extend prio system

[xanunderscore]

it's still not perfect but this is a big improvement imo

background

mobs used to be divided into two-ish categories: forbidden (prio is negative) and not forbidden (prio is not negative). then only the highest non-forbidden mobs were considered as priority targets for AOE target calculation. this system works fairly well but lacks granularity. for example, the way i used to handle uninteresting fate mobs was to just not add them to the enemy list at all.

explanation

really we just add two new negative priorities, or four depending on how you look at it, because two of them are renamed.

• -1: we don't care about this enemy, or pending effectresults indicate that it's about to die, etc etc. doesn't count as an AOE target
• -2: enemy is invincible, doesn't count as an aoe target
• -3: enemy is out of combat or otherwise uninteresting to us. AI will pick a different target if you manually target one of these.
• -4: enemy is actually forbidden. AMEx will refuse to use actions on it (unless they are emergency prio) and auto autos tweak will stop autoattacking it as well.

as a result of these changes, the "OK targets" list continues to start at priority 0, but now the "not OK" targets list begins at -3, giving us room in the PotentialTargets list for actually uninteresting and low priority targets without needing to drastically redesign the system.

additionally, the set of potential enemies is stored in a fixed size array in AIHints. enemies are guaranteed to have even SpawnIndexes between 2 and 198, so enemy lookup is now constant time instead of linear (although the performance loss from a linear search on a list of 90 items is negligible anyway...)

you will also notice that i removed some code that was forcibly adding Part-type targets to the enemy list since we add those by default now. i verified in titan normal that Part targets have even spawn indices the same as regular battlenpcs

also

i would like to add "current target priority" as an argument to the Execute function of RotationModule, because right now the difference between -1 and -2 priority is purely cosmetic, and it will be up to the rotation modules themselves to decide what actions to use on a -1 priority target (-2 should always be ignored)

[awgil]

I assume this is an oversight and should be [100]