Wondering if anyone else has noticed this. Not sure if we’re just not meant to change WalkSpeed locally anymore at all. Essentially, it’s inconsistent, but changing the WalkSpeed locally while the player is moving causes the walking/running animation to trip over itself so to speak, seemingly looping incompletely. Making another core animation play over the walking/running animation by jumping, or ceasing movement, for example, temporarily fixes it, but when the WalkSpeed is again changed the issue has a chance of reappearing. However, I wanted to change movement locally to avoid client-side delay, and this pesky “newish” issue rose up. I take long breaks, but this wasn’t a problem ~6 months ago.
Here’s the only relevant script running (LocalScript within StarterCharacterScripts), so you can hopefully replicate the behavior if need be:
local plr = game.Players.LocalPlayer
local char = plr.Character
local hum = char:WaitForChild("Humanoid")
local animator = hum:WaitForChild("Animator")
local changed = false
local c = 1
while true do
wait(3)
if hum then
print("==========================")
print("RUN " .. c)
for i,v in pairs(hum.Animator:GetPlayingAnimationTracks()) do
print(v,v.Name,v.Animation.AnimationId)
end
print("--")
if changed then
hum.WalkSpeed = 10
else
hum.WalkSpeed = 40
end
changed = not changed
c = c + 1
end
end
This is intentional and occurs because of animation blending from the Animate script. R15 characters have both a running and walking animation in a movement set, the latter of which is only supported on mobile and console devices as a result of the thumbstick delta. When moving a thumbstick slightly the character will walk slower and therefore trigger the walk animation. Keyboards have no concept of a slight press. This is not a new thing.
I’m not using a thumbstick here, and I understand what the “walk” animation is used for. This is a new thing, because it wasn’t present before. This doesn’t look like blending; it looks like animation confusion.
No, it is animation blending between the run and the walk animation. Check the source of the Animate script for that. Specifically when the Humanoid moves slower it starts playing the walking animation. The slower you are, the heavier the weighting of the walk animation becomes.
As for my reference to thumbsticks, the implication to be made here is that because devices with thumbsticks are capable of moving slightly, this exists. The Animate script plays the walking animation when the character is slower; thumbsticks can make the character move slower.
I understand. The issue is that it’s inconsistent. If it were what you’re saying, it would occur consistently, like it always has in the past. I understand weight is changed with WalkSpeed–it was something I was exploiting, in fact. But this is different.
Oh, I see. I had another look at the video - is the inconsistency you’re bringing up related to the blend seemingly being nonexistent after you jump? Threw the code into Studio to try and repro. Strangely enough for me it actually ended up consistent but behaved differently because I had a bundle on. With a bundle the blend was a lot more crude and without a bundle it was better. Is the first one what you’re trying to avoid and looking for it always to be the second? Video below.
It definitely doesn’t have anything to do with you changing WalkSpeed locally, where you’re changing it from is irrelevant. The Animate script is managing the weighting of the run and walk animations based on the speed argument from the Running event so if there was a problem it’d be specific to how the Animate script is handling weighting. Could be related to other features you’ve missed though.
How new is your game environment and have you made any changes, specifically in the sense of using any beta features or enabling non-defaults in Workspace?
Weird as it may sound but worth noting that according to documentation and the behaviour of weighting the “tripping” movement is the intended behaviour/how you’re supposed to look when you’re moving slower, not the latter - that case looks like it’s not playing the walk animation at all, only the run animation with a lower speed.
Yes, I’m trying to avoid the first instance. I thought something might have been up with my game (for example, I thought it was related to the deprecation of Humanoid:LoadAnimation, but it wasn’t). That’s why I tried it on a blank slate game and I still managed to get the same behavior. I don’t doubt it has something to do with the Animate script: I was just hoping to get something more concrete in terms of cause and effect. Months ago, what would happen is the animation would play more slowly, but the actual blending didn’t become noticeable until you were at WalkSpeed values of around 5 or lower. Now, on the other hand, it appears jagged, in my opinion, and is noticeable at much higher WalkSpeed values–if it is blending related.
Overall, what I’d like to achieve is getting players to move more slowly by default, and having the “walk” animation be the default, rather than the “run” animation. I may have to resort to forking the Animate script, which I wanted to avoid.
Can’t seem to find any Animation or Motor6D related updates within the last bit of time that would affect this and the Animate script isn’t a part of the CoreScripts directory so there isn’t really a way to check for any recent commits on it nor are updates made to it ever announced unless there’s a very significant change worth keeping everyone up to date on.
My advice at this point would be to fork, can’t imagine any other way you’ll sidestep the issue without doing so because without code on hand it’d be up to trying to find a setting or cause you can control without modifying the Animate code and said setting/cause/event/whatever doesn’t exist.
Got nothing further for you here, sorry about that.
Yeah, seems to be a function called “setRunSpeed” that I don’t remember being there/being written the way it is in Animate. I just commented out its only call–seems to have done the trick. Thanks, though.
