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.
[2.0.17] Inconsistent Train Interrupt Condition Handling (Full Destination vs. No Path)
Re: [2.0.17] Inconsistent Train Interrupt Condition Handling (Full Destination vs. No Path)
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.
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 mods: Multiple Unit Train Control, Smart Artillery Wagons
Maintainer of Vehicle Wagon 2, Cargo Ships, Honk
Maintainer of Vehicle Wagon 2, Cargo Ships, Honk
Re: [2.0.17] Inconsistent Train Interrupt Condition Handling (Full Destination vs. No Path)
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.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.