[kovarex] [0.16.25] Inserter placing items on fully compressed belt

[AntiElitz]

So when testing the amazing new feature of inserters compressing the belts I found a bug i can't think of a reason for.
So I have an uncompressed mining belt and insert additional ore at the end of it to compress it. So when a "hole" is found, an item is inserted and the belt stops for a moment to fit it in as intended. However, even thought the belt backs up about 10 tiles, another "hole" is found just 2 tiles later. Technically the belt should be fully compressed at the area it backed up to. The Video below shows the bug in interaction.

Small Video explaining the bug:
https://youtu.be/X34CDl6btGM

Thanks for your work on fixing it!

[impetus maximus]

i'm guessing it's related to [kovarex] [0.16.1] Items on belt creeping forward at specific position.

would help if you uploaded the save.

not a bug 0.16.25
"Changes

• Inserters and belt sideloading can now squash item on belt even when the gap isn't big enough. The squashed gap is extended to normal size once the front of the belt starts to move again. This means, that inserter rows and side loading can produce fully compressed belts without the usage of splitters"

[AntiElitz]

i'm guessing it's related to [kovarex] [0.16.1] Items on belt creeping forward at specific position.

would help if you uploaded the save.

not a bug 0.16.25
"Changes

• Inserters and belt sideloading can now squash item on belt even when the gap isn't big enough. The squashed gap is extended to normal size once the front of the belt starts to move again. This means, that inserter rows and side loading can produce fully compressed belts without the usage of splitters"

I'm aware of that, but that is not my point. I think if you watch the video you will understand my point better. It's about finding a gap in a section that was already fully compressed by backing up.

[RexRox342]

It doesn't look like sideloading can fully compress a belt, whereas an inserter can. So the source of this problem seems to be that inserters can insert into any gap in a belt, no matter how small, but sideloading can't.

Somebody on reddit put up the following gif demonstrating this which I can reproduce: https://gfycat.com/FinishedEqualLeafwing

[impetus maximus]

I'm aware of that, but that is not my point. I think if you watch the video you will understand my point better. It's about finding a gap in a section that was already fully compressed by backing up.

if you take the inserter away, do you notice any creep on the belt?

[kovarex]

Side loading should have exactly the same "power" when it comes to compression. (As well as mining drills).
I agree, that this looks like a bug and I will take a look at it.

[impetus maximus]

without me fully understanding the update, yes it does look like a bug.
[edit] AntiElite [/edit] can you post the save?

[RexRox342]

If it's any use, I've attached the save I used to reproduce it, which included some additional testing to confirm that the compression issue wasn't just a visual bug. I used the latest version of 'Creative Mode (fix for 0.16)'.

It compares smelting (a 48 steel furnace line) between a sideload compressed line only, a sideload compressed line with inserters at the end, and two spawned compressed iron plate lines. You can see that only the smelters for the sideload-only line operate less than they should at the very end.

[impetus maximus]

RexRox342, side loading vs inserter is not what this bug report is about.

[RexRox342]

Except that it is, if you watch Anti's video and see how he's generating a compressed lane. He's compressing the lane with sideloading and electric mining drills, unless I'm missing something off-screen. The inserter is then further compressing the lane later, because sideloading and mining drills do not appear to fully compress a lane (which is the same problem demonstrated in the gif I posted from reddit, which I replicated in my save). If you watch the video closely, you can actually see the gaps between the iron ore that the inserter is filling (it fills gaps from behind, which can make it hard to spot at first) that aren't being filled by the miner or the sideloading belt earlier in the line. The belt lane isn't fully compressed before it reaches the inserter.

By contrast, if you compress a lane with inserters, inserters down the track will never insert onto it (because it is truly fully compressed). In any case, I'm sure the devs will work out exactly what is happening here as it's clear that inserters have different behavior to belt compression than other elements right now (which kovarex has said he's looking into above).

[AntiElitz]

No, this is is completely not about sideloading, that is a different bug. As you can see the sidebelt never comes into affect and I could also remove it. This bug is about 1 inserter inserting an item on a not fully compressed belt. The lane wait for the item and backs up. The area that backed up must be fully compressed because it waits right? However magically the inserter find another gap in the area that backed up which should not be possible.

I repeat this bug is about backing up does not fully compressed a belt for an inserter, not sideloading.

I'd appreciate to split the sideloading bug into a different bug report thread, to separate these 2 different issues.

[AntiElitz]

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.

This is exactly the reason of the issue i was talking about! Great find.

[Engimage]

I think this is intended behaviour here and is related to belt optimizations. We can obviously see the whole belt block (like 8 belts) back up unstead of individual items.
IMO if this results in better performance then let it stay as obviously the compression is achieved.
However these gaps are there due to a real bug which is sideloading not compressing. This is what is really causing problems.

Here we come to an interesting dilemma. While this behaviour lets you fill gaps it does not really produce desired compression if it can't force belt backing up to compress as well. To recreate the problem at a disastrous level I dare you create a circuit contraption which will put individual items on a belt spaced say 10 slots instead of current 8 and see the result. And a result will be like a disaster where you will generally lose like a half of throughput.

So this insertion backing up is not real backing up physics but another version trying to be heavily optimized. But personally I think this is not a good decision.

[Loewchen]

Ref: 58046

[kovarex]

Hello, this has been fixed for 0.16.26

[Engimage]

My hands are shaking... Show me! Gimme!