Friday Facts #389 - Train control improvements

[svalorzen]

Interrupts are evaluated when ready to leave a station. It's been suggested that signals from that station are still available at that time. If that is the case, you could simply set the B signal to 1 for stations in the base, and add B=1 to the conditions of the refueling interrupt.

What this makes me wonder is how interrupts interact with waypoint stations (stations without wait conditions, where the train will not stop).

This is true, but I guess that with different trains and different schedules you might want to set the stations where interrupts are available differently. Without counting the fact that you can have multiple types of interrupts. Given that one of the main features is the fact that interrupts are global so you don't need to specify them multiple times, having to specify for each train some specific signal that will make a certain interrupt available or not, seems to me kind of counter to that, as you'll have to duplicate interrupts just that one will only trigger if B=1, and another if A=1 and so on depending on which schedule is associated to it. Going to end up with lots of INTERRUPT_FUEL_ON_A and INTERRUPT_FUEL_ON_B etc..

[Khagan]

This is all good stuff, and I look forward to having it in 2.0. But no sign of a fix to my single biggest QoL gripe with the current version, namely the inability to configure a sensible default behaviour for temporary train stops.

[ignatio]

Good stuff. Only thing I'm missing is some way of expressing "in the vicinity" as a condition in an interrupt. It'd be quite useful for not dashing right across the whole map, skipping many stops that are on the way (as a few others have already mentioned). It'd also leave a lot of room to do entirely interrupt-based "intelligent" schedules where trains make themselves as useful as possible in the local area, minimising long travels.

Not sure exactly how that'd look, but a few thoughts:

• A condition that the target stop is less than X distance units away. (Having "more than" and "between" as comparisons could be useful too.)
• A condition that the current stop is (or isn't) one of a list of stops.

Both could have their uses - the 1st would give easy but somewhat imprecise control, while the 2nd would allow very accurate and complex schedules.

[ThePiachu]

I love these changes! I really like the interrupt one since I have had to implement too many "add a parking to my Space Exploration logistics in case something is too full".

I am also looking forward to the train groups so I don't have to copy paste the same train schedule too many times!

Hmm, could we maybe get train colours based on the average colour of its cargo? Could be neat to see a train turning blue when we put in iron ore and all that...

One important thing I'd love to see though, would be train stop priorities based on last time a train visited them - viewtopic.php?f=6&t=109164&p=593810#p593810 . It seems this would be still unaddressed by the current train changes and it's still a bane in my train city Space Exploration playthrough where I do have some parts of my base that will eat entire trains worth of inputs for WEEKS before anything else will get a piece (I'm looking at you, Bioscrubbers and Productivity Modules that eat Bioscrubbers...).

[robot256]

Interrupts are evaluated when ready to leave a station. It's been suggested that signals from that station are still available at that time. If that is the case, you could simply set the B signal to 1 for stations in the base, and add B=1 to the conditions of the refueling interrupt.

What this makes me wonder is how interrupts interact with waypoint stations (stations without wait conditions, where the train will not stop).

This is true, but I guess that with different trains and different schedules you might want to set the stations where interrupts are available differently. Without counting the fact that you can have multiple types of interrupts. Given that one of the main features is the fact that interrupts are global so you don't need to specify them multiple times, having to specify for each train some specific signal that will make a certain interrupt available or not, seems to me kind of counter to that, as you'll have to duplicate interrupts just that one will only trigger if B=1, and another if A=1 and so on depending on which schedule is associated to it. Going to end up with lots of INTERRUPT_FUEL_ON_A and INTERRUPT_FUEL_ON_B etc..

If you want the trains to have different behavior based on which train they are, isn't it natural that you would need different schedules for them? Unless you had the stop read the train ID and decide whether to activate the interrupt based on that. Each version could still be a train group applied to any number of trains following each set of interrupts.

For the refueling example, you could have two refueling stops at opposite ends of your network. Stops near the "FUEL_A" stop would provide the "A" signal, and stops near the "FUEL_B" stop would provide the "B" signal. You could include both A and B interrupts on all trains, even if they never go to the A-adjacent destinations and therefore never get sent to FUEL_A.

Similarly, you could have refueling stops for different lengths of trains. You make one schedule group for each length of train, and include just the interrupt for the appropriate fuel stop in each group. That interrupt can itself contain a circuit condition, so you can still indicate proximity to a particular fuel stop.

[Unknow0059]

Would be nice to finally get semi-automatic trains, and/or trains that automatically switch to manual if they have no stops.

[kwyntes]

This is neat, but it doesn't feel like a proper revision of the system to me. The main issue that makes it inflexible is the lack of a way to dynamically control train schedules, and while these changes do kind of touch on that, the system is ultimately still static in nature.

There's still no way to add a new type of station to the network and have the system work with that automatically. Instead, we need to update schedules to accommodate for the new station.

Fully dynamic cargo compositions (mixed cargo trains bringing in a specific combination of resources required by the destination) is still not viable.

Systems with ridiculous amounts of combinator circuitry exist that can (in theory at least, putting it into practice is an insane amount of work even by factorio standards IMO) route trains arbitrarily, but they're quite hacky in practice, need so much testing for edge cases that a QA team has to be hired and an automated unit testing framework has to be written, and - I- I think it's clear why this isn't very fun.

I really hope that this isn't too niche of a feature to be included in the base game, because I don't think there's a way to elegantly solve this with mods. I suppose it might just be me with a software background who wants to have my train system to work as if it were some kind of API/library one could install and have 'just work' without requiring new config everytime anything changes.

P.S. Allow trains pasted from blueprints to be put into automatic mode automatically! (and of course leave this as an option because we don't want *all* trains in automatic mode probably)

[Tertius]

So let's take the example given in the FFF: your train picks up an unknown resource from a generic loading station, then an interrupt triggers to tell the train that it is in fact carrying iron ore and should thus head to an iron ore depot (before then proceeding to an iron smelting station). Path-finding can ensure that the train heads to the nearest available iron ore depot... but it can't know anything about the associated iron smelting station. So if you have two iron smelting stations (with one nearby depot for each) where one smelting station is ore-starved and another is backed up, some trains will end up going to the wrong depot and then making a long trek over to the ore-starved smelting station. Do you see a clean way around this?

This problem already exist in 1.1. You can have only one depot for one collection of smelter stations nearby. If you have 2 groups of smelter stations, with one depot for each, you need 2 groups of trains - one that exclusively drives to depot#1 and subsequently a bunch smelter#1 stations, and another group that has a different schedule that drives to depot#2 and its bunch of smelter#2 stations.

In 2.0, you need to make sure you have enough trains, so that if the depot for the backed up station is full (over its train limit), additional trains will overflow to the other depot. You also need to make sure that a train waiting at one depot is only driving to the unloading stations nearby, not to some far away, just as in 1.1. I don't know how this is possible with 2.0 interrupts. Would be nice if we don't need different groups of trains as in 1.1. If it's possible to use circuit conditions in trigger conditions, we could identify the depot we're currently halting, so we could direct the train to only nearby smelter stations. Every group of smelter stations need their own name for this. In this case, we only need groups for the smelter stations, not for trains, not for depots and not for mines.

[SteelWolf300]

Nice additions!

One thing I would love to be added to the game is the ability to change the station in the scheduler without to have to recreate the whole schedule.

For example, let's say that I have configured my iron train, and I copy-paste it as a baseline for the copper train. It would be nice to be able to either rename the station (illustrated in red), either drag conditions between stops (illustrated in yellow, assuming I just added the copper station to the schedule), instead of having to add the new stations and all conditions.

edit-station.png (601.07 KiB) Viewed 3179 times

On the same note, it would be nice if we could duplicate interrupts, train groups, and even logistic/constant combinator groups as seen in FFF382. It would make it easy to "fork" any configuration.

[Tooster]

Nice additions!

One thing I would love to be added to the game is the ability to change the station in the scheduler without having to recreate the whole schedule.
[...]

Highly agreed, The inability to change the selected station and duplicate them makes creating and editing repetitive conditions really tedious. Sometimes when I missclick a train stop and realize later, I have to recreate all it's conditions for the new stop...

[Gemma]

aKJDGakjgadasglkj

[bcwhite]

Regarding use depots to accept empty trains when the providers all have trains waiting for open destinations...

It's highly unlikely that a train tries to depart a requester at the same moment that a provider suddenly can accept another train. Thus, wouldn't almost every delivery start at a depot and every train departing a requester go to a depot?

Can the interrupt that sends a train to a depot be cancelled if a desired destination becomes available?

[Lithane]

Really like that you've added train schedule groups, generally speaking you are always going to be working with a bunch of groups of trains with the same schedule in a large factory, it only makes sense for them to be grouped and all changed at once. I also like the way you are approaching more complicated train logic, it's simple to the extent of being user player friendly, yet it will allow people to make the very complicated systems they want from something like logistics trains as well, big win.

[main.psyhos]

IMO this makes LTN and Cybersyn almost irrelevant.

No, it dosn`t.
Train control is still flow-based, not request-based (like logistic drone network).
You still can not controll it throught circuit network (except for enable/disable entire station).
Automatic balancing is still imposible.
You still cannot use DEST station state in rules.

It is much better then 1.1 but still not sufficiently good.

[Freddy404]

Two things just occurred to me, that would be awesome for generic train schedules:

1. Wildcard matching between interrupt conditions and station names. So instead of separate interrupts for 'if [iron plate] > 0, goto [iron plate] unload' and 'if [copper plate] > 0, goto [copper plate] unload' we could just have a generic 'if [any] > 0, goto [any] unload'.
2. A way to switch train stop names from the circuit network. This would enable generic unload stations that call in the specific resource they need by renaming themselves. The Mod Stringy Train Stops does this in a relatively complicated way. I think for vanilla having a numbered list in the stop configuration, which gets indexed with a configurable signal would be easier to understand and entirely sufficient.

[Hares]

Nice additions!

One thing I would love to be added to the game is the ability to change the station in the scheduler without to have to recreate the whole schedule.

For example, let's say that I have configured my iron train, and I copy-paste it as a baseline for the copper train. It would be nice to be able to either rename the station (illustrated in red), either drag conditions between stops (illustrated in yellow, assuming I just added the copper station to the schedule), instead of having to add the new stations and all conditions.
edit-station.png

On the same note, it would be nice if we could duplicate interrupts, train groups, and even logistic/constant combinator groups as seen in FFF382. It would make it easy to "fork" any configuration.

YES, PLEASE

[picklock]

...
One thing I would love to be added to the game is the ability to change the station in the scheduler without to have to recreate the whole schedule.

...

I would also like to see this implemented.

[Abarel]

IMO this makes LTN and Cybersyn almost irrelevant.

No, it dosn`t.
Train control is still flow-based, not request-based (like logistic drone network).
[...]
It is much better then 1.1 but still not sufficiently good.

I agree with main.psyhos, LTN Cybersyn and other train scheduling systems send trains when there is a request and a supplier; the trigger is the request.
Still have not seen everything about the new changes for vanilla trains, but from what we already saw, it is flow-based, not request-based; that is, a train will be sent whenever a supplier have room for another train, independently of if there are requesters for the materials offered.
The new features are a good improvement, and I like it, but it cannot replace a per request scheduling system just with what we have already seen.

...

How can I now limit the number of trains loaded with the same type of ore?

I would prefer to use it as an exception system, to send trains to a depot just if something weird happens, not as my normal way of work.

...

For me, train jobs are divided in 3 categories, with different compositions and schedules:
1- Big trains, deliverying raw materials, like ores. Usually at least 2 trains for every consumer (like a smeltery), so a train can be unloading at the consumer while another one or more are travelling or waiting at the producers.
2- Medium and small size trains, deliverying intermediates and finished products. I use different approaches (vanilla, different mods...), but usually at least 1 train for every producer.
3- Special trains of different sizes but mostly small trains, for the different services, like fuel supply, perimeter defense supplies, builder trains, artillery, or mods' special stuff (like air filters for pollution).

Without a scheduling system, my trains for all categories will almost always wait at the producers, waiting for a requester to open the station (increase the limit above zero, or the currently satisfied amount). I usually have more than one producer for the same item, specially mines for ores, so most stations will be open waiting for a train to come, as long as the assigned train/s are busy deliverying or just waiting full of materials at other producers.


Train groups, interrupts and any other improvement will be welcome, and probably I will try generic schedules for some trains, but I doubt that it can fully replace a per request scheduling system.
I reserve my final decision about generic schedules until I can use it myself, but until now it seems to me like another tool, not a definitive solution for everything.

[Freddy404]

Train groups, interrupts and any other improvement will be welcome, and probably I will try generic schedules for some trains, but I doubt that it can fully replace a per request scheduling system.
I reserve my final decision about generic schedules until I can use it myself, but until now it seems to me like another tool, not a definitive solution for everything.

In my opinion, that's in the spirit of the game, providing tools, not solutions. As presented, it already makes it far easier to implement a request-based system with just train schedules and circuits. And maybe interrupts can also get conditions like 'reservation available at station <name>' - or even just a way to test current target, which combined with checking for empty could provide a roundabout way to implement this.

[kwyntes]

Train groups, interrupts and any other improvement will be welcome, and probably I will try generic schedules for some trains, but I doubt that it can fully replace a per request scheduling system.
I reserve my final decision about generic schedules until I can use it myself, but until now it seems to me like another tool, not a definitive solution for everything.

In my opinion, that's in the spirit of the game, providing tools, not solutions. As presented, it already makes it far easier to implement a request-based system with just train schedules and circuits. And maybe interrupts can also get conditions like 'reservation available at station <name>' - or even just a way to test current target, which combined with checking for empty could provide a roundabout way to implement this.

Interestingly enough, no. This isn't even a tool. If you want to make a fully circuit-controlled train system (Knightelite's LTN in vanilla), these additions won't change anything. The issue is purely in the static nature of train schedules. It's like trying to program a computer that doesn't have any RAM nor storage.

Sure, there's slightly more control now, even from circuits, but apart from reading the fuel level, all of this was already possible in 1.1, just uglier. (You'd stack a lot of 'dummy' stations after each real station which you conditionally enable/disable to make the train skip through all of them in its schedule. Inelegant, yes, but interrupts are equally static.)