Train Routefinding

[Teshi]

I have been playing OTTD for decades, mainly using a very old version of the game game, and mainly just to build huge train systems. Recently (Spring 2023), I downloaded a new version and I've noticed a change in train routefinding from the previous version I had that probably dated back ten years. I'm not sure if this is just me not playing well with an updated routefinding mechanism (i.e. I can fix it by using different lights or settings), or if this is an "improvement" I just don't like. I've looked for settings that might help, but not found anything.

In the new version I now have, trains seem either less patient or far stupider than they did before and the game is less fun. It's hard to tell exactly what is happening, but I'll try to explain...

Trains now seem to privilege shorter station waiting times over shorter travel times. In the new game, trains seem to take the first available route that might take them to their destination, however long it is, rather than simply waiting for a clear line on the most direct route. This leads to ridiculous routes, with trains doing huge loops to get to their allotted stations rather than simply waiting a few seconds. It vastly reduces the efficiency of the train system and, frankly, kind of ruins the game as I'm spending all my time untangling trains from stupid situations. I can't just trust the trains to take allotted routes themselves, even if I put really close together lights or assign waystations--it's not different than stations. A single train leaving at the same time in the same direction, if it occupies the track before any lights, seems to trigger a train to leave the station on an alternative route, usually an insanely roundabout one. I just want trains to wait their turn and go direct!

In the older game I'm used to playing, trains ALWAYS privileged distance over amount of station waiting time, and would only take circuitous routes if there was a severe blockage. Like a real train, they would simply wait their turn to take the most obvious route, i.e. the route they were intended to take. This meant I could mostly just let them get on with the business of delivering goods or passengers. I'm not an especially technical player. I like to just get up a system that feels like it offers towns a good railway service, so this frustratingly stubborn train behaviour gets in the way of the way I play the game.

I assume other people aren't struggling with this as it makes trains really annoying to deal with. Am I doing something wrong with the 'new' routefinder, perhaps something to do with lights? Is there a setting that I'm missing regarding how patient my trains are or a toggle switch that privileges distance over waiting? Or am I supposed to be micromanaging timings, or something?

I also strongly dislike the darker patch of "active track" that follows trains around. Is that deliberate? Can I turn it off?

Please help!

[skc]

If you place a waypoint just after the exit from a station AND also after a junction, you can ensure the trains will take the preferred route.
Another option would be to put a 'station bypass loop' around the station, so that express services can bypass the station without taking a massively long (de)tour.

The 'darker' patches indicates that you've got 'show path reservations for tracks' turned on.

[Eddi]

check the setting "firstred_twoway_eol" in the console. on some network build styles it can cause the behaviour you describe, taking extreme detours to avoid a red signal.

the track darkening can be disabled in the settings, yes (but it should be disabled by default)

[2TallTyler]

"Show path reservations" is enabled by default since so 1.11 (April 2021). This was part of a collaborate effort to improve default settings for new players (expecting more experienced players to tweak the settings to their liking).

"firstred_twoway_eol" has been enabled since 13.0, but it only does anything if you use two-way block or pre-signals. It does not affect path signals. Here's more info about what it does.

[Transportman]

Usually trains should take the shortest most direct route* and only takes (minor) detours if that most direct route is blocked but a similar route is available. The firstred_twoway_eol setting being referred to changes the behavior of two way block signals, if one is red it effectively marks the route as end-of-line, making the pathfinder not consider that route any further.

Can you maybe post a screenshot or even better a savegame where this behaviour you don't like is happening?

*With some consideration for sharp turns, crossings, height changes and ideal platform lengths for trains.

[Teshi]

Thanks all! I think the "firstred_twoway_eol" setting may be the issue--the behaviour described sounds right. I do use two-way block signals as my standard signal--I had no idea they were supposed to be an advanced setting. I suppose I'm an unusual user--well-established, but not technically advanced.

I find this choice to activate this setting by default a strange one if it's intended to help newbies. In the game, block signals are described as "the most basic signal type" and a single click (implying simplicity) puts in two-way signals. The "only use these signals if you're an advanced user and you understand their use" is not super helpful if the instruction is in an article on the WayBack Machine. Put another way, the game language (literal and symbolic) is at odds with the choice to make this setting the default for new users, as it introduces a behaviour that is detrimental to the casual user.

I speak from experience--it put me off the game for months before I thought of asking here.

I have changed the settings and will report back. Appreciate the help!

[Teshi]

Important question: Will the change to the config settings affect old games or not?

So far, I'm still seeing the same behaviour.

This does seem to be the problem, however. Looking at behaviour of trains in a 2050+ game with lots of routes and trains, a red light directly ahead does cause a train to act as if the route doesn't exist, to even try an impossible route (i.e. one blocked by signals), and then to select an alternate (and ridiculous) route, often involving backtracking to its origin station. I'm also seeing bad behaviour in the form of trains in double-ended stations looping through the platforms until they perceive there is a track open.

The next thing I can try is replacing all my double block lights with singles.

[skc]

Important question: Will the change to the config settings affect old games or not?

If you are at the 'main menu' screen and change config settings, all new games will be affected, and any settings that are not stored in a save-game file will affect all existing games.
If you have loaded a game (starting a new game, or from a previously saved game), game settings which you change and that are stored in the save-game will ONLY affect that single game.

In all cases, the 1st row of information for each (and every) setting is the 'Setting type", which will be one of:

• "Game setting (stored in saves; only affects new games)"
• "Game setting (stored in save; only affects current game)"
• "Client setting (not stored in saves; affects all games)"

The two variations of the "Game setting" text are because the 1st is what's shown when accessing the settings from the main menu screen, while the 2nd is from within a game.

[Teshi]

To change the config file, the instructions say to actually go into the config file where the game is stored. I did this.

From your comment, I'm guessing that only new games will will be affected by my config change, so I'll have to rig up some kind of test to check this.

[skc]

To change the config file, the instructions say to actually go into the config file where the game is stored. I did this.

From your comment, I'm guessing that only new games will will be affected by my config change, so I'll have to rig up some kind of test to check this.

There are some settings which are only accessible through the config file, but have so rarely had to worry about those that I keep forgetting that there's extra settings beyond what's available through the GUI.
As for whether they'll affect all games or only new games - I've no idea, actually.
What I do remember about editing the config file is that you must do it only when OTTD is completely closed as it gets written out each time OTTD closes.

[Emperor Jake]

I find this choice to activate this setting by default a strange one if it's intended to help newbies. In the game, block signals are described as "the most basic signal type" and a single click (implying simplicity) puts in two-way signals. The "only use these signals if you're an advanced user and you understand their use" is not super helpful if the instruction is in an article on the WayBack Machine. Put another way, the game language (literal and symbolic) is at odds with the choice to make this setting the default for new users, as it introduces a behaviour that is detrimental to the casual user.

Your game probably inherited settings from your previous install. With a fresh install, the block signals aren't even visible by default and the path signals are the default signal, which is simple and directs new players to using path signals only. Give this a read for a more detailed reasoning behind this choice https://www.openttd.org/news/2021/11/06 ... -ui-change

To change the config file, the instructions say to actually go into the config file where the game is stored. I did this.

From your comment, I'm guessing that only new games will will be affected by my config change, so I'll have to rig up some kind of test to check this.

If you change the settings via a console command, you can do it while the game is running. For example

Code: Select all

set yapf.rail_firstred_twoway_eol false

will disable the twoway eol setting.

[Teshi]

I think I probably turned the signals back on myself, not realising that turning them back on would create a different situation than what I was used to. I am precisely the "far-fetched use-case" (as another user described) that JGRennison was highlighting in the thread here, haha.

JGRennison wrote:

I would suggest that having it in the settings window with a detailed explanation of what it does should probably be done even if it is not actually turned on by default.
If it is turned on by default it should be absolutely be in the settings window as people trying to make old school block signal networks will either need to turn it off or be made aware of its existence and adjust their signalling accordingly.

They were right! There was a person! I definitely would have appreciated some kind of heads up.

Okay, after much guessing, I have managed to confirm that my setting for this thing is turned to false (although it's still not clear to me that it's affecting an existing game). When I get some free time I will recheck how things are working.

[Teshi]

Okay, I think it works. This setting turned on, my trains do loops through more complicated stations--I can sit and watch them take loops. With it turned off, they do not. Thanks all for your help in resolving this issue.

I think the discussion about legacy long term users in some of these discussions is right. This is a great game, and lots of people learned in the 90s and are either still playing, or are now introducing their children to the game--they'll be teaching those kids the methods they learned a quarter-century ago. Furthermore, the approach on this forum tends to be extremely high-level. I'm not sure if you necessarily realise how sophisticated your discussion is. You're mostly experts, and to outsiders the discussion is arcane and impenetrable, even in documents that are intended to help. It's like being a high schooler and walking into a graduate school classroom--there's a gulf in language use and comprehension that is difficult to bridge, even if you do have a solid grasp of the game.

Generally, I think you would all hate my signal systems. I did tried to learn from these and other forums but what I've ended up with is clearly, uh, unique. However, with this setting turned off, my systems do work and the trains seem to run in an efficient way. I'm not a technically-minded person and I don't really play the game like a technical puzzle, so relearning signal systems at this point doesn't seem that fun. Someday, maybe.

Thanks again!

[Transportman]

Okay, I think it works. This setting turned on, my trains do loops through more complicated stations--I can sit and watch them take loops. With it turned off, they do not. Thanks all for your help in resolving this issue.

I think the discussion about legacy long term users in some of these discussions is right. This is a great game, and lots of people learned in the 90s and are either still playing, or are now introducing their children to the game--they'll be teaching those kids the methods they learned a quarter-century ago. Furthermore, the approach on this forum tends to be extremely high-level. I'm not sure if you necessarily realise how sophisticated your discussion is. You're mostly experts, and to outsiders the discussion is arcane and impenetrable, even in documents that are intended to help. It's like being a high schooler and walking into a graduate school classroom--there's a gulf in language use and comprehension that is difficult to bridge, even if you do have a solid grasp of the game.

Generally, I think you would all hate my signal systems. I did tried to learn from these and other forums but what I've ended up with is clearly, uh, unique. However, with this setting turned off, my systems do work and the trains seem to run in an efficient way. I'm not a technically-minded person and I don't really play the game like a technical puzzle, so relearning signal systems at this point doesn't seem that fun. Someday, maybe.

Thanks again!

A lot of changes have been made to make the signalling system more accessible to users. Only showing path signals is part of that, as those signals are (almost) impossible to do wrong and also handle most use cases properly (junctions, multi-platform stations), while block signals allow more complex setups but are also easier to make mistakes that break the train flow.

The EOL setting referred in this topic is something that usually is required for a lot of the advanced block signal setups, and with hiding the block signals by default, it makes sense to set the EOL setting to true by default, as users going to the more advanced signal setups will have more experience with the game and how signals work, but the setting might still be hidden a bit.

But i'm curious to know how your system is know if it requires the EOL setting to be disabled, as you should not notice the setting in normal gameplay and only when using two way block signals (which you should not spam everywhere) should you notice it.

[Eddi]

in the before time, when path signals were *cough* experimental *cough*, the reason why i hated the EOL behaviour was the following basic station setup:

Code: Select all

--<---><SSSSSSS><---<--
    X             X
-->---><SSSSSSS><--->--

a train would try to leave the station, but encounter a red signal and instead of leaving in the proper direction, they would turn around, only to loop back onto the other station track with a 90° turn. this leads to using excess capacity and frequent deadlocks.

PS: with path signals this station setup is much simpler and a lot less error prone.

[Teshi]

only when using two way block signals (which you should not spam everywhere) should you notice it.

Got it in one!

a train would try to leave the station, but encounter a red signal and instead of leaving in the proper direction, they would turn around, only to loop back onto the other station track with a 90° turn. this leads to using excess capacity and frequent deadlocks.

Yes. This was a major problem until I turned the thing off. Since I use stations like that in a lot of scenarios, all lines were incredibly inefficient, especially large drive-though delivery stations, like at a factory. I'd lose tons of capacity just from trains doing stupid 180 degree loops through the station and then ALSO driving off into the wrong routes (like to the wrong farm) just because the route was currently open. It was routefinding gone bananas, which previously caused no issues.

*

One-way block signals only allow trains to go one way. I find this annoying in certain situations--it's sometimes useful for trains to be able to back out. I think probably what's now intended is to replace those block signals along a route with path signals.

I use block signals because I learned this game sometime in the 1990s when block signals were all there was, and in the glorious isolation days before there were such things as internet tutorials. You either read the instruction manual (which I did not as like an 8 year old), you learned from someone else, or you figured it out for yourself. I only much later figured out a way of allowing (for example) multiple trains in two-ended stations through a mixture of trying to interpret people's tutorials and trial and error.

Until I updated, block signals presented no issues at all, because they behaved, as far as I can tell, pretty much exactly like path signals do when used along a single length of track.

I ignore the entry, exit and combo signals whose descriptions remain wholly cryptic.

[odisseus]

exit and combo signals whose descriptions remain wholly cryptic.

If you don't understand pre-signals, you really should stick to path signals. They are very easy to learn, and they cover every conceivable use case for an unsophisticated player. Moreover, they allow some track layouts which are unfeasible with block signals, such as two-way single track with passing loops.