[0.16.x] belt->inserter throughput limit

[Therax]

Unsure if this is really a bug, but there appears to be an inherent engine limit that prevents sets of multiple inserters from picking up more than 1 item per tick (60/s) from a belt segment. This limit only becomes visible with faster modded belts (> 60 items/second), and remains even with modded inserters with extremely fast speeds, or using large number of inserters to pick up from a belt via custom pickup vectors.

For an illustration of what this looks like: viewtopic.php?f=93&t=54343&start=100#p342631

As I hope is apparent, it looks like only a few of the inserters are active, with the rest idle and not picking up any items, despite there being items that leak past on the belt. The belt involved in this test was 5x yellow belt speed, or 5 pixels per tick, so each item should have been within the bounds of the tile and accessible to the inserters for at least 6 ticks.

My conjecture is that there's some sort of per-tick handling where inserters search for an items to pick up from a belt, something like: each inserter picks an item, the first inserters successfully picks up the item, and any other inserters interacting with that belt segment wait until the next tick to select another target item.

[Twinsen]

Multiple inserters on top of each other is something we don't support. For many reasons including the logic of how they work(they all try to aim for the same item).
And it's not something we want to support since there is very little reason to do this. Just sue a priority splitter and loader.

[Therax]

Multiple inserters on top of each other is something we don't support. For many reasons including the logic of how they work(they all try to aim for the same item).
And it's not something we want to support since there is very little reason to do this. Just sue a priority splitter and loader.

Note that this isn't limited to the case of inserters on top of each other. Using inserters with different pickup vectors pointed at the same belt segment can result in the same behavior. Here is an example of 21 of Bob's Ultimate Stack Inserters aimed at a segment of Bob's Ultimate Transport belt, no scripting required:

https://gfycat.com/IdealisticSmartDamselfly

For context, this came up in the case of Miniloaders, which uses inserters to work around the inability of loaders to interact with cargo wagons, so splitter + loader isn't always an option.

[Guilty]

Multiple inserters on top of each other is something we don't support. For many reasons including the logic of how they work(they all try to aim for the same item).
And it's not something we want to support since there is very little reason to do this. Just sue a priority splitter and loader.

Note that this isn't limited to the case of inserters on top of each other. Using inserters with different pickup vectors pointed at the same belt segment can result in the same behavior. Here is an example of 21 of Bob's Ultimate Stack Inserters aimed at a segment of Bob's Ultimate Transport belt, no scripting required:

https://gfycat.com/IdealisticSmartDamselfly

For context, this came up in the case of Miniloaders, which uses inserters to work around the inability of loaders to interact with cargo wagons, so splitter + loader isn't always an option.

RIP Miniloader

[Twinsen]

This should be fixed in Version: 0.17.49
This should be fixed in Version: 0.17.50