Closes https://github.com/ppy/osu/issues/25239.
`LegacyEditorBeatmapPatcher.processHitObjectLocalData()` was already
supposed to be handling changes to hitobjects that will show up neither
when comparing the hitobjects themselves or the timing point with
"legacy" info stripped - so, in other words, changes to slider velocity
and samples.
However, a change to slider velocity requires default application to
take effect, so just resetting the value would visually fix the timeline
marker but not change the actual object. Calling
`EditorBeatmap.Update()` fixes this by way of triggering default
re-application.
This could probably be smarter (by only invoking the update when
strictly necessary, etc.) - but I'm not sure it's worth the hassle. This
is intended to be a quick fix, rather than a complete solution - the
complete solution would indeed likely entail a wholesale restructuring
of the editor's change handling.
`SelectionHandler` is receiving input from anywhere out of necessity:
19f892687a/osu.Game/Screens/Edit/Compose/Components/SelectionHandler.cs (L119-L125)
Also important is that `BlueprintContainer` will selectively not block
right clicks to make sure they fall through to the
`ContextMenuContainer`:
19f892687a/osu.Game/Screens/Edit/Compose/Components/BlueprintContainer.cs (L122-L126)
But because the whole editor is sharing a `ContextMenuContainer` and
it's at a higher level than both components, we observe here the
playfield's `SelectionHandler` intercepting the right click before it
can reach the `ContextMenuContainer`.
The fix here is similar to what we're already doing in
`TimelineBlueprintContaienr`.
The import preparation task can actually be non-null when exiting even
if the player hasn't passed:
- fail beatmap
- click import button to import the failed replay
Closes https://github.com/ppy/osu/issues/25247.
The scenario involved here is as follows:
1. User completes beatmap by hitting all notes.
2. `checkScoreCompleted()` determines completion, and calls
`progressToResults(withDelay: true)`.
3. `progressToResults()` schedules `resultsDisplayDelegate`, which
includes a call to `prepareAndImportScoreAsync()`, a second in the
future.
4. User presses quick retry hotkey.
This calls `Player.Restart(quickRestart: true)`,
which invokes `Player.RestartRequested`,
which in turn calls `PlayerLoader.restartRequested(true)`,
which in turn causes `PlayerLoader` to make itself current,
which means that `Player.OnExiting()` will get called.
5. `Player.OnExiting()` sees that `prepareScoreForDisplayTask` is null
(because `prepareAndImportScoreAsync()` - which sets it -
is scheduled to happen in the future), and as such assumes that
the score did not complete. Thus, it marks the score as failed.
6. `Player.Restart()` after invoking `RestartRequested` calls
`PerformExit(false)`, which then will unconditionally call
`prepareAndImportScoreAsync()`. But the score has already been marked
as failed.
The flow above can be described as "convoluted", but I'm not sure I have
it in me right now to try and refactor it again. Therefore, to fix,
switch the `prepareScoreForDisplayTask` null check in
`Player.OnExiting()` to check `GameplayState.HasPassed` instead, as it
is not susceptible to the same out-of-order read issue.
- Closes https://github.com/ppy/osu/issues/25248
- Possibly also closes https://github.com/ppy/osu/issues/20475
Regressed in e33486a766.
`StopUsingBeatmapClock()` intends to, as the name says, stop operating
on the working beatmap clock to yield its usage to other components on
exit. As part of that it tries to unapply audio adjustments so that
other screens can apply theirs freely instead.
However, the aforementioned commit introduced a bug in this. Previously
to it, `track` was an alias for the `SourceClock`, which could be
mutated in an indirect way via `ChangeSource()` calls. The
aforementioned commit made `track` a `readonly` field, initialised in
constructor, which would _never_ change value. In particular, it would
_always_ be the beatmap track, which meant that
`StopUsingBeatmapClock()` would remove the adjustments from the beatmap
track, but then at the end of the method, _apply them onto that same
track again_.
This was only saved by the fact that clock adjustments are removed again
on disposal of the `MasterGameplayClockContainer()`. This - due to async
disposal pressure - could explain infrequently reported cases wherein
the track would just continue to speed up ad infinitum.
To fix, fully substitute the beatmap track for a virtual track at the
point of calling `StopUsingBeatmapClock()`.
