Realistic foot-steps without Server-view choppiness?

[MarkMcBlox]

Hi,

My goal is to create an sword-swing animation that moves the HumanoidRootPart during the animation. I want the character to take the right step forward with the swing, and then have his left foot move to his right foot. I understand animation objects do not allow moving the RootPart itself, so I tried a couple things such as tweening the rootpart forward and using bodymovers to move the character forward as well. All result in a choppy server-side view.

The current animation:

The server view:

My idea is to have the animation move the character backwards while using a tween or bodymover to move the character forward.

This appears flawless on the client; the character takes a step forward and the animation ends with him a few studs farther ahead than before his swing.

Is there any way to make this animation smooth for the server and client? My main concern is latency issues with enemies attacking players at locations they aren’t at anymore.

I feel like there may be a completely different and better approach to this.

[PixEclipz]

how are you moving the HumanoidRootPart currently? I’m pretty sure that as long as long as you move the rootpart and play the animation on the client (and allow it to replicate to the server), the two shouldn’t be out sync on the server. There will be latency between the client and the server, but there’s no way ti prevent it (though in some cases you can reduce it). Also, make sure the rootpart isn’t counted as a hitbox that players can take damage in. A simple “if part.Name ~= HumanoidRootPart” in the damage dealing script should work.

[MarkMcBlox]

I currently send an animation event signalling to move the character forward as the pose that begins to move the character backwards begins. This code cancels the movement out perfectly for my rig:

track:GetMarkerReachedSignal("MoveForward"):Connect(function(studs)
	
	local b = Instance.new("BodyPosition")
	b.Position = rootPart.Position + ((rootPart.CFrame.lookVector) * studs)
	b.D = 1000
	b.P = 50000
	b.Parent = rootPart
	game.Debris:AddItem(b, 0.2)
end)

This is how the client sees it.

I guess bodyPosition and character animations are replicated to the server differently?

[PixEclipz]

Instead of having the torso move forward and then being pulled back again, try changing the animation to keep the torso in the same place. Then, make the root part position bring the player forward. If timed correctly, it should look the same on the client but won’t make the player back up on the server. The only issue is the movement may seem out of sync on server, but at least the player won’t go backward

[colbert2677 (ImagineerColbert)]

This is actually a perfect thing to note. The Torso itself should be rarely moving or not at all on animations. For example, if you take the running and jumping animations for a default Roblox R15 rig, you’ll notice that the character performs its actions in place or in that relative location. That is because the actual movement is applied by the force, not the animation.

Example keyframe from the default jumping animation when the character reaches a high point:

At the very least, this will get rid of choppy behaviours. As far as animations go, playing them from the client is the best way to reduce choppiness. The server will always show choppy results which is typically why it shouldn’t be handling aesthetic effects - from animations to tweens and so on.

[MarkMcBlox]

I typically do not move the torso in my animations; however, moving it does produce the effect I want.

Here’s some screenshots of the animation with the BodyPosition and torso going backwards:

Without the torso going in reverse, the character simply returns his right leg instead of bringing his left leg forward like a normal lunge/footstep.

Aside from the legs not moving in the order I want, moving the rootPart forward makes it look like the character is just sliding across the floor. Am I reaching a limitation with animations, or am I not understanding something

[MarkMcBlox]

Instead of the hip going forward or backward, I made it stay in place:

The problem now is both legs come together rather than the left foot coming to the right.

I could write this off as good enough since there’s no bouncing back and forth on the server’s view, but it’s not exactly how I want it

[GooierApollo664]

Imagine you are that character. Do the movement in your imagination. You will see that you move forward while swinging the sword. Your character doesn’t move forward, it ends up being at the same position. I believe if you try and move your character forward with just pressing W key.

[MarkMcBlox]

I don’t want the character to press W mid-swing. This works fine with running animations, of course, but I only want the user to be using the attack button during this process.

In this attack combination example from Dark Souls:

https://media.giphy.com/media/evrh8UKc80wJq/giphy.gif(image larger than 10 MB)

The character alternates feet placement in between attacks (Right foot forward, then left, then right), and the character definitely not in the same 3D place after each attack. (Same place on screen, though, since the camera is following the character)

[PixEclipz]

Maybe try changing the timing of the rootPart movement so that it moves at the same speed as the right foot moves backward (on the second frame of that timeline). This way, it will appear (to the client, at least) that the foot is stationary and the torso is what is moving, even if it is not animated in this way.

[MarkMcBlox]

My solution is to keep the torso in the same place and push the rootpart forward like in my previous gif, but I decided to have the feet come towards each other 1 at a time. This looks a lot more realistic and doesn’t involve the animation moving backwards. It’s not perfect from the Server view, but I think this is as good as I can get it.

Client:

Server:

[PixEclipz]

It might look even smoother if you move the RootPart forward twice. Once for when the left foot goes backward, and once for when the right foot goes backward at the end.