This fell out of my work on hit window-related replay issues. In my WIP
branch (that is probably going to get PR'd as draft soon) I refactored
`HitWindows` and found a few straggling test failures due to some places
reading hit windows for results that were not actually supported by the
underlying `HitWindows` implementations, leading to returning garbage
(mostly zeroes).
Importantly, there is one actual usage in game code with impact here -
`TaikoModSingleTap` was attempting to read the hit window for MEH, when
MEH was never actually a valid hit result in taiko (OK is). This was a
result of a copy-paste oversight from osu!, specifically from
https://github.com/ppy/osu/blob/51cf835fb6300aca53b5b98143d606f64d7a4d49/osu.Game.Rulesets.Osu/Mods/InputBlockingMod.cs#L58
I'd have preferred a `get; init;` property but tests were also attached
at the hip to the public bindable. Without some extra composition this
is the best that I can do.
The sorting logic is now exercised in
`TestSceneSoloGameplayLeaderboardProvider`. Trying to work around
it with local test classes would mean that the test would be covering
test code, i.e. complete nonsense and having a green test for the sake
of having a green test.
Intends to close https://github.com/ppy/osu/issues/32859.
The difference between this and https://github.com/ppy/osu/pull/32942 is
that this PR takes the approach of completely moving the score sorting
behaviour to `IGameplayLeaderboardProvider` implementations.
This is going to be helpful for further work - to be precise, I am
looking to add a leaderboard position indicator in the bottom right of
multiplayer player to match stable, and having the position in the
provider will make the implementation of that *much* easier.
This PR converts the leaderboard into a full-fledged skinnable component
that can be manipulated by users at will.
Notably, this finally allows https://github.com/ppy/osu/issues/20422 to
be fixed - although it's a very mixed bag, for several reasons:
- Because of taiko players' refusal to see reason^W^W^W^Winsistence on
keeping stable behaviours related to aspect ratio treatment, I have to
assume the worst case scenario, which means than on typical
resolutions like 16:9 (or even worse, 4:3), the leaderboard will
likely not occupy as much vertical space as it probably could.
- Additionally, there's the problem of where to put the spectator list.
I settled on putting it to the right of the leaderboard, but that's
kind of janky, because the leaderboard sometimes collapses and
sometimes fully hides, leading to a very awkward space left behind. If
we had the capability to anchor elements to other elements, maybe this
could be resolved, but for now, I'm not sure what to do. I think if
some users are bothered by it they can move it where they want it. Or
delete it.
As time goes on, default skin layouts are getting more and more
complicated because of per-ruleset overrides. This was already sort of
apparent in https://github.com/ppy/osu/pull/31527, and I'm about to make
it worse, so before I do, this is a test scene that is supposed to make
it easier to check all possible combinations at a glance.
This is a prerequisite for supporting skinning of leaderboards.
- New `IGameplayLeaderboardProvider` and `IGameplayLeaderboardScore`
interfaces are introduced. They are strictly concerned with supplying
leaderboard data.
- Logic of managing display, which was previously jammed into the
inheritance hierarchy of `GameplayLeaderboard`, is now moved into
`IGameplayLeaderboardProvider` implementations. Solo play,
multiplayer, and multiplayer spectator get their own implementation of
the interface.
- The inheritance hierarchy of `GameplayLeaderboard` and per-player
overriding of the implementation of the gameplay leaderboard is gone.
Only one drawable class (renamed to `DrawableGameplayLeaderboard`) is
allowed to display the leaderboards, across all modes of play.
It's all a bit weird so let's just disable it for now. For instance,
this is exposed as "text" font / colour but only affects the header.
Also, no other headers are cusotmisable in similar components.