Done for two reasons:
- During review it was requested for the logic to be moved out of
`BezierConverter` as `BezierConverter` was intended to produce
"lazer style" sliders with per-control-point curve types,
as a future usability / code layering concern.
- It is also relevant for encode-decode stability. With how the logic
was structured between the Bezier converter and the legacy beatmap
encoder, the encoder would leave behind per-control-point Bezier curve
specs that stable ignored, but subsequent encodes and decodes in lazer
would end up multiplying the doubled-up control points ad nauseam.
Instead, it is sufficient to only specify the curve type for the
head control point as Bezier, not specify any further curve types
later on, and instead just keep the double-up-control-point for new
implicit segment logic which is enough to make stable cooperate
(and also as close to outputting the slider exactly as stable would
have produced it as we've ever been)
The logic in `LegacyBeatmapEncoder` that was supposed to handle
the lazer-exclusive feature of supporting multiple slider segment types
in a single slider was interfering rather badly with the Bezier
converter. Generally it was a bit difficult to follow, too.
The nice thing about `BezierConverter` is that it is *guaranteed* to
only output Bezier control points. In light of this, the same double-up-
-the-control-point logic that was supposed to make multiple slider
segment types backwards-compatible with stable can be placed in
the Bezier conversion logic, and be *much* more understandable, too.
To be used in the editor, for the beatmap submission wizard.
I've recently been on record for hating "abstract" as a rationale to do
anything, but seeing this commit ~3 months after I originally made it,
it still feels okay to do for me in this particular case. I think the
abstraction is loose enough, makes sense from a code reuse and UX
consistency standpoint, and doesn't seem to leak any particular
implementation details. That said, it is both a huge diffstat and also
potentially controversial, which is why I'm PRing first separately.
See https://github.com/ppy/osu/issues/29720,
https://discord.com/channels/188630481301012481/188630652340404224/1334294048541904906.
This removes the tooltip due to being zero or negative information, and
also changes the description of the setting to not contain the word
"mirror", which will hopefully quash the "this is where I would place a
mirror to my screen to achieve what I want" interpretation which seems
to be a minority interpretation.
The first time this was complained about I figured this was probably a
one guy issue, but now it's happened twice, and I never want to see this
conversation again.
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.
