[15.37] Train changes path after chainsignal (again)

[Rseding91]

In the round-about example you gave the train is currently inside a chain signal block and is not allowed to re-path. That was fixed a while ago so it doesn't happen unless you break its path by removing rails/signals/stops.

Is switching a stop on/off through the circuit network equivalent to removing it in that case? (I'd guess yes, but I'd rather ask).

OG.

Yes. Doing that invalidates the path the train is driving on forcing it to switch. In 0.16 the train will continue from the example you've given because it won't see itself as blocking itself.

[aaargha]

As far as I can see this has two parts: A) Which area is recognised as critial?

path_lock_suggestion.png (135.4 KiB) Viewed 1852 times

And B) How do we handle soft reapathing in the critical area?

I don't mind a train repathing, However it must not pick a path where it ends up stopped after a chain signal and before a regular signal. That means if it chooses to repath between a chain signal and a before it passes the regular signal, it needs to choose a path where it can reserve a route past a regular signal. (Unless someone has mined a track or disabled a station or something similar, it already has a suitable a path reserved. If it can find a better one fine, but otherwise it shouldn't block the intersection).

To me this would be the ideal solution, though even just locking the path for the suggested area would probably be preferable to the current implementation.

Also "the chain signal existing doesn't alter the train logic once the train has passed the signal" doesn't make sense to me. By that logic a train could pass any chain signal, then decide to repath, and choose a path which has a chain signal leading to a blocked exit, and stop at that chain signal. Somewhere the logic needs to know that the train has passed a chain signal, and is now in a set of blocks protected by chain signals, otherwise it could decide to change it's path, pick a different path where it can't reserve the next signal, and block any intersection.

Consider the train below. It entered the roundabout from the east, intending to exit to the west. Just before the exit to the west it decides to repath and exit to the north. Where is it going to stop? Will it be blocking trains wanting to enter from the south and west? Trains that might otherwise have had a clear route through the intersection? Will the fact that I added extra chain signals just before the regular signals at the exit actually help?

Welcome to the world of pre 0.15.27 intersection design, how to design safe intersections with those rules is something we've explored pretty in-depth. While the changes in 0.15.27 made most of the intersections safe, for soft path changes at least, there are still some designs that can deadlock as demonstrated in the bug report I linked earlier.

Yes. Doing that invalidates the path the train is driving on forcing it to switch. In 0.16 the train will continue from the example you've given because it won't see itself as blocking itself.

That does seem like a sensible decision, I look forward to seeing how the train re-works pan out.

Keep up the good work!

[KAA]

Thank, Rseding91, I've got your point.

Looks like a lot of adjustments need to be done around my whole railway now.
Can I ask some additional questions then:
1) Train cannot re-path after they entered rail chain block, right?
2) Train will not re-path while passing several rail chain blocks one by one (no rail signals between), right?
3) When leaving rail chain block, train will TRY to re-path and MIGHT do it in case it finds more suitable route, right?

And just to be clear, can you please mention in that particular cases train turns on searching of a path? I remember I saw it once in some guide, but it was long time ago.

[mrvn]

this problem has been around for a long time. trains calculate when leaving a station.
so if a train plans on using a slot, then another train enters said slot you get this problem.

try adding this before the stacker.

That is not the problem. If two trains go to the same station the second one waits before the chain signal. Still bad but it will eventually repath to a new station.

[mrvn]

That's pretty unintuitive. My understanding was that the train would not pass a chain signal until it had reserved its whole route to pass the regular signal at the end of the block, and that if it decided to repath whilst inside the block, it would choose a path where it could instantly reserve its route past the regular signal that marks the end of the chain signals. (Obviously if you disable a station/mine rail line, it might be unable to find such a path).

What you are saying is that the train can choose to repath between the last chain signal and the regular signal that denotes the end of the set of blocks that the chain signals were employed to protect, and that when doing so, it can choose a route where it can't exit past the regular signal and exit the set of blocks that the chain signals were employed to protect. To me that sounds like an unintended feature of the current implementation, rather than a good design choice. It will force people to add lots of chain signals just before regular signals in places where they would otherwise be unnecessary, just to make sure that the train can't change it's path at the last moment and block an intersection.

Indeed unintuitive.

But think about it. When the train has passed the chain signal is no longer reserves the block, it occupies the block. And what exit it takes from the block does not change the block. All possible paths have the block the train is currently in occupied. The "fix" only considers reserved blocks with chain signals, not occupied ones.

[mrvn]

In the round-about example you gave the train is currently inside a chain signal block and is not allowed to re-path. That was fixed a while ago so it doesn't happen unless you break its path by removing rails/signals/stops.

Is switching a stop on/off through the circuit network equivalent to removing it in that case? (I'd guess yes, but I'd rather ask).

OG.

Yes. Doing that invalidates the path the train is driving on forcing it to switch. In 0.16 the train will continue from the example you've given because it won't see itself as blocking itself.

Doesn't that make the fix mostly useless? I rarely build new rails but my stations get enabled/disabled frequently and caused my roundabouts do deadlock on a regular basis.

Shouldn't the train only be allowed to repath inside a chain signal block when the new path sucessfully passes a regular signal or the old path up to the next regular signal becomes invalid? I.e. only take the new path when it can pass the next signal. Otherwise set the path to be the old path to the next regular signal. Hard repath if that is impossible. Anything that happens beyond the next regular signal should not cause a hard repath, only a soft repath.