Improve SklSpdRate usage and application

[Terotrous]

This stat effectively seems to function similarly to attack speed, where it speeds up your attack animations, but currently none of our skill handlers account for this. Do we need to create a method to auto-adjust your delay calls using this value?

[exectails]

That's a very good question. There aren't that many skills that are affected by the speed rate data, but they do exist, so the answer is most likely yes. We could technically include them only in the skills that need them, but since it's based on easily editable data, we should certainly consider including it in all of them. Though we'd want to add a simpler way to get and calculate them than what we did in the melee ground handler.

[Terotrous]

How do we know which ones are affected by it? Does the description mention it?

[exectails]

By default, SklSpdRate is potentially affected by three things: the skill's speed rate, dex, and buffs, though the latter two only if the respective toggles in the skill data are on. So if a skill has a speed rate of 1 (no change) and both speedRateAffectedByDex and speedRateAffectedByBuff are false, the skill doesn't need the speed rate adjustment, unless someone modifies the values. In total there are ~150 skills currently using this.

[exectails]

Reading and thinking about this issue again, I'm not sure how much sense it would really make to go out of our way to add this to all skills, regardless of whether the skill data is modifiable or not. The reason is that most skills will presumably not be affected either way.

Unlike normal attacks, a skill like Bash for example has a fixed animation delay and a fixed overheat count. Modifying the delays doesn't change how quickly you can bash, and even if it did, you're hard-capped on the number of bashes you can do in quick succession. It doesn't really need this, and I suspect this to be the case for most skills.

That being said, if we were to refactor how these delays are set up and calculated, to make it more concise and reusable, we might as well make it a convention to use those hypothetical functions in all handlers, just in case. I will leave this issue open for such a potential improvement.

[exectails]

For some more context, this is what the relevant code for normal attacks currently looks like.

var damageDelay = TimeSpan.FromMilliseconds(skill.Id != SkillId.Common_DaggerAries ? 330 : 250);
var skillHitDelay = skill.Properties.HitDelay;

damageDelay /= skill.Properties.GetFloat(PropertyName.SklSpdRate);
skillHitDelay /= skill.Properties.GetFloat(PropertyName.SklSpdRate);

We would probably want to move this into reusable functions that take base values and apply the rate as appropriate. We might also look into where these base values come from, instead of hardcoding them like above.