Hey Hey,
So I'm at a point with my 'Factory of Everything' where I have to go wrangle some patches of Iron, Copper, Coal and Stone (luckily all the Crude and Uranium I'll ever need are closer than a train ride) and I saw that Interrupts are a thing. I think I conceptually 'get it' where the trains can semi autonomously go grab the thing the Interrupt asks for if given a signal or trigger to do so.
So my two questions are
1. I have one station at the FoE for unloading solids - Iron/Copper/Coal/Stone with a set of filters on splitters to sort them to the appropriate 4x belts. All Iron and Copper is coming in as plates with on-mining-site smelting. To avoid clogging at unload, my hunch is I don't want to send an interrupt signal too early so should I just set up a buffer 'probe' that has a fast inserter to fill it up and a regular inserter to unload, and when that box hits 0, the train goes and fetches more plates/coal/stone? If so, should I place this towards the 'butt' of the whole factory? Mid-point? I don't want to do fancy ass math to figure the exact locations or use several probes, I'd like minimal wiring if possible here.
2. Can a train get confused by two interrupts and not make up its 'mind' on which one to fulfill, or wind up in a spot where it can't fulfill two at once because the train tracks don't allow it? Like the train can't go A->B->C->A it has to go A->B->A->C->A to reach all 3? Just trying to figure if I'm going to get mad later when it mostly works but for that.
Creating 'Probes' for train pickup interrupts and potential for conflicting interrupts?
Re: Creating 'Probes' for train pickup interrupts and potential for conflicting interrupts?
It's difficult to give advice for interrupts if we don't know your intended train design. An interrupt driven design usually starts with one static schedule entry for a station the train will always visit as default. At start any train is empty, so the static entry is usually one that will load something into the train. The interrupts detect what has been loaded and direct the train to the proper unloading station. This is the design in general that was presented in fff#389 and fff#395.
You seem to want some universal unloading station, quite the opposite of that. So to understand what you have in mind, it's necessary to see more of your train design. In general, at loading stations you use the "cargo full" waiting condition to make the train leave and at unloading stations you use the "cargo empty" waiting condition to make the train leave. Interrupts are different, they don't decide when to leave but instead where to drive next.
For me, it's not clear what you mean with "probes" for train interrupts. "Probes"?
About multiple interrupts: interrupts are checked after a waiting condition became true and the train is about to leave for the next station. In this moment interrupts are checked. They're checked from top to bottom and the first match will trigger. If one matched, its schedule is copied to the main schedule as temporary entry and the train will consult this entry to determine where to drive next.
If one interrupt added multiple schedule entries (you shouldn't do this usually), interrupts are checked also if the 1st temporary entry has been visited and the train is about to leave to the next temporary entry and if there is an interrupt that is allowed to interrupt an interrupt schedule. That's that check mark in each interrupt configuration. If this is activated for one interrupt, and the corresponding interrupt triggers while still having a temporary schedule not yet finished from a previous interrupt, its schedule is also added as temporary entry. As far as I remember, it will replace the remaining schedule.
As rule of thumb, you should have just 1 static schedule entry in your main schedule, and all of your interrupts should also just contain 1 schedule entry. Not more. Otherwise it can get confusing. See interrupts as simple: "if this, than do that". Not "if this, than do that and that and that".
tl;dr
Consider using static schedule entries without interrupts. Use interrupts only if train configuration is easier. Not if it becomes more complex.
You seem to want some universal unloading station, quite the opposite of that. So to understand what you have in mind, it's necessary to see more of your train design. In general, at loading stations you use the "cargo full" waiting condition to make the train leave and at unloading stations you use the "cargo empty" waiting condition to make the train leave. Interrupts are different, they don't decide when to leave but instead where to drive next.
For me, it's not clear what you mean with "probes" for train interrupts. "Probes"?
About multiple interrupts: interrupts are checked after a waiting condition became true and the train is about to leave for the next station. In this moment interrupts are checked. They're checked from top to bottom and the first match will trigger. If one matched, its schedule is copied to the main schedule as temporary entry and the train will consult this entry to determine where to drive next.
If one interrupt added multiple schedule entries (you shouldn't do this usually), interrupts are checked also if the 1st temporary entry has been visited and the train is about to leave to the next temporary entry and if there is an interrupt that is allowed to interrupt an interrupt schedule. That's that check mark in each interrupt configuration. If this is activated for one interrupt, and the corresponding interrupt triggers while still having a temporary schedule not yet finished from a previous interrupt, its schedule is also added as temporary entry. As far as I remember, it will replace the remaining schedule.
As rule of thumb, you should have just 1 static schedule entry in your main schedule, and all of your interrupts should also just contain 1 schedule entry. Not more. Otherwise it can get confusing. See interrupts as simple: "if this, than do that". Not "if this, than do that and that and that".
tl;dr
Consider using static schedule entries without interrupts. Use interrupts only if train configuration is easier. Not if it becomes more complex.
Re: Creating 'Probes' for train pickup interrupts and potential for conflicting interrupts?
Yes, universal unloading station for the base resources, that's pretty much it. Haha, sheesh, so I got the whole thing backwards.Tertius wrote: Tue Sep 09, 2025 7:37 am It's difficult to give advice for interrupts if we don't know your intended train design. An interrupt driven design usually starts with one static schedule entry for a station the train will always visit as default. At start any train is empty, so the static entry is usually one that will load something into the train. The interrupts detect what has been loaded and direct the train to the proper unloading station. This is the design in general that was presented in fff#389 and fff#395.
You seem to want some universal unloading station, quite the opposite of that. So to understand what you have in mind, it's necessary to see more of your train design. In general, at loading stations you use the "cargo full" waiting condition to make the train leave and at unloading stations you use the "cargo empty" waiting condition to make the train leave. Interrupts are different, they don't decide when to leave but instead where to drive next.
So the stations look like:
1 - Main Base Unload
2 - Iron Plate Pickup
3 - Copper Plate Pickup
4- Stone Pickup
5- Coal Pickup
And I want one train to service them all that starts at 1. Walking it out a tiny bit, I was thinking I could use the interrupt logic to tell the train to 'drive to the next station' based on the circuit signal it receives. Probes come into play here.
A probe, more or less, is a sensor that determines if items are running on a belt at all by loading items into a chest and loading items out of it. Linking this to circuits, I was thinking that I would use a probe to generate a signal to a train stop like such:For me, it's not clear what you mean with "probes" for train interrupts. "Probes"?
Sensor: Coal<=0, Signal D is set to 1
Main Base Unload: Signal D = 1 AND Cargo Empty, Go To Coal Pickup
Coal Pickup: Wait Until Cargo Full, Go to Main Base Unload
And then I would iterate a Signal for each item and connect it to a 'probe' reading the belt for items, so Iron = Signal A, Copper = Signal B, Stone = Signal C, Coal = Signal D. I suppose I could also do it so they all share the same Signal but the corresponding number determines where to go - Signal A = 1, Go To Iron, Signal A = 2, Go To Copper, etc etc.
Train/Train Stop Setup:
Main Base Unload is connected to each probe via Green/Red wire.
Train only has Main Base Unload as a listed station with a 'Cargo Empty' condition.
Train Interrupts:
Interrupt A for Iron that keys off Signal A = 1
Interrupt B for Copper that keys off Signal B = 1
Interrupt C for Stone that keys off Signal C = 1
Interrupt D for Coal that keys off Signal D = 1
Does this sorta make sense even if it won't work or is wrong for how the Interrupt system works? I am more than happy to bin the idea and do it differently if it can work differently. It's been years since I've played and even when I was playing back in 2019-2020, I was super mechanical and barely touched circuits - mostly very simple ones for Uranium processing and Heavy Oil->Light Oil and Light Oil->Petrol conversion.
Okay, so getting to this part, I'm a little less worried about running into a headache later with getting too many 'go fetch this now' instructions or conflicting ones.
About multiple interrupts: interrupts are checked after a waiting condition became true and the train is about to leave for the next station. In this moment interrupts are checked. They're checked from top to bottom and the first match will trigger. If one matched, its schedule is copied to the main schedule as temporary entry and the train will consult this entry to determine where to drive next.
If one interrupt added multiple schedule entries (you shouldn't do this usually), interrupts are checked also if the 1st temporary entry has been visited and the train is about to leave to the next temporary entry and if there is an interrupt that is allowed to interrupt an interrupt schedule. That's that check mark in each interrupt configuration. If this is activated for one interrupt, and the corresponding interrupt triggers while still having a temporary schedule not yet finished from a previous interrupt, its schedule is also added as temporary entry. As far as I remember, it will replace the remaining schedule.
As rule of thumb, you should have just 1 static schedule entry in your main schedule, and all of your interrupts should also just contain 1 schedule entry. Not more. Otherwise it can get confusing. See interrupts as simple: "if this, than do that". Not "if this, than do that and that and that".
tl;dr
Consider using static schedule entries without interrupts. Use interrupts only if train configuration is easier. Not if it becomes more complex.
For your last line, I do think there is a 'timing solution' where after getting things fleshed out, I can just take a stop watch and determine how long it takes to clear the 'unload zone' of previous unloading and just make it a regular schedule thing. But I do want to learn circuits better so I can do things a little more automatically without as much waste or energy consumption, on a smaller factory footprint.
Re: Creating 'Probes' for train pickup interrupts and potential for conflicting interrupts?
Doing it backwards and computing destinations isn't feasible, because it's too complex for no benefit. Too many edge cases. The game engine doesn't properly support this.
Having one universal unloading station with a sorting facility behind is a bottleneck, because it doesn't scale. It can unload only one material at a time. If you need multiple materials, trains are unload only one after another. It might work for a small beginner base, but as soon as you build for all the science packs, you need more than just one station.
Instead, build one unloading station for each material. One for iron, one for coal, one for stone etc. As name, include the corresponding icon from the icon picker in the name of each unloading station. For example "(coal) unload", where (coal) is the coal icon.
Give all the loading stations the same name, no matter the material. For example "loading".
Make all the stations the same layout, for example 4 cargo wagons and 1 locomotive, so they can all use the same trains.
Create 1-4 trains and put them all into the same train group.
As static schedule entry, add the loading station with waiting condition "cargo full".
Add one interrupt called "delivery":
condition: cargo <green cargo wildcard> > 0
destination: "<green cargo wildcard> unload".
waiting condition: cargo empty
Set all the stations to train limit 1. Or better, provide a waiting are in front of all of them for 1 additional train, then set all the train limits to 2.
That's the new train interrupt logic that was explained in fff-389 and fff-395. 389 shows the interrupt concept and 395 the universal train concept with the wildcards.
An empty train will first proceed to some loading station. It will load some material. It it's full, it will check interrupts.
The "delivery" interrupt has the green cargo wildcard in its condition, so the wildcard will be substituted by the material in the train. If coal was loaded into the train, it will say: "coal > 0", and this will match, so the destination will be added to the schedule as temporary entry.
The wildcard at the destination will also be substituted by iron, so the schedule being added is actually "coal unload". And that's the name we gave our unloading station. And so the train will proceed there. If iron was loaded, the substitution would be "iron unload", so the train will always go to the proper unloading station.
And that's all. No circuits required. For screenshots, see the fff's I mentioned.
This will work and balance perfectly, as long as you produce more in the loading stations than you consume in your unloading stations. You need as many trains as the sum of the slots of the loading stations plus the sum of the slots of your unloading stations minus 1. This could clog, it's recommended to add a depot for empty trains and add an additional interrupt to move empty trains from the unloading station to the depot:
interrupt condition: no path or destination full AND empty cargo
destination: depot
waiting condition: inactivity 5 seconds
Such a depot consists of multiple train lanes, each with a station called "depot" and a train limit of 1.
Having one universal unloading station with a sorting facility behind is a bottleneck, because it doesn't scale. It can unload only one material at a time. If you need multiple materials, trains are unload only one after another. It might work for a small beginner base, but as soon as you build for all the science packs, you need more than just one station.
Instead, build one unloading station for each material. One for iron, one for coal, one for stone etc. As name, include the corresponding icon from the icon picker in the name of each unloading station. For example "(coal) unload", where (coal) is the coal icon.
Give all the loading stations the same name, no matter the material. For example "loading".
Make all the stations the same layout, for example 4 cargo wagons and 1 locomotive, so they can all use the same trains.
Create 1-4 trains and put them all into the same train group.
As static schedule entry, add the loading station with waiting condition "cargo full".
Add one interrupt called "delivery":
condition: cargo <green cargo wildcard> > 0
destination: "<green cargo wildcard> unload".
waiting condition: cargo empty
Set all the stations to train limit 1. Or better, provide a waiting are in front of all of them for 1 additional train, then set all the train limits to 2.
That's the new train interrupt logic that was explained in fff-389 and fff-395. 389 shows the interrupt concept and 395 the universal train concept with the wildcards.
An empty train will first proceed to some loading station. It will load some material. It it's full, it will check interrupts.
The "delivery" interrupt has the green cargo wildcard in its condition, so the wildcard will be substituted by the material in the train. If coal was loaded into the train, it will say: "coal > 0", and this will match, so the destination will be added to the schedule as temporary entry.
The wildcard at the destination will also be substituted by iron, so the schedule being added is actually "coal unload". And that's the name we gave our unloading station. And so the train will proceed there. If iron was loaded, the substitution would be "iron unload", so the train will always go to the proper unloading station.
And that's all. No circuits required. For screenshots, see the fff's I mentioned.
This will work and balance perfectly, as long as you produce more in the loading stations than you consume in your unloading stations. You need as many trains as the sum of the slots of the loading stations plus the sum of the slots of your unloading stations minus 1. This could clog, it's recommended to add a depot for empty trains and add an additional interrupt to move empty trains from the unloading station to the depot:
interrupt condition: no path or destination full AND empty cargo
destination: depot
waiting condition: inactivity 5 seconds
Such a depot consists of multiple train lanes, each with a station called "depot" and a train limit of 1.
Re: Creating 'Probes' for train pickup interrupts and potential for conflicting interrupts?
Fwiw, I made my original idea work with interrupts. I now have a circuit where an empty chest generates a signal, that triggers the correct interrupt in the train schedule, and sends the train to the pickup station to replenish whatever ran out.
I must have described everything wrong because I made it work almost exactly how I originally wanted - 1 train, 1 unload station, 4 interrupts with one for each resource, 4 pickup stations with 1 for each resource, 4 probes to generate a signal when they're empty, train sits at the unloading station for the main base most the time, waiting for signal to tell it where to go, works like a charm on the logic. I even made some color coded light signals to tell me the status of a train with 'free to go fetch', 'unloading' and 'out fetching', and build in an unloading buffer chest probe to toy around with sending a train to fetch if the probe buffer and unload buffers are clear, not just the probe buffer - mostly to avoid clogs at unload.
There are temporary clogs and its a matter of how large the 'probe buffer' is and how large the 'fetch size' is. I was able to tell the train how much to pick up based on the interrupt instructions and specifying the wait time - 30 seconds = ~9k of items with fast inserters and buffer chests. 15 seconds has no clogs with more trips, 30 seconds has more clogs with less trips. Bottleneck is belt throughput to factory need and actual item consumption (and Iron serves as the tempo of consumption since enough items use Iron/Steel plus Copper/Coal/Stone to make something else and are waiting on Iron), so I can't use an identical probe/trigger/fetch size for each resource type.
'Probe buffer' is how many items the probe can store. So if I forced a chest to only hold 1 stack of items, it would generate a signal sooner rather than later. If I force a chest to hold 10 stacks, it would generate a signal later as it trickles the reference item out onto the belt. A smaller probe buffer creates too many fetch requests for Stone/Coal, a larger probe buffer creates too few Iron/Copper.
'Fetch Size' is how much a train grabs at pickup and while 'Full Cargo' works for Iron and Copper without gumming things up based on their belt throughput and consumption, its way too much to clear out for Coal/Stone in any timely fashion. So I've been teasing out Fetch Size with 15 and 30 seconds intervals for Coal/Stone.
I guess I had to prove it one way or another just to see and it was dead simple to program in the end. Programming was the easiest part, getting the probe buffer size and fetch size closer to optimal is harder and I kind of wish there was a way to calculate fetch size based on other probes or a relative reference? Like measuring the amount of slack in the system by noting the theoretical max capacity of input buffers (and I went nuts making sure everything has an input buffer chest just in case I needed it for reference later), the consumed buffer capacity, the rate of consumption...yeah, IDK how to pull numbers out that will tell a train to wait 15 seconds because there's 4.5k item slack in the system or 30 seconds because there is 9k item slack in the system. I actually hate doing math and love playing by feel and experience, but if there is a function that describes 'pulling close to the right amount to fulfill building items always while avoiding clogs at the sort', maybe I can figure it out.
I'm letting it run for 8-10 hours to see if it screws up at some point and stops working.
I must have described everything wrong because I made it work almost exactly how I originally wanted - 1 train, 1 unload station, 4 interrupts with one for each resource, 4 pickup stations with 1 for each resource, 4 probes to generate a signal when they're empty, train sits at the unloading station for the main base most the time, waiting for signal to tell it where to go, works like a charm on the logic. I even made some color coded light signals to tell me the status of a train with 'free to go fetch', 'unloading' and 'out fetching', and build in an unloading buffer chest probe to toy around with sending a train to fetch if the probe buffer and unload buffers are clear, not just the probe buffer - mostly to avoid clogs at unload.
There are temporary clogs and its a matter of how large the 'probe buffer' is and how large the 'fetch size' is. I was able to tell the train how much to pick up based on the interrupt instructions and specifying the wait time - 30 seconds = ~9k of items with fast inserters and buffer chests. 15 seconds has no clogs with more trips, 30 seconds has more clogs with less trips. Bottleneck is belt throughput to factory need and actual item consumption (and Iron serves as the tempo of consumption since enough items use Iron/Steel plus Copper/Coal/Stone to make something else and are waiting on Iron), so I can't use an identical probe/trigger/fetch size for each resource type.
'Probe buffer' is how many items the probe can store. So if I forced a chest to only hold 1 stack of items, it would generate a signal sooner rather than later. If I force a chest to hold 10 stacks, it would generate a signal later as it trickles the reference item out onto the belt. A smaller probe buffer creates too many fetch requests for Stone/Coal, a larger probe buffer creates too few Iron/Copper.
'Fetch Size' is how much a train grabs at pickup and while 'Full Cargo' works for Iron and Copper without gumming things up based on their belt throughput and consumption, its way too much to clear out for Coal/Stone in any timely fashion. So I've been teasing out Fetch Size with 15 and 30 seconds intervals for Coal/Stone.
I guess I had to prove it one way or another just to see and it was dead simple to program in the end. Programming was the easiest part, getting the probe buffer size and fetch size closer to optimal is harder and I kind of wish there was a way to calculate fetch size based on other probes or a relative reference? Like measuring the amount of slack in the system by noting the theoretical max capacity of input buffers (and I went nuts making sure everything has an input buffer chest just in case I needed it for reference later), the consumed buffer capacity, the rate of consumption...yeah, IDK how to pull numbers out that will tell a train to wait 15 seconds because there's 4.5k item slack in the system or 30 seconds because there is 9k item slack in the system. I actually hate doing math and love playing by feel and experience, but if there is a function that describes 'pulling close to the right amount to fulfill building items always while avoiding clogs at the sort', maybe I can figure it out.
I'm letting it run for 8-10 hours to see if it screws up at some point and stops working.