I’m in the making of a pathfinding system and I’m currently coding the part that handles the way that the npcs will reach their target if they are in sight, so no need to use any pathfinding at this point. I am simply using Humanoid:MoveTo(location,part).
Now, the thing is that as you can see in this video right there and in the title, our guy suddenly stop moving and I just recorded it once, but it happens a lot of times. I reviewed my code many times and huh I don’t see any problem with it. Here, take a look in the part in question that handles the moving.
while player and player.Character and player.Character.Humanoid.Health > 0 and (player.Character.PrimaryPart.Position - model.PrimaryPart.Position).magnitude < reference.interestRange.Value do
--is there a path that directly leads to the target (w/o pathfinding)
local ray = Ray.new(model.PrimaryPart.Position, player.Character.PrimaryPart.Position)
local intersectingPart = workspace:FindPartOnRayWithIgnoreList(ray,ignoreListCopy)
if intersectingPart == nil then
local inSight = true
while inSight and player.Character.Humanoid.Health > 0 do
model.Humanoid:MoveTo(player.Character.PrimaryPart.Position,player.Character.PrimaryPart)
model.Humanoid.MoveToFinished:Wait()
local ray = Ray.new(model.PrimaryPart.Position, player.Character.PrimaryPart.Position)
local intersectingPart = workspace:FindPartOnRayWithIgnoreList(ray,ignoreListCopy)
if intersectingPart == nil or (player.Character.PrimaryPart.Position - model.PrimaryPart.Position).magnitude <= reference.interestRange.Value then
inSight = true
else
inSight = false
end
end
end
wait(1)
end
Sorry for the indentation, happens when I post code on devforum, but anyways if you need precisions concerning the code just let me know and I’ll get right back at you. And obviously, if you didn’t get it yet, I want to stop the npc from making stops like this, it’s really ugly. That would be good for some zombie maybe but that’s not the kind of chasing that I’m searching for right now.
*Also, I noticed that it starts working back after 8 second which is the timeout of :MoveTo() if I’m not mistaken. But then, I don’t know why the MoveToFinished is still waiting for the npc to get to his point.
I’m thinking about adding a timeout after 1 second, but I find that a little bit frustrating
Kind of found a temporary solution. But if anyone has an idea about why the MoveToFinished isn’t running just let me know.
while inSight and player.Character.Humanoid.Health > 0 do
model.Humanoid:MoveTo(player.Character.PrimaryPart.Position,player.Character.PrimaryPart)
local eProxyEvent = Instance.new("BindableEvent")
local proxyEvent = eProxyEvent.Event
local hasFired = false
do
spawn(function()
local moveToFinished = model.Humanoid.MoveToFinished:Wait()
if not moveToFinished then
hasFired = true
eProxyEvent:Fire()
end
end)
delay(1,function()
if not hasFired then
hasFired = true
eProxyEvent:Fire()
end
end)
end
local result = proxyEvent:Wait()
local ray2 = Ray.new(model.PrimaryPart.Position, player.Character.PrimaryPart.Position)
local intersectingPart2 = workspace:FindPartOnRayWithIgnoreList(ray2,ignoreListCopy)
if intersectingPart2 == nil or (player.Character.PrimaryPart.Position - model.PrimaryPart.Position).magnitude <= reference.interestRange.Value then
inSight = true
else
inSight = false
end
end
I’d like to publicly take this moment to announce that I dislike, very strongly, the way pathfinding and Humanoids have been implemented.
I’m pretty sure I could give a couple hour presentation on the long history or bugs, struggles, frustrations, and unspeakable hacks (in both meanings of the word), and most probably psychological damage that has been Humanoids since their conception (heh…) and the Pathfinding service since it was released.
I could keep going now, but I doubt that is what the author would like. So, for the betterment of the quality of developer life and for the sake of chad’s sanity I’m recommending that Humanoid.MoveToFinished be avoided. Like the abomination that is the Humanoid. Implement your own version of it. Check how far the Humanoid has to go, how fast it is currently going, and calculate how long it will take to get there. I did this and was able to create an AI that jumped and navigated an obby.
In other words, yes. I’m speaking from experience. I’m very sorry.
(P.S. The humanoid doesn’t get up to speed instantly when it starts walking or changes direction. It acts more like a force is being applied. I took this into account when I developed my version of MoveToFinished. I’m not sure where it is now, I’ll let you know if I find it.)
If the goal is not reached within 8 seconds the Humanoid will stop walking and reached will be false.
Maybe that’s the source of your problem? Movement timeout? Try putting a print statement right after the wait and see if it passed the wait after the NPC stopped.
Thanks for your answers guys. I kind of fixed the issue by kind of setting the timeout to 0.2 seconds with the script that I postee above and it looks fluid, but it’s frustrating to see that humanoids seems to not work correctly and I totally understand your point IdiomicLanguage.
Yes it was, the move wasn’t considered as finished when it was suppose to be so instead of 8 seconds I reduced the timeout to 0.5 with some trick that colbert suggested me about what to do if some events aren’t firing after x seconds.
I actually managed to make a pathfiniding using the Roblox Humanoid:MoveTo function, but as I said I changed the timeout and not gonna lie, it works good.
Might make a tutorial about how to make something similar if I get enough feedbacks. I may post it on the cool creation stuff.
a method I found for fixing it randomly breaking, is to simply do
local v = workspace.npc
local human = v:WaitForChild("Humanoid", 5)
for i, V in ipairs(waypoints) do
human:MoveTo(V.Position)
repeat task.wait() until (v:GetPivot().Position - V.Position).Magnitude < 4
end
rather then using MoveToFinished, in my testing it never tried backtracking, there might be some flaws, but I couldn’t find any
