[2.0.15] Inserters' wait time for full hand does not scale with quality

[FlachFritz]

Problem

Higher quality bulk inserters are significantly faster than normal quality bulk inserters for belts containing a single item type. However, as soon as the items are mixed on the belt (e.g. crusher or recycler output), higher quality inserters are nearly useless.

See the following video for a demonstration. The top half has mixed items, the bottom half has only one type. Quality of the bulk inserters grows from left to right. Even a legendary bulk inserter cannot keep up with three normal fast inserters that are limited to two items, when 3 item types are mixed on a belt. For homogeneous belts, it can handle 7 such inserters, i.e. a half full green belt:

https://youtu.be/8NoJgrXaFIs

vlcsnap-2024-11-14-23h11m33s552.jpg (1.15 MiB) Viewed 364 times

Explanation

Inserters that can carry more than one item make a small pause to wait for more items of the same type after the last one was picked up, before deciding to give up and drop their hand even if it is not full. From the analysis of the video, the pause (22 frames) seems to be a bit less than the time it would take to make one full rotation to the output and back (~24 frames) for a normal inserter. This makes sense, I think.

However, the legendary bulk inserter also waits for 24 frames before moving, although it could have made 3(!) full round trips in the time it waited for the hand to fill.

The end result is that your insanely fast and expensive inserters are standing still for 75% of the time, which is quite frustrating to watch. And you need 2-3x more inserters to empty a sushi belt than necessary.

Mitigation

Wait time should scale inversely with rotation speed, or proportional to a full rotation duration. Inserters that are 2.5 times as fast should wait for 1/2.5 of the time. Of course this will lead to a lot of additional rotations when operating on a slow belt, but who would put a legendary bulk inserter on anything else than a green belt anyway?

[boskid]

This is not broken so i am moving this to ideas and suggestions

[FlachFritz]

Thank you boskid. I thought this was broken (or at least unintended), because it almost completely negates the quality effect in some cases.

[boskid]

Fact that it has to wait for more items means it is not inserter throughput issue but input throughput issue and as such i am not seeing this to be a bug. It waits exactly 20 ticks from last item pickup until it times out. This is extremally hot code path so i am not willing to make this value dynamic by any means.

[FlachFritz]

Let's called a "mixed input throughput issue". The input and inserter throughput are fine for non-mixed payloads.

Yeah, I can imagine that changing a constant to a member variable (or method call ) in such a code path that can run tens of thousands of times per tick is problematic.

Anyway, if you say that this change is not gonna happen, I guess we will have to accept that faster inserters are not always faster, and deal with mixed inputs a different way. Thanks for the feedback.

[ividyon]

As a small bandaid fix, I suggest adding separate stack inserters filtered to the most prevalent item type (and quality) in situations where the mixed belts have one predominant component, and reducing the stack size to 1 in situations where the items are distributed somewhat evenly. A legendary/epic inserter can do several round trips with 1 item in the time it takes a lesser inserter to get a stack, as stack size 1 leads to zero wait time.

[FlachFritz]

I tried fixing it with combinators. Basically, if the held item count does not change for 2-3 ticks, time out and set the hand limit to 1. My current solution only works partially and sometimes gets stuck until the next item on the belt passes the inserter because changing the hand size does not cause the inserter to re-evaluate its situation.

Setting filters could work though.

[Linsanga]

Looks like you're hitting the same root issue as me when I posted viewtopic.php?f=6&t=122029, inserters can't be configured to reasonably deal with mixed belts (especially with stacked items, without stacked items setting inserter capacitor of 1 could help throughput).

I also tried higher quality inserters and found it didn't help much, because just as much time is spent waiting.

[Tinyboss]

I'm not sure there's anything that can be done other than to limit hand size. As boskid said, it's really the speed at which items go by that makes the difference, so there's no reason anything should be different based on inserter quality.

[Linsanga]

When inserting into a chest, the speed that items go by is equal to the speed that the inserter works at. If the inserter throughput were increased, the belt would start to flow faster, so an expectation that 2x swing speed = 2x throughput is reasonable.

Here's an example of a quality-upcycling layout that I use all over (sometimes with EM plants or assemblers instead of foundries, but same idea). Items are recycled, split based on quality, re-assembled, re-recycled, and so on. Buffering ingredients in chests is necessary to balance out the randomness of the recycler. The inserter with a red circle around it is the bottleneck of this system, although it could work much faster if it didn't spent 70% of its time waiting for items. It doesn't seem like it's working much faster than a normal inserter, but in theory (with more inserter options viewtopic.php?f=6&t=122029 or shorter wait time) it could have a much faster throughput than a normal inserter.

qualityupcycle.png (1.66 MiB) Viewed 127 times