[2.1.7] Inserter rotations now depend on belt direction

[Providence]

This is adjacent to [134061], which was marked as "not a bug" which makes sense (left relative lane preference is (was) a feature), but in 2.1.7 the inserter logic changed, which was undocumented in the changelog (or it's accidental and came from some another unrelated change instead):

For the corner belt case, inserters now take from the inside lane always (which is optimal), not the left lane (which was the intended behavior as per "not a bug" category for the report above), which is optimal for the corner belt case.

factorio_H1ka0uEoYQ.gif (2.1 MiB) Viewed 916 times

But as you can see, after inserting into a chest the east inserter now prefers returning by counter-clockwise rotation instead of the optimal clockwise rotation (that would make the throughput equal to the west-east belt case)
In 2.0.77, that was not the case, in the same setup the east inserter correctly rotates clockwise, although inoptimally taking from the far lane (this was intended I guess)

factorio_w7qQIimIVI.gif (29.7 MiB) Viewed 909 times

The new inside lane preference for corner belts brought the throughput difference from approx. 20% down to just 3.6% (there's still a difference because of the rotation preference changes which is the subject of this report) more details in the previous report mentioned above.

But the rotation changes introduced a roughly 10% difference in throughput even when taking from parallel belts running opposite directions, which was equal in 2.0.77, which is the main reason why I'm making this report:

(2.1.7):

factorio_ITcCLhfKJc.gif (21.64 MiB) Viewed 916 times

(2.0.77):

factorio_WrFRyc5uNs.gif (21.01 MiB) Viewed 916 times

I think it's best if the new 2.1.7 inside lane preference for corner belts stays, and the rotations are fixed back to their 2.0.77 state (or at least made consistent for belt direction, as it has higher throughput when taking from parallel lanes and doesn't leave stray items in the gif above), as it will make all cases in both these reports equal in throughput, which is especially important in loading trains.

[boskid]

Thanks for the report. I did some tiny adjustments to inserter hand rotation logic which hopefully will fix this issue.

[Providence]

Thanks for the report. I did some tiny adjustments to inserter hand rotation logic which hopefully will fix this issue.

Thanks! It's fixed and now throughput is consistent across all cases, even corner belts