Also didn't notice a particular case here, but if all code passes up
until we get to the `foreach (var h in nestedHitObjects)` below, then we
could end up stuck here for quite a while.
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*.
* Calculate hit windows in performance calculator instead of databased difficulty attributes
* Apply mods to beatmap difficulty in osu! performance calculator
* Remove `GreatHitWindow` difficulty attribute for osu!mania
* Remove use of approach rate and overall difficulty attributes for osu!
* Remove use of hit window difficulty attributes in osu!taiko
* Remove use of approach rate attribute in osu!catch
* Remove unused attribute IDs
* Code quality
* Fix `computeDeviationUpperBound` being called before `greatHitWindow` is set
The `EventCount` variable wasn't factoring in that some results do not
affect unstable rate. It would therefore become more incorrect as the
play continued.
Closes https://github.com/ppy/osu/issues/31712.
- Caches `DrawableRuleset` in editor compose screen for mania playfield adjustment container (because it's used to wrap the blueprint container as well)
- Fixes `ManiaModWithPlayfieldCover` performing a no-longer-correct direct cast with a naive-but-working approach.
Closes https://github.com/ppy/osu/issues/25608.
Logic mostly matching stable. All operations are done on `ComboOffset`
which still makes overridden combo colours weirdly relatively dependent
on each other rather than them be an "absolute" choice, but alas...
As per stable, two consecutive new combos can use the same colour only
if they are separated by a break:
52f3f75ed7/osu!/GameModes/Edit/Modes/EditorModeCompose.cs#L4564-L4571
This control is only available once the user has changed the combo
colours from defaults; additionally, only a single new combo object
must be selected for the colour selector to show up.
As I look into re-implementing the ability to choose combo colour for an
object (also known as "colourhax") from the editor UI, I stumble upon
these wretched ternary items again and sigh a deep sigh of annoyance.
The structure is overly rigid. `TernaryItem` does nothing that
`DrawableTernaryItem` couldn't, except make it more annoying to add
specific sub-variants of `DrawableTernaryItem` that could do more
things.
Yes you could sprinkle more levels of virtuals to
`CreateDrawableButton()` or something, but after all, as Saint Exupéry
says, "perfection is finally attained not when there is no longer
anything to add, but when there is no longer anything to take away."
So I'm leaning for taking one step towards perfection.
Originally this was an intentional choice (see
https://github.com/ppy/osu/pull/18088) when these controls were more
transparent and didn't for a solid toolbox area.
But this is no longer the case, so for now let's always block scroll to
match user expectations.
Closes#31262.
RFC. This closes https://github.com/ppy/osu/issues/31186.
To explain why: The issue occurs on
https://osu.ppy.sh/beatmapsets/594828#osu/1258033, specifically on the
slider at time 128604. The failure site is
fa0d2f4af2/osu.Game.Rulesets.Osu/Edit/Blueprints/Sliders/SliderCircleOverlay.cs (L65-L66)
wherein `LastRepeat` is `null`, even though the slider's `RepeatCount`
is 1 and thus `SpanCount` is 2.
In this case, `SliderEventGenerator` is given a non-zero `tickDistance`
but a zero `length`. The former is clamped to the latter:
fa0d2f4af2/osu.Game/Rulesets/Objects/SliderEventGenerator.cs (L34)
Because of this, a whole block of code pertaining to tick generation
gets turned off, because of zero tick spacing - however, that block also
includes within it *repeat* generation, for seemingly very little reason
whatsoever:
fa0d2f4af2/osu.Game/Rulesets/Objects/SliderEventGenerator.cs (L47-L77)
While a zero tick distance would indeed cause `generateTicks()` to loop
forever, it should have absolutely no effect on repeats.
While this *is* ultimately an aspire-tier bug caused by people pushing
things to limits, I do believe that in this case a fix is warranted
because of how hard the current behaviour violates invariants. I do not
like the possibility of having a slider with multiple spans and no
repeats.
* Change slider drop penalty to use actual number of difficult sliders, fix slider nerf being too lenient
* Move cubing to performance calculation
* Add separate list for slider strains
* Rename difficulty atttribute
* Rename attribute in perfcalc
* Check if AimDifficultSliderCount is more than 0, code quality fixes
* Add `AimDifficultSliderCount` to the list of databased attributes
* Code quality
---------
Co-authored-by: James Wilson <tsunyoku@gmail.com>
* Simplify osu! high-bpm acute angle jumps bonus
* Add aim wiggle bonus
* Add hitwindow-based aim velocity decrease
* Revert "Add hitwindow-based aim velocity decrease"
This reverts commit bcebe9662cfcb7a72805e48712525ef54ec9820e.
* Move wiggle multiplier to a const, slightly decrease acute bonus multiplier
* Make sure the previous object in the wiggle bonus is also part of the wiggle
* Scale the wiggle bonus multiplayer down
* Increase the acute angle jump bonus multiplier
* Make wiggle bonus only apply on >150 bpm streams, make repetitive angle penalty
* Reduce wiggle bonus multiplier to not break velocity>difficulty relation
* Adjust wiggle falloff function to fix stability issues
* Adjust wiggle consts
* Update tests
