[boskid][1.1.33] Do Loaders sleep too long?

[eradicator]

After a loader enters sleep due to a saturated belt it produces a minimal gap on wake-up.
(Yea, sorry for posting a belt gap bug... )

The circuit stops the belt for 1 tick every 30 ticks.

loadergap2.gif (1.86 MiB) Viewed 4133 times

0eNqlVluOozAQvIu/YYQJ5IH2GPu3GlkGOoklsJFtookiDrC32LPtSdaN8yAT2Ly+kN12V7nK3eZA8qqFRgtpSXYgolDSkOzXgRixkbzCObtvgGREWKhJQCSvcQRfjQZjQqu5NI3SNsyhsqQLiJAlfJGMdsHDSSrFS9CDzXH3GRCQVlgBnk4/2DPZ1rlbmdFzDiHXQrpQWGzBWJe7UcZtUxJRXaowjj/SgOxJlqQfaQ/hNzAD1gq5MbhQQ612wFoXqyxoKBkydaE1rwwExE97KidgrWTYVNyCAy1UiwKmURQFpFYlLuA2rID3nM6afHYoy7fDxFOCjByGDo9SCg2FD7scR4lVa5sWnbjBmd1z7xaPLq/FGyKOICQvIKyeQkhfQJg/hTB/AWHxFMLicb9pctdvISfsXr5wkHT6IHjJpdWqYjls+U4ojbsKoYtWWOZi5TnVWmhj2U3x74S2rZs58/Irwp9Y+dh4LMciinBQN1xzixjk7+8//YIjEkieV8BKYfBLMqtbuEQ18JJtuSyRkXWKXGp4QLUP+LW+WCPPQPrT9i2B+r5QDtuPcCMaXVLhOMaiHpF/9XiLom+1KBRgjAASPTIooRDugoVO11zIXtcRFlO9ZT5u/THpxXrzvvez7+b/cDt8R3s6Z7NnfVtma61q5svkJNao2RsNIO/bHVzHsakHJJ64LUt8yR5KTCfuEb28dSed/u/jdEOdMHL4uD0rcv/s0asX7g1xvQZOsf4/IRv8mwRk5yj6TrSkyWIVL2bLJJonUdf9A6yS+yw=

Copy blueprint

[eradicator]

Is there some official policy now that "belts are good enough" and gaps are generally not going to be fixed, or was this rejected because it's loader related? It would be rather nice to not have to waste time on writing reports just to have them trashed with no fucks given. I mean, if you can't be botherd to give reasons, then maybe I can't be bothered to play bug report lottery.

[sp55aa]

what do you expect?

[disentius]

Some reason why would be nice, and a recognition of the effort involved in reproducing the bug. Just moving it to "won't fix" feels rather dismissive.

[eradicator]

what do you expect?

I expect that - given that we all spent time and effort to report bugs for free, so that they can sell a good game - Wube would at least have the grace to notify the community if some classes of bug reports are generally not appreciated. This is imho the least they should do to stop wasting everybodys time (including their own). I don't even personally care about belt gaps. But I spent half an hour on finding, reproducing and filing a proper report anyway. Hoping to help. If this help isn't wanted/needed/appreciated then why not just say so? Anything is better than silence. There's even a Known Issues pinned topic just for this. But I see nothing there related to this report. I'm sick of having to try to read the devs mind on what might or might not - to them - be a "worthy" bug to fix. So I'd rather stop writing reports at all that don't directly affect me or my mods.

I don't have any grudges. I hear Corona has hit Czech pretty hard - hope everyone is alright. So I'm sure everyone is not in their best mood. As am I. So I just want to not waste time and effort.

[boskid]

I have no idea what was the reason behind moving this bug report to wont fix. Just in case i decided to look at this behavior and i found why it was leaving a gap. This behavior was because loader registers as a sleeper which is a "sideloading" interaction and this has some consequences for when entities are being woken up: all sideloading iteractions are only woken up when there are gaps on the belt. This makes sense to not wakeup inserters and mining drills when belt is full as it would have quite huge performance impact. In this particular case the condition for having gaps was not triggering even when there was a gap because the condition works under an assumption that there may be a direct input belt which will add some items onto the belt which will fill all the gaps. This condition is based on the current belt speed and designed items spacing but it was not accounting for a case when there is no direct input belt. Since it is not possible for an output loader to have a direct input belt, this condition was kind of wrong as there was no direct belt that could, even in theory, fill those gaps. So i made some small changes into the transport lines logic which will wakeup side interactions when belt has no direct input and there is a sufficient gap on the back of the belt. This may also change belts behavior in some other cases, like waking inserters a tick earlier, mainly when they are dropping directly onto a first belt which has no direct input.

I think this is fixed for 1.1.35.

[eradicator]

Just in case i decided to look at this behavior and i found why it was leaving a gap.
I think this is fixed for 1.1.35.

I am glad for all the people who actually care about belt gaps. I think you deserve at least a heartfelt "thank you".

I have no idea what was the reason behind moving this bug report to wont fix.

But,... at this point I'm not quite in the mood to pretend that this makes everything alright.

I wish everyone a nice day anyway.

[disentius]

Thanks Boskid!

[eradicator]

PS:
Oh, and I forgot to mention that I do very much enjoy reading the detailed technical explanations that you always give. Even when you're just explaining why something can't be done. It's a service that not all devs bother with and gives a feeling that you don't think of the community as just a bunch of numbers on the quarterly financial report.