What the actual heck is that magic number stupidity.
I'm not looking into why the test falls over so badly that it apparently
dies on some main menu logic just because assertions fail, because the
main menu logic is for hold-to-song-select-v2 and is thus temporary.
Rounding semi-regularly confuses users who aim for star rating pass / FC
medals and then feel they have been cheated out of a medal because they
passed an "X-star beatmap", but the actual star rating of the beatmap is
slightly under X.
The latest instance of this can be found at
https://osu.ppy.sh/community/forums/topics/2091333?n=2. The relevant
beatmap there is https://osu.ppy.sh/beatmapsets/2162554#osu/4746232,
whose raw star rating is 6.9976070253117344.
The other direction would be to fix the star rating medals instead, but
I think this is more reasonable given we already do similar things to
accuracy displays.
As proposed in https://github.com/ppy/osu/discussions/33572.
Note that this won't work if you leave to song select. We could make
that work but it would require further global faffing and I don't think
it's worth the effort.
Closes https://github.com/ppy/osu/issues/33393.
This is admittedly a half-assed diff. This was apparently "fixed" once
before, eons ago, in https://github.com/ppy/osu/pull/11032, but I'm not
sure whether it regressed, or where, because I don't want to bisect four
years back. (At that time `ControlPointInfo.ControlPointsChanged`
did not exist yet.)
Also there's the part where changes to control points do not undo or
redo (see https://github.com/ppy/osu/issues/31942), but I'm not touching
that *either*, because if I start touching that, then I will get yelled
at for not reviewing the 2.5k line PR that rewrites the entirety of
change handling in editor instead
(https://github.com/ppy/osu/pull/30314). I will attempt to get through
that mental block sometime within the year. Please do not rush me.
The cheap cop-out argument is that hooking this up to `ControlPointInfo`
specifically is probably "more efficient" anyway.
This is a very dodgy fix, but it fixes an edge case that has so far - to
my knowledge - not been reported by users in the wild, only by me trying
to break things, so my hope is that we can do this and move on for now.
User feedback is that it's no longer possible to see the applied rate
adjust change when it's non-default without hovering. This fixes that
issue.
I've adjusted the visuals a bit so you can still get a hint at which
mods are displayed, even when they are overflowing.