In order for the new star difficulty to be shown to users on the next
release.
catch's difficulty calculator version is not bumped because the only
catch change pending deploy is https://github.com/ppy/osu/pull/28353 and
that affects performance points only.
Closes https://github.com/ppy/osu/issues/29832.
The underlying reason for the incorrect sample playback was an equality
comparer failure.
Samples are contained in several pools which are managed by the
playfield. In particular, the pools are keyed by `ISampleInfo`
instances. This means that for correct operation, `ISampleInfo` has to
implement `IEquatable<ISampleInfo>` and also provide an appropriately
correct `GetHashCode()` implementation. Different audible samples must
not compare equal to each other when represented by `ISampleInfo`.
As it turns out, `VolumeAwareHitSampleInfo` failed on this, due to not
overriding equality members. Therefore, a `new
HitSampleInfo(HitSampleInfo.HIT_NORMAL, HitSampleInfo.BANK_NORMAL,
volume: 70)` was allowed to compare equal to a
`VolumeAwareHitSampleInfo` wrapping it, *even though they correspond to
completely different sounds and go through entirely different lookup
path sequences*.
Therefore, to fix, provide more proper equality implementations for
`VolumeAwareHitSampleInfo`.
When testing note that this issue *only occurs immediately after
placing an object*. Saving and re-entering editor makes this issue go
away. I haven't looked too long into why, but the general gist of it is
ordering; it appears that a `normal-hitnormal` pool exists at point
of query of a new object placement, but does not seem to exist when
entering editor afresh. That said I'm not sure that ordering aspect of
this bug matters much if at all, since the two `IHitSampleInfo`s should
never be allowed to alias with each other at all wrt equality.
Closes https://github.com/ppy/osu/issues/28989.
Because swell ticks are judged manually by their parenting objects,
swell ticks were not given a start time (with the thinking that there
isn't really one *to* give). This tripped up the "judge past objects"
logic in `EditorPlayer`, since it would enumerate all objects
(regardless of nesting) that are prior to current time and mark them as
judged. With all swell ticks having the default start time of 0 they
would get judged more often than not, leading to behaviour weirdness.
To resolve, give swell ticks a *relatively* sane start time equal to
the start time of the swell itself.
Before I go with a hammer to redesign these, I want to remove stuff that
does nothing first.
Hard-breaks API to allow rulesets to specify an enumerable of custom
sections rather than two specific weird ones.
For specific rulesets:
- osu!:
- Stack leniency slider merged into difficulty section.
- osu!taiko:
- Approach rate and circle size sliders removed.
- Colours section removed.
- osu!catch:
- No functional changes.
- osu!mania:
- Special style toggle merged into difficulty section.
- Colours section removed.
Closes https://github.com/ppy/osu/issues/28369.
The reporter of the issue was incorrect; it's not the beat snap grid
that is causing the problem, it's something far stupider than that.
When the current selection changes,
`EditorSelectionHandler.UpdateTernaryStates()` is supposed to update the
state of ternary bindables to reflect the reality of the current
selection. This in turn will fire bindable change callbacks for said
ternary toggles, which heavily use `EditorBeatmap.PerformOnSelection()`.
The thing about that method is that it will attempt to check whether any
changes were actually made to avoid producing empty undo states, *but*
to do this, it must *serialise out the entire beatmap to a stream* and
then *binary equality check that* to determine whether any changes were
actually made:
7b14c77e43/osu.Game/Screens/Edit/EditorChangeHandler.cs (L65-L69)
As goes without saying, this is very expensive and unnecessary, which
leads to stuff like keeping a selection box active while a taiko beatmap
is playing under it dog slow. So to attempt to mitigate that, add
precondition checks to every single ternary callback of this sort to
avoid this serialisation overhead.
And yes, those precondition checks use linq, and that is *still* faster
than not having them.
