Data/Behaviors/Buff

# Buff (Behavior)

## Buff

(Editor Screenshot) need screenshot of UI left of unit showing several buffs

### Description

Buffs are applied to units and can do a huge range of effects ranging from enabling and disabling Abilities, Behaviors and Weapons to periodically applying an effect tree or altering the timescale for the unit it is applied to. If you want a passive skill or aura use this.

### Hint

* Each unit can only have 64 different buffs on it at once so consider having a buff that has the effect of a combination of several non-stacking buffs replacing them if all the non-stacking buffs are present.
* Table view should be favored for filling up Accumulator fields, as the detailed and wizard view do not offer it.

### Lag Issues

One problem with the buff behavior is the possibility of lagging the game according to certain circumstances. For example, if we take the Mothership, which has a buff that periodically scans around for units to cloak, nobody will notice any type of lag. This can be explained by the fact that you can only spawn 1 Mothership and that's the end of it. However, if you create 200+ Mothership units, then you would start noticing (perhaps not for strong computers) lag spikes. The shorter the period timer is, the greater lag you get according to the number of units using it.

* Possible work around: If the aura or periodic effect is intended to search enemy units, one can replace it by a weapon that allows movement and is hidden. Disable flags in the option such as Only fire at attack target / Only fire while attacking / Linked Cooldown and the Can Initiate Attack flags (preventing to approch the target). Give it 360 degrees arc, the desired range, and use validators in the first effect. If an attack ability is required, make a dummy one that is disabled (because the weapon can still attack if attack is disabled).
* Using an Effect-Target Ability will not work. Apparently auto-cast doesn't work with transient flag, which ruins any form of "aura" capability.
* Another way would be to set validators in the search result that limits the applicance of the given buff behavior. On that buff, make it last forever, but with a validator (remove) that calculates the range from caster.

### Some behavior/behavior classes cannot be disabled

As far as tested, some behaviors cannot be disabled, such as wander, resource, jump and Click Response.

* This is probably a lack of content.

### Some fields won't stack

Some fields, such as **Weapon Scan Limit**, **Critical Attack Chance** will not stack upon having multiple stacks of the behavior.

## Example Usage

### Marauder - Slow

A buff is applied by the marauder's weapon once the upgrade is researched. The buff multiplies the speed of the unit it is applied to by 0.5 (halves) making the unit slower until the buff expires.

#### URL

As the marauder is already present in the editor no URL is needed

### Mothership - Cloak Field and Mothership - Cloaking Field Effect

The Mothership unit has Mothership - Cloak Field under the Behavior - Behaviors - Behavior field which creates a periodic Search Area effect that in turn applies the Mothership - Cloaking Field Effect buff to surrounding units using a validator on the applied buff that disables it when applied to the Mothership. The applied buff cloaks units by enabling cloaking in the **Behavior - Modification - State Flags** field. The duration of the cloaking buff is just longer than the period between applying the search area effect to reapply it to prevent units from momentarily decloaking.

#### URL

As the Mothership is already in the editor no URL is needed

### Turret Swapping

For starters, using the turret modifications from a behavior is oriented toward failure in most cases. You cannot add a new "turret" that's not innate to the unit (from that buff behavior), and yet, if you put it innate, you get another problem that causes the unit to mix up both, causing invisible rotation. Further more, disabling the extra turret from the beginning also fails, while destroying the unwanted turret's actor causes the turret to stay on spot while its unit moves away, detaching the turret Z from the model (this happens when no other turret on the unit is availlable). Summary: The problem is that these fields aren't fully configured by Blizzard to allow the modder to use them properly. Can you have 2 different turret data on a same unit? Quite possible; Just keep in mind that the main problem lies in the turret's actor. The synchronisation between its creation and its attachment to the unit's turret data is very static. Here's how to work around this issue.

The rules and receipe:

1. In order for a weapon to work with its turret, it is IMPERATIVE that those weapon/turret are innate to the unit. It is sadly impossible to use a custom one from a buff behavior's modification.
2. Two weapons with 1 different turrets each will not work togheter. Of course both can shoot, but one of the two will invisibly rotate to shoot. Only 1 weapon must use Turret Z with its turret actor, or both weapons must use the same turret data. It is possible, however, to disable one weapon while the other one takes action, as long as the Turret Actor of the disabled weapon/turret is destroyed, leaving the control of the turret Z attachement point of the model to the secondary weapon/turret. Also, you might not notice it at first, depending of the index of the weapon. Weapons with higher digit index will have their turret take priority over the first ones.
3. Disabling a turret with a buff behavior doesn't do anything about freeing the Turret Z attachement point for use, it is only the turret actor that matters (unless using the Turret.Disable actor event to destroy it within the turret actor itself). You can destroy the turret actor from within the turret actor itself (not with behavior event, they don't work. Instead use ability morph or turret disable), or you can destroy it from the CActorUnit itself or any macro attached to it by using the target box.
4. If you are to destroy an unwanted turret actor, make sure that another turret is active, otherwise this will do some glitchy model parts wearing off the model itself when moving.
5. Turrets actor can only be created valid upon "Turret.Enable" msg type. There are no other ways to create them if need be. To work with that, one can put a buff behavior that disables the secondary turret and make sure that the turret actor contains the "turret.disable/destroy" event action in its events. Now, when an upgrade or something allows the secondary weapon to shoot, have this buff behavior disabled by the other source.
6. While the morph ability doesn't destroy the Turret Actor, the fact that the new morphed unit doesn't own the said turret is considered as a "TurretDisable" event, which can be used in the actor to destroy it upon morphing.

* This methodology is the way to go, until someday Blizzard dev team should decide to look upon turret modification data and improve it.

### Tests Conducted with the "Cannot die" State Flag

Tests conducted on a command center revealed the interactions for the flag "cannot die".

* Damage effect:
	+ Kill flag, failed at killing the unit.
	+ No Behavior Response flag failed at killing the unit.
	+ Kill "remove" succeeded but failed if the unit is bugged at 1 hp.
* Modify Unit effect:
	+ Remove (Modify flag) succeeded.
	+ Any vitals set in negative failed at killing the unit.
	+ Salvage (Modify flag) failed.
* Launch Missile effect:
	+ Impact Death (default, and assuming most other types) failed at killing the unit.
	+ Remove Death succeeded and still does if the unit is bugged at 1 hp.
* Train ability:
	+ Training cancel and training complete (death types of the same name) failed.
	+ Training cancel and training complete (death type remove) succeeded.
* **Has a bug**
	+ When a damage effect has the unit reach 1 hp and taps on it, the Cannot Die state makes the unit's hp become glitched, hence negating any source of damage/kill effect. This bug even occurs after the behavior with the state is gone, leaving the unit into a conflicted state. It appears that the 1 hp at which the unit is stuck, is the epicenter of the bug. A test conducted has shown that using a modify unit effect, setting life to 1 unglitched the unit. In otherwords, it changed the hp of the unit from bugged 1 hp, to normal 1 hp, which would let any killing effect, damage amount proceed. Also, regenerating life brings it back to unbugged.
	+ The bug can also be reproduced by creating a behavior with cannot die flag, and have the field Validator (Remove): Target Life > 1. Naturally, the buff gets out at one hp, effect resulting from the cannot die blocking the damage. However, try killing this unit again, you won't be able to (even if the buff is totally gone).
	+ A visual difference is noticeable on the health bar when the unit is at normal 1 hp versus at the bugged 1 hp. The normal still displays a partial shade of health, but the bugged health bar is completely depleted. This state looks like some kind of purgatory in the eye of the editor, which sees the unit dead and not at the same time and invalidating any damage dealt against it.

### Tooltip can indicate the current stack

Use a text key to indicate the current amount of stacks on a unit.

## Fields Description

### (None): Death Type

Overrides any death type on the unit to this type, sending the actor this specific death message when the unit dies.

* This can override a unit's DeathType and will ignore the death type of the killing damage effect.

* The “Remove” death type may not be overridden in this way.
* Default value is “Unknown”, meaning “don’t override”.

### (None): Face

* Uses data from the Buttons data type

### (None): Periodic Display Effect

* Damage effect used to calculate modifications to status bars over the duration of the buff
* (not sure) if Modify Unit effects can also be used

### (None): Periodic Effect Rate Multiplier

Increases the execution speed of Periodic Effects on buff behaviors.

* Does not affect rates located on some effects (such as Create Persistent, Create Healer or Launch Missile). Does not affect Weapons either. In fact, only affects the said behavior, nothing else.
* It is unfortunatly possible to bug the periodic timer with an accumulator. For example: Assuming that you can decrease the rate to 0,01%, the period timer will attempt to complete its periodic time scaled at 0.01% before running any newer value (which takes forever), thus making it way too long before the next, updated period duration. To solve this, make sure to refresh the behavior.

### (None): Reveal Unit -

Does litterally the same thing than the "Reveal" State flag from modifications, and works independently.

* Which unit to reveal from the tree of effects.
* Able to be used to track units through the fog of war

### (None): Stack Alias

If two buffs of the same StackAlias are applied to the same unit, they will share a Max Count, prioritizing the lower one. If their total count exceeds the shared max count, the game will begin removing stacks, starting with the buff with the lowest **StackAliasPriority** and then the shortest duration. This will occur until the total stack count matches the shared max stack count.

### Behavior: Acquire Player - Effect

* Reference effect for the acquire player value

### Behavior: Acquire Player - Value

* Reference player to assume weapon acquire. Particularly useful in some cases which a mind controlled unit is to be spared or not by its former allies. An example use is to simply create a behavior that changes the ownership, and put this field to "Target". The player who's against this unit won't engage it, and even respond in flee if attacked by it.

### Behavior: Buff Flags

* **Channeled:** Provides Channel, binding the Caster to this ability/weapon while the channel is going. If the channel stage can be interrupted, taking any other action will interrupt this channel.
* **Channeling:** Sets up to destroy this behavior if any Parent effect (Create Persistent/Create Healer) or parent buff behavior with "Channeled" flag on should stop providing channel. In the absence of any Channeled parent, this flag being enabled will instantly destroy the behavior at its creation. Using this flag in pair with the "Channeled" flag above is pointless, as an interrupted Channeled effect still gets to be destroyed anyway, ending with the same result. This flag is usually best used on a child buff behavior to clear up left overs that would last longer than then the Channel providing source, exempting the necessity of setting addtional data for clearing it.
* **Countdown:** Used in conjunction with the field **UI: Display Countdown**. If checked, will display a bar on the UI that will "empty" over the Buff duration. If not checked, will display a bar on the UI that "fills up" over the Buff duration.
* **Disable During Construction:** means that the buff is disabled if the unit is still under construction. This flag is not as strong as the Validator (Disable) field, as a unit that just started constructing will still let a "Behavior.On" event slip through. If planning to use an actor that shouldn't trigger if the unit is under construction, rather use the validator section instead.
* **Extend:** If not checked, reapplying a buff will reset the duration specified in the field **Stats: Duration**. If checked, will add the maximum duration with any remaining time (60 Duration + 30 Remaining = 90 Duration). Only extends when the maximum amount of stacks is reached. Also, if using stacks, this will only extend the duration of 1 stack while the other ones will expire from the normal duration. If it is required to extend all stacks, check the **Refresh Stack** flag. Else, for what's mostly possible to manipulate here, it is impossible to add an individual extended time to each stack in hope that each extended durations will expire gradually, except in one very case: if the stacks are limited to 1 caster at the time, each caster granting a stack may extend its owned stack.
	+ Now if we're talking about using Accumulators, it is possible to do otherwise with a Behavior accumulator. Not only you can put a limit to the extend time, but you do not need to wait to have all the stack to extend their duration and you can regenerate new stacks that are not Refreshed, with a longer duration to each stacks (meaning that they will each expire individually). So far, accumulators can do exactly everything this flag can't.
* **Leech Use Damage Response Condition:** Forces any "Leech" entries, such as resource leech/vital "Leech" on buff behaviors to be treated the same way "Damage Handled" would be filtered on the Damage Response field. For instance, this field requires the chance field > than 0 (and the chance will also be an odd for a successful leech), requires validators to pass if any, requires location to Match Attacker (this is logically needed in 100% cases ?), etc. This is useful when using the behavior to create a leech fraction of damage, but at the same time, limit its use. For example, if you want the Zergling melee attack to leech off Biological Units but not Robotic Units, then you can, instead of setting a vital fraction on the weapon's damage effect, use the buff behavior, select the Required Effect Array if needed for a specific weapon/ability. That being said, this flag does not affect any current Leech Fraction set on any damage effects used by the behavior's holder.
* **Refresh Stack:** If checked, reapplying a buff will reset the duration specified in the **Stats: Duration** field of all instances of that buff on that unit. This will cause all stacks of a buff to remain as long as it keeps getting reapplied before running out or getting removed through other means.
* **Remove Exhausted Damage Response:** whether the Damage Responses **Exhausted Effect** should trigger when the damage response **Modify Limit** is reached. (in HotS used a lot by shield effects when they break). Also prevents the behavior from being removed when a damage limit is reached.
* **Update Duration While Disabled:** Causes the duration specified in the **Stats: Duration** field to continue to count down even if the buff is disabled

### **Behavior - Modification**

Main field of this behavior class. Contains all the categories of buff/debuff stats that affects units.

* Important rule to remember: Enable > Disable. This means that any behavior/ability or whatsoever that is disabled by 1000 sources will never beat a single buff behavior that "Enables" it. This can be useful when disabling every abilities but enabling only some of them.

#### (None): (Modification) - Abil Categories Disable

Disables abilities by their Category when the buff is present.

#### (None): (Modification) - Abil Categories Enable

Enables abilities by their Category when the buff is present.

#### (None): (Modification) - Abil Tech Alias Disabled

Disables abilities by their Tech Alias when the buff is present.

#### (None): (Modification) - Abil Tech Alias Enabled

Enables abilities by their Tech Aliaswhen the buff is present.

#### (None): (Modification) - Attack Target Priority

* Increases or decreases the value of the **Combat: Attack Target Priority** of a unit used by weapons and AI for target choice

#### (None): (Modification) - Behavior Category Duration Factor

* Multiplier applied to the **Stats: Duration** of behaviours belonging to the specified categories

#### (None): (Modification) - Damage Taken Fraction

* Multiplier applied to damage taken
* Works like a damage response that modifies the fraction of damage taken but easier to set up

#### (None): (Modification) - Damage Taken Maximum

* Applies a clamp to the maximum amount of damage a unit can take from a single attack

#### (None): (Modification) - Damage Taken Minimum

* Applies a clamp to the minimum amount of damage a unit can take from a single attack

#### (None): (Modification) - Damage Taken Scaled

* Modifies how much damage a unit takes from a single attack that is multiplied by **(None): Modification - Damage Taken Fraction** modifiers

#### (None): (Modification) - Damage Taken Unscaled

* Modifies how much damage a unit takes from a single attack that is not multiplied by **(None): Modification - Damage Taken Fraction** modifiers

#### (None): (Modification) - Kill XP Bonus

* Modifies the **Combat: Kill Experience** value for the unit

#### (None): (Modification) - Move Speed Base Maximum Bonus

* Used to change the maximum speed of a unit.

#### (None): (Modification) - Radius Multiplier

* Changes the unit's radius (this usually interacts with structures and other units).

#### (None): (Modification) - Resource Damage Leech

Is a calculated amount of resource from which the behavior's buffed unit will generate everytime it attacks another unit. It can be fun to use this field, however, the lack for formulaes makes it very random at some extent. Further testing would help clarify.

* Is based on the damage "Kind", including abilities.
* Works only with "inflicted damage". Negated damage doesn't count (such as Damage responsing 0 damage).
* Is based on the behavior's carrier's damage amount, the enemy type, its armor. The less damage is inflicted, the less amount is taken.
* The formulae is not fully known, but some facts seems relevant:
	+ A cyclone being attacked generates more cash for than a thor being attacked?? Yet their cash quantity seems premade. Same goes for "Structures".
	+ The number imputed in this field seem to be a factor number.
	+ Some units grants vespene, others not. Their cost doesn't seem to be the variable either. For example, an armory which cost 100 vespene does not return any vespene gaz.

#### (None): (Modification) - Vital Damage Gain Score Array

**Value**

* (Unknown) Which score from the Score Values data type to modify?

**Validator**

* (Unknown) The Validator used to determine if the buff can modify the score?

#### (None): (Modification) - Vital Damage Leech Score Array

**Value**

* (Unknown) Which score from the Score Values data type to modify?

**Validator**

* (Unknown) The Validator used to determine if the buff can modify the score?

#### (None): (Modification) - Vital Max Decrease Affects Current

* If the buff modifies the max vitals, enabled vitals in this field will be subtracted from the current vital by the modified amount when the buff is removed

#### (None): (Modification) - Vital Max Increase Affects Current

* If the buff modifies the max vitals, enabled vitals in this field will be added to the current vital by the modified amount when the buff is applied
* Disable these values for buffs used by items to prevent healing by dropping and re-equipping item.

#### (None): (Modification) - Weapon Scan Limit

Sets a cap on the Minimum Scan range of any weapon used by the unit.

#### Ability: (Modification) - Abilities Disabled

* Disables using specific abilities when the buff is present (no known cap)
* Can be used for spells like WC3 Silence which prevents the casting of several spells but not all.

#### Ability: (Modification) - Abilities Enabled

* Enables specific previously disabled abilities
* Not all that useful unless you want to renable only a few abilities at a time without using validators or requirements
* Use this field to re-enable the Attack ability of units inside the container of transports to allow them to attack while the transport is moving

#### Ability: (Modification) - Ability Classes Disabled

* Disables all abilities of a certain class eg. Arm Magazine or Effect - Target

#### Ability: (Modification) - Ability Classes Enabled

* Enables all previously disabled abilities of a certain class eg. Arm Magazine or Effect - Target
* As abilities can already be easily regulated with requirements this field is of limited utility

#### Behavior: (Modification) - Attribute Changes

**Attribute**

* What attribute behaviours the buff adds
* Useful for items

**Points**

* How many points for each attribute are added to each attribute

#### Behavior: (Modification) - Behavior Categories Enabled

* Enables previously disabled behaviour categories

#### Behavior: (Modification) - Behavior Classes Disabled

* Disables certain behaviour classes
* Disabling buff causes the behavior to strobe on and off very fast as it temporarily disables itself

#### Behavior: (Modification) - Behavior Classes Enabled

* Enables previously disabled behavior classes

#### Behavior: (Modification) - Behaviors Disabled

* Disables specific behaviours
* Can be used to create conditional feedback mechanisms or bistable states for other behaviours

#### Behavior: (Modification) - Modify Flags

* **Detected:** makes the unit targetable despite having cloaking active
* **Disable Abilities:** prevents the unit with the buff from using any abilities
* **Disable Weapons:** prevents the unit with this buff from using any weapons
* **Enable Attack:** allows the unit to attack even if abilities have been disabled
* **Enable Move:** allows the unit to move even if abilities have been disabled
* **Hide Change UI:** Adjustments by the buff with not be shown in the UI (ex. If a buff gives +25% damage, and this is checked, the buff will not show under the weapons damage.
	+ Affects only the buff. Other buffs will still show in the UI.)
* **Modify Movement:** (Unknown)
* **Modify Override Attack Target Priority:** (Unsure) Ignores attack priority checks when acquiring target with a weapon.
* **Orders Uninterruptible:** makes queued orders unable to be cancelled?
* **Reveal:** reveals the buff'ed behavior unit to the behavior's caster.
* **Share Vision:** gives to the caster players the unit affected by the behavior's Line of Sight
* **Suppress Movement:** Immediately interrupts and prevent the unit from moving. This does not disable the Move ability. Additionally, effects like Apply Force and Launch Missile will fail under this state. Exceptionally, one can set the mover of the launch missile effect to "Ignore Movement Suppression" from its flags.
* **Suppress Turning:** stops the unit from turning
* **Warpable:** allows model deformation by physics effects eg. the Mothership - Vortex Event Horizon of the Mothership - Vortex ability

#### Behavior: (Modification) - Queue Count

* Increases the number of units that can be trained/upgrades researched at one time
* Used by the terran Reactor add-on

#### Behavior: (Modification) - Queue Size

* Increases the max number of units to train/upgrades to research that can be queued at once

#### Behavior: (Modification) - Rate Multiplier Array

* **Charge:** Increases the speed at which charges are generated by the factor entered here.
* **Cooldown:** Increases the speed at which cooldowns cool down by the factor entered here. This can be used to make items and buffs that give "Cooldown Reduction" as known from many MOBA games.
* **Creep:** increases the rate creep is generated by units with a Creep Source behaviour
* **Morph:** (Unsure) adjusts the speed at which the unit morphs (Mutant Larvae in beta used to use this to morph faster before they were removed)
* **Progress:** increases the rate of Buildable and Warpable to increase constructing and warping rates.(This effect is increased by unit time scale regardless of this buff's time scale source).
* **Queueable:** increases the speed at which queued stuff is finished
* **Spawn:** (Unknown) increases the rate of the Spawn behaviour / Arm Magazine ability?

#### Behavior: (Modification) - State Flags

* **Benign:** means that the unit is not automatically targeted by weapons
* **Bury:** Adds the **Burried** flag to the unit, which will be considered by target filters. The unit is still considered targetable without detection, which is why this flag usually pairs up with the **Cloak** flag.
* **Cannot die:** Marks a unit as “not able to die” unless the behavior is removed. Though the use of damage responses is able to achieve a similar effect, death responses can only prevent death by damage. This behavior state prevents death for any reason, e.g., life set to 0. This state provides a simple alternative for a trigger-based death prevention system.
* **Cloak:** makes the unit become untargetable by enemies without a detector and creates the cloaking visual (blueish by default but can be set under the Global Configuration actor type). Pairing up this flag with the flag **Bury** will remove the blueish visual.
* **Daze:** stuns the unit without disrupting channelled effects
* **Detector:** makes the unit become identified as a detector in the user interface. It can be then disabled by other behaviours with **Suppress Detection** flag.
* **Generate Threat:** raises a unit's attack target priority, so AI units and units with Priority Target Sorts on their weapons or abilities will be more likely to acquire the unit.
* **Hallucination:** sets the unit status to hallucination which is used by the **Combat: Kill Hallucination** field of Damage effects
* **Hide Waypoints:** hides queued and active waypoints of the unit from the UI
* **Ignore Player Allied Flags:** The unit will now treat allied players as enemies (used on Dark Archon Spells).
* **Ignored By Placement:** Makes the unable to block or affect the placement of other unit/structure. This affects footprints as well, you can build directly through the unit.
* **Invulnerable:** sets the unit to invulnerable which is used by search filters to exclude most things targeting the unit
* **Is Kiting:** AIFlag to temporarily mark the unit as a kiting unit (used by cyclone). To work, this must pair up with a minimal value in the AI Kite Range field used on unit data, and will only work on Computer users (AI).
* **Line Movement:** The unit will ignore pathing and try to move in a straight line towards its current orders.
* **No Draw:** prevents the unit's actor from being drawn, making the unit altogether invisible to all players.
* **Passive:** prevents automatic weapon acquisition (Attack moving will not attack). This seems to affect auto-cast abilities as well.
* **Radar:** makes the unit become identified as a radar. It can be then disabled by other behaviours with **Suppress Radar** flag
* **Resistant:** Dummy flag that can be used for filtering purposes. (used by the war3 mod for Resistant skin Behaviours)
* **Reveal Progress:** (Unknown)
* **Silence:** Disables all abilities except attack and move
* **Stasis:** gives the unit the Stasis flag, modifying the targeting and search results accordingly
* **Stun:** disables the unit from moving, attacking or using abilities without affecting the order queue
* **Suppress Army Select:** Prevent the unit from being selected when using the "Select Army Units" button on the UI.
* **Suppress Attack:** Immediately interrupt and prevent any weapons from attacking. Does not disable the Attack ability and does not recall magazine units that were out before state was applied.
* **Suppress Build On:** stops construction of buildings on the unit (eg. Terran Refinery being built on a Vespene Geyser).
* **Suppress Cloak:** disables the cloaking of the unit making them targetable and removing the cloaking visual
* **Suppress Collision:** reduces the collision radius of the unit to 0 allowing it to pass through other objects with collision. Does not disable footprints
* **Suppress Combat:** removes any recent history of this unit dealing/receiving damage. This could compare with validators of type "Damage taken/dealt over time". A difference can be observed if the unit inflicts 0 damage. The Sentry Hallucination behavior uses this field.
* **Suppress Damage Visibility:** stops the unit being revealed to the enemy through the fog of war when attacking an enemy unit
* **Suppress Detection:** Disables behaviors marked with the **Detector** flag (used to disable the unit from detecting cloaked/buried units)
* **Suppress Drop Off:** prevents a unit with cargo from unloading
* **Suppress Energy:** stops the caster using anything that costs the energy vital
* **Suppress Energy Regeneration:** prevents energy from generating/degenerating
* **Suppress Fidgeting:** stops the UI: Fidget+ stuff under the Units data type from occurring
* **Suppress Food Made:** negates any food the unit might supply
* **Suppress Food Used:** negates any food the unit might use
	+ Useful for summoned units
* **Suppress Gate Enforcement:** (Unsure) HotS field for units to ignore the footprint by lane gates. Maybe usable in sc2 with the unit flag **Gate**
* **Suppress Invulnerability:** makes the unit vulnerable (removes the Invulnerable filter)
* **Suppress Item Usage:** prevents the use of items in the Inventory containers
* **Suppress Kill Credit:** Prevents a unit from granting kill credits or killed resource credits to the killing player. Useful for creating hallucinated units.
* **Suppress Life:** stops the caster using anything that costs the life vital
* **Suppress Life Regeneration:** stops hit points from being regenerated/lost
* **Suppress Passenger:** stops any effects/abilities made by the passenger like bunker held units attacking
* **Suppress Radar:** Disables behaviors marked with the **Radar** flag
* **Suppress Requirements:** (not sure) removes requirements for abilities and effects?
* **Suppress Shield Regeneration:** stops shields regenerating/degenerating
* **Suppress Shields:** stops the caster using anything that costs the shield vital
* **Suppress Tech:** As far as test, this prevents add-on buildings from giving their attachement tech to the main unit that's attached to it. Putting this state on the main structure is meaningless, it really has to be on the attached component part.
* **Suppress Threat:** negates a unit's attack target priority, so AI units and units with Priority Target Sorts on their weapons or abilities will not acquire the unit if other targets are available.
* **Suppress XP Gain:** disables any Veterancy behaviour from accumulating gained experience
* **Suppress XP Grant:** stops the unit from giving experience on death
* **Suppress XP Sharing:** stops a killing unit from sharing experience with nearby units
* **Suppress Unit Use Line Of Sight:** Suppresses the line of sight flag on the unit, allowing it to see past doodads, cliffs and units that block vision
* **Transient Morph:** Set the "Transient" flag on any Morph abilities used by the unit. Used by the Viper's Abduct ability when dragging out burrowed unit.
* **Ultravision:** If the game uses time and it is night, the unit will use night time sight range defined on the unit. This is mainly used in Warcraft 3 upgrades for Night Elves.
* **Uncommandable:** makes the unit unable to respond to orders given by a player (they can still be commanded by triggers).
* **Undetectable:** prevents the buried/cloaked unit being detected
* **Unit Attribute Off+**: removes the specified unit attribute from the unit which used by filters
* **Unit Attribute On+**: adds the specified unit attribute to the unit which used by filters
* **Unradarable:** prevents the unit from being detected with radar
* **Unselectable:** makes the unit unable to be selected by a player
* **Unstopable:** prevents the unit from getting pushed when colliding with other units
* **Untargetable:** makes the unit unable to be the target of attacks and abilities

#### Behavior: (Modification) - Subgroup Priority

Increases or decreases the priority of the subgroup the unit is in when selected

* Adding means the unit will be more selected in the prior subgroup (it is not like abilities auto-cast priorities in which the smallest numbers means the first).
* Be careful when using this flag temporary on units, as for all abilities that are casted in subgroup should all have their command flag: "Send To Selection" enabled. Otherwise this field will cause some subgroup missynchronisation when casting abilities.

#### Behavior: (Modification) - XP Multiplier

* Multiplication factor applied to the **Combat: Kill Experience** of killed units

#### Behavior: (Modification) - XP Scaled Bonus

* Value applied to the **Combat: Kill Experience** of killed units which scales with **Behavior: Modification - XP Multiplier** bonuses

#### Behavior: (Modification) - XP Unscaled Bonus

* Value applied to the **Combat: Kill Experience** of killed units which does not scale with **Behavior: Modification - XP Multiplier** bonuses

#### Combat - (Modification) - Attack Speed Multiplier

* Alters the period of the weapons by a percent
* Formula is 1/1+(1n^x) where n is the value of the multiplier and x is the number of stacks
* (The effect of stacking is multiplicatory)
* Maximum attack speed increase cap is set by the Attack ability of the unit

#### Combat - (Modification) - Critical Attack Chance Multiplier

* Multiplication factor applied to the **(None): Critical Chance** of weapons on the unit with the buff
* (Unknown how this field stacks)

#### Combat - (Modification) - Critical Attack Chance Scaled Bonus

* Percentage points added to the **(None): Critical Chance** of weapons on the unit with the buff that is affected by **Combat - Modification - Critical Attack Chance Multiplier** values

#### Combat - (Modification) - Critical Attack Chance Unscaled Bonus

* Percentage points added to the **(None): Critical Chance** of weapons on the unit with the buff that are not affected by **Combat - Modification - Critical Attack Chance Multiplier** values

#### Combat: (Modification) - Damage Dealt (Scaled)

* Amount of damage added onto each kind of damage that is affected by Damage Dealt Fraction
* Stacking is purely additive so 2 stacks of 10 with a Damage Dealt Fraction of 2 with give (damage +20) x 2 +20 added damage

#### Combat: (Modification) - Damage Dealt (Unscaled)

* Flat amount of damage added onto each kind of damage irrespective of Damage Dealt Fraction
* Stacking is additive

#### Combat: (Modification) - Damage Dealt Attribute Multiplier

* Percent of damage added/subtracted to each unit attribute

#### Combat: (Modification) - Damage Dealt Attribute (Scaled)

* Amount of damage added onto each unit attribute that is affected by the sum of the **Combat: Modification - Damage Dealt Attribute Multiplier** modifiers

#### Combat: (Modification) - Damage Dealt Attribute (Unscaled)

* Flat amount of damage added onto each kind of unit attribute irrespective of the **Combat: Modification - Damage Dealt Attribute Multiplier** modifiers

#### Combat: (Modification) - Damage Dealt Fraction

* Percent of damage added/subtracted to each damage kind eg. Damage - Quad adds +4x damage to all damage kinds
* Stacking is additive

#### Combat: (Modification) - Damage Dealt Maximum

* Sets the cap for the maximum damage the unit can do in a single damage event

#### Combat: (Modification) - Damage Dealt Minimum

* Sets the cap for the minimum damage the unit can do in a single damage event
* Good for armor ignoring stuff

#### Combat: (Modification) - Death Response

**Chance**

* Chance for the death response to trigger when the unit dies eg. Exploding Barrel (Large) Explosion

**Cost**

* Standard cost fields associated with the death response

**Effect**

* Effect cast when the unit with the buff is killed

**Relationship**

* Diplomatic relationship of killer required to trigger the death response

**Type**

* Determines what types of death triggers the death response
* The type of death caused by each damage effect can be set under the Effect - Death field of the Damage effect
* Note that unit removed by trigger does not create unit dies event but still treated as remove type death. This will cause remove type death response so disabling it is recommended.

#### Combat: (Modification) - Heal Dealt Additive Multiplier

* Heal Dealt Additive Multipliers are added together. 1.0 would be a 100% increase in healing, -0.5 would be a 50% decrease in healing. Modifies in % any Create Healer rate launched by this unit, Exemple: SCV repair ability is an Effect - Target ability that uses a Create Healer effect.
* All Heal Dealt/Taken fields seem to increase the heal on Create Healer effects (because it heals more for an equivalent time) and yet, they only speed up the rate of delivery since the consumed vital spent is accordingly increased. This is otherwise for the Modify Unit effect (which requires "Is Heal" flag enabled), their vital modifications can be increased from those fields with no backfire.

#### Combat: (Modification) - Heal Dealt Multiplier

* Heal Dealt Multipliers are multiplied together. 0.5 would halve the healing, 2.0 would double the healing. Modifies in % any Create Healer rate launched by this unit,
* All Heal Dealt/Taken fields seem to increase the heal on Create Healer effects (because it heals more for an equivalent time) and yet, they only speed up the rate of delivery since the consumed vital spent is accordingly increased. This is otherwise for the Modify Unit effect (which requires "Is Heal" flag enabled), their vital modifications can be increased from those fields with no backfire.

#### Combat: (Modification) - Heal Taken Additive Multiplier

* Heal Dealt Additive Multipliers are added together. 1.0 would be a 100% increase in healing, -0.5 would be a 50% decrease in healing. Modifies in % any health Create Healer rate received on this unit (impact unit),
* All Heal Dealt/Taken fields seem to increase the heal on Create Healer effects (because it heals more for an equivalent time) and yet, they only speed up the rate of delivery since the consumed vital spent is accordingly increased. This is otherwise for the Modify Unit effect (which requires "Is Heal" flag enabled), their vital modifications can be increased from those fields with no backfire.

#### Combat: (Modification) - Heal Taken Multiplier

* Heal Dealt Multipliers are multiplied together. 0.5 would halve the healing, 2.0 would double the healing. Modifies in % any health Create Healer rate received on this unit (impact unit),
* All Heal Dealt/Taken fields seem to increase the heal on Create Healer effects (because it heals more for an equivalent time) and yet, they only speed up the rate of delivery since the consumed vital spent is accordingly increased. This is otherwise for the Modify Unit effect (which requires "Is Heal" flag enabled), their vital modifications can be increased from those fields with no backfire.

#### Combat: (Modification) - Total Damage Multiplier

* Calculates the total damage of the specified kind and adds this multiplicated value from it. Exemple: A unit with has a behavior with this field's melee array set to 0.1 receives 50 melee damage from any source will receive an increased damage (amplified by 10% according to the 0,10), so 60 total damage in the end. It can also be used in the negative form to decrase the damage.

#### Combat: (Modification) - Vital Gained from Damage Taken - Damage Kind

* Amount of vitals the unit receives when it takes damage from each kind of damage
* Can be used to reduce the damage taken by certain damage kinds
* Tricky detail: The vital is gained before the damage is dealt. For example: if recovering 0.5 shield (implicitly per 1 damage) when shield is full, the damage taken will still be fully taken by the shield, because the shield recovered that damage amount while being at 40 (refilling nothing at this point), then the damage is dealt to the shield.

#### Combat: (Modification) - Vital Leeched from Damage Dealt - Damage Kind

* Amount of vitals gained per damage event based on damage kind
* Unable to do % so more of a supplement to a vital than a significant contributor

#### Movement: (Modification) - Acceleration Bonus

* Flat value added to the acceleration
* Stacking is additive

#### Movement: (Modification) - Acceleration Multiplier

* The % of the base acceleration speed
* (Unknown how stacking affects it)

#### Movement: (Modification) - Additive Attack Speed Factor

* Alters the period of the weapons by a percent
* The period change caused by multiple stacks is additive
* The classification of this field as movement and not combat is probably an oversight by Blizzard

#### Movement: (Modification) - Additive Move Speed Factor

* The % speed value of a unit's base speed
* Stacking is additive
* (not sure if the **Movement: Modification - Movement Speed Bonus** is applied before or after)

#### Movement: (Modification) - Deceleration Bonus

* Flat value added to the deceleration
* Stacking is additive

#### Movement: (Modification) - Deceleration Multiplier

* The % of the base deceleration speed
* (Unknown how stacking affects it)

#### Movement: (Modification) - Movement Speed Bonus

* Value added/subtracted from the movement speed of the unit
* Added after Speed Multiplers are factored.
* Stacking is additive

#### Movement: (Modification) - Movement Speed Minimum

* Minimum speed clamping value
* Used by Mothership - Vortex

#### Movement: (Modification) - Movement Speed Multiplier

* The % speed value of a unit's base speed.
* Stacking is Multiplicative.
* Units gain **Movement: Modification - Movement Speed Multiplier** before Speed Bonus is added

#### Movement: (Modification) - Plane Delta

* Alters the Movement - Plane Array for the unit
* 1 adds and -1 removes being able to be targeted on that plane
* Used by Pheonix - Anti Gravity Height and Hercules - Rescue Pods (Unnamed)

#### Movement: (Modification) - Snare Multiplier

* Modifies the effects of negative speed bonuses and multipliers (Positive amounts amplify/increase the effects of a snare).
* Example Use: Apply a positive snare multiplier on a positive buff. When units gain a negative speed buff (aka snare), the effects of the snare will be amplified to counter the effects of the positive buff.
* Formula: Base Speed \* Positive Speed Multipliers \* (Negative Speed Multipliers ^ Snare Multiplier) + Positive Speed Bonus + (Negative Speed Bonus ^ Snare Multiplier)
* Formula Example: 3 Base \* 1.1 Positive Speed \* 0.9 Negative Speed ^ 1.5 Snare = 3 \* 1.1 \* 0.9 ^ 1.5 = 3 \* 1.1 \* 0.85 = 3.3

#### Resource: (Modification) - Resource Harvest Amount Bonus

* The flat increment to the amount harvested per interval spent gathering

#### Resource: (Modification) - Resource Harvest Amount Multiplier

* The % increment to the amount harvested per interval spent gathering
* (Unknown how stacking affects it)

#### Resource: (Modification) - Resource Harvest Time Bonus

* The increment/decrement spent per gathering interval

#### Resource: (Modification) - Resource Harvest Time Multiplier

* The % increment/decrement spent per gathering interval
* (Unknown how stacking affects it)

#### Unit: (Modification) - Detect Filters

* Filters for determining valid targets that can be detected

#### Unit: (Modification) - Detect

* Radius at which the unit with the buff can detect cloaked/buried units

#### Unit: (Modification) - Detection Arc

* The angle centred in front of the unit that determines the field of detection
* A 90 degree angle would be 45 degrees to either side

#### Unit: (Modification) - Detection Bonus

* Amount added onto the unit's existing detection radius

#### Unit: (Modification) - Energy Armor Bonus

* Amount the energy vital armor is adjusted

#### Unit: (Modification) - Energy Armor Multiplier

* Amount the energy vital armor is multiplied by
* (Unknown how stacking affects it)

#### Unit: (Modification) - Energy Damage Ratio Bonus

* Value added/subtracted from the damage to energy conversion ratio of energy armor

#### Unit: (Modification) - Energy Damage Ratio Multiplier

* Multiplication factor applied to the damage to energy conversion ratio of energy armor
* (Not sure how this field stacks)

#### Unit: (Modification) - Height Time

* The times taken for the unit to reach the set height and return to the default height

#### Unit: (Modification) - Height

* The height to which the unit is lifted/lowered

#### Unit: (Modification) - Kill Bonus

* (Unknown) bonus given to score on kill?

#### Unit: (Modification) - Life Armor Bonus

* Amount the life vital armor is adjusted

#### Unit: (Modification) - Life Armor Multiplier

* Amount the life vital armor is multiplied by
* (Unknown how stacking affects it)

#### Unit - (Modification) - Lost Bonus

* (Unknown) bonus to score when unit dies?

#### Unit: (Modification) - Radar Arc

* The angle centered in front of the unit that determines the field of the radar
* A 90 degree angle would be 45 degrees to either side

#### Unit: (Modification) - Radar Filters

* Filters determining which units appear on the radar

#### Unit: (Modification) - Radar

* Radius for the radar detection (highlighting units that are not in the line of sight)

#### Unit - (Modification) - Shield Armor Bonus

* Amount the shield vital armor is adjusted

#### Unit - (Modification) - Shield Armor Multiplier

* Amount the shield vital armor is multiplied by
* (Unknown how stacking affects it)

#### Unit: (Modification) - Shield Damage Ratio Bonus

* Value added/subtracted from the damage to shield conversion ratio of shield armor

#### Unit: (Modification) - Shield Damage Ratio Multiplier

* Multiplication factor applied to the damage to shield conversion ratio of shield armor
* (Not sure how this field stacks)

#### Unit: (Modification) - Sight Bonus

* Bonus given to the unit's line of sight
* Apparently cannot exceed 16 total sight radius

#### Unit: (Modification) - Sight Maximum

* Clamp total sight to this maximum value

#### Unit: (Modification) - Sight Minimum

* Clamp total sight to this minimum value

#### Unit: (Modification) - Sounds

* Sounds that replace the ones set under the Unit actor

#### Unit: (Modification) - Supplies

* Supplies added/taken adjustment
* Field of interest for making certain units free supply wise

#### Unit: (Modification) - Time Scale

* Time scale % adjustment to the unit's timescale relative to **Stats: Time Scale Source - Value**
* Stacking is multiplicatory
* Affects cooldowns, movement speed, animations, periods, durations of buffs (if buff timescale is based on the unit it's applied to), basically affects the speed of everything on the unit.
* Cannot be set to 0 (0.01 Minimum) which equivalently freezes the unit making it good for effects like that where you don't want the unit animating
* Known bug as of patch 1.3 If a buff that modifies unit time scale is removed before expiring the animation timescale will not be reset.
* Known issue as of patch 1.3, unit's under building or warping will finish sooner but their vital progress rate will not increase(unit will not finish with full health).

#### Unit - (Modification) - Unit Name Override

* Replaces the name of the unit with the specified text string from the [[Text Editor]

#### Unit: (Modification) - Vital Max Additive Multiplier

* Adds an amount to the unit's max vital based on a % of the unit's max vital
* Field of preference for units that gain vitals with kills/levels
* (Unknown how stacking affects it)

#### Unit: (Modification) - Vital Max Bonus

* Adds a fixed amount onto the max of the vital
* Used by Psi Shield (Tosh) to add a temporary shield

#### Unit: (Modification) - Vital Maximum Fraction

* Adds an amount to the unit's max vital based on a % of the unit's max vital
* Field of preference for units that gain vitals with kills/levels
* (Unknown how stacking affects it)

#### Unit: (Modification) - Vital Regeneration Bonus Scaled

* Amount of vital regen adjusted
* Dependent on the unit's regeneration delay
* Used to give the buff a constant vital drain eg. Ghost - Cloak

#### Unit: (Modification) - Vital Regeneration Bonus Multiplier

* Multiplication factor applied to the vital regeneration of a unit
* (Unknown how stacking affects it)

#### Weapon: (Modification) - Turret Enable

* Enables a previously disabled turret of the unit

#### Weapon: (Modification) - Weapon Minimum Range Bonus

* Adjusts the minimum range of the unit's weapon eg. could be used to make siege tanks have no minimum range

#### Weapon: (Modification) - Weapon Range Bonus (All weapons)

* Adjusts the range of the unit's weapons eg. bunkers giving +1 range to loaded units

#### Weapon: (Modification) - Weapon Range Bonus (Melee weapons)

* Adjusts the range of the unit's weapons if they have the **Melee** option flag enabled

#### Weapon: (Modification) - Weapon Range Bonus (Non-melee weapons)

* Adjusts the range of the unit's weapons if they have the **Melee** option flag disabled

#### Weapon: (Modification) - Weapon Scan Bonus

* Adjusts how fast the weapon scope can track a target

#### Weapon: (Modification) - Weapons Enabled

* Enables a previously disabled weapon
* Weapons can automatically be set to disabled using the Weapon - Options field under Weapons

#### Weapon: (Modification) - Weapons - Turret

* Turrets given to the unit, associated to the weapon in the same array of the behavior.
* Unlike a given Weapon (given by behavior), putting a turret here only will not create it on the unit. This means that the unit data must ALREADY have the turret in its weaponry. If a weapon should depend of this turret, it will not work either if this section doesn't contain the same turret as the unit has.
* A unit that already has a turret, cannot support a second one for another weapon. This causes a weird conflict. For example, if you add an innate weapon + turret on a siege tank, and use the turret/weapon combinaison of the behavior, the older turret will override and cause weird behavior to the newest turret.

#### Weapon: (Modification) - Weapons - Weapon

* Weapons given to the unit
* Used by the A.R.E.S. Warbot in the WoL campaign to give it a choice of 3 different weapons

### Behavior: Player - Effect

* Specific effect that the scope of which is to be used in combination with the **Behavior: Player - Value** field to determine the player

### Behavior: Player - Value

* Changes ownership of the affected unit to the value
* (Not Sure) what Outer does but is presumed to swap to any player other than the caster, target or source
* Can be used for confuse type abilities by setting all targeted units to hostile and swapping their Attack abilities
* Does not change the owner in the eyes of filters in some particular cases, unless the behavior is innate /or not based on a duration. Further more, if a behavior that makes the owner change is disabled by another behavior, this ownership may just not work in some cases. The limitation of this field are not fully detailed, but still leaves this field to be seen as very picky. A true owner change would be instead with a modify unit effect.

### Behavior - Replacement

* Determines the priority of how the buffs are replaced
* **Farthest Distance:** (Unknown)
* **Shortest Duration:** replaces the stack with the least amount of time remaining

### Behavior: Replacement Location

**Effect**

* Specific effect that the scope of which is to be used in combination with the **Behavior: Replacement Location - Value** field to determine where the behaviour is known as being replaced at
* Used by **Mothership - Vortex Event Horizon**

**History**

* (Unknown)

**Value**

* Location at which the behaviour is known as being replaced at
* Important for using Apply Force effects via buffs
* Used by **Mothership - Vortex Event Horizon**

### Behavior: Requirements

* The Requirements that need to be met to enable the behaviour

### Behavior: Validators (Disable)

* Validators that if return false disable the behaviour

### Behavior: Validators (Remove)

* Validators that if return false permanently remove the behaviour until it is reapplied

### **Combat: Damage Response**

Contains a lot of field related to a response occuring when the unit using this behavior is being damaged by a "Damage" effect.

* An effect dealing 0 damage is not considered.
* There is an interesting way of setting damage response which causes linked units to share damage.
	1. The Simplest way is to set up the Handle Value to "Absorbed". Change the Damage fraction to something lower than 1 and then, put a damage effect in the handle value with 0 damage (or more if additional damage is required). By doing so, the carrier of the Buff damage response will send back any damage to any "Target" (set on the Damage effect) based on the damage fraction.
	2. This method works equally well with the Enum Tracked Units effect, which can "Distribute" the damage to all tracked units.

#### (None): (Damage Response) - Attack Type

Modders can change the damage multipliers of each Attack Type against each Armor Type in the Game Data.

#### (None): (Damage Response) - Block Chance

When an effect is executed, the game will query the response structure on the impact unit and check its Block Chance and any validators.

* Can interact with Accumulators.

#### (None): (Damage Response) - Damage Type

Target Filters for Damage Type in Game Data.

* Using Target Filters on Damage Types allow users to configure all the damage and AoE damage effects in the game. It can also decide whether certain damage effects can ever damage certain targets.
* For example, by simply filtering out “Ally” targets in every Damage Type, users can easily make all weapons in the game no longer splash allies. This is useful when creating a Co-op mod as it would need to be built on top of multiple other mods, and the AoE weapon and spells in these other mods have various friendly fire effects.

#### (None): (Damage Response) - Deflect Chance

Deflection is almost identical to Block Chance except the effect that would have occurred will be duplicated and shot back to the caster.

* The deflected effect will have caster and target properties reversed and will count as a shot from the original target unit to the original caster unit. The damage bonus setting in the reflected effect tree will still be set to use the original caster’s damage bonuses.
* Another difference between deflection and blocking is that effect trees will only evaluate deflection once each. If an effect has passed the Deflection check once, the rest of the effect tree will not check deflection chance again, even if there are following effects in the effect tree that have the ValidateImpactDeflection flag checked.
* Can interact with Accumulators.
* In order for this field to work, the damage effect or/and launch missile effect must have their "Validate Impact Deflection" field enabled to interact with this damage response.
* Does not trigger the handle response value, since the deflection send it all back.

#### (None): (Damage Response) - Evade

* Marks the damage response as having an evaded state able to be detected by Effect Compare Evaded validators

#### (None): (Damage Response) - Handled Value

Defines what value should be transferred to the handled effect. For example, adding an handled effect such a damage effect, even with 0 damage, will still trigger a retained amount of damage determined by the damage response. It is the same principe in which enum tracked units effect leading a damage effect can distribute that damage. It is suggested to use a dummy damage effect and to fill the pertinent **Required Effect In Chain Array** field to avoid overflow.

* **None:** Will not transfer any
* **Absorbed:** damage absorbed by the response. Ex: if reflecting a damage taken to target, this is rather useful to **Defender location**, so the damage received by the buff holder.
* **Original:** the original damage before it was changed by any behaviours. Ex: if doubling a damage dealt, this is rather useful to **Attacker location**, so the damage dealt by the buff holder.
* **Remaining:** the remaining damage after this behaviour has absorbed.

#### (None): (Damage Response) - Missing Chance

Attack Modifiers can also add the NeverMiss property to a weapon effect tree

* If a weapon effect tree says a weapon can miss, when the weapon fires, it will check the Missing Chance on both the attacker and defender sides. It will then mark whether the effect will miss based on validators and chances set in the response structure.
* Ground units attacking targets on higher cliff levels can also have a bonus miss chance, which can be modified in Game Data.
* If a weapon’s effect tree has been marked as “Missed”, the weapon will not execute impact damage, nor any Orb effects on impact.
* When a weapon misses, it will send an Actor Weapon event with “Missed” as its sub name. This way, modders can decide whether they want to capture this event to create “Miss!” floating text on the unit or display a dodge effect.

* Can interact with Accumulators.

#### (None): (Damage Response) - Modify Limit Vital Max Fraction Array

The percentage of the max vitals of unit the damage response can take before the damage response becomes exhausted

* When Exhausted, the behavior is removed.

#### (None): (Damage Response) - Modify Score Array

Modify specified score when the behaviour prevents damage

* **Value**
	+ (Unknown) Which score from the Score Values data type to modify? **Validator**
	+ (Unknown) The Validator used to determine if the buff can modify the score?

#### (None): (Damage Response) - Prevent Categories

Used to prevent subsequent responses from triggering that match any of these categories

* Enhancement | Evasion | Procedural | Reduction Shield
* Used in conjunction with **Provide Categories** field

#### (None): (Damage Response) - Priority

* Priority to consider which damage response should trigger first when the unit has multiple damage response behaviours.

#### (None): (Damage Response) - Provide Categories

Used to check against existing response prevention requests.

* Enhancement | Evasion | Procedural | Reduction Shield
* Used in conjunction with **Prevent Categories** field

#### Combat: (Damage Response) - Chance

* The chance to perform the damage response
* If set at 0 before the game starts, upgrading it will never work since the whole damage response system is dropped. The other values related to damage response will remain, but will be unable to link with the chance value.

#### Combat: (Damage Response) - Cost

* Costs associated with the damage response (same as all other cost fields)
* Still continues, even if the behavior is disabled.
* Beside Modify Unit effects, is the only location in the behavior that can affect the **Cost** field of the behavior (the generic one) when triggered. However, this requires 2 things: same link location, and a valid entry (any numbers) in the **Cost** field. It does not matter how much you put in that **Cost** field, as this **Damage Response Cost** field will override it.
* If Cost field (generic) is on cooldown, this field won't work if both location links match.

#### Combat: (Damage Response) - Damage Value

What damage value is used in the damage calculations

* **Original Amount:** the amount of damage to be done before any other damage responses modified it.
* **Remaining Amount:** the amount of damage left to be done, possibly modified by other damage responses.

#### Combat: (Damage Response) - Exclude Effect Array

* List of Damage effects that cannot trigger the damage response

#### Combat: (Damage Response) - Exclude Effect In Chain Array

* Considers the effect dealing damage and all its parent effects. To use this field, it is only required to put the child effect. Useful in some cases where the damage isn't directly inflicted, (ex: created units).

#### Combat: (Damage Response) - Exhausted

* Effect performed when the damage response finishes when the **Combat: Damage Response - Modify Limit** is reached

#### Combat: (Damage Response) - Fatal

* If enabled means the **Damage Response - Handled** is only applied if the damage received would kill the unit eg. Valerian02a hero KO associated buffs
* Does not work if **Combat: Damage Response - Location** is set to Attacker
* To get a damage response on killing a target it is necessary to use a damage response on attacker that applies a buff to the target unit with a fatal damage response on defender. Both damage responses will be triggered by the same damage effect despite the second buff only being applied after the first damage response

#### Combat: (Damage Response) - Handled

* The effect performed in response to damage.
* To refer to the unit that had the behavior and sent the Handled effect later on, use Source.

#### Combat: (Damage Response) - Ignore

* Ignores any damage dealt over the amount set

#### Combat: (Damage Response) - Kind

* Types of damage that trigger a damage response

#### Combat: (Damage Response) - Location

* In what situation the Damage Response - Handled effect is applied
* **Attacker:** applies the damage response when the unit is attacking another unit
* **Defender:** applies the damage response when the unit is attacked

#### Combat: (Damage Response) - Maximum Clamp

* Caps the maximum damage a damaging effect tree can cause

#### Combat: (Damage Response) - Maximum

* Only damage below the value triggers a damage response

#### Combat: (Damage Response) - Minimum Clamp

* Sets a floor for minimum damage a damaging effect tree can cause

#### Combat: (Damage Response) - Minimum

* Minimal damage needed to be taken to trigger a damage response.

#### Combat: (Damage Response) - Modify Amount

* Flat amount of damage subtracted or added from any damaging effect tree eg used by **Sentry - Guardian Shield**

#### Combat: (Damage Response) - Modify Fraction

* The % Amount of damage taken from any damaging effect tree
* If set to 0 the unit takes no damage from any attacks eg. **Valerian02a - Hero Death Prevention**

#### Combat: (Damage Response) - Modify Limit

Maximum amount of damage that can be absorbed by the damage response before the behaviour is removed using the exhausted effect.

* When reached, the behavior will be removed.

#### Combat: (Damage Response) - Modify Minimum Damage

* Ensures that the above 3 fields are applied even if it results in damage below the Damage Minimum set under Gameplay Data

#### Combat: (Damage Response) - Require Effect Array

* Effect the unit needs to be subjected to for the damage response to occur.
* Particulary used by **Massive Void Ray Vulnerability**
* Requires a Damage effect that has at least 0.001 in the **Combat: Amount** field
* Effects are logically OR (the damage effects has to be one of the effects listed here).
* As far as tested, this field mostly works if the effect is in the chain of effect of this behavior. Effects that are external should be indicated in "Effect In Chain Array" instead.

#### Combat: (Damage Response) - Require Effect In Chain Array

* Considers the effect dealing damage and all its parent effects. To use this field, it is only required to put the child effect. Useful in some cases where the damage isn't directly inflicted, (ex: created units). Exemple use: If it is required to block the damage from Purification Nova (Disruptor's ability), this field will be required. The field **Require Effect Array** wouldn't be able to trace this effect and will not trigger.

#### Combat: (Damage Response) - Target Filters

* Determines the required attributes of the damaging unit that trigger a damage response eg. Immune to Friendly Splash excludes neutral and enemy damage

#### Combat: (Damage Response) - Validator Array

* Validators that must return true to trigger a damage response

### Cost: Cost +

* Standard cost fields associated to the behavior. Within the behavior, only triggering the **Damage Response Cost** may affect this field and only if there's a common link entry in the proper cooldown/charge field. Letting this whole field empty will return it invalid for any cooldown modification attemps. Other means such as removing, adding, refreshing, disabling/enabling it, etc. will never affect it, except cooldown time start when the behavior is first applied. In fact, a disabled behavior still gets to have its **Cost** cooldown to refresh over time. Can prevent the **Damage Response** from working if both costs match in link and location, EVEN if **Damage Response Cost** has a lower cooldown and is ready for use.
	+ Can also only be modified from a modify unit effect and with the same principe: There must be minimaly an entry in the cost type (in either used one cooldown, vitals, resources or charge) so, not 0. Otherwise, the modify unit effect will never be able to modify it. Also, fraction value on the modify unit effect is relative to the total of the buff's same field value. Example: 0.5 vital on the effect will consider 50% of the current same vital fraction on the buff. It will not check the flat amount, as this kind of field is a different brand. Vital/Resources entries can be triggered when modified by a modify unit effect.
* Its only use, is probably to put a UI cooldown visual on passive button on units, using this behavior on the passive behavior's entry. In that matter, a passive being used can use the modify unit effect to animate the cooldown. Can also be validated by a Unit Compare Cooldown validator, which could invalidate effects created by this behavior if it's still on cooldown (because on cooldown doesn't mean the behavior is disabled, so it still runs its effects). Unfortunatly, the UI display part seems only to work for Cooldown, and not charges.
* Does not prevent the behavior from granting its buffs.
* Is used by Immortal's Barrier system.

### Effect: AI Notify Effect

* (Unsure) Used to point to a effect that will cause Notify Effect for the AI

### Effect: Effect - Final

* Effect created when the behavior is removed
* Not applied if the buff is disabled and then removed

### Effect: Effect - Initial

* Effect performed when the buff is present on the unit. This effect outpasses any behavior's validator fields because it occurs before the behavior itself. The only way to block it would be either to prevent the behavior from being applied, either using a validator on the effect itself.

### Effect: Effect - Periodic

* Effect that is performed each **Stats: Period**

### Effect: Expire Effect

* Effect that is performed if the buff is removed by the **Stats: Duration** reaching the end

### Effect: Refresh Effect

* Effect that is applied if the buff is refreshed before expiring
* (Not sure) if the **Extend** flag is needed under **Behavior: Buff Flags**

### Stats: Duration Bonus Maximum

* (Not Sure) Maximum duration the buff can obtain when refreshed
* (Not Sure) Maximum time added to the duration each time it is refreshed

### Stats: Duration Bonus Minimum

* (Not Sure) Ensures a buff always has at least this duration when refreshed
* (Not Sure) Minimum time added to the duration each time it is refreshed

### Stats: Duration Override

#### Index

* Priority at which point the duration is assigned. For example, if entry 0 and 1 affects a common unit, entry 0 will override anything below, even if further indexes come after.

#### Duration

* Used to override base duration based on validators
* Accepts accumulators
* If the validator is true, the duration is ovrrided only at buff creation. This never changes anything if the behavior is simply refreshed.

#### Validators

* The Validators for the **Stats: Duration Override - Duration**

### Stats: Duration Random Maximum

* Maximum random factor between which a value is added onto the duration bonus
* Bug warning: attempting to use this field as a data reference will have the wrong terminaison as such; <d ref="Behavior,BehaviorIDname,DurationRandomMin"/>

### Stats: Duration Random Minimum

* Minimum random factor between which a value is added onto the duration bonus
* Bug warning: attempting to use this field as a data reference will have the wrong terminaison as such; <d ref="Behavior,BehaviorIDname,DurationRandomMax"/>

### Stats: Duration Shield

* The DurationShield field is multiplied by the unit's total shield bonus (from all buffs that modify damage with a limit) to obtain a bonus duration for a buff.

### Stats: Duration Vital Bonuses

* The DurationVitalArray and DurationMaxVital array fields are multiplied per vital type by the unit's current and maximum vitals respectively to contribute towards the bonus duration as well.
* Quote from Blizzard -"We haven't run into a case where these fields were needed internally but we thought that they'd be something that the community might use so that's why they were included."

### Stats: Duration

* How long the ability lasts before it expires

### Stats: Flags

* **Always Use Game Text:** If the behavior should be **Hidden From Default UI,** allows the **Unit Name Override** modification value to show (otherwise, any name change never displays when the behavior is hidden from UI).
* **Hidden From Default UI:** determines if the buff icon is hidden or visible in the UI

### Stats: Kill Credit - Value

* Which unit gets the kills made by the unit with this buff added to their kill count

### Stats: Maximum Stack Count

* Maximum number the stack of the buff can go up to
* Able to go up to >1000 but game becomes very laggy over 256 if the buff modifies the unit
* Useful if the buff is to act as a counter
* When the hatchery pops larvas from the Queen Larva Spawn, the ability adds 3 stacks of a buff behavior of a buff that has 0 maximum stack count for the release phase. (Unsure) Perhaps this is intended to spend each buff stack seperatly by the Spawning behavior which casts 1 larva per stack.

### Stats: Maximum Stack Count Per Caster

* Maximum number of stacks one caster unit can add

### Stats: Period Count

* Number of times the periodic effect is executed

### Stats: Period

* The period between **Effect: Effect - Periodic** effects
* If an upgrade should modify it while this period is in progress to completion as the oldest period, will have to pass before the newest value if that one is shorter. Ex: Period is set at 10. An upgrade sets it 3. It will have to pass the 10 second (game time) before executing every 3 seconds. Applying the behavior anew or refreshing it will set it right. Also, in some ultimate situations, such as putting a behavior on a unit that starts at map initialization, and then changing its period from a map initialization upgrade along with it just might not work as an initial effect, because it is way too fussy to be execute in such a short time.
* As is it seems, the Period time resets to 0 when refreshing ONLY if a new period duration is set (from upgrades or periodic rate multiplier). Otherwise, refreshing the buff never prevents the period from executing in their due time.

### Stats: Tech Alias

* An Alias for the Behavior to link multiple Behaviors or Units to a Requirement Node.

### Stats: Time Scale Source - Effect

* Effect reference for the unit's time scale source

### Stats: Time Scale Source - Value

* Affects the behaviour's time scale for duration and period but doesn't appear to modify the behavior's modify unit timescale (probably because if the time scale is based off the source it would create an infinite loop).

### Stats: Vital Regen Based on Vitals Percent Remaining - Amount Missing

* The fraction of the max vitals of a unit that when missing will cause an increment in vital regeneration
* Number of increments = % vital missing/% Amount Missing value as an integer

### Stats: Vital Regen Based on Vitals Percent Remaining - Regen Modification

* Amount of vitals regenerated per second per increment based on the amount of vital lost

### Stats: Vital Regen Based on Vitals Remaining - Amount Missing

* The vitals of a unit that when missing will cause an increment in vital regeneration
* Number of increments = number of vital missing/Amount Missing value as an integer

### Stats: Vital Regen Based on Vitals Remaining - Regen Modification

* Amount of vitals regenerated per second per increment based on the amount of vital lost

### UI: Display Countdown

* Players to which the buff timer appears when the unit is selected or the cursor is hovering over.

### UI: Display Shield

* (Unsure) Used by custom UI layouts to display damage response shields? (Used by Garrosh ArmorBuff & Tassadar Archon in Heroes)

### UI: Herd Node

* The herd node from the Herd Nodes data type applied to the unit

### UI: Tooltip

* The text displayed if the mouse cursor is moved over the buff icon ingame

## Related

* Abilities
* Attack
* Behavior
* Behaviors
* Effects
* Launch Missile
* Apply Behavior
* Remove Behavior
* Damage
* Transfer Behavior
* Validators
* Weapons