[0.14.5] Train is stuck and won't repath (save)

[FeepingCreature]

I have a mixed smelting area with multiple stations (copper load/metal load/ore unload), and a combined waiting area before it, of the sort

Code: Select all

>---[chain]--\----[signal]--[queue 1]--[chain]----/----\----[signal]-[copper load]->
              \---[signal]--[queue 2]--[chain]---/      \---[signal]-[iron load]--->
               \--[signal]--[queue 3]--[chain]--/        \--[signal]-[ore unload]-->
                \-[signal]--[queue 4]--[chain]-/
                 \[signal]--[queue 5]--[chain]/

There's a train that I've switched to manual standing on [queue 1], blocking it.

A train trying to enter the waiting area has pathed through [queue 1] attempting to get to [ore unload]. All station signals are green.

The train is waiting for the manual train to move, so it can move into [queue 1], despite the fact that all other queue slots are free.

I've waited for about five minutes and it's obstinately refusing to repath to get around the obstacle.

The issue persists on reloading the save.

Save: http://feephome.no-ip.org/~feep/train_repathing_bug.zip (47MB).

Screenshot:

[Rockstar04]

This is because the open paths are longer than the one its waiting for. The only way I have found to reliable make waiting bays like this work is to have the entrance and exit in the same direction so the path through all bays is the same length.

Code: Select all

-> ENTER from main tracks -> _______________ 
                                \ \ \ \ \ \ \
                                 \ \ \ \ \ \ \   waiting bays
                                  \ \ \ \ \ \ \
                                   \ \ \ \ \ \ \
                                    ‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾ -> EXIT to unloading bays ->

[Deadly-Bagel]

There are also currently problems with chain signals not seeing open bays, it doesn't recalculate while waiting. See this topic for a solution.

[Loewchen]

I assume the train is not really stuck but just behaves "stupid" and insists on the shortest path, that in itself is not necessary a bug. The PF is weighing path length and occupied blocks, if you give different lengths for your holding tracks then this is a possible outcome, use a design like Rockstar04`s to prevent that issue.
The issue that the PF does not recalculate a chosen path if nothing has changed along it is already documented here: viewtopic.php?f=173&t=21603.
Edit: It's a different one see my next post.

[FeepingCreature]

I think the correct behavior is to recalculate train paths when 1) your preferred way is blocked, and 2) any of the exit signals of the next block of the preferred route, not just the signals on the preferred route itself, change state. That way it should notice that the adjacent queue spots had become free.

That won't necessarily lead to a completely free route, but it should at least allow the train to make progress.

[FeepingCreature]

I see this has been sorted into "Duplicates"; maybe it should be added to the "Known Issues" list?

[Loewchen]

It is actually this one: viewtopic.php?f=41&t=14748