This commit changes BeatmapCarouselFilterGrouping to now use floored star
rating when determining which group a beatmap belongs to,
to be consistent with changes introduced here:
https://github.com/ppy/osu/pull/33679.
The AdvancedStats section of the original song select is also
updated to show the floored star rating (rather than rounded).
Closes https://github.com/ppy/osu/issues/33542.
For a diff this simple this took much more hemming and hawing because
things are a bit annoying here from a few angles:
- The only way that is considered idiomatic right now for a skin
component to not be applicable to a screen is to require a dependency
from DI that is only provided by applicable screens.
`DrawableGameplayLeaderboard` has a few of those dependencies, but the
scope of all the usages makes it so that the only really viable one to
use here is `IGameplayLeaderboardProvider` itself (see: visual tests,
and also the usage of multiplayer spectator, where the leaderboard is
*not* under a player instance).
- The smelly part of this is that the `Player` inheritance hierarchy
must ensure that *every* non-abstract class has an
`IGameplayLeaderboardProvider` cached. It is not trivial - if not
straight up impossible - to force this via some `Player` level
abstract method, because such a method would need to somehow
accommodate all possible leaderboard providers. That however also
means that every possible future `Player` implementor *must inherently
know* to also cache a leaderboard provider lest it die at runtime. I
don't love that, but I also don't see better alternatives.
- Speaking of which, I also noticed that solo spectator and playlists
don't have gameplay leaderboards. At all. Which I don't believe to be
something that I broke with the leaderboard work - I'm pretty sure
that was the pre-existing state - however I don't see any reason why
they *couldn't* receive gameplay leaderboards. I'm not doing that
here, though, just leaving TODOs for later.
Closes https://github.com/ppy/osu/issues/33455.
The fundamental misunderstanding and source of confusion in
https://github.com/ppy/osu/pull/33062 is that solo wants to show
*maximum combo*, and multiplayer wants to show *current combo*, for
their own, valid reasons. Which is spelled out explicitly in this
change.
For easier understanding, substitute "non-user-playable" with
"autoplay".
The reason that I'm bothering to do this is that if you put autoplay on
and turn on the "Selected Mods" filter, the request will actually go
through and hit web, and web will obviously return no scores. On song
select that's *maybe* fine, even though probably unintended still, but
now with the leaderboard state being global this also means gameplay
gets impacted. Which also means that if you Ctrl-Enter to start a map in
autoplay you're not going to get any gameplay leaderboard scores at all.
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.
Saves having this defined in 20+ places. If we ever make any changes to
shear, it's 100% going to need to be applied to every usage (there will
never be a case of multiple different shears in the game).
Also fixes a mismatching definition in `ShearedNub`.