Rank animation is played for new panels when scrolling down, showing the
previous rank belonging to the previous beatmap assigned to that
specific panel instance.
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.
The rationale for this change is that the return value was mostly
useless, and at worst, misleading.
When using `LeaderboardManager`, it's assumed that a consumer will bind
to the global `Scores` list to ensure they receive updates for things
like local score changes via the internal realm subscription. If one
decides to instead use the return value of the task, it will be a static
snapshot that potentially becomes stale in the future.
I fell into this trap when refactoring the new leaderboard component
(while attempting to assert correctness that the values we are
displaying were in fact from the fetch operation we requested).
In the interest of keeping things simple, removing the return value
seems to be the best path forward.
Kind of a big oversight this. In wanting to get the leaderboard
refactors to move forward I sort of didn't realise the fact that all of
the error handling related to online status and such in
`BeatmapLeaderboard` kind of... can't stay there...
It's also an all-or-nothing business too - moving this stuff can't
really be done only in part.
Not sure whether tests are warranted if it's more or less moving logic
across?
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.
With `ReplayPlayer` now consuming the `LeaderboardManager`'s global
state, flows such as presenting a score need to set the global state up
correctly to avoid accidentally showing a leaderboard from a completely
different score.
This also incidentally closes https://github.com/ppy/osu/issues/27609.
RFC. Another attempt at this.
- Supersedes https://github.com/ppy/osu/pull/31881
- Supersedes / closes https://github.com/ppy/osu/pull/31355
- Closes https://github.com/ppy/osu/issues/29861
This is a weird diff because I am feeling rather boxed in by all the
constraints, namely that:
- Leaderboard state should be global state
- But the global state is essentially managed by song select and namely
`BeatmapLeaderboard` itself. That's because trying to e.g. not have
`BeatmapLeaderboard` pass the beatmap and the ruleset to the global
leaderboard manager is worse, as it essentially introduces two
parallel paths of execution that need to be somehow merged into one
(as in I'd have to somehow sync `LeaderboardManager` responding to
beatmap/ruleset changes with `BeatmapLeaderboard` which is inheritance
hell)
- Also local leaderboard fetching is data-push (as in the scores can
change under the leaderboard manager), and online leaderboard fetching
is data-pull (as in the scores do not change unless the leaderboard
manager does something). Also online leaderboard fetching can fail.
Which is why I need to still have the weird setup wherein there's a
`FetchWithCriteriaAsync()` (because I need to be able to respond to
online requests taking time, or failing), but also the
`BeatmapLeaderboard` only uses the public `Scores` bindable to
actually read the scores (because it needs to respond to new local
scores arriving).
- Another thing to think about here is what happens when a retrieval
fails because e.g. the user requested friend leaderboards without
having supporter. With how this diff is written, that special
condition is handled to `BeatmapLeaderboard`, and
`LeaderboardManager`'s state will remain as whatever it was before
that scope change was requested, which may be considered good or it
may not (I imagine it's better to show scores in gameplay than not in
this case, but maybe I'm wrong?)
This design is about to get replaced, so I'm just making some minor
adjustments since a lot of people complained about the font size in the
last update.
Of note, I'm only changing the font size which is one pt size lower than
we'd usually use. Also overlapping the mod icons to create a bit more
space (since there's already cases where they don't fit).
Closes https://github.com/ppy/osu/issues/32055 as far as I'm concerned.
I can read everything fine at 0.8x UI scale.