Fix osu! stacking not matching stable in very specific edge cases#36056
Fix osu! stacking not matching stable in very specific edge cases#36056bdach merged 6 commits intoppy:masterfrom
Conversation
Closes ppy#36052. Not much more to say here. Until now the `PreEmpt` typing discrepancy has likely gone unnoticed since it's usually only used in visual usages.
|
!diffcalc |
|
1 minute late smh |
|
we were going to run it anyway as a surrogate of checking that this doesn't accidentally break stacking on some other special snowflake ranked map that was depending on the floating point [REDACTED] going the other way |
bdach
left a comment
There was a problem hiding this comment.
if we're already tracking this down I would probably apply the truncation in a few other places:
this one shouldn't have any material effects but maybe? who knows at this point
osu/osu.Game.Rulesets.Osu/OsuRuleset.cs
Line 415 in af290dd
osu/osu.Game.Rulesets.Catch/CatchRuleset.cs
Line 303 in af290dd
these ones are purely visual, probably best to not pretend fractions are involved here when they're not
|
There's also some additional similar cases in |
let's not do that because it's not going to be as simple to handle (the flooring in AR makes it so that you can get multiple different answers when you attempt to take the inverse after flooring) |
|
!diffcalc just for my peace of mind |
bdach
left a comment
There was a problem hiding this comment.
pending diffcalc check
(I posted a wrong comment here earlier then deleted it because I confused myself)
|
I've done a follow-up check on the other beatmaps that the diffcalc run turned up by running conversion mappings. It almost looks good. Unfortunately it's only almost.
From the failures with this PR, /b/1341554, /b/2730824, and /b/4235513 are not regressions (still failing, but less so), so I'd be happy to just dismiss them, merge this as-is, and investigate those as follow-ups. Unfortunately /b/2593923 is an apparent regression and therefore needs further investigation. |
Some are not immediately relevant to the stacking issue because they fail both before and after it, just less so after the stacking issue (half-)fix, and as such have been commented out for the time being.
|
I've pushed a fix for the regressed beatmap. @peppy please check if you're ok with my changes whenever able. In the meantime: !diffcalc The other broken cases I'll look at separately. |
|
The fix looks appropriate, thanks. |
They all pass along with the last stacking threshold fix, so I see no reason to keep them in.
|
Turns out remaining failures from #36056 (comment) are also relevant to stacking code (25ba3f2), so I've just pushed here to hopefully kill this once and for all. Might regret it later. I've canceled the previous diffcalc run, so 🎶 here it goes, here it goes, here it goes again 🎶: !diffcalc |
|
I've gone through the latest sheet and double-checked conversion mappings for the new changed beatmaps, too. Won't lie that I did regret pushing that last change in due to number of maps that needed checking, but the end result looks clean, so as far as I'm concerned, this is good to go. DetailsGenerated mappings: mappings.zip From the pp angle the changes look negligible (at most ±2% swing in worst cases) and I don't particularly care about pp anyway because this is fixing stable-lazer beatmap parsing discrepancies. |
Closes #36052.
Not much more to say here. Until now the
PreEmpttyping discrepancy has likely gone unnoticed since it's usually only used in visual usages.