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.
Apparently useful in modding workflows when you want to test out a few
different variants of a thing.
Re-uses `Ctrl-L` binding from stable. Some folks may argue that the
dialog makes the hotkey pointless, but I really do want to protect
users from accidental data loss, and also if you want to power through
it quickly, you can hit the 1 key when the dialog shows, which will
bypass the hold-to-activate period (which wasn't intentional, but so
many people want a bypass at this point that we're probably keeping that
behaviour for power users).
Requested too many times to count.
I'm not sure what to do about the code quality of this. It's a bit weird
that there's no way to check the current composition tool from a higher
level.
Also it was discussed IRL that there should be some kind of hinting that
existing notes will be deleted when they are hovered, but I'm not sure
how well this will work in normal mapping flows, since it will display
even in cases that users aren't intending to delete an object. Still
willing to explore this direction though (it's just non-trivial to
implement so I haven't yet).
Closes https://github.com/ppy/osu/issues/28791.
The reason why nudging was not changing hyperdash state in catch was
that `EditorBeatmap.Update()` was not being called on the objects that
were being modified, therefore postprocessing was not performed,
therefore hyperdash state was not being recomputed.
Looking at the usage sites of `EditorBeatmap.PerformOnSelection()`,
about two-thirds of callers called `Update()` themselves on the objects
they mutated, and the rest didn't. I'd say that's the failure of the
abstraction and it should be `PerformOnSelection()`'s responsibility to
call `Update()` there. Yes in some of the cases here this will cause
extraneous calls that weren't done before, but the method is already
heavily disclaimed as 'expensive', so I'd say usability should come
first.
Closes https://github.com/ppy/osu/issues/31915.
Reproduction of aforementioned issue requires 1280x720 resolution, which
should also be a good way to confirm that this does anything.
To me this is also equal-parts-bugfix, equal-parts-code-quality PR,
because tell me: what on earth was this code ever doing at
`ComposeBlueprintContainer` level? Nudging by one playfield-space-unit
doesn't even *make sense* in something like taiko or mania.