[2.0.77] Inserter throughput from corner belt changes with belt direction

[Providence]

- What did you do?
I was testing inserter throughput when I stumbled upon weird behaviour when taking from corner belts going into an inserter.

- What happened?
Left to right belt going into an inserter has higher throughput than right to left belt in the same exact setup.

- What did you expect to happen instead? It might be obvious to you, but do it anyway!
I think the inserters should have equal throughput in both setups.

- Does it happen always, once, or sometimes?
I tested it on max stack size with bulk inserters, on min stack size with bulk and blue inserters, and on stack size 3 upgrade with bulk inserters, I suppose it's always the case.

- If you can reproduce the issue, provide the exact steps!
1. Open the attached test world (fresh map, no mods, base game, max stack size researched, editor mode)
2. Resume tick speed in the editor menu by clicking the play button, it's already set to 64x
3. Wait a couple seconds for the inserters to move enough items to see the difference
4. Open both chests and see that the right one has (significantly) less items than the left one, thus the right setup's inserter's throughput is lesser than the left inserter.
5. You may run the test multiple times with different inserters and stack upgrades.

I don't know whether it's a bug or an intended behaviour, I'd like to know.

[eugenekay]

Inserters:

Inserters may have problems picking up items:

• From very fast belts, because the items are moving too quickly.
• From the entry or exit of an underground belt (because the time they have to pick up is shorter)
• From turning belts if the item is on the inside of the corner

When picking items from a belt, many more factors come into play besides belt fullness:

• How fast the items move (i.e. if they are queued up on the belt or move at belt speed).
• Whether the belt is perpendicular to the inserter or approaches it head on.
• Whether items are on the near or far lane of a perpendicular belt.
• Whether the belt turns or not, and whether the items are in the inner or outer side of the bend.
• If the belt is an underground entrance or exit. This shortens the time items are visible to the inserter for pickup.
• All sorts of intricate timing factors between the inserter and the items on the belt, since the game simulates the arm homing in on every item.

Inserter throughput when picking from “non-perpendicular” belts is always lower because the arm has to “reach” farther to grab items as they go around the corner.

Good Luck!

[Techjar]

Inserter throughput when picking from “non-perpendicular” belts is always lower because the arm has to “reach” farther to grab items as they go around the corner.

Good Luck!

Right, but the issue is that even when the items are on both lanes, the throughput is affected by which direction the belt turns. I guess it has something to do with which lane the inserter prioritizes.

[eugenekay]

I guess it has something to do with which lane the inserter prioritizes.

Yes, from the Wiki again:

If the belt is the same/opposite orientation of the inserter or a curve, the inserter prefers taking from the left lane, from the belt's perspective.

The West one is grabbing from the Inside lane, so it is able to Turn-and-Drop faster than the East one which has to reach allll the way to the Outside lane. Both of these are considered to be the "Left" side of the turning belt, demonstrating the behaviour described.

You can visualize the Lanes with the F4 Debug option "show-transport-lines".

[Techjar]

I wonder if 2.1 inserter flipping also flips the pickup lane...

[eugenekay]

I wonder if 2.1 inserter flipping also flips the pickup lane...

Unlikely; that feature appears to move only the Dropoff position according to the movement of the yellow “triangles” in the FFF-442 screenshot. The Pickup location (straight line) is unmoved in the demo GIF while switching lanes.

It is already possible to change the sub-tile dropoff/pickup location using Mods.

[Providence]

I guess it has something to do with which lane the inserter prioritizes.

Yes, from the Wiki again:

If the belt is the same/opposite orientation of the inserter or a curve, the inserter prefers taking from the left lane, from the belt's perspective.

The West one is grabbing from the Inside lane, so it is able to Turn-and-Drop faster than the East one which has to reach allll the way to the Outside lane. Both of these are considered to be the "Left" side of the turning belt, demonstrating the behaviour described.

You can visualize the Lanes with the F4 Debug option "show-transport-lines".

It seems now in 2.1.7 they both prioritise the inside lane instead of the left one, oddly (the robot signal just enables the inserters at the same time)

[Providence]

and instead the east one now rotates all the way counter clockwise instead of making a half turn clockwise like the west does and the east did in the eugenekay's gif above but taking from the relative left lane?? lol

[Providence]

at stack size 12 bulk inserters, throughput is now higher at west inserter only by one stack (1320 vs 1272 in favor of the east one, ~3.6% higher) instead of like 25% in the first post, although still it's weird that the west inserter now inserts clockwise and returns counterclockwise which is optimal and the east inserter instead rotates the same counter clock wise direction and thus moves less items, why don't just make the west one also return the shortest path again (as was the case in the gif above) in addition to it now prioritising the closest lane, for them to be equal completely, but at least the difference is not that drastic now.

I also tested stack size 1 fast inserters, the rotations are the same and the throughput difference is 8.3% 867/795, I might make another report because the behavior surely changed, accidentally maybe because it's not listed in the logs explicitly

[Providence]

man, now parallel belts direction also affects throughput because of the rotation preference changes!! in 2.0.73 (I will test it at 2.0.77 a little later), they are fully symmetrical, throughput is practically the same (not sure why it differs by 3 items, maybe some rounding error, doesn't matter really)

factorio_Z91vO7QYqi.gif (18.02 MiB) Viewed 115 times

In 2.1.7, they now rotate the same direction and it results in a quite signifacant throughput difference once again

factorio_KMrqoTQuNU.gif (26.61 MiB) Viewed 115 times