Maybe try skipping some waypoints, kind of like this:
local waypoints = path:GetWaypoints()
for i = 1, #waypoints, 2 do
hum:MoveTo(waypoints[#wapoints].Position) -- Just in case it skips the last waypoint
If you want to avoid creating your own paths, which essentially are a table of waypoints(Vectors) from which you would “MoveTo” each one, I suggest planning your builds around a certain hallway width and utilizing the AgentRadius of the :CreatePath(agentParams) argument.
Giving the “agent” a bigger radius means it can’t cut the corners as close because the path computed would make sure the side of the agent would not crash into the wall.
You will probably need to make your own pathfinding using this.
This seems like a basic 2d Pathfinding. You could drop your nodes as you want, and then connect them together somehow for example by storing those points in a table with the reference to their neighbours as well.
Then you can implement the A* algorithm pretty easily.
You can :Connect to the path.Blocked event and trigger a function that gets the blocked waypoint index(automatically passed with the event as the first argument). In that function do your logic checking why it’s blocked. Quick and dirty magnitude check for any doors etc. then open the door or smash it down followed by a new :ComputeAsync to continue on the mission.
This only detects if the door was open and then after computing the path it closed. If a door is already closed it will not be able to find any path. In that case custom pathfinding would be more suitable.
Plus there are some known unreliability issues on Path.Blocked event.
Absolutely agree with this and custom implementations can be boundless. Using built-in pathfinding and customary code can work hand in hand, but as you mentioned it would be beneficial having a custom implementation for these types of events.
path.Blocked can be unreliable and I wouldn’t suggest using it as your only check.