JGR opened the ticket and wrote:

CFollowTrackT::Follow in src/pathfinder/follow_track.hpp unconditionally returns EC_NO_WAY for failure conditions due to CanEnterNewTile returning false, even when CanEnterNewTile returns the correct result of EC_RAIL_TYPE in the case where the current vehicle cannot use the new rail type.
When a result of EC_NO_WAY instead of EC_RAIL_TYPE is cached (via the test of the return value in PfCalcCost), subsequent vehicles which can use the new track type will erroneously avoid it if using the cache, as it is cached as a dead end, but will use it if the segment had not been cached (or had not been cached incorrectly), which leads to desyncs and can be caught by the cache checks in stChooseRailTrack etc.

See savegame for example.
Train 1 cannot use the track segment from Tile B to the station, Train 2 can.
If starting train 1 from the depot, it goes via Path 2 at Tile C, and caches the segment at Tile A towards Tile B incorrectly as a dead end.
If starting train 2 from the depot afterwards, it incorrectly goes via Path 2 instead of Path 1 at Tile C, and this triggers the desync check in stChooseRailTrack.
If starting train 2 without previously starting train 1, it correctly goes via Path 1 at Tile C.

See attached patch for proposed fix to avoid overwriting return code of CanEnterNewTile with EC_NO_WAY, the savegame performs correctly with this applied.
EC_NO_WAY only needs to be explicitly set in the changed line when `m_new_td_bits == TRACKDIR_BIT_NONE` (an actual dead end), as the ` || !CanEnterNewTile()` in the conditional already sets `m_err` to the correct value in the other cases.

The patch/testing was performed on r27409.

Attachments

• Prundstone Transport, 2000-01-23.sav (24.62 KiB)
• pf-yapf-cache-follow-railtype-fix.diff (0.51 KiB)

Reported version: trunk
Operating system: All

This issue was imported from FlySpray: https://bugs.openttd.org/task/6379