recursal/Fanatic-Fandom huggingface dataset:
Data/Validators/Player Race

## Player Race

### Description

Compares if the race selected by the owner of a unit is a specific race from the Races data type.

### Hint

* Can be used to see what race a player is in order to activate a certain effect.
* If you want other players to be able to capture a certain race unit to trigger the validator use a Unit Compare Field validator instead.

## 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

* Logic function that the number of stacks of the behaviour and the Validator - Value are compared with
* Equal To
* Greater Than (Doesn't work)
* Greater Than Or Equal To
* Less Than (Doesn't work)
* Less Then Or Equal To
* Not Equal To
* (Not Sure) if this works with anything other than equal unless each race represents an integer

### Validator - Failure Result

* The alert from an unknown source that is played if the validator fails to return true

### Validator - Player - Effect

* Specific effect that the scope of which is to be used in combination with the Validator - Unit - Value field to determine the unit validated for the behaviour

### Validator - Player - Value

* Caster: Validates owner of the caster unit.
* Caster Outer: Validates the owner of a unit near the caster.
* Creator: (Unknown)
* Hostile: (Unknown)
* Neutral Player: (Unknown)
* Outer: (Unknown)
* Player Origin: (Unknown)
* Source: Validates the owner of the most recent unit targeted or created by a previous effect in the effect tree
* Target: Validates the owner of the target unit unless specified otherwise by the Target - Launch Unit - Effect field
* Target Outer: Validates the owner of a unit near the target unit unless specified otherwise by the Target - Launch Unit - Effect field
* Unknown: (Unknown)

### Validator - Result - Failure

* Error message that is played when the validator returns false. Allows for use of preset or custom messages and sounds. Only seems to appear when the validator is under the first effect in the effect tree of an ability and is preventing the ability from happening.

### Validator - Value

* Race from the Races data type against with the player is compared with.

### Related

* Races
* Abilities
* Behaviors
* Effects
* Validate Creation Effect
* Validate Player
* Validate Position
* Validate Unit
* Validate Unit Type
Data/Behaviors/Reveal

## Reveal

### Description

This behavior seems to be only used as a core file for setting up "Visibility" field used on damage effects.

### Testing

Used on a unit by manually adding it on, this behavior never seemed to reveal the unit, nor using the duration/filters related. Also, since there is no radius indcator, it leads to think that this behavior is simply a tool used by effect that possess a source and a target manage the duration of reveal parameters.

In other words, this behavior can never be used directly, and will only serve for coordonating hard coding. If further testing prooves otherwise, it is welcome to demonstrate how this behavior can be used. It is used gameplay data for the "Attack Reveal Behavior" field.
Data/Actors/TransferFlag

### **Animator**

Copy as much of the source actor's animation stack as possible, given that the model of the new actor may not have all of the same animations available.

### **Anim Props**

Copy persistent anim props that have been assigned via the AnimGroupApply message.

### **FOW Color**

Copy the source actor's fog of war tinting color.

### **FOW Shader**

Copy from the source actor whether to use a shader to render fog of war.

### **Model**

Copy the model contained by the source actor.

### **Model Materials**

Copy the model materials applied to the source actor. (Glazes)

### **Textures**

Copy the source actor's dynamic textures, to the extent that it is possible.  For example, this copies the source actor's decal textures, provided it is possible to display them on the newly created actor.

### **Status**

Copy the source actor's status variables, which can be created and manipulated with messages like ''StatusSet'', ''StatusIncrement'' and ''StatusDecrement''.
Data/Effects/Use Calldown

## Use Calldown

(Editor Screenshot) need screenshot of ghost nuke splat

### Description

Consumes magazine units set by the Arm Magazine ability to cast an effect or unloads loaded units of the Transport ability using the Effect - Calldown Effect field of the ability.

### Hint

* Several Arm Magazine and Transport abilities can pool for the same use calldown effect
* This effect can be seen as a Use Magazine effect, but with the first difference of doing it from a distance, like a remote controle. The Arm Magazine ability must have this effect in its Calldown effect field in order to "respond" to that remote signal. The second difference is that once the Magazine unit has been pulled out of the its **Arm Magazine** ability, it is no longer considered as an "availlable" calldown charge, whether it gets recalled, ignored or destroyed by the owner of the Arm Magazine ability, in contrary of the **Use Magazine** effect, which can use it over again as much as desired. This is the reason why the nuke ability has a suicide effect, that kills the nuke unit coming out of the silo when the nuke persistant has ended.

## Example Usage

### Ghost - Nuke (Cooldown)

Consumes the Weapon - Nuke magazine unit constructed with the Ghost Academy - Arm Magazine (Nuke) ability to allow ghosts to cast their Ghost - Nuke (Persistant) effect used by the Ghost - Nuclear Strike ability

### Transport Limitation

As transport abilities can also supply a calldown effect (their transpoted units), it is impossible to use a calldown from anything else than Effect - Instant or Effect - Target abilities, which also need to imput the Calldown effect section.

* There also seems to be a placement check when unloading units from this effect, which prevents multiple units to be unloaded at the exact same spot.

## Fields Description

### Effect - Calldown Count

* Number of magazine units consumed to cast the effect
* Consumes random magazine units
* Once used up, those magazine units are no longer usable, even if they're still alive/active or even recalled from by the owner.
* Putting this value in negative is an excellent formulae to break the game (freeze and crash warning!)
* As the description states in the editor, "*if more are requested than are availlable, it will simply use as many as it can find*". This also means that putting 0 here will still consume 1 charge anyway.

### Effect - Calldown Effect

* The effect cast
* Needs full number of magazine units sacrificed
* If no effect is specified it just unloads the magazine/container unit at the target point
* This following effect can refer the calldown unit as "source", if needed.

### Effect - Response Flags

* Determines if units hit by the effect show the aquire/flee response

### Effect - Validators

* Validators that must return true for the effect to be used

## Related

* Arm Magazine
* Transport
Data/Attach Methods/Arc Test

## Arc Test

### Description

Seems to be related to weapons or abilities, validating if they're acquiring or not. This may be some sort of validating attach method.

## Field Categories

### Test

* Action Acquisition: (Unsure) verifies if the unit using this attach method is currently acquiring/approching ?
* Weapon: (Unsure) Scopes on weapon or not, in which case is probably an ability ?

### Type

* Absolute: Filters the test like a validator. It must succeed to return true.
* Fall Back To Closest: Whenever the test fails, will jump the the closest valid attachement point.
* Preference: (Unsure) Whenever the test fails, test the other attachement point and will return this one true in the end, if the others should fail as well.
Data/Validators/Location Type

## Location Type

### Description

This validator type applies other validators depending on whether the target is a point or a unit.

### Creating a Bugged Location Splitter

One could use this validator to split an effect into favoring a point or a unit. The problematic with this validator when attempting to favor locations for different child effects, is that you can get an error message for failing to target the validated true target. For as much as this has been unfixed by Blizzard, there is a bugged method which consist into setting the "Result - Failure" field to "Not Supported". Using it, you can safely create a validator that will target a unit if the validator is true for it, or simply ignore it and cast on the ground if failing the "Unit" validator.

## Fields Description

### Target - Location - Value

Determines the unit or point that is validated.

* This is not some kind of : target must be target unit only, or must be target point only. It only serves as a scope to which location of the effect we're looking for.

### Validator - Point

* Refers to a validator which is checked only if the target is a point. If this validator returns TRUE, then the current validator will return TRUE as well.

### Validator - Result - Failure

* The error message that will display when the validator returns FALSE, if the validator is checked for an interactive ability.

### Validator - Unit

* Refers to a validator which is checked only if the target is a unit. If this validator returns TRUE, then the current validator will return TRUE as well.

## Related

* Behaviors
* Effects
* Validate Creation Effect
* Validate Player
* Validate Position
* Validate Unit
* Validate Unit Type
Data/Abilities/Redirect/Target

### Hint

Mostly used on transports (bunkers). It is also convenient to link it to matching abilities that have target (attack abilities as well) rather than Instant abilities. Yet it seems to work well with attack abilities, but does hardly match with Effect-Target abilities, even if they're auto-cast. As this ability still need to be documented, it is possible that it requires an ability that has its own acquire, other than auto-cast. Or otherwise, perhaps it only matches with Attack Class abilites, this has to be verified. It also seems to be unable to distinguish two different kind of Attack abilities (for exemple loading a unit with the an Attack A ability and another type of unit with Attack B: both will fire from the transport, even if the selected ability from the Redirect-Target is related to Attack A only).

### Example Usage

- Units loaded in a Bunkers have the attack ability. Since the bunker cannot attack on its own, the Redirect - Target allows the units inside to do so.

## Fields Description

### Ability - Ability

Specifies which ability is redirected. If the ability matches with the same one as the units inside, they will be able to use it.

### Ability - Command Buttons

Select the default button and requirements.
Data/Validators/Unit Compare AI Area Evaluation

## Unit Compare AI Area Evaluation

### Description

(Unsure) Probably related to unit's AI Evaluation fields, but with a radius to include anything around (to search them in a certain way). This would reseemble to enumerate area validation, but instead focusing on the AI Evaluation of surrounding units.

## Field Categories

### Other Unit

(Unsure)Which unit's Evaluation is retreived from ?

### Radius

Range of the area in a radius shape that is validated.

### Unit

Which unit is validated inside the determined radius.
Data/Textures

## Textures

### Description

The texture referencing the 2D artwork of the game used for decals, texture swaps and UI cutscenes

### Hints

* Useful for the customisation of actors and browsing for icons

## Example Usage

### AssimilatorDarkDiffuse (Unnamed)

The texture that Texture Select By Id used to replace the diffuse of the Assimilator for the dark protoss in the WoL campaign

### URL

As the Assimilator, it's model and the alternative textures are already in the campaign dependencies, no URL is needed

### BriefingTHanson01\_00

An **.ogv** file cinematic used in the THanson01 mission briefing from the WoL campaign

### URL

As BriefingTHanson01\_00 cinematic is already in the campaign dependencies, no URL is needed

## Fields Description

### File

* The **.dds** or **.ogv** format file used by the texture

### Flags

* **Unify With Model Textures:** (Unknown) On by default

### Movie Sound Settings

* Sound from the Sounds data type with adjustments do the Sound: Speaker Mix field used to adjust the audio of the cinematic
* (Unknown) what other sounds can do

### Movie Sound Settings (5.1)

* Sound from the Sounds data type with adjustments do the Sound: Speaker Mix field used to adjust the audio of the cinematic when using 5.1 surround sound
* (Unknown) what other sounds can do

### Movie Sound Settings (Stereo)

* Sound from the Sounds data type with adjustments do the Sound: Speaker Mix field used to adjust the audio of the cinematic when using stereo sound
* (Unknown) what other sounds can do

### Slot

* The slot and texture layer of the model this texture is to replace when using actor events (eg. Texture Select By Id) to replace textures
* Only accepts non-capitalised strings in the slot.layer format eg. main.diffuse
* Use the same slot and layer as set in the **Texture: Texture Declarations - Adaptions - Texture: Slot** field of the model whose actor is to do the texture swapping

## Related

* Models
* Events
* Sounds
Data/Kinetics

There are 6 categories of Kinetics:

1. **Distance:** Works as **Follow** does, with a rather more strict positioning. As its field state "**Distance Away From**" (regarding the location from), it is not some kind of push back kinetic, but rather, "be at that distance" and its non-negociable.
2. **Follow:** The unit will follow the location as this location is moving. Doesn't forbid the unit under the effect of the kinetic to move on its own, however, it will follow accordingly to the direction of the Follow location if that one is moving. Adding a Distance kinetic on top of this one is useless, since the Distance will force the unit to stay all the same (and even more).
3. **Rotate:** Gives a location to rotate from. This concerns the unit itself, it is not only the actor that's rotating. Be careful, it is possible for rotating unit to move away from the kinetic (breaking it) if the main location keeps jugling itself around a certain point of the rotation. Think of that glitch like creating a swing with the rotation that would eventually launch it out. This can be fixed by joining a **Distance** kinetic.
4. Sequence
5. Set
6. Translate

### URL

https://www.youtube.com/watch?v=7ENQvfvsVuY&t=459s

### Hint

Some field values can only be changed while having the **View Raw Data** button activated.
Snorlax

Location | Land

**Snorlax** is a support Pokémon that can be unlocked in Magikarp Jump.

## Skill

Activating Snorlax's skill immediately generates food in the Pond based on rank.

The food created does not count towards the food limit. If the food is not eaten once Snorlax's skill recovers, using the skill again will still create the full amount of food.

## Random Encounters

Snorlax is featured in the random encounter: Snoozing With Snorlax
Data/Abilities/Morph Placement

## Morph

### Description

A targeted version of Morph. This allows a unit to morph at target location, allowing a placeholder.

### Hint

* To animate a morph, there must be an associated 'morph animation' model.
* It is a struggle for certain players to trace where the placement error sounds originate from. Know it now: it does not come from the ability as it is. They originate from Actors of unit type, particularly in the Error field of the unit using the morph. See a spine crawler/spore Crawler unit actor to understand the placement error sounds are set up.

## Example Usage

Change a Command Center from flying to landed.

## Fields Description

Visit the Morph ability page to view the fields categories, both abilities have the exact same fields.

The only great differences between both abilities are:

1. Morph Placement supports the placement/placeholder system, which allows the player to pop a placement actor on use
2. Morph Placement has the 3 following flags enabled, opposed to the Morph version which disables them.
	* Best Unit
	* Move Blocking Units
	* Show Placeholder

## Related

* Merge
* Mergable
* Morph
Data/Accumulators/Arithmetic

## Arithmetic

### Description

Works like Constant, but instead of only a flat value, gives the opportunity to modify according to the result of a mathematical operation. Each variable of these mathematical operation is to be mixed with other accumulators.

## Field Categories

### (None): Operation

The method for calculating. Dividing, multiplying, adding, substracting, every parameter line.

* Only the final result of it will be the number (constant) that will be run through application rule operation.

### (None): Parameters

The constant used for producing the Arithmetic.

* Each entry is a number that will be operated by the operation. It is pointless to just do math, the idea behind this accumulator is to insert other Accumulators in it and calculate them.
* Be advised, you won't be able to see the accumulators field until you fill up parameters first. Also, when on table view, they are only visible from outside, opening the window doesn't display them (lack of editor ease).
* Each Parameter number always operates its Accumulator according to that array accumulator's application rule. Now if we're talking about the **Operation** field, it is used to operate all the parameter arrays togheter.
* Don't get mixed up with the locations; if the parameter accumulator checks the caster for a behavior stack for example, and yet the intention was to check if the target has that behavior, parameter will still scope on the caster of its parameter accumulator. Also be careful with the Scale and Application rule within the parameter accumulator that is recalled. This must be factored into the formulae.
* Can be used as some kind of validation check. Imagine a parameter that goes 1x(Behavior Stack Count amount on target) and that target has nothing of such a behavior on it...
Data/Actors/Site (Rocker)

# Site (Rocker)

## Description

Actors that tilts/turn a model in diverse axis.

* Turning means a partial rotation that goes back and forth. In other words, this actor creates a looping "go" and "return" system for each kind of axis, ex: **Elevation** lifts up and down, endlessly.
* When using multiple axis, the tilting executes all of them togheter. They can be asynchronous however, if their period differs.

* Before destroying this actor, one can use Transition action (actor events) to gradually smooth it out before removal.
* As far as tested, this actor cannot work if the **elevation** arrays are empty. Not much is needed though, and the value can be under 1, according to the *Anti Grav* *Rocker* Actor (Phoenix's graviton Beam ability)
* Some fields might not work if the value is under 1.
* Some units simply cannot effectuate particular axis tilts; For example, the Battlecruiser can hardly roll, hence not at all. Other units such as Siege Tank (Unsieged) execute the Rocker nicely and can be used for testing.

## Base and Range logic

Each field category in the list below contain 2 imputable values:

* **Base:** Minimum value
* **Range:** Value that is treated as "Random", consecutive to the base value (added to it).

Since each fields contains those fields, we'll cover them all here in one explanation, taking **elevation** as an example:

**Elevation:** Base=0.1 Range=0.05

* Means that the actor will elevate up and down at a distance that goes between 0.1 and 0.15.
* Take note that this distance travelled start below and goes above the unit, letting the unit be the epicenter of the Elevation value.
* Once the **Range** string is given, the final value does not reset its randomness on every cycle, it's limited to one fixed value per actor creation.

**Elevation Period:** Base=4 Range=6

* Means that the actor will take between 4 and 10 seconds time to execute its elevation
* A lower time of course means a faster movement.
* Once the **Range** string is given, the final value does not reset its randomness on every cycle, it's limited to one fixed value per actor creation.

Be careful not to confuse the Range string value with an actual range distance, the name is simply misleading.

It is not mandatory to use the range string. Just use it to add a little bit of randomness.

It is possible to have **Base** 0, but consider at least putting a value in the **Range** if the axis modfication is required.

## Field Categories

### Actor: Elevation Period

Duration over which the site will adjust its elevation

### Actor: Pitch

Up and down tilting motion parameters for the actor

### Actor: Pitch Period

Duration over which the site will adjust its pitch

### Actor: Roll

Side-to-side rolling motion for the actor

### Actor: Roll Period

Duration over which the site will adjust its roll
Data/Actors/FieldTypes/AcceptedTransfers

## Accepted Transfers (*AcceptedTransfers*)

### Description

Determines which additional properties of a source actor will be transferred to a new actor. Copy Source can be set to directly copy from another actor in the same scope(**Unsure** if can be out of actor scope).

### Values

* **Animator:** Allows transfer of the *Animator* from the source
* **Anim Props:** Allows transfer of the *Anim Props* from the source
* **FOW Color:** Allows transfer of the *FOW Color* from the source
* **FOW Shader:** Allows transfer of the *FOW Shader* from the source
* **Model:** Allows transfer of the *Model* from the source
* **Model Materials:** Allows transfer of the *Model Materials* from the source (Glazes)
* **Position:** Allows transfer of the *Position* from the source
* **Rotation:** Allows transfer of the *Rotation* from the source
* **Textures:** Allows transfer of the *Textures* from the source
* **Status:** Allows transfer of the *Statuses* from the source
Data/Validators/Unit Behavior State

## Unit Behavior State

### Description

This validators nearly acts like a Unit Compare Behavior Count but instead, verifies deeper into the Behavior flag found in the Buff Behaviors. This means that any behavior creating this effect on the validated unit will be accepted.

These flags are popular unit states, such as hallucination, stun, unit attribute on, etc. Some of them are the same as some unit filters found in the Unit Filters validator.

### Exemple use

Ghost Cloak uses it to verify that it is not a state of "Supress Energy", in which case the Cloak fails.

## Field Categories

### Enabled

Works the same as **Find** fields on most behaviors. Tells if the behavior state has to be enabled or not.

### Other Unit

Probably validates another unit as well, as both Unit and this one must return true.
Data/Accumulators/Unit Custom Value

## Unit Custom Value

### Description

Used to obtain current custom value of unit specified in **Unit Source** field. Custom values are set in triggers, using **Set Unit Custom Value** action. These accumulators will update immediately upon changing the custom value they get their data from.

## Field Categories

### Fallback Value

The value used if custom value doesn't exist, or if the unit doesn't have this custom value index.
Data/Validators/Unit Compare Power Levels

## Unit Compare Power Levels

### Description

Evaluates the power that is received on the **Unit**. Simply put, it validates what current Power User level strength is currently activated on it. Of course any unit using a Power user behaviors can be evaluated (or any unit receiving the power from a custom source), but what makes it happen is to have a Power Source granting this power level.

* This validator seems however not able to distinguish the Power Link. It can only check for a specific behavior, or all of them (in terms of having X amount of whatever type of power level).

## Field Categories

### Behavior

Name of the specific Power User level to evaluate. Leaving this blank will have any Power User behavior evaluated.

### Other Unit

(Unsure) Any other unit to compare its power level to ?

### Unit

Unit on which the Power User level is checked.

### Value

The numeric value representing the level of the power level required for validation.
Data/Accumulators/Constant

* By luck, Blizzard made us an example for the shield Battery. It shows that a Switch accumulator distinguishes if the shield battery has the boost that makes it recharge for free. If that's the case, it uses a constant, which is 0.

The constant is simply a number, that is not based on anything else than its flat amount, and the application rule.
Data/Effects/Remove Behavior

## Remove Behavior

### Description

Removes all behaviors matching the name/categories/alignement/class mentionned. It may only remove a certain quantity if specified.

Setting a Behavior in this effect will not display it in the effect trees.

### Example use

Starcraft 1 Medic had the restoration ability. This is very possible in a simple way, by imputing no behavior in particular, but simply a category (like restorable). For that, the editor needs to find all behaviors that can be considered as removable and edit their category to "Restorable".

### Discovred Bug

When attempting to remove a behavior based on its Tech\_Alias, this also removes any further behaviors that were created by "that" Tech\_Alias behavior (created from a periodic effect for example).

## Field Categories

### (None) - Exclude Caster Unit

Specifies which caster location will not have a behavior removal.

### (None) - Exclude Origin Player

Specifies which player location will not have a behavior removal.

### (None) - Heroic

Specifies if this effect will affect Heroic units, or not, or both.

Set to any by default.

### (None) - Matches All

Determines whether the effect/validator will be executed if any of the config fields are met or if all config fields need to be met.

### (None) - Require Caster Unit

Specifies which caster location it must be to get a behavior removal.

### (None) - Require Origin Player

Specifies which player location it must be to get a behavior removal.

### (None) - Matches All

This allows users to remove buffs based on StackAlias.

### Effect - Behavior Alignement

In addition to other fields, remove all behaviors with "this" Alignement

### Effect - Behavior Categories

In addition to other fields, remove all behaviors with "this" category

### Effect - Behavior Classes

In addition to other fields, remove all behaviors with "this" class

### Effect - Behavior

Specific name of a behavior to remove.

* Only 1 possible entry here, but can add up with other fields

### Effect - Count

Number of behaviors that are removed by the effect. Use 0 to remove all matching behaviors.

* It is unsure (requires testing) if this removes stacks before or different behaviors in priority, but it sure can do both.

### Effect - Kill Hallucination

Automaticaly kill units with a buff behavior that has the "Hallucination" state flag enabled.

### Effect - Unit

Location of the unit that gets the behavior(s) removal.
Data/Validators/Player Type

## Player Type

### Description

Validates the type of player using the validated player. It is simply the difference between User (a human being) and Computer (AI).

### Exemple Use

* It can be used to combine in an auto-cast validator of an auto-cast ability, which if the computer has to aim more properly than the player, than the player is computer should be combined with Enumerate Area validators allow the computer to use it properly.
* Can also be used to prevent a computer from using an auto-cast ability, that is availlable for all, but should be used by the player (ex: Creating an auto-cast version of Spawn Locust Targeted is pointless, since the computer already uses it).

## Field Categories

### Compare

Operator of the value. Oddly compares it, as It remains easier to use anything that contains the word Equal in it, than using the Greater/Less Than values. While these could be work, this would require deeper testing.

### Other Player

Compares a player to another. A simpler comparaison should be that both player are equal or not.

### Value

* Computer:Controlled by the game itself. Excludes players 0 and 15.
* Hostile: Controlled by the game itself. Exclusively player 15.
* Neutral:Controlled by the game itself. Exclusively player 0.
* None: Returns the validator as false. (or true if the specified player is inexistant ?)
* User: Controlled by a human.
Updates/1.1.0

>
> **Official Update Notes**
>
>
>
> * You can now challenge the  Heal League!
> * You can now fish up new patterns of Magikarp!
> * New events have been added!
> * New Friendship Items and Decorations have been added to the Diamond Shop!
>
>
>

* Added Heal League
	+ Expert League JP moved to after Heal League. Jump Power ranges adjusted accordingly
* Maximum trainer rank increased to 63
* Added Food: Shalour Sable and Lumiose Galette
* Added Training: Frost Cruncher and Soccer Ball Juggle
* Added Decorations: Lilligant Doll and Starmie Bubbler
* Added Friendship Items and corresponding Support Pokémon: Shell Bell and Black Sludge
* Added Swampy Jungle Theme
* Added Apricot and Brown Magikarp Patterns
	+ Added Rare Old Rod
* Added Random Encounters: Our Eyes Met and Research Money
	+ Event numbers reordered.
Data/Validators/Unit Last Damage Player

## Unit Last Damage Player

### Description

As the name states, this validator validates the relationship of the last player that damaged the **Unit**.

## Field Categories

### Other Unit

Probably validates which other unit must have the right relationship. It can also serve to trace it back in the parent effects of an ability. If left to none, the validator will bluntly check the relationship of the last unit damaged the validated unit.

### Relationship

The value of the diplomacy:

* Ally: An allied player of the unit's owner.
* Enemy: An enemy player of the unit's owner. Player 15 is accepted.
* Neutral: A neutral unit. Exclusivly player 0.

* Self: The player that owns the unit.

### Unit

Which unit is validated (the one who received the damage).
Data/Validators/Unit Missile Nullified

### Explanation:

Nullify state can only be produced by a Modify Unit effect. Also, it is irrelavant whether the unit is a missile or not, any unit can be nullified. The reason why the validator carries the word Missile is probably because this modify unit has a greater purpose on missile units, as it seems to do nothing on any other type of unit.

### Exemple use

This validator is used to by defense drones or such that only aim for "Missile" units (filters) from their weapon. In fact, there is a premade core file named "Missile Is Active", on that behalf. This validator avoids the defense drone from aiming twice at a missile that is already nullified, avoiding the waste of firing.

## Field Categories

### Find

Must the Unit be "Nullified".

If yes, then this must be enabled.

### Unit

Which unit is validated as being Nullified or Not. It will mostly likely be a missile, most of the time.
Callbacks

Callbacks are functions called by Starcraft II directly when an event occur.

* InitMap() - After all the galaxy files have been parsed.
* DebugCallback(int player)

##### AI

* AIMeleeStart(int player)
* AINewUnit(int player, unit u)
* AIIsAttacking(int player)
* AINeedsDefending(int player)
* AICombatPriority(unit target, unitgroup attackers, unitgroup enemies)
* AITownIsFull(int player, int town)
* AIWaveThink(int player, wave w, int type)
* AITownWasLost(int player, int town)
* AIMelee(int player)
* AIWaveAddedUnit(int, wave, unit)
* AIGetMaker(int player, string objType)
* AIGetObjectType(int player, string objType)
* AIGetFirstUnfinishedReq(int player, string objType)
* AIGetFirstMissingReq(int player, string objType)
* AIGetDefaultBuildFlags(int player, string objType)
* AISpellPriority(unitgroup src, unitgroup dst)
* AIGetScout(int player, int index, unit prev)
* AIWaveChange(int, wave, int, int)
* AIEarlyDefScout(int player, unit prev)
Decorations

Decorations are cute little items that can be placed within the Pond and in its upper section. It helps with making the area look cute - maybe it will help Magikarp feel less useless! Who knows?!

Decorations may be acquired by beating Leagues or purchased at the Diamond Shop in town using Diamonds.

Decorations also have special effects on Magikarp. They vary with each decoration.

* The effects of any Decorations will always be active, even if they are not placed in the pond.
* Special effects from Decorations may be viewed by checking the Record's Status section.
Mayor Karp

**Mayor Karp** is the mayor and "washed up old man" of **Hoppy Town** in **Magikarp Jump**.

## Summary

The Mayor is a Magikarp aficionado and self-described "washed up old man". He is the first person to reach out to the Trainer about possible competing in the league with a Magikarp.

## Random Encounters

* Idol Riches
* Massage a Karp
* Magikarp Adrift
* Fan Mail
* A Challenge
* Many Wise Words
* Research Money
* 500 Coins?!
* Say Cheese!
Data/Abilities/Buildable

### Hint

MUST be present on a unit that is created via the **Build** ability. Can be modified to create buildings that are constructed faster with more workers present.

### Update 5.0

* CAbilBuildable will now send **Start, Cancel, Complete, Pause, and Resume** events to the actor system.
* Start events will also contain the build time information of the building. Actors will automatically set the build animation to be the same length of the build time. This way, buildings will finish their Birth animations as soon as they finish construction.

## Example Usage

An Drone building a Hydralisk Den, or Starport builing an Add-On.

## Ability

### Cancelable

* Enable/Disable. Sets if the build order can be cancelled during construction.

### Commands+

* Sets the **Cancel** (Quit) and **Halt** (Pause) buttons for unit construction.

### Vital Start Factor

* Sets starting Energy, Life, and Shields at start of unit construction. Fractions based on **Stats - Starting \_\_\_\_\_\_** of unit.
* Ie. Values of (0.1,0.1,0.85) yields a Nexus starting with 1 Life, 1 Shield, and 0 Energy (85% of 0 is still 0).

## Stats

### Maximum Builders

* Max number of units (workers) that can cooperate in construction of a single unit.

### Stats - Power Build Bonus Rate

* Alter the **Stats - Build Time** when multiple units construct a single unit according to the formula:

### Power Build Cost Factor

* Add additional **Stats - Build Cost** to construct a unit when multiple units work together to build it according to:

UI
--

### Activity

* Text to be displayed above the progress bar of the unit's construction.
Data/Data Collections

## Data Collections

### Description

A data collection is a new type of catalog that allows users to declare and group a set of data elements in a collection. A collection can be thought of like any other single piece of data such as a unit, ability, or upgrade.

When copying, renaming, or deleting a data collection, the editor will intelligently apply the same action for all data elements in the collection. For example, when copying a data collection, users will be prompted to provide a name for the new collection. The editor will then duplicate every data entry within the collection and name them accordingly. The editor will also set all linked fields such that the new data entries all point to their new counterparts.

* Deleting a data collection will delete all data entries in the collection.
* Changing the id of a data collection will also change the ids of all data entries in the collection.
* The data entries of a data collection can either be set manually or be auto-populated.
* Data collections make use of a new key character, “@”, in naming child data entries. The data collection system can automatically search the entire catalog to find any data entry whose id starts with the id of the data collection followed by the character, “@”. It will then automatically add them into the collection.
* Because of this linked functionality, whenever the effect tree of an ability is changed, the corresponding data collection and its data entries will automatically be updated.

* **Menu: Data Collection -> Auto Fill Data Collection** will automatically search the entire catalog and find any data entry with an id that starts with the data collection id followed by the character “@”. It will then automatically add them into the corresponding collection.
* **Menu: Data Collection -> Auto Name Data Collection** will rename the data entries of the data collection based on the name of the data collection.
* Data collections also allow us to add extra relationship information between data entries. For example, with data collections, the game can now understand information such as “what is the main actor for this unit?”.
* Many other features in this update are dependent on this data collection feature. Data collections expect certain coding conventions or guidelines to expose their full potential:
	+ All data collection should be as self-contained as possible.
	+ For example, an “Ability collection” should always work whenever you add it to a unit, and an ability should never be hardcoded to only work on specific units or units with specific weapons. As a cautionary example, in the old SC2 database, there was a Void Ray passive that increased damage after attacking for a long duration. This passive was actually fake, and the functionality was hardcoded into the weapon of the Void Ray itself. In this new era with data collections, we heavily discourage this misuse of data. As such, many new features described below were created to help achieve this goal.
Data/Actors/Base

#### Description

* Configures what events this actor responds to, and what messages the actor sends in response to those events.
* Events are explained in detail on Events page

#### ActorEvent

* Send
* Target
* Terms

#### Description

* This is used to remove event responses from this actor that occur in an actor this actor inherits from.
* Events are explained in detail on Events page

#### ActorEvent

* Send
* Target
* Terms

## Relations

* CActor
* CActorAction
* CActorActionOverride
* CActorBearings
* CActorBlob
* CActorCreep
* CActorEventMacro
* CActorEventMacroRunnable
* CActorGlobalConfig
* CActorList
* CActorListPerPlayer
* CActorLookAt
* CActorOverrides
* CActorPower
* CActorProgress
* CActorPropertyCurveSet
* CActorQueryResponse
* CActorScene
* CActorSetQueried
* CActorShieldImpact
* CActorSimple
* CActorSiteOp
* CActorStateMonitor
* CActorTerrain
* CActorTurret
Data/Validators/Is Unit Tracked

## Is Unit Tracked

### Description

Validates if the "Tracked Unit" is tracked by the specified Unit Tracker behavior, belonging to the specified "tracker unit".

* Unsure: It is perhaps possible to track a unit without a valid unit tracker behavior.

## Field Categories

### Behavior Link

The name of the Unit Tracker behavior that is checked upon the tracked unit. This can be handy if multiple Unit Tracker behaviors are in plays.

### Tracked Unit

The specific location of unit that is checked as "tracked" (registered).

### Tracker Unit

The specific location of which unit owns the tracker behavior, tracking the unit.
Data/Actors/Portrait

Key Word to refer to this actor from any unit actor: ::**PortraitGameSelf**

* At basis, this actor plays the Portrait Animation of the model with a "Stand" animation that plays forever. this can be changed to something else if using a cutom model like "Repair Bot" for exemple, that has nicer animations than stand.

* This is useful when editing the portrait reaction to certain events, editing team color on a custom portrait, changing the tint, the time scale, etc. If the portrait model used on the unit contains more animation that can be used, this actor is the one that manages them.
* Use the key word on the "Target" box from any event at the unit's actor to send an action at the Portrait Actor. This avoids creating tons of custom Portrait actor, and simply uses the default one at will. Ex: Unit [ Unit Portrait / Animation Play "Attack" ] and set the target to ::**PortraitGameSelf**. This will cause the portrait to play the attack animation (that must be present on the portrait) each time the unit is clicked/commanded.
Data/Validators/Unit Combat AI

## Unit Combat AI

### Description

Reserved for any units controlled by a computer. (Unsure) This validator returns true if the AI considers the **Unit** to be in combat.

## Field Categories

### Find

Determines if the AI must consider its unit in combat or not.

### Other Unit

Perhaps which other unit is causing the **Unit** to be in combat.

### Unit

Which unit is validated to be in combat or not.
Data/Campaign/Characters

## Characters

### Description

Characters are used as Speakers in Conversation Lines, where it will define the name of the speaker and the color of the text as it appears in the editor and the player screen.

#### Hints

* Most fields are only relevant for Blizzard developers. Name and Color are of interest to map-makers who are working with conversations.

## Fields Description

#### Name

Title of the Character, as it will appear in game Transmission and in the editor.

#### Color

The color you pick will color the subtitle.
Data/Validators/Unit Compare Vital

* Do not confuse with Unit Compare Vitality, which compares both life and shield together without allowing a selection.

### Testing

The exact values going in decrease can be bothersome in some cases. For example, if a validator has to check that a unit has Less than or Equal to 50 Energy, and yet this energy pool is draining down, the validator will not accept the energy at exactly 50, since it is considered as a 50 higher than 50.0000. Hidden decimals would be like 50.9 / 50.8 / etc, going down until the exact 50.0 is reached, but however this will still not accept it until the value has decreased to 49. To solve this, one can make a personalized validator that checks if the Energy is Less than 51, and at the moment energy decreases to 50 with whatever decimal, the validator will pass.

## Field Categories

### Validator: Other Unit

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

### Validator: Type

Type of verification about the vital.

* **Current:** Current amount of vital. Ex: The unit has 5 life out of 100, the 5 is checked.
* **Delta:** Difference between maximum and current vital. Ex: The unit has 5 life out of 100, the value 95 is checked. You can use this type with "Less than" when you want to allow only less than X damage taken on the target location. Also, take note that if this validator is set on a buff behavior with more than 1 stack, it can become affiliated with stacks, decreasing each stacks per delta value (stackable) quantities returning false. It may also have some unwanted behavior when checking a unit shields while the value of the delta is greater than the actual quantity of shield owned by the validated unit. In that case, it might be recommanded to check for the Unit Compare Vitality instead.
* **Fraction:** Percentage amount of vital. Ex: Putting a value of 0.1 means 10%. 1 = 100%.
* **Maximum:** The maximum amount of vital. Ex: The unit has 5 life out of 100, the 100 is checked.

### Validator: Unit

Which main unit has its vital 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.
Data/Validators/Unit Compare Cooldown

## Description

Validator to compare the cooldown of abilities or behaviors.

* This field is not necessary, the Cooldown Link is the only essential part.

* **Equal To** - If the Cooldown is equal to **Value**, then the Validator will return a successful result.
* **Greater Than** - If the Cooldown is greater than **Value**, then the Validator will return a successful result.
* **Greater Than Or Equal To** - If the Cooldown is greater than or equal to **Value**, then the Validator will return a successful result.
* **Less Than** - If the Cooldown is less than **Value**, then the Validator will return a successful result.
* **Less Than Or Equal To** - If the Cooldown is less than or equal to **Value**, then the Validator will return a successful result.
* **Not Equal To** - If the Cooldown is not equal to **Value**, then the Validator will return a successful result.

### Validator - Cooldown

The **Cooldown - Link**, as set in the Ability or Behavior.. This field is primary. The validator won't work without it.

### Validator - Location

The **Cooldown - Location**, as set in the Ability or Behavior. It is very important to identify the very location than set in the ability.

### Validator - Unit

The Unit that the Ability or Behavior is attached to.

### Validator - Value

The value to compare the Cooldown to.
Unlike the Cooldown entry field in the Ability or Behavior, this value is not in seconds. To get the desired compare time in seconds, multiply by 16.16

**For Example:**

* When comparing if the Cooldown is less than 40 seconds, input 646.4 into the Value field and the Validator will return a successful result when the Cooldown has about 40 seconds remaining.
Data/Validators/Unit Compare Damage Dealt Time

## Unit Compare Damage Dealt Time

### Description

Verifies, according to a time value, if the location unit has dealt any form of damage. Verifies the damage dealer, contrary to the Unit Compare Damage Taken Time validator that verifies the damage receiver.

### Exemple use

This validator is to be used at the exact moment the effect is being validated. It will calculate the time at that exact moment. It does not work as requirements do on behaviors. For exemple, if a requirement is false, the behavior is disabled, but enabled back when the requirement is true. This validator only validates at the exact moment the behavior is implented. So when the time is up, it's not validating anymore.

## Field Categories

### Compare

Time operator. Usually, if the unit has dealth damage within a certain past time limit, this can be used as Less than (Less than or Equal , Greater than, Greater or Equal than too). It is about the most logical comprators that can be used, as the others are perhaps too specific.

* If the time is set to 1, with a "Lower than" this means the validator is true if the unit has dealt damage, less than 1 second from the moment this validator kicked in for validation.
* If the unit must have dealt damage since past X time (Compare Greater than the time value).

### Other Unit

If this validator required to validate which unit is getting inflicted damage at, this would serve as its identifier.

### Unit

Which unit is validated as the damage dealer.

### Value

Time value, in seconds. More than 0 promises a successful validator in many cases.
Data/Alerts

## Alerts

### Description

Alerts are notifications that can be generated by any effect. For a effect, assign an alert in the alert field. This will display an icon with text. Optionally can have tooltip, create a map ping at the point of the effect, and play a sound. Alerts appear on the left side of the screen by default.

## Fields Description

### Display

* Which Players this Alert is displayed for, in relation to the player who created the effect that generated this alert
* **Allies:** Displays to the allies of the player who created the effect
* **Self:** Displays to the player who created the effect
* **Enemies:** Displays to the enemies of the player who created the effect
* **Observer:** Displays to observer players
* **Neutral:** Displays to neutral players
* **Other:** Displays to those not in the above categories (replays I believe).

### Duration

* How long the alert remains on the screen

### Fade Time

* How long it takes for the alert to fade out once the duration has expired

### Flags

* **Combined:** Unknown
* **Hide:** Hides the text and icon of the alert. The sound will still play.
* **Ping:** The alert will display a ping at the point of the effect that created this alert

### Ping Model

* The ping model displayed on the minimap

### Primary Actions

* Actions that occur when a player left clicks the alert

### Secondary Actions

* **Flash:**
* **Select:**
* **View:**

### Tooltip

* Tooltip that is viewed by hovering the mouse over the alert