Page 1 of 1

[2.0.77] Quality rounding math results in inaccurate values

Posted: Fri Jun 19, 2026 10:10 am
by dupraz
The default behavior of quality is to floor the values resulting from the relevant factor (1 + quality_n * 0.3), which makes sense for discrete values like inventory size, but otherwise results in meaningless discrepancies from the theoretical result, for example when using quality modules themselves:
  • Quality 1 (0.3% step): 1% -> 1.3% -> 1.6% -> 1.9% -> 2.5%
  • Quality 2 (0.6% step): 2% -> 2.6% -> 3.2% -> 3.8% -> 5%
  • Quality 3 (0.75% step): 2.5% -> 3.25% -> 4% -> 4.75% -> 6.25%
In practice Quality 3 is floored to the nearest 0.1%, which makes the progress irregular and even the final value inaccurate. For example you could expect Quality to top-out with 4 slots at 4*2.5*2.5=25% as in a clean 1/4, but in practice this ends-up being 4*6.2=24.8% for no apparent reason.

factorio_1781863134.png
factorio_1781863134.png (448.66 KiB) Viewed 290 times
This behavior is hard-coded into the engine and cannot be modified whatsoever using the API, which makes no meaningful distinction between value types. Here flooring to 0.01% would fix the issue, even as it's not actually needed, because 3/10 is an integer division (rather than say 1/3), you cannot end-up with non-rational values, so floating points are not necessary either way.

The fix is simple, don't floor value types that are not strictly integers (or at least make the rounding resolution meaningful depending on the type).

Re: [2.0.77] Quality rounding math results in inaccurate values

Posted: Fri Jun 19, 2026 10:19 am
by dupraz
Here for example using Speed modules instead, you can see how this behavior is inconsistent, with the speed property being calculated at a much higher resolution (only the estimated preview is rounded).

factorio_1781864160.png
factorio_1781864160.png (399.28 KiB) Viewed 276 times

Re: [2.0.77] Quality rounding math results in inaccurate values

Posted: Fri Jun 19, 2026 10:20 am
by boskid
As for 2.0 this is not a bug because quality effects are still integers under the hood, they are just divided by 10 for display purposes which is why there is only 1 decimal digit of precision. As for 2.1 there will be changes due to 125320.

I will close this as Not a bug as this behavior matches 2.0 design decisions.

Re: [2.0.77] Quality rounding math results in inaccurate values

Posted: Fri Jun 19, 2026 10:27 am
by dupraz
boskid wrote: Fri Jun 19, 2026 10:20 am As for 2.1 there will be changes due to 125320.
Does that mean that for 2.1, Tier-5 Quality-3 modules will be allowed to be 6.25% as expected (using floating point or otherwise)?

Re: [2.0.77] Quality rounding math results in inaccurate values

Posted: Fri Jun 19, 2026 10:37 am
by boskid
That means you will have to wait for 2.1 experimental release to know how it was resolved.