[1.0.0] Possible oversight/bug in train repathing/recalculation triggers due to blue chain signal

[Theikkru]

Recently I participated in a thread in Gameplay Help that was asking about trains that sometimes waited at the entrance to a stacker despite available empty stacker slots (see that thread for details and the game save). Some monitoring with the debug overlay revealed that if two trains chose the same empty stacker slot while pathfinding, it was possible that the second train to arrive would fail to receive any triggers to recalculate its path up until stopping and waiting at the chain-signaled entrance to the stacker for up to 30 seconds.
The reason I bring this up as a possible oversight is that the wiki lists a repath trigger that appears to try to address these types of situations by causing a train to recalculate upon encountering a block it cannot reserve:

The train is braking for a signal (chain or regular) it cant reserve and the train is not inside a chain signal block. The train is forced to recalculate its path.

However, this trigger seems to fail to account for the blue chain signal state, since it is possible that a train will try to stop at a chain signal that it CAN reserve, but won't, because the next non-chain block along its path cannot be reserved. Shouldn't a train be forced to recalculate its path in such a case as well?

[Tekillaa]

Hi,

I got the exact same issue, some people told me it was maybe necessary to make a bug report :

stacker issue.png (2.12 MiB) Viewed 6191 times

so here is the picture

[frayien]

By the way did you reproduce it in singleplayer or is the problem only happening in multiplayer ?

[Rseding91]

Trains do repath in that situation; if the destination exists on multiple stops. If the destination is one stop and there's only one stop in the whole game with that name it will keep its path.

[Theikkru]

By the way did you reproduce it in singleplayer or is the problem only happening in multiplayer ?

Yes, reproduced in singleplayer.

Trains do repath in that situation; if the destination exists on multiple stops. If the destination is one stop and there's only one stop in the whole game with that name it will keep its path.

In which situation? The thread I referenced is a multi-slot stacker before a single destination station, and the repath trigger I brought up is dealing with signals, not stops. The only repath trigger I found that distinguishes between unique and duplicate stops is this one:

The train has waited at a chain signal for a multiple of 5 seconds.
If the trains has waited for a multiple of 30 seconds or if multiple train stops with the name of the destination exist, the train is forced to recalculate its path.

All it does is make the wait shorter if there are duplicate stops. It doesn't address the blue chain signal issue directly.

Let me rephrase as a question: the trigger in the first post dictates that a train that is approaching a red signal should recalculate its path to look for alternate, "faster" routes to its destination in order to avoid stopping at that signal. Why is this logic not extended to avoid stopping at a blue chain signal?
Currently, the counterintuitive and janky workaround to this is to remove the offending chain signal (i.e. break signaling conventions) so that the train hopefully encounters the red rail signal further down the line with its braking point, and recalculates to an alternate path before the train itself passes the fork to that alternate path.

[boskid]

First of all, blue chain signal has nothing do to with trains movement, it is purely for visualisation purpose. Only part the trains are interested in are the signals in front of its path and if its able to reserve blocks that are guarded by them. When a braking point approaches a rail signal it wants to reserve next block. When a braking point approaches chain signal it wants to reserve all blocks up to the block after regular chain signal or at the end of the current path.

I looked at the related topic and the reason why the train does not repath on that signal is because train is in the chain signal section:

89587-in-chain-section.png (888.52 KiB) Viewed 5986 times

When the braking point (1) approaches signal (2) that cannot be reserved (using current path), train should repath. However the train is still in chain signal section (signals 4 and 5) as it did not yet pass the regular signal (3).

The no repath in the middle of chain signal section rule was added in version 0.15.27 by the fix

Code: Select all

Fixed that trains could stop in the middle of chain signal blocks in some specific setups causing deadlocks.

because it was possible that when train would repath while having all signals in chain section reserved, when a new path would be choosen moving the path through chain section in a way that the train would not be able to reserve all the signals, train would stop in the middle of the chain section (like crosssection) violating the guarantees given by the chain signals.

However in the 0.17.50 there was the fix

Code: Select all

Fixed train another train pathfinding issue related to repathing while in chain signal sequence.

which changed trains pathfinder in a way it is aware of a chain signal section: it will never choose a path starting inside of chain signals section that cannot be immediately reserved: path through chain signal section will either go through chain section as previous path (since the signals can be reserved immediately) or it will choose another path that also can be immediately reserved.

Behavior as in 1.0.0:

89593-before-fix.gif (1.01 MiB) Viewed 5986 times

Behavior without the in-chain-section rule:

89593-after-fix.gif (1.24 MiB) Viewed 5986 times

Issue is now fixed for 1.1.0. It will not change the behavior when a braking point approaches red chain signal that later changes into blue: in that case train will recalculare path when approaching red chain signal but if the paths are still equal (train loading into stacker is entirely between red chain signal and regular signal on the stacker lane entrance) it may still happen the path choosen will be the same as for the train loading into the stacker and incoming train will have to wait for the periodic repath when the train loading is already inside of a stacker lane.

[Theikkru]

First of all, blue chain signal has nothing do to with trains movement, it is purely for visualisation purpose. Only part the trains are interested in are the signals in front of its path and if its able to reserve blocks that are guarded by them. When a braking point approaches a rail signal it wants to reserve next block. When a braking point approaches chain signal it wants to reserve all blocks up to the block after regular chain signal or at the end of the current path.

So as far as the repath triggers are concerned, a train encountering (with its braking point) a sequence of chain blocks ending in an unreservable rail block along its path already considers that "can't be reserved", even if the chain blocks are technically reservable because alternate paths to open rail blocks exist (blue signal)?

[...]
The no repath in the middle of chain signal section rule was added in version 0.15.27 by the fix

Code: Select all

Fixed that trains could stop in the middle of chain signal blocks in some specific setups causing deadlocks.

[...]
However in the 0.17.50 there was the fix

Code: Select all

Fixed train another train pathfinding issue related to repathing while in chain signal sequence.

So the issue was actually caused by an old pathing exclusion that was a fix mooted by the more recent changes to repathing behavior while in chain sequences?

Issue is now fixed for 1.1.0. It will not change the behavior when a braking point approaches red chain signal that later changes into blue: in that case train will recalculare path when approaching red chain signal but if the paths are still equal[...]

Shouldn't the signal turning blue set off the following trigger?

The train is preparing to stop at a signal (chain or regular) that changes so that the train can now continue. The train is forced to recalculate its path.

I realize that, based on what you described above, that's probably not how the conditions are coded, but it seems like that would be consistent with the intent of the trigger.

[boskid]

So as far as the repath triggers are concerned, a train encountering (with its braking point) a sequence of chain blocks ending in an unreservable rail block along its path already considers that "can't be reserved", even if the chain blocks are technically reservable because alternate paths to open rail blocks exist (blue signal)?

Yes. Train decides if it can reserve a signal based on the current path it is following. It never looks anywhere else. Because of that, the repath event is needed because the pathfinder is able to look at other possible paths and change the current one.

So the issue was actually caused by an old pathing exclusion that was a fix mooted by the more recent changes to repathing behavior while in chain sequences?

Yes.

Shouldn't the signal turning blue set off the following trigger?

There may be some issues with that when a signal changes from red to blue and there is still no empty lane inside of a stacker (for example due to early bypass exit that misses the target train stop). There would also be a question how to deal with a signal that changes from "blue" to "blue" due to early bypass exit being available but useless and one stacker line becoming empty because the train left the stacker. Not likely to be implemented. I will think about this.

The train is preparing to stop at a signal (chain or regular) that changes so that the train can now continue. The train is forced to recalculate its path.

I realize that, based on what you described above, that's probably not how the conditions are coded, but it seems like that would be consistent with the intent of the trigger.

"train can now continue" applies to its current path. It does not apply to a general state of being possible to find another path that would move the train forward.

[Theikkru]

[...]
There may be some issues with that when a signal changes from red to blue and there is still no empty lane inside of a stacker (for example due to early bypass exit that misses the target train stop). There would also be a question how to deal with a signal that changes from "blue" to "blue" due to early bypass exit being available but useless and one stacker line becoming empty because the train left the stacker. Not likely to be implemented. I will think about this.
[...]

Shouldn't the pathfinding algorithm be able to handle the red-to-blue case normally? (In other words, it'll path-search through the bypass, but should discard that path branch once it sees that it's looped back upon itself without reaching the destination.)
I can see the blue-to-blue case going two ways: either leave it for the interval trigger to catch, since a bypass before a stacker (is weird and) likely implies duplicate destination stops, or generalize the recalculate trigger to apply whenever any of the rail blocks immediately downstream of the chain sequence opens up (may be too expensive computationally).

[boskid]

The issue of the red-to-blue transition is that at the moment there is no ready trigger to catch that transition. Blue chain signal internally is considered OPEN (you may see this by using `show-debug-info-in-tooltips`) as it directly does not contain any trains in the guarded block. Blue color is only for the purpose of visualisation. It is possible to implement the trigger which would check state of all chain signals (including the chain state like blue) in front to make a vector and if any chain signal would change its state to recalculate path. It would not solve the cases where all paths are the same so signals along the path are not changing but train on another stacker lane leaves (unrelated chain signal changing but none of signals the train is checking). And it would cause a lot of unnecesary repaths in case signals would be changing due to other trains movement.

Case where signal changes and repath based on chain state would be completly useless.

89587-signal-disco.gif (578.2 KiB) Viewed 5869 times

The case still failing that i described as still running into the periodic repath is this:

89587-case-still-failing.gif (955.32 KiB) Viewed 5869 times

Here the train when arrives to chain signal it repaths but since right train is entirely in a block that belongs to both possible paths, penalty of train in block is the same for both paths and it cancells making the distance penalty primary reason to choose the same path to left train stop.

Possible solution using in game mechanics is to place rail signal before chain signal and close it when chain signal gives red: that way when a chain signal turns blue, rail signal currently reserved for circuit network opens, train repaths and right train is already entirely inside the stacker lane so the penalty to another stacker lane will be lower and it will be choosen.

89587-closing-signal-when-red.gif (947.83 KiB) Viewed 5869 times

[Theikkru]

[...]Blue color is only for the purpose of visualisation. It is possible to implement the trigger which would check state of all chain signals (including the chain state like blue) in front to make a vector and if any chain signal would change its state to recalculate path. It would not solve the cases where all paths are the same so signals along the path are not changing but train on another stacker lane leaves (unrelated chain signal changing but none of signals the train is checking). And it would cause a lot of unnecesary repaths in case signals would be changing due to other trains movement.
[...]

What about using the chain signal visualization logic to find the rail signals/blocks that are downstream of the chain signal? In other words, instead of capturing the chain signals themselves in a vector and reading them directly, query the chain signals to find the downstream rail signals they're using to determine their blue state, and put those rail signals in the vector instead. That would get around your "signal disco" example, because the signals on an intersecting (but not reachable) rail would not be downstream of the chain signal, and therefore would not end up in the vector. This would also be a (relatively) fast way for the train to find the rail signals that are relevant to the repathing decision but not on the current path (such as the other lanes in a stacker).

[...]
Possible solution using in game mechanics is to place rail signal before chain signal and close it when chain signal gives red: that way when a chain signal turns blue, rail signal currently reserved for circuit network opens, train repaths and right train is already entirely inside the stacker lane so the penalty to another stacker lane will be lower and it will be choosen.
89587-closing-signal-when-red.gif

There are two reasons this doesn't feel like a good solution to me.
First, the rail signal there seems really clunky and redundant, in that its only purpose is to supplement repathing behavior that feels like it should also work with chain signals.
Second, is that because the rail signal is in front of the chain signal, there can be edge cases where the braking point of a train gets "cut off" by both signals turning red, and the train can end up waiting at the chain signal anyways.