Addresses https://github.com/ppy/osu/discussions/33291
This is a half-baked RFC because things are awkward.
For this to work correctly the submission flow has to do an API request,
because one, the local beatmap status has been overwritten with "locally
modified", and secondly, even if it *was* there, there's no guarantee
that it was actually *up to date*.
And if we have to do an API request then there are two choices:
- Hard block on the API request and don't show anything until it
completes which possibly means waiting at a spinner for several
seconds if someone's on bad internet.
- Don't block on the API request --- but then there's no guarantee
what timing the API request completes at, which means that possibly the
user could change the dropdown before the API request completes, and
the API request will overwrite their choice, so to prevent that block
the dropdown until the request completes. This is what this commit
does.
There are two primary paths here:
1. A user requests an update. The existing request is used if it's in
progress, or a new request is made and processed immediately.
2. Something is changed (e.g. the release stream) that triggers a
background request. A new request is made to run after the existing one.
As proposed in https://github.com/ppy/osu/discussions/33572.
Note that this won't work if you leave to song select. We could make
that work but it would require further global faffing and I don't think
it's worth the effort.
Closes https://github.com/ppy/osu/issues/33393.
This is admittedly a half-assed diff. This was apparently "fixed" once
before, eons ago, in https://github.com/ppy/osu/pull/11032, but I'm not
sure whether it regressed, or where, because I don't want to bisect four
years back. (At that time `ControlPointInfo.ControlPointsChanged`
did not exist yet.)
Also there's the part where changes to control points do not undo or
redo (see https://github.com/ppy/osu/issues/31942), but I'm not touching
that *either*, because if I start touching that, then I will get yelled
at for not reviewing the 2.5k line PR that rewrites the entirety of
change handling in editor instead
(https://github.com/ppy/osu/pull/30314). I will attempt to get through
that mental block sometime within the year. Please do not rush me.
The cheap cop-out argument is that hooking this up to `ControlPointInfo`
specifically is probably "more efficient" anyway.
Mostly closes https://github.com/ppy/osu/issues/33505.
Compare
https://github.com/ppy/osu/blob/97e6187f0d7c3dbee896596a623e34627135bf0e/osu.Game/Rulesets/Objects/Legacy/ConvertHitObjectParser.cs#L56-L59
I say "mostly" here because I'm rather skeptical that this is 100% rock
solid still, for one reason - namely that the game stores path control
point coordinates relative to the head, then turns them into absolute
coordinates when encoding, and then on decoding turns them back into
coordinates relative to the head, which in floating-point world is a Bad
Idea because of round-off error. But I'm not fixing that without
introducing a completely new beatmap format or rewriting half the
editor to address that, so I'll just pretend that I don't know any
of this until someone notices.
This is a very dodgy fix, but it fixes an edge case that has so far - to
my knowledge - not been reported by users in the wild, only by me trying
to break things, so my hope is that we can do this and move on for now.