[kovarex]Weird behaviour with splitters and inserter stack size

[TheUnknown007]

See attached save file.

This is about the left and the middle box of the contraptions.
All boxes start with 200 iron (-2 or 3 because the insterters already grabbed some)
Place a power pole on the hazard concrete to start the contraptions.

The only differences between the two contraptions is that the left one has the inserters limited at stack sizes of 2, the right one is at the max of 3.

In the right splitter contraption, everything works as expected: the two boxes empty at te same rate.

In the left splitter contraption, it doesn't: the middle box empties faster.

I don't know why. I would think it shouldn't matter, for two reasons:
- the stack size doesn't seem like it should matter, because all belts are always full
- both belts go directly into a splitter, so that should take one from one, and then one from the other regardless of output.

[Philip017]

yeah ive also noticed that my splitters aren't true 50/50 at times, especially noticeable when you have it set up to seem to be even unloading but end up with uneven amounts in the chests

example.jpg (229.52 KiB) Viewed 3396 times

in this example you will see that the trains first wagon has become empty while the second still has ores and even though my belt is supposed to be split evenly, after a while the top chests will become empty and i will loose half of my capacity if i left it long enough

i think this is new in 15.31, but also present in 15.32 didn't notice it before this but that doesn't mean it hasn't been happening. this will hopefully be fixed with the belt optimizations coming in 16 so don't think that they will be "fixing" this for 15.

[Rseding91]

Thanks for the report however I can assure you splitters are working correctly. They haven't had a functionality change in over 4 major versions.

[golfmiketango]

Thanks for the report however I can assure you splitters are working correctly. They haven't had a functionality change in over 4 major versions.

With all due respect, in all my years of working with information systems, I have never once heard anyone say "it can't be broken because nothing has changed in years" who was (in my assessment) thinking clearly, open-mindedly, and holistically about their business logic. Splitters are not islands and of course they can be broken. Indeed OP is precisely correct. I've been banging my head against precisely this for months now in my smelter build, and have come to the conclusion that it's just irredeemably broken, and I have to wait until 0.16.

[daniel34]

Thanks for the report however I can assure you splitters are working correctly. They haven't had a functionality change in over 4 major versions.

Then how do you explain this? (taken at 0.4x speed)


On one turn the splitter takes from the right belt (OP's middle belt), on the other turn it takes from both belts. (It does this continuously until the chests are empty.)
This leads to the right belt emptying at 2x the speed of the left belt and empties the chest from which the right belt was fed while the chest that feeds the left belt still has half the contents. Interestingly enough this only happens because the stack size on the inserters was overridden to be 2. If you remove the stack size override prior to starting the test then the chests empty equally.

Not only does it take 2x the amount from the right belt, it also outputs 2x the amount onto the right belt (or in this case splitter).

EDIT: I've done some more tests and apparently it only happens when a splitter feeds directly into another splitter, as in the example above. I couldn't recreate it after placing a belt between the two splitters.

[posila]

As far as I know, splitter cares about outputs - it tries to keep both outputs saturated and if output belts are mixed, they should have similar ratio of different items on them.

I'll let kovarex decide if it should also care about even usage of inputs.

[kovarex]

Yes, there seems to be some imperfection.
I compared the results of 0.15 and our current 0.16 with the belts logic changes, and it seems to work as you would expect in 0.16 so I'm moving this to "Fixed for 0.16"

[posila]

Yes, there seems to be some imperfection.

I take it issues like this should be considered bug in the future.