Choppy Humanoids: Target Position updating too quick for the server?

Help and Feedback Scripting Support
, , ,
#21

Seeing some code might be helpful to understand the problem a bit better.

#22

Can I send it over dm or do I need to send it here?

#23

Up to you on that. Again, this could benefit others in the future.

#24

Code Removed and Hidden; Refer to me in dms for solutions.

#25

This is the BASIC structure of how it works.

#26

Thanks for showing the above, where did you try to do the direct MoveTo while the path is updating? I don’t see that in the code above so I assume you’ve removed it, could you show what you were attempting there?

#27

Yeah, apologies, I did remove it as it wasn’t helping.

I tried fitting it into a repeat under the UpdatePath function, constantly checking to see if the path status is ‘success’.

Also tried throwing it in the raw coroutine itself in the while loop, but doesn’t seem to help?

Would having the UpdatePath() function return false or true help, and then have it constantly moveto() target’s position until the path has been calculated?

#28

I’d say if the FollowPath function is able to fully complete the run of all waypoints then you would want to MoveTo the target, since it’s out of waypoints. Once the PathfindingUpdate function completes it would once again call your FollowPath function, thus overriding this behavior so that works pretty nicely.

One fun detail about Humanoid:MoveTo is that you can specify a Position and a Part, if the part moves then the position is updated automatically so you don’t need to keep recalling the MoveTo function. One caveat is that the MoveTo function times out after 8 seconds but that shouldn’t really be a problem in your case since your path should really be ready by then. See Humanoid | Roblox Creator Documentation

If the part parameter is specified, the Humanoid will still attempt to walk to the point. However, if the part moves then the point the Humanoid is walking to will move to be at the same position relative to the part. If the part parameter is not specified, then the position the Humanoid is walking to will not change.

I think this should work as a solution for you though. Let me know your thoughts.

#29

So you’re suggesting I just throw the MoveTo() right into the end of the for loop of the waypoints in my FollowPath function?

So I should set the second parameter of the moveto() function to the humanoidrootpart?

#30

So you’re suggesting I just throw the MoveTo() right into the end of the for loop of the waypoints in my FollowPath function?

You’d want to put it after the loop ends, also checking that it completed all iterations of the loop and the break out case here:

if (self.Threads.ActivePathfindingCoroutine ~= coroutine.running()) then
	return
end

is not hit, so maybe have a boolean before the loop that’s something like local PathComplete = true and in the case mentioned above, set that to false and then after the loop ends you can check if that boolean is still true… although I never can remember if that’s actually necessary when you return from a loop versus break from a loop. Might just end the whole function at that point :man_shrugging:

Anyway, after that for loop ends should work, yeah.

So I should set the second parameter of the moveto() function to the humanoidrootpart?

This is correct, yeah. Should automatically track movement on the HumanoidRootPart that way.

#31

Okay, so outside at the bottom of the for loop, looping through the waypoints. How would I go about doing this? Do I wrap it in a while? do I wrap it in a repeat until boolean here or…?

I lost you here, not sure wym sorry im slow lol

#32

Checking the path has already been iterated through before calculating a new path is not necessarily what I want as we always need the enemies heading to the target’s position at all times.

#33

Oh I just realized you said it’d update if the humanoidrootpart moved. mb

#34

but the other thing i’m still confused about

#35

I want to say you could actually do this:

self.Threads.ActivePathfindingCoroutine = coroutine.running()

local Humanoid = self.Rig:FindFirstChild("Humanoid")
local HumanoidRootPart = self.Rig:FindFirstChild("HumanoidRootPart")
	
for index, waypoint in ipairs(waypoints) do
		
	if (self.Threads.ActivePathfindingCoroutine ~= coroutine.running()) then
		return
	end
		
	if (waypoint.Action == Enum.PathWaypointAction.Jump) then
		Humanoid.Jump = true
	end
		
	Humanoid:MoveTo(waypoint.Position)
	Humanoid.MoveToFinished:Wait()
end

Humanoid:MoveTo(self.Target.Position, self.Target) -- Not sure what your current target looks like but this is the gist of it.
#36

Yeah I just now figured, mb. but if you could help me understand the other thing you said?

#37

Are you referring to this? If so then the above code should be sufficient, I thought you had a break in that if case but it’s a return so it should just stop the execution and not just the loop.

#38

The return completely closes the function.

I’m assuming I would only want to keep the target as a second parameter to a MoveTo() at the end of the for loop?

#39

Correct, your MoveTo call would look something like this:

Humanoid:MoveTo(TargetHumanoidRootPart.Position, TargetHumanoidRootPart)
#40

Alright, as long as I’m not tripping, they appear to not freeze and lag as much but they still stay a small fair distance behind the target.

Ultimately, there is still a noticable distance. The objective is to have them rub up against the character if they are in fact faster than the target. How possible it is, well is different