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

Spinner "clear bonus" doesn't increment score when set to "classic" display mode #17011

Closed
peppy opened this issue Feb 27, 2022 Discussed in #17007 · 9 comments · Fixed by #24924
Closed

Spinner "clear bonus" doesn't increment score when set to "classic" display mode #17011

peppy opened this issue Feb 27, 2022 Discussed in #17007 · 9 comments · Fixed by #24924
Labels
area:gameplay priority:1 Very important. Feels bad without fix. Affects the majority of users.

Comments

@peppy
Copy link
Sponsor Member

peppy commented Feb 27, 2022

Likely needs some special case logic applied to the algorithm to handle this.

Discussed in #17007

Originally posted by Moltanicaa February 27, 2022
After the last update that changed the scoring method, when using the classic scoring system, the spinner (especially the first one) does not score points at all. Neither bonus, nor for the object itself.
osu_2022-02-27_10-56-39

The second screenshot after the end of the spinner, for clarity
osu_2022-02-27_10-56-51

@peppy peppy added priority:0 Showstopper. Critical to the next release. area:gameplay labels Feb 27, 2022
@bdach
Copy link
Collaborator

bdach commented Feb 27, 2022

This is not very easy to fix. The score is not actually 0, it's a small number that gets rounded down to 0. And that's because the spinner is worth so little at the beginning with the way classic works now (by squaring the standardised score divided by 1M), that the resulting score is that small.

You could exclude bonus points from the standardised score, calculate classic score without bonus, and then add bonus points back, but this potentially breaks the condition that standardised and classic modes should always preserve score order. Because depending on the count of objects the weight of the bonus points relative to normal objects would change in classic.

About the only thing I can think of is to adjust the squaring that is done to not be so harsh at the beginning of the map, like so (warning: not meant as a serious proposal, but more of a demonstration of an idea - I have not ran any numbers on actual scores):

                    double standardised = GetScore(ScoringMode.Standardised, accuracyRatio, comboRatio, statistics);
                    return (0.95 * Math.Pow(standardised / max_score * totalHitObjects, 2) + 0.05 * standardised) * 36;

Mathematically sepaking any other increasing function of the standardised score would work there that has the desired characteristics that classic generally is looking for. The above would amount to a polynomial of:

f(x) = 0.95(x / 1 000 000)2 + 0.05x

which is a strictly increasing function when x is positive.

@WitherFlower
Copy link

I'd like to mention that adding a small linear component to the scaling function (the 0.05x here) would actually make classic scoring closer to scorev1.
This linear behavior is present in scorev1 in the form of every note giving you its hit value as a flat score increase.

If this is to be considered, the 0.95 and 0.05 coefficients could be scaled based on the number of hitobjects to get even closer to the scorev1 rate of increase.

@smoogipoo
Copy link
Contributor

This doesn't need priority 0, but the above proposal looks promising.

@smoogipoo smoogipoo added priority:1 Very important. Feels bad without fix. Affects the majority of users. and removed priority:0 Showstopper. Critical to the next release. labels Feb 28, 2022
@WitherFlower
Copy link

After doing some investigation, it seems that the glitch is caused by the calculation of the number of total hitobjects.

Right now we are just counting the number of hits of the score, however when you're playing this number starts at 0 and increases with each hit, where it should in fact be equal to the total from the start.

This means that classic scoring, right now, has a cubic rate of increase instead of quadratic, and this is why the first hitobjects give 0 score.

@bdach
Copy link
Collaborator

bdach commented Feb 28, 2022

I entirely missed the fact that the hit object count was based on the sum of judgement counts from statistics. Which is indeed completely wrong until the map has completed.

@bdach
Copy link
Collaborator

bdach commented Mar 20, 2022

#17164 has fixed the cubic rate of ascent issue, but #17011 (comment) is still an issue - so I guess this is technically "resolved" but possibly the behaviour is still not as users expect it to be...

@smoogipoo
Copy link
Contributor

Yep, that's why I didn't close this issue just yet. Probably still want to do something similar to the above proposal, though I don't know the state of it after #17164.

@0xallie
Copy link

0xallie commented Jul 15, 2023

I'm posting here because it seems relevant.

On stable, autoplay gets 447,100 points on Spinner Training by spinner boi, while on lazer it gets 3,746 points with score display set to classic and classic mod enabled (though the latter doesn't seem to make a difference). Of course it is not exclusive to autoplay, non-auto scores are also significantly lower than stable.

@bdach
Copy link
Collaborator

bdach commented Jul 15, 2023

@0xallie classic mode != stable scorev1. classic mode never was - and likely never will be - the same as stable scorev1.

classic mode is mostly a transformation derived from standardised score which is supposed to make scores be in the same ballpark as stable scorev1. of course that may need revisiting after standardised score changes (#23763), but it will never be exactly the same across all maps. we cannot support two disparate scoring systems going forward.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:gameplay priority:1 Very important. Feels bad without fix. Affects the majority of users.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants