Closes https://github.com/ppy/osu/issues/32420.
The failure cause here is that in editor the beatmap version for the
beatmap affected (or... any beatmap, really), is 0 (ZERO). That is
probably a regression from https://github.com/ppy/osu/pull/32315, but
like... can we universally agree that calling that change "a regression"
in any capacity is dumb? Like what was that code *doing* playing dumb
reference games and copying stuff into an arbitrary instance that could
get or not get used later on? And now you have a 50/50 chance of
accessing the *correct* model's field, depending on whether you go via
`BeatmapInfo` or `Beatmap.BeatmapInfo`?
Moving the field to `IBeatmap`, i.e. what is by now - by consensus,
since https://github.com/ppy/osu/pull/28473 - supposed to be the "decoded
and materialised" beatmap, fixes this issue.
I probably should have done this as part of
https://github.com/ppy/osu/pull/28473 but it slipped my mind. Probably
for the better too because this change has rather large chances of
breaking stuff so maybe better to examine it in isolation (via diffcalc
runs or whatever).
For added humour points, you'd say that the field on `BeatmapInfo` was
not `[Ignore]`d, so this is a realm schema change, right? No. As far as
I can tell, it's not. I opened realm studio and `BeatmapVersion` *is not
a listed column` on `Beatmap` models.
I'm also not gonna get into the fact that I think `EditorBeatmap` doing
dumb games with juggling two `BeatmapInfo` references since
https://github.com/ppy/osu/pull/15075 is bad, because I don't think I
have the mental capacity to hotfix this by going down that train of
thought.
This was reported internally in
https://discord.com/channels/90072389919997952/1259818301517725707/1343470899357024286.
The issue described was that sample specifications on control points in
stable disappeared after the beatmap was updated from lazer.
The reason why the sample specifications were getting dropped is that
they got lost in the logic that attempts to translate per-hitobject
samples that lazer has back into stable "green line" type control
points. That process only attempted to preserve volume and custom sample
bank, but did not keep the standard bank - likely because it's kind of
superfluous information *for correct sample playback of the objects*, as
the samples get encoded again for each object individually. However
dropping this information makes for a subpar editing experience.
The choice of which sample to pick the bank from is sort of arbitrary
and I'm not sure if there's a correct one to pick. Intuitively picking
the normal sample's bank (if there is one) seems most correct.
The logic in `LegacyBeatmapEncoder` that was supposed to handle
the lazer-exclusive feature of supporting multiple slider segment types
in a single slider was interfering rather badly with the Bezier
converter. Generally it was a bit difficult to follow, too.
The nice thing about `BezierConverter` is that it is *guaranteed* to
only output Bezier control points. In light of this, the same double-up-
-the-control-point logic that was supposed to make multiple slider
segment types backwards-compatible with stable can be placed in
the Bezier conversion logic, and be *much* more understandable, too.
Addresses one of the points in https://github.com/ppy/osu/issues/31496.
Not going to lie, this is mostly best-effort stuff (while the refetch is
happening, metadata lookups using the local source *will* fail), but I
see this as a marginal scenario anyways.
Reported at https://osu.ppy.sh/community/forums/topics/2015478?n=1.
Would you believe it that this button that has been there for literal
years never did anything?
Implemented at a per-beatmap level. Also additionally added to context
menu (at @peppy's suggestion), and also copy reworded from "Delete from
unplayed" to "Mark as played" because double negation hurt my tiny
brain.