Closes https://github.com/ppy/osu/issues/33393.
This is admittedly a half-assed diff. This was apparently "fixed" once
before, eons ago, in https://github.com/ppy/osu/pull/11032, but I'm not
sure whether it regressed, or where, because I don't want to bisect four
years back. (At that time `ControlPointInfo.ControlPointsChanged`
did not exist yet.)
Also there's the part where changes to control points do not undo or
redo (see https://github.com/ppy/osu/issues/31942), but I'm not touching
that *either*, because if I start touching that, then I will get yelled
at for not reviewing the 2.5k line PR that rewrites the entirety of
change handling in editor instead
(https://github.com/ppy/osu/pull/30314). I will attempt to get through
that mental block sometime within the year. Please do not rush me.
The cheap cop-out argument is that hooking this up to `ControlPointInfo`
specifically is probably "more efficient" anyway.
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.
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.
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.
Closes https://github.com/ppy/osu/issues/31909.
Previously: https://github.com/ppy/osu/pull/30062.
Happening because of rounding errors - in this case the beat index
pre-flooring was something like a 0.003 off of a full beat, which would
get floored down rather than rounded up which created the discrepancy.
But also we don't want to round *too* far, which is why this
frankenstein solution has to exist I think. This is probably all
exacerbated by stable not handling decimal control point start times.
Would add tests if not for the fact that this is like extremely annoying
to test.
This was pointed out as an issue in the osu!taiko editor, but actually
affects all rulesets. Has now been fixed everywhere.
---
Closes https://github.com/ppy/osu/issues/31548.
osu!mania could arguable be consdiered "more correct" with the old
display, but I don't think it's a huge deal either way (subjective at
best).