So basically, I’m adding a “tackling” mechanic to this zombie. It plays an animation and moves via Move() wherein it moves forward at keyframe “jump” and stops at keyframe “landing”
local function Latch()
local cons = {}
hum.WalkSpeed = 15
anims.latch:Play()
cons[1] = anims.latch.KeyframeReached:Connect(function(name)
if name == "jump" then
--@ testing
task.spawn(function()
char.Head.Color = Color3.fromRGB(255, 0, 0)
task.wait(.1)
char.Head.Color = Color3.fromRGB(126, 104, 63)
end)
hum:Move(HRP.CFrame.LookVector)
elseif name == "landing" then
hum:Move(Vector3.zero)
for _,v in cons do
v:Disconnect()
end
end
end)
end
The only issue I’m facing is the delay on the client, and using the testing line above (blinks head red on “jump” keyframe), I’ve isolated the problem to the Move() being delayed on the client?
I’ve also tried a body mover like LinearVelocity, seemingly similar delay. And yes the zombie’s network owner is set to nil/server
if you’re just facing issues with the zombie’s movement, have u tried predicting the position on the client, and then brute-forcing the zombie’s position until it until it’s mostly synchronized?
Unfortunately, that’s just how it is… Physics replication always comes with a delay, caused by both ping & physics interpolation. You can’t do much, your best bet here is to try and disguise the visible delay with either visual effects or adjusting the animation itself to also move forwards.
Alternatively, if you’re feeling a little crazy, you could maybe try to do velocity-based prediction, but this might result in desynchronization between client and server down the line.
I’ll def try looking into the whole clientsided prediction stuff, but here’s another idea I had – Honestly I thought it was a bit overkill but I’ve always thought about doing a “server handle position and pathfinding, then let client handle the visible rig, animations, and everything visual” approach. I never thought about doing it considering I’m doing a “smart ai over wow big zombie horde” based zombie game, but issues like these warrant solutions like that I suppose. Never looked much into it so I’m not so sure yet but we’ll see.
Thank you for your responses btw, I’ll see whatever I decide to do and I suppose I’ll update this post whenever (and if ever) I do something new about it.
I’ve had to solve the same issue with my own NPC taking a swing at a player and registering the damage to line up with the animation because the client delay made it look odd when the NPC would swing but damage was registered before the “hit” part of the animation completed. The video example, I don’t understand the issue I guess?
Genuinely curious, how did you line up the animation for the client?
The video example, I don’t understand the issue I guess?
Watch when the head blinks red, this indicates when the “jump” part of the animation starts. When I switch to the server, it moves in sync but when I’m on the client – the movement is delayed from the blink of the head.
Brute force.
First, I figured out the delay under ideal, unrealistically low ping of my studio testing in team test. Knowing what the baseline was, I could take the players ping and extrapolate the time difference. For example, the players ping is 100 ms (average), when the animation fires on the server, I know there will be a 100 ms + 10 ms replication delay to the client, then the animation takes 500 ms before the “hand” would hit the player. If the hit was “good”, it fires the damage event (red screen, smack sound, lose health, etc.) around the same time at the end to “line up” with what the client is seeing. Otherwise without this, what happens is the animation would play, Internet latency would cause the client to get the “damage” before the animation of the NPC hand appears to hit them. Maybe it’s a nitpick on my part, but I wanted to two to be in sync, or pretty darn close to look more natural.
