Way Directions

[Spartanis]

This is a topic that can be discussed in any pak set, so I think this sub-forum is probably the best place to ask a quextion regarding WAY Directions.

When "Query"-ing a road, you have a dialog box showing information. I have noticed that it also shows the DIRECTION number. This i can understand, for a road facing certian direction has a unique number. Eg: heading north-west (corner road) is Direction 3. A crossroad (or intersection) has a Direction number 15.

My question is. Can we USE this, when creating dat reference? For example. Two lanes intersection. I place a say.. Roadsign image of line markings, to tell the Simutrans bot (or program) these lanes that at the "crossroad" of the intersection, the vehicle cannot turn left nor right into another road (it has to keep driving straight ahead). (Imagine you are driving towards the intersection, you'd normally change lane to the left before turning left right? well, you would turn left fromt eh right most side of the lane?) but ALSO that the oncoming perpendicular traffic can drive straight thru.

I hope i make sense here?

[Ashley]

The ribi for a tile apply to all the paths possible through it. There are 4 "fundamental" directions and these are combined bitmask style to give the overall number. E.g. 1 is North, 2 East, 4 South, 8 West (I believe these are the right numbers). So a crossroads would have ribi value 15 (1+2+4+8), a straight-line road from North to South 5 (1+4) etc. Masking this value further wouldn't make sense since that would essentially be the same as just modifying the underlying road itself. E.g. putting a roadsign on a tile which changed the ribi from 14 (East-West road with a T-junction to South) to 10 (East-West road) would be the same as simply deleting one branch of the T-junction.

No-entry signs can already be used to this effect to control one-way access to a particular tile from another one.

The representation as it is currently doesn't describe the individual paths which can be taken through a tile (e.g. saying "you can go from South to West, from South to East, from West to East and from East to West etc.) it simply says "when you're on this tile, you can leave via the South, West or East direction". That isn't enough information to do what you desire.

[VS]

Yup. The implicit assumption that all sides are always connected means that you can't create eg. a X-crossing that forbids turning. An [easy to imagine] change would be making the ribi directional, so that there would be 8 bits instead of 4. That still doesn't solve the problem as stated here, which would require switching the representation to connection between individual sides, which would need 16 bits.

I guess it's a rather low-level design choice that can't be avoided without other problems. Switching to connection-based structure would allow 100% TTD-style tracks and switches, with another set of problems.

BTW: when creating roads, you already use directions - they dictate what will be the picture used

[Spartanis]

Thanks Timothy and VS, Now i understand further about Ribi's and such.  You are saying that a Road connects to every possible direction UNLESS stated by a road sign. Got it! ::Thumbs up::

I suppose One ways and low level design is the only way (Bridge over perpendicular road) and a series of connected roads with one ways placed all over the joint). Well.. for now.. I hope..


It is a pity that a road sign cannot be placed on a junction (according to pak64 standard)

[prissi]

TTD style ribis would be fine, since they are no longer integrated into the ground. Increasing their size would not hurt the game much and might benefit those directional stuff. For rails even in pak64 there are matching images (although not all are used right now).

Although I am not sure how to build those properly without making the way building menus an even greater mess.

But I am open to a patch to get this behaviour.

[VS]

I have played OpenTTD a lot during summer and I must say its track construction methods are a good way to induce swearing and RSI, if anything. The interface mess is another consequence. I can't really imagine replacing the current method... it's very pleasant, given how few clicks it needs. I would see GUI as problem number one, in case this happens.

[Spartanis]

I agree VS, Considering the number of options and tools to create such things would be staggering alot, so much so, the toolbar would fill the entire screen!!! lol

Sure, one can clean it up in menuconf, but then you be spending something like an hour clicking this, then that, then this, then that, then this, and so on, just to get to the tool you need, assuming you know where it is!!

[An_dz]

I never played OpenTTD, but I think I understood how it works. You need to keep opening menus to build road pieces. Fewer clicks, better.
I think Spartanis asked specially thinking on one-way roads. To make the car go to other lanes. Am I right?

And since nobody wrote about the Ribi in the binary way here it goes:

The ribi is a 4 digits binary number. In this format: WSEN
If the road 'goes' to this direction it's an 1.
That's why N-S road have ribi 5: 0101
And a N-W 12: 1100
And the 4-way-cross is 15: 1111

If a sign is placed in a N-S road (Ribi:5 Bin:0101) telling to not go south (Sign Ribi:4 Bin:0100) It's mathematic:
0101 -
0100 =
0001
The road is now ribi:1

[Ashley]

Regarding the way-building complexity I did some work into a system which would use 8 directions (major and minor compass points, e.g. the edges and vertices of a tile) and then sub-divide that into 3. This gives some rather neat properties including nice-looking and easy to build ways. The building was centered around the idea of either constructing single or double track, you click to place the start of a section and then click to place the end (with a live-preview of the way-building based on a path-finding algorithm in between). Junctions get constructed automatically (as would bridges etc. eventually...) For fine-tuning complex trackwork I'd just use a little pop-up window to let you manually edit the paths through the tile.

I never finished the implementation I was working on though.

Some discussion from the old forum: http://archive.forum.simutrans.com/topic/04061.0/index.html

[Ters]

With the so called TTD style ribis, would it be possible to have the normal construction tools set them up to produce a result identical to todays simutrans? One or more special tools, in the latter case on a submenu, could then be used for fine tuning by those who wish to spend time on it. Maybe the tool would open a window like in Timothy's solution.

Alternatively, setting up ribis to match the direction one uses the tools might also be possible, sort of like how trains appear to do it today. The remove track tool would work the same way to remove ribis, though here there is a problem if the user drags too far and how far too far is.

Unfortunately, I guess one needs to do a whole lot of work on the internals before it is possible to start experimenting with the tools.

[Ashley]

The key change is to switch from constructing ways between tiles and instead construct them between tile edges. I think using the edges may introduce complexity elsewhere in the game engine though. I was actually considering attempting to implement this style of ways in the game as the project for my compsi MSc degree next year... Whether or not that'll be practical I'll have to figure out.

[prissi]

The edges have lots of problems for a tile based game, as any corner would invoke three adjacent tiles. A lot of logic would be required to avoid tile one level different with a rail next to them (or in other word, this would impose quite a lot of additional restraints).

[Fabio]

Could it work with a 16 bits directional RiBi's?
for each entry direction, 4 bits for the outgoing directions:
e.g.

from N to N : 0 | 1
       to S : 0 | 1
       to E : 0 | 1
       to W : 0 | 1      
from S to N : 0 | 1
       to S : 0 | 1
       to E : 0 | 1
       to W : 0 | 1      
from E to N : 0 | 1
       to S : 0 | 1
       to E : 0 | 1
       to W : 0 | 1      
from W to N : 0 | 1
       to S : 0 | 1
       to E : 0 | 1
       to W : 0 | 1


NS bidirectional: 1100110000000000      
EW bidirectional: 0000000000110011      
NS direction N: 0100100000000000      
and so on...

default roads should keep the present behaviour, but it could be masked in a much more sophisticated way:
e.g. a tile-large highway NS with no grade intersection could have a 4-way juction masked like this:
0101101010000100 = N>S N>W S>N S>E E>N W>S
enabling traffic NS in both directions, exit only on the right, entry only turning right

[VS]

Also worth noting - 16 bits means 65536 possible images per way object

[isidoro]

Just some ideas:

• Fabio: if we keep apart "from N to N", "from S to S", etc. that would be 12 bits
• VS: if the images from N to S is the same as from S to N, that would be 6 bits: 64 images
• With such a system, diagonal tracks could be made closer than now.  If you try that now, you get a shape similar to multiple 8s

[Fabio]

Hi Isidoro, nice to have you around, again...

• Fabio: if we keep apart "from N to N", "from S to S", etc. that would be 12 bits

But from N to N etc. can allow / forbid turning back on that very tile, which could e.g. be forbidden by default and allowed only with special signals (this would be great specially for trains and trams, but also for road vehicles).
Would 12 bits vs 16 bits make a big difference?

• VS: if the images from N to S is the same as from S to N, that would be 6 bits: 64 images

Or, we could have a base image for N>S and S>N, but even for NSE in all the possible combinations etc... and use additional layers with stripes and horizontal markings (e.g. arrows) for the masked RIBIs

• With such a system, diagonal tracks could be made closer than now.  If you try that now, you get a shape similar to multiple 8s

This would simply be great!!!

[prissi]

I do not see why more than for bits are needed. Four bits four entering direction, four bits for exit directions. Eight bits, similar to openTTD.

The problem with diagonal tracks closer to each other would still occur, as those need two ways on a single tile. This will easily cause confusions with signals (as they can only be placed on every second tile). It would also cause many problems when a track crosses such a diagonal track. This again would only work on every second tile.

[Fabio]

I do not see why more than for bits are needed. Four bits four entering direction, four bits for exit directions. Eight bits, similar to openTTD.

But could this e.g. allow a vehicle entering from S going straight N or turning E, but forbid a vehicle entering from N turning E (just straight S allowed) ?

[prissi]

Well Openttd does this a little different. If you look closely, you have six different track directions.

left | (SW) upper - (NW) right | (NE) lower _ (ES) and then / (NS) \ (SW) Those are all bits that are needed (ignoring dead ends). It then just depends on the rules, that left | connects south with west and north, but not north only with south.

You could add then another flag for tiles endings and still be ok with seven flags.

[isidoro]

Hi Isidoro, nice to have you around, again...

Hi, Fabio.  In fact, I haven't lost contact and usually read the forum.

Well Openttd does this a little different.
[...]

I think that OpenTTD's is just the method proposed above.  Fabio included dead ends, even non-connecting (4 more bits) and was different left | (SW) when going from south to west than when going from west to south.  Therefore, 6 (OpenTTD) + 6 (to differentiate directions) + 4 (separate dead ends) = 16.

Closer diagonals are a certain consequence of OpenTTD's approach.  One tile with left | (SW) and right | (NE) bits activated are part of two closer (vertical) diagonals that can be followed by right, left in different upper cells and then repeat.  With present system, in Simutrans, if SW are connected and NE are connected, then WN and SE are also connected and thus the 8s shape when you try to build those closer diagonals.

Apart from that, also consider two closer parallel diagonal roads, that would also be possible but don't know if aesthetically appealing...

[prissi]

It would not work with roads, as the vehicles would overlap. Also in OpenTTD both ways are not seperated, that would make the block system of simutrans completely useless. For closer diagonals one would need to put two identical ways on a tile, one with | SE and | NW ribi each.

And to forbid turning, when there is a connection the openttd system is still: enough. If you want one way streets, you need way sign anyway, as one are using now. The pathfinder will use only the ribis from the way, thus a NE | and a NS do not jion on S, thus SE is forbidden. Can be done quickly using a table.

To have that flexibility ways in OpenTTD are done by overlay. I.e. you have a trackbed for NS/EW and four threeway crossings and one fourway trackbed. Thus essentially seven images, pus four overlauf images for the turning directions. This is no too bad, compared to the vast amout if you really need all combinations. The downside is, that especially at larger sizes such a system looks less pretty.

[Fabio]

To have that flexibility ways in OpenTTD are done by overlay. I.e. you have a trackbed for NS/EW and four threeway crossings and one fourway trackbed. Thus essentially seven images, pus four overlauf images for the turning directions. This is no too bad, compared to the vast amout if you really need all combinations. The downside is, that especially at larger sizes such a system looks less pretty.

This seems a nice option, how hard could it be to code it for ST?

[prissi]

Coding: quite possible, needs some ideas for single way signs (but we have a flag left); building crossings would depend on directions of start and end point, old savegames need to be converted meaningful.
Graphics: All ways have to be extended or it will cause utter confusion
Close diagonals: more work and with restrictions (crossings or signals only every second tile and not streets or channels) And the question of how to build diagonals at all? (because during wayfinding it is very hard for simutrans to figure out whether a diagonal is wanted or a crossing.)

The system would be just introduced for trains; all other modes of transport are not suited to that.

[Fabio]

Excluding (or, even, postponing) diagonals, could left turnings be enabled/disabled also for normal roads?

[prissi]

You can disable them already now by using a no entry sign ... I am not clear what you want to achieve.

Other than that, enabling such a sytem would require different road graphics. However, I am not sure, how those will look graphically.

[Fabio]

This is what I would like to achieve for roads.

In green the directions allowed, all the other forbidden:

[prissi]

That is not really doabale in any system without using asymmetric ribis, since you want a connection for down to left but not from left to down. But what is the purpose of that for a transport simulator?

[Ters]

I would assume the purpose is much the same as in real life. To turn left (or right in places where they drive on the left) means you have to cross a lane, disrupting traffic on it as well. (Unless you have to yield, in which case you have to wait until both lanes are clear, but I don't think Simutrans implements that.) In real life, safety is one reason for building such layouts, but efficiency is another, and that might apply to Simutrans as well, even without acceleration and deceleration lanes.

[Fabio]

Exactly for the reasons told by Ters.

E.g. this would be a very efficient road interchange, with full grade separation (cloverleaf layout) without two separate carriageways (not so important in ST).



Using masked RIBIs, on the other hand, would force citicars as well as player vehicles.

Could it work with a 16 bits directional RiBi's?
for each entry direction, 4 bits for the outgoing directions:
e.g.

from N to N : 0 | 1
      to S : 0 | 1
      to E : 0 | 1
      to W : 0 | 1     
from S to N : 0 | 1
      to S : 0 | 1
      to E : 0 | 1
      to W : 0 | 1     
from E to N : 0 | 1
      to S : 0 | 1
      to E : 0 | 1
      to W : 0 | 1     
from W to N : 0 | 1
      to S : 0 | 1
      to E : 0 | 1
      to W : 0 | 1


NS bidirectional: 1100110000000000     
EW bidirectional: 0000000000110011     
NS direction N: 0100100000000000     
and so on...

default roads should keep the present behaviour, but it could be masked in a much more sophisticated way:
e.g. a tile-large highway NS with no grade intersection could have a 4-way juction masked like this:
0101101010000100 = N>S N>W S>N S>E E>N W>S
enabling traffic NS in both directions, exit only on the right, entry only turning right