I'm not *super* sure why this works, but it appears to, and my educated
guess as to why is that it counteracts the effects of a change in the SV
of the juice stream by artificially increasing or decreasing the
velocity when running the appropriate path conversions and expected
distance calculations. The actual SV change takes effect on the next
default application, which is triggered by the `Update()` call at the
end of the method.
This is important because the editable path conversions heavily depend
on the value of `JuiceStream.Velocity` being correct. The value is only
guaranteed to be correct after an `ApplyDefaults()` call, which is
triggered by updating the object via `EditorBeatmap`.
Before I go with a hammer to redesign these, I want to remove stuff that
does nothing first.
Hard-breaks API to allow rulesets to specify an enumerable of custom
sections rather than two specific weird ones.
For specific rulesets:
- osu!:
- Stack leniency slider merged into difficulty section.
- osu!taiko:
- Approach rate and circle size sliders removed.
- Colours section removed.
- osu!catch:
- No functional changes.
- osu!mania:
- Special style toggle merged into difficulty section.
- Colours section removed.
Compare: https://github.com/ppy/osu/pull/26616
This came up elsewhere, namely in
https://github.com/ppy/osu/pull/28277#issuecomment-2133505958.
As it turns out, at least one beatmap among those whose scores had
unexpected changes in total score, namely
https://osu.ppy.sh/beatmapsets/971028#fruits/2062131, was using slider
velocity multipliers that were not a multiple of 0.01 (the specific
value used was 0.225x). This meant that due to the rounding applied to
`SliderVelocityMultiplierBindable` via `Precision`, the raw value was
being incorrectly rounded, resulting in incorrect conversion.
The "direct" change that revealed this is most likely
https://github.com/ppy/osu-framework/pull/6249, by the virtue of
shuffling the `BindableNumber` rounding code around and accidentally
changing midpoint rounding semantics in the process. But it was not
at fault here, as rounding was just as wrong before that change
as after in this specific context.
