Overall future direction for calculating pp

[GoldenMine0502]

Existing structure is not great
A comment of another player:
In the current pp system, we measure 'aim,' 'speed,' 'acc,' and 'flashlight' independently, and the problem arises here; the parts where 'aim' and 'speed' are mixed at a considerable level together, cannot be properly measured. (i.g. tech parts)
We can think of A and B maps. A map has hard jumps in the front part and hard streams in the last part. The jumps and streams of the B map themselves are a little easier than the ones of the A map, but they appear simultaneously. So the overall difficulty we feel in the B map would be higher than the one in the A map.
The point is, in the current system, the measured difficulty of the A map could be similar to what we feel, but the one of the B map would be much lower level to what we feel. We can't consider the synergistic effect that increases the actual difficulty when two ( or more ) elements are mixed now. I want to say this is because the 'aim' and 'speed' are measured independently. When relatively measured, we can alleviate this to some extent.

Because all skills (including unimplemented) have systematic relations.

How do you think about 150bpm notes? is it jump? or stream?
We couldn't answer this problem in detail definitely.

For example,
Speedy jump patterns exist. (400bpm jump)
Patterns which contain half speed and half jump exist. (i.g. alternative)
But we couldn't calculate those precisely.

As a result, we should rely on graph, and establish standard for calculating which patterns give same pp/strain/difficulty.
For example,
We choose distances giving same pp on specific bpm.
like when bpm is 100, 100px,
when bpm is 110...
bpm is 120..
130..
140..
when bpm is 150, 40px,
...
when bpm is 200, 20px... etc

After these, we could establish final graph fit to (distance/strainTime) multiplier. (simplified explanation but i believe you understand)
this will be our main work we should do for calculating aim precisely.
In this situation, speed should calculate only speedy thing (not use distance). because fast bpm stacked notes are hard.
and We will combine aim and speed.

This is result direction. I will show you that we could buff tech easily if you accept.

I agree my refactoring is not perfect
(about #15485)
idk how osuteam think.
Aim and Speed classes have been being bigger. The classes now have a lot of lines.

In future, We will meet cases applying to both Aim and Speed.
We will meet cases to calculate small total strain (for example, calculating only slider strain or angle variance strain below).
or you may find other complex thing.
So I think we should separate big code to small to work easily.

I contain ProcessInternal() on Aim and Speed class. i think its not good solution. agreed.
But we have a lot of new solution. maybe osuteam know. if you dont know, i will introduce about it.

Why we should have new class
In my PR, to get previous specific skill strain per note, i used new class.

Why?
I should calculate "frequency" which gives ours how hard patterns arise.
I give straindecaybase big multiplier, and calculating value small multiplier.

For example, just one note from acute to obtuse isn't too hard. (angle variance)
But patterns changing acute and obtuse frequently are really hard.
Next pattern is hard because of this.
https://osu.ppy.sh/beatmapsets/1357624#osu/2809623

https://osu.ppy.sh/beatmapsets/405011#osu/880496

in this context, We could apply this to same paragraph, slider variance.
changing slider velocity frequently is really hard.

last opinion
i have a lot of idea for calculating tech.
but because i cant be sure these changes will apply at least one... so I don't have courage to write next thing.

[smoogipoo]

How much do you want to share between Speed and Aim? For example, could this be handled by ordering the skills such that Speed is before Aim, and then passing the Speed skill into Aim (via constructor) and using the strain from it at the current point in time?
And, if the Aim skill needs only some part of the Speed skill, could that be exposed as required?
Of course, this doesn't work if the two skills become dependent on each other, but I'm not convinced that's a valid thing to do anyway - the dependent part of the skills need to be split out somehow at that point (read below).

I think we can't have Skills processing other skills, and I don't think explicit "pre-skills" as in the original PR is required to achieve what you want. What if you have a pre-skill which needs some calculation from another pre-skill, do we then need to have pre-pre-skills? Or is that the arbitrary limit we set and why?

BPM is probably a bad example because it isn't a complex calculation, but one other thing to consider is extracting that calculation to an object which is common to both. For example let's suppose that BPM was hard to calculate, I would rather extract that into a helper class like BPMStrainCalculator completely separate from the Skill class hierarchy, to serve that single purpose of calculating BPM strain.
#15010 sort of goes in this direction by splitting out the decay and peaks calculation into a separate class. In a way this is also currently done by OsuDifficultyHitObject for things like JumpDistance, but I wouldn't want that class to expand indefinitely.

[GoldenMine0502]

Yes in current structure(hierarchy), we can get current strain in other classes.
But the reason why i created new class is mainly for getting previous strain.

I realized we couldn't get the previous strain in current structure.
I tried accessing strainPeaks property on Skill, but the size(number) of the original strainPeaks and beatmap hitObjects is different.
As a result, the difference of my PreStrainSkill and original Skill is only the way of storing values in strainPeaks.

For example, AimVelocity referencing previous strain in my PR.

And we don't need to create pre-pre-skill because pre-skill(PreStrainSkill) act like also pre-pre-skill as well as pre-pre-pre-skill.

I'm trying to get precise share rate using statistical method. I got 100000 replays and I'm analyzing the replays but this is really big work.
Honestly, I have lack of work, data, or etc. Osuteam would find the problem solution easily than me.

I think your BPMCalculator is nice. This calculator would work without preskill.

[smoogipoo]

Okay, so your intention is to be able to get the strain of any arbitrary object from another skill? So for example RhythmSkill.StrainOf(myHitObject).

Maybe a different structure here that works alongside Skill, which is similar to Skill except it doesn't have Process and the whole notion of sections, and instead just one method to get the difficulty of an object. It would be a dumb stateless object that doesn't have the complexity of the Skill hierarchy and does not participate via CreateSkills().

Unless, you also need sections (the decayed strain) for some reason?

This would require the notion of History to not exist inside Skill, which I have successfully attempted to do in a branch.
From this, for example, #16260 would be split into two files: a RhythmDifficultyEvaluator which does the calculations resulting in the rhythmBonus variable, and a Rhythm skill class which makes use of RhythmDifficultyEvaluator to result in the continuous strain calculation that ends up in OsuDifficultyAttributes.

Thoughts? Also @stanriders?

[stanriders]

Idea of splitting calculation into raw difficulty evaluation and strain processing sounds nice. Current skill structure doesn't require processed strains so it should be okay, although it feels like we might need it too, but I can't remember where and why so for now it should be more than enough. I believe it should also make #14934 easier to implement.

[GoldenMine0502]

I agree the discussion.

We should start to discuss how to construct the system more clearly.

My PR is now in progress(not finished). I hope my work would be a good example.

[akivn]

I have been thinking about this for a while as well, but based on my experience of playing and idea from the original poster, I would suggest building a new difficulty factor called "Skill", addressed solely for technical maps (alt/tech).

My idea of the "Skill" calculation will be based on these factors:

1. Flow and Aim variation

This is based on how much the aim angle and real aim (jump-distance)/lazy aim changes throughout the map.
The non-reflex angle ("angle value") will be calculated in this case.

Situations like the first image shown on the original post (https://osu.ppy.sh/beatmapsets/1357624#osu/2809623) where there is big variation in short succession will be massively buffed due to this.

This factor will be based on how much the "angle value" changes and how fast these jumps are, and also how much variation of lazy path and jump distance changes. For the variation of jump distances, a "jumpVariation" pattern can be set up, where it is based on a weighted average of lazy aim and real aim distances.
Super-small jumps with a higher degree of overlaps will be valued less, slowly but exponentially increasing from a very low value in completely overlapped cases to 1x in completely separated cases. The multiplier calculation for both of the jumps will be calculated as well. Stacks will also be calculated as completely overlapped cases just like how the current pp system (and also the new rework) works.

This factor is also scaled by how fast the jumps are. Slower jumps at 150-200ms (150-200bpm) gets less valuable, while this scales up as jumps become faster, massively increasing after a certain value (e.g. 90-100ms) where alts gradually turns into tech.

e.g. https://osu.ppy.sh/beatmapsets/2074198#osu/4341639 - pattern buffed significantly

The pattern is a constant change of angles. It also consists of some variation of spacings (as well as lazy aim), so despite some jumps are being nerfed by small spacing the high jump density (185bpm 1/4s) and large variation inside a single strain gives a very high multiplier.

2. Slider Velocity and Length

Kicksliders (which is lazy aim = 0) has a difficulty of zero and does not make a difference in terms of SR (or even lower), yet tech is abusing them to make different difficulty spikes and intensity parts.

This factor will account the real slider movement and the lazy aim (weighted, with lazy aim > slider movement) - once the slider has a length over a certain value there will be a buff towards the "Skill" component. If the lazy aim component ≠ 0, or the slider has high slider velocity, the buff will be much more significant. This might also fix slider jumps in generic maps giving less pp and lower SR than normal jumps.

e.g. https://osu.ppy.sh/beatmapsets/1889729#osu/3912664
Maps with long and fast sliders (mostly alternating / tech) with be buffed by this component as well, such as this featuring generic alternating patterns and sliders.

The above two factors should cover most, if not all, alt / tech maps.

The "Skill" component can be separate from the current "Aim" / "Speed" / "Strain" (which fulfills the idea of the original suggestion) and the SR from skill can be directly addictive towards the final SR (and nerfing the base multiplier for the other two components to balance out). This keeps the current component mostly untouched which is much easier to work on with. I am not sure about where is the sweet point of the weighting between the two points above, but it might be worth a try to do this despite the need to build a new component from scratch. (Sorry for a dead post reply, hope you don't mind)

[GoldenMine0502]

so old. i close this