[0.17.38] Train repathing within chain signals not fixed as described

[Theikkru]

See 68681

Either I'm misunderstanding something, or the fix in the 0.17.38 patch notes is not working as described:

Changes

• When a train performs path finding while in a chain signal sequence, the pathfinding will have a constraint to not go through reserved block before exiting the chain sequence. This solves a problem of train intersections being possible to be deadlocked even with proper chain signals usage in cases of using temporary stops or when path is changed because of station is being enabled/disabled by a circuit network. (68681) This also allowed us to to let train recalculate path spontaneously even in chain signal sequence, as it shouldn't break anything now.

[...]

I threw together a test rig with a roundabout and 3 exits, and told my test locomotive to go to one station (south), then switched to another (north-east) as soon as it entered the roundabout. I expected it to head down the southbound exit, because I thought that the new rule would prevent it from picking the southern leg of the roundabout for its path (since that path consists of only chain signals followed by a reserved block), but it did pick the southern leg, and planted itself in the roundabout.

block.png (3.22 MiB) Viewed 3944 times

The southern station loops and comes back north, so the expected behavior would have been to exit south (following the old reserved path), loop through the southern station, and wait at the southern entry to the roundabout.
My test save is attached.

P.S. I'm really rooting for this fix because it seems like it would solve all the unexpected failure modes of a properly signaled roundabout (including trains crashing into themselves).

[robot256]

When you say you switched to the Northeast station while in the loop, did you do that by disabling the South station of the same name via circuit network, or manually by clicking in the train schedule GUI? If it treats manual commands different from ordinary repathing, the fix might not activate in the latter case.

[Theikkru]

I did it by clicking the arrow in the train schedule manually, but the fix says it's a general rule about repathing while within a chain segment, so the cause of the repath shouldn't make a difference. (Also the wiki doesn't indicate any distinction.) The two stations I used are the ones in the screenshot. They have different names.

[robot256]

But clicking in the GUI sets a new destination with a new path, and I wouldn't expect it to behave the same as repathing to the same destination. The new path can even cause the train to reverse direction, so it's pretty clear that it erases all the data from the previous route when starting the new one. That would include the fact that to get where it is now, it crossed a chain signal with the intention of exiting a certain way.

[Theikkru]

The same applies if the destination station gets disabled by a circuit, if the destination station becomes inaccessible, or if rail along the planned path gets destroyed/removed. As far as I can tell, there are only 2 different behaviors of trains regarding pathfinding: (in the wiki's terms,) revalidation, where something causes a train to re-check its current planned path to verify that it's still valid, and recalculation, where the train repaths its route from scratch (destination included). Presumably, the "chain signal" flag the devs have mentioned doesn't get cleared when a train repaths, or it wouldn't be very useful.

[kovarex]

The fix and the related logic has nothing to do with preventing train self-collisions on roundabounds.
The fix is related to not allowing train to get stuck in chain signal section, but it can still pick a different exit then previously selected (on purpose).

Having extra logic to prevent self-crashes in situations like this was considered, but discarded, as it would create different kind of problems. The solution is to do one of these things:

• Don't use roundabounds that are too small for the trains.
• Don't change destinations by circuit network or manually

[Theikkru]

The fix and the related logic has nothing to do with preventing train self-collisions on roundabounds.
The fix is related to not allowing train to get stuck in chain signal section, but it can still pick a different exit then previously selected (on purpose).

The logic itself doesn't have anything to do with train self-collisions, but if I properly signal a roundabout, wouldn't this prevent self-crashes incidentally since the train would always encounter a red chain signal if it tried to path through its own tail? In the example roundabout above, for instance, if a train comes in the southern entry and wanted to crash into itself, it would have to repath through the southern leg of the roundabout (where the example locomotive is in the screenshot), but there is a chain signal there that would be red because of its own tail if it tried that. By the new rule, that should count as a reserved block before exiting the chain sequence, right?

On another note, why is this now in "Not a bug"? I thought I showed a case of trains stuck in the chain signal section:

diagram

validity.png (3.07 MiB) Viewed 3797 times

[kovarex]

Red signal is generally ignored when the train reserved for the block is the same as the one trying to go through. The rule is there since forever and it can't be easily removed.

[Theikkru]

OK that makes sense....but what about the original example I gave? That is just about trains stopping in the roundabout because they didn't seem to follow the new rule (nothing to do with self collision).

[robot256]

I agree from what you describe, it should at lest take the upper left exit. Unless something else in those tracks is preventing it from using them.

Maybe try adding chain signals just before each exit off the roundabout? I know sometimes it only recalculates routes as it passes chain signals, and where it is in your picture, there is not another signal before the South split. Doesn't make sense why this would affect it in this case, but it's something to try.

[Theikkru]

The problem isn't that it's not recalculating enough, the problem is that it arrives at the wrong answer when it does recalculate; it doesn't matter how many times I make it redo the math if it's just going to make the same mistake.

At any rate, passing signals does not cause recalculation. Other conditions must be present for that to happen. Incidentally I used to make signals as you describe (since it was easier to remember the rules), but behavior was the same.

You can tell from the green block signals at the southern and northwestern exits that there are no trains blocking them.

[Theikkru]

Can anyone tell me why this topic is in "Not a bug"?

To be clear, the behavior I'm reporting in my example case in the first post is that trains within a chain sequence repath to a path that goes through a reserved block before it goes through any non-chain, non-reserved blocks, seemingly in direct contradiction to the new rule in the patch notes.

I'm not necessarily expecting the train to take the old path out of the chain sequence, and while the correction is appreciated, my erroneous assumption about self-collision doesn't influence the problem I'm trying to report.