Fix slider head being incorrectly dimmed twice #27369
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
frenzibyte
requested review from
frenzibyte
and removed request for
frenzibyte
There's something else there at play because I noticed when testing this that on some maps the slider tail won't dim correctly when it should. See attached video: Untitled.mp4Anyhow I'll look into that separately. This seems fine on its own. |
bdach
previously approved these changes
Feb 27, 2024
bdach
dismissed
their stale review
actually hold it, i'll investigate the tail issue first, because i have a feeling we may want to do something else here
|
Upon further investigation tails not correctly dimming is a separate issue. On first use of every pooled object it would "fix" the double dim of the slider head, but break the single dim of the slider tail. Working on fix, will be submitted separately. |
bdach
approved these changes
Feb 27, 2024
bdach
added a commit
to bdach/osu
that referenced
this pull request
Feb 27, 2024
Originally noticed during review of another change: ppy#27369 (comment). `DrawableOsuHitObject` tries to solve the initial dimming of objects by applying transform to a list of dimmable parts. For plain drawables this is safe, but if one of the parts is a DHO, it is not safe, because drawable transforms can be cleared at will. In particular, on first use of a drawable slider, `UpdateInitialTransforms()` would fire via `LoadComplete()` on the `DrawableSlider`, but *then*, also via `LoadComplete()`, the `DrawableSliderTail` would update its own state and by doing so inadvertently clear the dim transform just added by the slider. To fix, ensure dim transforms are applied to DHOs via `ApplyCustomUpdateState`.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Resolves #25761.
Notice that the slider heads's approach circles are also dimmed in the footage in the issue. Slider heads are supposed to behave like hit circles, which dim their body, but not their approach circle.
The issue is that
DrawableSliderdims its elements, including itsHeadCircle, butDrawableSliderHead, inheriting fromDrawableHitCircle, already dims itself (while also not dimming the approach circle), so the slider head is incorrectly being dimmed twice.Thus, the solution is to remove the slider head from the list of slider elements to dim.
Not sure why it's an issue only most of the time (eg. from a few seconds into the map) and not always. The drawable hit object's state might not always be updating when it should? Either way, the addressed issue is gone now.
some data
In the footage, the cutoff point seems to be between the orange 5 and the orange 6. Times in the map:
On my test map (offset 676) it would usually happen at 11497, but usually not at 11568.
Sometimes, moving the slider to a new time, or even just seeking away and back, would resolve or reintroduce the issue on the slider, or removing all objects before the tested slider and existing and re-entering the editor would resolve the issue. Changing offset didn't make a difference.