I’m super tired of MoveTo() since it generates MULTIPLE PROBLEMS, for example;
Yes I use it
Humanoid:MoveTo(Point.Position)
sometimes it does it well but at certain points it doesn’t run and leaves the code hanging,
also used;
local Value0 = 5
local Magnitude = (Bot.HumanoidRootPart.Position - Point.Position).Magnitude
repeat
task.wait(0.05)
if Punto.Action == Enum.PathWaypointAction.Jump then
Bot.Humanoid:ChangeState(Enum.HumanoidStateType.Jumping)
end
Bot.Humanoid:MoveTo(Point.Position)
until Value0 == 0 or Magnitude > (Bot.HumanoidRootPart.Position - Point.Position).Magnitude
Did you anchor the humanoid you are trying to move? I see that you’re calling the character Bot, so it’s probably not a player. See if it is unanchored. If not, maybe try using Bot:SetPrimaryPartCFrame(...).
I wonder if you know how MoveTo() works or I at least know how SetPrimaryPartCFrame works, please explain, but if I’m not mistaken, isn’t that obsolete? Shouldn’t PivotTo() be used? Anyway, in case you don’t know how MoveTo() works, what it does is move a Humanoid to a point in a fluid way, basically the same thing could be done but in a renderstepped, if you wonder why I call MoveTo() in a Loop is because on some occasions it is not executed
Basically yes, I already saw the documentation, the first example worked, but it affected the waiting time of 8 seconds, in such a way that I tried to do the other method, but it did not give the slightest sign of movement, @OptimisticSide the Anchored was deactivated
Hey, you will wonder why the documentation is not a solution and it is because in the example code, it shows an example which, if MoveTo() does not work, it will call it every 6 seconds, therefore when MoveTo() does not work, what happens is that it stays hung (with that script) I did a similar method but with the idea that it would repeat it from time to time and when it detected the slightest movement, it stops, the point is that it does not detect it since there is not the slightest movement , apart from the fact that I put it in my loop to wait longer but in the same way it did not execute the function
Move to makes sure the model will not clip. You can use Model.PrimaryPart.CFrame or Position instead to bypass that (works exactly like Setaprimarypartcframe except it isn’t deprecated and it’s fine
What do you mean? I mean I had an “ai” that moved behind you and I switched to that and it worked fine, even lets you tween position and size.
It worked similarly to what you explained
ok I’m going to try, while I also got other NPCs to guide me, and hey about your theme, I put that out of anger that I needed help and the people writing in your theme anyway, be strong.
Let’s see, with this method the loop is not necessary, I think, because MoveTo() gets stuck for that simple reason, if that’s why you think, would it be better to do the HearthBearth and replace the MoveTo()?
I don’t quite understand lol. Keep the current loop and replace moveto to PrimaryPart.Position or cframe, which will require you to change point.Position to point.CFrame
Run service is used for specific loops such as physics or renders and don’t support yields
please dear friend, MOVETO() is a function that is used to move humanoids fluidly, IF I FOR SOME REASON move the model with that function it will not do it fluidly, it will do it in less than 0.02 seconds, you don’t realize ?
Oh I got it. Sorry lol. Well again, replace moveto to that. It should not yield though, that’s weird but I’ll guess it’s trying to see if it’s clipping or not and replication lag is also screwing it up or something I don’t really know.
It’s obvious, Each waypoint has a magnitude of 2, if I use that, it will appear to teleport, please refer to this link which will explain the functions of MoveTo() https://create.roblox.com/docs/reference /engine/classes/Humanoid#MoveTo
Roblox indicates it in such a way and also, updating is necessary, SetPrimaruPartCFrame or as you said Model.PrimaryPart.CFrame It is not something Updated or suitable for that roblox I think PivotTo()