My approach to rails (junction, single header) [+blueprints]

vanatteveldt · Post by **vanatteveldt** » Tue Aug 02, 2016 10:55 am

I've experimented quite a bit with railroads (although not with super-high throughput) and of course I pinched ideas from all over the forums. Since I now have an easy and guaranteed deadlock-free setup for my trains, I thought I would share them.

If you're confused by trains, your should first read the "Stations, Junctions, and all things deadlock" post at viewtopic.php?t=18621, this is an excellent guide for how to design rail systems to be efficient and deadlock-free and I stole most ideas from there.

I use single-header trains and all lanes are one-way. I separate stations from normal traffic by creating "spur lines" that only serve that station. So, the main network is extremely simple, with stretches of double rail between junctions (replace by roundabouts as desired). For example, this is the main line in my current game:

All my stations consist of the following elements, displayed below:

1) junction from main line (black)
2) waiting bay(s) (red)
3) turnaround (green)
4) (un)loading bays (blue)

Entries into all bays have normal signals. Exit from waiting bays are chain signalled, exit from (un)loading is a normal signal. This will cause trains to wait in a waiting bay until their desired (un)loading bay is free. A station needs as many waiting bays as there are "extra" trains, where a train is extra if there are multiple trains using the same (un)loading bay. So, an iron smelting plant with one train bringing ore and another taking plates does not need a waiting bay as an (un)loading station is guaranteed to be free. If you have 3 trains grabbing plates and 4 bringing ore you need 2+3=5 waiting bays, assuming that you have one bay each for loading and unloading.

Some station designs:

Simple mining outpost

A station with only a single type of train (e.g. a mining outpost) does not need waiting bays as the trains will queue up on the spur line and turning point:

simple mining outpost

As you can see, I did add a second 'loading bay' for my shuttle train, as I want to be able to park it where it doesn't interfere. If there are multiple iron trains waiting to be loaded the shuttle train will be stuck in traffic, but I can just hop off, do whathever I needed to do, and hope that by the time I need it again it has made it to the passenger station.

This outposts has loading chests, but with stack inserters that is no longer needed for throughput. Of course, if you only use a single train you probably want to have chests as a buffer, to prevent the mines shutting down when there is no train. What I do now is have two trains for each outpost, and trigger trains to leave when the other train arrives. That way, (1) the smelters get ore even if the train is not full yet; (2) there is always a train to unload into unless there is no demand for ore; and (3) trains do not move needlessly since they will stop at the smelter until empty.

Multiple loading bays, one train per type

This is my general manufacturing plant, which is a robot-based plant that makes everything that is produced intermittently (equipment, weapons, etc.). It has a lot of different inputs, but each is served by a single train, so no waiting bays are required:

multiple loading, no waiting

Multiple waiting bays

Final example: my iron plant, which has ore unloading and iron+steel loading, and has multiple trains of each type:

multiple waiting bays

As you can see, as many waiting bays and (un)loading bays can be added. To further improve throughput, I can add multiple (un)loading bays per type and add a separate waiting bay behind each (un)loading bay, so the station is empty for the shortest period of time.

Note that the waiting bays are (way) oversized, but I liked the symmetry. I don't split waiting bays into blocks because then the train can decide to wait behind a train of another type and get stuck there. I could of course have multiple blocks of waiting bays, but to prevent trains getting stuck behind other trains it should allow crossing between all bays in each block, i.e. funnel them back through a single track with chain signals.

All critique and comments welcome!

Blueprints

Edit: I bit the bullet and made a set of blueprints in creative mode. Trains drive on the left and first enter the waiting bays on the left. After that they turn around and choose a station. Each station has a separate waiting bay as well to minimize time between trains. It fits LLLL-CC or smaller. This is a picture of a full station in action with 5 waiting bays and 5 un/loading bays. This station can service 15 trains without deadlock assuming equal distribution, or max 6 trains for a single destination bay. I've also uploaded a youtube video where you can watch trains drive around (guaranteed 20% better than cat videos!): https://youtu.be/5Fcu2CI7MaE

fully operational station

The blueprints are composed of three parts: the base loop, extra bays, and extra stations. All the 'extras' go on the outside, and you can add as many as you want.

base station

extra waiting bay

extra station

This leaves quite a big gap in the middle of the loop. You can easily squeeze in more waiting bays and stations with a bit of custom rails:
I bit the bullet and made a set of blueprints in creative mode. Trains drive on the left and first enter the waiting bays on the left. After that they turn around and choose a station. Each station has a separate waiting bay as well to minimize time between trains. It fits LLLL-CC or smaller. This is a picture of a full station in action with 5 waiting bays and 5 un/loading bays. This station can service 15 trains without deadlock assuming equal distribution, or max 6 trains for a single destination bay. I've also uploaded a youtube video where you can watch trains drive around (guaranteed 20% better than cat videos!): https://youtu.be/5Fcu2CI7MaE

+ FULLY OPERATIONAL STATION

extra bays

Frightning · Post by **Frightning** » Tue Aug 02, 2016 1:48 pm

No rail system is deadlock proof. But a well designed system can only become deadlocked due to having too many trains in it. (Easy proof of this follows from the finiteness of the number of blocks in a given system; what happens when number of trains is greater than or equal to number of blocks?)

I posted a guide to how to do rail signalling right a few nights ago in the Gameplay and Help section.

Very nice signalling solution for the waiting bay setup.

Edit: I feel that your rail system is approaching the scale where the 'Hubs' idea that I've had for a while might be useful. The basic premise is reduce the number of trains coming and going from high throughput stations by centralizing the relevant materials elsewhere first and then running fewer, longer trains from that hub to the relevant station (in the case of bringing ore to a main base, then has added benefit of reducing number of trains needed to serve mining outposts because those trains don't have to travel so far now).

dragontamer5788 · Post by **dragontamer5788** » Tue Aug 02, 2016 7:27 pm

I'm not quite at "endgame" yet (haven't launched a rocket), but I generally use a single-track spur for my mining outposts. Your dual-track spurs have the benefit of allowing multiple trains through (IIRC, it takes ~10 seconds for a set of stack inserters to fully load an ore train, or ~20 seconds to load a plate train). I do see the benefit of multiple trains visiting a single mining outpost at a time, and I think a design of either:

* Main line -> Waiting Bay -> single-track spur to mining outpost
* Or Main line -> single-track spur -> Waiting bay / loading dock of mining outpost.

I can agree that a two-rail maintrack makes sense, and a two-rail based waiting-bay makes sense for perhaps the main base where everything happens. But space is a premium in biter-infested territory. The smaller your design gets, the less area you have to defend. Still, it looks like your design is quite space efficient (one leg of the track effectively functions as a waiting bay, and the exit-bay doesn't exist for "simple outposts"). I just wonder if similar throughput can be accomplished with a single-track system instead.

Mainline should always be double-track of course: once you get more than 4 trains, bi-directional travel is just the way to go.

Frightning wrote:I feel that your rail system is approaching the scale where the 'Hubs' idea that I've had for a while might be useful. The basic premise is reduce the number of trains coming and going from high throughput stations by centralizing the relevant materials elsewhere first and then running fewer, longer trains from that hub to the relevant station (in the case of bringing ore to a main base, then has added benefit of reducing number of trains needed to serve mining outposts because those trains don't have to travel so far now).

The nature of this game, and compression, means that first, train stations should probably be designed for:

1. Sending plates only (smelt ore into plates on site) -- This offers 2x stacking. 100-plates per stack instead of 50-ore per stack. This instantly doubles the density of plate travel across the rail system. (Wagons carry 4000 plates instead of 2000 ore)
2. Assemble gears (2x iron compression) or steel (5x compression) whenever possible before loading onto a train. (A single wagon with 4000 Steel is effectively carrying 20,000 Iron. Every inserter is 5x more efficient at everything)
3. Assemble green circuits (2.5x compression: 1 Iron Plate and 1.5 Copper plate per Green Circuit), and 4x stacking (200-green circuits per stack instead of 50-ore per stack).
4. Assemble Red Circuits (Ship plastic to hub. 7x effective compression (2 iron, 5 copper, and 2 plastic that had to be shipped) and 4x stacking (200-red circuits per stack instead of 50-ore per stack).
5. Assemble Batteries (Ship physical sulfur to hub. 2x compression: 1iron and 1copper per battery, 4x stacking. 200-batteries per stack IIRC)
6. Assemble Blue Circuits(Ship physical sulfur to hub. 64x effective compression: 24 Iron, 20 Copper, 4 plastic (that had to be shipped) per Blue Circuit. 4x stacking for 200-processors per stack)

Iron plates are still used in a lot of recipes (namely basic inserters and yellow belts), and should be dropped off in the main base. Copper's only remaining uses would be weaponry (ex: Shotgun / Advanced Magazines), Solar Panels, and low-density structures.

Iron plates are still used in a lot of recipes, and should still be dropped off in the main base. But copper plates? If you can assemble Green and Red circuits 'in the field', then the main base will virtually never have to receive deliveries of copper directly. The idea of shipping "plastic out" of the main base for better compression seems like a needless complication. But achieving effectively 9x compression piques my interest. Every 2 plastic shipped to the "external red-circuit assembler hub" prevents 6-plates from getting shipped into the base.

#5 and #6 are far more complicated, since this would involve shipping sulfur out and setting up chemical plants to help compression. But the rewards would be grand.

This strategy taken to the extreme would have red-belts assembled at iron mines directly (11.5x compression), before being loaded onto a train. Working with limited, intermediate-products seems logical. But the additional hassle of mixing items on trains (and separating them out when they get to the main base) may make it unacceptable.

Still, if you're building "hubs" that take multiple types of plates (ex: Iron and Copper), the natural strategy would then "compress" the plates further for more efficient travel before entering your main base.

Frightning · Post by **Frightning** » Tue Aug 02, 2016 11:35 pm

dragontamer5788 wrote:I'm not quite at "endgame" yet (haven't launched a rocket), but I generally use a single-track spur for my mining outposts. Your dual-track spurs have the benefit of allowing multiple trains through (IIRC, it takes ~10 seconds for a set of stack inserters to fully load an ore train, or ~20 seconds to load a plate train). I do see the benefit of multiple trains visiting a single mining outpost at a time, and I think a design of either:

* Main line -> Waiting Bay -> single-track spur to mining outpost
* Or Main line -> single-track spur -> Waiting bay / loading dock of mining outpost.

I can agree that a two-rail maintrack makes sense, and a two-rail based waiting-bay makes sense for perhaps the main base where everything happens. But space is a premium in biter-infested territory. The smaller your design gets, the less area you have to defend. Still, it looks like your design is quite space efficient (one leg of the track effectively functions as a waiting bay, and the exit-bay doesn't exist for "simple outposts"). I just wonder if similar throughput can be accomplished with a single-track system instead.

Mainline should always be double-track of course: once you get more than 4 trains, bi-directional travel is just the way to go.

Frightning wrote:I feel that your rail system is approaching the scale where the 'Hubs' idea that I've had for a while might be useful. The basic premise is reduce the number of trains coming and going from high throughput stations by centralizing the relevant materials elsewhere first and then running fewer, longer trains from that hub to the relevant station (in the case of bringing ore to a main base, then has added benefit of reducing number of trains needed to serve mining outposts because those trains don't have to travel so far now).
The nature of this game, and compression, means that first, train stations should probably be designed for:

1. Sending plates only (smelt ore into plates on site) -- This offers 2x stacking. 100-plates per stack instead of 50-ore per stack. This instantly doubles the density of plate travel across the rail system. (Wagons carry 4000 plates instead of 2000 ore)
2. Assemble gears (2x iron compression) or steel (5x compression) whenever possible before loading onto a train. (A single wagon with 4000 Steel is effectively carrying 20,000 Iron. Every inserter is 5x more efficient at everything)
3. Assemble green circuits (2.5x compression: 1 Iron Plate and 1.5 Copper plate per Green Circuit), and 4x stacking (200-green circuits per stack instead of 50-ore per stack).
4. Assemble Red Circuits (Ship plastic to hub. 7x effective compression (2 iron, 5 copper, and 2 plastic that had to be shipped) and 4x stacking (200-red circuits per stack instead of 50-ore per stack).
5. Assemble Batteries (Ship physical sulfur to hub. 2x compression: 1iron and 1copper per battery, 4x stacking. 200-batteries per stack IIRC)
6. Assemble Blue Circuits(Ship physical sulfur to hub. 64x effective compression: 24 Iron, 20 Copper, 4 plastic (that had to be shipped) per Blue Circuit. 4x stacking for 200-processors per stack)

Iron plates are still used in a lot of recipes (namely basic inserters and yellow belts), and should be dropped off in the main base. Copper's only remaining uses would be weaponry (ex: Shotgun / Advanced Magazines), Solar Panels, and low-density structures.

Iron plates are still used in a lot of recipes, and should still be dropped off in the main base. But copper plates? If you can assemble Green and Red circuits 'in the field', then the main base will virtually never have to receive deliveries of copper directly. The idea of shipping "plastic out" of the main base for better compression seems like a needless complication. But achieving effectively 9x compression piques my interest. Every 2 plastic shipped to the "external red-circuit assembler hub" prevents 6-plates from getting shipped into the base.

#5 and #6 are far more complicated, since this would involve shipping sulfur out and setting up chemical plants to help compression. But the rewards would be grand.

This strategy taken to the extreme would have red-belts assembled at iron mines directly (11.5x compression), before being loaded onto a train. Working with limited, intermediate-products seems logical. But the additional hassle of mixing items on trains (and separating them out when they get to the main base) may make it unacceptable.

Still, if you're building "hubs" that take multiple types of plates (ex: Iron and Copper), the natural strategy would then "compress" the plates further for more efficient travel before entering your main base.

I tend to avoid pre-manufacturing because I want the system to be automatically manage how much of stuff such as steel and circuits to produce based on demand (with a sizable buffer to handle short-term changes). Pre-manufacturing is nice for train throughput, but you then have to control how much of the various projects are made somehow, and that isn't automatic anymore (I suppose combinator shenanigans could automate that, but then you have to string signal wires from your main to your hub (tedious to setup).

The actual logistics of sorting the cargo at your main base is really easy if you rely on logistic bots for all item movement as I do in my current kilobase, they will handle everything for you.

I suppose I have no real reason not to pre-compress copper ore into plates, but technically iron ore has 1 other use than making iron plates: Concrete production.

Also Processing Units are 100/stack unlike other circuits.

Pre-compression honestly isn't really necessary because trains already have such extreme throughput, especially longer trains. (Mind you, I can totally foresee hubs running 2-20-0 trains to your main)

dragontamer5788 · Post by **dragontamer5788** » Wed Aug 03, 2016 6:43 am

I tend to avoid pre-manufacturing because I want the system to be automatically manage how much of stuff such as steel and circuits to produce based on demand (with a sizable buffer to handle short-term changes). Pre-manufacturing is nice for train throughput, but you then have to control how much of the various projects are made somehow, and that isn't automatic anymore (I suppose combinator shenanigans could automate that, but then you have to string signal wires from your main to your hub (tedious to setup).

Actually, I've been experimenting with long-range train-based backpressure. Its actually rather simple and doesn't need long-range wires. A short-range circuit network "local" to the train station / main base is really all you need.

Just send the train back to the mines full. Instant backpressure (the mines will be unable to load an already full train). As long as home-base refuses to accept more goods, the backpressure will pile up even remotely. Don't take items off a train unless you know your location needs the item. No need for long-distance wires.

ONLY unload an item from a train if you know it will be "used" somewhere in your base. And that's easily set with constant combinators set negative (Ex: -50 Circuits "demanded" in this box. Set a constant combinator to -50 and hook it up to even a wooden box). It just needs to be some small value to let a train-station know that demand is downstream.

Some other throughts spoiled for excessive length:

I also tried to set trains to **immediately leave** if the unloading dock if the unloading train station isn't requesting any items aboard. For example, if a mixed-train is holding Iron and Copper, create a circuit that checks demand of iron / copper (I use negative numbers to indicate local demand) and maybe outputs A = 1 if the train Iron OR copper is demanded. This sped things up, but mixed-trains are harder to deal with.

If trains aren't mixed, you can leave under a simpler condition, like "Iron > -1" (Again, my circuit scheme has negative numbers tracking demand. If Iron is 0 or above, then no demand in my circuit network). Filtering items out of a mixed-train is a bit more difficult, but can be done with Filter Inserters (but not stack-filter inserters). Filter Inserters have 5-filter item slots, so a mixed-train with up to 5 different items can be managed by 12-filter inserters per wagon (6 on each side). Each of the filter inserters can be set into "Circuit Network: Set Filters" mode (which sets a filter if the circuit is positive. This is easily done with EACH * -1 for my "negative numbers indicate demand" scheme). As long as there are fewer than 5 items demanded, you can hook up the -1 circuit to filter inserters and everything works.

I haven't figured out a way to unload a mixed-train with successful backpressure using stack-filter inserters yet. The single-filter limitation and changing conditions of mixed train wagons just prevents a lot of things from working. But, if each wagon were only carrying a single type of good (or more specifically: if each unloading stack-filter inserter were guaranteed to only work with one item through proper train scheduling), then it is trivial to implement backpressure.

Frightning · Post by **Frightning** » Wed Aug 03, 2016 1:21 pm

dragontamer5788 wrote: Actually, I've been experimenting with long-range train-based backpressure. Its actually rather simple and doesn't need long-range wires. A short-range circuit network "local" to the train station / main base is really all you need.

Backpressure is a no-go for me because I use 'universal' train stations at my main for unloading. That is, my unloading bays handle all goods I am receiving (Currently, Coal, Copper Ore, Iron Ore, and Stone), except for the Oil train system which will be separate because of the need for sending Empty barrels back to the Oil outpost(s).

vanatteveldt · Post by **vanatteveldt** » Wed Aug 03, 2016 2:38 pm

I do the reverse: I set the trains to wait until empty (or until one of the goods is empty in case of mixed trains). Thus, the wagons act as a buffer, and I unload to chests if more buffer is needed (with stack inserters unloading to belts is fine otherwise).

Each outpost has at least one dedicated train. Outposts have buffers since I want everything out of the ground asap. The smelter has waiting bays so in most cases there is always a full train waiting so smelting can continue as long as resources are needed. Smelters also have buffers since plates are good

Consumers (i.e. circuit plant, main base) usually have a single train getting supplies unless more throughput is needed, which waits at the consumer until fully unloaded.

With this setup, only empty trains go to the outpost/smelter. If supply meets demand, returning trains should always be full. Moreover, intermediate goods (esp circuits) are not produced more than needed and don't take more resources than needed, buffers aside.

dragontamer5788 · Post by **dragontamer5788** » Wed Aug 03, 2016 5:53 pm

Frightning wrote:
dragontamer5788 wrote: Actually, I've been experimenting with long-range train-based backpressure. Its actually rather simple and doesn't need long-range wires. A short-range circuit network "local" to the train station / main base is really all you need.
Backpressure is a no-go for me because I use 'universal' train stations at my main for unloading. That is, my unloading bays handle all goods I am receiving (Currently, Coal, Copper Ore, Iron Ore, and Stone), except for the Oil train system which will be separate because of the need for sending Empty barrels back to the Oil outpost(s).

With only four items, you can build a universal unloading bay with backpressure using filter inserters and their "set filters" feature. (But not stack-filter inserters). Basically, set the filter-inserter as "circuit network set filters" and they'll only unload items that are "positive" on the circuit network wire. (Indeed: the fifth item could be oil barrels, and then your oil-trains can pickup empty oil barrels at another location)

This does not work with stack-filter inserters however, due to only having one filter.

vanatteveldt wrote:I do the reverse: I set the trains to wait until empty (or until one of the goods is empty in case of mixed trains). Thus, the wagons act as a buffer, and I unload to chests if more buffer is needed (with stack inserters unloading to belts is fine otherwise).

That's an interesting design.

I initially thought that this couldn't possibly work... but with enough waiting bays, this actually might be a cleaner design. You'd still need multiple unloading docks for different items (ie: Iron Dropoff station, Copper Dropoff station, etc. etc. instead of "Universal Stations" like Frightning's design... or my current design.) But this does seem to handle the backpressure problem cleanly, although it would use a lot of space for those waiting bays, and then lots of space for the various dropoffs.

The waiting bays could be shared between all of the dropoff stations however.

vanatteveldt · Post by **vanatteveldt** » Wed Aug 03, 2016 6:23 pm

Thanks. The space is not too bad, I think, see e.g. the "multiple waiting bays" screenshot above; and I really like having a large supply of ore trains waiting near the smelter.

The design I've taken to now is to have the stations on one side of the main line, cross the belts to the other side of the tracks, and have the smelter / assemblers there. That way, both the station and the assemblers can grow "infitinely" to the left and right (otherwise you always need to figure out how many loading/wating bays you'll need and reserve space...

I'm unfortunately on a factorio-break, but I'll post a new smelter design when I'm back...

siggboy · Post by **siggboy** » Thu Aug 11, 2016 8:01 pm

vanatteveldt wrote:

Entries into all bays have normal signals. Exit from waiting bays are chain signalled, exit from (un)loading is a normal signal. This will cause trains to wait in a waiting bay until their desired (un)loading bay is free.

This is a very useful layout. It is how I construct the depot for my train setup (where all trains are on the same line and go through the same depot).

The depot has multiple lanes ("unloading bays" in your example, only that they're not for unloading, just for the trains to wait for their orders), and there is an additional array of waiting bays that are all joined, with chain signals before the join.

Iorek · Post by **Iorek** » Thu Sep 15, 2016 10:11 pm

blueprints?

vanatteveldt · Post by **vanatteveldt** » Fri Sep 16, 2016 9:20 am

I see that this thread has been stickied, cool!

I'll update the first post with blueprint strings, it's about time I learn how these work

vanatteveldt · Post by **vanatteveldt** » Wed Sep 21, 2016 10:31 am

I've added blueprints to the original post!

I bit the bullet and made a set of blueprints in creative mode. Trains drive on the left and first enter the waiting bays on the left. After that they turn around and choose a station. Each station has a separate waiting bay as well to minimize time between trains. It fits LLLL-CC or smaller. This is a picture of a full station in action with 5 waiting bays and 5 un/loading bays. This station can service 15 trains without deadlock assuming equal distribution, or max 6 trains for a single destination bay. I've also uploaded a youtube video where you can watch trains drive around (guaranteed 20% better than cat videos!): https://youtu.be/5Fcu2CI7MaE

fully operational station

mrvn · Post by **mrvn** » Tue Dec 13, 2016 12:58 pm

Some thoughts:

1) Why not unload trains from both sides? And put the power pole between trains so you can unload using 12 stack inserters into 12 chests per train car.

2) You mention having 2 trains and stopping to load a train when the next arrives. Have you considered extending this to unloading too?

You can have 3 (or 4) trains: One stuck loading till another train arrives. One stuck unloading till another train arrives. One (or 2) trains on the way from one stop to the other. This should work completely without waiting bays.

Note: This scheme assumes that loading train cars is faster than loading/unloading the buffer chests. Otherwise the time wasted while switching trains would reduce throughput and you would be better off waiting for full/empty cars.

Lets extend this further. Why not have trains load until full or all the waiting bays are full?

Seems like a nice way to keep trains from blocking the main loop when you have more trains than waiting bays.

vanatteveldt · Post by **vanatteveldt** » Tue Dec 13, 2016 2:45 pm

Thanks for the feedback!

In fact, I've been working on a "train bus" based factory for a while now, so a number of the designs here have been improved. I'll post pictures soon (TM)!

- I don't use 2-side (un) loading in most places as I prefer to add an extra stop, so each stop gives 4 blue belts (in or out). I don't think it matters much in the end, since the amount of trains on the network is the same, and total throughput is the same. Stations are a big bigger, but not that much as unloading takes more space than the rails anyway. So, the main effect is that with 1-side (un)loading I have more cargo in the train buffers, and throughput is smoothed a bit.

- In 1-on-1 situations loading and unloading should be as fast, but there are hardly any 1-on-1 situations. Smelting has a lot of loading stations (many outposts) per unloading station, and most goods (i.e. green circuits) are the opposite.

- I set all trains to wait until empty, and this in the end determines the pace if production is sufficient. When starting up, or if production is insufficient, waiting until 30 seconds (most goods) or until the next train gets there (outposts) minimizes downtime, I don't want e.g. sattelite production to stop because my blue circuit train is only loaded 50%, as it only needs 100 blue per minute anyway.. Maybe this is not totally rational?

- For unloading, I don't see a reason why a train should go unless it's empty. I use the train waiting until empty as a 'backpressure' mechanism. Most places have two trains per input, with a waiting bay just before the stop, and no generic waiting bays are needed and the next train is always waiting behind the unloading train. For ore I have much more trains than ore stops, so I do use generic waiting bays.

- Stations should always have enough waiting bays! This can be easily calculated by clicking on each stop. Assuming it has a dedicated bay just before the stop, it needs n-2 waiting bays. Sum this for all stops, add a couple for good measure, and you should never have deadlocks.

mrvn · Post by **mrvn** » Fri Dec 16, 2016 11:07 am

I'm currently using unloading till empty and loading till full with 2 cars per train but I find that has problems. My cars have become unbalanced with trains waiting at stations with one car empty while the other is blocked from unloading because the buffer chests are full. Or one car full with the other half full and the buffer chests on that side empty.

I sometimes take items out of a train or buffer chests to hand craft stuff. Ore production isn't the same for all lanes and the last furnaces on a row don't always get enough ore to smelt. So my buffer chests fill up at different speeds too. I don't have the space or will to make a perfect 24 lane balancer before each loading station so I don't think I can do much about this. I assumed back pressure would cause the imperfect balancing I do have to fill all buffer chests. But I consume items too fast so there is no back pressure to speak of.

Are there any tricks to make a train leave if one of it's cars is full or empty instead of the whole train? Or do I have to start adding something to balance cars?

vanatteveldt · Post by **vanatteveldt** » Fri Dec 16, 2016 11:23 am

I always place balancers before loading / after unloading, 4:4 balancers are cheap and small and that prevents a lot of the problems. In fact, one of the reasons for prefering 1 express belt per wagon (instead of the maximal) 1.5 is that that gives me 4 belts per train, which is easy to balance, but 6 is a lot more difficult. I guess I could go with 8 belts from 6 wagons, but I can't really be bothered. I just add a train stop

I only have them wait for unloading, and the balancer makes sure that it is never really blocked. Output drops a bit if wagons empty out, of course, but it shouldn't take too long normally.

I'm not aware of a good setup to balance loading if one of the wagons is already full and you are waiting for input. However, if you have enough production, the only problem is increased loading time, and with balancer buffer chest insertion the problem should be temporary.

(for 1 rocket per minute with max prod3 modules, you need just under 12 blue belts of copper and 8 blue belts of iron, but I'm afraid that these little inefficiencies mean I will need more capacity... I'm currently at 55 rockets per hour or something. Problem is there's no space to add more stops, so increasing capacity will require quite a bit of redesign... )

mrvn · Post by **mrvn** » Fri Dec 16, 2016 12:30 pm

I probably should give up 2 buffer chests per train car and use those to load goods from one car to the other and back to balance them. So far it always seemed wasteful since they would continually shift items between cars till one of them is full or empty and only then things would balance. But maybe some circuit logic with the buffer chests could be added to make the inserters only balance cars when needed.

trqwe · Post by **trqwe** » Sat Jun 17, 2017 8:10 pm

Frightning wrote:I tend to avoid pre-manufacturing because I want the system to be automatically manage how much of stuff such as steel and circuits to produce based on demand (with a sizable buffer to handle short-term changes). Pre-manufacturing is nice for train throughput, but you then have to control how much of the various projects are made somehow, and that isn't automatic anymore (I suppose combinator shenanigans could automate that, but then you have to string signal wires from your main to your hub (tedious to setup).

An 80-20 solution would be to manufacture on site a minimal amount of steel. Something like a 10:30 steel:iron ratio would be good enough for almost any factory I think. This still offers a huge amount of compression, and if you need more steel you can always smelt more at your base.

mrvn · Post by **mrvn** » Thu Jun 22, 2017 12:24 pm

trqwe wrote:
Frightning wrote:I tend to avoid pre-manufacturing because I want the system to be automatically manage how much of stuff such as steel and circuits to produce based on demand (with a sizable buffer to handle short-term changes). Pre-manufacturing is nice for train throughput, but you then have to control how much of the various projects are made somehow, and that isn't automatic anymore (I suppose combinator shenanigans could automate that, but then you have to string signal wires from your main to your hub (tedious to setup).
An 80-20 solution would be to manufacture on site a minimal amount of steel. Something like a 10:30 steel:iron ratio would be good enough for almost any factory I think. This still offers a huge amount of compression, and if you need more steel you can always smelt more at your base.

I think it is still automatic. Your buffer just gets bigger. On top of the buffer chests for unloading iron plates you have the buffer chest for loading steel, the train full of steel itself and the buffer chests for unloading steel. Due to the compression (5 plates per steel) you now have more than 10 times the buffer. But if you produce more steel than you consume then the buffer chests will get full, the train will stop, the furnaces will be full and eventually no more iron plates will be requested by the steel smelter. At least for a short time.

Overall I find that smelters have an awfully big lag / buffer between input and output. If you have 96 pairs of furnaces for steel production then they have to over produce 9600 steel and 9600 iron plates for a total of 57600 iron ore before they stop consuming iron ore. But that is nothing compared to a 2 wagon setup with 24 steel chests for a total of 115200 steel or 576000 iron ore. Well, not nothing, 10% extra. That buffer easily drains a ore patch all on its own, even if you don't consume anything, before the back pressure stops it. For steel a single wagon train with <= 6 buffer chests is probably plenty for most factories.

As for the perfect ratio: With 9 yellow belts of iron plates, 12 yellow belts of copper plates and one yellow belt of steel you can produce 1 science pack each per second. A 10:30 ratio seems way to much steel.

Factorio Forums

My approach to rails (junction, single header) [+blueprints]

My approach to rails (junction, single header) [+blueprints]

Re: My approach to rails (junction, single header)

Re: My approach to rails (junction, single header)

Re: My approach to rails (junction, single header)

Re: My approach to rails (junction, single header)

Re: My approach to rails (junction, single header)

Re: My approach to rails (junction, single header)

Re: My approach to rails (junction, single header)

Re: My approach to rails (junction, single header)

Re: My approach to rails (junction, single header)

Re: My approach to rails (junction, single header)

Re: My approach to rails (junction, single header)

Re: My approach to rails (junction, single header)

Re: My approach to rails (junction, single header) [+blueprints]

Re: My approach to rails (junction, single header) [+blueprints]

Re: My approach to rails (junction, single header) [+blueprints]

Re: My approach to rails (junction, single header) [+blueprints]

Re: My approach to rails (junction, single header) [+blueprints]

Re: My approach to rails (junction, single header)

Re: My approach to rails (junction, single header)