Closes https://github.com/ppy/osu/issues/34959.
`ArgonCounterTextComponent` is pretty terrible and prevents being able
to fix the issue easily. The core issue is that this is the first
instance of the component's usage where the label text can be longer
than the counter in the X dimension, so the total width of any counter
is equal to max(label width, counter width), and the label will be
aligned to the left of that width, while the counter will be aligned to
the right of that width.
The fix sort of relies on the fact that I don't expect *any* consumer of
`ArgonCounterTextComponent` that meaningfully uses the wireframe digits
to want the non-wireframe digits to be aligned to the *left* rather than
the right. It's not what I'd expect any segmented display to work.
(There are usages that specify `TopLeft` anchor, but they usually
display the same number of wireframe and non-wireframe digits, so for
them it doesn't really matter if the digits are left-aligned to the
wireframes or not.)
Only seems to reproduce in gameplay for whatever reason. Can't justify
spending time to chase down why really because the previous code looked
obviously wrong on closer inspection anyway (`rightLayer` has transforms
applied to it on collapse/expand).
closes https://github.com/ppy/osu/issues/34688
I originally wrote it this way semi-intentionally because I thought
cutting out the sample was worse than letting it play out, but I also
forgot that people use like seventy hour long fail samples.
Probably closes https://github.com/ppy/osu/issues/34645.
Obviously this is only good if the score has managed to process online
and slot into a leaderboard before the user requested a retry. I can't
make miracles happen.
Notably this is not applied to quick retry, because it would make quick
retry slower, and the presumption is that if the user is quick-retrying
their last score is likely useless for global leaderboards anyway. (The
one exception to that last part is possibly quick-retrying from results
screen, which is a flow that we have, but maybe fine to ignore it...?)
This indicator allows the player to either rewind to an earlier part of
the replay, or to proceed to results. It also plays a shortened variant
of the failure animation SFX.
Before this commit, there was `AllowFailAnimation` (used by multiplayer)
and `OnFail()` (used by score submitting implementations of player to
ensure a failed play submits).
The former is replaced by `PerformFail()` which allows for arbitrary
operations on failure, which replay player shall leverage in subsequent
commits. The latter would ideally be replaced by nothing, but it's
placed in a very awkward place behind a schedule, so by force of
necessity to avoid code duplication it's replaced by
`ConcludeFailedScore()` which is overridden to submit the score in all
submitting players --- except for multiplayer, which is never supposed
to be calling it, so in that case it just throws an exception.