
Maybe? Anyway, with mixed inventory wagons it requires a little more work on the requester station schedule (I have to send off trains when any one of the materials is empty, but not before other items have had a chance to unload if they can - e.g. except, I suspect based on your other comment ("empty cargo" on requester station) I suspect you use single item trains rather than mixed-inventory (filtered slots) trains. It also makes spotting depleted outposts much easier: if the train just sits there, chances are it's empty. If you let them just idle at their depleted outposts, not only does this keep your tracks clean, but you can easily take them out of the system entirely and recycle the diesel locos when you get around to visiting the depleted outpost. You don't want to clutter your train system with trains that lost their purpose. As long as you balance the wagon load evenly, a train that does not fill up anymore only means one thing - the mining outpost is depleted. Unlike common perception, it is not helpful to give trains at mining outpost an OR- condition based on time. This is because the ore processing outputs are provider stations, while the ore processing inputs are reverse requester (= acceptor) stations - an exception, due to the fact that I don't want to request from mines, but rather have 1 train per mine that automatically delivers. The ore processing plant is the only factory plant I use that has stackers for both input and output. Unlike requester stations, it makes sense to maximize throughput for provider stations - no bit of throughput is wasted. As such, they use large stackers, leading into high-throughput loading stations. Unlike requester stations, which each house 1 train each, a provider station might have to accomodate more trains as your factory grows - it is dynamic. Because you can exactly calculate the needed inputs for a single processing plant, you can also exactly determine how many trains you need using this system.Ī provider station will have to handle fluctuating numbers of incoming requester trains. Because these stations are then sometimes empty, their throughput can be lower than the factory requires - instead, bulid more requester stations (with 1 train waiting each). There is exactly one train to each requester station, so no stackers are needed. In fact, there is two main types of stations that I use: requester and provider stations.Ī requester station has a train wait at the station itself, setting off to a provider station once the chest buffer in the requester station is getting dangerously low. Stackers are a must, and I build them large right off the bat (better safe than sorry). More trains do the same job as long trains, but you don't have to take into account massive lengths when building stackers. Standardize your train sizes and keep it small. This way, I can for example use two 1-4 trains instead of one 2-8 train, which makes my intersection / waiting area design easier: Instead, I tend to scale up the number of stations, but giving each station a limited throughput (and a bit of a buffer in the form of chests). For example, my green circuit cell produces 8 belts of circuits at the cost of a little more than 6 belts of iron and a little more than 4 belts of copper (prod modules).īecause trains need to travel, there is no point in giving the station as much unloading capability as the factory consumes. Then I scale the number of input stations to fit that. That means that I can easily predict their required sustained input. I have somewhat specialized production cells. I am going for a modular design, which is usually optional but for you with angels/bobs probably a must: Here's what I am currently doing for a rail based megabase project.
