[1.1.94] Train pathing anomaly

[2B1]

I searched the bug reports forum for the subject line and found none.

This may not be a bug and could be a signaling issue.
However, I'm fairly comfortable with train signaling after enjoying Factorio for five years now.
I'm also willing to learn in case I've miss signaled here.

System setup details:
Factorio version 1.1.94. Installed from .zip (not on Steam).
Windows 8.1

Mods: (I'm guessing these may not be relevant to the issue)
Krastorio2 version 1.3.23
alien-Biomes version 0.6.8
aai-containers version 0.2.11
FactorySearch version 1.10.8
flib version 0.13.0
FNEI! version 0.4.1
Wind_Generator-gfxrestyle version 1.2.3
My own mod that alters some base recipes.

Recent log file attached for further details.
I can attach a save (11 MB) if that becomes necessary but I'm thinking the visuals tell the story.


Problem setup: (please see attached images)
Two trains used for copper ore share bidirectional tracks between the dropoff and three pickup stations.
These are named Copper Dropoff, Copper Pickup, Copper Pickup 2 and Copper Pickup 3.
Both trains have the same schedule (used [shift right-click, shift left-click] when setting up the second train).
A single train had been used for several days of this playthrough.
The second train was set up to increase throughput. No new pickup stations were added.
When adding Train 2 a section of bypass track was added around the first Copper Pickup station and signaling was adjusted.

Problem:
Train 2 waits in the bypass above the first Copper Pickup station for the Copper Dropoff station to clear.
Once Train 1 empties its contents in the Copper Dropoff station it paths to the Copper Pickup 2 station.
Train 1 chooses to path through the rail segment Train 2 is on causing a deadlock wait condition.
Note that the chosen path has blocked signals and the alternate path has clear signals.
The wait lasts approximately 5 minutes after which the train repaths through the open station bridged by the bypass.
Once Train 1 clears past Train 2, Train 2 proceeds to the Copper Dropoff station as expected.
The issue is repeatable every time the unloading train attempts to proceeds to Copper Pickup station 2 while the other train is waiting in the bypass.

Expected behavior:
Train 1 paths through the open copper station bridged by the bypass without waiting.

Visual of implicated trains:

TrainPathing1a.png (4.46 MiB) Viewed 630 times

Reference to train schedule and station names:

TrainPathing2.png (1.98 MiB) Viewed 630 times

In case there is discussion on particular signals along the path:

SignalNames.png (730.66 KiB) Viewed 630 times

[Rseding91]

Thanks for the report. This is working correctly: trains will try *very* hard to never path through stations they aren't currently trying to stop at. You can see the path-finding penalties here: https://wiki.factorio.com/Railway/Train ... _penalties

[2B1]

Thanks for the amazingly fast reply.

The forums and blogs are another facet of enjoyment with Factorio.

I suspected the issue might have something to do with the path that I expected the train to take was through a train stop.

Given your confirmation I implemented a simple work-around by adding a second bypass.
In the given scenario Train 1 now departs via the second bypass and avoids, to your point, the path containing the train stop.

TrainPathing3a.png (4.53 MiB) Viewed 599 times

Thanks too for the link to the information on train pathing.
The text below in green is from that link.

I've studied it for a bit.
It seems with programming it's always the exception cases that tend to complicate things.

I've highlighted in yellow the items that I think apply to this case.

Path finding penalties

For calculation it uses a simple A*-algorithm[1]: The pathfinder first builds a list of non-disabled stops that match the name in the schedule, then searches outward from both ends of the train at once, if applicable, in segments. A segment is an uninterrupted plain sequence of rails, with no intersections, stops, or signals (all of which define segment borders). The cost (distance) is calculated using the following weighting rules:

Base cost for a block/segment is the length of the segment (linear grid length along the center of the rail).
When the rail block is occupied by a train -> Add a penalty of 2 * length of the block divided by block distance from the start, so the far away occupied paths don't matter much. (for the chosen path, a relative low penalty)
When the rail block is guarded by a rail signal set to red by the circuit network -> Add a penalty of 1000.
When the path includes a train stop -> Add a penalty of 2000. (for the path not taken, a relatively high penalty)
When the rail block contains a train that is stopped at a train stop -> Add a penalty of 500.
When the rail block contains a train that is stopped at a train stop and the train doesn't have other valid stops in its schedule -> Add a penalty of 1000.
When the rail block contains a manually controlled stopped train with a passenger -> Add a penalty of 2000.
When the rail block contains a manually controlled stopped train without a passenger -> Add a penalty of 7000.
When the rail block contains an automatic train without a schedule -> Add a penalty of 7000.
When the rail block contains a train currently arriving to a train stop -> Add a penalty of 100.
When the rail block contains a train currently arriving to a rail signal -> Add a penalty of 100.
When the rail block contains a train currently waiting at a rail signal -> Add a penalty of 100 + 0.1 for every tick the train has already waited.
When the rail block contains a train that doesn't have a path -> Add a penalty of 1000.

Path Revalidation

A rail path will be revalidated if any event happens that could make this trains path invalid. If the path is found to be invalid then the game will repath the train. Path revalidation just confirms that the current path is still valid and does not confirm that it is still the best. The following events cause path revalidation:

A rail is destroyed (all trains are revalidated).
A rail is created and invalidates a signal (all trains are revalidated) .
A signal (chain or regular) is created or destroyed (all trains are revalidated).
A rail block changes and invalidates a signal (chain or regular) (all trains are revalidated).
LuaTrain::recalculate_path() is called on the train by a script.
The train's schedule is changed.
The train's braking force gets changed and the train is currently driving normally, arriving at a signal (chain or regular) or arriving at a station.
The train has waited at a chain signal for a multiple of 5 seconds. (The signal Train 1 waits at is a chain signal.)

Repath events

There are a number of events that can cause a train to repath listed below. When one of these conditions is met the game considers possible paths from the trains current location to its destination train stop and will chose the path with the lowest score according to the penalties listed above.

User / script generated events

A locomotive that is part of the train is rotated.
LuaTrain::recalculate_path(true) is called on the train by a script.
The train is switched to automatic control when it was previously manually controlled.
The train is set to go to a station using the "Go to stop" button in the train's GUI.
A waypoint (train stop without wait condition) is removed from the train's schedule.

Repaths that happen as part of normal train operation

A train fails a revalidation.
The train stop a train is heading to is renamed or destroyed.
The train is preparing to stop at a signal (chain or regular) that changes so that the train can now continue.
The train is braking for a signal (chain or regular) it can't reserve.
The train enters a new rail block and can't reserve the next needed signal (chain or regular).
The train has waited at a chain signal for a multiple of 5 seconds and there are multiple train stops with the same name as the destination.
The train has waited at a chain signal for a multiple of 30 seconds and there is only a single train stop with the same name as the destination. (All the train stop names are unique in this setup.)
The train wants to depart from a signal (chain or regular) that it stopped at.
The train wants to depart from a train stop.
The train is pathing to a train stop that gets disabled.

Question:
From the above I don't see where the 5 minute wait comes from.
Is it possibly keeping a counter for the number times it completes the 30 second timeout without moving and if it reaches a threshold (10 loops) calculates the path penalties differently or chooses the next lower penalty path?

[computeraddict]

Question:
From the above I don't see where the 5 minute wait comes from.
Is it possibly keeping a counter for the number times it completes the 30 second timeout without moving and if it reaches a threshold (10 loops) calculates the path penalties differently or chooses the next lower penalty path?

Iirc it's this term:

When the rail block contains a train currently waiting at a rail signal -> Add a penalty of 100 + 0.1 for every tick the train has already waited.

.1 penalty per tick for ~5 minutes works out to 1800, so it should take a little longer than 5 min for it to pass the 2k station penalty.