Factorio Forums

When using the "destination station is full" interrupt condition to redirect trains to a parking area, the interrupt's new stops get added after the current destination. This makes it difficult to reuse interrupts for multiple train groups, because to avoid skipping stops the names of each station must be embedded into the interrupt.

Given this schedule:

• station: steel loading
  • condition: wait until cargo full
• station: steel unloading
  • condition: wait until cargo empty

Ideally it would be possible to define interrupts that can be reused between different train groups:

• interrupt: 1-4-1 refuel
  • condition: any locomotive [nuclear fuel] < 1
  • target station: 1-4-1 refuel
• interrupt: 1-4-1 parking
  • condition: destination station full
  • target station: 1-4-1 parking

However, in the current design, interrupt target stations are added after the current station, which is skipped. So trying to use the generic interrupts for steel transport might cause this sequence:

• arrive at steel unloading
• wait for empty cargo
• set destination to steel loading
• destination station full, set destination to 1-4-1 parking (skipping "steel loading")
• arrive at 1-4-1 parking, set destination to steel unloading

Instead of waiting in the parking area for a loading station to become available, the train will busy-loop between the unloading dock and the parking area.

What I want is a way to have the interrupt happen in addition to, rather than instead of, the original scheduled stop. There are a couple ways this might be expressed in the UI:

1. As a checkbox in the interrupt details form, "skip current destination", defaulting to true. Unchecking it would cause the interrupt to happen first, then the original schedule's destination happens after the interrupt finishes.

2. As a special "original destination" list item in the target station list. This would be a bit more complex, but allows new stations to be added before and after the original -- for example a refuel interrupt could be written to happen either before or after the original destination (depending on the order of interrupt targets).

I believe the main part of this suggestion was deemed a bug (115988) and fixed already, so this can be considered "implemented".