ppy
Remove estimations where score data is available for osu! difficulty calculations
This PR replaces estimations with score data where applicable for Lazer scores. More specifically, it…
- Removes estimations for sliderbreaks
- Removes estimations for sliderend drops
=== original post === (contains outdated info)
On non-CL lazer scores, extra slider data means certain estimations are no longer required.
For effective miss count, HitResults.Miss + HitResults.LargeTickMiss is used.
For sliderends dropped, HitResults.SmallTickMiss is used.
To my understanding, LargeTickMiss includes slider ticks and reverse arrows, the two parts that can break your combo, while SmallTickMiss is for sliderends. Please correct me if I am wrong.
I am not sure the "available" score data in question can be used. We've previously expressed worry that this was going to spiral into two separate implementations of pp for classic and non-classic scores.
My bad, I was not aware of these conversations. Could you drop a link to them so I can read through them?
Stan's decision of splitting the calculator into 2 parts for classic and non-classic is a direction I personally dislike, and the way Fina is doing it here is the way I would approach it myself. I don't see any harm in using the new metrics, and PP spiraling into 2 calculators should only happen if per note judgements ever become available, and prove to give much better results than without them. These new metrics are easily estimable, and the existing estimations can just be made harsher if they prove to give an advantage to stable scores.
Why is this only using additional data if slideracc enabled? Lazer scores with CL mods also have additional data that should be used to get more accurate result.
The implications of a change like this are massive. If I set scores with sliderbreaks, I will only ever be punished more on lazer than I would be if I played on stable. I play on lazer as my main client, but a change like this on its own would make me consider moving back to stable because I don't want to play with something like this that is just a clear disadvantage. You could try tuning the estimations for stable scores to be more harsh, but I doubt people would be happy with that and I'm honestly not sure if that's even possible. The complexity to balance this kind of change is so high that I don't think it's worth the trouble to begin with.
@Flamiii you’re already at an objective disadvantage if you play on lazer. This arguably helps you since it means miss estimations can no longer assume you may have sliderbroke where you didn’t. Any non-cl 1 miss plays where the break was in the middle are buffed. Same for plays on hard slider maps where you broke but didn’t drop any sliderends.
If by "objective disadvantage" you mean slideracc, I play on lazer because I'm certain that will be taken into account in the future (#27063). The scenario I'm thinking of which happens quite a bit is the one where a player misses near the end of a map but also sliderbreaks 2 times afterwards. In stable, this play is counted as a 1 miss and the sliderbreaks only negatively impact your accuracy. With these changes in lazer, this play would be treated as if it was a 3 miss. As far as I know, there really isn't a way to adjust stable's estimation to make this scenario balanced because the relevant information just isn't there. There are some situations where you're punished a bit less, but the scenario I mentioned is extremely common and you would be punished way more for playing on lazer with these changes.
Edit: It's also worth noting that using HitResults.LargeTickMiss to increase the effective miss count means that missing buzz sliders or any fast sliders with many sliderticks will be incredibly punishing. For example, misaiming a buzz slider with 5 repeats and missing it entirely would increase the effective miss count by 6, which would basically kill any score.
there really isn't a way to adjust stable's estimation
There actually is a way, if you take a look at the function in question, we could, for example, lower fullComboThreshold to make it assume there were more misses than before, and if you look at the changes in this pr, this function is only used if CL with slideracc is on.
misaiming a buzz slider with 5 repeats ... would basically kill any score
This is a valid point, however, I can assure you that future work will be done to account for this.
There actually is a way, if you take a look at the function in question, we could, for example, lower fullComboThreshold to make it assume there were more misses than before, and if you look at the changes in this pr, this function is only used if CL with slideracc is on.
I see. As long as these changes are balanced properly, I have no issues with them.
The scenario I'm thinking of which happens quite a bit is the one where a player misses near the end of a map but also sliderbreaks 2 times afterwards.
Ok but again this is already a thing. Sliderbreaks by missing the slider head are already counted as misses in lazer, so this scenario can already happen without any pp changes.
It's also worth noting that using HitResults.LargeTickMiss to increase the effective miss count means that missing buzz sliders or any fast sliders with many sliderticks will be incredibly punishing. For example, misaiming a buzz slider with 5 repeats and missing it entirely would increase the effective miss count by 6, which would basically kill any score.
I know, I'm more apprehensive about that part and wanted to spark discussion for that specifically. Also buzz sliders are a lot more forgiving in lazer anyways so a late tap leading to complete score annihilation isn't something I'm worried about.
The crux of the matter is, some scores will be punished by being unable to slip through the cracks. That's inevitable. The gain of scores no longer being undeservingly punished from estimations counteracts this and, at least in my personal opinion, is a fair trade off.
Actually, new score data can allow using 3 types of aim instead of 2:
- Only notes
- Notes + LargeSliderTicks (reverses and sliderpoints)
- Notes + LargeSliderTicks + SliderEnds
This will make slider judgements even more accurate. But it's out of scope of this PR
I think we can add a bool useSliderHead
Because we are likely to use this value frequently in future
like taiko's isConvert
https://github.com/ppy/osu/blob/15d286e57d8acc9d3967b63857c2cb0bfa283230/osu.Game.Rulesets.Taiko/Difficulty/TaikoPerformanceCalculator.cs#L45
useSliderHead is used for sliderend stuffs to ensure compliance with this statement from ppy
For future notice: yes, this quote is in direct regards to pp.
Also please update the op because I got really confused by what am I even looking at at first
Also please update the op because I got really confused by what am I even looking at at first
done, new one should be far less confusing
@Finadoggie for my own understanding while I try to trample through these changes, do your changes account for CL (on default configuration, which matches stable and doesn't have slider head accuracy) being 1:1 with stable?
