[Kovarex] [0.16.0] Sideloading works completely different now

[mrvn]

I want to mention something that I think is related to this problem:

When you have a compressed yellow belt becoming a red belt then, since red belts are twice the speed, there should be enough space between items to fit another item. But neither side loading or inserters can reliably place items in the gaps. I think they can only place items when the yellow belt isn't 100% compressed but has a 1 pixel hole.

When you are trying to do that, you have a red belt with gaps exactly 9 belt units long (exactly the length of one plate), but moving at 2 belt units/tick (where a belt unit is the distance a yellow belt moves in one tick). So the gap might be one belt unit before the inserter one tick, then one belt unit past the inserter the next tick. Hence the inserter might not be able to insert into the gap. Side loading probably has similar restrictions.

That makes sense (from a programmers viewpoint).

[mh_]

I want to mention something that I think is related to this problem:

When you have a compressed yellow belt becoming a red belt then, since red belts are twice the speed, there should be enough space between items to fit another item. But neither side loading or inserters can reliably place items in the gaps. I think they can only place items when the yellow belt isn't 100% compressed but has a 1 pixel hole.

When you are trying to do that, you have a red belt with gaps exactly 9 belt units long (exactly the length of one plate), but moving at 2 belt units/tick (where a belt unit is the distance a yellow belt moves in one tick). So the gap might be one belt unit before the inserter one tick, then one belt unit past the inserter the next tick. Hence the inserter might not be able to insert into the gap. Side loading probably has similar restrictions.

That makes sense (from a programmers viewpoint).

IHMO that does not make sense.
There are some other bugs with belts that would explain this behaviour, but if they are fixed the following should work: Loading a completely full yellow belt onto one side of a red belt.
If only one side of the yellow belt unloads onto the red it should have item spaced such that exactly 1 item fits inside (9 belt-places). Thats it. This should work. If not we will file a bug report. But with other bugs in belts creeping around there is no way to tell if the sideloading issue itself is a bug.

for example this bug could explain it (mentioned above already several times):
viewtopic.php?f=182&t=54693

[Koub]

I'm saying wait for the devs to actually fiw what they think are bugs. Once we've been delivered, if we think something doesn't make sense, we'll suggest an evolution.

[mrvn]

I want to mention something that I think is related to this problem:

When you have a compressed yellow belt becoming a red belt then, since red belts are twice the speed, there should be enough space between items to fit another item. But neither side loading or inserters can reliably place items in the gaps. I think they can only place items when the yellow belt isn't 100% compressed but has a 1 pixel hole.

When you are trying to do that, you have a red belt with gaps exactly 9 belt units long (exactly the length of one plate), but moving at 2 belt units/tick (where a belt unit is the distance a yellow belt moves in one tick). So the gap might be one belt unit before the inserter one tick, then one belt unit past the inserter the next tick. Hence the inserter might not be able to insert into the gap. Side loading probably has similar restrictions.

That makes sense (from a programmers viewpoint).

IHMO that does not make sense.
There are some other bugs with belts that would explain this behaviour, but if they are fixed the following should work: Loading a completely full yellow belt onto one side of a red belt.
If only one side of the yellow belt unloads onto the red it should have item spaced such that exactly 1 item fits inside (9 belt-places). Thats it. This should work. If not we will file a bug report. But with other bugs in belts creeping around there is no way to tell if the sideloading issue itself is a bug.

for example this bug could explain it (mentioned above already several times):
viewtopic.php?f=182&t=54693

That's not what he is saying. When the belt goes from yellow to red you get the following:

Code: Select all

                      v red belt                       v inserter
t=0 ##################---------#########---------#########---------########
t=1 ##########-#########---------#########---------#########---------########
t=2 ###########--#########---------#########---------#########---------########
t=3 ############---#########---------#########---------#########---------########
t=4 #############----#########---------#########---------#########---------########
t=5 ##############-----#########---------#########---------#########---------########
t=6 ###############------#########---------#########---------#########---------########
t=7 ################-------#########---------#########---------#########---------########
t=8 #################--------#########---------#########---------#########---------########
t=9 ##################---------#########---------#########---------#########---------########

The inserter can only place an item when it has a gap of 9 "-" AND the first "-" is below it. But as you can see above that never happens. One tick it still has a "#" below it and the next it has a gap of 9 "-" below it but is already one inside the gap. The gap has already move past the inserter.

What I think should happen is some anti-creep. When a gap approaches the inserter and is near enough that next tick the leading edge of the gap is past the inserter then the item should be place already, creeping back a few pixels. There would be no compression or anything. It would only ensure that a perfect gap won't get past the inserter because the leading edge never aligns the with inserter at tick intervals.

[Zavian]

What I think should happen is some anti-creep. When a gap approaches the inserter and is near enough that next tick the leading edge of the gap is past the inserter then the item should be place already, creeping back a few pixels. There would be no compression or anything. It would only ensure that a perfect gap won't get past the inserter because the leading edge never aligns the with inserter at tick intervals.

Well for inserters to be able to fully compress a red belt the inserters need to be able to drop into those odd belt positions (odd as in 9 belt units after whatever is currently moving past). This is something you can't achieve currently even with circuit controlled inserters for red belts (for yellow and blue is isn't an issue, yellow only moves one belt unit/tick, and blue move 3, so in 3 tick a plate is past and the inserter can drop without leaving a one belt unit gap. Note that for blue belts this also requires inserters to be spaced at multiples of 3 tiles). I'm not convinced that this needs fixing, but it does prevent inserters being able to fully compress a red belt. I haven't tested whether an inserter with a stack bonus dropping 2 plates on a red belt actually drops the second plate without a gap of one belt unit. That is a potential work around for circuit controlled inserters.

I also think that this "belt moves 2 (red) or 3 (blue) belt units/tick" might be part of the cause of the side-loading and splitters decompressing bugs.

[mh_]

I want to mention something that I think is related to this problem:

When you have a compressed yellow belt becoming a red belt then, since red belts are twice the speed, there should be enough space between items to fit another item. But neither side loading or inserters can reliably place items in the gaps. I think they can only place items when the yellow belt isn't 100% compressed but has a 1 pixel hole.

When you are trying to do that, you have a red belt with gaps exactly 9 belt units long (exactly the length of one plate), but moving at 2 belt units/tick (where a belt unit is the distance a yellow belt moves in one tick). So the gap might be one belt unit before the inserter one tick, then one belt unit past the inserter the next tick. Hence the inserter might not be able to insert into the gap. Side loading probably has similar restrictions.

That makes sense (from a programmers viewpoint).

IHMO that does not make sense.
There are some other bugs with belts that would explain this behaviour, but if they are fixed the following should work: Loading a completely full yellow belt onto one side of a red belt.
If only one side of the yellow belt unloads onto the red it should have item spaced such that exactly 1 item fits inside (9 belt-places). Thats it. This should work. If not we will file a bug report. But with other bugs in belts creeping around there is no way to tell if the sideloading issue itself is a bug.

for example this bug could explain it (mentioned above already several times):
viewtopic.php?f=182&t=54693

That's not what he is saying. When the belt goes from yellow to red you get the following:

Code: Select all

                      v red belt                       v inserter
t=0 ##################---------#########---------#########---------########
t=1 ##########-#########---------#########---------#########---------########
t=2 ###########--#########---------#########---------#########---------########
t=3 ############---#########---------#########---------#########---------########
t=4 #############----#########---------#########---------#########---------########
t=5 ##############-----#########---------#########---------#########---------########
t=6 ###############------#########---------#########---------#########---------########
t=7 ################-------#########---------#########---------#########---------########
t=8 #################--------#########---------#########---------#########---------########
t=9 ##################---------#########---------#########---------#########---------########

The inserter can only place an item when it has a gap of 9 "-" AND the first "-" is below it. But as you can see above that never happens. One tick it still has a "#" below it and the next it has a gap of 9 "-" below it but is already one inside the gap. The gap has already move past the inserter.

What I think should happen is some anti-creep. When a gap approaches the inserter and is near enough that next tick the leading edge of the gap is past the inserter then the item should be place already, creeping back a few pixels. There would be no compression or anything. It would only ensure that a perfect gap won't get past the inserter because the leading edge never aligns the with inserter at tick intervals.

Damn you all, now I understand what you mean, thanks. However we were really taking about two different things. I was thinking about belts and thought inserters have the exact same problem, you did the other way round.
For clarification: Take this blueprint:

Code: Select all

0eNrtXV1vG9cR/SsCn1pADPZ+3yu0D0FrIAbSFKiN9qEwBEpc2YtQJLFcOXEN/ffsiqTF7F5K54xl193qJYop7eHsmZn7MXdm7sfJxeKmXNfVspmcfZxUl6vlZnL274+TTfV2OVt0nzUf1uXkbPK+qpub9pPTyXJ23X2w/YvpXye3p5NqOS9/nZyp21PiyRcHT2rqyb8dPGmoJ/9+8KS9fXM6KZdN1VTl9qXv/vHhfHlzfVHW7evcP92U5WJ6+a7cNC3kerVpn1ktu+9rcabhdPKh/ZFuO1F6GPoTRvnrui43m+liNZu3vxnCuO/cHuh0Mq/q8nL7W3+6f6tqub5pJplvMYNvaerZcrNe1c30olzkhLb578qAWx7cwOCOB9cwuOfBFQweaPACxo40Ni53orFxwlVBg+OmohQNjhu50jS4w8F5//Q4OO+fAQfn/TPi4Lx/KtyHFO+gCQeP+Li+Yzt8536Paz+N66ub5sjAru699Wq2aR4fv3ZGGXpflZuZChl0BKAVCW2z0DnitSahDQ5tSGiNQ1sSWuHQjoMucGTPIRMyBw6ZIDpyyIR1kJ6Im7QhHdHhyKQfehyZdMOAI5NeGHFk0gkTjtzzwZt2g1G/rVftz4exu2H60TnAyKfJmNuSmCDGC1m84Vy4WS+qpsnPhvtdjnt8HjH8WnXqYXRbMHL7vdweQBbOfz1onYPWslkbgb73vGq5Kes8Dwfau1wtm3q1OL8o383eV6u6+5PLqr68qZrz9nfzT89dVfWmOYc36S+7Tfqm7CDwh15P7iS6Xs/qWdPJMvnT5HYr5HL71psORXX/eVuX5fJwx1/N29c/1GT3gfLq9k0HsXpf1nU1L883zezy51ak/5S7WEefQYswaEfLoOkxaANLoJMtwRDr9rKFIwIdELWb/xvHsZFVe0QI1KMlMPQIdPTAk0SbAMC2XSHbuSDQCtG6Gq3WY1/rmtS60wCBxVj5c6rPn2P5M6JtKGLaVrR1RpAdoPPR+ozTfZ17Vuce4G+0M03rIj3+EstfEIVBEMuWhW4Q5ATofLTLM+d7OvcFqXNfAPyNdlfTukiPP8PyJwvDAZbttSh0iCAjwYDRxgJaF+np3LI6R0IBfrT89SMBno0EeCcKAyOW7UWhawQZiQOE0eq8HwbwbBjAI2GAOFr++lGAQM/TSXgM0bftxxOOArIkSKNVFWvZQYmPXHzuyCVoMZ7L4gkSyNRul2kePw8JVg5vAXhBEtmeDgskegnSyBKOzp/GTSOOHsXoiF7l53MAeizE6IDRRN4l95k8CLoWoxsgPfDeXdGjRQTV0qgIEw5HdbhteBoVkTXgqBrnNdKoiKwJRzUwr6mgUQFZk4JRC5jWpHFR8akqGVZU5P0tLSqCinsWbqwJdyyC1MBKirx+ZCVFQHGvwgdWVeBehbuqKhQrq0VQNSsrhIq7lSd4tSwqJCvuV47QlmdRIVlxz4oEr7hrBYKBxMqKMKAKVlYIFfethDOgNIsKyWrEm0F7mwW0YkCTB3Ty/Z9CGPByfI3gB/kGE5JfvkuD4JN4A6uQyhkqjzLu8ygR4ulCAp8VW2ex5Vs0CN6I4SFmrHhzrBGd3nvsdTmvbq6n5aJ9oK4up+vVojy+I9TZAeCglODxoOT0iIE8HpVUbGHBXmpIoVGWeQthJ4YfI+aHLTXY70eRd2CLDfavAWFrhh8l58eI8uigVxCWAEHYrLfqh5zVMM76GVzLioAgPqIo/QqCZjxV7qi2EKXZIG/AFicQbmoZN5WP8taI8imgN7CihAoImnXS+JCTWsZJg5zqIDqGh/iIonN4CFp6EKpuAU4OUqJhYAH1Tn5mmDcZJz80VHlA+akhsm1x8lPDAoGXnxoWg/PyL3W+/Wp7VL3cNLOuQ0vRO7f+892vd99TLmcXi/J8Xm26n5Ozpr4p739bl7P5+bvZct7J07RkbCZnV7PF5uBP9r/Y/u31al5uXxU+F1eDXEOV3OCTu5TTrEa8dBtcDDqmfCWFqG9dIe4o2UEaFCgGY9m3n93xxZWSpTiym+i4GxyzaMSBX4IHWU8c+Pks6rP6j6jfQ/VN/pNPjbwYVHk9+KQ/OejupGz/zncf9P8gsQUL6iBHenM9Wyymi9n1+mjwbXyK2JUxZ6kxbBYFNKQQVdBjpHuw4qHTBZV3eCn+OC22T6GlKfRsNhNk2wGvVB6jYvo1qypoWjERr5YfI4XDNhOBpjCxGWWIbQc69wtCVXCR8gi1HQZrnsBWrKqg8Tr5MTpMGFCoaArZrD7IsumsPgjVwQXKY/SXQQApFrSyPVwiP0YGB2un4GgG2XxNyLDZfE0INMGlySPUdSwG3kKvk2MBF8eP0VsGm7VABxgim4eLGHZk03AhUAMXJY/RWwYr70hvzKOFy+LH6C1pwKChGWSzqyHD9mQi+HMQGwxixwDXZI9xyBjEOxK994gR7gowRgYHxwCRDndEtnDg2btB705s8cQzsyizCm6QMEavp308saUxz5aIWqK4POiLG+ZBHo3/VtgS1z7lszYOinT3bzttX/SiWt69aCZSuI2oaCjF7KpatAMLeWPXLoXpZpe/JLq7619ZDO4Wr5dZDO4+r9dZDEth/CWL4SiMH7IYnsL4MYsRKIzvsxiRwvgpi5H4u92GNtbFcsn0tf762x9LZjioXKc8zXw5T/vHE3jaiyfwtN95vNTVXjyBq70+4mpv2v/fnHf03w3clI2koymOKYgTiJFq3hTF8EiF30ErggfzlnbTj779b2Yhf55X66J/aGHMsaQlfdBMYV5etovL+mE33184gvn5DvKers3XWjH+lFkxnu6uhaHXVesP53dudn5Vr67Pt0UGd8smSlOZdLxu/Nb4Aypzp0Zf9/aophXmAfFrO4D6TAc4mgKvie4buyRfg9z0ZlhUjaBacsINWegnnG9//Ebm2++fYGX7zyeYbl88wcr2cMruKv1Fy9IfnmBZ+vIJlqWvji1L6TuEhyBGvsguinti1VOoWDluoZ0d6PMDlGPrBaAByrOo0AAV+K4Dhr+jUxPtcnbfArRg0ES7nF0CK8I00S5nh4owfdAuB+5fIGGaaKAz1bj0hk18RPSnLCsrpD/Hd0IQMe3Z5DaIk0Dm4UGURBIUsolEN0GQ0KwLMikKYVkrMn0LYVlrEhRh+aBJDtpNQcSyJZNpIJYdmfYDsexJUIjlQLdlELEcycwOiOVEZnYgLJuCBEVYNoruyCBh2WjyyBZh2RjyhB1i2ZKgEMuObr4gYtmTx5EQy4FolKaKT3GrLFaUnlPpPB7fI07hMxJ31a5Su1cHLvHV9F27Oxrc431EtNXiCK9FRDcy0S0iOttuKuKssJe0Jhzai6AhQoKIEAg6iroUQoSQF3vuYmwINH2zp4cJcUokNQStRR3+IEKMqMEfBG1FUkOEOJHUELQXdQuECAmiZoEQdBRJDRGSRFIj0L6QdB5E+PBK1HgQgtYSoSE6jEhoCNpK+g5CdDhJ20EI2UtkhtgIEpkh5ChpYQixkSQdDBHkIGq7iLARRF0XIWQt6YYIsWEkzRAhZCuRGWLDSWSGkL2kFSLERpB0QoSQo0RmiI0kkRlBjqQPEvu5SDohvnGJWoIM0SFO380299fRSjf6R/CcFM/l8SS9/LfzXQD23DGI4T0CH2Vbep/nIonjDwEwrVSI4REu0rCBKXJkVWTlf7xhqk5aFDzwQPwqGVHwAIK2EpbiwyQ9ENkkbo3aERSytpm8KHwA2WUQhQ8g6Mg0g/Ojq8zRx1PPUsLbFfr/weIbjqb4aOKiKdjaZ1MUojAQYNimUKIwEASt8X5+YzeMTul9Mwi0GRi8u9/4PS0NCNU0oVYU8oOM34lCfhC0x3sJjt+v+l2+jFK0GQS8s+D4CdUDv/I0oVES34VsP4niuwi0KuCGg6M3AjVYtCi2GZhRCm8/OH6v8gNCC5pQLQnmQ6ZvJMF8CNnCXQnH71RuYAOJtgEH9ygcP5/FgE9L8+klBzeQ5QfJwQ2EHOHeheO3gcEuQNO7a5XgTobj59MOfIrtdWd0ITmkQyyfvdYVj1VoDXc4HL0N6EGoQtOhCm3gfofj96k44JOOVGgrOZCFLN9JDmQhZA+3ABy/Tw3CFJpe++kANwQcP5+DKIWmoxTsxcwJt/wEN3Ebv6ZovZhCfNQeAeUYJb6/MT7f33i0MUW/D8ux7hzGaDH/CVGv4UpGtor9ziHQVnrPZHy+ZzI/Ohxt12OMk5Kd8nheem8lZHWBzY6IeSnpqx/tQ2hJdL97HuygFou5h7oF67p0NeV1++DF4qZc19Wyo2Uxa/lpP3vVTgqL1WxeLd+e/LKqf96cdBa7KJty8eFkXl1dlXUrysly9cvJHy4+nFy/+2P7cDuZbLauFIMuvPMm2tvb3wAD7exh

Explanation: Fill the chest. Turn the two constant combinators to the far left on and off (read them for clarification). Turn up speed: /c game.speed=100

Turns out: we both were right. The inserters get stuck right a way in a pattern that could possibly be explained by mrvn's description right away.
The belt behaviour however is strange, since the transition between the side-loading and the side-loaded belt do depend on the adjacent belts in strange ways. Please tell me how this is not a bug.

Covarex (probably): Does this count as a good enough "how to reproduce"? I tested for loop/circular vs strait, both have the same problem.

A easy fix proposal: If the belt gets stuck try to place the item not only belt-position 0 on the target belt, but after that fails try to place it at belt-position 1 in forward direction, so it could fit on the position that just ticked away by 1. Same for inserters. They can place should place the item either at position 0 or if this is not possible at position 1. This could be done for pos. 3 as well although as mentioned before we could probably live without it.

[Ringkeeper]

ok... didn't read every post word by word, but so far i saw only "yellow to red" and "red to blue", where workaround exist... but what do you do with "blue to blue" ?

https://imgur.com/a/chaDP

Before i reloaded the save the plastic was the same, now there was a little backup , after that plastic kinda went normal.

[mh_]

ok... didn't read every post word by word, but so far i saw only "yellow to red" and "red to blue", where workaround exist... but what do you do with "blue to blue" ?

https://imgur.com/a/chaDP

Before i reloaded the save the plastic was the same, now there was a little backup , after that plastic kinda went normal.

Your problem should have something to do with the splitter problems that are still unresolved. I would suggest it occurs in the splitter before the sideloading.

If you want sideloading atm, just use the the default setups:

This has the advantage of being able to be input balanced.

Sideloading a empty color belt from a full belt of the same color should be no problem. If you find a problem with that please try to find a minimal example that is not embedded in your factory and somehow disconnected from other bugs, that are still open. This one here is strange enough already.

[Engimage]

Your problem should have something to do with the splitter problems that are still unresolved. I would suggest it occurs in the splitter before the sideloading.

Actually not. It is a general problem with sideloading.
The core issue now is that you can actually sideload only from one side of the belt. So if you split a belt and try to sideload splits to 2 different belts it will result in 2 spaced results (randomly, not always, depends on relative positioning of lanes against each other).
If you sideload a full belt its ok every time.
So the problem is that inner belt lane does not effectively sideload if outmost one has any items and is not empty.

[mh_]

Your problem should have something to do with the splitter problems that are still unresolved. I would suggest it occurs in the splitter before the sideloading.

Actually not. It is a general problem with sideloading.
The core issue now is that you can actually sideload only from one side of the belt. So if you split a belt and try to sideload splits to 2 different belts it will result in 2 spaced results (randomly, not always, depends on relative positioning of lanes against each other).
If you sideload a full belt its ok every time.
So the problem is that inner belt lane does not effectively sideload if outmost one has any items and is not empty.

I take back saying this depends on the splitter. I tested. Easy fix for Ringkeeper: Give the splitter output priority to the left. This circumvents the bug.
Anyways: We perhaps could help the devs by finding a subsitute for "random". Any ideas?

[Kirk]

I seem to be having some success with this setup now.

[ospeovedos]

Unfortunately, my balancers no longer compress the belt in all cases:

...

As far as I can tell, the only way to make a balancer that compresses in all cases, without using a faster belt speed, is to split off the input to feed two balancers like the one in the picture then combine them with a splitter. It's a big mess.

Big mess fixed! It looks like 0.16.25 solved all of my problems. Major thanks to the devs for working on all of this!
I'd write more, but I need to get back to my factory...

[5thHorseman]

I seem to be having some success with this setup now.

That's pretty cool. I can't wait to fiddle with that idea, and see how the ratios are (If it's truly 50/50 that fixes - like - every balancing problem I've ever had.

[mh_]

I seem to be having some success with this setup now.

That's pretty cool. I can't wait to fiddle with that idea, and see how the ratios are (If it's truly 50/50 that fixes - like - every balancing problem I've ever had.

It does NOT. It just allegedly fixes the "full yellow to single red belt"-problem.

[5thHorseman]

I seem to be having some success with this setup now.

That's pretty cool. I can't wait to fiddle with that idea, and see how the ratios are (If it's truly 50/50 that fixes - like - every balancing problem I've ever had.

It does NOT. It just allegedly fixes the "full yellow to single red belt"-problem.

Yeah you can fiddle and get promising looking setups, but as soon as the belt backs up it loses the balancing. Oh well, at least there are more tools in the box now.

[mh_]

I seem to be having some success with this setup now.

That's pretty cool. I can't wait to fiddle with that idea, and see how the ratios are (If it's truly 50/50 that fixes - like - every balancing problem I've ever had.

It does NOT. It just allegedly fixes the "full yellow to single red belt"-problem.

Yeah you can fiddle and get promising looking setups, but as soon as the belt backs up it loses the balancing. Oh well, at least there are more tools in the box now.

Version 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.

officially fixed, not the nice way in my opinion, but fixed

[Loewchen]

For issues beyond the fix of this one see: 58046, 57998
If you found something not yet reported, make a new report please.