1
0
mirror of https://github.com/ppy/osu.git synced 2025-03-11 06:37:19 +08:00
Bartłomiej Dach 41db3c1501
Fix taiko swell ending samples playing at results sometimes
Closes https://github.com/ppy/osu/issues/32052.

Sooooo... this is going to be a rant...

To understand why this is going to require a rant, dear reader, please
do the following:

1. Read the issue thread and follow the reproduction scenario (download
   map linked, fire up autoplay, seek near end, wait for results, hear
   the sample spam).
2. Now exit out to song select, *hide the toolbar*, and attempt
   reproducing the issue again.
3. Depending on ambient mood, laugh or cry.

Now, *why on earth* would the *TOOLBAR* have any bearing on anything?

Well, the chain of failure is something like this:

- The toolbar hides for the duration of gameplay, naturally.
- When progressing to results, the toolbar gets automatically unhidden.
- This triggers invalidations on `ScrollingHitObjectContainer`. I'm not
  precisely sure which property it is that triggers the invalidations,
  but one clearly does. It may be position or size or whichever.
- When the invalidation is triggered on `layoutCache`, the next
  `Update()` call is going to recompute lifetimes for ALL hitobject
  entries.
- In case of swells, it happens that the calculated lifetime end of the
  swell is larger than what it actually ended up being determined as at
  the instant of judging the swell, and thus, the swell is *resurrected*,
  reassigned a DHO, and the DHO calls `UpdateState()` and plays the
  sample again despite the `samplePlayed` flag in `LegacySwell`, because
  all of that is ephemeral state that does not survive a hitobject
  getting resurrected.

Now I *could* just fix this locally to the swell, maybe, by having some
time lenience check, but the fact that hitobjects can be resurrected by
the *toolbar* appearing, of all possible causes in the world, feels
just completely wrong. So I'm adding a local check in SHOC to not
overwrite lifetime ends of judged object entries.

The reason why I'm making that check specific to end time is that I can
see valid reasons why you would want to recompute lifetime *start* even
on a judged object (such as playfield geometry changing in a significant
way). I can't think of a valid reason to do that to lifetime *end*.
2025-02-24 14:30:55 +01:00
..
2023-06-24 01:00:03 +09:00
2023-06-24 01:00:03 +09:00
2024-12-07 12:06:33 +09:00
2024-02-02 04:53:48 +03:00
2023-06-24 01:00:03 +09:00
2023-06-24 01:00:03 +09:00
2023-06-24 01:00:03 +09:00