While I can't reproduce any test failures because of this, I can
reproduce exceptions by simply running the tests with debugger attached.
There's one other similar related test failure in `TestSingleAudioFile`
but that appears to be an o!f issue.
I'm not entirely sure how this works, but CI was testing against the
updated Velopack package, whereas my local package was outdated and had
4 args.
Previous commit merges master to update the package version, this commit
fixes the args.
This is not doing the thing that the website does wherein the entire
user profile is replaced by the message that the user is blocked if
they're blocked. Someone else can try doing that.
I'm also not adding report button to this because it's going to be
annoying to make happen because currently reporting is only available as
a popover and not as a dialog. Someone else can pick that up as well.
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.
Closes https://github.com/ppy/osu/issues/24285.
This is not a perfect solution, as it is still possible for a replay to
play *beyond* its end if the HP system doesn't fail it after it runs out
of frames, but it's probably the best that can be done at this time.
Notably this removes existing F rank checks because they were really not
reliable.
- Scores coming from stable will never present F rank, because rank is
not stored to the replay, and the lowest rank that can be produced by
`StandardisedScoreMigrationTools` is D.
- lazer scores set prior to https://github.com/ppy/osu/pull/28058 will
present F rank as long as the user has kept them in their local
database and never exported and reimported them, for the same reason
as above (rank not stored to replay). Also there have been many
mechanics changes since, so it's not impossible for the replay to fail
*before* the user actually did even in this case.
- lazer scores set after https://github.com/ppy/osu/pull/28058 could
technically rely on F rank but making them rely on it is annoying for
several reasons:
- The PR in question didn't bump `LegacyScoreEncoder.LATEST_VERSION`,
so any checks based on the replay version field would be
half-reliable anyway.
- *Even after* the above, the replay version is only stored to realm
as `TotalScoreVersion`, which *then gets bumped* on score version
upgrades. So it can't even be used for any checks from that angle,
you'd have to decode it from the score.
- You *could* use `ClientVersion` because that's somewhat reliable,
but that's stored *as string*, so you'd have to do some snipping to
split off the `-lazer` suffix, then parse the version, then compare
it. I started going through the motions of that before deciding that
this is an edge case of an edge case and probably not worth spending
time over the simple and obvious solution of just doing away with
the rank check. Until I'm proven wrong, I guess.
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.