Factorio Forums

When designing belt balancers it usually takes a large amount of time to properly test it. Therefore I decided to write a tool to help me with that. No more need to painfully test every input ingame. Now I also decided to release it to the public.

You can get it from github.

Because of technical reasons the balancer that is tested needs to have each input and output as a belt piece. For example this 12 to 12 balancer:



Also side loading is a no go.

There are some commandline options that I will explain:

-f=FILE Loads the blueprint string file FILE, if not found tries again with %APPDATA%\factorio\script-output\blueprint-string\FILE
-t2 Tests all throughput combinations where exactly two inputs and outputs are used.
-tallcpu Tests all throughput combinations where more or equal to two inputs and outputs are used. (The 12 belt balancer needed 10 minutes on my pc with this option)
-i=N Specifies the number of iterations the simulation should run. Default is 2 * (2 * nSplitter + nInputs + nOutputs + 1)
-time Times the complete testing time needed.
-s Does suppress the ongoing progress display. Useful if you pipe the output to a file.
-benchmark times only the simulation time needed to run the specified amount of iterations.

-f=FILE is mandatory. Then there is also -gpu using CUDA, but the overhead is usually larger than the performance gain. There was one case with the big 512 belt balancer where this option did actually win against the cpu, but for all sane balancers (<= 32 belts), cpu wins. -tallgpu does also exist, but it crashes my display driver more often than not.

I usually have a cmd window open with the line:
BeltBalancer.exe -f=test.txt -t2
Then I can just save my balancer I am working on as test, swap to the console hit the up arrow and enter.

Happy balancer building!

Meh bored testing balancers. Let's automate.
Factorio/10

Oh great I was thinking about doing the same! Thank you!

Edit:
Your 12 by 12 balancer seems interesting. Do the loopbacks prevent throughput loss when output lanes are blocked?
Can you share the blueprint?

hansinator wrote:Do the loopbacks prevent throughput loss when output lanes are blocked?

No, it is based on 4 3 belt balancer that go into 3 4 belt balancer. Those loopbacks are part of the 3 belt balancers and do not prevent troughput loss in such situations.

hansinator wrote:Can you share the blueprint?

Yes, I already did: https://www.reddit.com/r/factorio/comme ... er/d8jolix

Cool stuff, cool stuff..

But I ask myself, why didn't someone not write just a mod to CREATE belt balancers automatically?
Define input belts and output belts, click on "Generate" and finished.


And another cool stuff is here:
https://wiki.factorio.com/Splitters/Weighted_splitters
where the first link points to
https://www.reddit.com/r/factorio/comme ... balancers/
and there you need to click on the pics like I did:

I released version 1.4 which features support for vanilla blueprint strings. By default it additionally reads from clipboard if you don't specify a file.

ssilk wrote:But I ask myself, why didn't someone not write just a mod to CREATE belt balancers automatically?
Define input belts and output belts, click on "Generate" and finished.

Nexela did it already, Picker Mod Extended.

Very nice tool, but there's something I don't understand while testing the 4x4 balancer. So, with the splitters after it, it should work whatever lines I cut, right?
When I cut input line 4 and output line 2, line 1 is still full, but lines 3 and 4 aren't completely compressed.

So, with the splitters after it, it should work whatever lines I cut, right?
When I cut input line 4 and output line 2, line 1 is still full, but lines 3 and 4 aren't completely compressed.

This seems to be a problem with the game, not the balancer design. I tested by building lots of these next to each other, and got some moving at full throughput, while some had the exact same problem you described. Probably something to do with how splitters work, as I managed to "switch states" (i.e. from near-full to full throughput or vice versa) a couple of times by removing and adding a splitter or piece of belt (temporarily blocking and reopening output 1 seemed to be most reliable).

See also this screenshot (green arrows indicate balancers working as intended):

pieppiep wrote:When I cut input line 4 and output line 2, line 1 is still full, but lines 3 and 4 aren't completely compressed.

That is thanks to the sorting ability of splitters. The only way to make a truly throughput unlimited balancer is to get a normal throughput unlimited balancer of twice the size, split each input belt side to its own belt and run that through the larger balancer. An example for a true 4 belt throughput unlimited balancer:



That gives you lane balance as well but is highly impractical. My tool does not simulate actual items on belt but instead a number for throughput, thus if it says 100% it can still have some weird behavior in Factorio. But if it is reporting less than 100% you can be sure that your balancer is not throughput unlimited.

This is strange!
I have to think about this to really understand what's happening here.
It's something about the sorting you say. Interesting.

May it be possible to output the 4 IO-Combinations with lowest throughput? So one can improve his balancers ... please.

pieppiep wrote:
This is strange!
I have to think about this to really understand what's happening here.
It's something about the sorting you say. Interesting.

Bugs aside, splitters can be thought of as obeying the following restrictions, in order of descending precedence:

1. Items are never destroyed or created and items do not move to the other lane of the belt when passing from input to output
2. Items do not ever stop moving at the input terminal of a splitter if there is room on either or both output belts to output them.
3. Items of a given type will be distributed evenly between the output belts (not the lanes).
4. When only a single belt can accommodate a given output but inputs are available from both input belts, the left side is chosen.
5. Splitters do what they want

Think of these like Asimovian robot rules. So if the splitter can't do #2 without violating #1 then it is required to break rule #2 and respect rule #1. In theory it will try to obey all the rules simultaneously but conflicts are common between them, in which case the lower numbered rules are always (in theory) respected even if this means breaking the higher numbered rules, and no exceptions are permitted, i.e., a splitter will break rules #2,#3,#4, and #5 to comply with #1 even if it could comply with all the other rules by breaking rule #1 "just a little bit".

I make one change to this Belt balancer... Just before the 2 output splitters I move it all one extra over and do a mirror of the input side. one in the middle and then the final 2 splitters. I find it balances all belts better than the ones shown here, it also mixes the sides of the belt so input and output switch sides of the belt. (should remove the 3/4 not full thing.)

I have never really tested it so it might not work... But I have always used the design. Never had real issues with it either.

Is it possible to configure this analyzer to recognize splitter priorities? The program evaluates both the following balancers equally reporting 50% minimum throughput in some input combinations.

With priority:
Copy blueprint

Without Priority:
Copy blueprint

Speaking about weird cases:
2x2, but balances belt sides too. It has 100% throughput under full load, but utility outputs only 50%.

Problem with your balancer is input: no crossover between left and right input belt.

To get lanes balanced you only need to invert half the lanes, like this (stolen from tzwaan):
Copy blueprint

Your balancer: This one:

One with priority actually should work.
It works as an infinite progression which starts as 2:1:1, but goes to 1:1:1 over time (in Factorio in should be pretty fast)

Math:

I respectfully disagree, it's not lane balanced. (because you invert both lanes)
This one is:
Which splitters shoud have what priority? they are not set in your blueprint.

I trough you answered on different message
well, looks like it not 100% correct, but the point stands: it messes 100% of input to output