Friday Facts #395 - Generic interrupts and Train stop priority

[crj]

I hate to be the masochist here, but this all looks so great I can't see myself ever using anything except generic trains.

Obviously I've not played this, but I'm wondering if this stuff is so good it needs to be enabled by research beyond the normal "Automated rail transportation" and "Rail Signals"?

[Qon]

And even with a way to route trains to stops dynamically, we might still need to design a whole central scheduling computer with combinator hashtables and whatnot, so it's not exactly making the game too easy either.

I'm making the solution for that with my Combinassembly language. Of course, my suggestion is just a very powerful but simple tool, none of the complexities are handled. It's way harder than anything done with regular static train schedules so far. But it removes the problem of being forced to path trains with circuits when you actually just want to set destination. But that is really far from "dumbing down" the game, we are talking about requiring combinator systems way more advanced than anything else in the game requires to utilize this feature completely. It's a bit like setting recipes on assemblers by circuit signals, but for trains. Making it "easy" is not really part of the discussion here.

I'm not yet convinced that the new cool interrupt features allow us to completely control trains with circuits. The interrupts and the generic signals are very cool, but with generic signals only being able to take the signal type from inventory and not from combinators we can't tell trains where to go.

We know that interrupts can read signals from the station the interrupted train is parked at, and this FFF mentions an "any signal" signal for the condition.

The ability to "read" signals doesn't tell us how they can then then be used. If I was the one to design the system I could be confident it would be done right, but I'm not.

You can totally make a train go to station "[A]" by sending the [A] signal to its train stop.

I'm not yet convinced I can "totally make a train go to station "[A]" by sending the [A] signal to its train stop." with the information provided. That sounds like you extrapolated based on wishful thinking. And it's still a bad system if it works like this because:

If you run out of signals, you can start naming your stations "[A] 1", "[ B] 1", "[A] 2", etc, with the downside that you'll have to duplicate the interrupt for any number you use (unless they add a replacement for the signal's value).

Running out is just 1 downside. The other is that it just isn't a good dynamic system, you can't really do generic computations to get from one signal type to another. I don't want to get introduced to a system that promises to let me name all stops the same, and then being forced to giving individual names (with manually typing in names in stops and interrupts) for configuring stops to have [A] 1 or [A] 2 as names because I ran out of signals. I don't want to have to configure a constant combinator to hold all possible signal values. I don't want to set constant combinators to "unique" signal types at each stop to utilize the "generic signal" feature that should have removed this manual configuration from each stop. It's clunky and bad.

What I want is more like the "generic signal" being converted to a numeric value instead of a signal type. Then I can actually ID all stations with unique identifying codes. I can generate these numbers programmatically from coordinates or incremented indexes.

Building on my suggestion description

with generic signals only being able to take the signal type from inventory and not from combinators we can't tell trains where to go. And just signal type isn't enough, we would need a number that could be used to identify the station. Just type can't be programmed for arbitrary amounts of stops. This alone wouldn't be give us the power to completely control pathing, but we would be able to explicitly control what stop to go to at least.

Adding to this, stations would also need a "generic signal" in their name so part of their name can be set by combinators. Well, it's enough if it's a fixed signal type with a dynamic value that changes the part of the "name" (doesn't have to actually change the name, just virtually to trains trying to decide stops) to the input value.

So the system would be something like

• stops with a name like "[train-stop] Unloading [A]" (actually "[item=train-stop] Unloading [virtual-signal=signal-A]" but I'm shortening it like in my language so it's more readable since forum doesn't transform rich text tags).
• The GUI for the train stops gets a checkbox "dynamic signal name", which means that the name is effectively "[train-stop:0] Unloading [A:7]" if the stop is receiving [A] 7 on red wire ([train-stop] and [A] have no inherent meaning, it's just a part of the name with rich text tags). The ":number" is just a way to convey that the name is "changed". If the box isn't checked the name behaves like "[train-stop:0] Unloading [A:0]" regardless of what the [train-stop] and [A] signals are.
• Trains with "[train-stop] Unloading [A]" in their schedule "changed" to "[train-stop:0] Unloading [A:7]" if there's a [A] 7 on the green wire to the train stop. It gets sent to any train stop with matching name and matching signals,on red wire for the target stop, to the signals on green wire from
  Trains with "[train-stop] Unloading [A]" in their schedule or interrupts. Since targeting and ID-setting uses different wires a stop can have dynamic ID and tell trains to go to any other target stop at the same time.
• Since non-existent signals == 0, the stops and trains don't need a configuration for every signal in schedule/stop name, and if you don't wire in any values then the stops/schedules will default to 0 and work like regular "static" names.

Having a specific [stop-id] signal (sent to stops to configure them) and [targeting-id] signal (sent to stops with trains to direct trains to stops with same value [stop-id] as the [target-id] signal) would be enough though and maybe even simpler. And then the signals wouldn't be needed in the stop/schedule names.

[crj]

I see that train blueprints now undergo a state transition once fully constructed. This is a thing I desperately want for more general blueprints: some kind of combinator which sets a signal when the blueprint containing it is fully constructed.

[MBkufel]

Priority setting via circuts will finally allow balanced distribution of materials. I love it

[Hanse00]

Maybe we’re getting too meta, but the first thought that came to mind for me was: Could we have a “no path” interrupt?

Whilst letting the engineer know that they’ve created a situation where pathing is not possible, it could still be desirable to move that train to some kind of “depot” for debugging, rather than blocking the track.

If we had an interrupt signal for: When you find yourself with no path, path to X Instead, this would be possible.

[cackling.fiend]

I like the "no path" / "destination full" icons, they look great on trains, could you just add a "manual mode" indicator? Sometimes I accidentally switch a train to manual and then it's not obvious why iron isn't coming in

Regarding the generic interrupts, I'm not sure I love the showcased implementation, often my trains will be called "[iron-icon] iron drop-off" to have the fanciness of the icon, but the readability / searchability of text. Would it be possible to implement a basic wildcard, for example "[any-item] *drop-off" would match anything starting with the generic interrupt's item and ending with "drop-off"? I don't know if that would hurt performance, probably not for <1000 unique train stop names.

You might be surprised to hear that icon in names are searchable and train destination selection has a search too. So I only have the icon in the name but I can still search for the word (e.g. "iron"). However, that is not an argument against what you are saying.

[morsk]

This won't help me ship intermediaries by train. I need a mall to be able to request the intermediaries it needs from across the train network. Only then would it be sensible to build intermediaries that aren't ratioed perfectly for science, and use "priority" to distribute them.

The main bus lets the mall request the intermediaries it needs. Vanilla trains have never been able to compete with this.

If a mall can't do this, I have to ship ore/plate so the mall can make its own things, and then I may as well make science from ore/plate. Every train is ore/plate. Or I suppose I could have some bizarre unloading area with 30 different stations for all the intermediaries. I will probably do this and just pretend it's something else, but I don't like it.

[MrGrim]

For example, if you disable a stop while a train is en-route, the train may very well be in a position where it can't path anywhere else (e.g. just turning the corner to arrive). This would cause the train to 'no path' while sticking out onto the mainline, causing chaos for the rest of the trains.

This is a design flaw of the network, but you've mistaken it as a design flaw of the feature. If you want the ability to re-target trains mid route, then of course you must make sure that they can re-path at any point in their route.

And that's what has been taken away, mid route target changes. This wasn't some esoteric exploit or an unexpected emergent behavior. This was a first class capability that you've decided we're what, too dumb to use now? Bit of a slap in the face, ngl.

Really, many of the new train features are great, but it feels very much like the rail system is being pushed into a "one right way to use trains" kind of design. You're riding a real fine line. If you solve all the problems for me, then what is there left for me to do? I'm already throwing away entire blueprint books of rail system designs that represent hundreds of hours of fun I had with this game, replaced with 3 clicks of a mouse. What's left has been made impossible because a unique first class feature was removed with no replacement.

[YotaXP]

Very nice additions. Might I suggest an interrupt condition called "Target Is Valid" that only passes when, well, the target has a valid stop? It might be useful to have some generic interrupts that don't put the train into a "No Path" state if the station doesn't exist, and instead lets it continue its normal schedule.

[Khagan]

In your post, you've skipped over an important question: which kind of setup actually needs the old skipping behavior? If you have a use case, one that isn't solvable via queue limits or interrupts, please do tell.

I currently use skipping for my ammunition supply train, in a way that certainly can't be replaced by stop limits, and I don't think (though I may be wrong) can be emulated by an interrupt. The supply train carries enough ammo, oil, repair kits etc. to top up three wall sectors. So its schedule reads 'Munitions' (in the main base), 'Wall', 'Wall', Wall'. Most of the time it sits in the main base, fully loaded. When a wall station is enabled (due to low supplies), the train heads out to top it up. If another sector or two also need topping up, the train does those before heading back to base; if not, it goes back to base directly.

That last 'if not' is impossible without skipping; without it, the train may remain indefinitely at a wall station, which is _not_ desired behaviour (not central, not topped up, potentially vulnerable to bugs).

[Kaisi]

In your post, you've skipped over an important question: which kind of setup actually needs the old skipping behavior? If you have a use case, one that isn't solvable via queue limits or interrupts, please do tell.

In my case i use logic controlled "bot unloading" stations with active provider for even allocation. A station that receives all trains needed for the production complex. One station for many different trains and there are a lot of such complexes with identical station name on big distances. Because of big distances i need to buffer trains (while one set is unloading, another one is "in route") and when complex take a break for some reason (item buffers are full or i mess with it) logic disables station and "in route" trains redirect themselves to other complexes or "station buffers" to not clog the receiving station. Without stop skipping the whole system breaks. Trains will not be rerouted and still try to unload each one of them. And there may be many of them, depending on how many resource types complex use and it's distance.

Same system is very efficient for trash hauling on big distances. A lot of trash trains rushing to load, but than there is no more trash and all of them reroute to buffer to not clog the rails.

"Stop skipping" is essential and can be used in many ways where ques has no power. Do not remove it.

[BaggyK]

I currently use skipping for my ammunition supply train, in a way that certainly can't be replaced by stop limits, and I don't think (though I may be wrong) can be emulated by an interrupt. The supply train carries enough ammo, oil, repair kits etc. to top up three wall sectors. So its schedule reads 'Munitions' (in the main base), 'Wall', 'Wall', Wall'. Most of the time it sits in the main base, fully loaded. When a wall station is enabled (due to low supplies), the train heads out to top it up. If another sector or two also need topping up, the train does those before heading back to base; if not, it goes back to base directly.

That last 'if not' is impossible without skipping; without it, the train may remain indefinitely at a wall station, which is _not_ desired behaviour (not central, not topped up, potentially vulnerable to bugs).

FF #389 shows an example of an interrupt with the conditions "Destination full or No path" and "Empty cargo inventory" in which case it seems that it should be possible to setup an interrupt to do that.

[Khagan]

FF #389 shows an example of an interrupt with the conditions "Destination full or No path"

OK, that could probably be used to skip.

[Tohim]

Man, I love train FFFs. Wouldn't it be great if ALL FFFs were train-related in some way?

[Violet_Scarelli]

Will there be a way to handle unknown items with generic item interrupts? For example, being able to say "if you can't find a stop to bring this item to, take it here"? That would be extremely useful.

[BaggyK]

Will there be a way to handle unknown items with generic item interrupts? For example, being able to say "if you can't find a stop to bring this item to, take it here"? That would be extremely useful.

In the FF they say that "Trains will 'No Path' for stops that don't exist." Then I would think it should be possible to handle that condition with a "No Path" condition.

[maxfrolikov]

I think that instead of icons on trains there should be small lights, like on drills

[Fiorra]

I'm not yet convinced I can "totally make a train go to station "[A]" by sending the [A] signal to its train stop." with the information provided. That sounds like you extrapolated based on wishful thinking.

From the FFF:

We also have similar signals for 'Any Fluid', 'Any Fuel' and 'Any Signal'.

The keyword being "similar", meaning that they share the characteristics spelled out in the FFF right above the quote.

I'm not sure if you're interested in discussing the theoretical capabilities of the system, or if you intend to build an actual base with it. The theoretical power of the "Any Signal" is identical to your suggestion, just requires more lookup tables. If it's about an actual base, then I'd be curious to know what you intend to build with it.

Good. If you don't need station skipping (especially when 2.0 drops), what's it to you if the feature was kept as an option?

Reason one, I've seen enough posts from players where this caused problems, and the usual answer is: don't disable the station, set the limit to 0, and it'll work as expected. If disabling does the same as setting the limit to 0, those posts disappear, and those players are happy.

Reason two, if I can disable a train stop instead of setting the limit to 0, that'd make some of my circuitry easier.

If your only reason to keep it is about spacebar-heating, that's not a strong argument.

I currently use skipping for my ammunition supply train, in a way that certainly can't be replaced by stop limits, and I don't think (though I may be wrong) can be emulated by an interrupt. The supply train carries enough ammo, oil, repair kits etc. to top up three wall sectors. So its schedule reads 'Munitions' (in the main base), 'Wall', 'Wall', Wall'. Most of the time it sits in the main base, fully loaded. When a wall station is enabled (due to low supplies), the train heads out to top it up. If another sector or two also need topping up, the train does those before heading back to base; if not, it goes back to base directly.

An actual use case, thank you! But it might be solvable with interrupts. Before I quote FFF 398, let me tag someone else:

I feel like there could be room for a "No path" interrupt.

So we just added a special interrupt condition called "Destination full", which allows us to make an interrupt to send a train to a depot if all the item inputs are occupied, so it doesn't block the current station.

So your schedule would be "Wall" -> "Wall", with an interrupt for ("Destination full" or "items low") that leads back to base. Bonus: if the wall stops need different items, then the new schedule can top up more than three wall sections, as long as supplies last.

In my case i use logic controlled "bot unloading" stations with active provider for even allocation. A station that receives all trains needed for the production complex. One station for many different trains and there are a lot of such complexes with identical station name on big distances. Because of big distances i need to buffer trains (while one set is unloading, another one is "in route") and when complex take a break for some reason (item buffers are full or i mess with it) logic disables station and "in route" trains redirect themselves to other complexes or "station buffers" to not clog the receiving station. Without stop skipping the whole system breaks. Trains will not be rerouted and still try to unload each one of them. And there may be many of them, depending on how many resource types complex use and it's distance.

Same system is very efficient for trash hauling on big distances. A lot of trash trains rushing to load, but than there is no more trash and all of them reroute to buffer to not clog the rails.

Yay, use cases! But if the train station gets reenabled, then all the trains are far away. To prevent starvation, you need enough buffers to last through one train trip anyway, correct?

In that case, the usual way to handle this is to dynamically set the train queue limit according to missing items, thus requesting exactly the amount of trains that you need. No more wasted trips.

When you're doing maintenance and you don't want to get run over, removing a piece of rail before the station is the only safe option. Trains are free to pass through disabled stations, especially when they spot an engineer on the tracks.

[Kadet123]

Will there be a way to handle unknown items with generic item interrupts? For example, being able to say "if you can't find a stop to bring this item to, take it here"? That would be extremely useful.

My thought was, since the interrupt list is evaluated top-down each time a train is ready to leave its current station, was to have at the bottom of the list a catch-all interrupt that says "if not empty, go to the dump station". My dump station might be a special station at base that puts all remaining cargo into active providers.

[Syriusz]

Maybe we could add a special train stop to the schedule that will be a fallback when there is no path/ invalid station for a train? So instead of stopping in the middle of the main track they could be sent to the depot. Of course fully optional, if not set up then normal no path behaviour would happen.