Item Parameter Interrupt Evaluations when no Stop exists
Posted: Thu Feb 13, 2025 1:42 am
TLDR: I was trying to set up a priority system for my trains using interrupts without remembering priority got added in 2.0 as well, and my roundabout solution made me wonder about how parameterized stops evaluate in interrupts when that stop name does not exist.
So, in my train network, I have 3 basic stop types:
Item Onload - A basic stop for where stuff is loaded onto a train
[Tag] Offload - Tag named output that the parameterized interrupt can route items to appropriately
[Tag] Buffer - A waiting stop where a train can sit that's near the actual output for the tag so there should be less time spent having a Offload stop blocked by a train that has to travel across my entire rail network
These are working great, but sometimes I would have a slight issue where if there were trains fully loaded at both a [Tag] Buffer and an Item Offload, the train on the other side of the map would be dispatched from the Item Offload, even tho there was a train waiting at the [Tag] Buffer that was much closer.
To fix that, I tried to set up some logic in the interrupts that I was using to only allow the trains to go to the Offload if Buffer were not full, or if they were at the Buffer.
The issue came up that I did not have buffer stops for all the materials I was putting on trains, as some things don't need the extra throughput, but since the new interrupt has conditions that rely on that material having a Buffer stop, the interrupt doesn't trigger as I assume there's some sort of error that comes up due to that stop not existing so it defaults to false as errors usually do for that condition.
Pretty much this was a long way of asking if that's the intended behavior, as while a false default to something that doesn't exist seems good in isolation, defaulting to true would also be ok in my opinion for these cases, as it both allows for more configuration, along with the case where the train tries to path a stop that doesn't exist having an error message in the no path found alert already.
In a counterpoint, what would be the use of a default to false that can't be replicated otherwise, as I can't really think of one.
So, in my train network, I have 3 basic stop types:
Item Onload - A basic stop for where stuff is loaded onto a train
[Tag] Offload - Tag named output that the parameterized interrupt can route items to appropriately
[Tag] Buffer - A waiting stop where a train can sit that's near the actual output for the tag so there should be less time spent having a Offload stop blocked by a train that has to travel across my entire rail network
These are working great, but sometimes I would have a slight issue where if there were trains fully loaded at both a [Tag] Buffer and an Item Offload, the train on the other side of the map would be dispatched from the Item Offload, even tho there was a train waiting at the [Tag] Buffer that was much closer.
To fix that, I tried to set up some logic in the interrupts that I was using to only allow the trains to go to the Offload if Buffer were not full, or if they were at the Buffer.
- Transport Items.png (79.03 KiB) Viewed 321 times
- Wait at Buffer.png (59.84 KiB) Viewed 321 times
Pretty much this was a long way of asking if that's the intended behavior, as while a false default to something that doesn't exist seems good in isolation, defaulting to true would also be ok in my opinion for these cases, as it both allows for more configuration, along with the case where the train tries to path a stop that doesn't exist having an error message in the no path found alert already.
In a counterpoint, what would be the use of a default to false that can't be replicated otherwise, as I can't really think of one.