I managed to do this by accident three times today while testing using
the dashboard display, so it's time to action on it.
Touched on in
https://github.com/ppy/osu/discussions/30740#discussioncomment-11345996.
Was also mentioned recently in discord or another discussion explicitly
but I can't find that.
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.
Would close https://github.com/ppy/osu/issues/31312.
Not super happy with the performance overhead of this, but this is
already a heuristic-based implementation to avoid every-frame
`.ChildrenOfType<>()` calls or similar, so not super sure how to do
better. The `Array.Contains()` check stands out in profiling, but
without it the indicators can collapse *too* eagerly sometimes.
- Closes https://github.com/ppy/osu/issues/21189
- Supersedes / closes https://github.com/ppy/osu-framework/pull/5627
- Supersedes / closes https://github.com/ppy/osu/pull/22235
The reason why I opted for a complete rewrite rather than a revival of
that aforementioned pull series is that it always felt quite gross to me
to be pulling framework's audio subsystem into the task of reading ID3
tags, and I also partially don't believe that BASS is *good* at reading
ID3 tags. Meanwhile, we already have another library pulled in that is
*explicitly* intended for reading multimedia metadata, and using it
does not require framework changes. (And it was pulled in explicitly for
use in the editor verify tab as well.)
The hard and dumb part of this diff is hacking the gibson such that
the metadata section on setup screen actually *updates itself*
after the resources section is done doing its thing. After significant
gnashing of teeth I just did the bare minimum to make work by caching
a common parent and exposing an `Action?` on it. If anyone has better
ideas, I'm all ears.
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.
Closes https://github.com/ppy/osu/issues/31290.
Tend to agree that this is a good idea for gameplay test at least. Not
sure about other similar interactions like exiting - I don't think it
matters what's done in those cases, because for exiting timing is in no
way key, so I just applied this locally to gameplay test.
