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.
Pull request #11107 introduced changes in osu! performance calculation,
related to a scaling coefficient applied to the speed and aim skills.
The coefficient in question was dependent on the approach rate of
a map. During a post-merge review of that PR, it was spotted that
the scaling coefficient for speed also had a 10x buff applied for AR<8,
which could reach magnitudes as large as 80% on AR0, which seems quite
exorbitant. This change was not discussed or mentioned anywhere in the
review process.
Revert back to the old multiplier of 0.01 rather than 0.1 for AR<8. The
negative slope through AR0 to 8 is retained in its previous form.
`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.
