[2.0.32] Yet another belt compression issue

[xeneonic]

02-26-2025, 13-17-46.png (617.34 KiB) Viewed 522 times

1. The middle belt row doesn't properly compress the items while the top and bottom row do. Any underground distance higher than the bottom belt (So, a distance of 2 or greater), produces the compression problem.

2. Weirdly, to me, removing the single belt piece that I marked in the red square, will also cause the belt compression issue on the bottom belt, but only for a few seconds, after which it'll rectify itself for some reason. adding the single belt back in, will cause the belt compression issue to show once again, once again only for a few seconds.

[xeneonic]

Added a video, showcasing what I mean.

[Pizzamand]

Can confirm this is still the case for [2.0.42-4]. I encountered this strangeness when building the train-unloading station that I also used in this reply to show the behavior, so i chose to try and get as close as possible to the how and why, because I wanted to fix my unloading station

Treat this post as two version, this part is me messing around and finding when and where this behavior occurs. The second part is what seems to matter.

The first part:
It seems that the side of the underground that you insert into matters.
The behavior never appears when loading from the "underground" side of the underground belt, as shown in the attached screengrab right below, no matter the belt length.
It does appear (With underground distance being greater than 1, as OP mentioned) with insertions from all 3 other sides.
The screengrab shows how the 4 inserters of the top case remain in sync, performing their 80 items moved onto belts per second. This rate of transfer also holds for the top 2 inserters of the bottom case, but the bottom 2 inserters of the bottom case have desynced, with noticeable larger gaps between the deposited 4x4 groups of plates.

image.png (485.65 KiB) Viewed 294 times

I also did some tests using yellow inserters of normal quality and differing stack size settings, shown in this image.

yellowstacksizetest.png (1.17 MiB) Viewed 294 times

The first is a stack size of 1. This caused the iron plates to be placed a little delayed from the control-test, but they did not lose any throughput, which was unexpected.
A stack size of 2 causes the exact same behavior, they were delayed, but throughput was not reduced.
As soon as the stack size reached 3, the throughput becomes reduced, which can be seen with the longer distances between the groups of iron plates in the affected cases.
A stack size of 4 has the same issues as 3.
This behavior is inserter- and quality-agnostic, and it occurs in the same scenarios with all types of undergrounds (according to my tests).

The inserters where this issue appears are spending visibly longer periods of time depositing, and less time swinging, when compared to any other case where the issue is not present. This also seems self-evident as the swing-speed of the inserters should be the same when the inserter and their quality is equivalent, so time spent depositing to belts should be the difference causing the loss of throughput. But the groups of iron plates are placed exactly as compact as they can be, which suggest swing-speed would be the issue, but that seems both not true by inspection, but also impossible.

The loss of throughput seems to be somewhere around 7.8%, which is calculated using the below attachment. Under normal circumstances this setup should produce exactly 4 green stacked belts, but the belt using 3 combined insertions into undergrounds from one of the problematic angles is lacking behind, but the others using insertion from the "underground" side suffers no loss at all.

image2.png (677.07 KiB) Viewed 294 times

(The splitters at the problematic belt were placed in this manner to more easily show that the loss of throughput is not because of anything being backed up. The throughput measurement is just a 1 minute counting, no averaging to produce more accurate numbers)

The second part:

yellowdistancecomparison.png (521.75 KiB) Viewed 294 times

See how the iron plates for the non-issue case are further ahead than the issue case? (If it is hard to spot, look at the very end of the belts)
This would make sense with how inserters places their items when the undergrounds are in the same tile. This small distance keeps being the case for all stack sizes, when we compare the undergrounds of distance < 2 (where the issue of reduced throughput does not occur) to the ones where this behavior never occurs (like with the top 4 inserters).
But the in the case with the issue, just changing the length of the undergrounds seemingly changes the location where inserters place their items, and for larger stack sizes, this starts to cascade upon itself and reduces throughput.
This, combined with OP spotting that having a seemingly unrelated belt at the end seems to change something, would seem to suggest that the spot where inserters place their items is different in some cases, like undergrounds < 2 and ones being 2 or longer, but I am not qualified in the slightest to know anything about this at all.

[atomizer]

Previously on this topic: 98223

[Rseding91]

Thanks for the report however I don't believe this will be changing. This is simply how belts work and has been how they work since forever.