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).
Closes https://github.com/ppy/osu/issues/25608.
Logic mostly matching stable. All operations are done on `ComboOffset`
which still makes overridden combo colours weirdly relatively dependent
on each other rather than them be an "absolute" choice, but alas...
As per stable, two consecutive new combos can use the same colour only
if they are separated by a break:
52f3f75ed7/osu!/GameModes/Edit/Modes/EditorModeCompose.cs#L4564-L4571
This control is only available once the user has changed the combo
colours from defaults; additionally, only a single new combo object
must be selected for the colour selector to show up.
As I look into re-implementing the ability to choose combo colour for an
object (also known as "colourhax") from the editor UI, I stumble upon
these wretched ternary items again and sigh a deep sigh of annoyance.
The structure is overly rigid. `TernaryItem` does nothing that
`DrawableTernaryItem` couldn't, except make it more annoying to add
specific sub-variants of `DrawableTernaryItem` that could do more
things.
Yes you could sprinkle more levels of virtuals to
`CreateDrawableButton()` or something, but after all, as Saint Exupéry
says, "perfection is finally attained not when there is no longer
anything to add, but when there is no longer anything to take away."
So I'm leaning for taking one step towards perfection.
Would close https://github.com/ppy/osu/issues/31312.
Not super happy with the performance overhead of this, but this is
already a heuristic-based implementation to avoid every-frame
`.ChildrenOfType<>()` calls or similar, so not super sure how to do
better. The `Array.Contains()` check stands out in profiling, but
without it the indicators can collapse *too* eagerly sometimes.
This was causing state pollution in the new selection. I can't see why
this needs to happen when a selection changes to another.
This fixes https://github.com/ppy/osu/issues/30839 and also the same
issue happening for the new combo toggle.
Tests all seem to pass, and I can't immediately find anything broken,
but YMMV.
This was another IRL request from a mapper / team member. The rationale
here is that it can be very annoying to map with break time enabled if
you have a large gap in the beatmap you are trying to fill with
hitobjects, as you are placing objects on top of a very gray area.
More specifically, this fixes placement blueprints not beginning placement when using touch input while the cursor was previously outside compose area, due to the placement blueprint not existing (removed from the scene by `ComposeBlueprintContainer`).
