Need help with trains deadlocking

[BlakeMW]

I'm not decided on whether this (long trains crashing into themselves, and self-deadlocking) is something that should be fixed in the game, or a "puzzle" to be solved by the player using the "puzzle pieces" made available. Because the idea is that each part has simple logic and these individual parts with simple logic can be put together to make complex systems. There is a good argument against giving parts more sophisticated logic - and that argument is that Factorio is partly logistics simulator and partly puzzle game; also keeping the logic simple means better performance and fewer code bugs. There is currently a solution to self-deadlocking, which is not using loops and especially not using round-a-bouts with a loop of chain signals.

[mrvn]

I'm not decided on whether this (long trains crashing into themselves, and self-deadlocking) is something that should be fixed in the game, or a "puzzle" to be solved by the player using the "puzzle pieces" made available. Because the idea is that each part has simple logic and these individual parts with simple logic can be put together to make complex systems. There is a good argument against giving parts more sophisticated logic - and that argument is that Factorio is partly logistics simulator and partly puzzle game; also keeping the logic simple means better performance and fewer code bugs. There is currently a solution to self-deadlocking, which is not using loops and especially not using round-a-bouts with a loop of chain signals.

Problem is that the game gives you puzzle pieces to solve this issue: signals. The problem is that those pieces don't work right. A signal is mend to prevent a train entering a block that is occupied. Imho that should include a block occupied by itself. The issue that started this was that the behaviour is inconsistent: A loop works if the train drives through it but breaks if it repaths while in the loop.

Your solution is basically not to play the game. Where is the fun in that?

[BlakeMW]

I actually posted that before reading the dev declaration that repathing after reserving chain signals is a bug (it's hard to know these things in advance, after all logically there's no reason why a train reserving signals should mandate it follows that path - the bugfix is introducing a new behaviour, that a train which reserves chain signals must follow that reserved path). I didn't bother going back and editing it because what it's still valid for trains long enough to crash into themselves, the pathfinder could try and avoid paths which would avoid a train crashing into itself, but should it?

[mrvn]

I actually posted that before reading the dev declaration that repathing after reserving chain signals is a bug (it's hard to know these things in advance, after all logically there's no reason why a train reserving signals should mandate it follows that path - the bugfix is introducing a new behaviour, that a train which reserves chain signals must follow that reserved path). I didn't bother going back and editing it because what it's still valid for trains long enough to crash into themselves, the pathfinder could try and avoid paths which would avoid a train crashing into itself, but should it?

The problem is not that the repath changes the path but that the repath does not succeed in reserving the same path again. With the train inside the loop one of the block is red and the path the train was on and that the repath finds crosses that red block. But chain signals prevent reserving a block unless the next block can be reserved too. So the repath train now stops at a chain signal where before it had it already reserved.

A bugfix could be that a repath train choosing the same path as before will preserve the reservation it had. This would prevent the deadlock while doing nothing for the crashes.

Personally I consider this 2 separate issues: 1) the deadlock on repath, 2) the crashing on long trains