Co-authored-by: Zyf <zyfarok@gmail.com>
Closes https://github.com/ppy/osu/issues/25860
Users reported that some stable scores would convert to large negative
total scores in lazer after the introduction of combo exponent. Those
large negative total scores were actually mangled NaNs.
The root cause of this was the following calculation going below zero
unexpectedly:
8e8d9b2cd9/osu.Game/Database/StandardisedScoreMigrationTools.cs (L323)
which then propagates negative numbers onward until
8e8d9b2cd9/osu.Game/Database/StandardisedScoreMigrationTools.cs (L337)
which yields a NaN due to attempting to take the square root of a
negative number.
To fix, clamp `comboPortionInScoreV1` to sane limits: to
`comboPortionFromLongestComboInScoreV1` from below, and to
`maximumAchievableComboPortionInScoreV1` from above. This is a less
direct fix than perhaps imagined, but it seems like a better one as it
will also affect the calculation of both the lower and the upper
estimate of the score.
Causes several knock-on inspections in `OsuGame` et al. Probably best
addressed in a separate pass, because treatment is mixed at best (some
places nullcheck, some expect non-null).
As it turns out, on some cultures, the "negative integer" sign is not
encoded using the U+002D HYPHEN-MINUS codepoint. For instance, Swedish
uses U+2212 MINUS SIGN instead. This was confusing the legacy decoder,
since it is correctly depending on the serialisation being
culture-independent.
To fix, ensure that the special "end replay" frame, as well as the
replay MD5 hash, are generated in a culture-invariant manner.
Thankfully the replay MD5 hash is currently being discarded in
`LegacyScoreDecoder`, so it changing in future scores should not have
any negative effect on lazer operation.
