The problem: I want to use trains to replace large swaths of my spaghetti belts. If possible, I want there to be no belts, only trains outside of space platforms.
I'd like to do this in a "generic" way, where I don't have trains dedicated to specific products; they just move whatever needs to be moved at the time.
My solution: using the circuit network to enable/disable stations, and interrupts to keep the trains going in the right direction. Wires are free now, so it's not even that expensive to scale.
To accomplish this, I have a "global" green and red wire network. Red has unallocated stations with demand--so long as they need a product and there's no train already dedicated to picking up that product, the demand will be on the red wire.
Green wire is unallocated supply trains. If a train has stuff in it, and isn't on it's way to a station, the station it is resting at will push it's inventory onto the green network.
There are five types of stations: Pickup and Dropoff for liquids and items, plus a fuelling station. Pickup stations check the red wire, and enable if thye have enough stock to fill a demand that they see on the red wire. They also take their train count, multiplied by -1, and add it to the red wire to reflect a demand in process of being met. Additionally, pickup stations have a limit for how much they will load into a train, disabling their pumps/insterters once the limit is reached.
Dropoffs track their stockpiles and put a signal on the red line when stocks get too low, so long as they don't already have a train unloading. They stay disabled unless there is a signal on the green line that matches a good they demand.
Both station types took 4 combinators to implement this logic. At the same time, I'm betting I'm going to need depots to handle race conditions. Any particular station will only enable for a single tick, but it's still feasible that they're going to collide at some point and cause havoc. I'll have to put some combinators in depots to handle that when it happens.
The trains have an interrupt to go to pickup when it's not full; stay until idle. An interrupt to go to dropoff; stay until empty or idle. An interrupt to go to a refuel station for low fuel stock. Their schedule only has a single stop--the depot, where they wait for 1s.
Has anyone else designed around this with the new interrupt system? I'm new at circuit network logic, so I figure there's probably someone somewhere who's done this better than I have.
My attempt at generic stations
Re: My attempt at generic stations
With station train limit and the interrupt signal item from inventory you dont need any circuit signals.
Re: My attempt at generic stations
You might want to take a look at the below two videos. To me it looks pretty well tested and covering most (all?) of the edge cases that a n:n depot-based train setup might run into and it sounds like exactly what you want (based on the comments on youtube it's still not "perfect" but it's the best i've seen so far):
https://www.youtube.com/watch?v=EggDldJVggM
https://www.youtube.com/watch?v=rRGAVDndFwk
Re: My attempt at generic stations
Actually you're right; that would simplify the circuits a great deal. I could label pickup stations then and not have to rely on enabling/disabling them.
It would still need circuits to avoid stampedes, though. Something needs to remove the 'demand' from the line while the trains are picking up cargo, and dropoff stations need to selectively enable themselves based on what's currently shipping. This just cuts out all the station-enabling logic in pickup stations.
Re: My attempt at generic stations
Not even that.
If trains are sitting "idly" in pickup stations waiting for somewhere to drop off their stuff thats fine. Reducing response time improves throughput.
If more dropoff stations are open than you can currently supply that means your supply throughoput is bottlenecked and no kind of station disabling will magically make you produce more, so thats also fine.
And with 2.0 train interrupt groups being blueprintable you can drop down an additional 15 trains in 4 seconds and they will start up seamlessly on their own.
When I say you don't need any circuit signals I mean you don't need any circuit signals.
If trains are sitting "idly" in pickup stations waiting for somewhere to drop off their stuff thats fine. Reducing response time improves throughput.
If more dropoff stations are open than you can currently supply that means your supply throughoput is bottlenecked and no kind of station disabling will magically make you produce more, so thats also fine.
And with 2.0 train interrupt groups being blueprintable you can drop down an additional 15 trains in 4 seconds and they will start up seamlessly on their own.
When I say you don't need any circuit signals I mean you don't need any circuit signals.
Re: My attempt at generic stations
With stampede, you mean multiple trains are employed for a task where just one is expected? Given proper usage of train limits, I can only imagine one setup where such a stampede could happen: if your train default state is empty, and every train is waiting at a depot for empty trains. If some requester station opens with demand, you open up some provider station with the requested material and an empty train will be dispatched to first pick up that item from a provider station, then deliver it to the requester station.Abnaxis wrote: ↑Wed Nov 27, 2024 1:23 pm It would still need circuits to avoid stampedes, though. Something needs to remove the 'demand' from the line while the trains are picking up cargo, and dropoff stations need to selectively enable themselves based on what's currently shipping. This just cuts out all the station-enabling logic in pickup stations.
However, the issue is that the circuit network need to keep status information about the connection between the requester station and the provider station to avoid another train being dispatched to the provider station as long as the first train left with full cargo and is en route to the requester station but hasn't satisfied the demand from the requester station yet.
In my opinion, this whole concept has so many flaws, it's not feasible.
- the response time between "demand signaled" and "demand satisfied" is huge, because an empty train first has to drive to the provider station, needs loading time, then drives to the provider station.
- keeping the connection between requester and the one provider that's handling the currently handling the request is a chore with the circuit network
- you need to wire every station
Don't do it.
Instead of keeping your idle trains empty, keep your idle trains full.
Make sure there's a train at all times at each provider station. Use your trains as buffers at provider stations. Not chests. And as soon as demand arises, a full train can immediately be dispatched (not even loading time required) to deliver. In this concept, interrupts work like wonders. Without any circuit network connections, no circuit computing, and with just a few tiny interrupts, everything works like magic.
Re: My attempt at generic stations
You'll have to show me how you can have dropoff stations that can handle multiple products without circuit connections, I'm not seeing how that can work. The requester station have to have a way to send a request.Tertius wrote: ↑Wed Nov 27, 2024 2:38 pm With stampede, you mean multiple trains are employed for a task where just one is expected? Given proper usage of train limits, I can only imagine one setup where such a stampede could happen: if your train default state is empty, and every train is waiting at a depot for empty trains. If some requester station opens with demand, you open up some provider station with the requested material and an empty train will be dispatched to first pick up that item from a provider station, then deliver it to the requester station.
However, the issue is that the circuit network need to keep status information about the connection between the requester station and the provider station to avoid another train being dispatched to the provider station as long as the first train left with full cargo and is en route to the requester station but hasn't satisfied the demand from the requester station yet.
In my opinion, this whole concept has so many flaws, it's not feasible.
- the response time between "demand signaled" and "demand satisfied" is huge, because an empty train first has to drive to the provider station, needs loading time, then drives to the provider station.
- keeping the connection between requester and the one provider that's handling the currently handling the request is a chore with the circuit network
- you need to wire every station
Don't do it.
Instead of keeping your idle trains empty, keep your idle trains full.
Make sure there's a train at all times at each provider station. Use your trains as buffers at provider stations. Not chests. And as soon as demand arises, a full train can immediately be dispatched (not even loading time required) to deliver. In this concept, interrupts work like wonders. Without any circuit network connections, no circuit computing, and with just a few tiny interrupts, everything works like magic.
The problem with this is that every full train is unecessary stockpile. That's kinda OK if you're talking about iron plates--though a train can still hold 4000 plates/cargo wagon, which is gross overkill in the early game--but it becomes a real problem when you're talking about science bottles or circuits. It's OK for late-game when you only want to move raw materials from remote mining/drilling locations to your base, but I'm talking about replacing belts with trains. I need more control over stock than parking trains in stations with full wagons will afford.
It also kind of defeats the purpose of having generic trains to being with, no? If the "default" state is full, what's the difference with having dedicated trains per product in terms of optimization?
As for the downsides of making "empty" default, there are ways to engineer around some of it:
- Every consumer uses items at a calculable rate, and every "dropoff" holds a stockpile of said items. As long as the dropoff station signals demand at a high enough threshold its stockpiles don't run out before the latency needed to carry the materials, said latency won't interrupt production.
- My solution to this problem, is to keep track of the difference in how many requesters there are and how many providers there are (this is my red nework). As long as the difference is less than or equal to 0, no trains get sent out.
- Yep! Every station is wired, with both colors. Like I said, at least wires are free now, so it's not like it's a drain on resources, just a bit of patience. At the same time, if you want a single station to receive multiple dropoffs, I don't see any way to avoid that?
Re: My attempt at generic stations
I'm not sure how I feel about that without thinking on it a bit. In theory, you have fewer total trains if they're parked without materials in them, but without actually testing it out at scale I don't know if it's enough of a difference.mergele wrote: ↑Wed Nov 27, 2024 1:39 pm Not even that.
If trains are sitting "idly" in pickup stations waiting for somewhere to drop off their stuff thats fine. Reducing response time improves throughput.
If more dropoff stations are open than you can currently supply that means your supply throughoput is bottlenecked and no kind of station disabling will magically make you produce more, so thats also fine.
And with 2.0 train interrupt groups being blueprintable you can drop down an additional 15 trains in 4 seconds and they will start up seamlessly on their own.
When I say you don't need any circuit signals I mean you don't need any circuit signals.
I do feel like there's an overfocus on loading and travel times in the discussion. At least in the early- to mid-game loading and travel time is negligible compared to production and consumption time of the same cargo. It'll take minutes to consume a trainload of plates that took minutes to forge and seconds to load and unload. That's just my gut talking though.
Re: My attempt at generic stations
That's correct, so don't do this. Use dedicated stations for every product, and always ship one single product with one train. Even in the early game, building multiple train stations, one for every material, is not prohibitively expensive.
As far as I mean it, no. No stockpile. On provider stations with your approach, you will need to use buffer chests. How many do you use to speed up loading? 4, or even 6 per wagon? 6 full buffer chests per wagon for a 4 wagon train are almost 7 full trains. That's way more buffer, so way more stockpile than the system I suggest: no buffer chests at all at provider stations required, since there is always a train at each provider station, so there is always a train being loaded, so it can be done without intermediate buffer chests. That's at most 1 trainload buffered. Not up to 7 in case you use buffer chests.
Without buffering, trains are being loaded during production, and as soon as the train is full, it is available to satisfy a requester station. There can be no smaller latency between production and consumption. In case you have a weak CPU, having no buffer chests at provider stations even help with UPS.
On the requester station you probably need buffer chests of course, but that's not different to your approach.
About your point with higher rated intermediates such as plates and green/red/blue chips, I don't see this is overkill. You have to wait for the first full train arriving, but after that, with continuous production, delivery comes in no different than with smaller portions. With full trains you have big bursts, but you need to send vastly less trains to get the desired (low) throughput. Throughput requirement is no different after all.
Sending whole trains has many positive side effects: you need less trains en route, so train congestion on the track is not a thing. And it scales very good. This system is suited for the earliest game up to late game. Personally, I start in early game with 2-4 trains and it wasn't necessary to change that ever. It scales up to the endgame. I even use the same station blueprint throughout the whole game. The only thing you might change is the inserter and belt type while you progress through the game, but the whole concept including schedules and interrupts scales through the whole game. I planned to update to 2-8 trains some later stage, but this simply wasn't necessary.
The only trains I use that carry multiple materials are the uranium ore train: it has an additional fluid wagon to provide sulfuric acid to the uranium mine. And the supply train I use to build and maintain the defense perimeter wall. This has a very specialized loading system for many different items per wagon. But the corresponding stations are all named the same: supply load and supply unload. To to deliver just one material, the whole train is carrying the whole set of items every time. But this train is not used to carry high traffic intermediates such as ore, plates, chips, etc. Just walls, robots, repair packs, mining drills, whatever you need to build and maintain walls and mines. That one is heavily circuit-controlled, but still not the stations themselves, just the loading and unloading is operated by circuits.
Re: My attempt at generic stations
"dropoff stations that can handle multiple products " is a new requirement that changes things majorly.
And yeah, of course you can have fewer trains if you load them only when required, but why do you care about that? Trains are cheap and easy to build.
And yeah, of course you can have fewer trains if you load them only when required, but why do you care about that? Trains are cheap and easy to build.
Re: My attempt at generic stations
If you're wanting trains to replace belts, you need to direct-load from them. It only really works if the same station reveives multiple products.
Pre-2.0, I would have a train with cargo wagons that I restricted the individual slots on, which would go around and pick items up to drop off. Say, a mixed train with sulpher, red chips and engines in it to feed a blue bottle assembly plant.
I think 2.0 trains will work a lot better, I'm just working on setting them up.
Re: My attempt at generic stations
Ergh, you made me forget why signal interrupts don't work.
You can only use signals in the circuit condition interrupt condition. Crucually, you can't use them in item count or fluid count. Otherwise, they would simplify my system a great deal.
Re: My attempt at generic stations
Oh yeah, good point, your right there.Abnaxis wrote: ↑Thu Nov 28, 2024 12:43 am If you're wanting trains to replace belts, you need to direct-load from them. It only really works if the same station reveives multiple products.
Pre-2.0, I would have a train with cargo wagons that I restricted the individual slots on, which would go around and pick items up to drop off. Say, a mixed train with sulpher, red chips and engines in it to feed a blue bottle assembly plant.
I think 2.0 trains will work a lot better, I'm just working on setting them up.
I made this blueprint system that technically does what you want, the circuitry required per unloading station is somewhat (very) unwieldy though. It may serve as an inspiration for someone to refine though.