Don’t do that. It’s bad. What if you ran this twice before durationOfSlowingEffect seconds had passed? Then you would be stuck at 4 WalkSpeed forever! Nobody wants that!
No matter how many times you call this kind of function, and no matter how many instances of it you call whenever you call it, your walk speed will always return to the walk speed you were at before, because maths.
I see this way too often! Don’t do WalkSpeed the first way.
If I need it to be compatible with scripts I have no control over (i.e. free models), I’ll typically do this:
walkspeed = newWalkspeed
wait(delay)
if walkspeed == newWalkspeed then
walkspeed = originalWalkspeed
end
If the walkspeed isn’t what I set it to previously, I assume some other script is handling the walkspeed and I leave it alone. [/quote]
I mean, no… no it won’t get interference.
WalkSpeed decreases to 4, two seconds later, it’s increased to 25, then two seconds later, it’s increased to 37 and then 2 seconds later it’s back to 16. There’s “interference” but there’s never a permanent change to your WalkSpeed – it’ll always return to normal. It can also be used uncomplicatedly from multiple scripts without worry.
Oops I added last time. Anyway, even if it always returns to 16, it’d still be bouncing around – if they hit a slow “boost” and then a fast boost, you wouldn’t want them to go 37 instead of 25, even if it were only for a couple seconds. If you were crouching at speed 4 and got up and sprinted to 25, you wouldn’t want players to be running at 37 walkspeed. I’d never want that for any of my games.
This is true, and why it’s typically better to use this method with flat boosts, such as “changeWalkSpeedBy(-7)” or “changeWalkSpeedBy(0.5)” as a percent. The “move to desired walk speed” is really not a good model for any situation, but I used it here for the sake of example.