Factorio Forums

The conclusion of this topic debate: Different behavior of splitters is confirmed in 0.15. It means that the input of a splitter is not balanced, only the output is. This behavior is said to be fixed in 0.16.

OK, I'm very tired of digging up for a problem in my unloading setup, which is simple but put in a messy way.

Here is the pic:
Lower two wagons are being unloaded faster than upper two, when iron ore is being used, should be 1:1. Can anybody try and check for a problem? Probably missed something, some nasty belt or smth...

Here is the save file:
mods:
Thank YOU All very much for the time YOU have spared for looking at or solving my problem!!! I owe YOU

one cominator and some red and green wires will balance them out.
this blueprint is set up for that stop.
here is a 4 way balancer that will also lane balance (left/right side) if items being 'stuck' on the re-balancer bothers you here is a cheaper (also 2:1 splitter) re-balancer than what you are using.

Yeah I know, but it should work without them. I hope it's not a games bug. All those things should be balanced the way they are now. I should have probably put in other words, boxes are unequally drained.

Are you sure that your consumption is similar on all sides?

It seems you have lane balancers before consumers but I think other balancers you have are not line balancers so they won't guarantee pulling from each source equally.
You'd need to consult one of balancers experts tho

orzelek wrote:Are you sure that your consumption is similar on all sides?

It seems you have lane balancers before consumers but I think other balancers you have are not line balancers so they won't guarantee pulling from each source equally.
You'd need to consult one of balancers experts tho

I'm not a newbie in this game, I read a lot again and again. There are one belt, unlimited throughput, input-output perfect lane balancers, that drain them, as you can see in pic. 4outputs are not in use yet, I keep them disconnected. So either I missed something or some unexpected magic happens ;D So yeah, Balancing masters please come and help me! ;D And it would be nice if You explained it in details =)

I'm not sure if thats the reason but your 4x4 balancers are not what wiki gives for 4x4 balancers for belt balancing.
That might be causing the effect you are seeing. Unless ones that you have same performance with 2 splitters less.
Wiki link:
4 by x belts

And wiki also has a nice explanation whats the difference between full one and one you have since 4x4 is used as an example.

orzelek wrote:I'm not sure if thats the reason but your 4x4 balancers are not what wiki gives for 4x4 balancers for belt balancing.
That might be causing the effect you are seeing. Unless ones that you have same performance with 2 splitters less.
Wiki link:
4 by x belts

And wiki also has a nice explanation whats the difference between full one and one you have since 4x4 is used as an example.

They are the same, just built differently. And You can see that upper and lower balancers are identical. Well actually they are just mixers not balancers, this thing doesn't need balancing since drain input and out are balanced. And difference after use of full 4 wagons is 100 ores. After second row - 200. And it gets bigger and bigger.

Maybe you'll understand it better instead of pointing out different designs

I've also had similar problems with belt arrangements that I believe should be balanced not drawing from input equally. Two things:

1) I can't see where the lane balancing is happening; am I just missing it? My vaguely similar unloading setups have a balancer in front of each pair of inserters unloading the boxes, before the two single-lane belts merge into a dual-lane belt.

2) I can't find a link to the thread now, but there was some discussion recently that implied that 0.15 might no longer be guaranteeing that a balancer pulls from each input belt equally in all cases, with some devs commenting that they are only guaranteed to *output* to each belt equally, and that this was determined to be a bug that's fixed in 0.16... if anyone can find that thread a link would be useful so I can read it again and confirming whether I'm remembering this accurately (I read it before I found this problem occurring in my own factory)

torne wrote:I've also had similar problems with belt arrangements that I believe should be balanced not drawing from input equally. Two things:

1) I can't see where the lane balancing is happening; am I just missing it? My vaguely similar unloading setups have a balancer in front of each pair of inserters unloading the boxes, before the two single-lane belts merge into a dual-lane belt.

2) I can't find a link to the thread now, but there was some discussion recently that implied that 0.15 might no longer be guaranteeing that a balancer pulls from each input belt equally in all cases, with some devs commenting that they are only guaranteed to *output* to each belt equally, and that this was determined to be a bug that's fixed in 0.16... if anyone can find that thread a link would be useful so I can read it again and confirming whether I'm remembering this accurately (I read it before I found this problem occurring in my own factory)

Well that's a bummer. Because all I could think of was my inserters couldn't keep up. But in normal conditions they easily keep up. And if You are right I will be sad until 0.16 gets out.

So long as there is backpressure -- even a little tiny bit -- this will always happen if you make any kind of even moderately complex arrangement involving splitters in 0.15. It's a known, WONTFIX'ed, bug. You are not crazy. I have a huge lab with gigantic input-lane-balanced input/output-perfect 12->10 balancers, and a bunch of exponential-decay throughput rolling-average calculators and various bean-counters for my completely practical smelter design, and have concluded that it is literally impossible to do accurate input-side balancing in factorio 0.15 with splitters.

If you want to try it yourself: split 8 belts into two groups of 8 single-lane belts, and build 8 1->8 balancers, then shuffle outputs "perfectly" across eight 8->8 balancers (per-lane, so that's 16 8->8 balancers, each holding about 1/8th of a lane worth of items), then reshuffle those two sets of 8 lanes perfectly into 2x8 8->1 balancers, then rejoin the lanes for your 8 perfect input-output balanced belts. Unless you then consume all those outputs, I promise you, once the backpressure eventually feeds through all that crap, it still won't balance the fucking inputs

Pretty frustrating but I am at least learning a thing or two about how to do floating-point arithmetic with combinators trying to measure all of this crap...

So, we must wait for 0.16. If there's still a problem, we can take it from there.

glad i spent the time to help you try and help you.

impetus maximus wrote:glad i spent the time to help you try and help you.

I still appreciate that very much!

golfmiketango wrote:So long as there is backpressure -- even a little tiny bit -- this will always happen if you make any kind of even moderately complex arrangement involving splitters in 0.15. It's a known, WONTFIX'ed, bug. You are not crazy. I have a huge lab with gigantic input-lane-balanced input/output-perfect 12->10 balancers, and a bunch of exponential-decay throughput rolling-average calculators and various bean-counters for my completely practical smelter design, and have concluded that it is literally impossible to do accurate input-side balancing in factorio 0.15 with splitters.

If you want to try it yourself: split 8 belts into two groups of 8 single-lane belts, and build 8 1->8 balancers, then shuffle outputs "perfectly" across eight 8->8 balancers (per-lane, so that's 16 8->8 balancers, each holding about 1/8th of a lane worth of items), then reshuffle those two sets of 8 lanes perfectly into 2x8 8->1 balancers, then rejoin the lanes for your 8 perfect input-output balanced belts. Unless you then consume all those outputs, I promise you, once the backpressure eventually feeds through all that crap, it still won't balance the fucking inputs

Pretty frustrating but I am at least learning a thing or two about how to do floating-point arithmetic with combinators trying to measure all of this crap...

So, we must wait for 0.16. If there's still a problem, we can take it from there.

Why developers decided to change the behavior of splitters? I mean it was complex enough, no need to make it worse...

If every train comes in completely full, you could set up some combinators on the inserters to disable train->chest if the associated chest gets too far above average, and disable chest->belt if it gets too far below. This still isn't a perfect solution, but might be better than letting it keep creeping farther out of balance.

Doing this will make each train take slightly longer to unload, but it's better than what happens otherwise where one train car is half full while the other three are empty, and your throughput craters for a while.

SpeedDaemon wrote:If every train comes in completely full, you could set up some combinators on the inserters to disable train->chest if the associated chest gets too far above average, and disable chest->belt if it gets too far below. This still isn't a perfect solution, but might be better than letting it keep creeping farther out of balance.

Doing this will make each train take slightly longer to unload, but it's better than what happens otherwise where one train car is half full while the other three are empty, and your throughput craters for a while.

Yeah I can do that, but now I'm so unmotivated, balancing is used all over my base, kind of sad to change everything.

Please don't attach 15.42 MiB screenshot.

namek wrote:
Yeah I can do that, but now I'm so unmotivated, balancing is used all over my base, kind of sad to change everything.

Quick question - what is the actual problem?

Don't say "the problem is it's unbalanced". What problem does the imbalance actually cause? There may be a simpler way to achieve what you actually care about than anything involving, say, exponential decay rolling average floating point throughput counters.

Selvek wrote:

namek wrote:
Yeah I can do that, but now I'm so unmotivated, balancing is used all over my base, kind of sad to change everything.

Quick question - what is the actual problem?

Don't say "the problem is it's unbalanced". What problem does the imbalance actually cause? There may be a simpler way to achieve what you actually care about than anything involving, say, exponential decay rolling average floating point throughput counters.

.......

darkfrei wrote:Please don't attach 15.42 MiB screenshot.

Please don't use mobile data to browse factorio forums.

namek wrote:

darkfrei wrote:Please don't attach 15.42 MiB screenshot.

Please don't use mobile data to browse factorio forums.

You know what?

I used to never think size was a problem. I had ~120 down at my house. Then go somewhere with really, really bad wifi and try to use a laptop to browse the forums. At one place I'm commonly at I get 5 down on a really good day.