Fix mod score multiplier rounding to 1.00x with specific mod combinations

[CaffeeLake]

Fix mod score multiplier rounding to 1.00x with specific mod combinations.

Before

After

[bdach]

Classic mod multiplier: 0.96x
Double time 1.2x mod multiplier: 1.04x
Actual total multiplier before rounding: 0.9984x

I'm not sure this solution is correct to be honest. The combination of mods does decrease the score multiplier, even if by just a bit.

I'd take displaying 0.99x over this, and changing the logic to always round the textual displayed value away from 1.0x (so 1.0x is only displayed to the user if the multiplier is literally exactly 1.0x). @ppy/team-client opinions please.

This is also an issue on the mod screen by the way and this PR doesn't fix that part.

[bdach]

needs work as per above (at least to fix the mod select screen too).

[peppy]

I'd take displaying 0.99x over this

Yeah I'd imagine it always flooring to the lower rounded decimal.

[bdach]

So in short, I'd say:

• mod multipliers below 1.00x should be floored to the nearest decimal value to 2 significant digits
• mod multipliers above 1.00x should be.. ceilinged? to the nearest decimal value to 2 significant digits
• this should be extracted to a helper method, every place that displays the mod multiplier should use that helper method

Seems simpler than just handling the values around 1.00x in a special manner?

[CaffeeLake]

This is a little off topic, In the Mod Select overlay, lower multiplier are green and higher multiplier are red.
However, in the footer Mods, lower multiplier is red and higher multiplier is green.
Is this the intended specification?

[bdach]

This is a little off topic, In the Mod Select overlay, lower multiplier are green and higher multiplier are red. However, in the footer Mods, lower multiplier is red and higher multiplier is green. Is this the intended specification?

The footer will be fixed to match when the entirety of song select is redesigned. Please ignore for the time being.

[CaffeeLake]

Changed to display 0.99x or 1.01x when the value is close to 1.00x and is not an error (such as 0.9984x).

[frenzibyte]

I've refactored this PR to add a helper method as proposed above and used it, instead of sprinkling the same code everywhere. I've also made the helper method use mathematical formulas as proposed above as well.

[frenzibyte]

Will wait for @bdach for a second review on this.

[CaffeeLake]

With the current method, for example, if only HT (Speed: 0.70-0.79) is used, the correct multiplier is 0.30x, but it is displayed as 0.29x.
I think this requires logic to handle floating point errors.
Fixed.

[peppy]

With the current method, for example, if only HT (Speed: 0.70-0.79) is used, the correct multiplier is 0.30x, but it is displayed as 0.29x. I think this requires logic to handle floating point errors. Fixed.

Could you please add new tests to cover the failure scenario you fixed?

[CaffeeLake]

Could you please add new tests to cover the failure scenario you fixed?

Added tests to cover floating point errors .

[peppy]

@CaffeeLake for future reference, please don't merge master in multiple times. We'll do that when we're ready to handle your PR.