Friday Facts #389 - Train control improvements

[svalorzen]

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.

Schedule yes, definitely. But the entire point of global interrupts is that interrupts are supposed to be written once, and be reusable, so if you can edit them once and the change applied across schedules. If you start to need an individual interrupt for each schedule, this mechanism is worthless.

For a stupid simple example, suppose you have a fuel station just east of the central hub, and two trains; one does west<->hub, the other hub<->east. Ideally the first train would look for the fuel station when around the hub, while the other would do the opposite. Because of this, you'd need to trigger their refueling using different interrupts, which defeats the purpose of a generic "go to refuel station".

Now please don't get me wrong, this is a stupid example and could probably be easily worked around, but hopefully you can see how this types of situations could come up with other things. My point is that being able to add a little bit more configuration to the proposed interrupts would allow for a hell lot more of flexibility when it's needed. Ultimately train schedules are on the path of becoming some sort of programming language, so stopping just short of allowing this additional option (because as far as the post showed all the required pieces are essentially already there) seems a bit weird. Maybe my suggested approach is not the optimal and just having conditional stations might work just as well; I was just trying to show why we are really close to be able to do this kind of stuff and would be nice to be able to.

[Qon]

P.S. Allow trains pasted from blueprints to be put into automatic mode automatically!

If only there was a mod for that by the best modder.
(enable/disable not yet available)

[bmmtstb]

(Written without reading all 6 pages before me...)

Thanks! Finally getting rid of mega-base (near) mandatory Train-refueling mods. After seeing the logistic groups I was wondering whether those were also possible for trains.

"I would be interested to know if other people encountered this problem in 1.1 as well."
-> Well. In my opinion it depends on the design of the trains / rail-network. Single headed trains can leave the station in most cases without issues by at least half a train-length before moving onto the main line. Double-Headed might get blocked by incoming trains. With the correct signalling this shouldn't be an issue though.
For single-headed this is solved by having a one train space of rail reserved in front of the station and one (or more) behind. So the train can leave the station for sure if it is empty / full.
I had deadlocks, most because somewhere one single signal was miss configured. Or there were just too many trains in a tiny area.

• much love for train depots <3
• +1 to condition for fuel value based interrupts
• +1 for train stop priorities (possibly circuit based...)
• After improving the robot behaviors, is train behavior already implemented? I have the feeling that sometimes not the "nearest" train is used, even though it is available.
• What about creating new Trains based on circuit conditions? With the logistic groups everywhere, this should be manageable.
• For the Depot a waiting condition like "until needed" would be nice. The 30sec inactivity just sounds wrong for automation.
• Can a train be in multiple train groups? With the mentioned general purpose ore-to-smelter-trains, I feel that I want to have the train be part of the "iron ore", "copper ore", "stone ore" groups at the same time...?
• Even though I personally don't have a problem with trains color based on target, I think a group based color would be more understandable... (but this works iff every single train can only have one single group)

[Freddy404]

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.)

I have the feeling one of us is missing the forest for the trees, and I'm not sure who it is. I'm don't know of the top of my head all the features LTN/Cybersyn/Knightelite's offer. However, for intermediate generic trains, the new interrupts can handle by themselves:

• select destination based on cargo
• prioritize destinations, going for a lower-priority one if the higher is full or unreachable
• as an extension of the above, select between multiple complete schedules (although as presented, only availability of the first stop, not of later ones, can be tested)

To turn this from the push network presented in the FFF into a pull network

you 'just' need circuits to change the limit of provider stations depending on if their product is in demand. Of course, that can still be more or less complicated depending on what exactly you want to achieve. However, the interrupts being able to handle some prioritization and schedule selection should make this quite a bit easier than now, even with e.g. prioritizing one group of stations over the other.

.

Of course, you're entirely right there's some kind of state memory missing for fully programmable trains - for some common cases, there are some easy workarounds, like testing for cargo, or having the current station emit a specific signal you test for. But that'll only get you so far.

Also, about current solutions disabling train stops: I remember reading somewhere that train stops can't be disabled anymore in 2.0. So from a certain perspective, interrupts are a more elegant, more beginner-friendly replacement for mucking around with conditionally enabled stops.

[bluewilson]

For every FFF, some mods are suddenly considered obsolete, and in some cases, the change is identical to what a mod does. Though, when changes like these occur, I catch myself thinking: "Oh, how will the modders exploit this for even more amazing features?". I do expect and hope that Wube will expand the API accordingly, we are so lucky to have such a strong modding community in addition to a solid base game.

[robot256]

Schedule yes, definitely. But the entire point of global interrupts is that interrupts are supposed to be written once, and be reusable, so if you can edit them once and the change applied across schedules. If you start to need an individual interrupt for each schedule, this mechanism is worthless.

For a stupid simple example, suppose you have a fuel station just east of the central hub, and two trains; one does west<->hub, the other hub<->east. Ideally the first train would look for the fuel station when around the hub, while the other would do the opposite. Because of this, you'd need to trigger their refueling using different interrupts, which defeats the purpose of a generic "go to refuel station".

Now please don't get me wrong, this is a stupid example and could probably be easily worked around, but hopefully you can see how this types of situations could come up with other things. My point is that being able to add a little bit more configuration to the proposed interrupts would allow for a hell lot more of flexibility when it's needed. Ultimately train schedules are on the path of becoming some sort of programming language, so stopping just short of allowing this additional option (because as far as the post showed all the required pieces are essentially already there) seems a bit weird. Maybe my suggested approach is not the optimal and just having conditional stations might work just as well; I was just trying to show why we are really close to be able to do this kind of stuff and would be nice to be able to.

Ah, I wasn't thinking so far ahead. It did occur to me that for a lot of more advanced purposes, the global interrupt list is going to get cluttered with entries that are only used in one train route. It would be great if you could choose whether a given interrupt is included in the global library. Even better would be if you could copy interrupts from the library into a schedule and then break the link, so you can save a template and modify it for certain trains.

[Raatle]

This is everything Ive ever wanted. Ive spent at least 300 hours on train controllers and this solves everything. Thankyou.

[Upserter]

Next planet prediction: a resource that decays rapidly once mined, meaning time is of the essence to get it to its destination. Thus calling for… assembler wagons! With interrupts that fire once the recipe is complete.

[Roxor128]

Any way to prioritise fuels?

If you're transitioning to a new fuel type, you'd want to be able to make the train work through everything other than the new one first, so as to use up all of the old ones. This could also be good for disposing of wood.

[Dixi]

I like the idea, but I disagree with naming. It should be called CONDITION not INTERRUPT.

When you initially invented interrupts as a way to refuel, it was working as interrupt in a fixed schedule just to go and refill. But for now, when whole railway transportation system logic can be made on conditions, calling this "interrupt" sounds wrong to me.
As I understand this new system, it will be quite logical just to have one loading or unloading station name in fixed part of train timetable and some conditions, either what to do if empty, or what to do if loaded with some cargo. More then that, having whole train system made on conditions, with empty fixed part, similar to LTN, looks possible.

Also mind, that in several posts in this thread different users use same word "CONDITION" to describe train behavior or/and possible scenarios of usage.

There is another question, that will likely be described in one of future FFF. Those space platforms, how they will travel and be controlled in megabase situation? Will they work as space trains?

[bragewizard]

Might be the best one yet

[FunMaker]

I really lile the idea to handle trains in a genericallier way and like the implemented way. But i miss something very essential for me what LTN brings to the place: Provider and Requester capabilities with multiple item types - i don't see how this is possible with this solution. Did i miss something (maybe there are some magic interrupts conditions?) Or is this just missing? I don't like to build 5-6 stations repetitively for a production line because i need 5-6 Input products. This takes too much space for something that is far away from reallity. This bothers me alot in classic vanilla and maybe 2.0 vanilla.

[Nosferatu]

You can make a requester station that sends a signal to tell the train what it should fetch next.
But if you need multiple trains to fullfil your stations needs tracking deliverys through combinator setups will be tricky.

And forget mixed trains

[jockeril]

This really is a big change - it transcends every thing possible so far in the game - I almost forgot how great it is to play Factorio and started wondering why I had so many hours registered in it and this reminded me - I love playing with your trains !

[robot256]

I really lile the idea to handle trains in a genericallier way and like the implemented way. But i miss something very essential for me what LTN brings to the place: Provider and Requester capabilities with multiple item types - i don't see how this is possible with this solution. Did i miss something (maybe there are some magic interrupts conditions?) Or is this just missing? I don't like to build 5-6 stations repetitively for a production line because i need 5-6 Input products. This takes too much space for something that is far away from reallity. This bothers me alot in classic vanilla and maybe 2.0 vanilla.

You're right. The generic train mechanic depends on using the circuit-controlled Train Limit to request trains, and it can't distinguish between different items with that single number. I've done things in the past with overlapping train stops on the same track, but the trains will be aligned differently.

[inetknght]

> The problem is that once the train decides to leave the station, it instantly clears the reservation of the train limit, while still physically blocking the stop. This lets another train start its journey toward the stop, while there might not be enough space to wait without blocking the mainline.

> So we fixed it, so the train will only give up its reservation once it leaves the block with the train stop. I would be interested to know if other people encountered this problem in 1.1 as well.

I also encountered this. I solved it by setting up logic circuits on the chests next to the trains and then enable/disable the station only if every buffer will accept one full load of stuff from the train wagon (for unloading trains) or will fill one full wagon (for loading trains). Then there's also balancers on the inputs and outputs so that each wagon's chests will drain or fill at the same rate. If some wagon's chests aren't ready then the input/output belts will disable until all wagons are ready or not.

[apriori]

Someone on Reddit suggested a condition that would test against remaining fuel Mj. This way you don't need to test for low specific fuel type(s). If fuel Mj is low, go refuel. If you change fuel type in the refueling station later on, the train doesn't even need to know.

I am also in favour of having such an option to choose from. Alternatively, you could just talk about fuel in general without specifying the fuel.

Universal refuel condition is not only...

Code: Select all

fuel(MJ) < 10

...but...

Code: Select all

fuel(coal) < 50 
AND fuel(rocket) < 10 
AND fuel(nuka) < 1 
AND etc.

...as well. Isn't it?

[Feather]

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.

Schedule yes, definitely. But the entire point of global interrupts is that interrupts are supposed to be written once, and be reusable, so if you can edit them once and the change applied across schedules. If you start to need an individual interrupt for each schedule, this mechanism is worthless.

For a stupid simple example, suppose you have a fuel station just east of the central hub, and two trains; one does west<->hub, the other hub<->east. Ideally the first train would look for the fuel station when around the hub, while the other would do the opposite. Because of this, you'd need to trigger their refueling using different interrupts, which defeats the purpose of a generic "go to refuel station".

Now please don't get me wrong, this is a stupid example and could probably be easily worked around, but hopefully you can see how this types of situations could come up with other things. My point is that being able to add a little bit more configuration to the proposed interrupts would allow for a hell lot more of flexibility when it's needed. Ultimately train schedules are on the path of becoming some sort of programming language, so stopping just short of allowing this additional option (because as far as the post showed all the required pieces are essentially already there) seems a bit weird. Maybe my suggested approach is not the optimal and just having conditional stations might work just as well; I was just trying to show why we are really close to be able to do this kind of stuff and would be nice to be able to.

I have a question. Why would you have two or more fuel stations that are named differently, instead of having a generic name for all of them? Or maybe I just misunderstood what you were saying in which case please clarify.

I read your original post and they're literally adding what you're asking for (I think), if not please clarify.

Interrupt in interrupt
Normally, when an interrupt is activated, other interrupts won't be able to interfere until it is finished. But in some specific cases, this is too limiting, so we added a another special interrupt condition, called "In interrupt". This allows the interrupt to trigger while another interrupt is in progress, which clears the original interrupt and replaces it with the new interrupt targets.

[Utoek]

...However, new improvements can confuse a beginner. Not because features are complex, but because most of them are not clear how you can use them. For example, "Interrupt in Interrupt", in your words, makes sense only on a specific planet, but some players are unlikely to even play with the Expansion

I like the idea, but I disagree with naming. It should be called CONDITION not INTERRUPT.

When you initially invented interrupts as a way to refuel, it was working as interrupt in a fixed schedule just to go and refill. But for now, when whole railway transportation system logic can be made on conditions, calling this "interrupt" sounds wrong to me. ... Also mind, that in several posts in this thread different users use same word "CONDITION" to describe train behavior or/and possible scenarios of usage.

It seems to me that there is a lot going on in this feature and a lot of elegance, simplicity, and capability built together. As perhaps suggested in the comments quoted, I think the problem is the naming domain used.

The name "interrupt" is probably logically elegant but, like many good programmer names, too abstract and confusing for someone to grasp on a first look. I suspect many players will not know what to do with this until they watch streamers build things with it (and the folks that do understand it quickly wouldn't miss anything if it was named in a more friendly way).

I think conditions (maybe "pre-conditions") better matches my user model, but I wonder what Sony, or Apple, or Freightliner would call this feature if they shipped it. Departure checks? Launch logic? (I'm not a marketing artist)

In terms of UI, I was pondering whether the block of active interrupts for a train should display in some form before the next schedule activity. Then it moves after the schedule activity when it starts and is sorted before the next schdule activity. This might visually demonstrate the evaluation precedence.

[Utoek]

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.

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

A crazy idea occurred to me to increase (not completely, but increase) the dynamisms provided by this system. What if we could add a combinator car to our trains. They could read, process, and re-emit the train's internal signals to provide logic to an interrupt. Maybe they would only re-process at interrupt time, limiting calculation cost. They could provide signal to allow a train to have multiple stocking levels for different types of cargo, and go back for a refill when they ran out of [shells|turrets|repair packs]. Maybe a flip-flop could be wired to create a tick counter, so that an interrupt was executed every 3 stops or similar. The interaction between onboard and external circuit networks could become interesting.