[0.14.20] Duplicate Train Stations Don't Work Anymore

[fandingo]

I've used this station complex design for a long time, but noticed that it's causing deadlocks now. It seems like Factorio isn't properly determining when a path is available to a station with the same name if its original destination is occupied.



The two stations with requester chests are of interest. Ignore the other three. I have two stations with identical names "iron output." In the past, when the train in the top right reached the blue chain signal, Factorio would see that it has a route to the right "iron output" station, and correctly proceed to that station since there's a green signal after the blue chain signal. Unfortunately, in present versions, the train is stuck trying to go to the left "iron output" station, causing a deadlock.

I think the major issue is that I have N stations with the same name, but N+1 trains assigned to use those stations. Both stations were occupied when the top right train departed, and the game just chose one of the stations. It proceeds as far as it can, but doesn't realize that the other station became available during its route. In the past, the game seemed to recalculate route when it got stopped at a blue chain signal, but that no longer works. If I toggle the top right train to manual and back to automatic, it recalculates the route and properly proceeds to the available station. That used to work without user intervention.

I attached my save file. I also added my mod-list.json to make it easier to load this save, but none of the mods affect train behavior.

[impetus maximus]

this is a known issue. i believe it's being reworked in 0.15.* a workaround is to put a station before the splits that has a 0 second delay.
it will force the train to re-calculate where to go and which lane is open.

[Loewchen]

There are two issues here, one thing is, that trains don't (reliably) reevaluate a chosen path, so it can happen that the train takes an occupied path/station because it was the fasted/unoccupied when it checked the last time: viewtopic.php?f=41&t=14748.
The other issue is, that your station design does not give any buffer on the entrance, so even with the above mentioned issue fixed would 3 trains with the "iron output" destination be able lock your network down completely.

[fandingo]

There are two issues here, one thing is, that trains don't (reliably) reevaluate a chosen path, so it can happen that the train takes an occupied path/station because it was the fasted/unoccupied when it checked the last time: viewtopic.php?f=41&t=14748.

Cool. Yeah, this is the bug part that I'd like to see fixed.

The other issue is, that your station design does not give any buffer on the entrance, so even with the above mentioned issue fixed would 3 trains with the "iron output" destination be able lock your network down completely.

This gets into the player's design, and since this is the bug forum, I won't belabor the point. However, there's decent workarounds; it's something the player can control. If the bug above is fixed, then it's not really a deadlock. By using complex wait conditions on this destination AND the origin stations, any blockage is fleeting. (Specifically, don't release a train unless "iron output" has enough items to fill the train via the circuit network, and use an OR condition on "iron output" to prevent a train from waiting forever for full cargo.)

[fandingo]

this is a known issue. i believe it's being reworked in 0.15.* a workaround is to put a station before the splits that has a 0 second delay.
it will force the train to re-calculate where to go and which lane is open.

Interesting suggestion! Maybe I'll look into implementing something like this to minimize the issue. However, it should be stated that this design still has issues. On the other hand, I may just write a mod to toggle to manual mode to force recalculating the path...

You can't actually use a 0s wait condition to avoid deadlocks; in fact, that only works in if and only if there is an available train station, but that already works fine. Let's say you have N train stations, but there's already N trains at those stations. The N+1 train arriving/departing the "wait" station would still be routed incorrectly, causing a deadlock. Really you need a buffer, a wait train stop, and then the destination stops (over 3x the length of the station complex in my screenshot). The "wait" train stop needs to be wired to the input rail signals (the row of 5 signals just below the curves in my screenshot) for the destination stops ("iron output" in my example) and only release the train once it reaches GREEN > 0. That would ensure that the routing algorithm will have an available destination when it performs the calculation. Pretty messy and bloated.