My first factory, tackling flow optimizing

[MrLumie]

Hey guys!

I've just started playing Factorio a few days ago, clocking only 7 or so hours in my first factory, and so far I'm having a blast figuring out the principles of factory design, and spending way too much time coming with solutions for all sorts of problems. One such problem was the problem of maintaining 100% belt usage for each resource while also handling over-, and underproduction. I'd like to walk you through the steps (and ultimately, mistakes) I took, and how I've arrived to my current version (which is still far from perfect, but it'll do for a while)

So, at first, the problem itself was merely just "sort resources into individual lanes that will feed the assembly section, and create a buffer to prevent overflow. So after some tinkering, I've arrived to this:

20200531225400_1.jpg (1.34 MiB) Viewed 5932 times

On the left you can see my furnace section that processes every raw resource in one place, and on the right the resources are sorted and then stored. Later, I've added a bit to feed some of the iron plates back into the furnace area to create steel beams, utilizing a splitter to 'cut off' the iron plate supply once the steel quota is reached:

20200531230001_1.jpg (1.22 MiB) Viewed 5932 times

But I soon had to realize that this simply won't cut it. Even with two inserters feeding each chest, this solution was prone to overflow on higher influx, and the chest now posed a huge bottleneck for feeding the resources into the rest of the factory. After trying to 'save' this solution by trying to optimize out the bottleneck, I've soon accepted that it was back to the drawing board.

Enter v2:

20200601031544_1.jpg (1.26 MiB) Viewed 5932 times

This time, it was all about handling throughput and overflow. I've figured that instead of using chests (which didn't work out all that well), I'll feed the materials directly into the facility, and loop the leftovers back into this area. The left belt feeded the resources into the facility, while the belt in the middle carried the leftovers. The inserters placed through the 'vein' managed to clean the belt even with maximum throughput, slowly feeding the resources back into the bottom chest from where 6 inserters proved to be enough to fill the belts and ensure that the 'artery' will always have 100% belt usage. But this, too, had a major flaw. The 'slowly feeding' part was an understatement. I've not realized at first, that the same bottleneck presented itself when dripping the resources down the boxes, having constant buildups even with moderate amounts of leftovers. This system could not survive a full-on overflow. So it was back to the drawing board again, but this time, I knew I'm on the right track, and only changed the inner structure of the mechanism.

Enter v3:

20200601213009_1.jpg (1.4 MiB) Viewed 5932 times

This is the current version of my throughput balancing system. This time, the 'loop' is more natural, the top splitter could be set to 'cycle' or 'collect' resources (on this image it's set to collection) while the bottom part, similar to v2, feeds resources back into the loop to ensure maximum throughput. if the 'artery' were to overflow, the top splitter diverts the excess resources into the collection belt, ensuring that the flow never stops. So in the end I've managed to come up with a solution that maximizes throughput, and prevents overflow in the case of overproducing resources.

Bonus GIF of my current baby:

ezgif.com-optimize.gif (15.28 MiB) Viewed 5932 times

And although I'm kinda proud of my creation, I can already see its shortcomings. Basic belts work fine with it, but the inserters won't be able to keep up with faster belts, and a larger rework will be required if I ever go double belt. Still, I think I did good with this one.

[5thHorseman]

Very cool! Nothing like what I'd build, and I love seeing others' takes on how to use the tools they gave us to solve problems.

What you're doing with multiple different item types randomly strewn on belts is called "sushi belts" in the community, and a lot of thought has gone into them by many players. Some absolutely hate them and others love them. I'm a bit torn on it myself and prefer dedicating belts to a single resource in most cases, and at the very most 2 different resources, one on each side. Looks better to my eyes is all.

Keep at it!

[MrLumie]

What you're doing with multiple different item types randomly strewn on belts is called "sushi belts" in the community, and a lot of thought has gone into them by many players. Some absolutely hate them and others love them. I'm a bit torn on it myself and prefer dedicating belts to a single resource in most cases, and at the very most 2 different resources, one on each side. Looks better to my eyes is all.

Keep at it!

Hey man!

I personally prefer this approach as I won't have to balance things for each individual resource, I'm only concerned about total throughput this way. Might cause some fluctuation on a per resource base but I'm convinced that it balances out in the long run.

[Premu]

I don't really understand the purpose of this design - as such it just locks a lot of ressources in an endless loop which won't be consumed until taken out manually. And sooner or later any buffer will fill up if nothing is taken out.

That's actually the problem with Sushi-belts - unless controlled very tightly they will gte blocked sooner or later. There are some usecases in which they can work, but these need circuits to ensure a proper balance of materials on the belts.

[MrLumie]

I don't really understand the purpose of this design - as such it just locks a lot of ressources in an endless loop which won't be consumed until taken out manually. And sooner or later any buffer will fill up if nothing is taken out.

That's because I closed the loop on the top for testing, and because the rest of the factory was nonexistent at that point. Since then I've expanded the loop to go through the whole factory area (well, the current area, at the least), feeding various assembly stations on the way. So worry not, the resources are being consumed

[foamy]

I'm not clear on this 'overflow' thing: why not simply let the items back up? If you're producing more stuff than you need that's good! The backpressure will turn off the production machines automatically for you.

Except for smelters, which kind of irritatingly will smelt to a full stack unlike every other production building in the game limiting itself to a small number in the output slot before locking off. :v

[valneq]

Except for smelters, which kind of irritatingly will smelt to a full stack unlike every other production building in the game limiting itself to a small number in the output slot before locking off. :v

Built-in buffers for items that you consume a lot!

But I agree: there is no need to worry about items on belts backing up. That is just an easy self-regulating part of the factory: everything that is not needed will automatically shut down. Non need to use power switches or the like.

[foamy]

Except for smelters, which kind of irritatingly will smelt to a full stack unlike every other production building in the game limiting itself to a small number in the output slot before locking off. :v

Built-in buffers for items that you consume a lot!

But I agree: there is no need to worry about items on belts backing up. That is just an easy self-regulating part of the factory: everything that is not needed will automatically shut down. Non need to use power switches or the like.

Well... yes and no. Power switches are handy for when you get to beacons, which don't shut down, or if you need to do emergency turnoffs on account of insufficient generation. But for the simple case of unbeaconed assemblers or miners? Just let them run

[MrLumie]

But I agree: there is no need to worry about items on belts backing up. That is just an easy self-regulating part of the factory: everything that is not needed will automatically shut down. Non need to use power switches or the like.

The problem in my case is that resources come mixed on a single belt (since I'm using a sushi-belt smelting area) before being sorted into their respective belts, and overproducing one resource to the point of building up on the input lane will clog the flow for the other resources as well. Also, this could cause a buildup on the smelting area as well, which (since it's a sushi belt) might cause it to clog up fatally, requiring me to manually get it started again. On top of that, I'm prone to try and design systems that will not fail in any circumstance, it's just a occupational habit of mine I guess.

[foamy]

I mean, build how you want, obviously, but a smelter area -- or other high-flow applications with minimal recipe complexity -- aren't the usual use-case for a sushi belt. They're best used for complex assembly. The labs are the prime example; another would be a mall, or yellow science assembly.

A sushi smelter is... hrm. With some tricks with splitters and/or circuit networks you can ensure the input materials are on in some given proportion of the total belt (or total quantity; I prefer proportion -- scales better). Output materials on the same belt is tricker and in the specific case of furnaces where you don't *know* what a given output will be even more so. My general inclination would be to do most of the management on the input side: Only feed resources into the sushi loop is needed, and use a filter inserter wired to only pull a specific material from the sushi belt if there's somewhere to put it.

In essence you'd take your output belt (or, in fact, possibly even the same sushi belt your inputs are on!), feed it through a set of filter splitters to sort it, then use priority splitters to direct material either directly onto the factory or, if that's full, into a chest (which also outputs to the factory via priority splitter, with output direct from the smelter taking priority there). The chest can then be read for fullness and used to set the filters on the inserters. There's some more sophisticated circuit stuff that could be done that would avoid the need for the chest altogether, too.

[MrLumie]

I mean, build how you want, obviously, but a smelter area -- or other high-flow applications with minimal recipe complexity -- aren't the usual use-case for a sushi belt. They're best used for complex assembly. The labs are the prime example; another would be a mall, or yellow science assembly.

Recipe complexity might be low, but there are multiple recipes that a furnace innately works with, and this "one does all" kind of nature is why I chose to build it that way. It doesn't matter what they are producing as long as they are producing. Of course, input must be managed to ensure a decent ratio between different raw resources, but that's the price I'm paying for not having to manage the number of furnaces for each individual resource.

In essence you'd take your output belt (or, in fact, possibly even the same sushi belt your inputs are on!), feed it through a set of filter splitters to sort it, then use priority splitters to direct material either directly onto the factory or, if that's full, into a chest (which also outputs to the factory via priority splitter, with output direct from the smelter taking priority there).

That's basically what I do now, the only difference is that the splitter for the chest is at the end, not the start, so the materials go through the whole factory first. I could place it at the start, but it's too much work for such a minor optimization, as the only benefit would be some saved time when I'm draining the belts into the chests, and maybe being able to keep the smelters running while the main loop is shut down.

My general inclination would be to do most of the management on the input side: Only feed resources into the sushi loop is needed, and use a filter inserter wired to only pull a specific material from the sushi belt if there's somewhere to put it.

My general approach is that resources are always needed, and production almost never stops, the only two exception being rebuilds and when I've overproduced a resource so much that even the chests are about to be full, which will hardly ever happen. Overproduction in general is fine as it will help keep the flow running when underproduction kicks in.

[DudebroPyro]

My worry with this system is - what if the ratio at which resources are consumed doesn't match the ratio at which they're produced? Then the sushi belt backs up. You can't assume that "resources are always needed" unless you're 100% sure your ratios match up - which is gonna be a very tricky endeavour as you build up your factory, constantly changing what resources are being consumed in what ratios as you add new assembly lines.

To see what I mean, imagine you make a green circuit assembly, which takes 1.5x copper and 1x iron. Easy enough to balance the input so far. Next, you build an ammo assembly, which only takes iron. Now, you have to calculate exactly how much ammo per green circuit you produce, to get an exact ratio, and make sure you're mining at the correct rate. If you're off, then one of copper or iron will build up, until eventually you end up with a stretch of belt that's full of one metal, but the assemblers need the other, so they stop running, so resources stop being consumed, so the entire belt grinds to a halt, so the other metal never reaches the assemblers. That's the eternal problem with sushi belts.

The chest buffer system is just that - a buffer. It'll delay failure, but won't prevent it. You're gonna have to be constantly thinking about the system and monitoring it for underproduction and overproduction and adjusting values every time you change anything about your factory. General wisdom is that buffers should not be added intentionally (except for some specific cases), since they solve almost no problems, but are very good at hiding problems so you don't know anything is going wrong for a while. But once the buffer fills up, you end up having to deal with it anyway. You say the chests will "hardly ever fill up" but that's only true if you make sure to constantly update the input ratios before they do; it's only not a problem if you rush to fix the problem every time it manifests. Then, sure, the chests give you a time buffer to fix it before the factory stops. But it won't be self-regulating.

This is why most builds tend to separate resources. This way, if you have an overproduction of one, that belt backs up and there's absolutely no negative effect. If there's underproduction, the factory slows down, but it's trivially fixed by increasing production - there's no risk of clogs or deadlocks. The overall idea is that it's easier to overbuild the amount of furnaces and ensure you have enough production (or more), than it is to have to monitor ratios carefully without any leeway to either underproduce or overproduce. At least when the factory is gonna be expanding and changing - if you're building to some known goal that you don't expect to ever change, then sure, either method will work fine since you know in advance exactly how much of what you need, and can supply it in whatever way strikes your fancy.

[MrLumie]

My worry with this system is - what if the ratio at which resources are consumed doesn't match the ratio at which they're produced? Then the sushi belt backs up. You can't assume that "resources are always needed" unless you're 100% sure your ratios match up - which is gonna be a very tricky endeavour as you build up your factory, constantly changing what resources are being consumed in what ratios as you add new assembly lines.

Of course, resources will not be used at the same rate as they are produced. That's kind of my aim, too, to have a slight overproduction. The whole point of this little overflow management system is to handle both over-, and underproduction.

The chest buffer system is just that - a buffer. It'll delay failure, but won't prevent it. You're gonna have to be constantly thinking about the system and monitoring it for underproduction and overproduction and adjusting values every time you change anything about your factory. General wisdom is that buffers should not be added intentionally (except for some specific cases), since they solve almost no problems, but are very good at hiding problems so you don't know anything is going wrong for a while. But once the buffer fills up, you end up having to deal with it anyway. You say the chests will "hardly ever fill up" but that's only true if you make sure to constantly update the input ratios before they do; it's only not a problem if you rush to fix the problem every time it manifests. Then, sure, the chests give you a time buffer to fix it before the factory stops. But it won't be self-regulating.

It will be partially self-regulating. Automatically cutting off supply of one material when the buffers are about to fill up is quite easy with some basic circuitry, and it solves the problem of overproduction. This will only cause problems with materials that are not smelted in a 1:x ratio, as a few pieces could get stuck in the smelters once supply is cut off (even though it's temporary, and the supply will be shortly restarted once the buffers fall back under the threshold). To be honest, I was thinking about separating those from the rest anyway.

The overall idea is that it's easier to overbuild the amount of furnaces and ensure you have enough production (or more), than it is to have to monitor ratios carefully without any leeway to either underproduce or overproduce.

I don't have to monitor ratios, just the changes in the buffers, which I can also automate. If the buffers are growing (which is what I expect to happen), supply will be eventually cut off automatically, and will turn on and off at regular intervals to maintain an acceptable amount of 'cached' resources. And if the buffers start to run dry, I could just as easily have a light or something signal me that X material is being underproduced, and I can increase production before the buffers run dry. This way, the flow of resources never have to stop, better yet, I'll maintain 100% belt throughput at all times, unless I stop the flow manually for some reason (e.g. restructuring the main loop). All in all, the only scenario where manual intervention will be required is when something is underproduced, which is something you'll have to deal with manually anyway. But having a signal for it definitely helps.