Whomst've thought this was an ok thing to do? How did this pass review?
Let's leave these as rhetorical questions right now. Huge chances are
I'd implicate myself with at least one of them.
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.
Noticed in passing.
```
Exit code is 134 (Unhandled exception. System.NullReferenceException:
Object reference not set to an instance of an object.
at osu.Game.OsuGameBase.onExceptionThrown(Exception ex) in
/Users/dean/Projects/osu/osu.Game/OsuGameBase.cs:line 695
at osu.Framework.Platform.GameHost.abortExecutionFromException(Object
sender, Exception exception, Boolean isTerminating)
at osu.Framework.Platform.GameHost.unobservedExceptionHandler(Object
sender, UnobservedTaskExceptionEventArgs args)
at System.Threading.Tasks.TaskExceptionHolder.Finalize())
```
People were deleting files they shouldn't, causing osu! to lose track of
where the real user files are.
For now let's just keep things simple and not let the users know that
some files got left behind. Usually the files which are left behind are
minimal and it should be fine to leave this up to the user.
Closes https://github.com/ppy/osu/issues/29505.
This class was only used in two places, both on the results screen, but
was holding references to `OsuPlayfield` game-wide (due to unrelated
issues, but still).
Because I can't really think of future use cases for this, and running
the calculation twice at results screen isn't a huge overhead, let's
just do that for now to keep things simple.
This avoids it ever mutating the underlying track (aka attempting to start
it). Resolves the one caveat mentioned in
aeef92fa710648d4a00edc523e13c17ac6104125.
The new implementation of `DecouplingClock` will not mutate the
underlying clock in any way (unless attempting to start it when
approaching from a negative time value).
This should be quite safe as a result.
As described in #24248, the workaround employed by
`GlobalActionContainer`, wherein it tried to handle actions with
priority before its children by being placed in front of the children
and not _actually containing_ said children, is blocking the resolution
of some rather major input handling issues that allow key releases to be
received by deparented drawables.
To resolve, migrate `GlobalActionContainer` to use `Prioritised`, which
can be done without regressing certain mouse button flows after
ppy/osu-framework#5966.
