[kovarex] [0.16.25] Splitter prioritization fluke with two outputs

[Jon8RFC]

https://youtu.be/3QUctMhFC5o
To make viewing easier, hover over the video, click on the gear icon, then click on speed and set it as low as it will go.

As shown in the video, the prioritization is set to output on the right, and this was a freshly built splitter in 0.16.25.
When the inserter is working, occasional gaps show on the prioritized belt above it. When the inserter is not working, the belt above it is fully compressed.

Sometimes the gaps are very obvious and look like 3/4 of a plate is missing. Often times, the smallest gaps are hard to spot because they're only off by a few pixels, but in the video you can easily see the 1/4-1/2 missing plates. I didn't see if the tiny gaps made it into this video, but I can sometimes spot them when I'm playing if I watch follow the belt across the screen.

Strangely, the problem occurs less frequently as I add more inserters, and the fewer full/half plate gaps make it harder to spot, but the problem does still occur. I can only record 30 seconds with FRAPS, otherwise I'd slow down the game speed and record a few minutes of it so that it's blatantly obvious.

I have not tested on prior 0.16 versions. I only played my save now because the compression was fixed in 0.16.25

[Jon8RFC]

The attached images show the difficult-to-spot small gaps (one in middle of red, and another two plates to the right) which aren't always obvious (slow motion is helpful), and are what frequently show up in the 2+ inserter setup, with fewer large gaps.

The larger gaps you can spot very easily playing the video yourself.

[kovarex]

Small side-note:
There is now a debug option called transport-line gaps, which shows the gaps.

[Jon8RFC]

Strangely, the gaps never showed up and it was always one color. That was at the time of the post though, I haven't tried in 0.16.26.

EDIT: Neat! Thanks for letting me know...I was just using the regular "transport lines" debug option. That's pretty cool.

[kovarex]

I tried it in 0.16.26 and it doesn't seem to happen anymore, so i guess that it was fixed already.

[Jon8RFC]

It still happens when I try in 0.16.27. If there's a gap on the input side and something is taking from the non-prioritized output side, the gap exists instead of being filled in by prioritization.

Here's a video of a new splitter being placed and setup, and the gaps existing:
https://youtu.be/X-AEHD7o9hk
(strangely, for me, the video hangs at various times in Chrome unless I play it in IE...it worked in Opera yesterday, but today it's not working in Opera anymore, either)

[Kayanor]

Reopened on request by OP.

[quyxkh]

I don't understand, blue belt lanes can only deliver one item every three ticks, so if a low-priority input is routed to satisfy low-priority output demands at a time when no gap has been detected on the high-priority belt, there are two subsequent ticks during which no low-priority item is available to fill any newly-arrived gap on the high-priority input. If you want to always have items available for gap-stuffing, split off a supply dedicated to high-priority gap-stuffing.

[Jon8RFC]

Attached is a save with a 0.16.27-placed splitter, in which I don't use the other belt/inserter at all, and a gap still makes it through. It happens about 15 seconds into the save when you load it up.

I have fiddled so much, I can't recall if it happens again a long time later in this save, or if it was before I made this save that it happened another time, a very long time after the power switch was off.

If you watch this video, you can see that multiple gaps make it through, well after the power switch is off and well after the belts behind are fully compressed on the belts and the splitters. Slow it down to 0.25 speed for ease of viewing. It happens a few times in the video, but this particular spot is very obvious:
https://youtu.be/oTojl7cZi0s?t=10s

[quyxkh]

I don't see that gap when I run it, I loaded it up, did `/time` and got 15 days, 23 hours, 54 minutes and 13 seconds, then I did /c game.speed=1/30, installed my compression-testing rig on that belt, `/time` after it was up was 15:23:54:17, and no gap ever appeared. The rig counts -6 per tick (two lanes, three item slots per blue-belt-lane-tick) and +9 per item (9 item slots per item), and records the latest two low-water marks in the running total. Your save hit its last low-water mark 2 ticks after startup (that's two ticks with no item deliveries, expected for a compressed blue belt), and didn't miss a single delivery for ... well over 25 game minutes so far.

[Jon8RFC]

I don't see that gap when I run it, I loaded it up, did `/time` and got 15 days, 23 hours, 54 minutes and 13 seconds, then I did /c game.speed=1/30, installed my compression-testing rig on that belt, `/time` after it was up was 15:23:54:17, and no gap ever appeared. The rig counts -6 per tick (two lanes, three item slots per blue-belt-lane-tick) and +9 per item (9 item slots per item), and records the latest two low-water marks in the running total. Your save hit its last low-water mark 2 ticks after startup (that's two ticks with no item deliveries, expected for a compressed blue belt), and didn't miss a single delivery for ... well over 25 game minutes so far.

All I can figure is that your compression testing rig is something that replaced belts/splitters and backed up the plates, which would nullify the scenario.

Please load it without using your compression testing rig and see if the gap appears, because if you say you don't see the gap (without touching the belts or anything), then we will know that the determinism is broken or that something very fishy is going on. If you hit F4 and enable show-transport-line-gaps you'll spot it more easily.

Here's a recording of loading the save and doing nothing more, and it is clearly shown to pass a gap when it shouldn't.
https://youtu.be/JsJH6QhLNZA

[quyxkh]

I think I see what's going on here, you've got a gap that's sneaking through because it's so small the sensor never sees it: since the belt moves three slots per tick, the item moves from one belt segment to the next on the same tick with or without that one-slot gap -- in particular, it appears at the splitter's input sensor the same tick either way. That would also explain why my rig missed it, the read pulse happens on the same tick. Wherever the plates after that gap are going, they're going to get there on the same tick as they would if the gap hadn't been there.

[kovarex]

I tried the save in our internal 0.16.29 (together with related fix for splitters) and it seems to be doing ok, so I'm moving it to "resolved for the next release".

[Jon8RFC]

Awesome!

[Jon8RFC]

It looks like gaps still regularly slip by on the prioritized side with a newly-placed 0.16.29 splitter, and an inserter taking from the low-priority belt:
https://youtu.be/6_OGCpwec3k