Hi all, I’ve made a custom pathfinding module using the A* algorithm on a grid. The point of it is to supplement roblox’s pathfinding, since roblox’s pathfinding is really jittery and tends to backtrack on smooth terrain. I’ve timed the computation time for the path using os.clock() and my algorithm is 2-3 times faster than roblox’s for the same start-end points. However, despite os.clock() returning less time for computation, my algorithm is causing the server to lag heavily when I create paths repeatedly, while roblox’s pathfinding algorithm causes next to no server slowdown with the same amount of calls.
I’m not sure if there is a solution to this but I’d like to know how roblox’s pathfinding manages to cause no server slowdown while still taking much more time to compute than my own algorithm. I’m guessing that my knowledge of the way the server makes its computations is incomplete, and os.clock() is not an absolute measure of the performance of a function, but if someone could explain how it works and why my algorithm would be slower, I’d be grateful.
So from what I understand this allows the computations to run in parallel, but I’m not sure how to connect this to my script. The script still needs to wait for the path computation to finish before continuing to follow the path, so is the idea that the script would still wait for the path to finish computing, but the computation would not slow down the server itself if the path computations were run under a different actor?
There’s a good chance that you can just calculate the path on a seperate actor, and then once it completes just follow it, and it won’t hold up other lia scripts since the computation isn’t part of the big main script pool.
I’ve been tinkering with Actors and parallel programming a bit, the problem is that to run the A* algorithm in parallel, my NPC’s AI script has to be parented under an actor. However, I can’t put each AI script under a different actor because the AI scripts have to communicate with each other. Bottom line is, I need some way to ask for the path (the computation being run in parallel) from another script without the script being in an actor.
I’ve tried using bindable events in parallel, but if I try to run a bindable event under an actor from outside the actor, I get stack overflow. Is there any way to fix that or should I try a different approach altogether?
I’m now using parallel programming across 16 different Actors, and unfortunately I’m still experiencing significantly more lag than roblox’s algorithm gives. Do you have any other suggestions for why my program might be causing more lag despite the faster calculation time os.clock says it has?
Hi @TheMoop, are you still seeing a stack overflow issue? I am curious if there might be a problem with Roblox itself, or if it might be an issue in your code.
Also, I am not sure if this is helpful for your specific use case, but we have some documentation about different ways parallel luau scripts can communicate here:
Have you taken a look at a microprofiler capture of a frame where your calculations are being performed?
The microprofiler can be really helpful because it lets you see when your script code is executing and you can even verify whether or not scripts are running in parallel as you expect.
Hi there, thanks for responding. I’ve actually identified the problem and cause of the stack overflow: I was sending “node” objects across the Actor Messaging API, which essentially had recursive tables inside of them, and that was causing the stack overflow. I fixed it by computing the path inside the Actor and only communicating to the main server the set of Vector3 positions. I’m using 64 actors currently and the server slowdown has been reduced by about half (still really laggy), but I solved that by just decreasing my node density and reducing the calls. I’ve verified the parallel computation through the microprofiler, but I’m still not sure though why roblox’s pathfinding seems to take longer to compute through os.clock() yet manages to cause less server slowdown than my algorithm.