Closes https://github.com/ppy/osu/issues/28983.
While the direct cause of this is most likely mouse confine in
full-screen, it shouldn't/can't really be disabled just for this,
and I also get this on linux in *windowed* mode.
In checking other apps, adding some tolerance to this sort of
drag-scroll behaviour seems like a sane UX improvement anyways.
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`.
Closes https://github.com/ppy/osu/issues/28989.
Because swell ticks are judged manually by their parenting objects,
swell ticks were not given a start time (with the thinking that there
isn't really one *to* give). This tripped up the "judge past objects"
logic in `EditorPlayer`, since it would enumerate all objects
(regardless of nesting) that are prior to current time and mark them as
judged. With all swell ticks having the default start time of 0 they
would get judged more often than not, leading to behaviour weirdness.
To resolve, give swell ticks a *relatively* sane start time equal to
the start time of the swell itself.
If a key is pressed while the pause overlay is visible, the ruleset input manager will not see it, therefore if the user resumes while the key is held then releases the key, the ruleset input manager will not receive the key up event.
Supersedes https://github.com/ppy/osu/pull/28907.
- Fix border being fat
- Fix thumbnail not masking correctly
- Fix background layer not being correctly fit to the panel
- Dim the main background on hover
- Minor tweaks to dimming
https://github.com/ppy/osu/pull/28900/checks?check_run_id=27652166871
This is an attempt. Going frame-by-frame I noticed that there's one
frame in which the text is loaded but the
FillFlowContainer/GridContainer haven't properly validated so the text
is not positioned correctly (it's overflowing the panel to the left). If
the cursor is moved at this exact time, then it may not be properly
positioned for the following assertion, even though it is _somewhere_ on
the panel.
If the above is the case, then this is a known o!f issue, but not a
simple one to solve.
I haven't reproed this locally.
