This is a bit of an unfortunate edge case where the unbind-on-disposal
doesn't help, since the binding is happening in BDL, and the usage is in
a nested `LoadComponentAsync` call. Combine those and you have a recipe
for disaster.
I've also changed the cutoffs to 5% rather than zero, as this seems like
a saner method of showing this dialog. With levels 5% or less, the game
is basically inaudible.
Arguably, the cutoff can be increased to 10%.
Would lead to exceptions due to modification of `Beatmap.HitObjects`
during its enumeration by `DrawableRuleset`, which was happening as an
async load via `EditorScreenWithTimeline.CreateMainContent()`.
If a user leave and then rejoins a multiplayer match while another user
is not at the lobby screen, there is a potential the `ParticipantPanel`
tracking the user will not correctly be recreated to reference the new
instance of the `MultiplayerUser`.
This happens because the `OnRoomUpdated` call is scheduled, which means
it is not running in the background, coupled with the local logic that
relies on `IEquatable(MultiplayerRoomUser)` (which in turn falls back to
a UserID comparison).
Changing this to a reference comparison is the easiest way to resolve
this. Whether we change the `IEquatable` implementation is up for
discussion.
Closes https://github.com/ppy/osu/issues/15970.
This covers the scenario where a user may be at the song select screen
while another user (the room host) starts the match. This was only made
possible with the new queue modes, so is quite a recent regression.
This avoids accidental usage which could result in data being lost or
ignored (as only the last `user` in a single frame would arrive).
This was added specifically to debounce sample playback, but given that
it's only debouncing on a single frame (hardly noticeable) I'm not going
to add back support for that yet. It should be handled by sample
playback concurrency or something more local to the usage.