## [Rewrite `BackgroundMusicManager` to not run into framework
breakage](https://github.com/ppy/osu/commit/622216d8911832c39fa4e126b2810e4e0f46cbf7)
The attempted proper fix to this was
https://github.com/ppy/osu-framework/pull/6727. Unfortunately when
presented with [the framework
bump](https://github.com/ppy/osu/pull/37217) with that change, CI says
"you're stupid" and fails on some disposal idiocy that of course is
undebuggable and irreproducible:
The active test run was aborted. Reason: Test host process crashed :
Unhandled exception. System.AggregateException: One or more errors
occurred. (Object reference not set to an instance of an object.)
---> System.NullReferenceException: Object reference not set to an
instance of an object.
at osu.Framework.Audio.Sample.SampleChannelBass.Dispose(Boolean
disposing)
at System.Threading.ExecutionContext.RunInternal(ExecutionContext
executionContext, ContextCallback callback, Object state)
--- End of stack trace from previous location ---
at System.Threading.ExecutionContext.RunInternal(ExecutionContext
executionContext, ContextCallback callback, Object state)
at System.Threading.Tasks.Task.ExecuteWithThreadLocal(Task&
currentTaskSlot, Thread threadPoolThread)
--- End of inner exception stack trace ---
at osu.Framework.Audio.AudioCollectionManager`1.UpdateChildren()
at osu.Framework.Audio.AudioCollectionManager`1.UpdateChildren()
at osu.Framework.Audio.AudioCollectionManager`1.UpdateChildren()
at osu.Framework.Audio.AudioCollectionManager`1.UpdateChildren()
at osu.Framework.Threading.AudioThread.OnExit()
at osu.Framework.Threading.GameThread.setExitState(GameThreadState
exitState)
at osu.Framework.Threading.GameThread.RunSingleFrame()
at osu.Framework.Threading.GameThread.<createThread>g__runWork|70_0()
at System.Threading.ExecutionContext.RunInternal(ExecutionContext
executionContext, ContextCallback callback, Object state)
--- End of stack trace from previous location ---
at System.Threading.ExecutionContext.RunInternal(ExecutionContext
executionContext, ContextCallback callback, Object state)
(https://github.com/ppy/osu/actions/runs/24019928154/job/70046733058?pr=37217#step:5:119)
I no longer have the energy for any of this shit.
@nekodex would appreciate if you could check that I actually haven't
broken anything with the bgm here. Seems okay to me in test scenes at
least.
## [Apply lowest-effort maybe-fixing changes to a bunch of flaking
tests](https://github.com/ppy/osu/commit/7bd3ca4adfcce5b90add11565a13f3fe9177ad5e)
None of the failures are reproducible locally, of course. I'm tired of
this. If anyone else wants to subject themselves to actually
investigating any of these, by all means, godspeed and good luck.
Arguably we should just nuke the now playing overlay playlist window
completely as the functionality was gimped when search was removed. Now
it doesn't seek to the currently playing track, nor play sequentially,
nor do anything useful.
---------
Co-authored-by: Bartłomiej Dach <dach.bartlomiej@gmail.com>
Closes#36246
This PR overrides `HandlePositionalInput` to reject all positional input
when `Item` is null.
---------
Co-authored-by: Dean Herbert <pe@ppy.sh>
What the actual heck is that magic number stupidity.
I'm not looking into why the test falls over so badly that it apparently
dies on some main menu logic just because assertions fail, because the
main menu logic is for hold-to-song-select-v2 and is thus temporary.
This aims to bring some conformity to naming to make it easier to
understand component structure for new components.
Renames are pulled out of the song select v2 changes and are more
relevant there due to many new classes being added.
- `V2` suffix is dropped, with v2 components being moved to a relevant V2 namespace.
- Related classes have a prefix of the area they are used.
- Experimenting with using partial/nested classes in the song select v2 implementation.
Not committing to this yet but want to see how it plays out.
- Moved base carousel components to a generic namespace to avoid confusion with actual beatmap carousel implementation.
The idea of specifying "bleed" is to make the carousel aware of its
vertical display area. The top bleed is under the filter control; bottom
beneath the toolbar. At the end of the day, the point of panel X offset
incursion, and the scroll target for current selection, should be at the
centre of the screen.
The fixes match code which already exists in the previous
implementation. Basically, without incorporating `BleedTop` into
calculations a second time, the centre position would not match
expectations (of being the centre including bleed).
RFC. Another attempt at this.
- Supersedes https://github.com/ppy/osu/pull/31881
- Supersedes / closes https://github.com/ppy/osu/pull/31355
- Closes https://github.com/ppy/osu/issues/29861
This is a weird diff because I am feeling rather boxed in by all the
constraints, namely that:
- Leaderboard state should be global state
- But the global state is essentially managed by song select and namely
`BeatmapLeaderboard` itself. That's because trying to e.g. not have
`BeatmapLeaderboard` pass the beatmap and the ruleset to the global
leaderboard manager is worse, as it essentially introduces two
parallel paths of execution that need to be somehow merged into one
(as in I'd have to somehow sync `LeaderboardManager` responding to
beatmap/ruleset changes with `BeatmapLeaderboard` which is inheritance
hell)
- Also local leaderboard fetching is data-push (as in the scores can
change under the leaderboard manager), and online leaderboard fetching
is data-pull (as in the scores do not change unless the leaderboard
manager does something). Also online leaderboard fetching can fail.
Which is why I need to still have the weird setup wherein there's a
`FetchWithCriteriaAsync()` (because I need to be able to respond to
online requests taking time, or failing), but also the
`BeatmapLeaderboard` only uses the public `Scores` bindable to
actually read the scores (because it needs to respond to new local
scores arriving).
- Another thing to think about here is what happens when a retrieval
fails because e.g. the user requested friend leaderboards without
having supporter. With how this diff is written, that special
condition is handled to `BeatmapLeaderboard`, and
`LeaderboardManager`'s state will remain as whatever it was before
that scope change was requested, which may be considered good or it
may not (I imagine it's better to show scores in gameplay than not in
this case, but maybe I'm wrong?)