Conversation
stanriders
added
perfcalc-gui
| int relevantResultCount = totalResultCount - countMiss; | ||
| // Relevant result count without misses (normal misses and slider-related misses) | ||
| // We need to exclude them from judgement count so total value will be equal to desired after misses are accounted for | ||
| double relevantResultCount; |
There was a problem hiding this comment.
countSuccessfulHits maybe? similar to https://github.com/ppy/osu/blob/master/osu.Game.Rulesets.Osu/Difficulty/OsuPerformanceCalculator.cs#L499
There was a problem hiding this comment.
Well, it's not "true" count successful hits because in non-CL case it's also weighted
Like it's just a number used for calculations, it doesn't have some objective meaning
There was a problem hiding this comment.
I think it's fine even if its weighted, im mostly concerned with the naming being self-explanatory enough for people to grasp the idea behind all this without too much strain - right now if i see relevantResultCount somewhere down the line it requires scrolling up to read the comment above it to remember what it actually is
There was a problem hiding this comment.
I think renaming it to something like StanR's suggestion is fine, even with it being weighted in mind. The current name doesn't mean anything to me
| double relevantResultCount; | ||
|
|
||
| // If there's no classic slider accuracy - we need to weight circle judgements accordingly | ||
| double normalJudgementWeight = 1.0; |
There was a problem hiding this comment.
I'd also appreciate a comment as to why this exist and why we need to use it
There was a problem hiding this comment.
For example let's assume that map has enough sliders so 10% of the score belongs to sliderends and sliderpoints. In this case we need to compensate for the fact that "circles" (includes sliderheads and spinners) only hold 90% of the influence they would've had in the CL scenario where they're the only type of judgments.
circleJudgementWeight is technically inaccurate (I probably need to fix comment above). This refers to 300s/100s/50s/misses. When "not normal" judgements are slider end hits and big tick hits.
There was a problem hiding this comment.
nonNestedJudgementsWeight then maybe? not really sure what'd be the best naming for this to make it self-explanatory. maybe an explanation comment would be enough, not sure
@tsunyoku any ideas?
There was a problem hiding this comment.
// If this is a score with slider accuracy then we need to compensate for the fact that circles, sliderheads and spinners generally hold less influence compared to classic slider accuracy where nested judgements don't exist.
double nonNestedJudgementWeight = 1.0;something like this?
|
|
||
| int totalResultCount = beatmap.HitObjects.Count; | ||
|
|
||
| int countLargeTicks = beatmap.HitObjects.Sum(obj => obj.NestedHitObjects.Count(x => x is SliderTick or SliderRepeat)); |
There was a problem hiding this comment.
count... is used for hitresults here, so maybe total... instead? preferably for the other usages in this file that already exist as well, to reduce the confusion
There was a problem hiding this comment.
totalLargeTicks doesn't sounds good to me
totalResultCount has "count" in it, and "totalResult" is a descriptor of what kind of count it is
maybe rename to largeTickCount would be better?
|
Right now, if CL is enabled, this calculates stable accuracy, not Lazer+CL accuracy. Wouldn't it make more sense to have it calculate Lazer CL accuracy when CL is enabled? iirc targetting Lazer was preferred instead of stable or introducing some command-line parameter to enable some stable behavior. |
How do you plan calculate stable scores then? Literally nobody is using CL to calculate lazer CL scores. Also lazer CL accuracy never should've had different accuracy from stable anyway, this is a bug if it's truly different. |
I'm not sure, I just figured I'd ask. It is also probably intended, large tick hits and small tick hits (CL-equivalent of slider tail hits) still contribute towards accuracy, specifically this much: Edit: What I had in mind when talking about "targetting Lazer was preferred instead of stable or introducing some command-line parameter" was the discussion about how max combo in mania should work, where stan had stated that Lazers' methology is preferred. (#227 (review)) |
|
If you're interested in having lazer CL work alongside legacy scores, as a post-step, you may want to add the ability to pass a flag that dictates if the given score should be treated as "legacy" and you can do it this way. I'm not going to say that's a requirement for this PR though, you should do that as a follow-up effort. |
tsunyoku
left a comment
tsunyoku
left a comment
There was a problem hiding this comment.
At some point we should probably have a method that is shared across the CLI and GUI projects because maintaining both like this is kinda jank. Problem for later though
4 participants
It doesn't accounts for slider judgements affecting judgements, this PR is fixing this.
It's kinda broken for accuracies below 40% because it can't add slider misses, but it's not very important.