Related: https://github.com/ppy/osu/issues/30539
When starting up the game with a data location that points to an
unavailable external device, a new realm file is created in the default
location. Eventually a popup is shown that informs the user that the
external storage is unavailable, and the user has an option to try the
storage again. The button that invokes said option would check said
storage correctly, but would not do anything about realm, which means
the previously opened empty realm that is placed in the default location
would remain open, which means the retry essentially doesn't work
because the user's stuff isn't there after the retry.
To fix this, take out a `BlockAllOperations()`, which will flush all
open realms, and re-open the realm on the external location if the
custom storage restore succeeds.
This was another IRL request from a mapper / team member. The rationale
here is that it can be very annoying to map with break time enabled if
you have a large gap in the beatmap you are trying to fill with
hitobjects, as you are placing objects on top of a very gray area.
Random user feature request that made sense to me because the same thing
is in currently online display.
Yes web doesn't have this, but web is in a browser where you can Ctrl-F.
You can't do that in the client.
Design taken out of posterior because I can't be bothered waiting for
design cycles for this.
- Use better param name ("restoring" what bindings? the key information
there is that the *defaults* are being restored)
- Split ugly and not easily understandable (but probably
best-that-can-be-done) conditional out to a method and comment it
appropriately
This fell out while investigating why the issue with online IDs
mismatching in the `.osu` could be worked around by importing the map
three times in total when starting from it not being available locally.
Here follows an explanation of why that "helped".
Import 1:
- The beatmap set is imported normally.
- Online metadata population sees the online ID mismatch and resets it
on the problematic beatmap.
Import 2:
- The existing beatmap set is found, but deemed not reusable
because of the single beatmap having its ID reset to -1.
- The existing beatmap set is marked deleted, and all the IDs of
its beatmaps are reset to -1.
- The beatmap set is reimported afresh.
- Online metadata population still sees the online ID mismatch
and resets it on the problematic beatmap.
Note that at this point the first import *is still physically present
in the database* but marked deleted.
Import 3:
- When trying to find the existing beatmap set to see if it can be
reused, *the one pending deletion and with its IDs reset -
- the remnant from import 1 - is returned*.
- Because of this, `validateOnlineIds()` resets online IDs
*on the model representing the current reimport*.
- The beatmap set is reimported yet again.
- With the online ID reset, the online metadata population check for
online ID mismatch does not run because *the IDs were reset to -1*
earlier.
Preferring undeleted models when picking the model instance for reuse
prevents this scenario.
