Factorio Forums

TL;DR

If a train ends up stopped on the tracks for some reason, I want an interrupt to fire which will send it back to parking so it doesn't block traffic.

What?

Sometimes a train will end up getting stopped on the tracks for some reason. Maybe the station it was heading to was deconstructed, or maybe a section of rail was destroyed so there was no longer a valid path to get there. In this case, the train will attempt to find another station to go to, via normal schedule or interrupt, but if it can't it will just sit there, potentially blocking traffic on the main-line.

This seems like exactly the sort of situation that interrupts should be able to solve, by having the train redirect to the nearest parking lot. However, there is no suitable interrupt condition to do so. You can check whether you are at or not any any given station, but not whether you are at any station at all.

What we need is a 'not at station' interrupt condition, which is true if the train is parked - not just halted at a signal but stopped with no active destination - while not at any actual station.

Why?

Because trains parking on the mainline are a traffic hazard.

Isn't this case handled by "Destination full or no path"? I use this to send trains back to a depot (sometimes in combination with "Not at specified station: depot"), and I never have them stopped on the tracks.

shuzen wrote: Mon Jun 08, 2026 10:55 am Isn't this case handled by "Destination full or no path"? I use this to send trains back to a depot (sometimes in combination with "Not at specified station: depot"), and I never have them stopped on the tracks.

No, because I don't always want them to head back to the depot if they are waiting at a station and their next is full. Specifically, if a train has loaded up with cargo, but none of the stations that receive that cargo currently need any, I do not want the train to leave. If it did, then another train would take its place, and eventually I'd end up with all my trains clogged with whatever cargo I was over-producing.

Then don't let trains leave their loading station unless they have somewhere to dump it.

I do agree that Destination Full is not the same as No Path, and it would be useful to be able to treat them differently.

radical_larry wrote: Tue Jun 09, 2026 10:18 am Then don't let trains leave their loading station unless they have somewhere to dump it.

I don't. This is to handle the case where something goes wrong, such as the destination stop being deconstructed or a section or rail removed while the train is en route.

I appreciate OP for creating this suggestion thread. The reason "Destination full or no path" are combined is because they are the only conditions that can trigger an interrupt when you are not at a station, and in that case the reason they teigger (destruction of the network) means there is no point in distinguishing between them.

The trouble arises because the "destination full" part can also trigger when you *are* at a station. You can get around it by ensuring that every schedule record and interrupt contains "Station not full" conditions so that destination-full never triggers, but this is cumbersome. The suggestion as written is that by combining "Destination full or no path" with "Not at any station", the interrupt would only trigger when a train finds itself without a destination while underway (or having just been turned to automatic).

An alternate, potentially more intuitive way to implement this request would be to separate "Destination full or no path" into two different conditions. Not "destination full" and "no path", as has been previously rejected, but "at station" and "not at station" variants:

"Station or path unavailable while en route": all no-path events and any destination-full events that occur while underway.

"Scheduled destination full": all destination full events that would otherwise result in a train sleeping at a station. Sleeping at a station is a special case, because interrupts can be triggered by circuit network signals to the station.

robot256 wrote: Wed Jun 10, 2026 7:54 pm "Station or path unavailable while en route": all no-path events and any destination-full events that occur while underway.

"Scheduled destination full": all destination full events that would otherwise result in a train sleeping at a station. Sleeping at a station is a special case, because interrupts can be triggered by circuit network signals to the station.

I do like the idea of splitting out on-route errors. It would still be nice for destination full (still at station) and no path (still at station) to be separate conditions.

Amarula wrote: Thu Jun 11, 2026 1:37 pm

robot256 wrote: Wed Jun 10, 2026 7:54 pm "Station or path unavailable while en route": all no-path events and any destination-full events that occur while underway.

"Scheduled destination full": all destination full events that would otherwise result in a train sleeping at a station. Sleeping at a station is a special case, because interrupts can be triggered by circuit network signals to the station.

I do like the idea of splitting out on-route errors. It would still be nice for destination full (still at station) and no path (still at station) to be separate conditions.

Assuming we achieve a separate "Destination full while at station" condition, what is your proposed use for separate "Destination full while en route" and "No path while en route" conditions? I don't have a clear picture of why these should trigger different behaviors.

Once you isolate them to en route conditions, they can both can be caused construction/destruction/attacks, and both result in trains being stranded on the mainline. For a given construction/destruction/attack event, it will be random which of the two conditions triggers because it is random whether the train stop or the track or the signal gets destroyed first. That is why I question the need to separate them into two different conditions.

robot256 wrote: Thu Jun 11, 2026 3:24 pm Assuming we achieve a separate "Destination full while at station" condition, what is your proposed use for separate "Destination full while en route" and "No path while en route" conditions? I don't have a clear picture of why these should trigger different behaviors.

Sorry if I wasn't clear. I specifically want the split "at station", combining them "en route" is fine.

Amarula wrote: Fri Jun 12, 2026 1:41 pm

robot256 wrote: Thu Jun 11, 2026 3:24 pm Assuming we achieve a separate "Destination full while at station" condition, what is your proposed use for separate "Destination full while en route" and "No path while en route" conditions? I don't have a clear picture of why these should trigger different behaviors.

Sorry if I wasn't clear. I specifically want the split "at station", combining them "en route" is fine.

Thanks for the clarification. Unfortunately this is not a state that currently exists so it cannot be made into a condition. Trains never search for a path until they reserve a destination slot and leave the current station, so there is no such thing as "no path while at station." Mentioned in this thread today: viewtopic.php?p=693813

Other suggestions asking for schedule conditions based on pathfinding results have been shot down due to the performance penalty constantly finding paths to update the condition. Given that large bases can have significant cycle time spent finding paths for all the trains just once or twice per trip, making stationary trains find additional paths is impractical.

Again apologies for my imprecise language.
We are agreed that once a train is en route, there is no need to distinguish between destination full or no path.
If the train is not en route, it is at a station, and for an interrupt to trigger it is trying to leave the station. At that point there are three options: the train finds a station and a path to that station; the train does not find a station (destination full); or the train finds a station but there is no path to that station.
The current mechanism merges the last two cases, and I would like to be able to program my trains to treat them differently. I can always merge them myself (destination full OR no path), but not the reverse.

Amarula wrote: Sat Jun 13, 2026 3:08 pm Again apologies for my imprecise language.
We are agreed that once a train is en route, there is no need to distinguish between destination full or no path.
If the train is not en route, it is at a station, and for an interrupt to trigger it is trying to leave the station. At that point there are three options: the train finds a station and a path to that station; the train does not find a station (destination full); or the train finds a station but there is no path to that station.
The current mechanism merges the last two cases, and I would like to be able to program my trains to treat them differently. I can always merge them myself (destination full OR no path), but not the reverse.

I understood what you meant. It is a new suggestion unrelated to the topic of this thread and would require significant changes to the game engine. Your description of train state is not accurate because current train logic only has the following states:

1. At station, waiting for conditions to be met
2. At station, waiting for space at a destination station
3. Not at station, has destination reserved, looking for path
4. Not at station, has destination reserved, following path
5. Not at station, has destination reserved, no path found
6. Not at station, no destination reserved, not looking for a path

("Destination full or no path" triggers on states 2, 5, and 6. My solution to the original suggestion is to separate state 2 from atates 5 and 6.)

As you can see, there is no state for "At station, has destination reserved, no path found". There is currently no provision to "return" to the starting station if a destination is selected and no path is found. If one were added, any train without a path and without an interrupt to trigger on it would stay in a loop of constantly pathing to an unreachable station until something changes. Train pathfinding is the most computationally intensive single-tick update in the game and scales exponentially with the size of the rail network. Imagine the impact to UPS on a large base if even one train is pathfinding every tick.

If you want to discuss this further, you should make a new suggestion thread and include this detail about the impact of what you are actually asking for, and try to explain the benefit versus the cost or how to mitigate it.

Previous suggestion threads that mention a valid-path condition as well, with the same potential performance impact:
viewtopic.php?t=117220
viewtopic.php?t=128203