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`).
