Closes https://github.com/ppy/osu/issues/32289.
There are two possible choices here: either pulling the lower bound of
the clamp down to `HitObject.Path.CalculatedDistance`, or pulling the
higher bound up to `minDistance`, if it happens to be larger than the
path's calculated distance.
Both options are a bit weird; pulling down can result in unsnapped
sliders when attempting to drag a slider's end when on a lower beat
divisor than was used to place the slider, and pulling up can result in
weird sliders wherein they get extended beyond their path's definition
with a weird linear section at the end without an anchor that is tangent
to the slider shape's end. I decided the first one was less weird, but
I'm open to discuss further.
Mainly an issue with "limit distance snap to current time". Reported in
https://discord.com/channels/90072389919997952/1259818301517725707/1369037235797753999.
This slightly changes behaviour of distance snap when the mouse is near
the edges of the screen (will turn off snap rather than clamp to edge as
previously), but I think that's probably fine.
Addresses concerns in https://github.com/ppy/osu/discussions/24226.
I basically adjusted opacity down until it started to visually detract
from the skin. The pro level is lower than I'd want to see, but feels
like a midpoint that some users may find usable.
This is a band-aid fix until we can get proper support for settings like
this into the skin editor.
This PR converts the leaderboard into a full-fledged skinnable component
that can be manipulated by users at will.
Notably, this finally allows https://github.com/ppy/osu/issues/20422 to
be fixed - although it's a very mixed bag, for several reasons:
- Because of taiko players' refusal to see reason^W^W^W^Winsistence on
keeping stable behaviours related to aspect ratio treatment, I have to
assume the worst case scenario, which means than on typical
resolutions like 16:9 (or even worse, 4:3), the leaderboard will
likely not occupy as much vertical space as it probably could.
- Additionally, there's the problem of where to put the spectator list.
I settled on putting it to the right of the leaderboard, but that's
kind of janky, because the leaderboard sometimes collapses and
sometimes fully hides, leading to a very awkward space left behind. If
we had the capability to anchor elements to other elements, maybe this
could be resolved, but for now, I'm not sure what to do. I think if
some users are bothered by it they can move it where they want it. Or
delete it.
Closes https://github.com/ppy/osu/issues/32880
Broke in conjunction with https://github.com/ppy/osu/pull/32638 because
of transforms not being applied to `DrawableSliderRepeat` but its
individual pieces instead.
In cross-checking with stable (visual only) the early fade in of the
arrow should still apply, it just shouldn't be instantaneous as is
currently ends up being with how the code is structured.
Make isSpinnableTime public in SpinnerRotationTracker and use it to set Tracking in OsuModSpunOut.
Tracking was previously set to true, causing the "spins per minute" to appear immediately when the spinner appeared.
Closes https://github.com/ppy/osu/issues/32420.
The failure cause here is that in editor the beatmap version for the
beatmap affected (or... any beatmap, really), is 0 (ZERO). That is
probably a regression from https://github.com/ppy/osu/pull/32315, but
like... can we universally agree that calling that change "a regression"
in any capacity is dumb? Like what was that code *doing* playing dumb
reference games and copying stuff into an arbitrary instance that could
get or not get used later on? And now you have a 50/50 chance of
accessing the *correct* model's field, depending on whether you go via
`BeatmapInfo` or `Beatmap.BeatmapInfo`?
Moving the field to `IBeatmap`, i.e. what is by now - by consensus,
since https://github.com/ppy/osu/pull/28473 - supposed to be the "decoded
and materialised" beatmap, fixes this issue.
I probably should have done this as part of
https://github.com/ppy/osu/pull/28473 but it slipped my mind. Probably
for the better too because this change has rather large chances of
breaking stuff so maybe better to examine it in isolation (via diffcalc
runs or whatever).
For added humour points, you'd say that the field on `BeatmapInfo` was
not `[Ignore]`d, so this is a realm schema change, right? No. As far as
I can tell, it's not. I opened realm studio and `BeatmapVersion` *is not
a listed column` on `Beatmap` models.
I'm also not gonna get into the fact that I think `EditorBeatmap` doing
dumb games with juggling two `BeatmapInfo` references since
https://github.com/ppy/osu/pull/15075 is bad, because I don't think I
have the mental capacity to hotfix this by going down that train of
thought.
See previous commit for partial rationale.
There's an argument to be made about the `NaN`-spreading semantics being
desirable because at least something will loudly fail in that case, but
I'm not so sure about that these days. It feels like either way if
`NaN`s are produced, then things are outside of any control, and chances
are the game can probably continue without crashing. And, this move
reduces our dependence on osuTK, which has already been living on
borrowed time for years now and is only awaiting someone brave to go
excise it.