While it is the case for the existing official Skills, Skill implementations shouldn't be required to conform to a strain based approach.
There are other valid approaches to calculating skill difficulty that can be supported by abstracting the strain logic into its own StrainSkill class.
As strains are an implementation detail of the current Skill calculations, it makes sense that strain related logic should be encapsulated within the Skill class.
In catch, rate adjustment mods do not only affect the timings of hitobjects, but also the speed of the player's catcher.
This catcher speed change has an impact on difficulty which is currently accounted for by using the clockrate directly in calculations.
Semantically this is a bad idea because clockrate adjustments are supposed to be fully accounted for in DifficultyHitObjects, but passing clockrate here for the purpose of being used as catcher speed doesn't make much sense, especially since it is copied in every DifficultyHitObject despite being the same value.
It makes more sense to account for this catch specific impact by handling rate adjustment mods in a catch specific way, or more specifically in a Movement skill specific way.
Although this isn't necessary for existing official rulesets and calculators, custom calculators can have use cases for accessing mods in difficulty calculation.
For example, accounting for the effects of visual mods.
There were two coordinate systems used:
- 0..512 (used in osu!stable)
- 0..1 (relative coordinate)
This commit replaces the usage of
the relative coordinate system to
the coordinate system of 0..512.
