For any scripters that knows Pathfinding service, you probably stumble upon this code in the script:
local Path = PathfindingService:CreatePath()
Path:ComputeAsync(start, end)
local Waypoints = Path:GetWaypoints()
Humanoid:MoveTo(Waypoints[3])
This code might look weird, but I want you to focus on the term Waypoints[3].
Does anyone know why there are scripters out there used that term in some pathfind scripts? Why are they making the humanoid to walk to the third waypoint?
It refers to the 3rd item in the Path:GetWaypoints Table
You’re not being helpful here. I know it is doing that, but why they index it to the 3rd element in the table?
That was a little harsh, I thought you were asking what it meant and was only trying to help.
They would do that because they want it to walk to the 3rd waypoint.
While quite frankly you have been really aggressive in your replies, let’s hope I’m able to help you…
It can simply just be bad coding practice, or a way to fix the bug where sometimes the start of a pathfinding operation has the first three points really close together. It could also be a potential way to force the script to not return the path blocked error until it moves a bit, to prevent mass re-creation of the path.
Overall, it could genunly be quite a few things, roblox scripts tend to bug out unless random little stuff like that is present.
If you were to follow the complete path, you would cycle through every waypoint, not just one of them. Obviously they aren’t doing that. This is an incomplete code fragment.
This looks like chasing code.
What they probably are doing is refreshing this path every second (as to not bog down the code with calculations). Each time they do, they get new waypoints. If they keep going towards the 3rd waypoint, they will never get there. They will always run towards the target, always refresh until they get there.
Why [3] and not [2]? I suspect if they used 2, based on the wait they selected, the move would end before the path was refreshed. This leads to choppy movement and looks bad.
This is all speculation, as the code is incomplete.
So using that term might help in some codes? It’s really weird to index the 3rd waypoint…
Your reply helped me a little, if you have any other ideas feel free to tell it out here.
You can try [2] if you like. If the movement stutters, it’s because the model reached its goal before updating the path. The waypoints are very close together. Experiment. Maybe the code is wrong.
You can think of it like this. I ask you to count a jar of marbles, but I only hand you one of the marbles at a time. You can count faster, but you need me to first give you the marbles. You will spend a lot of time waiting for me to give you the next marble to count.
On the flip side, I dump a handful of marbles on you every second. This is more than you can handle, the marbles start piling up and spilling onto the floor. It’s better to leave them in the jar.
If you want to count the marbles efficiently, I need to hand you them fast enough that you don’t stop counting, and not so fast that you lose data.
The same goes for code. Waypoint 2 is too close, and Waypoint 20 is too much information. The coder has determined that [3] is the right amount of info.
I have tested waypoints[3] and It can be used in while loop so when you change your target position the moving of NPC changes too. It just adds support for looping.