Add features to support finding nearest spawn by Nav distance

[Cezero]

Often macros use MQ2Nav to determine the closest spawn in a pull / hunt routine and use Nav distance as a factor, resulting in many calls to Navigation.PathLength to calculate distances to a bunch of mobs within a ${NearestSpawn[]} search. These macros could be drastically simplified if MQ2Nav had features to facilitate this. Additionally, I assume there could be some optimizations that could be done if MQ2Nav was aware that it was calculating a batch of navigation paths at once (less memory fragmentation leading to OOM crashes?).

This could be exposed via a new TLO: ${NearestNavSpawn[]} that has the same API as the built-in TLO ${NearestSpawn[]} but instead of using Distance3D internally, uses the nav PathLength.

Other options might be to provide a function SortByNavDistance() that accepts a list of Spawn IDs and returns that list sorted by Navigation distance. This would be useful for macros that want to apply additional criteria to selecting which spawn to path to. Another helper function would be GetClosest() which also takes a list of Spawn IDs but returns a single Spawn ID, of the closest spawn by nav distance.

[jessebevil]

By having this as a built in function you miss out on an opportunity to do your own searches the way you want to do your own searches imho.

For example, the one I have pretty much does what you're talking about as far as finding the nearest spawn matching a spawn search with some caveats.

First, I ignore mobs with "last names" meaning, that if they have a title under their name they get ignored automatically. However, that doesn't always apply. In some cases you need to consider other things such as if MQ2Headshot is going, which puts a "Last Name" under the spawn name, and based on your class this could be different, which would require you determine what your own class is and decide if the last name given to the mob is a headshot title or a normal title. Then sometimes the last name bit doesn't apply, so you need to add exceptions. For example you may want to ignore Brass Phoenix Brigade lastname when you're in stratos, or Diseased last name when you're in the Overthere.

Beyond that is leaves little room for a list of things you want to ignore, because you're using a TLO that returns the nearest one based on spawn search. You could always use an alert list to ignore specific things I suppose.

But continuing on, you may want to consider if there is a PC near the potential nearest spawn and determine if the PC's are part of your own group, raid, or fellowship to determine if you should treat that as the primary target.

What if you want to skip spawns that are outside of a certain degree arc from you? perhaps only spawns that are 20 degrees left, and 30 degrees right of a starting location with a given initial direction at a set magnitude.

Finally, to get a path to every spawn is necessary to determine a length of the path to get to the spawn, which depending on how many things are in the area will be a rather intensive task, or not. If no path can be found for a spawn at all it makes it even more so. Which would still leave you with trying to reduce the frenquency of use based on some timer to avoid making the client repeatedly stutter. So you'd want to make getting the path length to a spawn the last thing you do, after you've checked all the other things and then you could add it to a list, map, array, etc.

I'd think that with all things considered that something like that would ultimately lack the customization nessesary to accomplish the generalized task you're wanting it to complete. Ideally there could be something created as an include, or snippet that would provide you with the features you're wanting without having it as a built in function.

Now this is only my opinion and may not be the opinion of others, but just some food for thought moving forward.