@artainx alright that's fine, just wanted to see if the animation preview limits were actual animation speed limits or just interface limits. Forget that part of it.
First and foremost, what kind of game are you making? What I am suggesting might be heavy handed for you, but if it's common or likely that the player might be effected by multiple move speed effects simultaneously, I would do it like I am outlining below.
Make your movement speed a status value. Have your status effect apply bonuses or penalties to that value (probably by percentage). Set up a formula that converts that status value to the actual speed of your character. Example - maybe your movement speed is the time it takes to move one unit in Unity. So if your base move speed is 5, your move speed is 0.2 (since a speed of 5 means 5 units/second). I don't think you can put in 0.2 as a value for a status value, so you will have to put in 2 and in the formula divide it by 10 to get the actual value.
Set up a formula for your movement animations that converts that speed into an animation scalar (the formula will depend on how you set up your movement speed). Instead of picking value in the animation speed section, choose formula and select your formula.
This should scale the speed of your movement animations in line with the scaling of your actual movement speed without requiring you to override your animations in every status effect.
I know it's a fair bit to take in. I am going to be doing this in my own game, probably tonight after work. When it is done I can try and detail how I did it.
If you don't want to do any of this, I think you need to look more into how you set up your animations. If they aren't playings it's likely because ORK can't find them to play them. I do want to reiterate that your approach might be a kluge if you have several status effects that modify speed at the same time. Which one will win the animation override war? That might be neatly handled by ORK, but I would be surprised.
