News:

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

Railway bend and switch/crossing angle limitation

Started by merry, September 30, 2009, 12:11:02 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

merry

Hi,

It's nice to see the graphic update fro switches only having one direction (in development/bug discussion).

BUT this is only eye-candy. Nice eye-candy, and something with future re-use too, but still only eye-candy.
I would agree with a number of others, that the allowance of very acute turns (on non-tramway track) is a significant unrealistic aspect of Simutrans. It's just not possible to turn a train on an adjacent-track 'U' or even a tight '90 degree' bend IRL. Trams manage 90 degree bends (just) but only very slowly.
At the moment, a lot of effort seems to be going into 'realism' in the debates in ST... so restricting rail tracks to 45 deg bends may be a worthwhile consideration.
It's always been something that's bugged me about ST. The original signalling block system was a more serious flaw, and interestingly, we were told for a long time that the signalling couldn't be improved, but then along came PBS control, which is simply lovely. So maybe the revised curves/switches isn't an unrealistic request...

So here goes: is it possible, given the increased realism of gameplay, to restrict rail track build to 45-degree bends. This woudl include switch & crossing [S&C] design. Adjacent-tile 'U' bends would be impossible, whether on plain line or S&C. Crossings between adjacent tracks would be 'trailing' or 'facing' by design, although it should be possible (at a cost) to build 'scissors' crossings too.

If it is, there would be some significant changes to gameplay. Reversal would always have to be by the means of 'shunt forward and reverse over the switch/crossing'. Junction layouts would be more fun to design. And probably a new signal would be needed (a one-way signal that does not restrict reverse working, allowing a reverse-direction train to pass as though the block was to the next facing signal (ie reserving the route from facing signal to facing signal, and passing through reverse signals of this type).

An interesting matter is raised here: IRL, S&C are a serious cost on build and maintenance. Modern railway track & signalling designs minimise S&C for this reason. Should ST impose a cost to build and maintain S&C beyond that of plain line? Especially for high-speed junctions (but then the effect of the curve on speed limits at the junction is an issue too - and the subject of separte development experioments it would seem).

Cheers - look forward to comments!
Tom.

PS If there was a previous topic & I didn't finid it, sorry; please feel free to moderate if required :-)


The Hood

Definitely support this!  I think the current triangular junctions in particular are somewhat unreasonable (except tram tracks), for the 90 degree reason above.  Switches on standard rail track would ideally be:

---------------------------
                          \--------
allowing S-bend type movements at passing loops / stations etc or

-----------------------------------
                        \
                         \
                          |
                          |
i.e. requiring a greater radius of turn for right angle junctions.

-------------------------------
                  \/
                   |
                   |
would no longer be possible except on tram / light rail layouts.

Would also support the idea that crossings / points cost more to maintain too.

Fabio

I support this extension too, it would be awesome!

Ashley

#3
This again :)

In Simutrans there are only 90 degree bends, anything else is merely graphical prettiness. The directionality of tiles is represented as one of the 4 compass points, North/East/South/West. Trains may only travel from one to another (the diagonal tracks are just a lot of corners placed together, and the endpoints of tracks are represented as a single "direction", e.g. [1]).

There is an additional restriction, paths through a tile are represented as a sum of the edges that are accessible, so for example if we make North = 1, East = 2, South = 4 and West = 8 a straight track section from North-South would be represented by the number 5 (1 + 4) and a T-junction from North-East-South would be represented by the number 7 (1 + 2 + 4).

What does this mean? Essentially you can't have a junction where trains can only go from North-South and East-South.

The obvious extension is to store paths through the tile as paths, e.g. instead of storing that T-junction as the number 7, store it as [(1,4),(1,2),(2,4)]. In this case we have 3 distinct paths through the tile that a train can take (and these can even be made one-directional for one-way tracks). Remove one and you get a Y-junction (but still only using 90 degree bends), e.g. [(1,4),(1,2)].

This is the way I'd recommend trying to implement your suggestion, and it would work (though you'd still need some kind of multi-tile rulesets to restrict U-bends in the track. This is simply a restriction of the 4-direction approach, to really solve this problem you need to go further...)


The obvious extension from that is to increase the number of directions to 8, including the half-compass points NorthEast, NorthWest, SouthEast and SouthWest. This would give you true diagonals, instead of being able to move from tile to tile only via the edges a vehicle can move from tile to tile via the corners as well. You'd continue to represent the paths individually, say with the following representation:

1 - North
2 - NorthEast
3 - East
4 - SouthEast
5 - South
6 - SouthWest
7 - West
8 - NorthWest

(Though the actual representation isn't important)

Thus you could have a track represented as [(1,5),(1,4)], which would be a smooth switch between North and South/North and SouthEast.

(For bonus points, you could increase the number of "endpoints" at each direction to 3, allowing double/single track to coexist in happiness).


Pros - Realistic looking tile-based tracks
Cons - Increased graphical complexity, massive reprogramming effort (everything would have to be changed)

See also:

http://forum.simutrans.com/index.php?topic=1459.msg14748#msg14748

http://archive.forum.simutrans.com/topic/03050.0/index.html

And here for a reference implementation:

http://forum.simutrans.com/index.php?topic=2474.msg31739#msg31739
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.

Fabio

If the problem were only (or mostly) routing, the pathfinding routine could consider the number of direction in consecutive tiles. e.g. is a train is coming from south to north, it turns east-north-east it is 45 degrees, and so on. so the pathfinder could refuse to route simply east, whereas accepting to turn east-north-east. (similarly, citycars don't U-turn)
the graphics would be trickier, but probably not impossible.

The Hood

I think Fabio is on to something here, which could mean that nothing needs to change with the track building.  A set of routefinding rules could be implemented (and this could be different for different waytypes, so that trams could have a greater range of allowed routes than heavy rail trains, etc.).  These could be included in a "routerules.tab", and for continuity with existing versions (so as not to break save games when people upgrade) the rules could be turned on and off in simuconf.tab.

E.g. Train:
East-East allowed (always allows straight ahead)
East-North-East allowed (allows 45 degree turns)
East-North-North banned (bans 90 degree turns)
East-North-West banned (bans 135 degree and 180 degree turns)
etc.

Tram:
East-East allowed (always allows straight ahead)
East-North-East allowed (allows 45 degree turns)
East-North-North allowed (allows 90 degree turns)
East-North-West banned (bans 135 degree and 180 degree turns)
etc.

Combined with the recent implementation of swithces, this should result in a realistic graphics implementation most of the time without any extra effort (as certain movements on the track layout could never occur according to the routefinding rules, so the switch would never show this).

I know this doesn't completely solve the problem, but it may be a good compromise which doesn't require a complete rewriting of everything.  Of course, being a naive non-coder, I could be completely wrong in that assessment and this idea MAY in fact need a complete re-write, but I hope not!

prissi

Of course "only" routing maens, that every structure, that holds direction information and vehicle directions needs to be touched (for real diagonals) For switches, "only" the ribis everywhere must be changed. This can be done with debugging in a month or so. However, given the unfinished buisness around, I would advice against open the can now.

So many things are not finished, like the advanced settings dialoge, networking, more configurable settings from the patches and also some patches are still not integrated.

And before 18. Oct a new stable is needed, since the largest german computer journal wants to burn it onto CDs ...

Fabio

so we'll start back bugging you after Oct 18, i'll put the date in the calendar :P

honestly, congrats! this is an awesome news! ;D

Ashley

To take this topic slightly back to the topic, here are a couple of graphics I found from ages ago.



This demonstrates the diagonal idea graphically, might make it easier to visualise.



This is pretty good for showing the problems with the approach of having different images representing the same structural layout of the tile. The three track layouts on the left are all the same in terms of the information stored by the game. The difference between them is the arrangement of the signals. Due to the placement of the signals trains are restricted in the ways they can move through the track arrangement and this restriction is reflected in the track graphics drawn. It also incorporates the idea of preventing a "180 degree" turn (e.g. two right-hand or two left-hand turns one after another). This would give you the potential for further masking the directions trains can move in while retaining the same structure internally to represent tiles. The problem with it is how complex it would get with really complex track layouts. It also doesn't really give you much benefit other than restricting the tracks that can be laid out and used. The diagonal system gives you more flexibility, whereas this takes it away in return for a small improvement in the graphics.
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.