recursal/Fanatic-Fandom huggingface dataset:
Data/Validators/Player Compare Difficulty

## Description

Validates the difficulty of the targeted player.

It is unclear how this interacts with "user" players, since they seem to adopt the same value than their computer opponent in a 1v1. However, if used on a target computer, one has to keep in mind that the **Value** field equals the followings:

1. **Very Easy**
2. **Easy**
3. **Medium**
4. **Hard**
5. **Harder**
6. **Very** **Hard**
7. **Elite**

As it is indicated, the value can go up to 32, which would require further documentation.
Data/Validators/Player Compare Resource

## Player Compare Resource

### Description

Verifies the actual quantity of resources owned by the player. This does not validates the total made.

### Exemple Use

As stated in the Modify Player effect, this can be used for creating effects that drain resources. At the moment the enemy player validates as having 0 resources, this validator can block the draining player from generating any additional "fictional" resources.

## Field Categories

### Other Player

Probably allows the validator to validate 2 players togheter. This would mean that the main player's current resource has to be X quantity "Compared" to this Other player.
Data/Validators/Unit Inventory Is Full

# Unit Inventory Is Full

## Description

As the name states, mainly checks if the target location unit has its inventory full or not.

## Field Categories

### (None:) Require Enabled

(Unsure) Checks if the full inventory is enabled?

### Validator: Result No Inventory

Unique to this validator, error message that you would have if the target unit doesn't have any inventory.

### Validator: Unit

Target location of which unit the inventory is checked from.

## Related

Items

Inventory
Data/Actors/ActionTerrainSquib

## ActionTerrainSquib

### Description

Configures the models and sounds that will be created when this attack launches. These actors will only be created when launching on one of the physics materials specified, where the physics material is based on the terrain texture at the launch point.

## Field Descriptions

#### Description

Animation Properties to be played on the specified model link

#### Description

Additional scale applied for the specified model link

#### Description

(unsure)List of terrain physics materials this squib can be created at.

There is no Editor GUI for this field, can only be edited in Raw(Ctrl + D) or XML(Ctrl+3) view

Example:

* **RawView:** separate types with spaces -> *Ice Snow Rock Sand*
* **XML:** *TerrainPhysicsMaterial="Ice Snow Rock Sand"*
Data/Behaviors/Creep Source

(Editor Screenshot) need picture of overlord using generate creep

### Hint

* This behavior can set the rate of growth of the creep and the sizes it starts at and obtains but not the rate of decay and visuals of the creep. For those you need to go to Terrain Types and Gameplay Data. Cannot be applied to a point and needs to be emitted by a unit so dummy units may be needed.
* Used by the Location Creep validator

## Example Usage

### Hive (Zerg)

The zerg hive building uses the Zerg - Creep Growth Large behavior to generate the creep around it

#### URL

No URL is needed as the Hive is already present in the editor

### Overlord - Generate Creep

The ability of the overlord that allows the creation of a small creep area as long as the unit is stationary.

#### URL

No URL is needed as the Overlord is already present in the editor

## Fields Description

### Behavior - Birth

* Footprint of the creep when the unit is finished being created
* Adjust under Footprints

### Behavior - Build

* Footprint of the creep when the unit is finished being constructed eg. a building
* Adjust under Footprints

### Behavior - Disable Validators

* Validators that if return false temporarily disable the behavior until they return true

### Behavior - Footprint Grown

* Footprint of the creep when at full size
* Adjust under Footprints

### Behavior - Footprint Start

* Footprint of size if preplaced in the editor (start of game)
* Adjust under Footprints

### Behavior - Disable Validators

* Validators that if return false temporarily disable the creep spawning. This then submits the local patch of creep to the decay value set under the Gameplay Data until the \*values return true

### Behavior - Requirements

* The requirements to use the behavior
* Can also disable the behavior

### Stats - Delay

* The time after activating the behavior before creep growth occurs

### Stats - Period

* The time between creep growth (square per unit time?)

## Related

* Footprints
* Location Creep
* Terrain Types
* Gameplay Data
Data/Behaviors/Conjoined

### Description

This behavior is used to link two units together. Unit's the the same conjoined behavior will share the same stats.

### Hint

The Braxis Alpha Doodad uses the conjoined behavior to have a shared health pool among all doodads of the type on the map. Useful for making large piles of varying destructables, but with a single health pool.

## Example Usage

### Summons Linking

Have an invulnerable hero with an ability to spawn summons that do damage. Give both the summons and the hero the same conjoined behavior. Thus, the Hero is always invulnerable, but in order to deal damage, he must use his summons, but with summons he can be hurt.
Based on absolute values. If you have 2 units, one with 100 life and one with 1000, the latter will only have 100 out of 1000 of its HP.

## Fields Description

### Behavior: Alignment

Is the behavior Positive, Negative, or Neutral? Automatically colors the behavior icon depending on this selection. Negative = red, Positive = Green, Neutral = normal color

### Behavior: Conjoined Flags

Share Life: Do units with this behavior share a linked health pool?
Share Energy: Do units with this behavior share a linked energy pool?
Share Shields: Do units with this behavior share linked shields?
Share Visible: Do units share visibility?

### Radius

How far the units can be for the conjoined behavior to apply.

## Related

Link1
Link2
Data/Actors/PhysicsData

## PhysicsImpactData

### Description

Configures the types of physics impulses when the action impacts the target unit.

## Field Descriptions

#### Description

```
<Flags index="ExpectsOtherForces" value="1"/>

```

#### Flags

* **ExpectsOtherForces:** Signifies that this attack triggers physics deaths but relies on other forces to actually move the ragdolls it might create.

#### Description

Requires these Anim Props to be present on the attacker for this Physics Data to trigger.

#### Description

Requires the attackers model variation to match this value for this Physics Data to trigger.

#### Description

(Unsure)Keys to match impact to different death types that causes the Custom Death Data on units act differently, if configured correctly

#### Description

Generic name used to identify this Physics Data

#### Description

Link to a Physics Force Actor that will be created
Data/Actors/Turret

## Turret

### Description

Grants a visual animation required by the turret data from the unit's model Turret Z. This type of actor attempts to rotate the model queried attachement point (usually Turret Z) on request. It's up to the model's conception to allow the Turret actor to take control of its rotating section. For example, using Center point as rotation point may not work on every models, as they are not configured to synchronize with this type of actor and create a rotation from that point.

* When created, its animation speed is strictly synchronized to the turret's yaw fields, perfectly imitating the rotation speed. What truly rotates (invisibly) is the Turret itself.
* Only (as far as tested) events such as "Turret Enable" are capable of properly creating the turret on the unit. Destroying the actor while the unit is still alive with no other turret actor to take over will cause a bugged state in which the turret visual part will be completly removed from its model.
* "Behavior" msg type from actor events are unable to generate a response forthis type of actor, unless they originate from the CActorUnit or from a macro in it. The turret must be innate to the unit and only responds to itself or its attached unit (linked to a valid CActorUnit). Also, CActorUnit may target the related turret actor from within their events if desired. Unit Morph events and such may impact on a turret actor's response.
* Once created, a turret actor will stick to the unit, even after morphing to another unit. It is up to the modder to make sure that if the morphed unit uses another turret data, that the first turret is destroyed upon morphing. Also remember that morphing to unit that doesn't possess the same turret considers the situation as a "Turret Disabling", which can be used in the events as "TurretDisable".

## Field Categories

### Attachment: Pitch Query

As stated by the editor: Attach query that will get the attach point this actor will use to control pitch on the model. The attach point must be linked to a special turret bone in the model file.

### Attachment: Turret Body

Location from which the turret gets its attachement point. Is usually set to \_Unit (the unit's actor).

### Attachment: Yaw Query

As stated by the editor: Attach query that will get the attach point this actor will use to control yaw on the model. The attach point must be linked to a special turret bone in the model file.
Data/Validators/Compare Tracked Units Count

## Compare Tracked Units Count

### Description

Compares the amount of tracked unit relative to the specific Unit Tracker behavior, along with the specific Tracker unit.

## Field Categories

### Behavior Link

Which Unit Tracker behavior specific is concerned. This becomes handy when multiple behaviors are in plays.

### Compare

Operator that works with the numeric value.

### Tracked Unit Filters

Extra filter validation that can be used for this validator, checking the tracked unit.

### Tracked Unit Validator Array

Extra validators that can be used for this validator, checking the tracked unit.

### Tracker Unit

Which unit location is considered to be the "Tracker".

### Value

Nuneric value of how many tracked units this validator checks and operates with "Compare".
Data/Validators/Unit Compare Resource Contents

## Unit Compare Resource Contents

### Description

Checks the current stock of resource that is availlable at **Unit**. Is it wise to consider validating any type of resource unit such as Minerals, Vespene Geyser, Refineries, custom resources, etc.

* This validator doesnt seem to distinguish the resource type. It can only evaluate the particular behavior or any of them.

## Field Categories

### Behavior

Name of the Resource behavior that is evaluated. Leaving this field empty will have any type of Resource behavior be evaluated.

### Other Unit

(Unsure) Other unit from which the current stock of resource if compare to.

### Unit

The unit from which the current stock of resources is evaluated.

### Value

Numeric value representing the amount of resources to be compared.
Data/Validators/Location Range

## Location Range

### Description

Validator that returns true if the Target - Location - Value point/unit is the correct distance from the Validator - Value - Value Point/unit

## Fields Description

### Target - Location

The epicenter of where the range is checked. Think of it as the "Arrival Point"

* See Effect for understanding values and effect.

### Validator - Compare

* Defines the Range numeric value operation by comparing the Value and Location

### Validator - Pathing

Allow or disallow the use of pathing on the distance calculation.

* Disabled means: Any Flat Range between the Value and the Location is check, wherever in the map
* Enabled means: Any Flat Range between the Value and the Location is check, for as long as **location** unit can path to **value**, Example: If the location unit must be greater than 5 range, but is unable to move directly to the value unit within 5 range, because of a cliff or a chasm, then the validator considers that the range is still greater than 5 and will pass. This must also consider ramps as well. At a certain point, structures and units blocking the path can be considered as "obstacles", validating the pathing. It is also important to know that the FULL pathing is checked. This means that even if the unit can get closer below 5 range, but still can't get to 0 range inside of that 5 range, the validator still considers the distance greater than 5 range.

### Validator - Result - Failure

* The error message that will display when the validator fails to either return true or false.

### Validator - Value - Value

The start point of where the range is checked. Think of it as the "Start Point"

* See Effect for understanding values and effect.

## Related

* Behaviors
* Effects
* Validate Creation Effect
* Validate Player
* Validate Position
* Validate Unit
* Validate Unit Type
Data/Validators/Unit Compare Death

## Unit Compare Death

### Description

Validates the type of death. Since it's not easy to catch a dying unit, at the exeption of units that have the capability remaining on board while being dead, this validator is mostly useful for actors. Validating how a unit died can be used for particular events.

## Field Categories

### Compare

Operator for the value. It is not clear how Greater than or Less Than would apply here. Anything containing the word "Equal" might probably be the only working matches.

### Other Unit

Probably the unit that caused the death. This would then validate that solely this unit can be giving the validated death.

### Value

The Kind of death: Normal, Fire, Eviscerate, Blast, etc.
Data/Effects/Random Point In Circle

## Random Point In Circle

### Description

Effect that coordonates the child effect in random point locations inside a selected radius.

### Explanation

This effect is an alternate version of the triggers that are able to determine random points on the map without the necessity of indicating where they can occur.

Before patch 5.0, the only way data could generate random points was with the help of a Create Persistent effect, in which not only we had to fill up the list of offset locations (with the random offset flag enabled), but the occurance of the desired effect was limited to these offsets only. The work around to solve this was to use triggers to answer on an effect to generate effects at random point around the casting unit (or the target unit).

* Now imagine that not only you dont have to specify the offsets, nor set them to random, but you can have a full automated effect that gives you random offsets inside a radius, limitless. This is what this effect does. In fact, you can even deceide to generate the effect on the circumference itself.

### Testing

This effect has particular interaction when using an Issue Order at caster as follow up effect. If the caster should be ordered an ability at the random point, it is imperative to specify the player value of the Issue Order as "Caster", since this effect will result in a point location, which revolves around no player location.

## Field Categories

### (None): Count

How many child effects at once will be created.

* This has a delay of 0 seconds between each effects, which means they all occur at once. If it's desired to delay them, use a Create Persistent effect with period durations that generate this effect, and set this field to 1 only (default value) or more.

### (None): Effect

Which child effect will be created at random point by this effect.

### (None): Radius

The size of the radius (range) in which the random points are chosen for execution.

### (None): Restrict To Cicumference

If enabled, this field forces the random points to be generate only at the edge of the radius, instead of inside.

* If disabled, the random point can probably still hit the edge once in a while.
Data/Validators/Detect Range

## Detect Range

### Description

Validates the detection radius from the target location. This capability of detection comes from Buff behaviors. This validator oddly has no parent core file.

## Field Categories

### Compare

Compares the numeric value of the verified ranged.

### Radar

Includes or not the verification of the "Radar" capacility, also produced by Buff behaviors.

### Value

The range/radius numeric value that is verified.

### Unit

Which location unit is checked by this validator.
Data/Effects/Destroy Healer

# Destroy Healer

## Description

Such as Destroy Persistent, this effect aims exclusively for Create Healer effects and ends them (or 1 at the time upon choosing).

## Field Categories

### Effect: Count

How many healer objects that match the requested parameters are destroyed.

### Effect: Effect

If specified, this effect will only destroy healer objects created by the requested effect.

### Effect: Radius

The radius of the area to search for healer effects. The healer effect radius is also taken into consideration when performing the range check.

### Target: Location

Attempts to find a location in the parent effects where the Create Healer would be or the point where the **radius** should search at. See effects for more info on location.

* As editor puts it: *Specifies where to look for healer effects to destroy.*

## Related

Destroy Persistent

Create Healer
Data/Actors/Region (Circle)

## Region (Circle)

### Description

Is an actor that works like a continuous search. Its purpose is to launch events when a unit with X filter or X validator enters or leave the region. The region is determined by a range/radius.

### Hint

It's unsure how radius and range distinguish within this actor, this requires more testing. What we know for sure, is that when you create this actor, on "actor creation" we can launch "Query" type of events. Works well with Query Response actors (if using "Query Persistent" Action)

* Putting 0 range and 0 radius seems to work at any distance. This can be used at the advantage of the "Visible" filter.
Data/Validators/Location Power

## Location Power

### Description

This validator type is used check if the location is powered by a Power Source behaviour.

## Fields Description

### Target - Location - Effect

* This is which effect is going to be compared. *(None)* means any effect.

### Target - Location - Value

* This is at which point the effect needs to be compared.
* Caster Point is the point of the casting unit of the behaviour or effect
* Caster Unit is the casting unit of the behaviour or effect
* Caster Unit/Point can be either the point or unit of the caster of the behaviour or effect
* Origin Point (Unknown)
* Origin Unit (Unknown)
* Origin Unit Or Point (Unknown)
* Outer Point (Unknown)
* Outer Unit (Unknown)
* Outer Unit/Point (Unknown)
* Source Point is the point of the effect or unit directly casting the effect or behaviour which may not be the caster point
* Source Unit is the unit casting the effect or behaviour which may not be the caster unit
* Source Unit/Point is the point or unit casting the effect or behaviour which may not be the caster unit
* Target Point is the point which is being targeted by the behaviour or effect
* Target Unit is the unit being targeted by the behaviour or effect
* Target Unit/Point is the point or unit being targeted by the behaviour or effect
* Unknown (Unknown)

### Validator - Compare

What is essential to know about using this Compare field, is that any Power Source with higher levels (increased from the proximity of Nexus/Warpgare) will not be considered by "Equal to". In that view, it is wiser to choose "Equal or Greater Than".

* The logic functions applied to the integer of the Validator - Value field
### Validator - Player - Effect

* This is which effect is going to be compared. *(None)* means any effect.

### Validator - Player - Value

* Determines the required relationship of the owner of the power source to the validating player
* Caster
* Creator
* Hostile
* Neutral Player
* Outer
* Player Origin
* Source
* Target
* Unknown

### Validator - Power Link

* String refering to the Behavior - Power Link fields of the associated behaviours dictating the groupings of different power sources
* Allows the validator to compare several different power source behaviours of the same group

### Validator - Power Source

* The individual Power Source behaviour this validator is to validate

### Validator - Result - Failure

* The error message that will display when the validator fails to either return true or false.

### Validator - Value

* The integer for the power level to compare from the Stats - Power Level field of the Power Source behaviour

## Related

* Behaviors
* Power Source
* Effects
* Validate Creation Effect
* Validate Player
* Validate Position
* Validate Unit
* Validate Unit Type
Data/Loot/Unit

### Hints

* Can be used to reward the killing player with a friendly/spare unit or punish them by spawning hostile units

## Fields Description

### Basic: Spawn Location

* The location where the units are created
* **Target:** The point of the killing unit
* **Caster:** The point of the killed unit with this loot
* **Source:** The point of the killed unit with this loot
* **Outer:** The point of the unit that is the containing unit for the killing/killed unit.
* **Unit Origin:** The point of the killed unit with this loot

### Basic: Spawn Owner

* Determines the owning player of the created unit

### Basic: Spawn Range

* Determines how far from the spawning point the unit can be created if placement is prevented by collision or footprints

### Basic: Unit

* The unit from the Units data type spawned

## Basic: Validators=

* Validators that must return true to spawn the unit

## Related

* Units
* Validators
Data/Player Responses

## Player Responses

### Description

Player Response is a new data catalog that allows users to define response patterns when something happens for the equipped player. Designers can use triggers to equip these response patterns to certain players, and the player’s units will response to the registered events as if they all had damage response behaviors.

* Users have the option to set priority and fall through methods for Player Responses.
* Player Level Response removes the need to apply certain behaviors to everyone when creating commanders, which greatly improves the performance of the game. Also, since you only need to equip responses when the corresponding commander is responding, the game no longer needs to go through the death prevention data of all the commanders every time.
* Player Response is no longer restricted to “Unit is Damaged” like damage response behaviors. For instance, it can also respond to player spawn, unit spawn, player unit death, etc.

## Common Fields

### Location

(To be filled)

* Attacker: (To be filled)
* Defender: (To be filled)

## Player Responses Types

* Unit Birth
* Unit Damage
* Unit Death
Data/Validators/Game Commander Active

## Game Commander Active

### Description

Seems to be reserved for COOP, as it validates which commander is used in the game. Since this validator has no location, it is mainly used for a lonely player only. Using this in any custom mod should always result faillure, unless the one is able to have the game recognize a matching commander in the played map.
Data/Validators/Unit Compare Vitality

## Unit Compare Vitality

### Description

Compares a combination of the life and shields of a unit. A unit with no shield is considered as having 0 shields.

* Basically, this validator does not offer the **Vital** Field that requires a type of vital, it automatically combines both life and shields, and exclude energy. All the fields beside the one mentioned here are the same as the Unit Compare Vital validator.

## Field Categories

### Validator: Other Unit

**Unit** Compares to this location is specified.

### Validator: Type

Type of verification about the vitality.

* **Current:** Current amount of vital. Ex: The unit has 5 life out of 100, and 5 shields out of 20. The addition of 5 life + 5 shields is checked.
* **Delta:** (Unknown)
* **Fraction:** Percentage amount of vital. Ex: Putting a value of 0.1 means 10%. 1 = 100% (life and shields together).
* **Maximum:** The maximum amount of vital. Ex: Maximum shield value + Maximum life value.

### Validator: Unit

Which main unit has its vitality compared (compared to self if the **Other Unit** field remains unchanged)

### ~~Validator: Vital~~

~~Type of vital that is compare. Simply choose between Life, Shields or Energy.~~

*Not available on this validator.*
Data/Validators/Terrain

## Terrain

### Description

* This validator is to compare a Terrain Type with the one that is used as the **Primary Texture Set** in the map.

### Hint

* Cannot tell individual textures apart or terrain types that are not the primary texture set
* Next to manipulating doodads depending on what map they are placed this validator is of low utility

## Fields Description

### Validator - Compare

* The logic used for comparison of the terrain texture set used by the map to the value of the validator
* Has one of the following values:
* Equal To; means the terrain texture set used by the map must be the same as the Validator - Value field
* Greater Than; (Unknown)
* Greater Than Or Equal To; (Unknown)
* Less Than; (Unknown)
* Less Then Or Equal To; (Unknown)
* Not Equal To: means the terrain texture set used by the map must not be the same as the Validator - Value field

### Validator - Result - Failure

* The error message that will display when the validator fails to either return true or false.

### Validator - Value

* In this field you can put one of the terrain types from the Terrain Types data type

## Related

* Terrain Types
* Abilities
* Behaviors
* Effects
* Validate Creation Effect
* Validate Player
* Validate Position
* Validate Unit
* Validate Unit Type
Data/Abilities/Move

### Hint

Use Buff behaviors to make movement conditional. Can also be used to give units differing aquire/flee responses.
Apparently you cannot order units to use the **Turn** command via **Issue Order** effects

## Example Usage

Any unit that is required to go from a point to another, with the possibility of following, patrolling, holding position. Any abilities with like Effect - Target with a range 0 could work the same way, but wouldn't give as many options, nor wouldn't work with Magazine units which are commandable.

## Fields Description

### Stats - Flee Range

* Determines how far a unit flees from where it was last hit
* Based on the aquire/flee response of the Damage effect

### Stats - Flee Time

* Timer for flee response that stops further fleeing for that attack if the Flee Range is not met

### Stats - Follow Aquire Range

* Range from the unit that if attacked from it will aquire the attacker
* The filters for the targets for aquire are set under the weapon for the unit under Weapons

### Stats - Follow Range Slop

* The distance the aquired unit travels before canceling the chase

## Related

* Damage (Effect)
* Weapons
Data/Actors/Events/Actions/Set Team Color

# Set Team Color (Event Action)

## Fields Description

#### Diffuse

* Sets the team color of the diffuse layer of the actor.

#### Emissive

* Sets the team color of the emissive layer of the actor.

#### HDR Multiplier

* Increase the dynamic range of the team color part of the actor.

#### Blend Type

* The type of blending:
	+ One Shot: Do it once
	+ Cycle: Do it repeatedly
	+ Bounce: Bounce between the previous value and the set value.

## Related

* Actors
* Events
Data/Terrain Textures

## Terrain Textures

### Description

An individual terrain texture used by Terrain Types that is able to be painted on the map. Has fields determining the visuals and physical properties of the terrain.

### Hints

* The use of unique Physics Materials allows actors to be able to detect what individual terrain texture they are on

## Example Usage

### Agria Concrete

One of the eight textures used by the [Outdated] Agria (Jungle) terrain type

### URL

As the [Outdated] Agria (Jungle) terrain type is already in the editor, no URL is needed

## Fields Description

### Doodads - Model

* Foliage type models from the Models data type added to terrain painted with this texture by the **Generate Foliage** function of the Terrain Editor

### Doodads - Placement Radius

* How far from the edge of the texture the foliage can spill over onto another terrain texture

### Doodads - Probability

* How likely a foliage model is to spawn at any tile on the terrain
* Affects foliage density

### Doodads - Random Rotation

* If enabled randomly rotates the foliage models around the z axis

### Editor Icon

* Icon of the terrain shown in the terrain editor
* Usually uses 64 x 64 pixel **.dds** files

### Height Map

* Texture used to give the terrain texture additional 3d detail
* Uses the same format **.dds** files as the normal texture

### Height Offset

* Offsets the height texture from the other textures in the **(?)** Direction

### Height Scale

* Scales the Z deformation of the terrain caused by the height map
* Has a saturation point

### Normal Map

* Normal map used to add fine 3d detail to the terrain
* Uses **.dds** files

### Physics Texture

* The physics material from the Physics Materials data type used for determining how physics interact with the terrain
* Can be used for specific terrain identification

### Texture

* The diffuse texture for the terrain
* Uses **.dds** files

## Related

* Foliage
* Terrain Editor
* Physics Materials
* Terrain Types
Data/Abilities/Queue

## Queue

### Description

Micromanagement of the train ability. This ability allows multiple units to be trained simultaneously. This also handles training queue visuals.

### Hint

Most commonly used in combination with the **Arm Magazine** or **Train** ability.

## Example Usage

A Barrack that can train 3 marines, a firebat, and ghost all at once because of its **Queue** ability.

## Fields Description

### Stats - Flags

* Best unit: When a group of units is order to cast this ability, only the "best unit" (usually the closest one) will do so.
* Hidden: Makes the button not visible by default.
* Notify Add-On: (Unknown)
* Passive: Unknown, maybe allow usage of other abilities while queue is in progress

### Stats - Queue Count

* Number of units that can be simultaneously trained.

### Stats - Queue Size

* Maximum number of units that can be put on standby for training at one time.

## Related

* Train
* Arm Magazine
Data/Validators/Unit Compare Ability Level

### Description

Compares and validates the level of an ability on a unit. Value Index is 0 based. (0 = level 1; 3 = level 4, etc). Validator always returns true for level 1, even if the ability is learnable, but not learned yet. This is because abilities cannot be < level 1

## Example Usage

### Example Name 1

(Description from a global overview, tell us the relationship of combined data objects to this object)

#### URL

(URL to the real example, because we could use 1 example for 5 different objects)

### Example Name 2

(Description from a global overview, tell us the relationship of combined data objects to this object)

#### URL

(URL to the real example, because we could use 1 example for 5 different objects)

## Fields Description

### Validator: Compare

* The comparison to be made (Less than, Equals to, Greater Than, etc)

### Validator: Failure Result

* What to do if the validator fails (unknown?)
* Validator: Ignore While Channeling
* Ignore the validator while the ability is channeling?

### Validator: Other Unit +

* Compares the ability level of a second unit? (Unsure, but seems to check against another unit for targeted abilitys. Maybe used for same-ability negation). Typically left (none):(Unknown).

### Validator: Unit +

* The unit who's ability is being checked. Typically Caster or Source

### Validator: Value

* The ability level to compare again. Values use a 0 base index, so set this value to (ability level to compare - 1).

## Related

* Abilities
* Behaviors
* Effects
* Validate Creation Effect
* Validate Player
* Validate Position
* Validate Unit
* Validate Unit Type
Data/Validators/Player Compare Food Available

## Player Compare Food Available

### Description

Validates if X number of supplies is currently availlable for the player. Having more supplies than the food limit does not count as accepted. This type of validator doesn't seem to have any kind of parent core files.

### Exemple Use

In certain cases where an ability creating a dummy unit leads to create the real one as a follow up, this can be used to prevent the ability from casting, if the dummy unit doesn't have a matching Supply with the real unit that will follow up. The only problem with this system, is that they dont put any visual on the cast button, and it is highly recommanded to edit the Result - Failure field, finding a matching sound as well.

## Field Categories

### Other Player

Probably allows the validator to validate 2 players togheter. This would mean that the main player's current available food has to be X quantity "Compared" to this Other player.

### Result - Failure

Error Message given if the validator fails. While field was already documented before, it was important to mention its importance here.

### Result - No Player

Error Message If the concerned player has left the game (or defeated).

### Value

The numeric amount of food (supply) to validate. The supply type is already known by the game, from the validated unit's race.
Data/Attach Methods/Numeric Field

## Numeric Field

### Description

Seems to check for attachement point's field radius. As model data can modify the radius of points or shield in their attachement properties field, this attach method has its tool to compare the numeric value of it.

## Field Categories

### Field

The type of radius to be evaluated. Open model data's attachement properties field to see those fields.

* Radius Target: Regular attachment point's radius, named "Radius Target"
* Shield Radius: Shield's radius, named as such.
Data/Campaign/Conversation States

## Conversation States

### Description

These arrays of values can be accessed through Conversation and the trigger module. They can be made to impact how flows of Conversation Lines will branch.

### Hints

* It will probably be easier to use triggers and scripts to fork your Conversations. The Conversation States are not very transparent.

## Fields Description

#### Indices

* An array of variables that can be manipulated by Conversations Actions, checked with Conversation Conditions and accessed by Conversation Triggers.

## Related

* Data/Campaign/Conversations
* Triggers/Category Conversation
Data/Actors/AttachQuery

# Attach Query

## Description

Attachment point or set of Attachment Methods that will determine which attach point this query will pick

## Field Descriptions

#### Description

Attach point to go to if the method fails

#### Description

* Attachment methods used or direct attachment reference for attaching
* Please refer to Attach Methods data type for more details
* With direct reference to an method point make sure you use the right index number (able to be seen in the Cutscenes Editor under **Attachment Points**)
Data/Accumulators/Attribute Points

## Attribute Points

### Description

Useful to obtain current attribute points on the unit specified under Unit Source.

Example usange: Creating an ability that does x(+75% INT) damage.

## Field Catagories

### Attribute

The attribute whose value accumulator will obtain. By default uses the current attribute amount. This won't be the case when checking some of the flags below.

### Flags

* Use Base Points - Uses units base attribute points specified in Attribute Poitns Info Array in Units catalog. Exclusive to unit type Hero.
* Use Main Attribute - Checking this flag will ignore whatever attribute you put in Attribute field. Instead it will by default use hero's current main attribute amount. Exclusive to unit type Hero.

### Scale

Simple constant that will be multiplied by the attribute amount accumulator obtained.
Data/Accumulators/Abil Level

## Abil Level

### Description

Pure verification of the ability level, which is a field that can be modified on abilities.

## Field Categories

### (None) Amount

Amount modified, based on the level.

* Each entry index here would correspond to the level of the ability.
* This accumulator removes the previous need to create a set of effects for each level in order to "update" the amount.

In case an amount isn't specified for the current level, the amount will be auto generated by the following formula:

Current Level Amount = LevelFactor \* Previous Ability Level + Previous Amount \* Previous Value Factor + BonusPerLevel

### (None) Bonus Per Level

Amount multiplied by the cumulative amount of levels of the ability.

### (None) Level Factor

Amount multiplied by previous ability level (**not** amount).

### (None) Previous Value Factor

Amount multiplied by amount of previous ability level.
Data/Actors/Sound

This works the same way than any Model animation, but instead, uses a "sound" field instead of "model" to imput its sound. The Sound "Continuous" parent isn't much different than the Sound one shot, as it is best to loop the sound instead of the actor to have better results.

* By default, destroying the actor will fade out a sound (even loop ones) gradually, which is practical in any case.
* It is pointless to use "animation bracket stop" on any sounds. Such thing doesn't exist on sounds and the only way to modify the fade in/out of a sound is on the sound itself.

### Exemple use

Use it in cases where an action actor is too much for just a simple sound to be played. It can be used for everything either way, as it is a very malleable actor that suits most sound cases.

* Zealot uses this actor when dying. The idea of why they didn't use the sound on the unit actor's Death Effect field was to allow the sound to be filtered out on the term that the zealot is an hallucination or not, so that the sound doesn't always launch based on that term.
* Some sounds like machine gun sounds, have a repeated noise. If using a sound that launches from an effect that repeats a lot, it would be best using this actor than an Action actor, to avoid spamming the multi-noise sound each time the effect is launched. Same logic applies to impact effects with multiple noises.
Data/Validators/Unit Compare Order Target Range

## Unit Compare Order Target Range

### Description

Validates if an ability has the compared range. This accepts that the unit could be reapproaching distance as well. This validator can sometime be unstable depending of surrounding cliff levels or the facing of the unit, making the Unit establish a compicated evaluation. The reapprochement can be buggy too. The best way to use this validator, would probably on a unit that cannot move. It is important to remember that Buff Behaviors/Requirements do not affect this validator. In fact, even the fact of not having the ability does not matter. This also means that the ability doesn't need to be executed to return this validator true.

### Hint

This validator is very picky and is mainly more suited for adaptive range (if a unit could get closer). If it is required to evaluate directly the current range from caster to location, it is recommanded to use a Location Range validator instead.

## Field Description

### Ability

Validated ability. Leaving this field to nothing will have any ability work, returning this validator true (even if other abilities are not suited).

### Ability Command Index

The Ability's command value. Usually contains "Execute" (0) and "Cancel" (1). Other abilities like Move have a greater variety of commands.

### Other Unit

Perhaps the other unit from which the range is compared to.

### Pathing

(Unsure) This might calculate the range of Pathing. For exemple. if the the order's range is true to the ground location on a different cliff level, but for heading there, the unit must take a ramp that is way more far than the range distance that is accepted, then the Pathing will be considered and return this validator false.

### Unit

Which unit is evaluated for the abilitie's range. Remeber that a unit can be evaluated for any ability, even one it does not possess. The validator simply looks into data, not on the unit itself.

### Value

Numeric value representing the range/radius that is compared.
Data/Actors/State Monitor

## State Monitor

### Description

Monitors a unit, based on terms. When a term passes, one can use events to create new actors or such.

* Since this type of actor is very suited for CActorUnit, it is more respectful of any modification done to it. For example, modifying the scale many times of the unit actor (using \_Unit in the target box) will modify the global scale and always relate to the original value, opposed to a Simple actor, which will always relate to the current scale value.
* State Change events only trigger when a new term is true. An old term that is still true, but unchanged, isn't considered a change. Ex: Unit Kill Count is greater than 5. This value will be true when obtaining it, but then, if the newest term is greater than 10, the old one, while still being true, isn't a variation.

### Example use

Terran flames (actor) uses this actor to create or change the model of fire on a structure is at a certain health point, going from smoke to fire models. The actors created by it are also retrieving information from this actor for attachement points.

See "Terran Flames" actor for better knowledge how to use it.

#### Events use

**For using each state:**

Event: StateChange

Terms:

* StateValid: (The name of the newly acquired state that is true right now)
* StateChanged: (The previous state before entering this one)

Action: What happens in this transition.

**Don't forget to delete previous states:**

Event: StateChange

Terms:

* !StateValid: (Name of the state that no longer is true). To create the exclamation point, which means that the state is gone, modder must add it in XML view, just put the "!" right before StateValid (no space).

Action: Destroy => Target Box on top => ([ID name of the created actor if one was created off this state]

#### Terms invertion

It is possible to invert the logic of the terms, meaning that they must not be true. Add an exclamation point in XML view, right before the StateChanged word (or the StateValid word) (no space) to invert the logic.

## Field Categories

#### State

Index number, in order in which all term is checked by the Think Interval. Important to mention that the Think Interval does check 1 by 1, but all of them at once. That being said, there is no such use for indexing priority.

#### Terms

The kind of condition for that state to be considered true when the **Think Interval** passes (see next field).

* The simplest way to use this in most cases, would be a validation type, where you can various validators.

### Actor: Think Interval

Amount of time it takes for the actor to periodically check its states.

* This works with the same logic as period durations from Create Persistent effects.
* Consider that the performance of the game can be harmed by shorter Intervals
Data/Effects/Morph

## Morph

#### Description

As it seems newly implented, it looks to be an effect that works like a morph ability. Targetting a unit with this effect will swap its unit stats (and actor's armor icon) into the specified unit, but some features do not swap, such as weapon, abilities (else than move).

### Hint

Tested on a Marine on which you transform it into a Marine over again, the morph seems to reset it, and he is functional still. Tested on a Zergling or a Drone, both of them lost their abilities, except move. They couldn't attack either, even if they had a weapon on their own.

### Exemple Usage

It would work, perhaps if used in the same purpose as Polymorph in Warcraft 2. Transforming the unit into a passive unit such a critter could make this effect handy. However, it is to be considered that the actor doesn't swap when the effect fires up, Otherwise, using an "Apply Behavior" Effect aside from the morph could comply with it, for 2 things: using a "Simple" Actor to modify the model of the morphed unit, and to have a weapon granted by the behavior. Although, this needs to be verified, if functional.

## Fields Description

### (None): Abil Key Fallback

(Unsure) Key to use the actor key cannot be found.

### (None): Actor Key

(To be confirmed) Seems to communicate with an actor, in the eventuallity of the morph's usage.

### (None): Morph Flags

Flags of the effect

* Birth: Morph generates birth event

* Ignore Facing: The Morph will ignore the facing.
* Ignore Placement: The Morph will occur even if the Placement doesn't fit.
* Ignore Morphing: (Unknown)
* Rally Reset: Newly morphed unit loses its old set rally point

### (None): Morph Unit

Unit value in which the effect will transform the target.

### (None): Type Fallback Unit

If no unit should be specified in the **MorphUnit** field, indicates which target will be the morph to become.

### (None): Which Unit

Selects which target in the effect tree is affected by the morph.

#### Value

Location of the unit that gets affected by the morph.
Data/Validators/Unit Compare Charge Used

* Ability: Only at this partcular ability

* Behavior: Only at this particular behavior.

* Global: For all players, a shared charge.

* Player: For the same player, all units/structures with the same ability/behavior share the same charge.

* Unit: At the same unit (morphed accepted if the other unit contains the same ability/behavior). Any ability with the same ID will be considered if it is at the same Unit.

### Unit

Which unit has to be checkedto have his charge validated.

### Value

Numeric value that is compared, for the amount of charge(s).
Data/Game UI Data

### Description

Game UI Data among other things is used for maps and mods to customize some of the display and sound properties with respect to the UI including default camera, selection circles, UI text, minimap colors etc. Usually there is only 1 for any particular map called Default SC2 UI Settings derived from "CGameUI".

## Fields Description

### UI - Selection Colors

* The color of the selection circle around units for allies, enemies, selected and subgroup.

### UI - Vital Colors +

* These are the values for the color of the unit's vitals on the info panel. The defaults are Blue for Shields, Green with several entries approaching Red for Health, Magenta for Energy.
Data/Movers

## Introduction

* Movers determine the pathing used and motion patterns of units when moving or being launched as a missile. Movers with multiple motion phases can be used for activating **Unit Compare Mover Phase** validators or allow for movement patterns that change depending on certain conditions.

## Blizzard tutorial on movers

http://us.battle.net/sc2/en/game/maps-and-mods/tutorials/missile-movers/

## Movers: Sub Types (Classes)

* Avoid
* Flock
* Missile
* Null
Data/Validators/Unit Detected

## Unit Detected

### Description

Simply validates if a unit is being "Detected" by another player. This triggers when a cloaked unit is being revealed by the detector quality of another unit. The quality of a unit being able to detect or radar other units can be selected on a buff behavior.

## Field Categories

### Detected

Works like Enable/Find fields. Toggles if the unit has to be detected or not.

### Flags

* Normal: Indicates to the validator that it is required to validate that the **Unit** has a "detection" interaction.
* Radar: Indicates to the validator that if is required to validate that the **Unit** has a "radar" interaction.

Those interaction mean that they are being either "Detected", either "Radared", or both at the same time, or none of them (this must consider the **Detected** field as well).

### Other Unit

Which other unit is the one detecting/radaring the **Unit**. Leaving this to none would mean that the validator remains true in any situation that the **Unit** is detected/radared from any source.

### Which Player

Further validation of which is player owns the unit that is dected/radared.
Data/Accumulators/Tracked Unit Count Accumulator

* Blizzard has left no core file for this type of Accumulator. The very first one would be created by the editor.

## Field Categories

### (None) - Scale

The constant that is calculated with the number of tracked units.

### (None) - Tracked Unit Filters

Filter that allows this accumulator to use the tracked unit.

### (None) - Tracked Unit Validators

Validator that allows this accumulator to use the tracked unit.