[2.0.29] Recycler doesnt return ressources equally weighted

[Legendendear]

So I noticed in my upcycling loop for Accumulators on fulgora that I accumulate consistently too many iron plates, compared with the batteries, so I set up a test world to affirm that this is indeed a problem.

I also noticed this problem reappearing with other recipes using batteries, but I have not confirmed that in a test world.

This problem is probably not battery specific, but I have only noticed it with them.


Expected behavior: Recycler returns all resources with a 75% loss rate, but equally weighted, so an assembler reassembling the ingredients can assemble ~25% of the original input.

Observed behavior: Recycler returns consistently only ~1/3 of the expected amount of batteries

[Lou]

Hello. If the Bug report.zip is supposed to be a save file, it appears to be corrupted.

Anyway, I did some quick test on latest internal version I did not observe incorrect ratios.

ShareX_OXaDszk5nr.png (1.31 MiB) Viewed 672 times

[Legendendear]

Ok theres some funky business going on here.

I set up an input of 6k accumulators to be recycled and stored the plates and batteries in chests.

There is a visible difference between the production stats and the actual production.

See attachments

Screenshot (8).png (719.43 KiB) Viewed 641 times

Screenshot (7).png (644.72 KiB) Viewed 641 times

[Rseding91]

Does the value show correctly in the “all” tab?

[boskid]

Please post a save file from the "funky business" contraption where the issue has occured because there are some suspicious parts of your setup that i cannot verify just from the screenshots.

[boskid]

Ok so it looks like this bug report is chapter 3 of "boskid does not understand how flow statistics are implemented", chapter 1 being 120351 and chapter 2 being 125025. All 3 of those are covered by tests so i hope they should not reappear again. Statistics issue should be now fixed for 2.0.30. Counts in the "All" tab should remain correct.

[Legendendear]

Well it turns out this particular problem was a problem by my own doing...


But nice that its fixed anyway...

Congrats. You guys are the only devs out there I know of who are able to fix nonexistent bugs Keep on rocking.

Oh and sorry for the time loss I have caused you

[boskid]

Well, there was a bug that i was able to observe in the flow statistics so i am not fixing a "non existing" issue.
Chapter 1 was observing that flow statistics values get too large because they included a newly created sample, so i removed that sample from being included as it caused the overall average for the time period to be inaccurate.
Chapter 2 was a report where statistics were incorrect between time frames (internally each time frame is a separate instance of statistics with a different time to commit an accumulated sample) so i had to readd the currently accumulated sample and fix the root cause of the incorrect equivalent time used by the average by subtracting fraction of the last sample from the flow statistics window.
Chapter 3 is that the value to adjust was supposed to be taken from the oldest sample but because of some obscure implementation of flow statistics i was actually using newest sample so the value shown was incorrectly smaller than it should be because the adjustment was applied when there was nothing to adjust yet.

[IsaacOscar]

Well it turns out this particular problem was a problem by my own doing...

I'm curious, what was causing you to not get enough batteries?