they shouldn’t rlly freeze. Which you’d think MoveTo() directly would solve
This is a built in thing with humanoids, they stop a bit short of their target… I’ve never really known exactly how to compensate for that but you could add an offset to the target position and move a little bit further. That might take some tuning though.
It’d take some difficult math on all coordinates?
I’ve tried using the target’s velocity. I WONT use lookvector, as the player may not always be facing in the opposite direction of the enemies.
Target velocity doesn’t seem to help, they always over shoot, and if the target sways from side to side, they get all seperated and messed up.
As for this, I wonder if maybe you have a path waypoint or two that is really close to the NPC? Since they’re moving pretty fast how do you pick the first waypoint they should move to?
Removing ending waypoints would not be smart, as they’d get stuck on obstacles easily and they’d likely just bug further behind the target.
It would actually look something like this:
local OVERSHOOT_FACTOR = 2
local targetPosition = targetHumanoidRootPart.Position
local myPosition = NPCHumanoidRootPart.Position
local offset = (targetPosition - myPosition)
local goal = targetPosition + offset.Unit * OVERSHOOT_FACTOR
Humanoid:MoveTo(goal, targetHumanoidRootPart)
The only problem with this is that the overshoot really needs to be computed constantly otherwise if the direction between the NPC and the player changes drastically between pathfinding calculations then they would overshoot to the sides of the player or potentially even undershoot if the directions reversed. That seems kind of unlikely in 100ms or so but it might be a consideration for you.
I’m suggesting that the first few waypoints may be close to the NPC. From my experience path waypoints start at the position you started the path at, which makes sense but if you ask the NPC to move to where they already are then they might stutter a bit if that makes sense?
Would this be something I include in finding path calculations or is it something I’d slap in a moveto() to every waypoint or just the final moveto() while a path is being calculated, sorry not 100%, this stuff been driving me insane.
Though the way you found an offset is not something ive tried or seen yet so
Thats why I remove the first waypoint in every path that is calculated so they don’t freeze in place.
This code would be where we just added that MoveTo after the for loop, sorry, I should specify.
You said constantly calculate the overshoot factor, how might I do that?
I’d test to see how if this actually is a problem before worrying about it.
Also for the other problem of removing the first waypoint, imagine this scenario:
That built in “close enough” behavior on humanoids sometimes can be a problem in these cases, it decides that it doesn’t need to move because we’re already there. So the overshoot thing might be something you also want to consider in your goal position for pathfinding. My experience has always been that this behavior is inconsistent and difficult to account for because of that. But it might be worth a shot for you
Alright, I see,
I implemented your overshot method, they do not bug at all now, except for the fact they sometimes decide to run back a bit after they “reach” where I’m at. Still a notable distance, but they don’t really freeze in place anymore…
I implemented your overshot method, they do not bug at all now, except for the fact they sometimes decide to run back a bit after they “reach” where I’m at. Still a notable distance, but they don’t really freeze in place anymore…
This might actually be a pathfinding waypoint they’re returning to that’s behind them. In the time it takes to calculate the path, their position has changed substantially if they’re moving quickly. At 60 walkspeed they can move 6 studs in 100ms, so that’s something to take into account, maybe find the closest waypoint to them first?
That also has some potential issues where the “closest” waypoint could potentially be on the other side of a wall, so you’ll have to decide how to deal with that.
Update: The distance is less notable when the target is way slower than the enemy.
I think I I know what you mean, they move too quick, and the path has already been updated for an older position of theirs (the enemy’s).
I’m not entirely sure how I’d go about finding the nearest waypoint. (You mean the nearest waypoint on the most recent path calculated?) if so, yeah that would be a problem with obstacles, etc.
Yeah that can be tricky to deal with. I’m not really sure on a great solution for you there. There’s a few “hacky” solutions I can think of but I don’t know if they’re really worth exploring without spending some time on them myself.
Hopefully all of this has been helpful in figuring out what’s going on. I think we’ve mostly solved the issues in your original post. Perhaps someone smarter than me can chime in on this most recent problem in a new post?
1 Like
Well, yeah I’m pretty sure the problem is the target’s position either updates too quick for the Enemy, and/or path is calculated for a previous location of the Enemy. I appreciate your help. I’m going to continue to leave this post opened, like I said, and bump it. Feel free to refer back to this post if you happen to have a simple solution or idea that may help. I really appreciate you helping.
heres some notes:
Im not entirely sure why anyone would suggest handing over ownership to client, if anything it should be set to nil (server) to negate automatic network ownership to becoming client (if applicable)
if setting to nil doesn’t work;
I don’t see why it would get choppy when it gets near a target area however maybe all you need is this:
this is a module I have recently found and it improved my ai npc movement, you could utilize it in such a way that while chasing, continuously follow the target
--where goal is the target's HRP object
while Chasing do
Path:Run(Goal)
end
this module also comes with a path tracer so you can debug/see whats occurring perhaps? note you would have to replace your waypoint code with this module
Honestly, I’d recommend a new post. This one is really long and judging by the most recent response here people aren’t actually reading, or understanding what we’ve gone over so far. The problem you need to solve is how to deal with path waypoints that are behind where your NPC is now, since there’s like 100ms computation time for paths. Using someone’s module won’t speed up Roblox’s pathfinder being insanely slow unfortunately.