[0.15.30] Splitter randomly not splitting

[qUiXui]

A splitter with two compressed input and output belts switches its behaviour when there's an interruption in the input, resulting in sometimes not splitting items at all, or just swapping items from one belt to the other. The following screenshots illustrate this, taken a few moments apart after having taking a few items off the belt between each screenshot. I had no mods active when testing this.

[TruePikachu]

I'm able to confirm that shift in behaviour, but it has to do with specifics about the belt moving, especially since it is already at full density -- specifically, when one item reaches the splitter, one of the output belts is considered "blocked" (by an item just split into that position), so the item goes onto the other belt. Technically not a bug.

[qUiXui]

I'm not sure i'd call this "technically not a bug". A splitter sometimes and randomly behaving as if it weren't there at all sounds like a bug to me, I'd expect a splitter to output items from each input to both outputs.
Anyway, I've done more testing on the following map, tests are from top to bottom #1, #2 and #3:

20170716073447_1.jpg (663.64 KiB) Viewed 4324 times

Here are my findings:

1. Splitters correctly preserve items lanes, so the problem occurs if only one (but the same) lane of each input belt is occupied.

2. If items enter the splitter on the very same tick, the splitter works correctly (Test Case 1 in my save)

3. If items enter just one tick apart, the splitter bugs out, putting one whole input belt on one output belt, either on the same or on the opposite belt (i wasnt able to see a pattern here). (Tests #2 and #3)

4. A buggy splitter may correct itself after some time (Testcase #2). I'm not sure what causes this, at first I thought it was the items leaving the chunk the splitter is in, but both #2 and #3 seem to be the same, yet #2 corrects itself, while #3 stays buggy.

5. A working splitter may bug out if its output backs up. This can be shown by activating all 3 tests simultaneously, the working splitter #1 will bug out after some time. When #2 and #3 are subsequently stopped, it will stay buggy.

---

The save for my tests is attached as well. Activating the constant combinator next to a belt starts the corresponding test, with the tests being:

#1 - Both belts release their items at the same time, the splitter works correctly, i.e. produces two mixed-item output lanes.
#2 - The green belt is activated immediately, while the red belt is delayed by one tick due to its signal coming from the decider combinator. The splitter bugs out, and remains buggy for 42 items (the answer? ), then switches lanes and puts another 5 items on the opposite belts (seems like Kovarex' memory of disbalance), and then starts working correctly.
#3 - Setups is the same as #2, yet for some reason this splitter stays buggy.

Resetting the tests works either via reload, or manually by:
1. Removing the belts between the circuited belts and the splitter.
2. Activating the constant combinator to allow the items to reach the gap, to get both belts "zeroed".
3. Deactivating the constant combinator.
4. Rebuilding the removed belts.

[Rseding91]

I'm able to confirm that shift in behaviour, but it has to do with specifics about the belt moving, especially since it is already at full density -- specifically, when one item reaches the splitter, one of the output belts is considered "blocked" (by an item just split into that position), so the item goes onto the other belt. Technically not a bug.

You're correct. They're working exactly as they should in all of the examples given.

[qUiXui]

Just to make sure: a splitter sometimes simply not doing its job when both input and output belts are connected is working as intended? If thats the case, its description is wrong, since it states the splitter splits input items 1:1.

Edit: Just to illustrate this more clearly - imo only the top splitter shows expected behaviour, the bottom one to me does not:
https://youtu.be/tvVhBCylQAA

[Patashu]

Just to make sure: a splitter sometimes simply not doing its job when both input and output belts are connected is working as intended? If thats the case, its description is wrong, since it states the splitter splits input items 1:1.

It does so only if both outputs are unblocked. If a splitter stopped working when one output was blocked, that would make it less useful for the typical case. And in general, descriptions of items should be written to be clear and easy to understand for the new user, not 100% comprehensive of all edge cases - power users can go and look their behaviour up in the wiki or test in creative mode, after all.

[qUiXui]

Except the outputs are unblocked. Anyway, I found another even more striking example of this in my opinion buggy behaviour, so here it is as my last attempt at bringing this to attention. I really do hope it is not working as intended:

splitterbug.gif (2.71 MiB) Viewed 4196 times

The expected behaviour would be when connecting the second belt, both belts should get red/green mixed outputs.