Factorio Forums

Can someone explain to me the splitter behavior in my experiment?
The splitter in the center is the one I'm interested in. The left side is just a random setup to produce uneven demand.
The arithmetic combinators on the right side count the total number of items transported on each belt.The constant combinator was used to start both input belts exactly at the same time.
After a couple of minutes the bottom counter is already 500 items ahead (6k vs 6.5k).
I always believed splitter drew evenly from both inputs but this is apparently not true. It seems to be more like 45:55.

i noticed something similar with my trainstations using splitter to balance the unloading of the chest
whenever the belt is not moving as fast as possible, the left (belt direction) part of the splitter is always drained fatser then the right
wzhat i do is merge 2 inserter outputs with a splitter, still using 1 lane only, and merge 2 of the splitteroutputs onto both sides of a single belt after a third splitter scrambling the belts to account for uneven demand of the beltlanes (to lazy for blueprint atm)
and it does get very noticable when after a coulpe hundred wagonloads 2 out of 4 chests that should be perfectly merged on a single belt are empty and the others have not even lost 20% of their content

this must be a relatively new bug as i dont recall this happening ever before my current factory (started in 0.15.33) or i just did not notice
and no matter it is very close to gamebreaking as it makes it almost impossible to build a beltonly-unloadingstaion that lasts for more then a very few dozen trains without the train being stuck longer then neccecary unkess MANUALLY fixed

Well, measuring like this with one belt segment won't be accurate. One belt tile holds a fractional ammount of items. (7.111 items/tile). Depending on circuit network timings, this could significantly alter your readings.

The most likely reason for the imbalance, is the fact that a stack inserter has a longer pickup time(and it picks up more items/sec) than a fast inserter (since it takes a while to pick up 12 items from a moving belt); leading to an imbalance since you are then merging two red belts into one, then voiding the single output belt.

Well, measuring like this with one belt segment won't be accurate. One belt tile holds a fractional ammount of items. (7.111 items/tile). Depending on circuit network timings, this could significantly alter your readings.

I don't think so because it's measuring in pulse mode. Also as joonnnyy correctly mentions, one can observe the same behaviour when unloading e.g. train cars.

The most likely reason for the imbalance, is the fact that a stack inserter has a longer pickup time[...]

I think you are misreading me, I'm concerned with the input balance. The output side is deliberately unbalanced.

joonnnyy wrote:and no matter it is very close to gamebreaking as it makes it almost impossible to build a beltonly-unloadingstaion that lasts for more then a very few dozen trains without the train being stuck longer then neccecary unkess MANUALLY fixed

Since the imbalance is about 8-10% I just went ahead and set my trains to leave at 10% remaining cargo.

whynotboth wrote: I think you are misreading me, I'm concerned with the input balance. The output side is deliberately unbalanced.

The fact is... splitters do not swap lanes and you're causing a backup from trying to push 1.x belts down 1 belt.

Since you are merging more than one belt of capacity into one belt of capacity... any imbalance will be propagated upstream, causing backups at whatever source. Since splitters do not change lanes of items, imbalanced lanes will stay imbalanced lanes until you put in a dedicated lane input balancer.

You need one of those (each belt line needs one like this): or something similar.
Main idea is that regardless of output consumption side input is always consumed from each side equally.

For more info I'd recommend Wiki section on belts/balancers.

Please notice that this is only about balance between the two input belts, not between individual lanes.
@orzelek I think that is a lane balancer.

whynotboth wrote:Please notice that this is only about balance between the two input belts, not between individual lanes.

@orzelek I think that is a lane balancer.

It is the individual lanes though. The splitter works per lane for each belt, and the splitter does not swap the lanes of the items. Your test is fundamentally flawed, it only proves that stack inserters move more items per minute than fast inserters.

Krazykrl wrote:It is the individual lanes though. The splitter works per lane for each belt, and the splitter does not swap the lanes of the items. Your test is fundamentally flawed, it only proves that stack inserters move more items per minute than fast inserters.

Still doesn't offer an explanation. Why should the splitter prefer the top lane from the bottom belt over the top lane from the top belt?

whynotboth wrote:

Krazykrl wrote:It is the individual lanes though. The splitter works per lane for each belt, and the splitter does not swap the lanes of the items. Your test is fundamentally flawed, it only proves that stack inserters move more items per minute than fast inserters.

Then remove the two inserters - result stays the same.
Edit: Or maybe not...? Still doesn't offer an explanation. Why should the splitter prefer the top lane from the bottom belt over the top lane from the top belt?

This comes back to a possible measurement error then. Repeat the test with more detector segments, since 1 tile of belt holds 7.111 items. If there was such a discrepancy with splitters, the issue would be noticed immediately, and quite a few count-perfect belt balancer designs would break.

Here's a version with the output side mirrored. Still the bottom input belt draws faster. I'll do a version without circuits next.

Here you go: All four chests started full at the exact same time. The second and fourth from the top emptied exactly in the same moment. The other two have each 2.3k left. That big a discrepancy surprises even me. And evidently it also happens when the lanes are perfectly balanced.

EDIT: ok now I think this is definitely some kind of bug. Because this strange behaviour randomly appears and disappears again.

0.15 has a bunch of issues like this. For perfectionist results -- and sometimes for just tolerable results -- your best bet is to downgrade to 0.14 or wait for 0.16.

I would be surprised if this has ever been /explicitly/ promised -- as to do so would be to foment avoidable temper-tantrums over trivial differences -- but, speaking broadly, I believe 0.16's in-game splitter and belt dynamics are intended to be more-or-less precisely as they were in 0.14 (except, hopefully, for their computational/UPS cost, which should be noticeably improved), and that the developers have decided that several acknowledged 0.15 bugs, like this one, simply aren't worth fixing since the code-base which manages them is a doomed legacy branch.