See https://github.com/ppy/osu/pull/30215#issuecomment-2407775408 for
context.
Turns out the test failures were more correct than I'd thought. The
long-and-short of it is that both in "pure random" mode and in
"permutation" mode, when running out of track history to fall
back on, it was possible for the random algorithm to pick the same song
twice in a row - which is probably not desired, and which this explicit
exclude should make impossible.
I'm not sure why this was "fine" for as long as it apparently was,
but what `MusicController` was doing was completely incorrect and
playing with fire (accessing raw managed realm objects), which went
wrong somewhere around - admittedly -
https://github.com/ppy/osu/pull/29917, likely because that one started
*storing* these raw managed realm objects to fields, and you know what
will happen to those after you do a migration and recycle realms.
To attempt to circumvent this, (ab)use `DetachedBeatmapStore` instead.
Which does necessitate moving it to `OsuGameBase`, but it's the simplest
way out I can see. I guess the alternative would be to faff around with
`Live<T>` but it's ugly and I'm attempting to fix this relatively quick
right now.
`SkipWhile()` in this context does not correctly ensure that
`ElementAtOrDefault(1)` is not a protected track. An explicit `Where()`
does.
Spotted accidentally when I noticed that skipping to next track can
select a protected track, but skipping to previous cannot.
RFC. Closes https://github.com/ppy/osu/issues/18169.
Implements the given proposal of keeping the current stable order but
adding a shuffle facility to the now playing overlay, and enabling it by
default.
There are more changes I want to make here but I'd like this to get
discussion first, because I am likely to continue putting this sort of
selection logic into `MusicController` and I just want to confirm nobody
is going to have a problem with that.
In particular this is not sharing the randomisation implementation with
beatmap carousel because it doesn't generalise nicely (song select cares
about the particular *beatmap difficulties* selected to rewind properly,
while the music controller only cares about picking a *beatmap set*).
In testing I can't find a reason for this to exist. Blaming back shows
that it existed before we had `AllowTrackControl` and was likely being
used as a stop-gap measure to achieve the same thing. It's existed since
over 6 years ago.
Let's give removing it a try to fix some usability concerns?
Closes https://github.com/ppy/osu/issues/29563.
This changes the editor to track the current track as it is *loaded* by
`MusicController`, rather than haphazardly following the current global
`WorkingBeatmap` (with a potentially unloaded track) or relying on local
immediate-load behaviour (as implemented in `ResourcesSection`).
This avoids any blocking overhead caused by a backlogged audio thread.
Test seem to pass so might be okay?
Note that order is still guaranteed due to the `ensureUpdateThread`
queueing system framework-side.
Isolates `CurrentTrack` from being directly adjusted by the mod, which could lead to issues depending on how the mod adds adjustments (i.e. `ModTimeRamp`, which adds adjustments based on changes to a setting bindable).
