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*).
These aren't used in many places, but we've since moved away from
opacity in UI elements like this, so let's just nuke it here for
legibility.
Addresses https://github.com/ppy/osu/discussions/29906.
Closes https://github.com/ppy/osu/issues/29793.
I believe that the sequence of events that makes this happens is as
follows:
- User selects a range of objects. Some of those objects are off-screen,
and thus would be presumed to be not alive - except the blueprint
container forces them to remain alive, because they're part of the
selection.
- User moves the selection to another column, which is implemented by
temporarily removing the objects from the playfield, changing their
column, and re-adding them.
This sort of pattern is supposed to kick off the
`HitObjectUsageTransferred` flow in `HitObjectUsageEventBuffer` - and
it does... for objects that are *currently visible on screen* and thus
would be alive regardless of `SetKeepAlive()`. However, this does not
hold for objects that are off-screen - nothing ensures they are kept
alive again after re-adding, and thus they inadvertently become dead.
- Thus, this doesn't kick off the `BlueprintContainer` flows associated
with transferring objects to another column, and instead fires the
removal flows, which ensure that the off-screen objects that were
being moved are instead deselected.
I tried a few other options but found no better resolution than this -
calling `SetKeepAlive()` directly would require making it public, which
seems like a bad idea. There's really no good way to generically handle
this either, because it is the ruleset that decides that its way of
implementing this operation will be a removal and re-add of objects,
so...