Every now and again someone will report having done something horrible
to their beatmap via lazer submission, always claim having done
"nothing" while invariably having done *something*, will not provide me
with a workable reproduction scenario, and even if they attempt to do
so, I will be unable to reproduce the issue anyway. So this change is
just desperation mostly. It's logging pretty much all that it is
possible to log of client-side state.
Closes https://github.com/ppy/osu/issues/33231.
I'm not sure how to reproduce the instances of this reported to sentry
with `Drawable{Slider,Spinner}`, but this bug is about to be made worse
by `DrawableHoldNote` in mania getting its own `JudgementResult` subtype
in https://github.com/ppy/osu/pull/33194 - for that one to reproduce
just start gameplay test while editor is seeked to a time instant where
a hold note is mid-hold.
There's possibly an argument here that `CreateResult()` should live on
`HitObject` and not `DrawableHitObject`, and I'd even be partial to such
an argument, but doing that would be a rather hard ruleset API break
(albeit trivial one to resolve), and also may dredge up past
conversations about `Judgement` and `JudgementResult` (cf.
https://github.com/ppy/osu/pull/26563) that I would rather not get into
again.
Notably this is not source-breaking for rulesets. It may be
binary-breaking, I haven't tested.
Probably closes https://github.com/ppy/osu/issues/33230.
I say "probably" because I couldn't reproduce this myself using the
scenario provided in the issue but looking at the code involved I can
see why it would happen. Long and short of it is that the speed
adjustment cleanup code was much too reliant on disposal executing
quickly, which as we've learned on several occasions before, cannot be
relied upon.
The normalization formula didn't handle the 180° boundary consistently,
and produced asymmetric results for top vs. bottom rotation points.
Changes made: replaced the angle normalization with symmetric normalization,
and forced 180º to be the displayed angle across all rotation points.
Should be self-explanatory (feedback loop between `reloadMetadata()`
changing text box current, and text box current changing calling
`applyMetadata()`).
I was testing with mp3s ripped via Apple Music and for whatever reason
the artist was in `JoinedPerformers` rather than `JoinedAlbumArtist`.
I'm not about to go down and do research on id3 so I'm just going to try
this and see if anyone complains.
I'm not sure why this condition was written this obtusely, but
importantly it was also wrong. It fires when the selection contains
multiple items and only some are removed from it, like when
ctrl-click-unselecting an item from a multiple selection.
Closes https://github.com/ppy/osu/issues/32825.
Tested manually to fix the issue. Setting up test coverage for this is
going to likely take over an hour compared to the 30 second fix, so
please advise if required. I couldn't find any existing tests which
perform this flow.
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.