Closes https://github.com/ppy/osu/issues/32420.
The failure cause here is that in editor the beatmap version for the
beatmap affected (or... any beatmap, really), is 0 (ZERO). That is
probably a regression from https://github.com/ppy/osu/pull/32315, but
like... can we universally agree that calling that change "a regression"
in any capacity is dumb? Like what was that code *doing* playing dumb
reference games and copying stuff into an arbitrary instance that could
get or not get used later on? And now you have a 50/50 chance of
accessing the *correct* model's field, depending on whether you go via
`BeatmapInfo` or `Beatmap.BeatmapInfo`?
Moving the field to `IBeatmap`, i.e. what is by now - by consensus,
since https://github.com/ppy/osu/pull/28473 - supposed to be the "decoded
and materialised" beatmap, fixes this issue.
I probably should have done this as part of
https://github.com/ppy/osu/pull/28473 but it slipped my mind. Probably
for the better too because this change has rather large chances of
breaking stuff so maybe better to examine it in isolation (via diffcalc
runs or whatever).
For added humour points, you'd say that the field on `BeatmapInfo` was
not `[Ignore]`d, so this is a realm schema change, right? No. As far as
I can tell, it's not. I opened realm studio and `BeatmapVersion` *is not
a listed column` on `Beatmap` models.
I'm also not gonna get into the fact that I think `EditorBeatmap` doing
dumb games with juggling two `BeatmapInfo` references since
https://github.com/ppy/osu/pull/15075 is bad, because I don't think I
have the mental capacity to hotfix this by going down that train of
thought.
See previous commit for partial rationale.
There's an argument to be made about the `NaN`-spreading semantics being
desirable because at least something will loudly fail in that case, but
I'm not so sure about that these days. It feels like either way if
`NaN`s are produced, then things are outside of any control, and chances
are the game can probably continue without crashing. And, this move
reduces our dependence on osuTK, which has already been living on
borrowed time for years now and is only awaiting someone brave to go
excise it.
Requested too many times to count.
I'm not sure what to do about the code quality of this. It's a bit weird
that there's no way to check the current composition tool from a higher
level.
Also it was discussed IRL that there should be some kind of hinting that
existing notes will be deleted when they are hovered, but I'm not sure
how well this will work in normal mapping flows, since it will display
even in cases that users aren't intending to delete an object. Still
willing to explore this direction though (it's just non-trivial to
implement so I haven't yet).
Closes https://github.com/ppy/osu/issues/31915.
Reproduction of aforementioned issue requires 1280x720 resolution, which
should also be a good way to confirm that this does anything.
To me this is also equal-parts-bugfix, equal-parts-code-quality PR,
because tell me: what on earth was this code ever doing at
`ComposeBlueprintContainer` level? Nudging by one playfield-space-unit
doesn't even *make sense* in something like taiko or mania.
See
https://discord.com/channels/188630481301012481/1097318920991559880/1334716356582572074.
On `master` this is actually worse and shows thousands of pp points, so
I guess `pp-dev` is a comparable improvement, but still flagrantly
wrong. The reason why `pp-dev` is better is the `speedDeviation == null`
guard at the start of `computeSpeedValue()` which turns off the rest of
the calculation, therefore not exposing the bug where
`relevantTotalDiff` can go negative. I still guarded it in this commit
just for safety's sake given it is clear it can do very wrong stuff.
* 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
See https://github.com/ppy/osu/issues/29720,
https://discord.com/channels/188630481301012481/188630652340404224/1334294048541904906.
This removes the tooltip due to being zero or negative information, and
also changes the description of the setting to not contain the word
"mirror", which will hopefully quash the "this is where I would place a
mirror to my screen to achieve what I want" interpretation which seems
to be a minority interpretation.
The first time this was complained about I figured this was probably a
one guy issue, but now it's happened twice, and I never want to see this
conversation again.