Fixes the root client-side failure causing
https://github.com/ppy/osu/issues/30415.
Thread of breakage is as follows:
1. `SongSelect` loads the carousel.
At this point, the ruleset is what the ambient ruleset would have
been at the time of pushing song select, so most likely it will
match the current ruleset.
Notably, the carousel is loaded with `AllowSelection == false`.
2. `OnlinePlaySongSelect` sets the ruleset to the one taken from
the relevant playlist item in `LoadComplete()`.
3. At any point between the previous and the next step, the user
changes the ruleset manually.
4. `SongSelect.carouselBeatmapsLoaded()` is ran, which calls
`transferRulesetValue()`, which calls `FilterControl.FilterChanged`.
But at this stage `Carousel.AllowSelection` is still false, so
the filter is not executed, but `pendingFilterApplication` is set
instead.
Unfortunately, the pending filter never gets applied after that.
The only place that checks that flag is `OnEntering()`, which at
this point has already ran.
To fix, move the `pendingFilterApplication` check to `Update()`, which
seems like the most obvious and safe solution.
Closes https://github.com/ppy/osu/issues/30163.
If I'm to be blunt, the decoupled stuff in song select makes my head
spin. I spent a solid 20 minutes thinking how I was going to fix this
one but then finally realised that generally most of the cause there
was the fact that `AdvancedStats` was seeing the new rulesets *before*
the "ensure global selected mods are valid for current ruleset" logic,
and so decided to just _delay_ that until the decoupled transfer
thingamajig happens.
I was honestly considering combining `BeatmapInfo`, `Ruleset`, and
`Mods` into one property on `AdvancedStats`. I figured I'd rather not
push my luck and try the baseline version first, but I honestly think
that direction is going to be required at some point to properly corral
all of the decoupled madness taking place in song select.
These used to work because there was a huge blocking load operation,
which is now more asynchronous.
Note that the change made in `SongSelect` is not required, but defensive
(feels it should have been doing this the whole time).
The only exception to the rule here was "when screen isn't active apply
without debounce" but I'm not sure we want this. It would cause a
stutter on returning to song select and I'm not even sure this is a
common scenario.
I'd rather remove it and see if someone finds an actual case where this
is an issue.
This reverts a portion of https://github.com/ppy/osu/pull/9539.
The rearrangement in `SongSelect` is required to get the initial filter
into `BeatmapCarousel` (and avoid the `FilterChanged` event firing,
causing a delayed/scheduled filter application).
Closes https://github.com/ppy/osu/issues/21794.
I'm not actually super sure as to what the exact mode of failure is
here, but it's 99% to do with working beatmap cache invalidation. Likely
this can be even considered as another case of
https://github.com/ppy/osu/issues/21357, but because this is a one-liner
"fix," I'm PRing it anyways.
The issue is confusing to understand when working with the swap scenario
given in the issue, but it's a little easier to understand when
performing the following:
1. Have a beatmap set with 2 difficulties. Let's call them "A" and "B".
2. From song select, without ever exiting to main menu, edit "A". Change
the difficulty name to "AA". Save and exit back to song select; do
not exit out to main menu.
3. From song select, edit "B". Change the difficulty name to "BB". Save
and exit back to song select.
4. The difficulty names will be "A" and "BB".
Basically what I *think* is causing this, is the fact that even though
editor invalidates the working beatmap by refetching it afresh on exit,
song select is blissfully unaware of this, and continues working with
its own `BeatmapInfo` instances which have backlinks to
`BeatmapSetInfo`.
When editing the first of the two difficulties and then the second,
the editing of the first one only invalidates the first one rather than
the entire set, and the second difficulty continues to have a stale
reference to the first one via the beatmap set, and as such ends up
overwriting the changes from the first save when passed into the editor
and modified again.
It should not run in multiplayer. Even if we wanted to allow touch-only
playlist items at some point, the current behaviour of multiplayer song
selects with respect to touch device mod is currently just broken.
