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.