NPC Pathfinding Client to Server Latency --- Any Fixes?

Help and Feedback Scripting Support
#1

hello developers! for some time now i have had the problem of npc’s lagging behind in the client’s viewport compared to the server and i was wondering if anyone knew anything about this or had a fix?

Video Showcasing:


as i’m guessing you can see in the video, even though it’s not by an extremely large margin the NPC does lag behind in the clients view opposed to the server. more apparently however is when the NPC just starts moving. you might notice that it looks like they just sort of walk in place for a second? well yeah, anyways thanks for reading this and if you know anything on the subject please don’t hesitate to reply! thanks!

#2

In a real game, it always takes some time for something to replicate from server to client, from tens of millisecond to hundreds. This isn’t a problem you can solve, it’s just a fact of the internet. What you see in a local server-client test isn’t particularly representative of this either, since it’s all running on your machine whatever delay is there has more to do with how often your computer is updating each instance (foreground window gets updated more often IIRC), rather than network transmission time. So I wouldn’t worry about it.

#3

well ok but then how do games like say entry point make the ragdolls transition smoothly rather than freeze like that and also say a player shot a moving npc, wouldn’t it not hit because on the server its in a slightly different spot?

#4

It’s a long shot and also would generate a lot of issues but maybe make the closest player have network ownership over the NPC when it’s ragdolling??
There’s probably a better solution but I don’t know it!

1 Like
#5

create and move an NPC on each client

then check on the server to make sure its not too off

send a remote event telling the client to ragdoll the npc when the server wants to ragdoll it

you can also put a gun on the client to shoot the npc and then do a check on the server to make sure its not too off

1 Like
#6

edit: ok i’ll try that thanks

just real fast to highlight the problem:

16:40:23.381 4 3 -30 - Server - NPCPathfinding:19
16:40:23.418 5 3 -36 - Client - ClientReplication:8

i made a short script that printed the position of the torso on the npc and client. if you look at it you can see that in just a 0.1 second difference, the client’s npc is like 7 fricken studs behind i feel like the replication should be faster than that, or at least a way to do it?

#7

you cant fix the delay
thats how the internet works

you have to do the calculations on the client and then use the server to make sure its not suspicious

#8

Well, I think this is where we say this is simply just the demonstration of NetworkOwnership!!!

what the heck is that?

Well, explained briefly, it’s simply just any unanchored object inheriting the network latency of its “network owner”. The owner won’t see the latency of the physics since it’s the owner of said object, but everyone else would see that latency of the object.

Let’s use this scenario: We have a tool that acts like a basketball, allowing you to throw it and dribble it and whatnot. Within that script, it sets the network ownership of the ball object to the player who currently has the ball when they decide to throw it.

If the player who owns the ball had a ping of 50 ms, then the ball’s physics of being thrown would be 50 ms slower to others than it would to the owner of the ball. (The player)
If the player who owns the ball had a ping of 200 ms, however, the ball’s physics would be 200 ms slower to others than the player who threw that ball.

In your scenario, your NPC is owned by the server I’m assuming, (whether that is they’ve been moved into the workspace via server script, or simply was in the workspace before runtime) meaning its parts network ownership (mainly the root part) is being owned by the server. So, since no one else has the ownership of those parts, they’ll get the network latency of the NPC on top of their own network latency.

So how would you fix this? It actually depends.

If you don’t mind the latency of the NPC, and it doesn’t impact the gameplay of players too much, then you don’t need to change much since it’s internet on the client’s part. So, you really can’t do anything here.

Now, if the NPC is needed to be as synced as possible, I suggest you have the NPC’s movement be handled on the client’s, so that they can see the NPC moving in real time with no latency. Just have the server check if it’s close enough to do said task. (Like what @happyxander0810 said) I do think, though, the NPC’s root part needs to set its network ownership to the clients (or the client with the shortest latency) to control the movement of the NPC. This will leave room for exploits though, which is why I said make sure the NPC is positioned where they should be with the server-sided script, as a checker to make sure it’s following its set path. There are more things you would have to check, like if the NPC is jumping when it shouldn’t, but I think you get the gist of “checking if the movement of the NPC is sanitized”.

Hopefully this helps. (I might’ve just talked a mouthful for no reason, though, LOL)

#9

Uh, also I forgot to mention but network ownership set to the npc makes it lag for anyone besides who it’s set to, and also makes it vulnerable to exploits, since the player who you set it to’s client now has control over it’s movements! If it’s not that important for a ragdolled NPC to be there then the exploiting shouldn’t matter too much so long as it’s also not used to flung anyone, but if the body does need to be there then just beware of that.

You could always do anticheat on the server for that, too.

#10

ok yeah that does help. so if i were to have the npc’s movement handled on the client how could i go about this? would i have the pathfinding run on the server and client? and about the npc latency even mattering i think it does for what i’m trying to make. and again about the delay, @happyxander0810 why would the remote event be able to be sent over in less than 0.2 seconds then why couldn’t the npc’s position be sent in that amount of time? i mean the ragdoll in general looks fine on the server and client btw, its just the lag in between starting it on the client

#11

If you did go with networkownership you’d only need the pathfinding to be done on the client that has ownership over it. The rest will be replicated. This’d cause less pretty much no latency for one person, but more for others iirc?? It’s a whole mess.

RemoteEvents are very small amounts of data. The NPC, while still a small amount, is more. But it’s also not the only thing getting sent, I believe. It needs to send the data of every property that has updated for every instance in the world, and I assume it does this either all at once or in large chunks.

Plus, this is just a guess, but I’d imagine theres a lot of checks being done for both the server and client when sending and receiving anything physics based before rendering at all.

1 Like
#12

Well, if you got the path of where it SHOULD follow on the server, then you could use that to check if they’re positioned as they should on each key point of the path. I wouldn’t use RemoteEvents, but actually just a Heartbeat to check if they’re where they should be. If you’re advanced enough, you can use a math equation on the server to find the position of where the NPC should be, and use that to check if the NPC is “close” to the calculated position. (I think you could use distance = speed / time for this?) There’s also a kinetic equation to tell if it’s exactly within the calculated position, but that might be a little more advanced.

#13

what if i just used remote events to send over the exact CFrame of the npc’s torso to the client and position it accordingly? would that work?

#14

Honestly I have no clue how well that’d work. Send it for the HumanoidRootPart, though! Positioning torsos instead of HumanoidRootParts is really buggy.

One thing I’d note is that doesn’t necessarily mean that it’d be accurate. It might look choppy since your game still runs before the server sends more data over. If you anchored the parts for the NPC (on each of the clients) and then sent over the positions then that’d help but it’d still be a weird-looking low FPS, if I had to guess.

1 Like
#15

oh yeah that reminds me how do roblox fps games like arsenal tackle this problem because there’s still latentcy in those games unless they know a way to reduce it? i saw a video of someone who reduced it i can’t find it anywhere on youtube tho… (i tried the setting the rootpart position, it didn’t go well haha)

#16

I’m not sure tbh! I don’t really make anything fast/importantly timed like an fps/fighting games. I usually make more casual games.

I know combat warriors uses local detection per person, but that’s for detecting where something is, not moving it. In the case of positioning something I’m stumped.

1 Like
#17

ok i finally found it! this is what i mean, how do they get the network delay so fetching low?

#18

In the comments, apparently it’s something to do with RemoteEvents I guess, before UnreliableRemoteEvents were born. Not sure how exactly true this is, might be a joke based on the interaction:
image

But, if this is true, their script is firing to the other clients the CFrame of a player in that current frame. Basically, Player1 would be firing its CFrame of the RootPart to the server, which the server sends that information to the other clients to replicate. How much would this cost in performance on the server if it was running like this? Well, from the creator of the replication, it’s good for up to 50 players.

But this is still for custom replication between p2p, (player to player) so this might not apply well for the server since again, the server would be owning the NPC if you’ve not set the NPC’s root part to a specific player. You could mix what I said with checking if the position of the NPC is close to what the server calculates, while doing what I broke down with how that server’s doing p2p custom replication. Doing this, though, would basically be more work than what I had said might work better.