Friday Facts #389 - Train control improvements

[mcmase]

Wow, this weeks post was awesome! I must confess that even with the train schedules that were implemented for 1.0, I didn't use trains much. Maybe because I never sank enough time into a single world where max size/richness ore patches wouldn't be enough to sustain my base, but I think also in part to the issues that are being addressed here, where adding trains or adjusting the network required hunting down specific types of trains and really a lot of running around with sometimes less obvious benefit, or at least it seemed that way.

This post makes it seem like some of the cumbersome process will be so slimmed down that trains will be almost natural, instead of only being used when absolutely crucial. I love the bit about not having to add refueling to every stop, which I always did just to be safe! But that meant everywhere trains were going, logistics bots were flying all the way to carry fuel, and then might as well have just grabbed the item and brought it back anyway. This way, I can save time on trains, bots, and all logistics in general

But my very first thought after that was already stated in the post above:

Very cool! Something not mentioned that I think would really be an additional improvement on top of interrupts would be the ability to temporarily disable interrupts, or fully disable interrupts and only check them at specific points in a schedule.

For example, if you know that the refueling station is in a certain location, you may not want the train to check the fuel during some parts of its schedule which are particularly far away from it, since it would need to travel a lot to get there, and to get back again, wasting time and occupying the tracks more than necessary.

This seems crucial to me as well, so we don't have trains at their furthest point take a huge detour back to the refueling station. Yes, we could build a few refueling stations around the world but seems best to have a central one near all your drop offs and if a player can't ensure that trains will be refueled efficiently then we might as well stick with the old system.

Also this:

So I guess my question boils down to: Can I somehow make sure that when a train goes to pick up an item, it will be able to drop this item off somewhere?

Assuming that the interrupts have the same pseudocode system and logic the trigger should be able to have AND and OR logic (can't recall the others) in their conditionals. To me this seems obvious and essential as well. I suppose you could always fall back on circuit network but for me as a circuit newb I almost never use circuits and if a problem is so complex that circuits are required and I don't instantly know how to fix it then I just find a workaround. I've tried a few times to learn but never really enjoyed just reading the forums and none of my friends play this kind of game so I'm content to just ignore that part of the game for the most part. I think they mentioned somewhere before that circuits will be actually required in the expansion at some part however (in a very small way) but with no workaround at that might be interesting and make me learn a bit more but I could also see just searching up the solution and spamming it all over my base.

Anyway now I'm rambling, great post and hope the above two issues are a no-brainer with the new train logic.

[mcmase]

So we made it that interrupts are shared globally (identified by their name), and when you edit an interrupt it changes for all the trains with that interrupt. This made it much more convenient and less error prone.

I didn’t understand a little, if I add an interruption, then it is automatically applied to all trains or I can add it to one train, and then how, for example, with an existing station, select from the list?
although it seems to me that it’s the latter, otherwise it would be strange.

Also, I would like the ability to copy stations in lists, now when I rarely set up trains but need to copy a station either to the same train (but with a different station under the same conditions) or to another train but with a different schedule, I wonder if it is possible how to do this?

I think new interrupts are not added to all trains automatically. But When you add an interrupt, if another interrupt with the same name already exists on another train, they will merge with each other.

If you have a schedule called "Iron Delivery" that applies to 5 trains, then add a new interrupt to the "Iron Delivery" schedule, all 5 trains' schedules would be updated.

If you choose not to use master schedules and just write each train's schedule individually (like we do now), then presumably making changes would only affect the one. But I assume that if you're copy/pasting train schedules that automatically groups the trains under that master schedule, so really the whole thing should happen pretty automatically.

[ElderAxe]

I always try to have smarter trains in Vanilla without mods like LTN or similar.

These improvements are what i would ask to make it real.
Being able to read the train layout from station would be the frosting on the cake.

Let's say i'm gonna send a signal to a train to trigger interrupt for picking up iron ore. If we're using one type of depot for keeping idle trains, there is no way to know if the train has cargo wagons or fluid wagons.

About refuel stations: when i switch to an upper tier of fuel, i want all trains to switch to new fuel type to match their speeds.
Right now you cannot remove fuel from trains if you allow this, refuel station can unload other fuel types from trains while refueling it.

[Dial-up]

I think new interrupts are not added to all trains automatically. But When you add an interrupt, if another interrupt with the same name already exists on another train, they will merge with each other.

maybe, and, as I understand it, the list of interrupts is global and I doubt that it will be possible to add 1 more with the same name

[POPISowyNumer]

I admire the idea of making train schedules make more sense than they do in current vanilla, but in my honest opinion you should have done to LTN what you did to Space Exploration.

Hire its creator and seamlessly integrate the whole mod into 2.0.

[AileTheAlien]

Aaaaaarrrrrgggggghhhhh! I want to play 2.0 already! So many quality of life improvements! (And I'm definitely going to get the expansion too. XD )

[picklock]

And another FFF with long-awaited features. Thank you.

I like to use the trains in Factorio and especially the option to refuel only when needed is a relief for me when planning train routes. This makes some of my Bluepronts obsolete, but the implementation in the game is much better.

Another innovation that I would rather play today than tomorrow. Unfortunately, we still have to wait almost a year.

[Fiorra]

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.

With the fact that I interrupts are global, I think this point is a bit moot. Only one small update to one global interrupt to fix your whole network.

We will have separate train networks in SA (or mods, or even vanilla), possibly with different fuel per network depending on local resources.

During the early parts of the game, where fuel isn't cheap, I've often used mixed fuel networks. Use the good fuel when available, but fall back to the cheaper one when it gets low. I've had networks that provided different fuels at different parts of the network, simply due to local availability of coal or oil.

In those situations, the simple global "coal < 50" rule won't work. Complicated rules or multiple global interrupts are possible, but for a QoL feature, MJ would be simpler to use and more flexible: one rule per game, done. Remember that this isn't just for the veterans, it's also for new players just getting introduced to trains and signals and everything. There's a big barrier, and any simplification to lower that barrier is welcome.

As the reddit post points out, trains with multiple locomotives exist, including dual-headed trains. Uneven fuel consumption or fueling need to be dealt with. We aren't actually interested in the amount of fuel in the train, we're interested in the locomotive with the least amount of fuel remaining, and that could only be reported in MJ.

Very cool! Something not mentioned that I think would really be an additional improvement on top of interrupts would be the ability to temporarily disable interrupts, or fully disable interrupts and only check them at specific points in a schedule.

For example, if you know that the refueling station is in a certain location, you may not want the train to check the fuel during some parts of its schedule which are particularly far away from it, since it would need to travel a lot to get there, and to get back again, wasting time and occupying the tracks more than necessary.

According to the blog post, interrupts are only checked when leaving a station, not while already en route. At least for the simple "Pick up" -> "Drop off" schedules, the detour should be the same no matter when the interrupt is triggered.

If that's not enough, then with a bit of engineering, you can decide which stations your interrupt can trigger on. Re-read the blog post carefully, the hints are there.

A couple questions from previous FFF that crossed my mind - recycling machines are going to be a thing. How do they handle items with fluid components, like electric engines or blue circuits? I'm assuming the fluid is just lost to the aether? Also in regards to the quality mechanic, I recall that components can have quality, but can fluids as well?

IIRC that was answered by the devs on reddit. Fluids don't have quality (how would you mix them?), and recycling never returns them.

[Tertius]

There might be a problem with making universal trains.

Imagine I create one universal schedule with interrupt conditions for every kind of ore. The schedule/interrupts are defined in a way that whenever some mining station has enough ore available, one train is dispatched due to an interrupt and the ore picked up, then delivered to the corresponding ore delivery station.
For overflow trains and for reducing the latency between load+unload, I also define an interrupt for a depot, so if the delivery station is currently full, the train goes into the depot for full trains.

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

Reason: imagine I have a bunch of coal mines but almost no coal consumers, so whenever a coal mine is full and a train is dispatched for pickup, this train will end up in the depot. Sooner or later every train will end up filled with coal, waiting either in the mine or in the depot, and no trains are available for the metal ores of high demand. How can this be solved? Which limits can be applied to avoid this case? Or in general: is there a solution for this? A possible solution would probably be some special interrupt condition that's able to count the number of trains loaded with some material, so it can make the interrupt condition not trigger, if there are more than xx trains loaded with the same material.

[Kadet123]

Very cool! Something not mentioned that I think would really be an additional improvement on top of interrupts would be the ability to temporarily disable interrupts, or fully disable interrupts and only check them at specific points in a schedule.

For example, if you know that the refueling station is in a certain location, you may not want the train to check the fuel during some parts of its schedule which are particularly far away from it, since it would need to travel a lot to get there, and to get back again, wasting time and occupying the tracks more than necessary.

As another idea, you could have specific "interrupts" not be general for the entire schedule but instead only set to be checked at specific points in the schedule, to create a way to make trains conditionally go to some stations with minimal changes to the interrupt system. In other words, when you reach a certain point in the schedule, there's an "interrupt stop" which checks some conditions and decides whether to take it. Once that point is passed, the interrupt stop(s) is no longer available until the train does a complete round of stops and gets back at that point.

This makes some valid points. It might a good addition to have conditions on normal stops like the FFF's conditions on interrupt stops. That way a train can go to a loading station, for certain proceed straight to its delivery station, and only then check if it needs fuel. To give some control over when the interrupt can kick in (except in this case, its not an interrupt, its a normal schedule slot with skip condition).

Edit: Though, thinking about it more, the interrupt conditions I guess could have an extra condition like "Empty AND Fuel < something" then this may not be a problem after all. Then the interrupt woudn't kick in during the provider->requester part of the schedule.

[iestynne]

This is truly amazing. I will be extremely happy to rework all my megabase blueprints! I suspect Nilaus will be a big fan of this one too

One question: when switching a train from group schedule X to group schedule Y, could the switchover be deferred until schedule X is complete? (so the train would have an internal state "I want to switch to schedule Y", which it would apply at the bottom of schedule X) This way we can quickly switch a bunch of trains between schedules, without having to manually inspect each train to determine if it's currently carrying cargo (or anything that could potentially mess up the new schedule).

Another thought: to maximize efficiency, you ideally want a train to set off towards a target station *before* that station is ready to receive the train, and for the train to arrive immediately after the station limit increases by 1... but as you pointed out, you don't want a new train to arrive too early otherwise it could block the entrance area, and this kind of timing is impractical to predict in all cases. I was wondering if it might be possible to adapt the depot concept to deal with this by implementing an airplane-style 'holding pattern' behaviour, whereby trains head towards their target station (by using a schedule option that says train reservations may exceed the station limit by exactly 1 - which triggers a new type of interrupt when activated) and then circle around nearby until the station limit increments. But with generic station names, there's a missing feature here: you need each station to be paired with its *closest* depot (or maybe paired by color, to provide manual control), so that a train can hang out 'nearby' while waiting for the target station limit to increment, so it can then quickly swoop in once it does.

Generally it seems like the path-finding capability of the train system is under-utilized in the current model... perhaps there's a nice elegant way to make better use of it by decoupling it from explicit schedules. Maybe a simpler alternative to pairing stations with depots would be to use 'station limit chaining', whereby a loading station can increment the limit of the nearest non-full depot station (so depots would need to specify a 'max limit' value) to ensure that trains are ready and waiting nearby. So instead of "search for 'nearest available train' and tell it to reserve the station", it would "search for 'nearest non-full depot' and tell it to increment its limit". LOL, this is starting to sound like an event-driven messaging system

[Pepfof]

Auto-colored trains feel a little immersion-breaking to me. Since we're now in the space age, can't they have something like RGB LED strips or a bunch of RGB lamps on them? Perhaps only on the ones that have the change color option set... The lamps could then display the destination color, while the body of the train would remain the same?

[FuryoftheStars]

Love it! \o/

[Trific]

So many mods blown away!

I presently refuel at each pickup stop. A special refueling train brings in fuel, which travels to each pickup rack by belt where it can refuel each train as it is loading cargo. Changing fuels is just a matter of telling the refueling train (or trains in a large base) to pickup fuel at a different place. I'm not sure I would change that with the new system.

As for the logistic improvements, I'm not seeing how this would solve what is my biggest problem right now, and that is that a train, on it's way to deliver cargo to a distant location, hits a repath point and ends up switching its destination to a closer station that opened while it was en route. If this happens repeatedly, the distant location can end up starving of material. Normally, just having enough supply and enough trains fixes the issue, but sometimes there is a huge burst of demand. Each facility has a buffer that would carry it through that burst, and trains dispatch in a flurry to refill the buffers, but the trains going to distant stations often end up repathing to closer in stations, and the distant station ends up starving because trains repeatedly dispatch to it, but then repath closer. Using station priorities to fix this has been discussed in the past, and would also help deal with the issue of byproducts in many overhaul mods. I don't see how these improvements (awesome though they are) will help these situations.

[V0ID]

The train group feature is nice. This way I can find my "personal" locomotive more easily. (Always wished to have a feature like in RTS, where you can save units with the number keys. This comes close )

[Agamemnon]

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.

YES! I tried to design a train depot with circuit logic to distribute coal across the base dynamically. This was one of the issues I ran into.

[pleegwat]

Very cool! Something not mentioned that I think would really be an additional improvement on top of interrupts would be the ability to temporarily disable interrupts, or fully disable interrupts and only check them at specific points in a schedule.

For example, if you know that the refueling station is in a certain location, you may not want the train to check the fuel during some parts of its schedule which are particularly far away from it, since it would need to travel a lot to get there, and to get back again, wasting time and occupying the tracks more than necessary.

As another idea, you could have specific "interrupts" not be general for the entire schedule but instead only set to be checked at specific points in the schedule, to create a way to make trains conditionally go to some stations with minimal changes to the interrupt system. In other words, when you reach a certain point in the schedule, there's an "interrupt stop" which checks some conditions and decides whether to take it. Once that point is passed, the interrupt stop(s) is no longer available until the train does a complete round of stops and gets back at that point.

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

[BrainlessTeddy]

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.

Very specifc and direct question, so I'm here to answer you, yes, I had that problem too. And I am really glad you noticed.

[Terrahertz]

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

I wondered about that too, but the solution is seen in the screenshots: It only enters the depot if its cargo is empty, this means the train waits at, for instance, a mine for a drop location to become available. So the stations train limit makes sure not all your trains get filled with iron ore.

[Tertius]

Another thought: to maximize efficiency, you ideally want a train to set off towards a target station *before* that station is ready to receive the train, and for the train to arrive immediately after the station limit increases by 1... but as you pointed out, you don't want a new train to arrive too early otherwise it could block the entrance area

I am currently (game version 1.1) using depots for this. It's like an extended waiting area in the outskirts of the city, with the destination in the city itself, where there is only minimal space for waiting areas.

The depot has 8 waiting areas for example, so it gets a train limit of 8. Trains with long journeys, ore trains for example, have a schedule of 4 stations: outgoing depot, ore mine, incoming depot, smelter station. The outgoing depot is far away outside the main base, near the ore mines. The incoming depot is within the main base, near to the smelters. An empty train first travels to the outgoing depot, which has many waiting areas and a corresponding high train limit. Whenever a mine has ore, one train is released and reaches the ore mine fast. Then it immediately travels the long way back, to the incoming depot, which also has many waiting areas and a corresponding high train limit. It doesn't matter if some smelter station is free or not, only the space in the incoming depot matters.

If a smelter does need an ore train, it only has to travel from the incoming depot. This way the incoming depot is filled independently from the fill state of the smelter stations, so there is never a long waiting time. It doesn't happen that a smelter station runs empty, because the train needs so much time to travel from the far away ore mine.

I guess the interrupts can help with creating better schedules for this concept.
But I don't see a point in holding patterns, manipulating station limits, and let trains wait somewhere on the tracks. This will have unpredictable results and just congest your tracks and probably provoke deadlocks and blocks.
This holding area can simply be the depot for the incoming trains, visited on an interrupt if the regular delivery station doesn't have a free slot currently. By using a dedicated depot with waiting areas, the trains will not congest the main tracks.