The `EventCount` variable wasn't factoring in that some results do not
affect unstable rate. It would therefore become more incorrect as the
play continued.
Closes https://github.com/ppy/osu/issues/31712.
- Caches `DrawableRuleset` in editor compose screen for mania playfield adjustment container (because it's used to wrap the blueprint container as well)
- Fixes `ManiaModWithPlayfieldCover` performing a no-longer-correct direct cast with a naive-but-working approach.
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.
Originally this was an intentional choice (see
https://github.com/ppy/osu/pull/18088) when these controls were more
transparent and didn't for a solid toolbox area.
But this is no longer the case, so for now let's always block scroll to
match user expectations.
Closes#31262.
RFC. This closes https://github.com/ppy/osu/issues/31186.
To explain why: The issue occurs on
https://osu.ppy.sh/beatmapsets/594828#osu/1258033, specifically on the
slider at time 128604. The failure site is
fa0d2f4af2/osu.Game.Rulesets.Osu/Edit/Blueprints/Sliders/SliderCircleOverlay.cs (L65-L66)
wherein `LastRepeat` is `null`, even though the slider's `RepeatCount`
is 1 and thus `SpanCount` is 2.
In this case, `SliderEventGenerator` is given a non-zero `tickDistance`
but a zero `length`. The former is clamped to the latter:
fa0d2f4af2/osu.Game/Rulesets/Objects/SliderEventGenerator.cs (L34)
Because of this, a whole block of code pertaining to tick generation
gets turned off, because of zero tick spacing - however, that block also
includes within it *repeat* generation, for seemingly very little reason
whatsoever:
fa0d2f4af2/osu.Game/Rulesets/Objects/SliderEventGenerator.cs (L47-L77)
While a zero tick distance would indeed cause `generateTicks()` to loop
forever, it should have absolutely no effect on repeats.
While this *is* ultimately an aspire-tier bug caused by people pushing
things to limits, I do believe that in this case a fix is warranted
because of how hard the current behaviour violates invariants. I do not
like the possibility of having a slider with multiple spans and no
repeats.
Also makes the mod display initialization sequence (start expanded, then
unexpand) controlled by HUDOverlay rather than mod display itself. This
enabled different treatment depending on whether the mod display is
viewed in the skin editor or in the player.
Co-authored-by: Bartłomiej Dach <dach.bartlomiej@gmail.com>
Several users have reported stutters when this happens. It's potentially
from the error report overhead. We now know that this is a BASS level
issue anyway, so having this logging is not helpful.
