I suggest that a path created by
Module.new have its own move method.
I suggest that a path created by
How so? I believe this is very efficient if you are not creating many paths at a time. It is also meant mainly for making Roblox pathfinding functions and not for a alternate pathfinding service.
I don’t really understand by what you mean about incorporating a move function in the module.new function? Do you mean having another parameter and if true, moves on the created path right away instead of having to call the move function separately?
I was suggesting that whatever
Module.new returned had its own function to begin movement instead of passing it to a function as a parameter. In retrospect, seeing as this is a wrapper for PathfindingService, this wouldn’t really be easy without rewriting some crucial parts of the code.
Would you like me to make an example Object Oriented pathfinding module?
Its a lot better for intuition and it saves having to make
path an argument for every function.
Please refer to:
Hi, when i use the array the npc stops before it gets to the first checkpoint no matter how close I put the checkpoint, this does not happen using the single checkpoint point method.
Noted. Thanks for the report. I will get back to you when the bug has been fixed. Although it might be on ROBLOX’s end with pathfinding. Either or, it should be fixed soon.
You really don’t need to wait for Replicated storage. I’ve never had to.
It is better practice and I rather use WaitForChild rather than indexing it right away as ReplicatedStorage may not have loaded in yet. Besides that is part of an example of how to use it. If you are not satisfied with the way I set it up, then that is your fault and not my issue to take care of.
Its just personally bad practice ¯_(ツ)_/¯
Then you can’t view what’s inside replicated storage, IVE never seen replicated storage or any service not exist;
Your not really understanding my point nor know bad/good practices. WaitForChild is actually a way better practice than just flat out indexing it. Many other alternatives can be used as well, such as game:GetService. As said before, if you don’t like the example I put, then that is your own problem and not my problem to deal with.
Could you please explain more thoroughly what you mean?
It is more of the fact that it is better practice not to just index services using game.Service. Your not understanding my point at all. It is my personal preference to use GetService and WaitForChild instead of indexing. Also, using GetService or WaitForChild is indeed a better practice. As I have said like a million times, if you don’t like it that it not my fault, it is yours.
Once again, this is not an issue with my module. If you don’t like it, change it. That’s why it is considered an example. I don’t really know how else to explain it.
I’m confused about your choice to use a constructor function but not call any functions from the value it returns… is this supposed to add support for multiple paths at once?
As @ihavoc101 said, constructor functions are generally reserved for Object-Oriented Programming and it doesn’t really seem to be contributing anything here.
It would be helpful if you could add some documentation for every function of the module and not just the “extra” ones.
Thanks for reminding me. Totally forgot to document all the other non-extra functions. Don’t know how I missed that. Thanks again for the reminder. Ill do that soon as I haven’t really reviewed this module in for ages.
Big fan of your EZ pathfinding Modules, I am currently using it for my Telltale Engine!
I’m glad to hear people are using this in their games! Good luck to you and your Telltale Engine!
Would this work with parts or only NPCs?
This works with parts also however it uses a different method with pathfinding.