Goonhub
MULEs SOMETIMES work. Sometimes. They seem to be able to find their way to some areas but grump at other areas, even if it just came from said area.
Looks like path-finding is broken in general. On a related note, how functional is the GPS command? If that is perfectly fine, then the coders could probably just use that for bot pathfinding, and if not, then that's just more stuff that the coders can analyze to see why the heck things are borked.
After a quick search of the 2016 public release, a comment in the parent code for bots seems to indicate that the bots use A* pathfinding. Here's the wikipedia article.
https://en.wikipedia.org/wiki/A*_search_algorithm
I'm really just spitballing ideas because I can, and I can't view any error logs for the bots failing to pathfind, so yeah, heck. But, maybe it's possible that the process for finding a path takes too long, so it gets shut down before it can actually reach its goal. This would align with some observations that I saw whilst trying to get the MULE to work.
On Cog1, I had sent it from QM to Research, and it got there successfully. However, when it tried to return home, it grumped. I then tried sending it to Engineering - no dice. But, when I told it to go to Medbay, bang, it worked. Note Cog1's shape - it's a big C, essentially. Perhaps the A* algorithm tried searching for its destination - QM/Engineering - both East and North of Research - both of which are pretty long hallways with a lot of branching rooms. However, Research is right next to Medbay so it wouldn't have to search very far; QM is at the very end of the hallway on Cog1, so there's only 1 way that the MULE can search.
There are probably ways to optimize the pathfinding here, if that is actually the case. I'm not too sure as to how it could be optimized, though, so maybe just extending the time that the algorithm can search for its destination would suffice?
Looks like path-finding is broken in general. On a related note, how functional is the GPS command? If that is perfectly fine, then the coders could probably just use that for bot pathfinding, and if not, then that's just more stuff that the coders can analyze to see why the heck things are borked.
After a quick search of the 2016 public release, a comment in the parent code for bots seems to indicate that the bots use A* pathfinding. Here's the wikipedia article.
https://en.wikipedia.org/wiki/A*_search_algorithm
I'm really just spitballing ideas because I can, and I can't view any error logs for the bots failing to pathfind, so yeah, heck. But, maybe it's possible that the process for finding a path takes too long, so it gets shut down before it can actually reach its goal. This would align with some observations that I saw whilst trying to get the MULE to work.
On Cog1, I had sent it from QM to Research, and it got there successfully. However, when it tried to return home, it grumped. I then tried sending it to Engineering - no dice. But, when I told it to go to Medbay, bang, it worked. Note Cog1's shape - it's a big C, essentially. Perhaps the A* algorithm tried searching for its destination - QM/Engineering - both East and North of Research - both of which are pretty long hallways with a lot of branching rooms. However, Research is right next to Medbay so it wouldn't have to search very far; QM is at the very end of the hallway on Cog1, so there's only 1 way that the MULE can search.
There are probably ways to optimize the pathfinding here, if that is actually the case. I'm not too sure as to how it could be optimized, though, so maybe just extending the time that the algorithm can search for its destination would suffice?