[kovarex] [0.16.25] Gaps moving backwards when items put on belts

[Bilka]

I think I discovered the issue behind this. When the inserter inserts the item into the gap, the whole transport line is pushed back, including other gaps, instead of just pushing the items until the next gap. This means the belt is not actually compressed, like Anti assumes. I hope the gif makes this behaviour obvious.


Merged...

[c4rt]

Issue:
After updating to 0.16.25 I often see quite strange behaviour : when e.g. extractor or manipulator places item on transport belt right before already riding item, it does not stop only that item but a few items on previous transport belts, even if there is enough space for them to continue moving.
Expected : if there is enough space for items they should continue moving.
My game is quite modded (bob's + angel's + etc) so this may be not vanilla bug, or even as designed.

Example :
I've made small video illustrating this https://youtu.be/2-sOz46uGF8.

I haven't tried to reproduce this one in vanilla yet, but if this is needed - I'll try.
Mods.zip : https://drive.google.com/file/d/1yxKAV- ... sp=sharing.

Thanks for the help and great game!

[Bilka]

Ref: 57998

[boskid]

Same here

It looks like compression is achieved by increasing gap between two items on lane till there is gap wide enough to insert item, but because position of items on belt is (after belt optimization) not directly accesible but depends on "head offset" and offsets between items from start of lane (where items leave lane) and current item - gaps cannot be easily removed.

I think easiest workaround for devs would be to force split of internal lane represenation where inserter places stuff on belt (to make it last in chosed iternal lane) - this would create additional "compression" spots.
Other solution would require change in internal lane representation as to allow fast "find next gap" operation starting from arbitrary position (where inserter is trying to insert stuff).

In my attachment i have very long blue belt that was internaly optimized to one long lane and so stack interter on right when inserting items will make whole lane stop moving, even when there are gaps to compress. "gap generator" places items with gaps on blue belts, then there is this rounded rectancle of lamps where items go using "one internal lane" object and on the right is stack inserter. If stack inserter forces compression, whole lane stops up to last inserter in "gap generator"+1, where compression takes place because new lane object starts here (use "show-transport-lines" to show where lane objects ends - there will be arrow on lane)

-- edit:
in my map it is not sideloading but inserter compression stuff, but most likely they are highly related - inserters are easier to setup conditions when to insert stuff

[kovarex]

No it is not moving backwards, it never was. It is just a optical illusion created by the movement of the transport belt.

[Bilka]

No it is not moving backwards, it never was. It is just a optical illusion created by the movement of the transport belt.

And I didnt make the thread title. The gaps were also stopping (like the items), not moving backwards. I tried to reproduce in 0.16.28 and couldnt, so I guess this is fixed. Instead I found that sometimes items move too much forward now. But the bug report that will have to wait until the version is actually out.

Edit: Turns out I can reproduce items moving too far forward in 0.16.27. Here is the report: 58313

[Monara]

No, they don't move backwards, but the gaps standing still looks extremely weird and doesn't make sense. The items at the front should stop, and the gaps behind them should close.
Supposedly this was fixed though, but it's in 'not a bug' forum. I really hope this is not intended behavior because it looks weird and makes no sense.

[c4rt]

Starting from 0.16.27 I do not see initally reported behaviour in my setup. So I presume it was fixed in 26/27 (at least for situation I observed).

About *not a bug* thing - I doubt this is not a bug, I can see this issue being as designed only if not only gaps stopped at the moment of sideloading/item compression but if transport belt stopped too - like in real life,
you actually need to stop some part of transport belt branch to insert item if there is small amount of space. But on videos/gifs we clearly see that gaps (do not move backwards, who called this thread so?) just stop moving, and
transport belt continues.

Anyway, initial issue seems resolved for me, thanks for the help!