The effect shows up more subtly in the #4 inserter, but the traffic there is clearly identical in both lanes.
blueprint
[kovarex] [0.16.22] Belt back pressure inconsistency
[kovarex] [0.16.22] Belt back pressure inconsistency
Watch the inserters, you can see that one lane's getting much more backpressure transmitted than its belt partner even though the items are moving at the same rate (and I think there "should" be no backpressure at all, since these are priority splitters with clear output paths, but I wouldn't call that a bug).
The effect shows up more subtly in the #4 inserter, but the traffic there is clearly identical in both lanes.
The effect shows up more subtly in the #4 inserter, but the traffic there is clearly identical in both lanes.
Re: [0.16.22]backpressure glitch (?)
It took me al while to understand what you mean because at first I just looked at what the splitters do.
Especially when watching insterter #8 and the splitter above it I always see a free output on the splitter but still it somehow seems to decide to not accept input for a short time. This ist what you meant, right?
Another thing I noticed when watching Inserters #5 and #6: somehow the first steel of each "grab" of inserter #5 seems to jump ahead. (The alternative was the rest of the Items being blocked for a short time but that is impossible because then both inserters wouldn't be synchronous.)
Especially when watching insterter #8 and the splitter above it I always see a free output on the splitter but still it somehow seems to decide to not accept input for a short time. This ist what you meant, right?
Another thing I noticed when watching Inserters #5 and #6: somehow the first steel of each "grab" of inserter #5 seems to jump ahead. (The alternative was the rest of the Items being blocked for a short time but that is impossible because then both inserters wouldn't be synchronous.)
Re: [0.16.22]backpressure glitch (?)
I don't understand this report, sorry. What is backpressure on a belt?
Re: [0.16.22]backpressure glitch (?)
Sorry if I invented a term, I mean what happens when exit lanes are at capacity so the input lane traffic backs up. Watch the #6 inserter gradually get out of step with the one loading the other lane.
I think now that this is a not-a-bug, an accident of timing that I missed noticing, I can see that the lane merge makes the priority-merge splitters take different number of items per lane,
I think now that this is a not-a-bug, an accident of timing that I missed noticing, I can see that the lane merge makes the priority-merge splitters take different number of items per lane,
Re: [0.16.22]backpressure glitch (?)
But there is nothing blocking inserters 4 and 8 and they are always free to insert steel on the belt! I do not understand why these inserters are going off sync with their "brothers". Can anyone explain?
Re: [0.16.22]backpressure glitch (?)
There is something blocking them actually. The splitter they feed has one end of it's output blocked.
Re: [0.16.22]backpressure glitch (?)
So? If one end of a splitter is not blocked, it should not block the input at all! I was watching the animation closely, and the right side (as we see it) of the belt input and output of the right side of the splitter is always free. As such, inserters 4 and 8 should never be blocked? Maybe that is a defect in itself?
Re: [16.22] Belt back pressure inconsistency
remaking this gif with 'show info' on would be helpful
Re: [0.16.22]backpressure glitch (?)
The small S-curve between splitters at top left seems to be constantly free for items. I don't see why the 4th inserter desyncs with the rest. Is it maybe just because it is a turn? A straight belt would work but this not?Aeternus wrote:There is something blocking them actually. The splitter they feed has one end of it's output blocked.
Re: [16.22] Belt back pressure inconsistency
It seems to me now that if the splitter's chosen output lane for an item is busy and its buffer is occupied it takes a tick to switch. That seems fair enough. To keep the traffic flowing freely put four belt segments on the inserter-drop-to-splitter-input path, not just two. That fits in to most of my station designs without trouble and poses only solvable problems for the rest so I'm happy.:
Re: [kovarex] [0.16.22] Belt back pressure inconsistency
I re-tested this setup after making different (but related) bugfix of the input priority logic. And it seems to work properly now (by now I mean in the to be release 0.16.29)