In-gameplay pp counter is inaccurate when difficulty hit objects are not created for every hit object in a ruleset

Type

Game behaviour

Bug description

This was reported on the performance points discord, with the symptom that the count of hit objects in the beatmap as calculated from OsuDifficultyAttributes was 1 smaller than the count of hit results collected at each judgement. I have confirmed this by breakpointing at this line:

https://github.com/ppy/osu/blob/2d1cc2e5ea820e13028692b729448eed08e6d2de/osu.Game/Screens/Play/HUD/PerformancePointsCounter.cs#L136

and looking at what the state of attrib and scoreProcessor is. attrib will have one object less.

I believe that the reason that this is happening is the following incorrect implicit assumption in DifficultyCalculator in the loop that computes incremental difficulty attributes:

https://github.com/ppy/osu/blob/2d1cc2e5ea820e13028692b729448eed08e6d2de/osu.Game/Rulesets/Difficulty/DifficultyCalculator.cs#L104-L115

By constructing partial beatmaps in this way, DifficultyCalculator is implicitly assuming that each real hitobject has a corresponding difficulty hitobject. But this is not the case, because osu! diffcalc skips the first object and only creates difficulty hitobjects from the second object onwards:

https://github.com/ppy/osu/blob/2d1cc2e5ea820e13028692b729448eed08e6d2de/osu.Game.Rulesets.Osu/Difficulty/OsuDifficultyCalculator.cs#L88-L100

This is not generally easy to fix. One way to fix this in the general case would entail providing some sort of builder object that can receive hitobjects in a stream-like manner, and spit out difficulty objects on-the-fly (or information that one was not constructed because the object is ignored for diffcalc purposes). But this would require new API at best, and substantial restructuring of how the difficulty objects are created at worst.

Another possibility would be to require 1:1 hitobject-difficulty hitobject correspondence, and force pp developers to return ‘ignored’ difficulty objects for hitobjects they don’t care about.

Screenshots or videos

n/a

Version

current master

Logs

n/a

[peppy]

Another possibility would be to require 1:1 hitobject-difficulty hitobject correspondence, and force pp developers to return ‘ignored’ difficulty objects for hitobjects they don’t care about.

Without looking into this too deeply, I agree with this direction to keep things simple. Curious to hear what @smoogipoo thinks.

[apollo-dw]

The suggestion with different skills for each type of nested hit object doesn’t exactly sound easy to manage… I’ve tested nested hit objects in the difficulty hit object loop before and it works as expected for osu!, and I know that the mania folks are also looking into doing it which is why I’m pushing against requiring the 1:1 thing. I could go into the advantages here but they’re essentially summarised by ‘convenience’. I’d be interested in hearing your reasoning against the nested hit objects if you absolutely believe that that should be the use case @smoogipoo

Would a one-to-many relationship here also throw off the pp counter? is my next question. If it doesn’t, then a potential solution in my head is return the ignored difficulty objects (as suggested), and to only add hitobjects to the progressive beatmap if they are /not/ nested.

EDIT: Another big reason why adding nested hit objects to the ODHO list would be good is for reasons of strain: A difficult slider with many repeats and ticks will not be represented properly as one huge strain value with respect to strain decay and strain aggregation