What is a load balancer?
A load balancer takes arbitrary inputs and gives every output the exact rate you asked for, sending the leftover to a sink. The inputs need not be equal and need not be saturated: you type what arrives and what each machine must receive.
What comes back is a build order — the splitters and mergers to place, the exact rate on every belt, and one line per surplus container. Nothing is averaged and nothing is simulated: each requested rate is hit exactly or the problem is refused.
How is it different from a belt balancer?
A belt balancer gives every output the same rate; a load balancer gives every output a rate you choose. That one difference brings in the surplus, which is the part most hand-built layouts get wrong.
| Belt balancer | Load balancer |
|---|
| Inputs | saturated belts | any rates, equal or not |
| Outputs | N outputs, all the same rate | one rate per output, typed by you |
| Surplus | none, the input is divided entirely | whatever the targets do not claim |
| Typical use | feeding N identical machines | feeding a mixed line, or tapping a bus |
Both obey the same rule about belts: capacity is a hard constraint, and a problem with no layout under the tier rate is refused rather than drawn.
Why must the surplus be consumed?
Because a blocked output is skipped by the Splitter round-robin, which hands its share to the other outputs instead. The targets then receive more than the rate you asked for, and the exact solution collapses — quietly, because the belts still look fine.
So the surplus line is always drawn, and what you attach to it is a real decision: another factory, a container you empty, an AWESOME Sink. Anything that keeps taking items will do; anything that backs up will break the plan upstream of it.
This was a checkbox once, and the checkbox changed nothing in the layout — the graph was identical either way, only the wording of the message moved. Declaring an intention with no effect teaches nobody anything, so the condition is now stated once, as a warning, and the line is drawn whether you tick anything or not.
How is the surplus split across containers?
Onto as few outputs as possible, with none of them over the belt rate. 600 items/min of surplus does not fit on a Conveyor Belt Mk.4, which carries 480 items/min, so it is packed onto two outputs rather than drawn as one impossible belt.
The packing fills the lightest container first and adds an output only when nothing else fits, because two partly filled containers are easier to keep drained than one full and one empty. A measured example, three inputs of 300 items/min feeding two targets of 150 items/min on a Mk4:
- total in: 900 items/min;
- claimed by the targets: 2 × 150 = 300 items/min;
- surplus: 600 items/min, split across two outputs at 250 and 350 items/min — both under the 480 items/min ceiling;
- cost: 6 splitters and 4 mergers, no loopback.
On a Mk6 the same problem needs no splitting at all: 600 items/min fits on one belt, and the plan drops to 2 splitters and 2 mergers.
What if a target exceeds the belt capacity?
Then no topology can help, and the tool refuses instead of drawing something unbuildable. A target is a machine you declared and it is fed by one belt, so a target above the belt rate is a problem about your factory, not about the splitting.
The floor for this mode is the larger of the biggest single input and the biggest single target — below it, no layout exists at any level of cleverness. The solver tries a single trunk belt first, then one division per input, then a pre-split per input when the return belt still overflows, and keeps the first arrangement that saturates nothing. If none of the three fits, it names the floor and the belt tier that clears it.
Frequently asked questions
Can inputs have different rates?
Yes, and they need not be saturated either. Three inputs of 200, 100 and 60 items/min feeding two targets of 90 and 45 items/min is an ordinary problem here, and it is solved exactly with no belt over the 270 items/min of a Mk3.
What is a sink?
On this page a sink is the destination of the surplus: the belt carrying whatever your targets did not claim. In game it can be another factory, a container you empty, or an AWESOME Sink — anything that keeps accepting items, because a sink that backs up breaks the round-robin upstream of it.
Why is my layout refused?
For one of two reasons, and the message says which. Either the targets ask for more than the inputs supply, and the shortfall is named — 480 items/min in against a target of 500 items/min is short by 20 items/min. Or no topology keeps every belt under its tier rate, and then the floor is named along with the belt tier that clears it.
How few buildings does it use?
Fewer than the arithmetic suggests, because the tree is pruned. Taking 70 items/min out of a saturated 480 items/min Mk4 belt is a division by 7/48, and the full tree would be 31 splitters and 23 mergers; the pruned plan is 5 splitters and 3 mergers. It walks 480 down to 240, then 120, then 60, tipping each unwanted half into the surplus, and takes 10 from one last 60 divided in three: 60 + 10 = 70, with 410 items/min going to the sink.
