d4rkc0d3r / factoriosimulation Goto Github PK

For testing balancers using BeltZip.

Test case:

0eNqdlNFOwzAMRX9l8nOKmqzroI98BgihdGQjUpZEiQObpv477jbGRDsR+pTEio/vlS0foDVJ+aAtQnMAvXI2QvN8gKg3Vpo+hnuvoAGNagsMrNz2L7XzQcVYRG80ogrQMdD2Te2g4R3LTscgbfQuYNEqg1cQ0b0wUBY1anUSdHzsX23atlSu4belMPAuUqKzfX2CFeXdgsGeLlXXi/uFEgNUIhFhExydJ2FDJD8B5yT57NAl9Kn3MCgw/8v3AF9+00do1STnYgy1uKDWMmKG7bMunuO6ngYvf9ja3kAvL+j8TmVpvv8/OEfvw8QBGG0aL6cMAB9F8emjLzJ8c/Fv42c6TT4tgOPSaK5WFAMjKY9iomilkXalwuxT4/ssJq/C2iSX4uyRyE/a0+8PFeKRXVeVqJfzZV3TCvgCmGysyg==

The program does not process priorities for splitters

When testing the attached balancer with -tallcpu, the program instantly finishes and results in a minimum throughput of 6900%.
balancer.txt

Testing a 2 to 4 Balancer gives me:

Loading a 2 to 4 balancer with dimensions 4x6 and 5 splitters
Output balance: 2/2
Input balance: 4/4
Throughput under full load: 100%
Min Throughput with all combinations: 100%

Shouldn't it be:
Input balance: 2/2
Output balance: 4/4

Standard 4-balancer minus 1 input should work as a 3:4 balancer. In the screenshot I slowed down the belts a bit to avoid the splitter quirk. However the program doesn't think it's balanced.

Loading a 3 to 4 balancer with dimensions 4x7 and 4 splitters
Output balance: 3/3
Input balance: 0/4
Throughput under full load: 100%

Flipping the balancer around would not work as a 4:3 balancer as 1 output belt would get more items pushed onto it than the other 2. But 3:4 does not have the same problem; all 3 belts are pulled evenly.

Please add build instruction to e.g. build it under linux

Hey d4rkc0d3r, i'm having a problem, it doesnt find my inputs/outputs.
this is a image of the blueprint i want to test:

the blueprint string is:
H4sIAAAAAAAA/6WVwWqEMBCGX0U8x0Wzbi8lzyJWp0vAnUgy0l0k794oUpB01ZiLiuT3m0w+xlYlnWrqLqnEKBuFRoyjxBaeomBG3rHuxEivHkQqCR4pw/rh nr9rQxnpGk2vNGVf0FFqLVuSfC9p+k4SgXYZywBJkoQJ/P7jrFfGrVIoxqfIruzlLpa1UkMzv+UOHpTmZ9PFHvtvc+scn6mX20lu7mHL42G/5vJIzfnl5rUq gMo96kdgmNvjAf9UA2izE3mUUEWMUFvoLZ/y0z4VMTXvlTy4MaDvWrn7O5VX6JItgwL7wQ2SI2pOFZze/HJgR0CRbZ7dOD1rpnCUV1vhDa+KKK1irNpq1b5V /D+p1EC+VXt2hDcuvm/XgGmXz+tXLLv8YRF+qiK1nxpo0JhUn4DtL8s3V83mBwAA
this is the output of the script:

I'm sure it loads the file, because if i try an file that doesnt exist, it gives an error.

I was testing the idea that an n-n UTU balancer can function as an m-m UTU balancer without looping outputs where m<n

The following (on the right) 6x6 ballancer when limited to the left 4 inputs and the right 4 outputs loses throughput. Despite being marked as 100% on all categories with your script. This is the only combination of 4 inputs to 4 outputs that loses throughput.
The balancer on the left is the fixed version.

Blueprint:
0eNqlmetqq0AUhd9lfpvi3NVXKeWQtEMREhUvh4bgu5+YUMhJXVVn/QqG5JvlnrX37K0XcTgOoWnLqhfFRZTvddWJ4vUiuvKz2h+n7/pzE0Qhyj6cRCKq/Wm6Cl9NG7pu17f7qmvqtt8dwrEXYyLK6iN8iUKOyWpI1xzLvg/tw9/V+JaIUPVlX4a7oNvF+U81nA7XXxZySUoimrq7/r2upvUnRSp/sYk4i2Kn1YsdJ4FPULUdqtMlqI6AyiWoiYCqJailYprOQx0FlfNQT20UUJpRGwWgOaUU3L5MKamIKilTgQBIRVGRVo2ryIyhsjttMtYsLSKdlP/WqDJA/ZlPw7W6tZ9tff2E3Ow/bvJdOuuhb4apwv5cx22JhU4XYuGjVOebVWdMZsCY50xmIKpKN0VY/R5hReUZ1KgoD3tAjTi9Hhzsb174KNvwfv+Fm1vDRPnXAcXUKbZSsaNchpT7TXGQCzuXUS5DGnOKCrTqlNozC6gyylcG0FRMXXzYdbOuLmod5QIUA6pRhFRLUVGEHVXBUPvtKap+rgdqbo2MqpLr1sjJc1k9+q+sgP0Ml4oajCuSOuzVmgCZuARNn7ZhMUENNdCtvBcubdHQyKUt2lsubcHYYLi0BWODyciWXK5LonzTdJL/HgqbRp1jIASWS0Wkkeo+JehpraaooP+2hqnWkGpjdgnSXIyDYByp5yWQSj0wkdmaTttS/ea6NVwa8yxBgg7ZScqzoEN2KspdSCM11UGNhmkdINVyx7r0q0q2czEjPgyw54aFtaKpGQ9GPKccDGYGn1JUMDN4STkZaVWUkxGVyzoUAS7rENVSJwaKgKOoN61vyf0tUvHw5ioRf0Pb3bvpTBqfK6/z1EnvxvEfYKrWJQ==

I download the BeltBalancer_v1.10 archive In it I run BeltBalancer.exe a window opens and immediately closes I don't understand what the reason is help

-tall's tip: tests all throughput combinations where more or equal to two inputs and outputs are used N specifies how many threads will be launched and is 1 by default

This seems to suggest that it tries every combination with 2 or more inputs and 2 or more outputs, I tested this with a 64 to 64 balancer that I'd expected to take forever to test like this.

I mean seriously there's some 3.2*10^38 permutations to iterate through for that set up, and the program ran in fractions of a second only telling me the throughput under full load = 100% while -t2 testing every 2 inputs to every 2 outputs takes minutes.

I'd hoped to leave it on over night and see if I have any unforeseen bottle necks built into the design so if this is a 'feature' to stop the program causing problems with large balancers that will never finish I have a few suggestions.

A providing a break out/quit method other than CTRL + Break (force terminate the program)

B including ongoing statistics while only testing a sample of each case in each pass,

Case example 1: 2 inputs or outputs, initially target tests at the two closest together inputs/outputs (25% of iterations as probably multiple places where inputs are adjacent), the two furthest apart (5% of iterations probably only one instance of the furthest apart but go for the next most and the next most until all these slots are taken) and a middle ground (45% most cases are somewhere in the middle of the two extremes my 64to64 has a lot that're 48 apart so test a number of there) and continue through the rest systematically.

Case example 2: N inputs again test inputs that're as close together as possible, let as evenly distributed as possible take the place of the mid ground, and with the largest gaps (with clusters on each end) take the as far apart as possible, continuing systematically.

My best guess is somewhere around 1000 iterations per case per pass is a good number, it'd let you pick 32 input sets in a case and 32 output sets in a case and iterate them against the other, of each case. In my 64to64 that'd be 1024 tests * 3949 cases and would take about as long for a single pass as the -t2 test takes, you could reverse engineer the number of tests based on that idea each pass should take about the same amount of time as -t2 would on the same data, it wouldn't provide certainty for all options obviouslty, but it could show roughly how accurate it is sure one test might have an minimum through put far lower than the rest that you never hit but the chances of that happening are minimal, so long as all inputs connect to all outputs

Here's how I'd display the data

And so on filling it in as the program does passes (I rather like the pattern of test 2 in to N out then 2+1 to N-1 then 2+n to N-n all the way to N to 2, I don't know why although filling in the NtoN cases (and the near misses) first, then the Max/2^n to Max/2^m cases before systematically doing the rest would likely be the most useful for the most people)

For the count perfect test introduce say Max inputsMax outputsinputs in case*outputs in case *some constant as the number of items added at each input (to give the balancer the best chance of being able to pass count perfect if the number of items isn't at least divisible by the outputs that's not a fair test) and count the items that output on each line if this number is the same on all lines (or within 1 given there's going to be loss to empty sections of the balancer) then it passes otherwise it fails, to be totally count perfect it should pass every time (at least on the 2^n to 2^N cases)

And again if you link it to the ability to quit you can let it keep running as long as the user can stand and have it save the output as a .txt or .cvs file for the user

By the way I know huge amount of criticism in here but actually still love the program wouldn't have spent over an hour filling a issue report with ideas if I didn't. wish I could be more help than just ideas.

The Lane balancer I made gives the wrong max throughput number in your belt balancing tool.

With beltzip I often only get one belt out of a splitter, and if I cross it in front of the other splitter output then the program does not give it full throughput. I'm not trying to do any lane manipulation; I just need the full throughput so balancing can be correctly calculated. The left case can be worked around by using the other splitter output instead. The right case much more problematic.