[2.0.23] Trains Ignoring Train Limits, Conditions

[Rubeus]

I had the idea that trains with interrupts could fly around to stops that requst small amounts of items, then refill only when the cargo gets low. The behavior I'm encountering does not seem like it would be intended behavior.

Issues:
When a train has a single stop in its schedule, it remains at the stop even though it has fulfilled its conditions.
When a strain has just 2 of the same top in its schedule, it rapidly switches the target between those scheduled stops without actually moving.
Both of these conditions occur, even when the station has a 0 limit set.
Placing a second, 'dummy' station immediatly after and adding it to the schedule to foce the train to leave causes the train to vacate the station, but immediately return - despite the train limit being 0 (the station shows 1/0 for the limit, even while the train is away). It seems that somehow, the train is pathing to the station it's already at, and despite the train limit.

The interrupts are for low fuel, low cargo, and staging while target station is full [never triggers with this setup].

Save file "Test" attached - train will loop after a few seconds.

Station status

12-10-2024, 22-48-10.png (4.74 MiB) Viewed 581 times

Schedule

12-10-2024, 22-39-35.png (46.11 KiB) Viewed 581 times

[robot256]

Thanks for the report, this is a duplicate of 118475

[Rubeus]

Thanks for the report, this is a duplicate of 118475

There is a lot of overlap there, true. I didn't read far enough in.

My report also covers that it's showing unexpected behavior despite a second, unique, stop added to the schedule. The others are trying to get the trains to loop - that coincides with the first/second issue. Now it's looping uncontrollably, which is a second (albeit related) issue.

[robot256]

The root cause of the report I linked is the new behavior in 2.0 that the train still has a reserved slot at the station it's leaving until the last wagon clears the stop. The bug is that the train is able to make a new path to that station using the "zombie reservation" even though it should be disallowed by the train limit.

In your test save, the second stop is a waypoint (no conditions) and is so close to the first stop that the zombie reservation at the first stop still exists when the train attempts to path to the next stop after the waypoint. Adding a "Time elapsed 0s" condition to the waypoint schedule entry causes it to actually stop there for a moment, and that seems to release the zombie reservation, so the depot interrupt fires properly when it leaves the second stop.

If the bug were fixed so trains are unable to path to zombie reservations, it would fix the behavior you are seeing here.

[Rseding91]

Thanks for the report. I talked with this internally to one of the train guys and the discussion led to leaving it working as is.