[boskid][1.1.70] Inserters to belts behavior depends on belt orientation

[redis]

If belts are facing Up or Left 2 inserters do not fill a belt at stack 8, but surprisingly they do if you rotate the blueprint with belts going Down or Right.

There should be no preferable orientation all directions should be equal. Behavior must be consistent and ideally in both cases 2 inserters at stack 8 fill the express belt. Please see the image. Thanks.


0eNrNltuOpCAQht+Fa50ICtq+yqZjaK3pJaNgADfT0/HdB3UOZlvjaS7mygPwf0UVVdQdXcoGai2kRekdiVxJg9I/d2TEVfKy+2dvNaAUCQsV8pDkVfcFr7UGY3yruTS10ta/QGlR6yEhC3hFKW691SKl4gXo0WLSnj0E0gorYDCn/7hlsqkubmaK5zQ8VCvjlinZUZ2UH4f0iXro1r3GiWN8miLrpjP4QZt8aQv5LKQb8vO/YOyS9umJ9jsY1mQGrBXyarq5Gir1D7LGjZUWNBRZ5wg3ZHUD7YQN4ZKjF2xhzpYJ2eigbDQtSw/K0mlZ9iDbuOOhr1q557xw9C1M+pAUQkM+zImWwx/vo9L/qR8c1dgZUHLQa+G0105bju/IV8GO4/vMSwMeGn4PifrJ1kr6dcktOG7uXOfKCw4CD1Wq6Ma59UvgvVVfBeM8tR0c7EzH37qf79JlLM9ffCENaDtTukbxwRNn2e1Ca1FA1ktlRrw53WSKSrZQ6U9Rw6MZzJL5DJ7PLBwdzeEP7lKtwHRfMNlwV6x3JNsXvs2ceE9NGu2LPYRripIcpMSrKKeDlGgNhQQHKXQVZVO/M1IPN19/hOy7Pxje3f64Xq/vC9NRL+ohd2ZNzyIJjuITiRlhNIrDtn0HDJyLbg==

[boskid]

I see no issues here. All inserters here are dropping items on the right transport line, which is on the west side when belt goes south.

-- edit:

Hm... i think most likely i misread the bug report. Let me reanalize it

[redis]

There is a gap depending on where the belt is moving Up or Down. The image shows the gap.
I understand the mechanics of belts and where inserters place items (on the right etc). The problem here is that if facing North the top inserter hick ups at some point and there is a delay causing the gap, while the behavior is different when the belt is pointing downwards.


Is it not an issue?

Thanks.


Edit: I just realized I think this might have something to do with the rotation direction inserters choose to go. On the left both inserters seem to travel a little bit longer because they have to cross over the second lane, while if the belt is pointing downwards they meet the required lane first. If this is the case it would be better if they rotated the opposite direction then to avoid the issue and keep consistency.

[boskid]

Ok i see where the issue is, the item insertion specification is incorrect for underground belts that are going South or East.

[boskid]

Thanks for the report. Issue is now fixed for 1.1.73. Insertion of items on underground belts that are facing south or east will now behave consistently with other directions, which means at stack size of 8 you will get gaps consistently at all directions.

[redis]

Oh man... lol , I was hoping the other behavior was correct!

Actually why would it be more correct with gaps?

If 2 inserters (stack 8) place items on a belt it compresses it (no gaps) and it is working fine in any direction. Now for undergrounds it becomes different compared to belts. I would think there should be no difference in speed if you put it on a belt or an underground, but there is now.

Additionally If you place items from the side on the 2 undergrounds it also compress (no gaps), why should it be different if you place on them behind/infront?

I wonder if people will be unhappy if they notice inserters behavior changed and broke megabases.

Thanks!

[boskid]

Issue is heavily based on how the item insertion specification function was implemented compared to insertion function for other transport belt connectables: other entities (except of linked belt which was also affected) are using transport belt connectable's center position so if inserter tries to put item, the effective drop position is relative to belt center and code keeps some symmetry between all cases. Underground belt has this function implemented slightly differently because it first converts UndergroundBelt position to a TilePosition and then back to MapPosition so all offsets are relative to top left corner and the for belts that are going right or down instead of using "offsetX", it has to use "1 - offsetX" value. This issue was kind of hidden because of a clamp nearby being a safeguard so item is not inserted onto a part of transport line on adjacent entity but i made a tiny debug tool (rendering) to observe if everything was fine. After the fix it is now correct because by changing inserter's dropoff vector, the insertion position will start moving in the same direction as the dropoff position, while previously it would move to the opposite direction which makes no sense. Item insertion specification is a step which is intended to give a position on a transport line which is the closest one to a given position and it is used by all sort of things (cursor drop, inserter placing item on belt, mining drill placing item on belt). It was also possible to observe this inconsistency with mining drills:

104104-b.png (910.93 KiB) Viewed 5401 times

If there would be a strong requirement to keep previous behavior, it would be made in a lot more consistent way (for example it could always insert items at the transport line transition regardless of the actual position where items are being dropped). My current changes were only to make all directions consistent with each other by fixing the missing "1 - offsetX" part in the item insertion specification logic.

[boskid]

I think this may be slightly more digestable image:

104104-c.png (127.1 KiB) Viewed 5393 times

Here in case of the undergrounds going south or east, you may see that inserter that is trying to insert closer to the open end of the underground belt is actually inserting item in the middle, where the inserter that is trying to insert item on the underground part is able to insert items near the open end.

[redis]

Ok so my general understanding it is because items were inserted in slightly different locations (fore/aft) on the underground depending on which side inserter was located. Some directions (E, S) had an erroneous offset, which caused "better" syncing of the inserters for undergrounds. From the explanation it sounds like belts work a little differently so this does not apply to them. The only question I still have what happens if you load on the undergrounds from the side and why does it allow for "good" inserters syncing?

On a side note I believe it is important to have good ability to sync belts with inserters. If you need to use a 3d inserter to fill up a belt fully because you are out of sync couple of ticks (because your inserter rotation is a bit faster than moving belt etc) it seems wrong and inefficient. A lot of players rely on the mechanic to compress the belt for train/chest unloading. This is one of the most cpu intensive operations in the game because nearly all you items need to go through the train to belt interface in very popular megabase designs.

[boskid]

The "good inserter syncing" was an artifact of the inserter to underground belt being slower by 1 tick: when inserter needs 43 ticks to dump 8 items onto a blue underground belt that gives you a throughput of 22.325 items/second and there will be a tiny gap after each burst of 16 items. This gap will be exactly after last item inserted by the second inserter so it goes back to grab more items and returns when there is another burst of items from first inserter so the second inserter syncs to the first inserter. After the fix, inserters are able to dump items faster within 42 ticks which gives a throughput of 22.857 items/second, but one lane of blue underground has only speed of 22.5 items/second. Because 22.857 i/s is faster than blue belt lane, second inserter has not enough time to dump all items and cannot stay in sync. It fills the gaps but it may happen that it inserts its last item at the beginning of the gap made by first inserter and in that case second inserter swings back to grab more items and that means the gap goes past second inserter not being filled. The "good behavior" was basically an inserter being slow causing accidental ability to unload almost(22.325 < 22.5) one lane of blue belt.

[redis]

This is a very detailed anatomy of how 2 speedy inserters are failing when working as a team! It is quite unfortunate for the belt because all the other machines are now missing some deliveries and started blaming the belt for that. All drama because 2 inserters can't agree who should wait for just 1 tick!

Thanks for your explanations and a quick fix. Looking forward to see how it is in action with all its side effects !

[Jon8RFC]

Thanks for the explanation. It's always interesting stuff to read!

[j_matya]

I love this level of discussion! (came here from the release notes, didn't regret it)