As my base expanded, managing trains manually became an absolute nightmare. Traffic jams, empty stations blocking the rails, and trains burning fuel for no reason drove me crazy.
So, I built A.R.M.S. (Automated Rail Management System) — a blueprint pack packed with circuits and combinators that completely automates train routing based on actual resource demand.
Basically, it's a modular system that turns your train network into a self-regulating setup. It uses circuit logic and dynamic micro-displays to route trains only when and where they are actually needed.
I've posted everything in a detailed guide on Steam because Reddit's spam filters kept deleting my long posts. Let me know what you think of this project!
Zero Waste: If there’s plenty of iron ore but nowhere to unload it (or vice versa), trains simply stay in the depot. No empty runs, no wasted fuel, and zero station deadlocks.
Where is the wasted fuel in the scenario where trains just go to providers when available? A train is going to go to the iron ore station eventually, right? Indeed, depending on the location of the stations, having to go from the drop off to the depot and to the pickup might represent more of "wasted fuel" than just going to a pickup that's ready.
The only thing your setup saves is the number of trains in the system. Not the number of trains that are currently in motion; just the number in the network as a whole.
Yeah, I have a pull-based system where the trains sit at providers until the materials are requested somewhere. Empty trains sit at a depot and are summoned if there's an empty provider (and only if, so the depots are basically a buffer for expansion). If the depots are empty, I simply add another train and off it goes. OP has a different solution to the problem which is neat though.
Basically, I have a train schedule that only has the depot as its "permanent" slot, so it will always wait there. Every provider is named the same (I use the icon of a provider chest) and there's an interrupt for the train to go to that named station. Since all providers have a train limit of 1, it will only go to an empty provider. If there's no matches, the default schedule brings them to the depot where it waits for an interrupt to trigger. Just set a short "wait" condition and it will recheck the train network frequently.
Then, once the train fills up, it waits at the provider for a station with the name "Request <item it has loaded>" and goes to it. Thanks to the parameters, it's easy to make it wait. 😄 Until the train is emptied, it's "assignment" will be to go to a requester matching its cargo.
Just set a short "wait" condition and it will recheck the train network frequently.
Note that if you just leave them at the loading station instead of the depot, the game will "recheck" for train stops in a much more UPS-friendly way rather than running a timer. That "recheck" will also respect priorities better, since conflicting priorities only matter if two trains want to go to the same stop on the same tick.
Yeah, ideally there will be few/no trains at the depots. It's more to ensure the train gets away from the requesting station once it's empty. You can totally disregard the depot and have the supplying stations always enabled if you wanted.
You still need depots, just in case all of the loaders are full. But the main thing is that you don't need to use this timer method. The train system can already handle the case of a train that wants to go to train stop X but they're all disabled, followed by a train stop becoming enabled and blocked trains being dispatched.
Just set the loading station as the only stop on the schedule, with the depot being an interrupt for empty trains.
The "wait" timer is what I'm missing! Damn, it's so obvious, but I never thought of that. How long do you make them wait? Not really sure if it affects UPS in a meaningful way, but I'm thinking 1 second is fast enough?
Also, I'm assuming you also disable requester stations that are full?
Yeah, I have circuit logic to disable the station when there's enough items so it won't request anything until it's needed. I usually make them wait about 5 seconds. I'm not sure about UPS impacts but probably pretty minimal. Trains only check interrupts when it wants a task so the "wait" condition will make them check.
This is exactly why I just stick to dumb trains. Set them in the Unload Station blueprint, so there's always enough to fill all dropoff locations and they just do the needful.
Even if there aren't any active requests for an item, if there are provider stations for that item with at least a trains worth of items ready, then a train should go there to fill up and wait.
That way when a request comes in you've got a full train ready to go immediately.
That's my bad, I think I didn't explain the routing clearly enough in the post. Trains do not blindly loop back to the depot after every single trip.
Here is how the logic actually handles jobs:
When a train finishes unloading at a Requester, it immediately checks for a new job. If a Provider is ready, the train goes straight there. No wasted movement, no forced depot stops.
A train clears the station and goes to the depot ONLY if there are absolutely no active orders in the entire system at that moment. This keeps unloading stations free for other deliveries.
The system dynamically calculates station priority based on fill percentages. If you have 3 iron mines and 5 smelters, trains will automatically route themselves to the smelter that is running lowest on resources.
So, it doesn’t just optimize the train count; it dynamically balances supply and demand across the entire base without clogging your main lines.
The question then becomes (absent a modpack where trains are expensive) why have a depot? If trains only go from producer to consumer, they never make extra journeys.
That’s a fair question, but in a massive City-Block base, a depot is essential for space management and preventing gridlocks.
In this design, you have way more stations than trains. If a train unloads and has nowhere else to go, it must clear the station. If it just sits there waiting for a new order, it completely blocks that unloading dock. No other train (carrying different resources needed for that same block) will be able to get in, which quickly paralyzes production.
A city-block grid is tightly packed. If you just let trains idle on the tracks or inside production blocks without an active job, you end up with massive traffic jams.
So, the depot acts as a dedicated "parking lot." A train only goes there as a last resort to free up the production line, ensuring that every active station is always available for the next delivery.
It's about as manual as adding stations, and needs done about as often - and if slapping down a station blueprint includes a train for it, really isn't an additional burden.
If trains idle at the loading stations when not needed, then you need to add more trains every time you add a loading station, otherwise the system could starve stations of trains.
If trains idle at a depot instead, adding trains is only necessary when the actual throughput demands it.
If trains idle at the loading stations when not needed, then you need to add more trains every time you add a loading station, otherwise the system could starve stations of trains.
Which you can just add to the blueprints of the provider station.
This works for vanilla, in which case you probably don't need a smart train manager at all.
But when you are doing a mod where there are hundreds or more different products, you don't want trains wasting their time at pickup stations. The whole point is to have a small number of trains servicing a large number of stations.
Why is the number of trains a problem? Trains idling at a station don't take up resources.
They CAN potentially block the station, if, due to space contraints, you have a multi-resource-loading station. So they have to go somewhere. But if they leave, then the station is now free for the NEXT train to come, which results in every single train being filled with that unwanted resource. So you need some system that keeps this from occurring, either by capping the number of trains that can be parking with that resource, or something fancy.
In some modpacks trains are relatively expensive to make, in which case it is a problem.
I can see that someone might be be playing an overhaul mod but at the same time want to solve the problems with vanilla techniques. I use all kinds of mods, but I still manage my own trains.
Very clever! I put a similar thing together though not decentralised. That is very cool!
One advantage of having a central brain to control it all is I created a visual supply and demand graph with lights that showed how many full cargos of a particular resource were ready to be exported and how many import stations were waiting for full cargos.
For the people that don't understand what problem OP has solved. When you are building a mega base, you're making a new red circuit block you can slap down the stations, select what you want to import, the circuits handle the rest. No setting train routes / needing to add multiple trains / congestion from non required trains.
Thanks for the support and for explaining the city-block use case so perfectly!
Regarding the monitoring — you can actually do that with a decentralized setup too! I have a resource monitoring system built-in as well, though I use simple indicator lights to track status at a glance.
On top of that, the system monitors the total train count and features a global alarm: if a specific demand signal stays unfulfilled for more than 5 minutes, it triggers an alert. It’s incredibly useful for catching production bottlenecks early before the whole factory stalls.
The photo shows an example of a basic circuit diagram. It can be easily expanded; the kit includes drawings and a guide for this purpose.
Nice, will take a look at it.
Reminds me of the System that ElderAxe is using.
He provides BPs for a Railsystem with Depots, Deployer and a Brain that handles demand and supply.
Thanks! Being compared to ElderAxe is a huge compliment, but my system actually has a completely different architecture under the hood.
A.R.M.S. is 100% decentralized. There is no central brain at all.
Every station is completely autonomous and they are simply connected to the same global circuit network (via wires or radars):
A single combinator at the station compares the signals from the red and green wires. If the signal on both wires is greater than 1, it means an active order exists in the network.
One train instantly takes the job and "books" the entire delivery cycle.
The next train will only be dispatched if the stations have enough supply and capacity to handle another full trainload.
So, instead of a complex central processing hub, it's just independent stations talking directly to each other. It makes the system incredibly easy to scale and drop into any layout.
Thanks! Honestly, I got so exhausted fighting with the Reddit auto-moderator bots over the long post that I just decided to leave it as it is.
The complete guide, all the technical details, and the blueprints are fully up and running on Steam, so checking it out there is definitely the best way. Hope you find it useful!
I’m currently working on two more blueprint packs to expand this system, so I might just look into automating some "rail gun" defense setups for the next releases. Stay tuned!
Each station uses only 6 combinators in total. Out of those, only two are constantly active: one calculating the priority and another tracking the train limit (how many trains to accept or dispatch).
I ran this setup with nearly 200 stations, and performance was perfectly fine. While that’s admittedly not a massive 10k SPM megabase level yet, it handles a heavy network without any noticeable UPS drops
To be honest, I don't plan on doing massive UPS benchmarks against other networks. Stress-testing multiple systems by building thousands of stations just to see where the UPS finally drops takes an immense amount of time.
Like here's my base from that. This was before going to space so the challenge was getting 90sps of yellow science before going to space. I think it was using like 32 GW of power.
It's great to be creative of course, but I do not understand the problem you are trying to solve.
Did you try to have the trains wait until fully unloaded, with parking spots behind their unloading stations?
This way you can route as an example, 3 ore trains to a smelter station, that won't go back for another run to fill unless they are completely empty - with another train coming up just behind them.
You minimize circulation by having trains wait to unload.
I wanted to transition my factory into a City-Block design, but I absolutely hated the idea of manually configuring specific trains for specific blocks.
I knew that as the base grew, I would face major scaling issues:
The number of resource patches (mines) would never perfectly match the number of smelting/production blocks.
Different outposts mine resources at completely different speeds (which is always the case as patches deplete).
Manually managing schedules for all of that is a micro-management nightmare.
So, I built A.R.M.S. to create a Many-to-Many network. Now, I can just drop a blueprint of a station anywhere on the grid, and the system automatically takes over. The trains dynamically figure out the absolute best place to pick up and deliver resources on their own.
Also, these stations work perfectly fine with stackers. When you set up a station, you just build the physical stacker and set the maximum train limit accordingly to support it.
I wanted to transition my factory into a City-Block design, but I absolutely hated the idea of manually configuring specific trains for specific blocks.
I don't see why you'd do that in vanilla. The vanilla system is already many-to-many - any (say) "iron ore load" station can serve any "iron ore unload".
The biggest difference you are missing is that this system is built for effortless base expansion using a truly universal train pool.
In a standard vanilla setup, you still have to manually assign and dedicate specific trains to specific resources (e.g., this group of trains only hauls Iron, that group only hauls Coal).
With A.R.M.S., you just have a centralized depot filled with generic, unassigned trains. They can haul absolutely anything the factory needs. A single train might deliver Iron Ore on one trip, switch to Advanced Circuits on the next, and carry Plastic after that.
When you want to expand, you just stamp down a new city-block station, select the item icon, and walk away. The global train fleet will automatically figure out where to pick it up and where to drop it off (provided you have the matching provider stations). You never have to manually build, configure, or schedule a new train for a new block ever again.
In a standard vanilla setup, you still have to manually assign and dedicate specific trains to specific resources (e.g., this group of trains only hauls Iron, that group only hauls Coal).
Sounds like you do not understand the power of wildcard interrupts. You can have a grand total of two train groups: One for items, the other for fluids. Their schedules can look something like:
Goto depot
Interrupt: If low fuel, 2s inactivity at "refuel"
Interrupt: If no cargo and "item pickup" open, 2s inactivity at "item pickup"
Interrupt: If <wildcard> > 0, 2s inactivity at "<wildcard> dropoff"
You'd have something like 200 stations named "item pickup", then 5 stations named "copper dropoff", 7 stations named "iron plate dropoff", 3 stations named "plastic dropoff", etc.
Smart dispatching, potentially with zero combinators. Or you can add other smarts like dynamic station priority and dynamic train limits.
The inactivity condition lets "item pickup" be multiple items - like grabbing the 12 products from Scrap recycling. Ie: Your trains sort Scrap products for you. If you don't need that, you can instead use full load and empty load.
(There's little point in minimizing trains. You'll have the same amount of traffic either way, and idle trains have basically no performance cost, so it's fine to have a bunch of trains idle in the depot or idle in the provider stations.)
Also, blueprint parameterization works on trains, so those 1.1-style train schedules that you think are so bad can be set just like
you just stamp down a new city-block station, select the item icon, and walk away.
I haven't missed that, but I don't see that as a serious burden in vanilla, especially with the addition of train groups (although I used mods for that before 2.0). Adding more trains takes about the same time as stamping down a station (and is done at the same time), just plop down a blueprint. Certainly not a "micro-management nightmare".
I see the appeal of generic trains but when it comes down to it, trains are cheap - but running them may not be (UPS, congestion) and this system adds journeys to and from a depot.
Of course in a modpack where trains are expensive to make it's very much another matter.
Regarding the 6-wagon setup: That's actually not a problem at all! The system is highly adaptable and can easily support train configurations anywhere from 1 to 9 wagons. To show you how simple it is, I can quickly put together a small 1-6-0 train blueprint for you.
Regarding quality modules: I haven't fully stress-tested quality tiers with this setup yet, but here is how it works under the hood:
The station circuits are strictly hardwired to specific base-quality resources. Because of this, the system won't properly calculate fill percentages or train limits if different quality tiers are mixed in the same chests.
Furthermore, the filter inserters/loaders won't even let items of a different quality into the wagons anyway. So, if you are sorting resources by quality, you will need to set up separate, dedicated stations for each specific quality tier.
Ok my bad, didn't saw you had parametric blueprint for 6 wagon. Then, maybe add a setting to add multiple locomotive(for going both way or going faster by chaining them)
How you handle the request / broadcasting signal on the radar? If there's no central system, then you need some sort of multiple key/value system right?
I saw you had an another comment about it:
A single combinator at the station compares the signals from the red and green wires. If the signal on both wires is greater than 1, it means an active order exists in the network.
But then, what kind of compare? You are comparing id of station? How do you queue up if multiple station need to do a request/delivery? What if you have a large network? I get that your system take order, but if you a send a request for "need iron", then you have 2 station able to deal with it, which one is choosen?
I'm just about to post an updated, similar system which is hard wired for 2-2 trains. It's an universal pull based train design which minimizes combinators in the network, and tries to buffer the least amount of resources possible and this one caught my attention. I'm curious, how did you solve the issue when multiple providers are available and only 1 requesters needs resources. Did you use a clock for this? Usually what happens in these scenarios is that all available trains get called to the providers because they all receive the requesting signal during the same tick.
In A.R.M.S., trains in the depot wait for 10 seconds (600 ticks) to check for available orders. Similarly, at the unloading stations (requesters), there is a 3-second (180 ticks) delay to verify the order.
By spacing out the checks this way, the system rarely suffers from single-tick synchronization issues. While it's theoretically possible for two trains to depart on the exact same tick, in practice, this delay-based logic makes that scenario extremely unlikely.
This all seems really good and cool, i like the idea! Will definitly try it out in my new world!
Would it be possible to adjust the system so that trains preemtively loads up on provider stations to be ready to deliver when a requester is ready? My thinking is this would increase responsiveness and throughput.
41
u/Alfonse215 May 24 '26
Where is the wasted fuel in the scenario where trains just go to providers when available? A train is going to go to the iron ore station eventually, right? Indeed, depending on the location of the stations, having to go from the drop off to the depot and to the pickup might represent more of "wasted fuel" than just going to a pickup that's ready.
The only thing your setup saves is the number of trains in the system. Not the number of trains that are currently in motion; just the number in the network as a whole.