True Dynamic Pathfinding

well, this system i made isn't as batteries-included as something like, say, OSTW's built-in pathfinding, where you pathfind directly on a dummy bot and the library does the rest of the work for you. instead, the way this pathfinding system works is by directly supplying a start and end position - in your case, the current position of the bot and the target position respectively - and it will output a list of positions representing each point in the path it found. from there, you'll need to make your own system to get the bot to walk to the first point of the path and then keep going to the next point when it reaches the first until it reaches the end. i might be able to hack together some OSTW code of that for you if you need help with that.

it's also worth noting that this system might not work well on more than a few bots at a time - dynamic A* pathfinding is REALLY taxing on the slow workshop servers and can already take quite a long time for just one bot, but more than one bot pathfinding long distances is definitely stretching it. additionally, because of OSTW's function semantics and the fact I chose not to make the pathfinder function a subroutine, the entire system will be inlined anywhere you use it, potentially making your element count explode if you use it more than once in your code.

the thing with the going through walls and floors i'm not entirely sure of. it's probably an issue with the path refiner (tries to remove unnecessary points in resulting paths). my best guess is that server-side raycasts are done on a simplified version of the map geometry that may not have entirely correct collision. it seems far fetched but it's my best guess, because i'm fairly sure that i coded my collision checks correctly. if this happens a lot, which it can on some maps, it can sometimes help to disable the path refiner, maybe i should make a workshop setting for that. EDIT: done

also, it doesn't use walkable positions. what it actually does is when it selects the neighbors of the grid nodes, it does a line of sight check to the neighbor direction plus 0.25Y. if this succeeds, then it chooses the position of a raycast pointing down from the position that was previously checked as the position for that node on the grid. i should note that line-of-sight checks are done with raycasts instead of Is In Line Of Sight because it seemed to be more accurate.

also, about the performance - the test code that i put here (not the github library version) has the default wait threshold set to 12. it is pretty fast but it also essentially consumes the entire server capacity while pathfinding. however, setting it to 5 will in my experience, decrease the server load to the point where it will not usually go over 100, so pretty good performance. in addition, the debug mode version is not good for gauging the performance, because creating the orange spheres generates a ton of extra server load, so the wait threshold is set to 3 instead of 12 in the debug version, so keep that in mind.

it basically does A* pathfinding along a 2D grid that's overlayed over the 3D space - that is, one position in 2D space could correspond to 2 or more grid positions, to account for the 3Dness of the real environment. it also has a sort of debug mode that can be enabled to show all of the grid cells that are explored by the algorithm, but it's not included in this gamemode - let me know if you want to have the debug code so you can see it more in depth