Was added in cc76c58f5f without any
specific reasoning. Likely not required (and will fix some storyboard
elements inside `.osu` files from not being correctly saved).
After way too much time investigating this, the encoding situation is
not great right now.
- Stable sets the "default code page" to be used for encoding filenames
to Shift-JIS (932):
c29ebd7fc5/osu!/GameBase.cs#L3099
- Lazer does nothing (therefore using UTF-8).
When importing to lazer, stable files are assumed to be UTF-8. This
means that the linked beatmaps don't work correctly. Forcing lazer to
decompress *and* compress using Shift-JIS will fix this.
Here's a rough idea of how things look for japanese character filenames
in current `master`:
| | stable | lazer |
|--------|--------|--------|
| export encoding | shift-jis | utf8 |
| utf8 [bit flag](https://superuser.com/a/1507988) set | ❌ | ❌ |
| import stable export osz | ✅ | ❌ |
| import lazer export osz | ❌ | ✅ |
| windows unzip | ❌ | ❌ |
| macos unzip | ✅ | ✅ |
and after this change
| | stable | lazer |
|--------|--------|--------|
| export encoding | shift-jis | shift-jis |
| utf8 [bit flag](https://superuser.com/a/1507988) set | ❌ | ❌ |
| import stable export osz | ✅ | ✅ |
| import lazer export osz | ✅ | ✅ |
| windows unzip | ❌ | ❌ |
| macos unzip | ✅ | ✅ |
A future endeavour to improve compatibility would be to look at setting
the utf8 flag in lazer, switching the default to utf8, and ensuring the
stable supports this flag (I don't believe it does right now).
Rather than creating a "corrupt" realm file in such cases, the game will
now refuse to start. This behaviour is usually what we want. In most
cases a second click on the game will start it successfully (the
previous instance's file handles are still doing stuff, or windows
defender is being silly).
Closes https://github.com/ppy/osu/issues/28018.
Closes https://github.com/ppy/osu/issues/21794.
I'm not actually super sure as to what the exact mode of failure is
here, but it's 99% to do with working beatmap cache invalidation. Likely
this can be even considered as another case of
https://github.com/ppy/osu/issues/21357, but because this is a one-liner
"fix," I'm PRing it anyways.
The issue is confusing to understand when working with the swap scenario
given in the issue, but it's a little easier to understand when
performing the following:
1. Have a beatmap set with 2 difficulties. Let's call them "A" and "B".
2. From song select, without ever exiting to main menu, edit "A". Change
the difficulty name to "AA". Save and exit back to song select; do
not exit out to main menu.
3. From song select, edit "B". Change the difficulty name to "BB". Save
and exit back to song select.
4. The difficulty names will be "A" and "BB".
Basically what I *think* is causing this, is the fact that even though
editor invalidates the working beatmap by refetching it afresh on exit,
song select is blissfully unaware of this, and continues working with
its own `BeatmapInfo` instances which have backlinks to
`BeatmapSetInfo`.
When editing the first of the two difficulties and then the second,
the editing of the first one only invalidates the first one rather than
the entire set, and the second difficulty continues to have a stale
reference to the first one via the beatmap set, and as such ends up
overwriting the changes from the first save when passed into the editor
and modified again.
Closes https://github.com/ppy/osu/issues/22783.
If the difficulty being edited has unsaved changes, the editor exit flow
would prompt for save *after* the deletion method has run. This is
undesirable from a UX standpoint, and also leaves the user in a broken
state.
Thus, just fake an update of the last saved hash of the beatmap to fool
the editor into thinking that it's not dirty, so that the exit flow will
not show a save dialog.
Closes https://github.com/ppy/osu/issues/24274.
Bit of an ad-hoc resolution but maybe fine? This basically proposes to
bypass the problem described in the issue by just not showing tick hits
at all on the distribution graph.
RFC. Closes https://github.com/ppy/osu/issues/27883.
The idea here is that `PopOut()` is called _when the hide is requested_,
so once an overlay trigger would hide, the overlay would
`StopAnyPlaying()`, but because of async load things, the actual track
would start playing after that but before the overlay has fully hidden.
(That last part is significant because after the overlay has fully
hidden, schedules save the day.)
Due to the loose coupling between `PreviewTrackManager` and
`IPreviewTrackOwner` there's really no easy way to handle this locally
to the usages of the preview tracks. Heck, `PreviewTrackManager` doesn't
really know which preview track owner is to be considered _present_ at
any time, it just kinda works on vibes based on DI until the owner tells
all of its preview tracks to stop.
This solution causes the preview tracks to stop a little bit later but
maybe that's fine? Just trying to not overthink the issue is all.
No tests because this is going to suck to test automatically while it is
pretty easy to test manually (got it in a few tries on master).
The issue also mentions that the track can sometimes resume playing
after the overlay is pulled up again, but I don't see that as a problem
necessarily, and even if it was, it's not going to be that easy to
address due to the aforementioned loose coupling - to fix that, play
buttons would have to know who is the current preview track owner and
cancel schedules upon determining that their preview track owner has
gone away.
Closes https://github.com/ppy/osu/issues/25633.
The reason why that particular beatmap did not have a double skip
on stable is here:
e53980dd76/osu!/GameModes/Play/Player.cs#L1761-L1770
The particular place of interest is the `leadInTime < 10000` check.
If `leadInTime < 10000`, then `leadIn == leadInTime`, and it turns out
that `AudioEngine.Time` will always be more than or equal to `leadIn`,
because it's also the gameplay start time:
e53980dd76/osu!/GameModes/Play/Player.cs#L2765
This essentially means that if the `leadInTime` is less than 10000,
that particular check is just dead. So a double skip can only occur
if the gameplay starts at time -10000 or earlier due to the storyboard.
In the Mod selection area, the search bar's focus could be changed by pressing TAB.
However, when clicking outside of the search bar, the focus would be killed but two TABs were required to get the focus back on the search bar.
This happened because the action of clicking in an empty area would trigger the search bar to change its appearence, but not its internal state.
In my solution, I made the OnClick function aware of the search bar's state, so it would not only change its appearance, but also its state.
Now, after clicking in an empty area, there is only needed one TAB to select the search box again, as expected.
