> Gonna disagree there: green circuits (and their descendents) are needed often enough and in high enough volumes that it absolutely makes sense to bus them.

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.

> Sure you use green circuits everywhere, but your compression ratio on belts is only 2.5 : 1

That said, your compression ratio on trains is double that again, because the green circuits have a stack size of 200.

To me the "main bus" design feels like Java OOP maximalism. Maybe some sound principles behind it, but feels too heavy-handed, unable to adapt to circumstances. Or at the very least, it's not any fun.

It's actually the opposite. Having a main bus tends to make your factory more flexible and easier to adapt for improved technologies / throughput.

Main bus designs work really well for building one factory to launch a rocket because the resource demands aren't so high that you run into belt scaling problems.

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.

That's what Java OOP people would say too. ;)

It's like the Event Bus pattern, instead of designing loads of point-to-point supply chains you build one big one where everything is pushed to, allowing random factories to consume the products alongside the bus according to need.

Fun is relative, however main bus is scaleable, up to certain level.

> unable to adapt to circumstances

One side main bus should be adaptable to many circumstances. I wonder what you mean by it cannot.

In my experience the main bus is perfectly adaptable until approximately “winning the game” (launching the first rocket). Making some broad assumptions, you need to reserve about 16 belts worth of bus width as an upper bound and that’ll be plenty for 99% of players.

It’s like the point of “most web apps don’t need distributed architectures until much later.”

This is the most interesting, friendly, respectful, online discussion about bussing I've ever read! Usually bussing is such a controversial divisive topic... Kind of like the "tabs -vs- spaces" of transportation and logistics.