The server will return a valid error message in most cases here. We may
eventually want to add some fallback message for cases an error may
occur that isn't of
[InvariantException](3169b33ccc/app/Exceptions/InvariantException.php (L9-L10)) type, but I'm not 100% sure
how to identify these just yet.
`onLoadRequested()` always released the `readyClickOperation` ongoing
operation, without checking whether it actually needs to/should (it
should only do so if the action initiating the operation was starting
the game by the host). This would crash all other consumers, who already
released the operation when their ready-up operation completed server
side.
To resolve, relax the constraint such that the operation can be ended
multiple times in any order. At the end of the day the thing that
matters is that the operation is done and the ready button is unblocked.
It turns out this polling was necessary to get extra data that isn't
included in the main listing request. It was removed deemed useless, and
in order to fix the order of rooms changing when selecting a room.
Weirdly, I can't reproduce this happening any more, and on close
inspection of the code can't see how it could happen in the first place.
For now, let's revert this change and iterate from there, if/when the
same issue arises again.
I've discussed avoiding this second poll by potentially including more
data (just `user_id`s?) in the main listing request, but not 100% sure
on this - even if the returned data is minimal it's an extra join
server-side, which could cause performance issues for large numbers of
rooms.
Finishing an operation started via
`OngoingOperationTracker.BeginOperation()` was risky in cases where the
operation ended at a callback on another thread (which, in the case of
multiplayer, is *most* cases). In particular, if any consumer registered
a callback that mutates transforms when the operation ends, it would
result in crashes after the framework-side safety checks.
Rework `OngoingOperationTracker` into an always-present component
residing in the drawable hierarchy, and ensure that the
`operationInProgress` bindable is always updated on the update thread.
This way consumers don't have to add local schedules in multiple places.
In theory this seemed like a good idea (and an optimisation in some
cases, due to lower fill rate), but in practice this leads to weird edge
cases.
This aims to do away with the operations on external drawables by
applying a dim to the area behind the `LoadingLayer` when required.
I went over each usage and ensured they look as good or better than
previously.
The specific bad usage here was the restoration of the colour on dispose
(if the `LoadingLayer` was disposed in a still-visible state).
I'm aware that the `BeatmapListingOverlay` will now dim completely during
load. I think this is fine for the time being.
