It's no longer possible to just assume that using the ambient
`WorkingBeatmap` is gonna work.
Bit dodgy but seems to work and also I'd hope that `WorkingBeatmapCache`
makes this not overly taxing. If there are concerns this can probably be
an async load or something.
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.
The previous logic was very wrong, as the check would only occur on each
beat. But that's not how kiai sections work – they can be placed at any
timestamp, even if that doesn't align with a beat.
In addition, the rate limiting has been removed because it didn't exist
on stable and causes some fountains to be missed. Overlap scenarios are
already handled internally by the `StarFountain` class.
Closes https://github.com/ppy/osu/issues/31855.
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.
Mostly trying to give more space to the queue as we add more vertical
elements to the middle area of multiplayer / playerlists. This whole UI
will likely change – this is just a stop-gap fix.
