Noticed this during work on https://github.com/ppy/osu/pull/25185.
In some circumstances, it seemed that spinner bonus ticks (and mostly
them specifically) would not always play with the correct volume.
Hours of debugging later pointed at a trace at
`DrawableAudioWrapper.refreshLayoutFromParent()` not firing sometimes.
Initially I thought it to be some sort of framework bug, but after
preparing a diff and running final checks, I noticed that sometimes
the sample was being played *by a `PoolableSkinnableSample` that wasn't
loaded*. And determining why *that* is the case turned out with this
diff.
As it happens, spinner ticks get assigned a start time proportionally,
i.e. the 1st of 10 ticks is placed at 10% of the duration, the 2nd
at 20%, and so on. The start time generally shouldn't matter,
because the spinner is manually judging the ticks. *However*, the ticks
*still* receive a lifetime start / end in the same way normal objects
do, which means that in some cases they can *not be alive* when they're
hit, which means that the `DrawableAudioWrapper` flow *hasn't had
a chance to run*, and rightly so.
To fix, ensure that all spinner ticks are alive throughout the entirety
of the spinner's duration.
This multiplier has to exist.
I'm not guaranteeing that the rest is correct here. Should we be doing
proper cross-testing on this? Maybe, but it's going to be hard to get
right. We could likely check as far as "game pixels", but there's still
a chance that the osu-framework could be doing something weird in the
rest of the hierarchy where playfield scale is involved.
Closes https://github.com/ppy/osu/issues/25162. Tested to fix the linked
replay.
They had scale transforms applied to them in two places: the actual
legacy pieces themselves (esp. `LegacyHitCirclePiece`), and on the
`DrawableSliderRepeat` level.
This change moves all of the scale transforms to the skinnable pieces.
Argon and triangles have received a copy of the previous logic each,
so behaviour on those skins should not change.
It turns out multiple components depend on `Tracking` eventually
becoming `false` at the end of a slider. With my previous changes, this
was no longer the case (as could be seen by the legacy cursor particles
test failure, and heard by slider slide taking too long to stop).
Fixes half of https://github.com/ppy/osu/issues/24956.
The other half is high effort. The number portion is nested deeply and
with reason - depending on skin setting it changes the visual order.
I'm not sure how to fix that one, but I also think it's weird behaviour
and if people don't complain, it's probably fine to just dim the number
for consistency.
That said, the approach circle is an important one to ensure it matches
1:1, so I've fixed that here.
This reverts commit 03c61a573e.
The goal here was to handle an edge case discovered during work on note
lock, wherein it was determined that on stable hit circles would block
input from reaching objects underneath them. However, the change
mentioned above did that _too_ hard and caused overlaps to also be
blocked even long past a hit circle has been faded out.
Revert the change pending further (and more careful) investigation.
This is another similar case where stable floating point precision comes
into play due to use of `hitObjectManager.Beatmap.BpmMultiplierAt` (see
1531237b63/osu!/GameplayElements/HitObjects/Osu/SliderOsu.cs#L680)
Closes#24708.
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
fce3eacd7d - 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.
Slider heads are guaranteed to always be drawn at (0,0). This fixes
weird behaviour in the editor, but also simplifies things in the
process. Win-win.
Closes#20644.
Stable would dim objects when they can't be hit (ie. the "miss" window
is not active yet). This was never implemented in lazer, and causes
quite large visual differences.
No one has mentioned this yet, but it will definitely be one of those
missing pieces which makes lazer feel different to stable.
