target prioritization questions...

[smoth]

my next game is going to have 2 types of units.

AI(spam units)
piloted units

I want to make my "AI" units target priority nearby units. As in the first thing that comes in range, that is their target.

I want to make my human units have their own priority where they evaluate the threat of units in sight. Say a unit can be quickly dispatched by a weapon because it is damaged. I want my unit to check it's nearby ally targets and if someone else has already targeted it, the unit will choose a different target. HOWEVER, if nothing else has targeted it, i would like this unit to quickly dispatch the target unit and then choose another target.

Should I attempt to do this at the unit script level? as a gadget it may be too expensive to have the blasted thing looping and evaluating all units. Where as at a script level I would only be checking at the pre-fire stage of the unit.

Is it possible within a reasonable performance cost to do the above concept? how do I check a nearby unit in order to evaluate if the unit needs to change target? just a simple check sphere?

[Google_Frog]

You unlock greater lua powers when you realize that there is no difference between the script level and the gadget level. You requirements look possible and I have a bunch of gadgets as examples of how to do things.

Target Priority: https://github.com/ZeroK-RTS/Zero-K/blo ... iority.lua
Config: https://github.com/ZeroK-RTS/Zero-K/blo ... y_defs.lua
Every slow update, every weapon looks at every nearby enemy unit and decides whether it is allowed to target the unit and the priority it should assign to that unit. It figures this out within the engine but it also asks lua with gadget:AllowWeaponTarget. I echoed these default priority values and they seemed nonsensical so I have replaced them.

This gadget replaces the target priority values. Currently gets a base priority from a precalculated table for each weapon/unit type pair based mostly on health/cost. Within the gadget there are some modifiers for things such as prioritizing damaged units and ignoring stunned units. There is room for more sophisticated priority handling such as attempting to use burst damage more efficiently.

An important limitation of this gadget is that the priority only seems to do anything when the weapon does not know what to do. If the unit has an attack command on a target within range then its weapons are going to try to shoot at that unit. This includes attack orders that units assign to themselves due to things such as patrolling or the roam movestate. I do not know whether automatically acquiring a target is affected by these priority values.

In theory you could make a global command to 'paint' enemy units and make them high priority (or low priority) targets for all of your units.

Overkill Prevention: https://github.com/ZeroK-RTS/Zero-K/blo ... ention.lua
Script Change: https://github.com/ZeroK-RTS/Zero-K/blo ... h.lua#L134
Overkill prevention prevents high reload units from wasting shots at units which are already going to die. It does this by keeping track of how much damage a unit is about to receive and prevents other high reload units from shooting at it. The handled units generally have high reload time, high flight time and a very high chance to hit their target. Also the gadget tells Target Priority about doomed units and makes them a low priority target.

Overkill prevention should only be used with high reload time weapons because it can introduce a firing delay. If many units try to fire at one thing then only the first one may be left unblocked. If the units did not have an attack command then they will have to wait until the new target numbers from target priority arrive in the next slowupdate. If they did have an attack command then they will only retarget once the enemy unit dies or the shot timeout (your hand-estimated maximum flight time for the projectile). It is a gadget to use when not shooting for a few seconds is better than shooting at a doomed target.

Another major drackback is that it does not think bubble shields exist. It comes with a state toggle so people can identify and workaround problem cases.

Don't fire at radar: https://github.com/ZeroK-RTS/Zero-K/blo ... _radar.lua
Script Changes: https://github.com/ZeroK-RTS/Zero-K/blo ... l.lua#L118
This gadget demonstrates what is required to effectively change a weapons target cats on the fly. It uses gadget:AllowWeaponTarget to allow or deny a target, although this does nothing for attack commands. It checks what a unit is aiming at and edits its attack command if it is aiming at the wrong unit. It has to use script.BlockShot because this seems to be the only reliable way to make a unit not fire at something.

This thorough hax causes the gadget has fewer major limitations than the previous two. There can be a firing delay if the unit picks an illegal target but it will not be stuck not firing. It even distinguishes player orders from automatic orders, if you give it an attack command and set it to hold fire then it will be stuck not firing until the target becomes legal. If the unit only has illegal targets in range it will look a bit confused and have some fluctuating commands.

A statetoggle is included here as well. The gadget is only used for a few units with; high reload, range longer than LOS, no AoE.

Set Target Command: https://github.com/ZeroK-RTS/Zero-K/blo ... e_move.lua
Here is a gadget which is not quite on topic because it just implements a new command. Set target is a command independent of the ordinary command queue. It is basically an attack command with no control over the units legs.

If nothing else is it an example of what you can do with Spring.SetUnitTarget.