Factorio Forums

Hi,

currently playing around with the train interrupt system. The drop logic (as described in FFF #395) works nicely, but i can't quite figure out how to sanely "rate limit" the trains.
Currently my "go pick up some copper ore" interrupt checks for available space in both "copper ore" and "copper ore drop" stations, then goes to pick up copper ore. Drop happens via generic cargo interrupt. The problem i'm facing currently: a couple trains are parked with nothing to do. once a spot in "copper ore drop" opens up, there's multiple trains heading to pick up copper ore from "copper ore" - even though there's only _ONE_ free limit on "copper ore drop". Is it possible to somehow limit that?

Basically, i have multiple trains trying to fulfil a request for "one load of copper ore please" by my smelters. But it only registers in the limit there once they're loaded and are actually heading there.

According to 117453 this behaviour is "Not a Bug".

Having a higher Limit set on the Unload stations than the Load stations seems to help with preventing over-dispatching.

Good Luck!

eugenekay wrote: Sat Apr 11, 2026 5:34 pm According to 117453 this behaviour is "Not a Bug".

Having a higher Limit set on the Unload stations than the Load stations seems to help with preventing over-dispatching.

Good Luck!

Thank you for finding & linking that post from 1.5 years ago.
So this is a known limitation of the current system with no decent workaround except "make drop station buffer gigantic and request trains in large batches".
Guess it's back to dedicated train groups per item for me then. At least i can have them park loaded thanks to interrupts i guess.

Easy solution: only have one "depot" stop, and make all your idle trains line up for it in a stacker. That way all but 1 are "en route" to the depot and cannot resoond to interrupts.

robot256 wrote: Sat Apr 11, 2026 7:41 pm Easy solution: only have one "depot" stop, and make all your idle trains line up for it in a stacker. That way all but 1 are "en route" to the depot and cannot resoond to interrupts.

Not sure this would do it, unless i misunderstand your suggestion.
What i understood is "have just one literal 'idle' train stop and all trains heading there, except the one actually at the stop, in a stacker". This unfortunately does not solve my issue, as the interrupt condition evaluates as true until the first train travelled from "depot" to "load", fully loaded there and started heading to "drop". the window for over-scheduling is more than 30 seconds in this setup, depending on travel/load times - don't think i can build a sufficiently large maze for the queue to cover that.

pic-helmed wrote: Sat Apr 11, 2026 8:04 pm

robot256 wrote: Sat Apr 11, 2026 7:41 pm Easy solution: only have one "depot" stop, and make all your idle trains line up for it in a stacker. That way all but 1 are "en route" to the depot and cannot resoond to interrupts.

Not sure this would do it, unless i misunderstand your suggestion.
What i understood is "have just one literal 'idle' train stop and all trains heading there, except the one actually at the stop, in a stacker". This unfortunately does not solve my issue, as the interrupt condition evaluates as true until the first train travelled from "depot" to "load", fully loaded there and started heading to "drop". the window for over-scheduling is more than 30 seconds in this setup, depending on travel/load times - don't think i can build a sufficiently large maze for the queue to cover that.

Oh right, of course. Interrupts only work for systems where every loading station acts as a depot for full trains. It is impossible to use interrupts to run a system where trains are always empty when idle.

robot256 wrote: Sat Apr 11, 2026 8:39 pm

pic-helmed wrote: Sat Apr 11, 2026 8:04 pm

robot256 wrote: Sat Apr 11, 2026 7:41 pm Easy solution: only have one "depot" stop, and make all your idle trains line up for it in a stacker. That way all but 1 are "en route" to the depot and cannot resoond to interrupts.

Not sure this would do it, unless i misunderstand your suggestion.
What i understood is "have just one literal 'idle' train stop and all trains heading there, except the one actually at the stop, in a stacker". This unfortunately does not solve my issue, as the interrupt condition evaluates as true until the first train travelled from "depot" to "load", fully loaded there and started heading to "drop". the window for over-scheduling is more than 30 seconds in this setup, depending on travel/load times - don't think i can build a sufficiently large maze for the queue to cover that.

Oh right, of course. Interrupts only work for systems where every loading station acts as a depot for full trains. It is impossible to use interrupts to run a system where trains are always empty when idle.

Yeah, i had kinda hoped to reduce the amount of trains idling by 75% or so by sharing them between different goods.


For what it's worth, the interrupts also work when the trains idle at generic depot stations everywhere when they're loaded. So no need for gigantic stackers at every station anymore, just enough to keep inserters busy. can't do different items with the same train though, which is what i was trying to do here.

pic-helmed wrote: Sat Apr 11, 2026 6:59 pm So this is a known limitation of the current system with no decent workaround except "make drop station buffer gigantic and request trains in large batches".

This is not required. If you have small train limits everywhere (1 is a good value, and in case you increase you need to add proper waiting areas in front of the stations) and a small depot for empty trains, trains will flow dynamically from loading stations to unloading stations and vice versa.

The schedule in your OP has the issue that it tries to cover 2 steps: first load, then unload. Don't do this. Instead, do these steps separately.
The schedules in your last post are a step into this direction, but are not complete.

• Create a schedule with 1 static entry. Target is loading station and wait for "cargo full". Give each loading station a train limit of 1.
• As delivery interrupt, add one with condition "has cargo in inventory", as target "<cargo wildcard> unload" with waiting condition "empty cargo".

These entries will make trains go to any free loading station, then load cargo, then the delivery interrupts trigger and they get the unloading station for the loaded cargo as destination.If such a station exists and is free, the train will proceed there. If not, the train will stay until there is a free unloading station.

Give each unloading station a train limit of 1 as well.

Now the handling of empty trains.

• A train that just got empty at an unloading station will consult its default schedule and will drive to the next free loading station and the cycle starts again. In case there is no free loading station, we need to do something since we cannot allow the empty train occupy the unloading station.
• So we add another interrupt, a depot interrupt.
  Condition "destination full or no path" AND empty cargo inventory AND not at depot"
  Target: depot, waiting condition: none or inactivity 1 second.
• Add a few stations all named "depot", all with train limit 1.

In case the empty train cannot leave because all loading stations are full, the depot interrupt will trigger because of "destination full or no path". This interrupt will only trigger if the train is empty, so it doesn't pull the full trains currently waiting at the loading stations. It's just for freeing the unloading stations from empty trains. To avoid the interrupt trigger continuously if the train is already at the depot, there is the 3rd interrupt condition (not at depot).
A train at the depot gets neither the delivery interrupt triggered nor the depot interrupt, so it resorts to the default schedule, which directs the train to the loading station. So the train will drive to the next loading station as soon as one becomes free.

The schedule I presented is a universal schedule. If you name all loading stations the same, regardless of the material, the trains will handle every material. One cycle with iron ore, the next cycle with copper ore, depends on what is free.
With this concept you need to make sure you build enough trains. With ore you have roughly 2 loading stations per unloading station, and if you sum up their train limits (1), you get 3. Build that many trains for this material. If you share trains for iron ore, copper ore, coal, stone and have 2 iron ore unloading, 2 copper ore unloading, 1 coal unloading, 1 stone unloading and double the corresponding loading stations, we have:

• iron ore: 2 unloading + 4 loading all train limit 1 = 6*1 = 6
• copper ore: 2 unloading + 4 loading all train limit 1 = 6*1 = 6
• coal: 1 unloading + 2 loading all train limit 1 = 3*1 = 3
• stone: 1 unloading + 2 loading all train limit 1 = 3*1 = 3
• added up: 6+6+3+3=18

So build 18 trains.

For the depot, build ~3 depot stations. Theoretically 1 depot is sufficient if you build exactly the correct amount of trains, in practice a bunch of depot stations are useful to avoid congestions. At maximum build as many depot stations as there are unloading stations, i. e. 6. However as I said probably 3 are enough.

It's actually nothing more than the concept presented in https://factorio.com/blog/post/fff-395
You wrote in your OP you implemented this, but you didn't do it correctly. I guess you didn't set proper train limits. They're essential.

Tertius wrote: Sun Apr 12, 2026 9:49 am

pic-helmed wrote: Sat Apr 11, 2026 6:59 pm So this is a known limitation of the current system with no decent workaround except "make drop station buffer gigantic and request trains in large batches".

This is not required. If you have small train limits everywhere (1 is a good value, and in case you increase you need to add proper waiting areas in front of the stations) and a small depot for empty trains, trains will flow dynamically from loading stations to unloading stations and vice versa.

The schedule in your OP has the issue that it tries to cover 2 steps: first load, then unload. Don't do this. Instead, do these steps separately.

[...]

Thanks for the Input. I already have all stops limited to 0/1 depending on storage via circuits, so that was not the issue.
Took me a while to understand your point, but what seems to actually solve this is:

• have full trains wait at the loading stop, not at depot
• have #Loading+#Unloading trains in the group
• have at least #Unloading depot stops (in case all Loading are full and all Unloading are 0/0 due to lack of demand)
• can even use the same name for all Loading stops in this setup, so just 4 interrupts per train configuration

Just to document this in case anyone stumbles upon this in the future, here's what works nicely so far