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?
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.
I have seen this module, I’m not up to use it, I’m up to learn and solve the problem alone. If the modules code is public I perhaps could take a look at how they do it, if it’s really as good as you say. Thank you though
I still think I’m stuck on the same relative problem.
I’ll be bumping this once again in a few days. Thanks for the help today.
Topic bumped for a third time.
If this truly gets confusing, I’ll make a new thread but please refer to everything that’s already been said as well as my initial post before posting.
Thanks!
Topic bumped for a fourth time.
If this truly gets confusing, I’ll make a new thread but please refer to everything that’s already been said as well as my initial post before posting.
Thanks!
Topic bumped for a fifth time.
Topic bumped for a sixth time.
Topic bumped for a final time; and I’ll be making a new post otherwise.