[boskid] Assembler working animation continues for 1 additional tick after finishing

[jurgy]

I was working on synchronizing an assembler's animation with the crafting and kept finding that the animation keeps drifting.

Repro:
I've modified the chemical plant's graphics to include the frame count (see attachment) and the the animation speed to last 1 second. Furthermore I've set the crafting time of explosives to 1 second as well

Code: Select all

data.raw["assembling-machine"]["chemical-plant"].graphics_set.animation_progress = 1
data.raw.recipe["explosives"].energy_required = 24/60

Starting state:

05-10-2025, 21-55-25.png (412.19 KiB) Viewed 182 times

After crafting the explosives once:

05-10-2025, 21-56-56.png (416.31 KiB) Viewed 182 times

This only occurs when the machine has to start and stop. If you throw in enough items to craft a bunch of time, the animation only drifts by 1 frame.

[boskid]

Welcome in the world of floating point errors where i have to explain why this is Not a bug.

I looked at the assembler's crafting code and assembler's animation code and here is what i found: Recipe you have is indeed specified to craft in 24 ticks, however when assembling machine is working, after 24th tick the crafting progress is not yet 100% but it is 99.999999999999% due to floating point errors accumulating. This means that this recipe in order to finish needs actually 25 ticks: 24 ticks are consumed entirely for crafting but the 25th tick is required to bump the crafting progress by remaining 0.000000000001% and this advances the animation by 1 frame. When the crafting machine is working continuously then this looks slightly different: since in that 25th tick the crafter only had to increase crafting progress by 0.000000000001% to finish previous craft, it has still remaining crafting capabilities and it immediately starts second craft. This is why when you have a crafter working intermittently it behaves as if it took 25 ticks to craft but when it is working continuously it behaves as taking 24 ticks: that one tick used to finish one craft is not wasted as it can still advance second craft.

As a workaround you can reduce your recipe's crafting time just a little and the animation behavior will be improved:

Code: Select all

data.raw.recipe["explosives"].energy_required = 24/60 - 0.000000000001

[jurgy]

Thanks for looking into it and provide a workaround. I did think of it being a floating point error, but had assumed that internally crafting time would've been converted into ticks and thus be discrete numbers not taking into account that the progression is actually what drives the animation logic.

As for your workaround, would that work in every case - i.e. any animation length and continues and intermittent crafting - or is it just reducing the odds of drifting the animation?

[boskid]

I cannot guarantee anything about animation alignment because crafting progress is stored as `double` while animation progress is stored as fixed point with a precision of 1/256th of animation frame progress. Reason why crafting is not measured in ticks is that we also have to account for various low energy situation where a machine is not working at full speed: in that case a recipe that usually takes 24 ticks may take for example 37 ticks just because of low energy state. In those cases the crafting progress will accumulate only its own rounding errors but the animation will accumulate additional errors caused by the rounding to a fixed point.

[jurgy]

I hadn't even considered low power state but after testing your workaround a bit, low power breaks it, unfortunately.

Do you reckon making an interface request for a flag to match the animation with crafting progress would have a shot at being implemented?