News:

Simutrans.com Portal
Our Simutrans site. You can find everything about Simutrans from here.

Proposal for developping two-lane one-way roads

Started by isidoro, January 05, 2012, 06:23:20 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Fabio

On crossing:  if the car needs to turn right, use the right lane. If left the left lane (although it was not overtaking). if straight, keep the lane you're on...

TurfIt

Quote from: isidoro on January 10, 2012, 08:28:27 PM
What has to be done when it arrives to the new crossroads that force a forbidden change of lanes there?  For example, a one-way road was changed to a two-way and the lane the car wanted to go is now forbidden
When the player changes the road, well then it changes. Nothing new from the current behaviour when a player deletes a piece of the convois path is needed. The car stops and recalculates its route from there. If it 'illegally' jumps lanes, then so be it. The rules should cover the normal steady situation, and provide sanity for that.


Quote from: isidoro on January 10, 2012, 08:28:27 PM
Another possibility is that a working patch or development appears and continue from that in a more classical way of doing things.  I'm not going to do it, though.  It is a lot of time not to be sure if it will go in or not.
If a patch is complete/correct, in it goes. If not...
Formalized development methods might work in companies where people are being paid to program. For people spending their free time doing this, not so much.


Quote from: prissi on January 10, 2012, 09:31:28 PM
koord3d is used in packed struct of all ding_t and grund_t. Increasing its size, will align all structs to the next larger sint32. Given the millions of trees and grund tiles, this will have notable impact.
Not sure where this notion of adding to koord3d came from. I was quite clear in my idea of increasing it only where it's used in routes, and further only in routes along multilane roads; For the very reasons quoted.

However, it seems having the lane hints in the route is not desired anyways. Instead keeping a next_intersection_where_turning_index to tell the convoi a turn is upcoming, get into the correct lane is the preferred approach. I like this latter approach too, consistent with the next_signal_index, next_stop_index used for the rail vehicles.


Quote from: prissi on January 10, 2012, 09:31:28 PM
When a vehicle has 16 dirs those can be mapped directly to subtiles. Just put them in such an order, that division by 2 (or four) gives the desired image.
...
And a second mapping for overtaking vehicles (one the other lane)
How would this work for 3 lanes?  IMHO if we're going to the trouble of adding this, why restrict ourselves to 2.



Quote from: prissi on January 10, 2012, 09:31:28 PM
About crossings: With the envisioned implementation you cannot have oneway crossings. There is no way the program can find out which are the allowed directions. Imaging you have a threeway crossing, with ONEWAY type (since it would keep its previous type). This crossing was formed due to a sideway attached to the one. If this is exit only, the allowed directions cannot be guessed. Same for entry only.
Hence my suggestion of a intersection_t which would contain the allowable routes, and a GUI whereby the player can select the type of intersection, and hence the allowable routes. Otherwise, guessing?, read my mind.  ;)

isidoro

@prissi: now, I understand the koord3d problem, reworking system type to be flag-like is nice, and I like the sixteen directions ideas.

However, I see the crossroads you intend quite unnecessarily restricted.  The one-way flag in a crossroads may indicate if you can keep the * lane or you are forced to the right.  For instance, in a crossing like this one:

  ********************************
W* -->                     -->     E*
  --  --  -           -  --  --  -
W  -->                     -->     E
  *********           ************
          *  A  |     *
          *           *
          *  ^  |  ^  *
          *  |     |  *
          *     |     *
             S*    S


A car in the A position should be able to go on to E*.  With occupations, it only happens that traffic coming from W or W* may have to stop some times.  But I see no problem.

The one-way flag in a crossroads may mean "you can keep your lane" (1) or "you must stick to the right" (0).  When building a crossroads, the system may check adjacent tiles and check or clear the one-way flag.

And I see more problems.  What rules would enforce in more complex crossings like this one?:

                         N*    N
                      *           *
                      *  ^  |  ^  *
                      *  |     |  *
                      *     |     *
  *********************           ***********
W* -->                                 -->     E*
  --  --  -                       -  --  --  -
W  -->                                 -->     E
  *********           ***********************
          *  A  |  B  *
          *           *
          *  ^  |  ^  *
          *  |     |  *
          *     |     *
             S*    S


And why shouldn't vehicles arriving in lanes S*, and W* be forced to keep to the right?
What is the problem for the A vehicle to follow this path?:

                         N*    N
                      *           *
                      *  ^  |  ^  *
                      *  |     |  *
                      *  x  |     *
  *********************  x        ***********
W* -->           xxxxxxxx              -->     E*
  --  --  -    xx                 -  --  --  -
W  -->        x                        -->     E
  *********  x        ***********************
          *  A  |  B  *
          *           *
          *  ^  |  ^  *
          *  |     |  *
          *     |     *
             S*    S



Quote from: TurfIt on January 10, 2012, 11:04:26 PM
[...]
If a patch is complete/correct, in it goes. If not...
[...]
This is either not true or a tautology, you choose.


Quote
[...]
Formalized development methods might work in companies where people are being paid to program. For people spending their free time doing this, not so much.
[...]
I think, on the contrary, that if I know that my effort has a high chance of success, then I will invest time.  But, otherwise, I have to carefully think about it because otherwise the effort will go to the dust bin.  Imagine that instead of having this exchange of opinions, I would have spent 1 month in doing a patch with my first ideas and that should be reworked nearly from scratch because better ideas have come.  No way.

Put it the other way round.  If I know what is wanted and I can program the first step, I may invest some time.  Don't ask me a "read-your-mind" approach if you don't ask the same to the program...



TurfIt

Quote from: isidoro on January 11, 2012, 12:07:33 AM
For instance, in a crossing like this one:
A car in the A position should be able to go on to E*.  With occupations, it only happens that traffic coming from W or W* may have to stop some times.  But I see no problem.
Reasonable and expected for A to proceed S*->E*. In real life, such an intersection would likely be controlled by traffic lights for two lanes turning like that (or atleast an all-way stop). If no light, the second land would probably end before arriving at the intersection. In Simutrans, allowing two turning without the light is possible, W and W* would be stopped by the subtile reservation so no chances of collision, just might look wrong/weird.


Quote from: isidoro on January 11, 2012, 12:07:33 AM
And I see more problems.  What rules would enforce in more complex crossings like this one?:
Allowable paths:
  W* -> N* or E*
  W   -> E
  S*  -> N* or E*
  S    -> E
W->N movement would conflict with a W*->E* and similar S->N conflicting with both W*->E* and S*->E*. Forcing W* and S to stop is getting to looking too wrong/weird IMO.



Quote from: isidoro on January 11, 2012, 12:07:33 AM
What is the problem for the A vehicle to follow this path?:
Cutting across W into W*'s lane. But see first answer re traffic lights... and probably allowing anyways.


Quote from: isidoro on January 11, 2012, 12:07:33 AM
Imagine that instead of having this exchange of opinions, I would have spent 1 month in doing a patch with my first ideas and that should be reworked nearly from scratch because better ideas have come.  No way.
The more complex the patch, and the more possible ways to achieve the goal, the better to have a discussion first...
And OT, funny you mention reworking from scratch, yet want a translation of the German that forces a total rewrite of every existing/in progress patch.

prissi

@TurfIt
You have me convinced on the intersection_t type for crossings. They can not only have more fine grained routes, but also keep handles for the crossing vehicles and so on. In such a system it would make even sense to have the traffic lights as part of intersections, and not a roadsigns. This would solve some graphics issues too.

The lookup system with 16 dirs is as easy to extend to three lane roads as a calculation on the fly. It would be just three tables and 24 dirs. But I do not think we will come up with a good logic to distribute traffic on the fly on three lanes. Even scientific research projects on that were a big challenge. Not to mention the simutrans tiles system, as the third car would drive on the border between to tiles.

About implementation: It can go in parts.
- intersection_t class derived from strasse_t can be done independently and may even enhace the game as it is (like left only intersection).
- Making 8->16 dir can be done an tested; this may even make crossing blocking check easier (but won't touch there, since it may need vhange anyway.)
- Reserving subtiles either ahead on intersections and the next tile or on all ways it is currently on and change crossing behaviour on ist_weg_frei()
- finally change behaviour is on one way road

1.) and 3.) seems like most work. But those for stages can be submitted without breaking code.

isidoro

Quote from: TurfIt on January 11, 2012, 01:59:01 AM
Allowable paths:
  W* -> N* or E*
  W   -> E
  S*  -> N* or E*
  S    -> E
W->N movement would conflict with a W*->E* and similar S->N conflicting with both W*->E* and S*->E*. Forcing W* and S to stop is getting to looking too wrong/weird IMO.
I don't understand your preference for some paths against others.  For example, why W->N is wrong whereas S*->N* is not?  Your rules seem more a right of way implementation than something forbidden.  But right-of-way is not implemented in Simutrans at all.


Quote
And OT, funny you mention reworking from scratch, yet want a translation of the German that forces a total rewrite of every existing/in progress patch.
You seem to pick a lot of contradictions in my behavior I don't pick.  And contradictions don't seem bad to me, by the way.  In this case, it is not comparable to change the name of a variable or class name in a patch to have something to be reworked from scratch.  The former means reviewing the patch and changing some words, the latter means a full rework.  But I think we are wasting our time with all these things, aren't we?

Talking about contradictions, I'll point out one: you have reworked crossroads behavior so that more than one vehicle can be moving at the same time to speed up things, but you are for not allowing all possible not-crashing possibilities in a crossroads so that things are not going as fast as possible...

@prissi: I don't see the intersection_t (too much micromanagement, two equal crossroads may be "programmed" by the player differently with no visual cues to the simucitizens,...)

The 16 dir is equivalent to allowing all possibilities in crossroads except for "change of lanes".  If that is what is wanted, I would rename the directions like this:

S to N: +*/+* dir::StoN
S to E: ++/+* dir::StoE
S to W: **/+* dir::StoW
N to S: *+/*+ dir::NtoS
N to E: *+/** dir::NtoE
N to W: *+/++ dir::NtoW
E to S: **/*+ dir::EtoS
E to W: **/++ dir::EtoW
E to N: +*/++ dir::EtoN


prissi

intersection_t is needed to define crossing, where both lanes can turn right. Otherwise I cannot see in your system how to find out about that. It would also fulfill the request of a crossing with turning south only when arriving from east but allow all other direction from north and east. That would be the situation at the start of southgoing one way road.

The 16 dir are equivalent only for right lane. For left lane you would need another set (as I wrote). And the names of those dirs corresponds to the image definition in pak files. One can change them, but still need to provide a good mapping to pak file image index. Of those only 8 (or four) are needed.

isidoro

About the lanes, I know you propose 16+16=32 possibilities.  What I say is that you exclude another 16, those which imply a change of lane in the crossing.  Incoming from south left lane going to north right lane, incoming from south right lane going to outgoing east lane...  This last case doesn't sound so strange to me and the most natural path for me is this one:

             N1i   N1o            N2*    N2
          *           *         *           *
          *  |  |  ^  *         *  ^  |  ^  *
          *  v     |  *         *  |     |  *
          *     |     *         *  x  |     *
  *********           ***********  x        **********
Wo  <--              xxxxx --> xxxx             -->     Eo*
  --  --  -         x -  --  --             -  --  --
Wi  -->            x       -->                  -->     Eo
  *********        x  ********************************
          *     |  x  *
          *        x  *
          *  |  |  ^  *
          *  v     |  *
          *     |     *
            So     Si

But you forbid it, don't you?

What about this one?

             N1i   N1o  N2*    N2
          *           *           *
          *  |  |  ^  *  ^  |  ^  *
          *  v     |  *  |     |  *
          *     |     *  x  |     *
  *********           *  x        **********
Wo  <--              xxxx            -->     Eo*
  --  --  -         x             -  --  --
Wi  -->            x                 -->     Eo
  *********        x  **********************
          *     |  x  *
          *        x  *
          *  |  |  ^  *
          *  v     |  *
          *     |     *
            So     Si



The case with one one-way southbound way is this.  Why only allow Wi->So?

             Ni    No
          *           *
          *  |  |  ^  *
          *  v     |  *
          *     |     *
  *********           ***********
Wo <--                     <--     Ei
  --  --  -           -  --  --  -
Wi -->                     -->     Eo
  *********           ***********
          *     |     *
          *           *
          *  |  |  |  *
          *  v     v  *
          *     |     *
             So    So*


My proposal is:
1) Route finding only implies tiles, not lanes and thus, ribi masks that have already been set accordingly
2) At intersections, all possibilities (48) are, in principle, allowed, but
3) For each segment of one-way roads, route is looked ahead and this is the moment to force or not one lane.  The car, seeing its route will choose its lane at the end and drive accordingly.

I'll have to give up.  I can't see your points.




prissi

QuoteI'll have to give up.  I can't see your points.
So I am confused. I fail to see a big disagreement.

Quote1) Route finding only implies tiles, not lanes and thus, ribi masks that have already been set accordingly
2) At intersections, all possibilities (48) are, in principle, allowed, but
3) For each segment of one-way roads, route is looked ahead and this is the moment to force or not one lane.  The car, seeing its route will choose its lane at the end and drive accordingly.

I would also agree:
1) Route finding only by tiles (was this questionable?)
2) intersections: in your example of turning left I fail to see the advantage of turning left immediately. But anyway, this is much later in implementation.
But somehow we have to define crossings with two lane exists. This seems to require either extension to ways and ribis or a new class intersection_t. Personally I am for the latter, but anything that works fine is acceptable.
3) seems like the algorithmwise difficult part

and 4) reserve the subtiles on the way tile or, if on an intersection, reserve the subtiles until on a normal way tile. That way ist_weg_frei (in the yoshi87 test game the biggest performance hog when profiling after drawing) would be much faster too.

And what about stepwise implementation:
Quote
- intersection_t class derived from strasse_t can be done independently and may even enhace the game as it is (like left only intersection).
- Making 8->16 dir can be done an tested; this may even make crossing blocking check easier (but won't touch there, since it may need vhange anyway.)
- Reserving subtiles either ahead on intersections and the next tile or on all ways it is currently on and change crossing behaviour on ist_weg_frei()
- finally change behaviour is on one way road

1.) and 3.) seems like most work. But those for stages can be submitted without breaking code.

isidoro

The thing I can't see is why physically avoid all possibilities in crossroads, even the ones that imply a change of lanes.

I can't also see (because I don't understand your explanations) what are the rules you want to enforce at crossings, but I can live with that.  At the end, it seems that there are no certain rules and the player must set each crossroads path manually...  I don't like it, but it's ok.

And I don't understand because in real life, paths are not usually enforced, but entrance/exits that are either allowed or forbidden.  Some times path are enforced by arrows written on the road, but many times, that decision can only be taken when you see the overall structure of the crossroads/roundabout at a whole.

Therefore, my proposed steps differ from yours:
1) Open a branch, since some changes are not clear enough and a lot of people use nightlies
2) Refactor phase: no one-way roads at this phase.  The occupations are implemented, lanes state for convoys, occupying/freeing them, but only mixing with current behavior: crossroads and overtaking in two way roads.
3) One-way roads: a fake is_one_way is implemented so that one of present time roads in a testing pak is one-way.  Make one-way road builder to set ribis in one-way configuration and see the route is working ok, specially at crossroads.
4) Driving behavior: make cars in one-way roads change lanes at random and see that everything works, even at intersections (in this place, some of these paths are the ones you don't like, but you can avoid them later).  The rules here are that cars don't deadlock or bump into each other.
5) Make the car have some intelligence: the idea to check the route ahead in each segment of one-way roads to decide what is the lane enforced or desirable at the end of the segment for the car
6) intersection_t
7) further reservations
8) do a right substitution of is_one_way: new type, graphics, etc.
9) polish

I can contribute up to 5) if get some time.  From that on, I'm less proficient or don't believe in your ideas.

To clarify what is the behavior intended up to phase 5 in the two examples above:

             N1i   N1o            N2*    N2
          *           *         *           *
          *  |  |  ^  *         *  ^  |  ^  *
          *  v     |  *         *  |     |  *
          *     |     *         *  1  |  2  *
  *********           ***********  1     2  **********
Wo  <--                    --> xxx1222222       -->     Eo*
  --  --  -           -  xxxxxx             -  --  --
Wi  -->             xxxxx  -->                  -->     Eo
  *********        x  ********************************
          *     |  x  *
          *        x  *
          *  |  |  ^  *
          *  v     |  *
          *     |     *
            So     Si




             N1i   N1o  N2*    N2
          *           *           *
          *  |  |  ^  *  ^  |  ^  *
          *  v     |  *  |     |  *
          *     |     *  1  |  2  *
  *********           *  1     2  **********
Wo  <--              xxx1222222      -->     Eo*
  --  --  -         x             -  --  --
Wi  -->            x                 -->     Eo
  *********        x  **********************
          *     |  x  *
          *        x  *
          *  |  |  ^  *
          *  v     |  *
          *     |     *
            So     Si


In the two diagrams the car will take the N2* or the N2 path depending on the next direction the car is going to take in that segment of one-way road...

TurfIt

Quote from: isidoro on January 13, 2012, 04:45:40 PM
The thing I can't see is why physically avoid all possibilities in crossroads, even the ones that imply a change of lanes.
Do we want the roads in Simutrans to resemble certain Asian countries? Or something with a little more sanity? I prefer the latter; Which means some traffic laws prohibiting certain behaviour.  I truly hope while out driving, we never meet...


Quote from: isidoro on January 13, 2012, 04:45:40 PM
and the player must set each crossroads path manually...  I don't like it, but it's ok.
There are certain tile layouts from which the paths cannot be deduced from the layout alone. In those cases, some extra input from the player will be needed to ensure his intended intersection is the one built. Use of an actual object (intersection_t) would allow for different graphics for different intersections and provide graphical feedback to the player as to the allowable paths.


Quote from: isidoro on January 13, 2012, 04:45:40 PM
And I don't understand because in real life, paths are not usually enforced,
Lax enforcement of the rules by the police doesn't suddenly make something legal.

You mentioned right-of-way and it not being in Simutrans. Thanks for putting the word into my mouth, I think a right-of-way concept is what's been in the back of my mind all along. Imagine that tanker truck that's finally reached highway speed not having to slam on its brakes due to a car pulling out right in front... Realistic? perhaps not. Utopian vision? sure. My daily commute could easily be cut in half, if not for the traffic jams caused by the wanton disregard for the rules of the road. Maybe seeing a beautifully free flowing traffic system in Simutrans would spur some to try and emulate such when out driving. Now that's dreaming!  ;D


Quote from: prissi on January 11, 2012, 07:35:08 AM
In such a system it would make even sense to have the traffic lights as part of intersections, and not a roadsigns. This would solve some graphics issues too.
Exactly.    :)


Quote from: prissi on January 11, 2012, 07:35:08 AM
Not to mention the simutrans tiles system, as the third car would drive on the border between to tiles.
Don't follow this. The third lane would be where the trams go...


Quote from: prissi on January 11, 2012, 07:35:08 AM
About implementation: It can go in parts.
- intersection_t class derived from strasse_t can be done independently and may even enhace the game as it is (like left only intersection).
- Making 8->16 dir can be done an tested; this may even make crossing blocking check easier (but won't touch there, since it may need vhange anyway.)
- Reserving subtiles either ahead on intersections and the next tile or on all ways it is currently on and change crossing behaviour on ist_weg_frei()
- finally change behaviour is on one way road
Sounds like a plan. For the vehicle behaviour atleast. Any thoughts on the actually building/representing the oneway roads?

prissi

I think oneway roads go by just setting the system type and get their direction during building. The waybuilder will take care during building to set ribis correctly. That will be very easy, two hours at most.

One needs to forbid to built oneway signs on such roads. Easy enough, imho.

Graphics are a little more difficult. On could use the one end tiles (as anyway ribis are lacking for straight of such roads. Four diagonals, I am not sure. The longer I think, maybe one needs two images per road tile. That is the more ugly part, due to compatibly issues and the like. Need to think more.

I think we are not far off about implementation. Maybe we can ask TurfIt about an intersection class. You do the subtiles. I built oneway road and how to code them into paks.

Dwachs

@ Isidoro: in this layout



             N1i   N1o  N2*    N2
          *           *           *
          *  |  |  ^  *  ^  |  ^  *
          *  v     |  *  |     |  *
          *     |     *  1  |  2  *
  *********           *  1     2  **********
Wo  <--              x?x1222222      -->     Eo*
  --  --  -         x ?           -  --  --
Wi  -->            x  ?              -->     Eo
  *********        x  **********************
          *     |  x  *
          *        x  *
          *  |  |  ^  *
          *  v     |  *
          *     |     *
            So     Si


It is not clear, whether the border marked with ?? can be one or two directional, here the player has to decide, as there is not possibility to build a one-way road tile there. Maybe this is TurfIt remark. I did not understand it either.
Parsley, sage, rosemary, and maggikraut.

prissi

Apart from the path through to above crossing is not a direction vehicles have graphics for ...

isidoro

#49
Quote from: TurfIt on January 13, 2012, 05:15:47 PM
Do we want the roads in Simutrans to resemble certain Asian countries? Or something with a little more sanity? I prefer the latter; Which means some traffic laws prohibiting certain behaviour.  I truly hope while out driving, we never meet...
You should be more careful with your remarks or somebody may be offended.  Remember that people of some of the so called now civilized countries used to wear helmets with horns and raid the coasts of Europe whereas some of the uncivilized ones were the origin of our nowadays culture and kept and transfer civilization to us in the Dark Ages...  I recommend you to actually visit Spanish Alhambra in Granada to fully check my point with your own eyes.  Not to mention slavery, witches' burning in the fire, native Americans...

Back to topic: my point is that we must separate physical behavior from forced behavior.  The game engine can be prepared to do all possibilities but, if wanted, enforced one of them.  Even in your most civilized countries, no law of physics stops you from moving from one place to another...  Only traffic laws.


Quote from: Dwachs on January 13, 2012, 10:11:43 PM
@ Isidoro: in this layout


             N1i   N1o  N2*    N2
          *           *           *
          *  |  |  ^  *  ^  |  ^  *
          *  v     |  *  |     |  *
          *     |     *  1  |  2  *
  *********           *  1     2  **********
Wo  <--              x?x1222222      -->     Eo*
  --  --  -     A   x ?    B      -  --  --
Wi  -->            x  ?              -->     Eo
  *********        x  **********************
          *     |  x  *
          *        x  *
          *  |  |  ^  *
          *  v     |  *
          *     |     *
            So     Si


It is not clear, whether the border marked with ?? can be one or two directional, here the player has to decide, as there is not possibility to build a one-way road tile there. Maybe this is TurfIt remark. I did not understand it either.

Well, in my way of seeing things, it doesn't matter.  Let's see the ribi masks, depending on how we built the crossroads:

First method.  First, two way roads:
             N1i   N1o
          *           *
          *  |  |  ^  *
          *  v     |  *
          *     |     *
  *********           *
Wo  <--               *
  --  --  -           *
Wi  -->               *
  *********           *
          *     |     *
          *           *
          *  |  |  ^  *
          *  v     |  *
          *     |     *
            So     Si


Then, first one way road:
             N1i   N1o
          *           *
          *  |  |  ^  *
          *  v     |  *
          *     |     *
  *********           **********************
Wo  <--               >    -->   >   -->     Eo*
  --  --  -           >  --  --  >   --  --
Wi  -->               >    -->   >   -->     Eo
  *********           **********************
          *     |     *
          *           *
          *  |  |  ^  *
          *  v     |  *
          *     |     *
            So     Si


Then, second one-way road:
             N1i   N1o  N2*    N2
          *           *           *
          *  |  |  ^  *  ^  |  ^  *
          *  v     |  *  |     |  *
          *     |     *     |     *
  *********           * ^^^^^^^^^ **********
Wo  <--               >           >  -->     Eo*
  --  --  -           >           >  --  --
Wi  -->               >           >  -->     Eo
  *********           **********************
          *     |     *
          *           *
          *  |  |  ^  *
          *  v     |  *
          *     |     *
            So     Si

Ribi masks are:
  cell A   cell B : all allowed
  cell A > cell B : from A to B allowed, from B to A not allowed
  cell A < cell B : from B to A allowed, from A to B not allowed
  cell A * cell B : from A to B and from B to A not allowed


But we can build the same this other way:

Second method.  First, two-way roads:
             N1i   N1o
          *           *
          *  |  |  ^  *
          *  v     |  *
          *     |     *
  *********           ***********
Wo  <--                    <--    Ei
  --  --  -              --  --
Wi  -->                    -->    Eo
  *********           ***********
          *     |     *
          *           *
          *  |  |  ^  *
          *  v     |  *
          *     |     *
            So     Si

Then first one-way:
             N1i   N1o
          *           *
          *  |  |  ^  *
          *  v     |  *
          *     |     *
  *********           **********************
Wo  <--                    <--   >   -->     Eo*
  --  --  -              --  --  >-  --  --
Wi  -->                    -->   >   -->     Eo
  *********           **********************
          *     |     *
          *           *
          *  |  |  ^  *
          *  v     |  *
          *     |     *
            So     Si

Then, second one-way road:
             N1i   N1o  N2*    N2
          *           *           *
          *  |  |  ^  *  ^  |  ^  *
          *  v     |  *  |     |  *
          *     |     *     |     *
  *********           * ^^^^^^^^^ **********
Wo  <--                           >  -->     Eo*
  --  --  -                       >  --  --
Wi  -->                           >  -->     Eo
  *********           **********************
          *     |     *
          *           *
          *  |  |  ^  *
          *  v     |  *
          *     |     *
            So     Si


In the former case, the paths in my example are allowed.  In the latter, coming from Si, only Eo lane (no change of lines) is allowed in the first crossroads.  To put it clearly, one-way flags is only valid for not crossroads.  In crossroads, the actual ribis are to be looked up.


Quote from: prissi on January 13, 2012, 11:14:22 PM
Apart from the path through to above crossing is not a direction vehicles have graphics for ...
True.  But may be approximated by two subpaths: first half N image, second half NE image.


Edit: add some ribi masks that were left and red color to make them clearer to see.

prissi

Maybe instead of intersection_t we could extend way ribis by entering and tile exit ribis just like OpenTTD. That would allow crossings fine control (and at the same time also introduce real railways switches ...) A reservation of subtiles for roads could be part of the road class of course.

isidoro

Now I see the difference between the system type and a flag for indicating one-way:

     
  • if a flag is chosen, all roads could be made one-way, even the most basic ones in the pak, and a new interface is needed when building to indicate one-way
  • if it is a system type, specific graphics should be made and a separate type or road

Am I right?

prissi: how do OpenTTD ribis work?

Those four entering ribis would be redundant as is the one-way flag.  One can always check the exit ribis of the neighbor tile, can't one?


Ashley

Presumably by storing paths through a tile as a list of entering edge/exiting edge tuples (which may be directional). I developed a system along these lines which permitted 8 directions of motion (i.e. true diagonals, movement from tile vertex to tile vertex) and double/single track mixing. There's a demo here. I considered trying to implement it for Simutrans at the time, but decided not to due to lack of experience with C++ and time.

The idea is you have 3 entry/exit points from a tile per edge or vertex, one to the left, one to the center, one to the right. Implementation of the 4 vertex entry/exit points is what gives you 8 directions of movement (and permits you to move from a tile to any of the 4 tiles which are located at its corners directly).

Each path through the tile is stored as a tuple, e.g. from East-Center to West-Center, or from North-Left to South-Left. Switches come about by having multiple paths through the same tile. Double track similarly by having both left and right paths.

Since this means 24 endpoints, excluding same-end and very tight curves (but including duplicates) you still get 24^15 possible track combinations (which is a lot!) so nobody is going to be drawing these by hand. I solved this problem by procedurally generating the graphics and then using caching/compositing to draw the final tiles.

You get quite realistic looking railways this way, with nice switches (animation could be added if desired) and a fairly full array of possible track layouts. Block reservation for conflicting movements can still be done per-tile, although some logic is needed for coping with the crossing of the vertex-adjoining tiles due to overlap in the graphics (if only octagons tessellated...)

May be worth considering...
Use Firefox? Interested in IPv6? Try SixOrNot the IPv6 status indicator for Firefox.
Why not try playing Simutrans online? See the Game Servers board for details.

isidoro

My perception, and I'm perhaps the less qualified here, is that it is nice, but it would imply a lot of work and redoing many aspects of the game.  For instance, route searching, movement, graphics...

This idea of extending two-way to one-way seems simple enough to me and we have already filled 3 pages and written not a line of code...

It also seems to me very nice the two step terrain tiles you also have in your image.  Those two things can be made more simple if a 3D version of ST eventually comes to life and we get rid of the tile slavery once and for all...



Spartanis

Assuming that these roads still be one tile set? or they be a whole new sets of 2x1, 3x1, 4x1 tile sets?

Isaac Eiland-Hall

It's a moot point since it's an early discussion, at the very most.


EDIT: What I mean is: It's not a lack of graphics that are preventing single-lane roads or whatever. It's a matter of the way the game is coded. It's not like we're sitting here thinking, "If only someone would paint roads, we'd have this feature!" - that is not at all the case.


Your enthusiasm is appreciated, but it's not a simple issue.

Spartanis

Quote from: Isaac.Eiland-Hall on June 04, 2012, 04:52:17 AM
It's a moot point since it's an early discussion, at the very most.


EDIT: What I mean is: It's not a lack of graphics that are preventing single-lane roads or whatever. It's a matter of the way the game is coded. It's not like we're sitting here thinking, "If only someone would paint roads, we'd have this feature!" - that is not at all the case.


Your enthusiasm is appreciated, but it's not a simple issue.

I understand what you are saying Isaac, but Due to my testing of a simple road surface, Upscaled Vehicles to match scale, new ONE WAY Signs that painted on the road. .. And draw the roads at every possible scenario.. interstection, t-junctions.. double lanes.. triple lanes, quadral lanes.. and so forth...

I then create a LINE to make teh vehicle go from point A to point B via a series of waypoints. The behavior of the vehicle works. so it IS a simple issue. Unless you spot something i missed....

The thing is.. Roads are there to be driven on. We can drive on the road to go anywhere. The only restriction, is road signs and road rules.. with out those, any simu-citizen can drive their cars and crash into each other!.. so.. Road signs and such is important.

But neverthanless.. What this bloke is attempting, is to create something very similar to Sim City style..

it is commendable to undergo such acheivement, but i prefer the old fashion way.. Single tile with road signs.. That way, i can create A MILLION possible road directions.

:)

But dont let that stop any of youse to work the new feature coding.  Which would reduce the tedious "ADD WAYPOINTS" between two STOPS :)

Ters

It seems like you have a different idea of two lane roads, or I'm reading your post completely wrong.

Spartanis

Quote from: Ters on July 01, 2012, 12:07:42 PM
It seems like you have a different idea of two lane roads, or I'm reading your post completely wrong.

Thats Possible... We shall see if this project is completed..  and/or my pakset is completed. Then I can compare the two...

Isaac Eiland-Hall

Quote from: Spartanis on July 01, 2012, 10:28:30 AM
I understand what you are saying Isaac, but Due to my testing of a simple road surface, Upscaled Vehicles to match scale, new ONE WAY Signs that painted on the road. .. And draw the roads at every possible scenario.. interstection, t-junctions.. double lanes.. triple lanes, quadral lanes.. and so forth...

I then create a LINE to make teh vehicle go from point A to point B via a series of waypoints. The behavior of the vehicle works. so it IS a simple issue. Unless you spot something i missed....

Your post doesn't relate to the topic at hand. I'm glad you're able to get something you want working now, but the topic is to discuss two lanes of traffic going the same direction on a single tile.

Spartanis

Quote from: Isaac.Eiland-Hall on July 02, 2012, 04:03:28 PM
Your post doesn't relate to the topic at hand. I'm glad you're able to get something you want working now, but the topic is to discuss two lanes of traffic going the same direction on a single tile.

aaaaaaaaaaaah.. NOW i understand.. i assume it was something else entirely.. thanks for clarifying that Isaac!

Now that i know, yes, this WOULD be a useful feature

wernieman

Sorry for the late Answer ... but did somebody work on it?

I have some Ideas ... but when somebody work on it, it could be "douple work"
I hope you understand my English

prissi

As this laid dormant for nearly a year the answer is obviously no. And a lot of "simple" and complex approaches were discussed in there too.

isidoro

wernieman, please go ahead.  I'll be "out of the business" for some time, but if you decide to work on it, please share your ideas so that we can support/help.