From 7e5533e2057a215f8bcbc9b9f1e9edc2282edcdc Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Bart=C5=82omiej=20Dach?= Date: Sat, 10 Jun 2023 11:02:29 +0200 Subject: [PATCH] Fix not being able to receive full score for extremely short sliders with repeats Closes #23862. Score V2 is a scoring algorithm, which aside from the raw numerical values of each judgement, incorporates a combo component, wherein each judgement's "combo score" is derived from both the raw numerical value of the object and the current combo after the given judgement. In particular, this means that Score V2 is sensitive to the _order_ of judging objects, as if two objects with the same start time are judged using different ordering, they can end up having a different "combo score". The issue that this change is fixing is an instance of one such reordering. Upon inspection, it turned out that the simulated autoplay run, which is used to determine max possible score so that it can be standardised to 1 million again, was processing a slider repeat before a slider tail circle, while actual gameplay was processing the same slider repeat _after_ the slider tail circle. The cause of that behaviour is unfortunately due to `LegacyLastTick`. The sliders which cause the issue are extremely short. Stable had a behaviour, in which to provide leniency, slider tails were artificially offset back by 36ms. However, if the slider is not long enough to make this possible, the last tick is placed in the middle of the slider. If that slider also happens to have exactly 1 repeat, then this means that the last tick and the repeat have the same time instant. Because of the time equality, what begins to matter now is the _order_ of processing the elements of the drawable slider in the hierarchy. For the purposes of legacy skins, tail circles were moved below ticks in fce3eacd7de3254ce75619efaa2d15d59d564623 - but in this particular case, it means that the order of processing the slider elements is now inadvertently inverted, causing the entire debacle. While the fact that scoring depends on order of processing of visuals is suboptimal, there isn't a great way to address this without significant restructuring. Due to the structure of processing judgements currently in place, in which each judgement is processed independently from others by its corresponding drawable hit object, this is probably the best that can be done for the time being at least. --- .../Objects/Drawables/DrawableSlider.cs | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/osu.Game.Rulesets.Osu/Objects/Drawables/DrawableSlider.cs b/osu.Game.Rulesets.Osu/Objects/Drawables/DrawableSlider.cs index 664a8146e7..01174d4d61 100644 --- a/osu.Game.Rulesets.Osu/Objects/Drawables/DrawableSlider.cs +++ b/osu.Game.Rulesets.Osu/Objects/Drawables/DrawableSlider.cs @@ -75,18 +75,24 @@ namespace osu.Game.Rulesets.Osu.Objects.Drawables [BackgroundDependencyLoader] private void load() { + tailContainer = new Container { RelativeSizeAxes = Axes.Both }; + AddRangeInternal(new Drawable[] { shakeContainer = new ShakeContainer { ShakeDuration = 30, RelativeSizeAxes = Axes.Both, - Children = new Drawable[] + Children = new[] { Body = new SkinnableDrawable(new OsuSkinComponentLookup(OsuSkinComponents.SliderBody), _ => new DefaultSliderBody(), confineMode: ConfineMode.NoScaling), - tailContainer = new Container { RelativeSizeAxes = Axes.Both }, + // proxied here so that the tail is drawn under repeats/ticks - legacy skins rely on this + tailContainer.CreateProxy(), tickContainer = new Container { RelativeSizeAxes = Axes.Both }, repeatContainer = new Container { RelativeSizeAxes = Axes.Both }, + // actual tail container is placed here to ensure that tail hitobjects are processed after ticks/repeats. + // this is required for the correct operation of Score V2. + tailContainer, } }, // slider head is not included in shake as it handles hit detection, and handles its own shaking.