Train pathfinding that takes chain signals into account.

[Leto]

I had initially raised this as a bug, however as it was denied bug status it is now a suggestion.

Currently the train pathfinder approximately follows these priorities:

1. Unoccupied by a train.
2. Shortest path in rail pieces/distance.
3. Complicated rules with signals/blocks to decide between equal length paths.

It does not consider the colour of a signal when deciding on a path, resulting in some strange path choices as the train will not take alternate routes that bring it closer to it's destination. If red signals were weighted like a train occupying a block, these scenarios would all be corrected.

Train will not move, will not proceed to open green signal:


Train will choose path that is stopped early, will never path around red signals to get closer to destination:


Train will not enter bypass:

[bobingabout]

You actually aren't considering all the rules here.

Also, I see you using chain signals, chain signals do not follow the same rules as normal signals.


Path finding works on a score, each piece of track has a score. Red signals (but apparently not chain signals) Increase the score, as do blocked rails. Stopped trains that are "Running", be it at a red light, or a station have a score based on how much time they'll likely be stopped, Stopped trains that aren't running at all have an insanely high score.
Paths are then chosen based on this score, and it takes the path with the lowest score (and if there are no trains blocking the path, the shorted path).

In all your examples, it doesn't matter which path a train would travel, it is met with a red light, therefore it doesn't matter what path it takes, it will get stopped at a red light. You're also using chain signals which breaks the conventional rules.

Chain signals basically push the final output of the normal signal of the path it wants to go to the first chain signal in the chain, if that one exit is blocked, it will be a full red path.

Chain signals should ONLY be used where there are multiple exits, a train will stop at a chain signal if it's exit is blocked, or continue past it if it is open. Multiple possible paths for the train are taken into account.

So the issue here is basically... that your signals are placed incorrectly. it should go... open a junction with a chain signal... then either go directly to a normal signal, or go to another chain signal, with the exits of the fork being a normal signal(before the remerge). Chain signals are also only Block based signals like the normal signals, not path based signals, so an entire rail block must be available for the light to be green, not only the actual line you want to use.

so...
in your first example, it's a chain signal issue as stated previously, the final output is red, but the chain signals relay that red to the first signal, even though there is another green normal inbetween on the fork path, what you really want Is for that middle signal on the bottom to be normal signal instead, and the train would pass to the 3rd signal. though to be effective, you need some extra length in that fork.
in your second example, you have an open block, so it doesn't matter that there are signals inbetween, the signal will always be red when a train enters the block, because it's one big block... a signal placement error.
in your final example where we can see the carriage... that Block is occupied, hence the signal leading to it is red.

[Leto]

Thanks for pointing out that trains have different values depending on their running status, I wasn't aware of that. These values however do not have any impact on my examples as the stopped trains are after the branching paths have merged and therefore should be accounted for in both path evaluations.

I'm well aware of how chain and block signals work, in my example I have merges going straight into branches which calls for more chain signals. My examples here are contrived to demonstrate very specific behaviours that you will not often notice in organic play.

In example 1 output is BLUE.
In example 2 it is possible to path around, as this is exactly what happens when you place a carriage between the chain signals.
In example 3 output is again BLUE.

It will be best that you build these yourself and see the behaviour in motion.

[ratchetfreak]

So what you want is for trains to repath and get as close as possible to their destination even if there is a train blocking the last bits.

[bobingabout]

So what you want is for trains to repath and get as close as possible to their destination even if there is a train blocking the last bits.

They do that anyway though, if you use normal signals instead of chain signals.

Though the block nature of signalling, the second example would break regardless.

[Leto]

So what you want is for trains to repath and get as close as possible to their destination even if there is a train blocking the last bits.

They do that anyway though, if you use normal signals instead of chain signals.

Though the block nature of signalling, the second example would break regardless.

Try it yourself, if you put a carriage in between the chain signals, the train will drive around them to the far block signal.

The reason it works for block signals is because block signals only ever show red if a train occupies the block, and trains occupying blocks have a large impact on the pathfinder.