ppy
Implement new "Aim Error" statistic and display it on the results screen
Prereqs:
- https://github.com/ppy/osu/pull/27064
Implements an aim equivalent to the Unstable Rate value, using the measured aim deviation multiplied by 10.
Things to note:
- Units are in osu! pixels. Aim Error is multiplied by 10 to match unstable rate better.
- The offset from center value is calculated assuming a normalized angle, similar to the aim error chart. This felt more intuitive to me. Since the chart is easily visible, I felt there was no need to have it in text saying which direction from the center is it offset.
- I grouped the unstable rate value with the hit error graph, as it looked a bit wrong having each graph be separate from its corresponding value when this was added. Can be reverted if need be. Same with renaming Statistics to Timing Statistics.
Sorry, I accidentally hit the enter key while writing the title and there's no confirmation menu for creating a pull request I guess.
Although there is an offset from center value, the aim deviation is calculated assuming the mean hit error is in the center.
If I'm understanding this correctly, this does not match unstable rate, where you can have 0 ur by being consistently n ms late. In my opinion, if this is to become a standardized statistic, it should agree with unstable rate and be based off the distance from the average aim location.
Misses are accounted for using the Rayleigh distribution, since the location in which a miss was tapped is not available.
does this match how ur deals with misses? I think ur is the stddev of hit errors without considering misses at all, but I could be wrong. I'm indifferent to whether we consider misses, but I think the two metrics should agree on this count, similar to above.
If I'm understanding this correctly, this does not match unstable rate, where you can have 0 ur by being consistently n ms late. In my opinion, if this is to become a standardized statistic, it should agree with unstable rate and be based off the distance from the average aim location.
Indeed it does not. A more complicated method of determining miss variance would have to be implemented for this to be feasible, but I can look into it for sure if this is the desired route.
does this match how ur deals with misses? I think ur is the stddev of hit errors without considering misses at all, but I could be wrong. I'm indifferent to whether we consider misses, but I think the two metrics should agree on this count, similar to above.
This also does not match how UR works, yeah. Not including misses causes the problem though where scores with many misses don't increase very much even for absurd differences in actual aim error. This isn't a problem with unstable rate since tapping has multiple hit windows, lenient enough that even OD11 plays rarely have mistaps land outside of the 50 window. However, aiming only has 2 "windows" - hit and miss. This is why I think aim error should include misses, while it's not necessary for unstable rate to do the same.
Hello, was reminded of this because I have been finding utility in a statistic like this again, and was wondering if it's simple enough to get in game sooner or later. If there's anything I can do to make this easier to review let me know, I do hope it's in a pretty decent shape already though because it's mostly copy pasted from the UR statistic.
@peppy would like a "do we even want this" check from you on this before I spend even the customary 15min
I like this but:
I would either group it with the hit statistics (with a more fitting heading):
and probably call it
Unstable rate (hit) and Unstable rate (aim) to help the user understand that they are both similar in meaning.
Or i'd move the statistics into each relevant box:
and just call each one
Unstable rate
Will try implementing the second suggestion when I wake up tomorrow. Just confirming, the change to merge UR with the hit/aim timings seems like it would apply to all modes, is that fine?
Only implemented the merging in standard because it turns out it was less invasive to do than I thought, can make a follow-up PR for the other modes or something to make it consistent if you want.