Page 1 of 1
[1.1.104] Priority Splitter producing gaps with full input
Posted: Thu Feb 22, 2024 10:58 pm
by AntiElitz
Related:
viewtopic.php?f=23&t=111444
Repost as topic was phrased poorly and described wrongly.
Situation: red box input is permanently full and never has any gaps
Expected bahavior: prioritized side of the output also has no gaps
Actual bahavior: sometimes there is a gap on the prioritized output (yellow circle)
clarification: I only talk about the right side of each lane.
safegame attached in related thread.
Re: [1.1.104] Priority Splitter producing gaps with full input
Posted: Thu Feb 22, 2024 11:40 pm
by Tertius
This is expected behavior. You seem to expect that splitters move items from the left lane to the right lane, if the left lane isn't full and the right lane is. However, splitters don't do this. Both lanes are strictly separate.
The left lane behind the splitter has a gap, if there isn't enough input from both left lanes at the input. Or with other words: if there is a gap on both left input lanes, this gap continues to exist at the (priority) output lane.
Also if the one input is set as priority, and there is a gap at its left lane, it cannot magically pull items from further up the input or from the right lane. If there is also a gap at the other left lane, there will be a gap at the output.
Re: [1.1.104] Priority Splitter producing gaps with full input
Posted: Fri Feb 23, 2024 7:29 am
by SoShootMe
Tertius wrote: ↑Thu Feb 22, 2024 11:40 pm
You seem to expect that splitters move items from the left lane to the right lane, if the left lane isn't full and the right lane is.
I think you have misunderstood. The unexpected behaviour is that the right lane of the splitter's right input has no gaps, but the right lane of its prioritised (left) output does.
I suspect it will somehow be due to update order (perhaps related to the second splitter and sideloading onto a fast belt further up) but even if that's the case I'm not sure exactly why. Regardless of the reason I agree with the OP that it is not expected behaviour.
Re: [1.1.104] Priority Splitter producing gaps with full input
Posted: Fri Feb 23, 2024 7:40 am
by quyxkh
It's going to happen. If the left belt ore is one or two ticks ahead of the right belt ore, the splitter can start passing the left ore, see the right ore and have to decide which belt to send it to. Since the left belt's currently busy (in that lane), it sends it out the right belt. But then there's a tick or two after the left-belt ore passes where the next right-belt ore can't possibly have gotten there yet, so that much of any gap on the left belt gets passed along.
The way to guarantee full compaction is with a buffer, the secondary belt feeds a buffer-reload splitter that prioritizes refilling the buffer but the primary (left, here) belt runs through a refill splitter that prioritizes taking from the main belt, that way there's always a buffer ore available to fill the gap if it's at all possible. If the left belt's demand is spiky you can even have it refill its own buffer.
Re: [1.1.104] Priority Splitter producing gaps with full input
Posted: Tue Feb 27, 2024 6:05 pm
by AntiElitz
quyxkh wrote: ↑Fri Feb 23, 2024 7:40 am
It's going to happen. If the left belt ore is one or two ticks ahead of the right belt ore, the splitter can start passing the left ore, see the right ore and have to decide which belt to send it to. Since the left belt's currently busy (in that lane), it sends it out the right belt. But then there's a tick or two after the left-belt ore passes where the next right-belt ore can't possibly have gotten there yet, so that much of any gap on the left belt gets passed along.
The way to guarantee full compaction is with a buffer, the secondary belt feeds a buffer-reload splitter that prioritizes refilling the buffer but the primary (left, here) belt runs through a refill splitter that prioritizes taking from the main belt, that way there's always a buffer ore available to fill the gap if it's at all possible. If the left belt's demand is spiky you can even have it refill its own buffer.
Splitters have an internal buffer that is supposed to take care of that.
Re: [1.1.104] Priority Splitter producing gaps with full input
Posted: Wed Feb 28, 2024 3:19 am
by Rseding91
AntiElitz wrote: ↑Tue Feb 27, 2024 6:05 pm
Splitters have an internal buffer that is supposed to take care of that.
They don't have any internal buffers.
Re: [1.1.104] Priority Splitter producing gaps with full input
Posted: Wed Feb 28, 2024 10:01 am
by Bilka
Rseding91 wrote: ↑Wed Feb 28, 2024 3:19 am
AntiElitz wrote: ↑Tue Feb 27, 2024 6:05 pm
Splitters have an internal buffer that is supposed to take care of that.
They don't have any internal buffers.
Anti means the extra transport line length mentioned here:
https://factorio.com/blog/post/fff-287
Re: [1.1.104] Priority Splitter producing gaps with full input
Posted: Wed Feb 28, 2024 8:13 pm
by Rseding91
Bilka wrote: ↑Wed Feb 28, 2024 10:01 am
Rseding91 wrote: ↑Wed Feb 28, 2024 3:19 am
AntiElitz wrote: ↑Tue Feb 27, 2024 6:05 pm
Splitters have an internal buffer that is supposed to take care of that.
They don't have any internal buffers.
Anti means the extra transport line length mentioned here:
https://factorio.com/blog/post/fff-287
Ah, my error. I read "buffer" and interpreted it as a separate inventory that items were held in.
Re: [1.1.104] Priority Splitter producing gaps with full input
Posted: Sat Mar 23, 2024 11:52 pm
by xykite
I tried minifying the Ximoltus save file and ended up with this example that's pretty far removed from the original. Here are three copies of the same blueprint; the speaker is set to beep when the belt has < 4 iron.
- three.png (1.6 MiB) Viewed 407 times
- A looks pretty normal and the speaker is silent.
- B shows some of the iron plates spilling out of the priority output lane, and the speaker is silent. This is relatively easy to reproduce.
- C is like B but additionally the speaker beeps in time with the spilled items, indicating a non-full belt. This is difficult to reproduce, see attached save.
Maybe this is something to do with belt compaction? e.g. the items joining the belt from the side could be pushing the line of iron plates slightly back into the splitter, which restricts flow and causes some of them to spill into the other splitter lane.
Is this the same problem, and is it a bug? I had thought full belts always had 4 items per lane, so C doesn't look right to me.