Skip to content
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

Treat misses and sliderbreaks equally in accuracy for osu! difficulty calculations #27690

Open
wants to merge 9 commits into
base: pp-dev
Choose a base branch
from

Conversation

Finadoggie
Copy link
Contributor

Currently, misses and sliderbreaks are generally treated as the same in pp, but misses drop accuracy slightly more than sliderbreaks, leading to misses being slightly more punishing for no real reason. By treating misses as 100s, misses and sliderbreaks will be treated the same in terms of accuracy.

Misses will still be significantly more punishing than 100s or 50s on circles and spinners for obvious reason, this only affects the relation between misses and sliderbreaks

(this makes very little difference on master currently, really only affecting high misscount plays, and matters more for any future PRs which aim to shake up how misses and combo are handled)

Makes sliderbreaks and misses equal
@Finadoggie Finadoggie changed the title Treat misses as 100s for accuracy calculations in osu!std pp Treat misses and sliderbreaks equally in accuracy calculations Mar 22, 2024
@Finadoggie Finadoggie changed the title Treat misses and sliderbreaks equally in accuracy calculations Treat misses and sliderbreaks equally in accuracy for difficulty calculations Mar 22, 2024
@frenzibyte frenzibyte changed the title Treat misses and sliderbreaks equally in accuracy for difficulty calculations Treat misses and sliderbreaks equally in accuracy for osu! difficulty calculations Mar 22, 2024
@frenzibyte frenzibyte requested a review from a team March 22, 2024 02:12
@Finadoggie Finadoggie marked this pull request as draft March 22, 2024 03:18
Someone brought this up during discussion, and from what I can tell, there's no real reason why this wasn't done either.

All this does is use the number of circles instead of the number of objects for accuracy calculations, since circles are the only objects that check for accuracy.

Could also be merged with ppy#27063 to use circles + sliders when sliders check for accuracy (aka when classic mod is disabled). Currently the code for that is included but commented out.
@Finadoggie Finadoggie marked this pull request as ready for review March 22, 2024 06:57
@smoogipoo
Copy link
Contributor

!diffcalc

Copy link

github-actions bot commented Mar 22, 2024

@Finadoggie
Copy link
Contributor Author

It appears I did not account for slider-only maps…

@Finadoggie
Copy link
Contributor Author

might revisit that later, for now I'm just gonna keep this commit to be just the thing that hopefully works

@Finadoggie
Copy link
Contributor Author

!diffcalc

Copy link

github-actions bot commented Mar 23, 2024

@Givikap120
Copy link
Contributor

isn't it's better to just ignore misses when calculating accuracy?
like stat acc is doing

@Finadoggie
Copy link
Contributor Author

Finadoggie commented May 27, 2024

isn't it's better to just ignore misses when calculating accuracy? like stat acc is doing

I chose not to do this since doing that creates scenarios where sliderbreaking is more punishing than missing and I think that’s dumb

In Lazer scores, I would advocate for ignoring misses in acc, I just haven’t gotten around to that yet

@Givikap120
Copy link
Contributor

isn't it's better to just ignore misses when calculating accuracy? like stat acc is doing

I chose not to do this since doing that creates scenarios where sliderbreaking is more punishing than missing and I think that’s dumb

In Lazer scores, I would advocate for ignoring misses in acc, I just haven’t gotten around to that yet

well, you can subtract sliderbreaks from 100s by doing this countOk -= effectiveMisscount - countMiss;

@Finadoggie
Copy link
Contributor Author

gonna close this for now since it's both incredibly minor and superceded by stat acc

@Finadoggie Finadoggie closed this Jul 3, 2024
@stanriders
Copy link
Member

stanriders commented Jul 4, 2024

superceded by stat acc

I don't think this is a good motivation considering stat acc hasn't been anywhere near completion for years. Its not superceding anything until its in a good enough shape

@Givikap120
Copy link
Contributor

superceded by stat acc

I don't think this is a good motivation considering stat acc hasn't been anywhere near completion for years. Its not superceding anything until its in a good enough shape

stat acc is practically ready

@Finadoggie
Copy link
Contributor Author

Finadoggie commented Jul 4, 2024

reopening this cause I didn’t realize it was pending deploy

(I was under the impression that it was awaiting review, and thought it just wasn’t worth the resources with how minor it is)

((it still vanishes once stat acc is implemented))

edit: wait I'm stupid, closing it apparently changed its status on the project lol

@Finadoggie Finadoggie reopened this Jul 4, 2024
Finadoggie and others added 4 commits November 8, 2024 15:52
Someone brought this up during discussion, and from what I can tell, there's no real reason why this wasn't done either.

All this does is use the number of circles instead of the number of objects for accuracy calculations, since circles are the only objects that check for accuracy.

Could also be merged with ppy#27063 to use circles + sliders when sliders check for accuracy (aka when classic mod is disabled). Currently the code for that is included but commented out.
# Conflicts:
#	osu.Game.Rulesets.Osu/Difficulty/OsuPerformanceCalculator.cs
why does merging have to be so difficult
@Finadoggie
Copy link
Contributor Author

Updated to the most recent deploy

...and apparently added 2000 commits 😭

@pull-request-size pull-request-size bot added size/S and removed size/XS labels Nov 9, 2024
@Finadoggie
Copy link
Contributor Author

oh ok I fixed it

@Finadoggie
Copy link
Contributor Author

@tsunyoku couple questions since I know you have something that relies on this branch:

  1. Should I be accounting for lazer's slider tick/tail score data for accuracy calculations? If so, what's the proper formula for calculating accuracy with slider ticks and tails? Would there be a potential need for accuracy with slider data in some places and accuracy without slider data in other places?
  2. Are there any specific things you need/want me to do for this branch?

@smoogipoo smoogipoo changed the base branch from master to pp-dev December 18, 2024 14:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Pending Review
Development

Successfully merging this pull request may close these issues.

5 participants