Factorio Forums

TL;DR

Having more conditions for limiting / triggering interrupts would open up a lot more amazing (and stupid! ) possibilities.

What ?

Train interrupts are EXTREMELY powerful , but a couple more conditions could really kick things up a notch, here's what I would find useful / could see being useful:

- Has fluid wagon: Does the train that the interrupt is triggering on have a fluid wagon? Useful for generic train dispatching systems, yes you can check manually with inserters and some additional logic, but that has caveats.

- Has cargo wagon: Ditto

- Cargo wagon count: Mixing train sizes on the same network is cool! If you're using the same interrupt on multiple train configurations, it would be nice to differentiate them somehow. Especially since Interrupts are not train group specific, you end up with a lot of duplicated interrupts if you want to use different logic for different train sizes.

- Fluid wagon count: Ditto

- Locomotive count: Ditto

- Trains on the way to station / station is empty: If there are trains already heading to the station, It would be useful to be able to detect that from inside the trains, so you can avoid sending 10 trains to the same stop at once. Yes train limits can be used, but having trains on the way is slightly more nuanced, especially if you are using bidirectional trains, where there might not be a open path to the station until the trains on route have fully arrived!

- Has priority / priority conditional: Being able to set a priority threshold would be cool, you could have 2 separate fleets of iron trains that are only activated when priority passes a threshold. Imagine a iron unloading station that increases its priority based on how much ore it has left in its buffer, and you can have a specialized fleet of trains that use higher quality fuel, which _only_ deliver to the station if the priority passes a certain point. IE [station] has priority [comparison] [number or signal value]

- Damage taken: Like space platforms, if a train is taking damage, you usually want to get it outta there ASAP!

- Time passed: Lots of people use inactivity in their unloading stations, but there is times where a train is sitting at a station, and being unloaded _very_ slowly, even though it would be better off going to another station to continue delivering items. Being able to set a hard cap with an interrupt could be useful, especially for stations where you are storing your trains depot style. Ever had a train end up stuck behind another train in a stacker, because the train in front of it has already "left" the station, but has been waiting to pathfind somewhere for 10 trillion years? An interrupt on that train in front to go to another "im idle" station would be useful!

- Has open path: This might be a stretch due to the performance hit of tons of trains doing path calculation when using this condition, but knowing if a train _can_ get to a station from where it is would also be very useful. Only being able to check _after_ a train leaves is a tad annoying, since the train would have to trip a second interrupt. _Or_, if you could allow players to invert the `Destination full or no path` condition.

- Distance: Set a maximum (or minimum!) Distance between the train and the desired station, IE [station] distance is [comparison] [number or signal value]. Imagine having a station on the other side of your base, but you know you need to have x fuel to go x distance, before sending the train, you could validate that the train can make it there and back without running out, or use a train with less cargo wagons to get there faster!

- Fuel level: Being able to check fuels is probably the most powerful part of the interrupt system , but you end up with several `or` statements in a row to check multiple types of fuel. Doing `fuel wildcard` < 50 works great for coal, but when you switch to using uranium in a train, that would trigger every time. A "fuel level" interrupt would allow you to send a train to a station if it is [comparison] [number or signal value]% full on whatever fuel item it is carrying. IE <33% would trip on 200 spoilage, 50 coal, 20 rocket fuel, or 1 nuclear fuel.

Why ?

The more ways you can interact with the interrupt system, the more cool things you will be able to do!
Train got blown up? Send it to the graveyard.
Station is too far away? Don't go there until you have a full tank of gas!
Station has low priority? Eh, somebody else can do that.
Don't have a fluid tank? Then don't go to the oil pickup station!

real this sounds baller

+1 to all of this.

- Has fluid wagon: Does the train that the interrupt is triggering on have a fluid wagon? Useful for generic train dispatching systems, yes you can check manually with inserters and some additional logic, but that has caveats.

- Has cargo wagon: Ditto

I don't think just this would be sufficient for a generic dispatch, assuming you're using circuit signals to trigger the interrupt. I think the ability to test if an interrupt circuit condition signal parameter is an item or a fluid would help with that.

dcohen8128 wrote: ↑Thu Oct 24, 2024 6:30 pm I don't think just this would be sufficient for a generic dispatch, assuming you're using circuit signals to trigger the interrupt. I think the ability to test if an interrupt circuit condition signal parameter is an item or a fluid would help with that.

Agreed! More options is always better.
I think letting the trains check if a signal is a fluid is a bit too far, since that's selector combinator territory IMO

If train stations could output what kinds of wagons are on the train, that would be cool, but that would be another 4 signal types, or it would output the items which would collide...

Especially for interrupts the following would be useful:

• Next destination is free

• Next destination is full

"Minimal priority" would be nice

Having a signal that says a train is on the way would make things so much nicer

I completely agree with these suggestions.

Considering that, currently, fuel is only measured by Item Count, the Fuel Wildcard being used in Interrupt feels useless given the variable stack size & efficiency of various fuel types. Being able to either count complete stacks of fuel in locomotives OR total Joules value in any (or all) locomotives would be be a great way to make that Fuel Wildcard more meaningful!

I was surprised to find that inactivity was not an available trigger condition for interrupts, since its already available as a train stop condition.

edit: turns out I don't know how interrupts work, they only check on station leave, not continually.

+1 for more options!

Dark_Wynd wrote: ↑Tue Oct 29, 2024 3:13 pm currently, fuel is only measured by Item Count, the Fuel Wildcard being used in Interrupt feels useless given the variable stack size & efficiency of various fuel types. Being able to either count complete stacks of fuel in locomotives OR total Joules value in any (or all) locomotives would be be a great way to make that Fuel Wildcard more meaningful!

Yup! Right now, you need to update your train group(s) when you're updating fuel types. Joules seems good, but would introduce a new problem since you're deciding based on maximum distance, but that changes if you have different length trains. Still a lot better than counting items.

Echoing my desire for the ability to query against wagon and locomotive count. I've been experimenting with running different-sized trains on my network and having to duplicate my "Refuel" interrupts to send trains to different stations isn't the end of the world... but being able to selectively enable inserters to insert fuel (and not accidentally into wagons) would be quite nice.

Perhaps a sort of regular expression / wildcard match could be useful?
I like to name stations things like [item=electronic-circuit]+ and [item=electronic-circuit]- and such a thing would allow me to have one clean schedule for absolutely all my trains in a sort of LTN delivery fashion.

I came to write some suggestions about interrupts. But here they are already written by you. Thanks...

DocJade wrote: ↑Thu Oct 24, 2024 6:07 pm - Has open path: This might be a stretch due to the performance hit of tons of trains doing path calculation when using this condition, but knowing if a train _can_ get to a station from where it is would also be very useful. Only being able to check _after_ a train leaves is a tad annoying, since the train would have to trip a second interrupt. _Or_, if you could allow players to invert the `Destination full or no path` condition.

My trains have the loading station on their schedules by default, and unloading station is added by an interrupt when there is an active unloading station.
I also have a "Destination Full" interrupt that sends trains to depots to prevent trains got stuck on rails or stations some edge cases.
When there is an active station which is unreachable, first the unloading interrupt triggers and train leaves the loading station. But since it's unreachable then other interrupt triggers and sends the train to depot. After depot, train goes back to loading station and this cycle continues. I couldn't find any solution to this except adding "Station is reachable" a condition to unloading interrupt which doesn't exist.

I tried adding a dummy interrupt similar to unloading interrupt with addition of destination full check but that interrupt doesn't get triggered. Destination full check only becomes active when the train leaves the station. So we need "Station is reachable" condition like "Station is not full" which can be checked at the station instead of "Destination is reachable"

DocJade wrote: ↑Thu Oct 24, 2024 6:07 pm - Fuel level: Being able to check fuels is probably the most powerful part of the interrupt system , but you end up with several `or` statements in a row to check multiple types of fuel. Doing `fuel wildcard` < 50 works great for coal, but when you switch to using uranium in a train, that would trigger every time. A "fuel level" interrupt would allow you to send a train to a station if it is [comparison] [number or signal value]% full on whatever fuel item it is carrying. IE <33% would trip on 200 spoilage, 50 coal, 20 rocket fuel, or 1 nuclear fuel.

I use dynamic fuel selection based on availability and current fuel logic doesn't work for me at all. So many variables, so many permutations and so many OR conditions... and mods can add more fuel types.. We definitely need another rule that can easily be configured with one condition.
- Fuel Value < X Joules
- Fuel Percent < X
- Number of Empty fuel slots > X