Just simple building modules

[LazyLoneLion]

Don't know if it's obvious or there are better projects, just wanted to share how I'm using them. And I'm still newbie in Factorio.

Those are projects considered for using with logistic bots (without any belts). They are simple. They waste fewer resources waiting for a feed into an assembler.

First one is for production with 4 assemblers from one chest and to another chest. It's four assemblers + one input chest + one output chest. Note two long-handed inserters for each assembler.

1 chest => 4 assemblers => 1 chest

Factorio-1-4-1.JPG (67.14 KiB) Viewed 4915 times

I suspect it's nothing new as for this forum?

Another one is not so neat. And not "one" for that, but two of them
It's mostly for modules automation chain. They take 15/30/60 seconds to produce and 4 modules of the lower level for input, so it makes sense to use 4=>2=>1 assemblers production scheme. But I don't like belts for that. So, here there are two similar projects.

production chain 4 assemblers => 2 assemblers => 1 assembler

Factorio-4-2-1.JPG (106.53 KiB) Viewed 4915 times

Call it "nothing aligns with anything".
Suppose somebody could make it nicer?

[AutoMcD]

Pretty common with anything built after logsitics chests I assume.
Here is how one of mine turned out:


For higher volume things like circuits and wires it really makes a difference to insert straight from one assembler into the other because of the stack bonus.

[LazyLoneLion]

Looks nice

Pretty common with anything built after logistics chests I assume.

But I wanted to maximize the number of the assemblers per request chest. Used four per chest instead of two.
And I have made balanced construction line for modules. Every module mk2 needs two assemblers of mk1 and so on. I wanted to not use any belts and use as few of chests as possible. Hoped the project will look nice, but got what I got Something very asymmetric.

[BlakeMW]

I just use a requester and provider chest per assembler - no sharing. Chests are just not expensive enough to bother economizing on and it works well with beacons.

[LazyLoneLion]

I just use a requester and provider chest per assembler - no sharing. Chests are just not expensive enough to bother economizing on and it works well with beacons.

Chests aren't expensive. Items (like modules) could be expensive. Every chest makes you have extra items in a buffer, and not in the production process. And you already have some buffer inside the assembler anyway. And every chest needs at least one more bot to fill it. Often more then one. That was my thought process.

[Qon]

I just use a requester and provider chest per assembler - no sharing. Chests are just not expensive enough to bother economizing on and it works well with beacons.

Chests aren't expensive. Items (like modules) could be expensive. Every chest makes you have extra items in a buffer, and not in the production process. And you already have some buffer inside the assembler anyway. And every chest needs at least one more bot to fill it. Often more then one. That was my thought process.

But you can set the request amount lower and use more chests if you think small buffers are important.

[BlakeMW]

I just use a requester and provider chest per assembler - no sharing. Chests are just not expensive enough to bother economizing on and it works well with beacons.

Chests aren't expensive. Items (like modules) could be expensive. Every chest makes you have extra items in a buffer, and not in the production process. And you already have some buffer inside the assembler anyway. And every chest needs at least one more bot to fill it. Often more then one. That was my thought process.

In practise I find it's usually better with more chests because it makes it simpler to control material feed to the assembler, also for high throughput assemblers (gears, electronic circuits, processing units and the like - especially when using modules) you can actually get seriously inserter-limited and might need several requester (or provider) chests per assembler just to provide enough places to put inserters, in the most extreme setups (alternating rows of beacons and assembler 3, with speed3 in the beacons and prod3 in the assemblers) you need up to 5 fast inserters to keep the assembler busy.

The other thing is for most things it makes sense to use smart inserters and set a limit using a logistics condition - not that there's anything wrong with limiting the chest - but a logistic condition works more precisely. It's also wonderfully flexible for things like engines, for instance with the Electric Engine assembler, you can use "Engine Unit > 40" for inserting materials in and "Electric Engine Unit < 60" when inserting the finished electric engine out. Then the system will keep 40 engine units for if you need to make a train and won't make more than 60 electric engine units. This kind of flexibility is also useful for things like speed modules where you usually want to keep a stock of speed1 modules, but also make speed2/speed3 modules, and for setting small limits like only keeping a stock of 12 productivity 3 modules. A smart inserter on input will entirely prevent over-production (i.e. with condition Satellite = 0 will only insert materials if there are zero satellites), something which can't be done by limiting chests.

Smart inserters are also one of those things which are really cheap by the time logistic network is available, there's no reason not to use them liberally. AFAIK in 0.13 we'll even be able to set logistic conditions on basic inserters.

[LazyLoneLion]

The other thing is for most things it makes sense to use smart inserters and set a limit using a logistics condition... Smart inserters are also one of those things which are really cheap by the time logistic network is available, there's no reason not to use them liberally.

That's a good point, really. I should try using it next time.

A smart inserter on input will entirely prevent over-production

Well, not "entirely"
At least you'll have overproduction because of the input and output buffer in assemblers. And there still will be input materials in the requester chests. It won't be possible to use those speed-modules-1 for yourself, they will be supplied only to speed-module-2 production. And for every additional requester chest you'll have that buffer. Maybe we could avoid overproduction with power switch to assembler in 0.13

[AutoMcD]

too much effort, limiting chest to a stack or two is easy.

[Qon]

If it's a normal block of assemblers just producing all the random stuff you need with logi bots then you will not care that much about throughput and so on. Then using active provider means that you can move the assembler block more easily because you don't have any full output chests that needs to be emtied out into storage chests. And when you place down a blueprint of the thing to where you want to move it then you don't double your buffer of every item because you moved your previous buffer to active providers.

But in something like a rocket production factory where everything works all the time you don't need big buffers since you have production capacity of everything enough to fill demand. I would then use passive providers limited to one stack. Then I can keep the small buffers close to the requesters with smart planning instead of everything taking an unnecessary trip to storage and then requesters. That's just 2 trips instead of one where both are much longer than the one. And just a single stack in the passive provider isn't a big deal when reconstructing.

Both have valid uses. Just know their properties and select the one that has the properties your base needs.