I am making a game and I want an npc to walk somewhere. I know that PathfindingService is the way to go. I watched a couple tutorials, but it seems that my npc lags for about 0.1 seconds and it makes him look laggy. When I looked at the developer hub, it showed me that there are part parameters in the function PathfindingService:CreatePath(partParam). I put in integers for the parameters, but it didn’t work. Then i tried using a table. Still unlucky. I just want to find a way to make my npc look like he is not stopping to find the next path.
1 Like
I don’t really know what you’re trying to describe but I am going to assume that your npc is stuttering while path-finding. There’s a post that solves this Pathfinding NPC seems to be hopping? - #7 by Eventive. If this is not the issue please correct me.
I’d say that it is stuttering. In the pathfinding article, it will say this for one of the codes:
local PathfindingService = game:GetService("PathfindingService")
local path = PathfindingService:CreatePath(pathParams)
it says that the path parameters is “a Lua table which lets you fine-tune the path for the size of the agent (the humanoid that will move along the path.” and I just want to change the radius from 2 to 5 so it would stutter less. I just don’t know how to word it.
Correct me if I’m wrong, but changing the path size of the agent would not do anything with the stuttering. It will just change the pathfinding to find paths that can fit in the specified agent parameters. The post above should fix your stuttering. This article explains how to change the agent parameters.
1 Like
I would check your methodology for using this. Make sure you are iterating through all the waypoints and listen to when the humanoid finishes it’s MoveTo.
In general, it’d be alot more helpful if you edited your original post so we have some resources to help diagnose the issue specifically, so if you can, could you please put your code in the main post so we can check it out? Otherwise, I’d check the above and look for any stray “wait()” statements.
The moveto:wait() function is the cause of the stuttering. Using magnitude instead to go to the next waypoint would make it less jumpy.
This wouldn’t cause stuttering. If you’ve set out a for loop that accurately iterates through all the waypoints, the difference between starting to move and just finishing a move should be milliseconds at best. We don’t know his code, so it’s just as equally valid that there could be the odd “wait(.1)” statement nested elsewhere in the overall loop.
Magnitude will also only make it faster if the system is set out so that it’d check if the target is in close proximity from the traveller, or the target is in the travellers line of sight. It won’t make the pathfinding itself faster and it won’t necessarily effect any stuttering in between thats caused by a stray wait() statement
The “humanoid.MoveToFinished:Wait()” does cause it to stutter. It causes a really small but noticeable pause when going from one way-point to another. Using magnitude would allow you to go to the next way-point in advance so you don’t stop at one way-point and then process the next way-point.
I double checked in studio this to be sure that it does and in ideal situations this should happen:
-- this is the code i ran, kinda scruffy but proves my point
local hum = game.Workspace.Dummy.Humanoid
hum:MoveTo(game.Workspace.a.Position)
hum.MoveToFinished:Wait()
hum:MoveTo(game.Workspace.b.Position)
The result of running this code…
(he moves straight to A, then to B after it reaches its destination)
You are correct in saying that there may be a very tiny delay in between, but it is certainly not noticeable which is why the method is ideal.
Part of the reasons why pathfinding exists is to calculate a specific path that X should take to arrive at Y. Magnitude is essentially a distance check, so the only reason you may want to use it is for cutting corners to specific waypoints. I don’t entirely follow how this could necessarily improve stuttering because you still have to actively check the traveller’s magnitude.
From what it seems from the original post, @MrTumbleWede’s issue is to do with either trying to create the next path or travel to the next waypoint and assuming he’s using MoveToFinished in the waypoint code, the delay must be caused by a wait() somewhere else in the loop.
It is not that noticeable right now because your humanoid has no animation playing. It is simply just being moved to location X. Try using a walking animation while the humanoid moves, it will become more obvious.