For green circuits, it takes less transport to move the green circuits than to move the materials to make them, so you should make them centrally and distribute the circuits.
Copper wire, on the contrary, is used in many things but takes up more space than copper plate, so you should make it locally.
In practice it can go both ways. Many of the production chains that take green circuits as an input require such low quantities that 1-2 assemblers is more than enough, so the marginal complexity of trickling them to where they're needed is low. And they only require the two basic input resources that are needed almost everywhere, so the alternative of making them on site isn't that complex either.
However, if you are trying to do a megabase (where you keep playing post-endgame and basically scale for the sake of scale), your green circuit demand shoots through the roof, and you will end up sinking half of your basic materials into making green circuits. At that point the plumbing itself becomes so complex to maintain high throughput that centralizing green circuits is an economy of scale decision. Additionally, the production ratios (number of assembler units you use for each intermediate product) will change, so it's easier if all of the green circuit production is in one place than to make individual changes in a lot of places.
Green circuits are distinct because (1) they don't save that much space compared to the basic materials you input to make them, and (2) demand for them is modest at first, but becomes a primary bottleneck if you're going for scale, and (3) their inputs are resources you need almost everywhere, so they're already there anyway. Most of the other resources for which you consider centralizing production, you do it because you save a ton of bandwidth by centralizing, or because demand is always high, or because the inputs are more complex to move (such as fluids).
In practice demand for green circuits is so huge primarily because of demand for blue circuits, so I will often make all circuits offsite and ship them in. The 20+:1 compression ratio you get from moving blue circuits offsite is a much bigger win.
> it doesn't really matter because for 99% of players the factory won't fall apart due to this decision
"Do I Need Kubernetes?"
> it doesn't really matter because for 99% of developers the infrastructure won't fall apart due to this decision
Factorio and Software Engineering :)
I tend to have a whole bunch of belts running from west to east, each belt carrying one type of item. When I want to add a new product, I put a splitter on each belt that carries and ingredient, with the second output branching down under all the belts carrying other products until it reaches a vertical line of assemblers. The output of those assemblers combines to a new belt that continues east.
The main factory ends up looking almost triangular [0], with vertical strips of assemblers dangling off the hypotenuse. One of the advantages of this approach is that scaling is simple, just add more assemblers and faster belts! Though it's possible to eventually reach a point where even the fastest belts can't carry enough products. In that case, you can just add another vertical strip of assemblers with separate inputs.
[0]https://media.discordapp.net/attachments/741107040079970314/...
As you allude to later, it's not really about green circuits for a megabase. Since blue circuits require 24 green circuits (20 directly and 2 for each of 2 red circuits), your huge demand for green circuits comes mainly from blue circuit production. It makes sense to centralize blue circuit production, so most of your green circuit production should be right next door, which is both on-site and centralized. But the green circuit production that isn't feeding directly into blue still doesn't really matter whether it's on-site or centralized.
I find it much easier to lay down just iron/copper belts and upgrade them as needed -- upgrading speed in cases where adding parallel lanes is inconvenient.
- using machines efficiently (in the sense that a central production facility means idle-capacity can be used elsewhere)
- replacing production efficiently, I.e. yolo build a potato-quality factory now so that it’s actually producing, then expand it to hyper efficient maxed productivity modules in all the machines between maxed speed beacons later (so your resources go further and you don’t need to spend as much time building remote bases), but do not interrupt production forever to rebuild everything during the transition.
Yolo-building with a high quality strategy to replace components is also a great strategy for startups. In either case the real limiting resource is manpower.
And I typically target about 8 belts of green circuits, to feed a nonstop-rocket shop (avoiding the major transition off belts altogether.) Get a balancer design off the Internet. It’s fine. :)
Sure you can, it's called a "sushi belt" and with some simple combinators, it can work reasonably well.
But that's what I had anyway in my last game, a big central line with a lot of the essentials. I think next time I'll go for a central line with just iron and copper and mini bases that take from it, or something. More trains as well, bringing in ore from all over the map.
Can make your train routes/efficiencies easier to manage.
This and parent post quickly proved my wrong.
I thought the same thing, but I think copper plate stores 100 in a stack and copper wire stores 200 in a stack.
I don't know what that means for inserters. (like low density structures - can stackers move more of them, even though you can store less in one slot?)
Certainly if you need a very small volume in one specific location and already have copper and iron present you can slap down an assembler making copper wire and another making the circuits, but that's generally far less space efficient than just pulling them in from the bus.
I think your parent was making a different argument.
Sure you use green circuits everywhere, but your compression ratio on belts is only 2.5 : 1. Not much better than gears, and I don't think anyone recommends centralizing gear production.
I too centralize green circuit production, but I think it's on the edge of what's reasonable
IMO, the thing that pushes it over the edge for me is that it takes 2 inputs (copper and iron), whereas resources that I distribute like gears or pipes only have 1 input.
That said, your compression ratio on trains is double that again, because the green circuits have a stack size of 200.
If you're going for one of those crazy ridiculous high output post-endgame factories, the sheer complexity of running 8+ belts of one resource and branching off 2-3 belts at a time, then having to double that to go from 1k SPM to 2k SPM is way too painful. That's why most of the factories you see north of 2k SPM aren't main bus designs (aka well organized monolith), they're modular designs ("microservice" based). I put that in quotes because at those scales the sub-factory for creating a single input resource might be bigger than a whole base used for launching a rocket.
The analogy actually applies really well to software engineering: for a practice that works really well for 99% of the players (main bus), at a certain level of scale the approach breaks down, and you need a different approach to deal with scaling past that point.
As evidence for that, I usually use a main bus design to get to the endgame, but once I start the megabase scale climb, I break the factory out into discrete, networked (by train) modules in order to keep the resource distribution problem under control.
> unable to adapt to circumstances
One side main bus should be adaptable to many circumstances. I wonder what you mean by it cannot.
It’s like the point of “most web apps don’t need distributed architectures until much later.”
300 copper (= 600 copper cables) + 200 iron => 200 green circuits in a stack.
Sometimes with caching it makes more sense to consolidate. Sometimes the scale can cause latency issues! It's about balancing tradeoffs
Microservices, on the other hand, are overrated and unnecessary in most cases they are applied.
Nah, electronic (green) circuits are high-volume but low-complexity to build. They are a good example of something that should not be produced centrally, because if you do, you have to invest a lot in high-volume transport to get them where they need to go. Much better to build dedicated electronic circuit factories wherever they are specifically needed.
Silly analogy to programming: Microservices. It makes sense to have a microservice to perform, say, user authentication, which is complex and only needed occasionally. It does not make sense to have a microservice to implement printf formatting, because you'll be calling it way too often and it'll waste a ton of network bandwidth. Better to import a string formatting library into each service.