-
-
Notifications
You must be signed in to change notification settings - Fork 2.4k
Use proportion of difficult sliders to better estimate sliderbreaks on classic accuracy scores #31234
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use proportion of difficult sliders to better estimate sliderbreaks on classic accuracy scores #31234
Conversation
6ac1067
to
b259e8d
Compare
I've updated this branch to the latest |
!diffcalc |
Difficulty calculation failed: https://github.com/ppy/osu/actions/runs/14682429178 |
c376097
to
ceda902
Compare
61da19c
to
6ac1067
Compare
6ac1067
to
4c08c14
Compare
4c08c14
to
9dacc57
Compare
9dacc57
to
1bbb3f9
Compare
I've fixed up the compilation errors caused by dodgy rebases/merging. Please be careful with pushing your changes up in future. |
!diffcalc |
Difficulty calculation failed: https://github.com/ppy/osu/actions/runs/14774814568 |
!diffcalc |
!diffcalc |
!diffcalc |
!diffcalc |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Still kinda hate this solution, but we don't really have any alternatives (except nuking stable) so it'll do
Works out individual top weighted strain count for hitcircles and sliders, and then multiplies countmiss by 1 + the proportion of top weighted strain on sliders to account for misses on sliders sliderbreaks. This assumes that the player breaks equally on difficult hitcircles and sliders, which is the most fair assumption in my opinion.
The number of sliderbreaks is then scaled with combo, to account for the fact that higher combo scores have less places for sliderbreaks to hide in.
Spinners are handled incorrectly (they're included in the hitcircle strain count) but because spinners are 0 difficulty anyways there is negligible values impact, so making a better solution would probably be more effort than it's worth.
TopWeightedSliderFactor
may be infinity on maps with no circles. This doesn't have any adverse values effects, becauseestimatedSliderbreaks
is capped atcountMeh + countOk
, but I'm unsure if it's going to cause any other weirdness.This probably wants some form of miss penalty or
effectiveMissCount
adjustment, because currently every affected score is losing.Sliderbreaks may be double dipped, as it uses
effectiveMisscount + estimatedSliderbreaks
, whileeffectiveMissCount
may already contain some estimated sliderbreaks. I'm not really sure of a good way to resolve this, and a little doubtful that resolving it would have any significant effect.