[0.17.66] - Inserter preferring incorrect lane

[foamy]

I was messing about trying out train station layouts and I noticed something: In a basic splitter -> 2x 3-tile runout layout, one inserter pulls from the wrong lane; the result is that the draw is not lane-balanced. This doesn't match the documented behaviour on the wiki.

Here's a screenshot:



The inserter drawing from the highlighted tile is preferring to draw from the far lane, not the near one. This is asymmetric with the inserter directly below it, which correctly, on the mirrored curve, pulls from the outside lane. As a result there are four inserters pulling from the left lanes of the input belt, and only two from the right. Wiki suggests the inserters should be pulling from the near lane, which would result in balanced draw.

This behaviour is consistent across inserter types and capacities. Tested were normal inserters at stack size 1 and stack size 3, fast inserters at 3, and stack inserters at 12. In all cases the belt was saturated at the point in question.

[Optera]

Is it consistent between rotations or once again a case where a certain orientation behaves differently?

[Twinsen]

Didn't it always work this way? Or is this something introduced in 0.17?

[Bilka]

Didn't it always work this way? Or is this something introduced in 0.17?

It has always worked that way.

[posila]

Afaik, inserters put items on far side of a belt, and how they take items is undefined, so even if it would have worked differently in 0.16 and the behavior changed in 0.17, it wouldn't have been a bug.

[Twinsen]

As long as it's consistent between blueprint rotations it's fine.

Even though I would prefer to fix this as the inconsistent behavior can be quite unintuitive, I'm marking it as minor issue

[foamy]

As long as it's consistent between blueprint rotations it's fine.

According to Bilka's test run it is *not* consistent between rotations, though.

EDIT: Wait, where'd their post go...

[Twinsen]

According to Blika's test run it is *not* consistent between rotations, though.

EDIT: Wait, where'd their post go...

They were not rotated correctly in that example(belts were not going the same way).

We just tested and they are rotationally consistent as far as blueprints are concerned.

[Bilka]

Sorry for causing confusion by deleting the posts, I didn't want to spread misinformation because I had somehow managed to set up 4 belts and inserters incorrectly. I have made the wiki more clear in regards to the lane preference:
If a belt is in the same orientation as the inserter, or a curve going towards the inserter and turning to a side, the inserter prefers taking from the left lane, from the belt's perspective.

[foamy]

According to Blika's test run it is *not* consistent between rotations, though.

EDIT: Wait, where'd their post go...

They were not rotated correctly in that example(belts were not going the same way).

We just tested and they are rotationally consistent as far as blueprints are concerned.

Ah. Yeah, just did the rotation test myself and it does, for the left-hand-turn, pick from the inside of the curve instead of the outside consistently regardless of rotation.

EDIT:

I can't speak for anyone else but the difference between the mirrored versions of the blueprint is unexpected behaviour even if not, strictly speaking, a bug. It also unbalances some very common and simple layouts (e.g. the train station stuff that I was looking at to start with) and doesn't match well with the output actions, which do both always put it on the far side. So you get this, starting from even seeding of both belts:

[foamy]

Followup: I tested the other case of curves moving away from the inserter; they behave as expected and prefer to draw from the near lanes:



So, the counter-clockwise turn, moving items towards the inserter, is the odd man out here and the only one where the inserter prefers removing items from the far lane.

[foamy]

2nd followup:

Which lane the inserters pull from can be influenced by construction order. Since this is now inconsistent behaviour I think I'm safe in saying it is not only unintended, but a genuine bug.

[Twinsen]

Which lane the inserters pull from can be influenced by construction order. Since this is now inconsistent behaviour I think I'm safe in saying it is not only unintended, but a genuine bug.

Ugh.
Can you make a detailed report about it? We might still consider it a minor issue but if i have some detailed steps i'll take a look at it.

[Trebor]

Screen Shot 2019-09-02 at 1.15.44 PM.png (1.91 MiB) Viewed 5334 times

The following lists which lane the insert picks from listed from left to right. (Note the first term is what
I think the inserter is using):

1. Outer/near/left lane
2. Near lane
3. Inner/right/far lane
4. Near lane
5. Left/inner/far lane
6. Near/right/outer
7. Left lane
8. Right

Terms

• Near - lane nearest inserter
• Far - lane away from inserter
• Inner - lane on inner curve
• Outer - lane on outer curve
• Left - lane on left from inserter's perspective
• Right - lane on right from inserter's perspective

Green wire just to synchronize to full belt.

Edit: Added this:

0eNrdWu1u2yAUfZWJ33ZlPgxJpD3AnmGqLMemLZqDLYyrdZXffdhO08zBCbD8aPKnUY19LvdcuBzgvoNt1fFGCanB5h2IopYt2Px8B614lnk1PNNvDQcbIDTfgQjIfDf895S3OtYql21TKx1veaVBHwEhS/4bbGAfuSFUdV5ydfQl6h8jwKUWWvCpI+M/b5nsdlvz5gb+C9CZz9Szqs3v1IkINHVrvq7lYNkg4gi8gU1MjY19P+pON93Q3RNwdNa/JWhmoEuheDE1IQsw9gMmVmBiASa+dJBPOo6hD+QIucBNerAk5JOQpikuXnhrMRGnk410DOv0btZyrYV8bod3FN/VrzzrTFulueJlNgwN06RVx3uLbWodNYuG8UPaX3aIuTtEru3QytEh4uPQ2t0heG2HYOJuHF3dOHSkE/rQCZEjKvJCxc5EJVfnibh5lHg55J4Y8NUdos62rz/omBuZ2ItMx8TgN+TcE8PVEx1K3BzySnQI+i2nH+sCsvbQc9H/yMl2MM+F/iMj2cGIJxg6B5b6gSXnsGiQTrJjMT+ssz6ugmSWHWsdNsagDQzPZoGQLVf6jIRJTuSZEeZa1VW25S/5q6jV8H4hVNEJnZm28gDyJFSrswviu6hNo7HR8uHby283DVdxrfjwTVHvmlzleugD+A768ZGUU1/HLAGHP8+Kc3ms4EVpiMD94/CBSSJKiZJnrc6LX8b+H77fNcyZg2Gz0x6Gz6m+46XodjGvTLeVKOKmrrgFDe+jYQPDzjEl9x3T5Iid8QHzDTIJy5r2IKdhWdMORp2DDO87yGwWZJL4Bpk5U4nuPQfO5gv1pXIVtJbbR/jaMyfC5ZRInJe55L4jTOeThXhGmMAghWWNMEFBCsuO5bzo4buOMCHzCPvOYUJcmbzvbEjm6oH4SkSSBql++/h2Xu/vW9OR+RrFUt+osKD9E7x8lk5WQcioPx8cLvNtxbNStMMv2DzlVcujQ7PieZm95CYIA4jp0v7QIzqO7vh8enVXlxMz7qTTMYfYPF4HbYIcuEwT3/uD/ZZoju1wfwCDdDnymmFfIIjEOnNshKAgQuDlS6E07BRqhkxtyN73TfD8cFm+i0uDDqysZzkpDYFyoYOF3UZCh0POdBUiAW8gy80XfIqWJsg6RLg6zA+ahADfWiZKVwu8Uhh2aQyX7oyXJzFFIdrsBpl2zPkUB2kXbMXyPTXDe6x/09qXJxfO88WSTKIeJQoTF8T7nmvv//R4KlA5Fd+Dd91QUDPIq8llkOu44vnYl0ORzKPVCxok9m4trCc6iSymKxakk/Dl5Zu6lmHAh/QwXjxlDF272VgwQR1MsCRE3lhzCoMhUMQKFVRMZe8V9iwxuO68Njvu/5rRjITIDXx598aCTj7wre2o0OlZWzRfIuypg1Gf6gMyFh/4VcUx5llbQQNLKx6j6bBnc1SwGYEqN5E2z37sz6m+NaL41TWtaXo143g0znACV4yuSbLq+7+MDWjx

Copy blueprint

[Bilka]

Left lane of belt is used for all curves (from the belt's perspective). Near lane is used for 2 and 4, the straight belts. Both of those are completely expected. Inserters 7 and 8 have belts going towards them, so they use the left lane of the belt (from the belt's perspective). All expected. All documented on the wiki.

Here's your list in my words:

1. Left
2. Near
3. Left
4. Near
5. Left
6. Left
7. Left
8. Left

Terms

• Near - lane nearest inserter
• Left - lane on left from belt's perspective

[Trebor]

... Inserters 7 and 8 have belts going towards them ...

Inserter 7’s belt is going north, inserter 8’s belt is going south how is that towards?

Also 3 & 5 have different items in the left lane.

[Bilka]

I just forgot to add "away".

[Trebor]

The Wiki states left from the Inserters perspective. The pic attempts to have its left the same as the inserter’s left. Never mind, read Wiki wrong/mis remembered.

[Bilka]

The Wiki states left from the Inserters perspective. The pic attempts to have its left the same as the inserter’s left.

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.

All inserters prefer to take from the left belt lane (from the belt perspective) except those picking up from perpendicular belts. It's really that easy.

[foamy]

Which lane the inserters pull from can be influenced by construction order. Since this is now inconsistent behaviour I think I'm safe in saying it is not only unintended, but a genuine bug.

Ugh.
Can you make a detailed report about it? We might still consider it a minor issue but if i have some detailed steps i'll take a look at it.

I haven't been able to consistently isolate and reproduce it yet -- but I do have a save where a counter-clockwise turning belt, with the inserter on the outside of the loop, was preferentially pulling from the outside lane of the belt, i.e. the right hand lane from the belt's perspective. I'll throw it into a dropbox link later today for you to look at. Rebuilding precisely the same arrangement can switch it back to left-hand draw, and I've gotten it to pull from the both the left and right hand in other, distinct arrangements, that depend (somehow) on how they are constructed.

Per @Bilka the right hand draw is not intended. Personally I think orientation *to the inserter* should govern things, i.e. to prefer the near lane to the inserter in all cases bar the head-on (where it can't be determined).