[2.0.77] Quality rounding math results in inaccurate values
Posted: Fri Jun 19, 2026 10:10 am
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:
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).
- 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%
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).