I have been trying to tidy up my Npc framework. However, I have this problem where the Npc doesn’t move smoothly to its given position.
This is because I’m firing to the client from
RunService.Heartbeat and moving the client object from there. Flow chart of what i mean:
Other Notes About the System
- no humanoid used on Npc
- everything is anchored (trying to avoid using physics)
I have tried lerping on the client but that doesn’t do anything to make it smoother. Please leave any suggestions you have in fixing this problem. Thanks!
Is the server firing every physics frame, or are you just sending movement instructions and the client is taking it from there?
well, i’m doing the second one you said except that they aren’t really instructions; they are just positions for the zombies to move to
I guess what I’m trying to ask is how the zombies are moving to the positions supplied by the server and how frequently the server sends those requests. Is the server sending a new position every physics frame and the client is teleporting the zombie to that point, or does the server only send a position when the zombie decides to move somewhere that the client then lerps to over time?
the server sending a new position every physics frame and the client is teleporting the zombie to that point
this is what i’m doing. I also forgot to mention that the server calculates a path using pathfinding service; then the server-sided zombie changes position to the current waypoint; then it fires the event for the client to teleport the zombie to the position every heartbeat
Unfortunately, that’s where you’re problem is stemming from. Even in studio, you will see a bit of latency, but the impact will be even more pronounced on a live server.
What would fix the problem would be to send the path logic to the client and let the client run all the updates from there, allowing it to achieve the actual
Heartbeat update frequency. I have not worked with
PathfindingService before, though, so I don’t know the exact methodology to use to get the path from the server to the client. If you aren’t afraid of some desync, you can have the client calculate the path itself, or you could send the waypoints that the server generated over to the client for the client to reconstruct the path, but, again, I am not experienced in this area, so there may be better alternatives.
the main reason I was doing what I was doing was to prevent exploiters from moving the npc to their advantage (since my npc system is based on rendering npcs on client). so, i don’t really think your solution will work for me because it can be easily exploited.
I understand your concerns with client-side security, but that doesn’t mean you can’t run the logic on the server, as well. You won’t use the server’s data to update the NPC movement every frame, only on route changes, but the server will still know where that NPC should be. That way, even if an exploiter moves the model, the server will be able to validate if whatever they did with that NPC would have been possible or not based on its own data.
Having parallel systems is the only real way to keep the impact of latency as low as possible, and even in a server-driven system, you can’t trust that a client-rendered NPC will be where the server told the client to put it, even when pinged as frequently as you have it.
Hmm. Good idea. I might try this out.