[0.18.4] Chain signal oddity

[planetmaker]

Consider the setup in the screenshot. The train (#203) is waiting on the blue chain signal. After some waiting the signal turns yellow, and the train passes it and it waits behind the next chain signal of the same chain.

The train has orders to visit the station between the two chain signals. If I remove the order of the train to visit the station between chain signals, it will keep waiting in front of the blue chain signal.

I expect the train to not enter a block guarded by chain signals - even when a destination station is guarded by that.

Make the train go-around and re-produce the initial situation by removing the red signal from the constant combinator next to the normal rail signal and re-adding it (not shown in screenshot, as it's slightly further South)

Savegame: https://cloud.planetmaker.de/index.php/ ... SZq6xZnAnB

[boskid]

Won't fix because i do not see what that behavior could break.

This behavior is a consequence of the internals of waypoint logic. Train is allowed to pass rail chain signal if it can reserve all rail blocks up to a train stop, in this case - up to a blue train stop waypoint. Reservation happens due to train's braking point in front so when train is on right-top corner, it already reserves rail chain signal before blue train stop, braking point approaches blue train stop and that train stop is internally considered as "reached" and train's path is now extended up to yellow train stop - this allows train to keep moving (not being forced to stop at blue train stop). However this also makes rail chain signal before blue train stop to force train to stop here since train cannot reserve all rail blocks because of closed rail signal (close signal from constant combinator) and so train stops. After small amount of time, train is forced to repath, this clears whole path up to yellow train stop (since it was ahead of "official" schedule goal), train is again going for a blue train stop, it passes rail chain signal, blue train stop is considered passed but train is already ahead of mentioned rail chain signal - this is why it will stop at next rail chain signal.

I could fix this by keeping track of which rail chain signals were considered as final before waypoint and ignore rail chain signal rules on them after path extension, but this would complicate rail signals logic and i do not want to do that.

81098-rail-chain-with-waypoint.gif (1.57 MiB) Viewed 2297 times

[planetmaker]

Won't fix because i do not see what that behavior could break.

This behavior is a consequence of the internals of waypoint logic. Train is allowed to pass rail chain signal if it can reserve all rail blocks up to a train stop, in this case - up to a blue train stop waypoint. Reservation happens due to train's braking point in front so when train is on right-top corner, it already reserves rail chain signal before blue train stop, braking point approaches blue train stop and that train stop is internally considered as "reached" and train's path is now extended up to yellow train stop - this allows train to keep moving (not being forced to stop at blue train stop). However this also makes rail chain signal before blue train stop to force train to stop here since train cannot reserve all rail blocks because of closed rail signal (close signal from constant combinator) and so train stops. After small amount of time, train is forced to repath, this clears whole path up to yellow train stop (since it was ahead of "official" schedule goal), train is again going for a blue train stop, it passes rail chain signal, blue train stop is considered passed but train is already ahead of mentioned rail chain signal - this is why it will stop at next rail chain signal.

I could fix this by keeping track of which rail chain signals were considered as final before waypoint and ignore rail chain signal rules on them after path extension, but this would complicate rail signals logic and i do not want to do that.

81098-rail-chain-with-waypoint.gif

I cannot but disagree: It breaks the fundamental behaviour and intention of chain signals: a train does not enter a block guarded by chain signals when the final normal signal is not green. As a result in this example, the train ends up in the middle of the junction blocking it. Thus this behaviour is in contrast to the default use-case of chain signals: disallowing entry into areas when there is no free exit it can go to.

[boskid]

I cannot but disagree: It breaks the fundamental behaviour and intention of chain signals: a train does not enter a block guarded by chain signals when the final normal signal is not green. As a result in this example, the train ends up in the middle of the junction blocking it. Thus this behaviour is in contrast to the default use-case of chain signals: disallowing entry into areas when there is no free exit it can go to.

If you have 2 rail chain signals that are red because of single train after far signal, by placing train stop between of them, rail chain signal before train stop will turn blue since now there exists some goal that can be reached that requires reservation of rail chain signals only up to given train stop. In that sense last rail chain signal works kind of as "rail signal" when next is goal train stop, however by extending path (because of waypoint reached by braking point), it works again as rail chain signal. Train is not interested by possible exit paths in the same travel direction because if train would be double sided, it could exit by rails it came from.

[planetmaker]

Thanks, I see where that comes from. Yet basically you are saying that the station has an implicit signal in-built. A signal which does exist under some circumstances, but not under others. And it never has any visual feed-back to the players.

Also, the train does never change the actual path it takes, the situation on the call to re-pathing does not change. However calling re-pathing on the train seemingly changes what is allowed - even when nothing else in the overall setup changes, including destination, free tiles, location of other trains etc. It is definitely not anything intuitive, as it is a signal which first is being taken into account, and then ignored. Your animation also clearly shows, that the signal of the crossing rail already turns red when the train enters the blue station. So a station has a normal rail signal for purpose of path finding when re-pathing to it, and has none as soon as a train enters.

A solution is to always require reservation of the full path to the next full signal when entering a block (if there is any such signal in the future path) - irrespective of whether anything within that block is the current destination. What would be broken by this - more intuitive - approach (as it means that signals have a meaning more often).

Adding signals explicitly to stations has its own set of problems, a can of worms one possibly would not want to open (are they one-way, are they two-way, and why do they add a signal in the opposing direction? Just to name a few)

[boskid]

Thanks, I see where that comes from. Yet basically you are saying that the station has an implicit signal in-built. A signal which does exist under some circumstances, but not under others. And it never has any visual feed-back to the players.

Well, it comes from a way waypoints are implemented: they work like a train stop but train is not required to stop. They are not a "waypoint" as to choose which overall paths are allowed between current position and next full train station schedule (not a waypoint). Waypoint works as a train stop when braking point did not yet reached it (this allowed train to pass rail chain signal) and works as no entity(kind of) when path is extended because braking point reached waypoint train stop (75143).

Also, the train does never change the actual path it takes, the situation on the call to re-pathing does not change. However calling re-pathing on the train seemingly changes what is allowed - even when nothing else in the overall setup changes, including destination, free tiles, location of other trains etc. It is definitely not anything intuitive, as it is a signal which first is being taken into account, and then ignored. Your animation also clearly shows, that the signal of the crossing rail already turns red when the train enters the blue station. So a station has a normal rail signal for purpose of path finding when re-pathing to it, and has none as soon as a train enters.

Doing repath will set "current goal" (which may be couple of schedule records ahead) to the "official goal" (that is shown in locomotive's schedule) and this is why that waypoint train stop changes train's behavior.

A solution is to always require reservation of the full path to the next full signal when entering a block (if there is any such signal in the future path) - irrespective of whether anything within that block is the current destination. What would be broken by this - more intuitive - approach (as it means that signals have a meaning more often).

When going for a train stop, this reservation is not required since train (being double sided) could exit in opposite direction, and this would also complicate a lot of logic because now it would be required to reserve whole path up to a train stop, compute at which point opposite train end would be and check if there is possible exit path in opposite direction counting from that position. If it would fail, and another path to train stop would be possible, it would also have to be checked (otherwise it would create issue: train choosed shortest path to waypoint and cannot enter, "i see" path longer by 1 rail that would allow train to exit, "pathfinder is broken"). Too much performance impact, not worth it.

Only part that could be fixed is this difference in train's behavior that makes it instantly stop at rail chain signal when waypoint is passed by a braking point - after fix it would just pass given rail chain signals as it would be going for a train stop and would stop only at rail chain signal after blue waypoint train stop. And this part i am not going to fix.

[boskid]

Tiny update about this behavior: in 1.1.0 the train will not halt at the chain signal before the waypoint when the path is extended. Instead in the case where after the waypoint there is chain signal that cannot be reserved and the train would be in chain signal section when approaching the waypoint, the train will approach the waypoint itself and it will stop before proceeding with going further. However it will still not be as the behavior from the first post as the train will enter the chain signal section to reach the waypoint anyway.