Data/Effects/Modify Unit

## Modify Unit

(Editor Screenshot) needs pic of auto refinery/changeling

### Description

A miscellaneous effect capable of performing a huge range of functions. Functions include modifying charges, adjusting unit height, mimicing team colour, changing ownership permanently, removing missiles, replenishing and harvesting resources and healing and dealing damage

### Hint

* Good all rounder and an interesting economy alternative
* Health modifiers are not supported by buff behavior heal multiplier/addtive increases/decreases.
* Salvage functionalities can be used as either some kind of kill resource leech, or refund from death. Simply add it to a buff behavior, either in the final effect or death response (or even "fatal" damage response). What's important to remember is that by default, the salvage will refund both players: the killer and the player itself. To correct that, one must add a validator on the effect that specifies which player filter is accepted.

## Example Usage

### Automated Refinery - AutoHarvestVespene (Unnamed)

Part of the automated refinery that removes 4 resources from the unit and harvests 100% of the amount removed

### Changeling - Disguise Mimic

Changes the team colour of the unit to look like that of a nearby enemy player via the mimic flag after a search applies a switch that choose either type of unit to create; What happens is that the original mimic is killed removed and passes on its timed life buff to a newly created unit of the imitated race type. The created unit is modified by the flag. See Mimic Flag below for more details.

### Vulture - Replenish Mines (Modify Mines charge count)

Adds 100% of the charges to the Deploy Spider Mine ability

### Modify Turret manipulation theory

In may come in some cases that a turret must be directed from a **modify turret** field. Usually, this is rather useful for effect-target abilities (such as Cyclone's lock on ability) and probably not for weapons since those have their own associated turret within the weapon's field in unit data. That being said, turrets are used for attacking structures mostly because Pathing - Footprints won't allow any unit to turn in any case. Even the Tree of life in warcraft 3, which seems to attack melee and turns itself is still using a turret for that matter. What do you do if the structure should cast an ability that's 0 arc degree (requires turning), let's say, Effect-Target? You would probably rely on this effect here to perform some kind of "look at engage" action, on which the structure turns itself to cast at the point. There are things to remember when dealing with this kind of set-up:

1. Your ability, even if the first effects uses a modify turret to aim at location, won't work if the Arc of the ability does not pass. It would even be recommanded to use 360. Since the unit is unable to turn, it cannot cast the ability, thus unable to use modify turret to allow to face the casting direction. This also come with the fact, that a channeled ability will probably force the modder to accept the fact that the channel is already started before that the turret is even turned to target point. This is the case because you cannot have **modify turret** start the effect chain, leading to the main channel effect/buff. Of course, a series of set ups, hence starting with a dummy channel, that pops that modify unit (turret) effect, then when the aim complete creates an effect that runs the next channeled effect and ends the first one, could work. But then again, you probably can't either have a relevant UI for the progress bar based on that effect. In summary, the modify turret action is in this case, only useful to give the appearence of casting "at that" point.
2. Anticipate putting a preemt delay of 0.0625 (or approximate) on each ability using the modify turret. In the preparation stage, this can work. The reason being: swaping right away from weapon to ability, on a same turret seems to be unfit, in terms of editor content. This will cause the ability wait the weapon to end up using the turret, while it already runs the Modify Unit effect that should turn that turret. Oddly, the aim complete will succeed as if the turret did turn, but in visual, you shall not see the turret turn to the updated direction. It will be stucked at where the weapon was ending using it. The prescribed delay is fairly just enough to allow the turret data to be passed on from a weapon to an ability.

### Known Bugs

* It appears that the "Copy" Flag from the **Modify Flags** field works, but in an inverted way. For instance, a *Launch Location* is where the information is copied from, sent to the *Impact Location*, which is the unit that should copy life, veterancy, kills, etc. A test has shown that those 2 locations invert the result: the Impact Location sends its information to the Launch Unit, and so, the launch unit gets to copy the Impact location. Warning: This only concern this very flag, the rest of the fields from this effect are fine with the Launch/Impact logic.
* Resource hint says: "*Specifies an amount of resource to harvest from the Launch Unit if it has a resource behavior*". It's not Launch Unit, it's Impact Unit in fact.

## Fields Description

### (None) Facing Adjustment

Manual rotation of the facing angle of the impact unit.

### (None) Facing Location

Which location is used as a reference to modify the facing of the Impact unit.

### (None) Facing Type

Choose between copying the facing or facing the location unit.

### Cost - Cost

Modifies the cost of an ability or a behavior. Positive number means extend/add cooldown duration, while negative means reduce/remove cooldown duration.

This can be handy for abilities that are "Player" based (such as Nexus Recall).

Those cooldown modifiers are also pre-programmed with pertinent error message if the ability/behavior cannot be modified by an ability or effect (ex: not enough life, ability on cooldown, etc).

#### Ability:

Ability command(s) of the ability to modify the cost. Be advised that the ability won't show up if the modder did not fill up the ability command button field of the ability itself, even if that one can work without it. There is also a bugged rule: The ability must have an entry greater than 0 in the cooldown or charge field to be modified, otherwise it will never work.

#### Behavior:

Choose the behavior to modify its cost (doesn't work with Damage Response Cost). There is also a bugged rule: The behavior must have an entry greater than 0 in the cooldown, charge, vital or tech cost field to be modified, otherwise it will never work.

#### Charge Count Used:

As it states, how many charges are used or restored. Ex: putting 1 charge in positive means to send a single charge into cooldown, while negative means to refresh a single charge as "regenerated". It is oddly possible to add 1.5 (or any decimal value for that matter) charge to an ability. The incomplete charge will only be kept as a left over, that can add up with further use but will be lost if all charges are regenerated. Cannot add more than Maximum Charges value. In other words, if all charges are ready, only putting into cooldown a charge is possible.

#### Charge Time Used:

Nearly as Charge Count Used does, this field rather focuses on the timer of a single charge. This only affect the current charge, and does not work if all charges are restored, only removing a charge count paired with this function can create a charge with a specific cooldown, on demand. Puting time in negative cannot affect a secondary charge (or more) if the given refreshed time is greater than one what was left of the modified charge. Ex: A unit has 2 charges in cooldown (50 sec.), and the first one is at 5 seconds left from being fully time regenerated. Adding -75 charge time will fully refresh this first charge, but will never give the difference to the second charge left.

#### Cooldown Operation:

Logical way to modify the cooldown, specifying how to manipulate the cooldown timers. Only affects "Cooldown Time Used" and "Cooldown Fraction", not charges (even if this is a timer on its own), vitals, resources. Nothing else. Positive amounts = Completed amounts, while negative means due time.

* **Add:** Adds/Remove cooldown, no matter what. It was not necessary to add a "Substract" field, because this field does it all the same. Does nothing if putting an amount in positive with no active Cooldown.
* **Add if Not In Cooldown:** Is default setting. Works like add but requires cooldown inactive. Does nothing if putting an amount if negative, it can only create active cooldown (otherly said, it's like refreshing some cooldown when there's no cooldown to restore). This operator is useful when the modder doesn't want to touch abilities that are currently regenerating.
* **Max:** Sets the current cooldown (cooldown active or not) to this amount, but will refuse to modify if the current cooldown is higher than this value (still resets the UI clock of the button to the current timer, for some reasons). Does nothing if put in negative (because you can't set the maximum above completion and because higher current cooldown timer values aren't modified either).
* **Min:** Sets the current cooldown (requires cooldown active) to this amount, but will refuse to modify if the current cooldown is lower than this value (which is also why a fully regenerated cooldown is considered 0, so lower than any minimum and won't be modified). Fully restores cooldown if put in negative at any amount (otherly put, it's like asking the minimum cooldown to be more than a fully restored cooldown).
* **Multiply:** Multiplies the current cooldown (requires cooldown active) by the "Cooldown time Used" field. Fully restores cooldown if put in negative at any amount (otherly put, it's like asking to multiply the amount that will result of the multiplication above completion).
* **Set:** Sets the cooldown to this exact amount, no matter what. Fully restores cooldown if put in negative at any amount (otherly put, it's like asking to set the amount to any set number above completion).

#### Cooldown Time Used:

Modifies the actual Cooldown of an ability. The number imputed will be highly susceptible to Cooldown Operation. Adds up with Cooldown Fraction value.

#### Fraction (description)

Section in which the fields are modified by multiplaying the values. Requires the pertient ability/behavior to have a value on its own, as it is impossible to make a fraction out of 0.

* This section can be misleading: Ex: Modifying a Resource or Vital does not concern the unit itself, but rather, the value of the ability of behavior. Ex: Life fraction 0.5 will use 50% of the the current 0.5 life fraction on the ability, causing the effect to request 25% of the unit's life in exchange of executing this effect.
* Do not confuse Vital Fraction with Vitals in the following way: Vital Fraction does not look at the total of all reunited vital costs, nor does the Vitals. They only adress the proper and equally named fields on the Ability/Behavior cost field.

* Modifying the cost in term of Vitality or Resource will multiply the ability/behavior values and spend it/them instantly, but will also fail the effect if the vital or resource value(s) cannot be met by the using unit.
* Still follows the rule of the positive negative: Positive adds up in cost/duration, while negative decreases the cost/cooldown duration.

#### Fraction Categories:

* **Charge:** Fraction of a single ability Charge - Count (Max) that is modified. By putting 1 here, you add one charge ready. It is oddly possible to add 1.5 (or any decimal value for that matter) charge to an ability. The incomplete charge will only be kept as a left over, that can add up with further use but will be lost if all charges are regenerated. Cannot add more than Maximum Charges value. In other words, if all charges are ready, only putting into cooldown a charge is possible. Adds up with other Charge Time Used value.

* **Cooldown:** Fraction of the cooldown (the original value, not the current on going cooldown) that is modified, works with Cooldown Operation. This field remains logical to the current cooldown in use on the ability/behavior: Cooldown Start or Cooldown Use. If the ability/behavior is not on cooldown, Cooldown Use will be favored. By putting 1 here, you fully reset the cooldown, 0.5 would be adding it at 50% of the total, etc. On the other hand, -1 fully regenerates the cooldown on all cases. Adds up with other Cooldown Time Used value.

* **Resource:** Fraction of the ability/behavior cost in resource cost that will instanly be requested when using this effect. If the resource is unavailable, it will fail to execute the effect. This field is probably the one that matches with the Player Field below, since one can choose check for the Creator's resource instead of the Player Origin (in cases of mind controlled units that checks the owner's resource). Leaving it at 0 still means 1 for abilities, as the using this effect will trigger the related cost field; it is not the case for behaviors cost which require a value here to trigger.

* **Vitals Fraction:** Fraction of the ability/behavior cost in Vital Fraction ONLY, relative the proper vital type that will instanly be requested when using this effect. If the vital is unavailable, it will fail to execute the effect. Leaving it at 0 still means 1 for abilities, as the using this effect will trigger the related cost field; it is not the case for behaviors cost which require a value here to trigger.

* **Vitals:** Fraction of the ability/behavior cost in Vital ONLY, relative the proper vital type that will instanly be requested when using this effect. If the vital is unavailable, it will fail to execute the effect. Keep in mind that on the ability, yes it is a flat amount to be removed (or added) on the unit, but this field remains a fraction of it. Leaving it at 0 still means 1 for abilities, as the using this effect will trigger the related cost field; it is not the case for behaviors cost which require a value here to trigger.

#### Player

* Effect: Relates the target value of "this" very effect. Useful when adressing a specific location in the chain of effect.

* Value: Location of the player that should have its resource cost checked.

* Caster: Charges the owner of the unit that cast this effect tree
* Creator: Charges the CURRENT owner of the unit, not essentially the original one. Creator in this sense, means the player that currently "creates" or is part of the chain of effect as the owner of the casting unit.
* Hostile: Charges the owner of the Hostile Player (15) (Brown)
* Neutral Player: Charges the owner of the Neutral Player (0) (White)
* Outer: Charges the outside unit (transport or Magazine unit) currently carrying the target unit.
* Player Origin: Default. The player that first owned that unit.
* Source: Most likely the caster. It may still check last behavior target in the parent effect as a source, or the launched unit of a Launch Missile effect.
* Target: Charges the owner of the unit being targeted by this effect or the one specified by the effect field of this player section.
* Unknown: No target.

### Effect - Experience

Experience amount of a unit with a Veterancy behavior modified.

* Useful for items that increase experience
* Is susceptible to buff behaviors modifying XP Multiplier.

### Effect - Height

* The amount of height the target has changed
* Unlike the buff behavior, it is possible to put number in negative in this field.
* This system still remains smart for units that are already on the floor. For example, if a Marine gets a -3 height modification, at first sight, he won't dig the ground headed to reach -3. That is because, the game keeps in memory that "this" unit owes -3 height, while still respecting the ground law (unless flags such as "Ignore Terrain Height" on Units or "collision" on that unit allows it to pass through). Then, he receives a secondary +3 height modification and because it was coded that he already had a modification of -3 earlier, the +3 won't make him float, the Marine will remain on the ground, back to 0 height. As a matter of fact, even if this unit "owes" a certain quantity of height, validators such as Unit Compare Height and Z still considers this unit to be at 0 height from the ground. This is ideal for a spells that would drag units to the ground and then set them back.

### Effect - Height Time

* How long the unit takes to change from the previous height to the new one

### Effect - Kill Hallucination

* If enabled kills all target units with the Hallucination state flag

### Effect - Modification Flags

This contains some of the more interesting features

* **Clear Last Attack Target:** (Unknown)
* **Clear Last Move Target:** (Unknown)

* **Copy:** Makes the Caster inherit the Target's behaviors (Not sure what else. Useful for creating unit clones. Example usage is to have an efect create a unit, then in the spawn field set to a modify effect with this checked. Then set Target to Caster and Caster to Target. This will make the newly created unit inherit from the parent. (Copies data such as experience, vital))
* **Copy Auto Cast:** (Unknown)
* **Drop From Container Item:** If the target is an item, this forces it to leave its current owner, even if the terrain is unpathable.
* **Drop From Container Passenger:** If the target is a passenger, this forces it to leave its current transport, even if the terrain is unpathable.
* **Hide:** Hides the unit. Similar to Behavior: Modification: No Draw, except the unit will stay hidden until a modify effect with "Show" is applied. Used only by Point Defense Drone - Point Defense Laser (Damage).
* **Interpolate Facing:** If enabled, the unit adopting a facing location will rotate to it instead of being set to it immediatly. Although the facing modification doesn't seem to relate on the unit's turning speed, this flag gives a little bit more of a natural rotation.
* **Is Heal:** Makes this effect susceptible to Heal Dealt / Heal Taken modifications from buff behaviors. Has a critical bug: spamming too many effects at once using this flag causes the game to crash instantly by draining all the memory of the sc2 application.

* **Mimic:** Changes the team colour of the unit to that of the target. This also comes with a permanent premade "Benign" state flag effective toward the imitated player, explaining why Changeling may walk around without being acquired. Further more, it seems that this field also causes the unit to inherit the upgrades/stats of the mimic'ed player, meaning that if the Mimic unit used a innate weapon for example (or data that can be upgraded) , it would deal damage according to the immitated player's value rather than the mimic's owning player. This was true when testing the changeling using a buff that generated an area damage upon dying. The damage could be upgraded but never dealt more damage because the buff was innate (put on the unit's data) to the mimic flaged modified units. To counter this, one must add the behavior from the origin player upon the mimic modification time (or at anytime). There seems to be no way to revert this field other than using another modify unit effect with a mimic flag launched from the owning player of that mimic unit.
* **Nullify Missile:** Prevent the missile from executing its Impact Effect when it arrives at destination. Missile Death at arrival may still happen if this field is enabled. Can be verified by Unit Nullified Missile validators.
* **Owner:** Enables the ownership change of the Impact unit. The new owner is specified in the **Modify Onwer Player** field.
* **Pause Death Time:** (Unknown)
* **Remove:** This flag that will directly remove the unit from the game and will destroy the unit actor’s entire scope. This is added because users are not able to use the “Remove” effect from CEffectDamage to remove a corpse.
* **Resource Drop:** When checked, the impact unit will instantly drop the resource it’s currently carrying without needing to travel to a Town Hall. The owning player will receive the resource. This flag crashes the game big time if the target of the modification doesn't have the capacity to harvest.
* **Revive:** Seems to be relative to the Revive system. Tested with a unit that has no revive ability, it was only possible to use this from a death response from a buff behavior + setting more than 0 second on the death time. This brought the unit back to life. It would make sense to say that this causes a dead unit that can be revived to revive "right now".
* **Salvage:** Activate the salvage function of this effect. If the Impact Unit is hit by this effect it will die. See the **Salvage Factor** field.
* **Set Vitals:** Directly sets a unit’s vitals.
* **Show:** Works in tandem with the Hide Flag. Will Show a unit previously hidden by the "Hide" flag.
* **Starting Vitals:** Sets a unit’s Life, Energy, and Shields to its starting vitals.
* **Unpause Death Time:** (Unknown)
* **Unraisable:** (Unknown)

### Effect - Modify Turret

Indicates an action that will be executed by the turret owned the impact unit (that unit becomes the launch location of this field). The impact location on which this turret will interact with is specified here by the value field.

* Used by Cyclone Lock On ability
* The effect that occurs from this field does not display in the effect tree, which makes it harder to understand at first.

#### Aim Complete Effect

The effect that occurs when the specified turrets has completed its task issued by this effect. Does not work properly if the Turret is currently used by another entity (such as a weapon). This is the only part of this effect that can generate child effects.

#### Flags

* **Tracking:** The turret will follow the target as it moves around. (Unsure how this field interacts with Clear Target On Aim Complete, but the Cyclone does use it).
* **Clear Target On Aim Complete:** As the name states, once the target is acquired, the tracking will stop (which implies that no Clear Target Action is required).

#### Target

**Value:** Unit that will be targeted by the turret. This value usualy evaluates previous effect, and not the impact unit (ex: Setting Target Unit will not look at the Impact location of this effect which could be caster).

**Effect:** Parent effect which from which the value relates from.

#### Turret

The Turret from turret data that will be used to execute this effect.

#### Action

* **Clear Target:** Makes the Modify Turret clear the target (the value field above). If the caster has the turret, set the value to Caster.
* **Set Target:** Makes the Modify Turret identify a target (the value field above).

### Effect - Resource Restore Bonus

Relative to the **Impact Unit** only; Restores a flat amount of resource, regardless of its capacity.

* As this field can be set in negative (up to -1), doing so has no effect at all.
* Since this field is only related to the **Impact Unit'**s resource pool and not the **Resources** field, it can be used on its own to restore resources.
* For starters, this field is no different, hence, exactly what the **Resources** field is when set in positive. The only use for this field would be in the following situation: You want to harvest resources from the Impact Unit, while requesting its resource pool to fill up or remain still. The logic behind it, is that since the Harvested fields only work with a minimal quantity in **Resources** field set in negative, this field offers the only viable option to reverse the draining process on the Impact Unit, nullifying it or even, filling instead. If the wrong initial idea was to set the **Resources** field in positive, the **Harvested** field would have never worked.

### Effect - Resource Restore Fraction

Relative to the **Impact Unit** only; Restores a fraction of its total amount, regardless of its capacity.

* Since this field is only related to the **Impact Unit**'s resource pool and not the **Resources** field, it can be used on its own to restore resources.

### Effect - Resources

Directly modifies the resource on the **Impact unit**, either in negative or positive. This only modifies the resource amount on it, and nothing else about the **Launch Unit** player. This field can do what **Resource Restore** fields can do when set in positive, but not the **Resource Harvest** ones. Even if the number is set in negative, this will only remove resource from the Impact unit without delivering to the Launch Unit.

* This field only modifies the **Impact Unit**.
* This field is the epicenter of all Resources fields (Harvested, Restored) from this effect. It will be greatly referred on this wiki resources segment.

### Effect - Resources Harvested Bonus

Flat amount of resources that is given to the Launch Unit player. This field is mainly used to pair up with the **Resource** field in order to create an exchange between **Impact** and **Launch** Unit, in terms of resources.

* As this field can be set in negative (up to -1), doing so has no effect at all.
* Requires **Resources** field to be set with a minimal quantity in negative. Failure to do so will nullify any effect of this field.
* It doesn't matter if the amount in this field matches or not the **Resources** field. This is only a flat amount of resource to send to the player, and won't affect the resources left on the **Impact Unit**. For example: if the **Resources** field drains 1 mineral, and this field grants 13 minerals, it will effectively only take off 1 mineral from the Impact Unit, and send 13 minerals to the Launch Unit player and that, even if the Mineral field only has 1 mineral left on it. In fact, this field can generate more resource than the actual quantity left on the modified Impact Unit.
* Doesn't work if the **Impact Unit** current resource left is at 0. As the previous example shows that it's possible to generate infinite amount of resources, yet, the Impact Unit must be able to provide a minimal quantity.
* This field does what "Resources" field from Modify Player effect do. The slight difference is the the fact that this field is not fully independant and only works in pair with the Resources field.

### Effect - Resources Harvested Fraction

Fractional amount (from **Resource** Field) of resources that is given to the **Launch Unit** player. This field is strictly dependant of the **Resources** field in order to create an exchange between **Impact** and **Launch** Unit, in terms of resources. Auto Harvest Vespene effect uses these fields.

* Is the simplest method for taking off resources from **Impact Unit** and give an equal quantity to the **Launch Unit** player.
* More than the **Resources Harvested Bonus** field, this field will always depend and be modified by the **Resource** field. You may still cheat the quantity, by exagerating the amount here toward the Resources field value.
* Doesn't work if the **Impact Unit** current resource left is at 0.

### Effect - Response Flags

* Determines how units respond when hit by this effect if they can (set by the Behavior - Response field under the Units data type)
* Aquire makes the unit aquire the caster
* Flee makes the unit run from the caster

### Effect - Salvage Factor

Only applies if the Salvage flag is set on this effect. Specifies the unit cost multiplier to determine how much of a refund is provided.

* In other words, this indicates how much (in resources, vitals or/and cooldown) to refund or penalize the Launch unit player with the cost of the impact's unit cost fields. Be careful not the confuse the mechanics of the Bunker's salvage ability, which is only a flat -75 cost put on the ability. Using this effect would however still work, and even better in relation with the "actual cost" of a unit.
* The cost fields are all factors, which implies that no flat number is to be meant here, but only multipliers.
* It has not been tested how this effect can pinpoint which ability is concerned for a cooldown/vital refund.

### Effect - Validators

* The validators that need to return true for the effect to take place

### Effect - Vitals - Change

* The amount of energy, life and shield healed or damaged

### Effect - Vitals - Change Fraction

* The fraction of the maximum energy, life and shield healed or damaged

### Target - Impact Unit - Value / Effect

* See Effects for more details.
* Tells which unit is to be modified by this modify unit effect.
* As stated above in the known bugs, the copy flag will use this field as the source of information to copy from.

### Target - Launch Unit

##### Value / Effect

* Unit this effect is known as launched from
* See Effects for more details.
* Tells which player to mimic from (modify flags).
* As stated above in the known bugs, the copy flag will use this field as the target to copy at.

### Unit - Kill Credit Unit

#### Value / Effect

* As stated by the editor: If this field points to a valid unit hostile to the impact Unit, it will increase the kill count on the Impact Unit by one and dispatch a kill credit notification to behaviors.

### Unit - Transfer Unit - Effect

* Specific effect that the scope of which is to be used in combination with the Unit - Transfer Unit - Value field to determine the player who receives the impact unit if the \*Owner flag is enabled

### Unit - Transfer Unit - Value

* Unit whose owner receives the impact unit if the Owner flag is enabled
* Caster Unit: Ownership is transfered to the casting unit player
* Outer Unit: Ownership is transfered to a unit that is not Target, Source, Caster, or Origin's player
* Source Unit: Ownership is transfered to the most recent unit targeted or created by a previous effect in the effect tree's player
* Target Unit: Ownership is transfered to the target unit (pointless) unless specified otherwise by the Target - Launch Unit - Effect field
* Unit Origin: (Unknown)
* Unknown: (Unknown)
* Good for treachery like abilities/behaviours

## Related

* Resource
* Abilities