[0.17.23] Splitter bug?

[ahydra447]

I was just testing a 3 -> 2 belt balancer and it didn't work as expected. Turns out, splitter behaviour seems to have changed (??). When fed a continuous stream of input on both input belts, they will output on the same side (or the opposite side) output belt, but not a mix of the two. In the picture attached, you can see the iron is always on the right and copper on the left, whereas I would expect each output belt to have copper, iron, copper, iron, etc.

Have I misremembered how splitters work, or has this behaviour changed in 0.17?

Thanks,

ahydra447

[tehfreek]

This behavior was changed back in 0.16.16.

• Changed splitters so they work more intuitively. The left and right lane splitting is now completely independent. The decision whether item goes to left or right output is now independent of the item type.

[Khagan]

It seems to depend on the precise relative timing of the two streams of items; in a quick test I got a complete exchange instead.

splitter.png (68.55 KiB) Viewed 3403 times

I suspect that you can't straightforwardly get the output you expect and simultaneously preserve full compression of the belt (unless the two inputs happen to be precisely synchronised).

[ahydra447]

This behavior was changed back in 0.16.16.

• Changed splitters so they work more intuitively. The left and right lane splitting is now completely independent. The decision whether item goes to left or right output is now independent of the item type.

This is not what's happening though, is it? The splitter is handling the two lanes as one combined input, viz.

- output starts as left lane
- item comes in on left lane, so goes to left lane and output is now right lane
- item comes in on right lane, so goes to right lane and output is now left lane
etc.

If the two were independent, the behaviour would be
- output starts as (L -> L, R -> R)
- item comes in on left lane, goes to left lane and output is now (L -> R, R -> R)
- item comes in on right lane, goes to right lane, output now (L -> R, R -> L)
- item comes in on left lane, goes to right lane, output now (L -> L, R -> L)
etc.

The latter pattern is what I was expecting.

@Khagan: yes I also observed that in some tests. The way I had set up the test was to put everything except the panel down first, then place the panel to start both inserters simultaneously. The inserters don't saturate (one lane of) the belt, but instead i just let it run until it was backed up for a clearer picture.

The problem this causes with the 3:2 balancer is that for three input lanes full of A, B and C, instead of each output lane being ABCABCABC, you get ABBABBABB and ACCACCACC - technically the combined sum of the two outputs is balanced, but each lane is not.

ahydra

[kovarex]

I don't even know what is the bug there. If you put two inputs and one output, it will produce a mix. But the current behaviour is ok, as both inputs and outs are alternating. Setting an input priority might do what you expect.

[ahydra447]

I don't even know what is the bug there. If you put two inputs and one output, it will produce a mix. But the current behaviour is ok, as both inputs and outs are alternating. Setting an input priority might do what you expect.

Tried with input priority but same result.

Essentially this behaviour reduces the utility of splitters, and breaks balancer setups where all inputs are not of the same type. Not technically a bug, sure, but I don't think it's a good design.

On a side note it appears the very helpful wiki page containing balancer setups from 1->1 to 8->8 has been deleted can that get put back in please?

Thanks,

ahydra

[coderpatsy]

The wiki is not meant to be a repository for blueprints, and so the balancer blueprints were removed. You'll have to go to a dedicated third party site like factorioprints.

[Trebor]

Got something similar in 0.17.66:

Screen Shot 2019-08-22 at 1.27.51 AM.png (1.05 MiB) Viewed 3140 times

Note the items are moving but at 1/3 the normal speed because all four belts connect to yellow.