Have PathFinder.search return index of destination goal
-
When passing an array of goals to PathFinder.search, it would be very useful if the returned object included the index of the selected goal. This would save CPU when you need to determine the object associated with the returned path. Currently you have to search using the last room position in the path which gets messy when using a range and multiple object types.
-
I agree the addition to the return value would be nice. I never pass game objects into a pathfinder. It's always an array of destinations (range,pos) even if it's a single destination. Associating the returned path with index of the destination was straightforward in my case and not terribly cpu intensive. My wrapper then returns the index so my higher level logic knows which target was selected.
It get's a little hairy when the pathfinding fails but that corner case is hard no matter how you handle it.
If the plugin did the index tracking it would be noticeably faster only when there are large number of destinations (>100 i'd guess, but for sure >10). Changing the plugin is a tall order.
-
@deft-code In my case I'm using pathfinder to find the closest damaged/missing road position by travel distance using range of 3 so there's a lot of wasted CPU since there's often hundreds of goals to filter by range using the path's final position. I've figured out some tricks to mitigate the CPU usage but getting the index from the results would just be so nice.
-
@TehFiend you can use findInArea to lower cpu cost instead of iterating all roads in a room. I agree this addition to know the index of target will be useful for multiple targets search.
-
@u-238 I'm not seeing a findInArea in the API but if you're referring to lookForAtArea or findInRange I don't think that will help in this case. The room positions for all of a bunker's paths are already cached in an array which is used to check for missing / damaged roads every 1000 ticks which is pretty light on CPU. Originally I was just sorting by range but was surprised with how little CPU PathFinder uses to determine closest position by travel distance despite hundreds of goals which works a lot better when walls or swamps complicate things. Even without getting the index returned and having to do the additional search, this approach is only using around 0.06 CPU per bunker on average. Getting the index would lower this even more and reduce complexity...
-
@tehfiend ah yes, I was refering to
Room.lookForAtArea(suggested that because you mentioned range of 3). agree with all your thoughts.[EDIT] ah, now I got what you mean by "travel distance 3", not roads in range of 3 from start pos but path to a road which ends at the range of 3 from closest