@peppy noticed recently that attempting to spectate just a few users was
very likely to end up in requests very quickly being rejected with code
429 ("Too Many Requests").
I'm somewhat certain that the reason for that is that a significant
number of players is wont to retry a lot in quick succession. That means
that spectator server is going to note a lot of gameplay start and end
messages in quick succession, too. And as it turns out, every gameplay
start would end up triggering a new beatmap set fetch request:
ccf1acce56/osu.Game/Screens/Spectate/SpectatorScreen.cs (L131-L134)ccf1acce56/osu.Game/Screens/Play/SoloSpectatorScreen.cs (L168-L172)ccf1acce56/osu.Game/Screens/Play/SoloSpectatorScreen.cs (L243-L256)
To attempt to curtail that, use the beatmap cache instead, which should
prevent these unnecessary requests from firing in the first place,
therefore reducing the chance of the client getting throttled.
This technically means that a different endpoint is used to fetch the
data (`GET /beatmaps/?ids[]=` rather than `GET
/beatmapsets/lookup?beatmap_id={id}`), but docs claim that both should
return the same data, and it looks to work fine in practice.
Compare: https://github.com/ppy/osu/pull/24548.
I don't have a reproduction scenario (judging from the stack trace
of the crash it's likely to be nigh-impossible to concoct a reliable
one), but there is some circumstantial evidence that this might help,
namely that that previous fix above worked, and the pathway that's
failing here is similarly async to the one that pull fixed. So I'm just
gonna start with that and hope that it does the job.
This is an interesting scenario where we arrive at a fresh
`BeatmapOffsetControl` but with a reference score (from the last play).
Our best assumption here is that the beatmap's offset hasn't changed
since the last play, so we want to use it for the `lastPlayBeatmapOffset`.
But due to unfortunate order of execution, `Current.Value` was not yet
initialised.
analysis container creates settings and the settings items are created more nicely
also removed use of localized strings because that can be done separately
I've been meaning to make the progress bar synchronise with the beat
rather than a continuous countdown, just to give the overlay a bit more
of a rhythmic feel.
Not completely happy with how this feels but I think it's a start?
I had to refactor how the break overlay works in the process. It no
longer creates transforms for all breaks ahead-of-time, which could be
argued as a better way of doing things. It's more dynamically able to
handle breaks now (maybe useful for the future, who knows).
I didn't really want to move the cursor in front of the HUD, but we face
a bit of an impossible scenario otherwise (it should definitely be in
front of the break overlay for visibility).
So I'll deal with it for now.
If a key is pressed while the pause overlay is visible, the ruleset input manager will not see it, therefore if the user resumes while the key is held then releases the key, the ruleset input manager will not receive the key up event.
