Target Sorts[ | ]
Description[ | ]
Used by Weapons, Damage effects and Search Area effects for target prioritization if there are more potential targets than can be hit in a singe use.
Hints[ | ]
- Target sorts are to been seen like filters, but allowing failure. For example, if an ability is to aim for a target, this TS (target sort) will suggest a specific kind of target. If it matches, the ability will rather aim for that match, if not, the ability will simply aim based on its default setting (usually the distance, acquire attacker, units, attack target priorities, etc.).
- Target Sorts are applied sequentially meaning that stacking target sorts in different orders will result in different units being picked if there are a lot of potential targets and a proportionally few units picked
- Stacking them doesn't mean a successful result. Sometimes, the meaning of a target sort contredicts another one. For example, if your first Target Sort is to hit a random target, then the second one with Largest life, the Life one will inevitably be invalidated because you can't compare the life differences of the availlable targets since THE random target has already been reviewed in the target sorting.
- One wise modder would guess it right, most of them could be replace only the Validator type of Ts. Although, consider them as short cuts.
Target Sort Types[ | ]
To ease the display, we will simply explain the slight and unique capabilities of each. TS are small data items, they do not have a lot of fields. See the common fields below to understand the main mechanics.
Alliance[ | ]
Based on the alliance's features between the target and the sorting player. Be advised that this TS can be misleading when trying to sort Enemies, Ally, Player and neutral. This TS is not fit for it, rather use the Validator one and create the relevant Unit Filter validator for it. Yes, the Medivac uses the AlliancePassive one, but it is the limit. You can't, with this TS identify a proper enemy player, since this "enemy" could still share a relation privilege with you. View the Unit Alliance validator to learn about each alliance type.
Alliance[ | ]
- Chat
- Control
- Defeat
- Give Help
- Passive
- Power Pushable
- Spend
- Trade
- Vision
Angle[ | ]
Seeks the target that is the closest (or farthest if inverted) to the angle view of the Launch Unit.
Launch unit[ | ]
Unit from which the angle calculation starts.
Impact Unit[ | ]
Unit from which the angle calculation ends.
- Ex: A marine (Launch unit) is looking ahead. There are 2 Zealots (Impact unit) around him, one in front, and a one in the back. Since this is [Ascending], the smallest distance of angle will pick the Zealot in front as the best target.
Behavior Count[ | ]
Checks the presence of a behavior (also viewed by the number of stacks) that is potentially on the target or not.
- Note that most Behavior TS use the Location field at target location to successfully identify the target.
Behavior Duration[ | ]
Checks the duration of a buff behavior on the target.
- This be a wise TS for casting buff/debuff on a target on which the duration is almost expired, allowing the hold the buff as much as possible on most units.
Charge Count[ | ]
Checks the charge count of an ability on the target.
Charge[ | ]
The ID name of the charge. Ex: Abil/VultureSpiderMines
Charge Regeneration[ | ]
Checks the charge cooldown of an ability on the target.
Charge[ | ]
The ID name of the charge. Ex: Abil/VultureSpiderMines
Cooldown[ | ]
Checks the cooldown of an ability on the target.
Cooldown[ | ]
The ID name of the cooldown. Ex: Abil/Stimpack
- Note that by default, most ID of the cooldown and charge is based on the ID of the ability name. Also, this example shows an ability does not use any cooldown, so using it wouldn't be useful.
Distance[ | ]
Checks the distance between 2 locations.
Location[ | ]
Start point of the distance.
Unit[ | ]
End point of the distance.
Field[ | ]
Checks for a field's value on the unit.
To understand how to use it, let's base the fields on the following example:
- Blizzard use the "Ground Target" TS, which seems to verify is the target has the Ground plane array checked.
Field[ | ]
The string name of the field
- Tough, picky target sorts that can be useful if well used. This is similiar to the Unit Compare Field validator.
- Based on the example, they used the exact words: PlaneArray[Ground]
The only way to find out is to test it in a simple situation.
Value[ | ]
Numeric value of the field OR Activation value of the field.
- Numeric value would be the Height of the target for example.
- Based on the example, they used the value 1 as an activation value, meaning that if the target has the Ground plane activated, is the closest value to "Enabled".
Interruptible[ | ]
(Unsure) Looks for an Interruptible value on the target. Should it be the unit that is casting a weapon/ability and is in an Interruptible phase?
Value[ | ]
Is the only TS that owns a value field with a "Enabled"/"Disabled" value.
- Probably means that there are no more than 2 possible choices: Interruptible or not?
- Ascending may revert the result, but it's somehow pointless at this rate.
Marker[ | ]
Checks if the target has a marker or not.
- The smallest value means no markers in this case, and putting Descening seeks the one with most markers.
- Effects carries most markers, and this is why a TS like this could be use for Chain Lightning effects. If the modder wishes a chaining lightning not to hit the primary target twice, as much as possible, the lightning will only fail this TS if there are no target not carrying the marker.
Power Source Level[ | ]
Checks the power source level. It has not been tested yet, but omitting to input a behavior name could perhaps aim for any power behavior.
Power User Level[ | ]
Checks the power user level. It has not been tested yet, but omitting to input a behavior name could perhaps aim for any power behavior.
Priority[ | ]
(Unsure) Checks the "Target Attack Priority" fields on units? If this is logical, it seems trivial to have it since the Field could cover this as well.
Random[ | ]
Comes with its own function that excludes values or location. Is simply "random".
- Ascending would perhaps invert the logical result it would have been, but yet again, what is the logic of random...
Validator[ | ]
Sorts a target according to a validator.
- This TS sure promises to be one of the most useful. Not only can the modder have the target sort look for something specific, but the possibilities are limitless. At some point, you can make an ability's auto-cast system overcome the Tactical AI field on units.
Example use:
Use an enumerate area validator to examine the target location. You can make one checks the largest amount of enemies, with X [= or greater] amount of life reunited togheter to make sure the ability launches where there is the most amount of hp to destroy.
Veterancy[ | ]
Checks for the veterancy lvl on a target. It has not been tested yet, but omitting to input a behavior name could perhaps aim for any veterancy behavior.
Vital[ | ]
Checks the specified flat vital on the target.
Vital[ | ]
The vital type between Energy, Life and Shields.
Vital Fraction[ | ]
Checks a fraction of the specified vital on the target.
- While this seems not to be so different than Vital, think about it: Does a battlecruiser at 1% health has the same flat amount of life than a Marine at 1% health?
Vital[ | ]
The vital type between Energy, Life and Shields.
Common fields[ | ]
Descending[ | ]
Usually disabled by default, inverts the logic of the target sort.
- In fact, ascending means the smallest value for all target sorts.
- Since most TS are viewed as Ascending (from the smallest value to the biggest), this will permit the modder to sort the target from the other way around. Example: A Vital TS always checks the smallest life first, to the largest. Use this flag to aim for fat targets first.
Unit[ | ]
Location of unit that is checked. This field is very important and yet, most TS leave it to "None". This is because Implicitly, most weapons, effect-target abilities come with the logic that the target of the weapon/ability will be the "Target Location", and it works well. However, in other cases, using this field can handy.
- For example, setting a chain of effects and using a Search area effect will require a relative point if using target sorts on it. A test has proven that point, by requiring a search effect to aim for a Validator TS based on "Target Is enemy" validator, couldn't tell if the enemy was from the target of the ability, or the target player. Result of this act, casting the ability on an enemy unit always aimed for the "Enemy" of the casting player and casting on the player also aimed for the "Enemy" of that same caster. Using this field solved it: it said to the Search Effect, please look at the "Enemy" of the "Target" unit location.
- It is not totally clear when, or where to use this field, but running some tests will give a fast result, at the will of the modder. Leaving it "None" also allows to use this TS on most abilities, since the Target is already implicitly identified.
Value[ | ]
Default at 0, value representing the amount that will be the closest to the expected number.
- Since most TS are set to ascending, 0 means that the smallest value will be searched first. Example, the smallest amount of behaviors stacks, behavior duration, charge count, etc.
- For the TS that do not possess that field (ex: distance), it means that the TS already implicitly gives the start and end point, particularly with the location points.
It can also verify a precise activation value, like an on/off switch (0 means off, 1 means on). See the Field TS above.