[2.0.17] Inconsistent Train Interrupt Condition Handling (Full Destination vs. No Path)

Post your bugs and problems so we can fix them.
Necandum
Inserter
Inserter
Posts: 40
Joined: Sat Jan 06, 2024 2:05 am
Contact:

[2.0.17] Inconsistent Train Interrupt Condition Handling (Full Destination vs. No Path)

Post by Necandum »

Not sure if this is a bug or an intended compromise. Apologies if the latter.

Summary: Interrupt condition handling (specifically evaluating if train is at a stop) appears different if the next station is full or if no path can be found.

What I did

Create Pick-up and Depot stations.
Set Pick-up as only station in schedule.
Create interrupt with conditions [Destination full or no path] AND [ Not at (Depot)] which sends train to the Depot station. No wait condition.

Train starts is currently at Depot station, attempting to depart for the Pick-up station.

Scenario A)
All pick-up stations are accessible, but full.
Outcome: as expected, the interrupt does not fire.

Scenario B)
There is a pick-up station that is not full, but there is no path from the Depot station the train is at.
Outcome: the interrupt continues to fire, ignoring the fact that the train currently at the depot station. It will continue to fire repeatedly.

Expected Outcome
Regardless of whether the next destination is full, or no path can be found, I would expect the interrupt to behave the same. I would expect the condition [Not at specified station] to work in both cases.

Please let me know if any further details / saves / etc. would be useful.
Many thanks for the excellent game.
robot256
Smart Inserter
Smart Inserter
Posts: 1062
Joined: Sun Mar 17, 2019 1:52 am
Contact:

Re: [2.0.17] Inconsistent Train Interrupt Condition Handling (Full Destination vs. No Path)

Post by robot256 »

This does seem to be an issue with the idea of a "No path" interrupt. The train still departs the Depot, attempts to path to the "available" stop, fails, and after 1 second triggers the interrupt again. If I add a "Wait 1 second" condition to the Depot in the interrupt, that just means it repeats this process less frequently. It seems like the "no path" determination cannot be made while the train is still waiting at the stop. The warnings still appear, so that makes me think it's not intended as an operational mode, but more of a failsafe to get "no-path" trains off the mainline until you investigate. In that sense, it makes sense to retry pathing every 1 second to avoid overloading the pathfinder.

Unrelated, I've seen a lot of people having issues with interrupts that have no wait conditions when they are meant to be places for trains to wait, so regardless I think you should have some sort of condition there.
Necandum
Inserter
Inserter
Posts: 40
Joined: Sat Jan 06, 2024 2:05 am
Contact:

Re: [2.0.17] Inconsistent Train Interrupt Condition Handling (Full Destination vs. No Path)

Post by Necandum »

robot256 wrote: Wed Nov 13, 2024 12:01 am This does seem to be an issue with the idea of a "No path" interrupt. The train still departs the Depot, attempts to path to the "available" stop, fails, and after 1 second triggers the interrupt again. If I add a "Wait 1 second" condition to the Depot in the interrupt, that just means it repeats this process less frequently. It seems like the "no path" determination cannot be made while the train is still waiting at the stop. The warnings still appear, so that makes me think it's not intended as an operational mode, but more of a failsafe to get "no-path" trains off the mainline until you investigate. In that sense, it makes sense to retry pathing every 1 second to avoid overloading the pathfinder.

Unrelated, I've seen a lot of people having issues with interrupts that have no wait conditions when they are meant to be places for trains to wait, so regardless I think you should have some sort of condition there.
My current solution is to avoid having disconnected networks. Not having a wait condition doesn't seem to have much of an effect: the interrupt triggers repeatedly by in a somewhat delayed fashion (every ?2-3 seconds) and isn't messing anything up so I just ignore it for now.
Post Reply

Return to “Bug Reports”