Changes: Data/Validators

Revision as of 01:39, 27 August 2021

Introduction

Validators are boolean conditions that can be applied to any effect. They are also used as conditions for autocasting abilities, as well as determine effect to execute in switch effects and for Actor Events. Validators control whether an effect runs based on the all the validators for the effect returning true.

Validators placed in the first effect of an ability (Like abilites of type Effect - Instant, or Effect - Target) are known as Root Validators. Validators normally will simply cause the effect to fail, but root validators will prevent the use of the ability instead of just failing to run the effect.

Common Fields

All the following fields are found in all validators

Ignore if Channeled

Flag to ignore the validator while channeling. This can apply to persistent effects and behaviors which can be channeled.

Other Unit

As far as it has been tested, this field implies that the "Unit" has to be doing or not the validated action, equal to this field.

Usually set to None, mainly useless for most validators.
DOES NOT indicates at which location the Unit is doing the validated action. Ex: A "Unit Weapon Firing", validating "Unit" target location, with "Caster Unit" location set on "Other Unit" has nothing to do with the target unit attacking caster.

Rather, this means: with the "Find" enabled, the Target unit will validated true if doing the same action as the Caster, if both are firing or not firing their weapons. In this very situation, the validator was not checking if any weapon was firing, but rather, both doing the same action, related to weapon firing/or not. Not using "Other Unit" makes the validator back to normal, only checking if the weapon fires or not (according to Find field) at the "Unit" location. When 2 units are compared, the Find field will rather indicate if the result must be equal or not for both.

However, this statement is flawed in some particular cases: Unit in Weapon Range for example, will identify the "Other Unit" as the target to be in range of the "Unit" location. The subtility in this very case is that each of the "Unit" and "Other Unit" are in range of each others, relative to the "Unit" location at which the weapon range is tested or rather, both are in range of the weapon, which makes them have their common situation result as "validated true". A clearer way to see through would probably be the guess that some validators, such as "Unit Compare Order Queue" have their proper "Target Location" location field AND a "Other Unit" field apart, which is a good clue for understand it.

Result - Failure

The error message that is displayed when the validator fails as part of Root Validation.

Some premade types of results have some unusual effects:
1. "OK" message, which causes the validator to be ignored (returns true forever).
2. "Not Supported" blocks the effect, but, even up to the ability/weapon. For example, a weapon first's effect which is validated by that, returning false, will cause the unit to move to the attack target (instead of attacking it), ignoring the attack ability.
3. Using the default "Error" message and setting a cutom text, that is well checked in the box, doesn't show up properly. The "Error" message will always appear anyway.

@@ Line 20: / Line 20: @@
 Rather, this means: with the "Find" enabled, the Target unit will validated true if doing the same action as the Caster, if both are firing or not firing their weapons. In this very situation, the validator was not checking if any weapon was firing, but rather, both doing the same action, related to weapon firing/or not. Not using "Other Unit" makes the validator back to normal, only checking if the weapon fires or not (according to Find field) at the "Unit" location. When 2 units are compared, the Find field will rather indicate if the result must be equal or not for both.
-However, this statement is false in some particular cases: Unit in Weapon Range for example, will identify the "Other Unit" as the target to be in range of the "Unit" location. The subtility of this field is hard to grasp, hence illogical. A clearer way to see through would probably be the guess that some validators, such as "Unit Compare Order Queue" have their proper "Target Location" location field AND a "Other Unit" field apart, which is a good clue for understand it.
+However, this statement is flawed in some particular cases: [[Data/Validators/Unit In Weapon Range|Unit in Weapon Range]] for example, will identify the "Other Unit" as the target to be in range of the "Unit" location. The subtility in this very case is that each of the "Unit" and "Other Unit" are in range of each others, relative to the "Unit" location at which the weapon range is tested or rather, both are in range of the weapon, which makes them have their common situation result as "validated true". A clearer way to see through would probably be the guess that some validators, such as "Unit Compare Order Queue" have their proper "Target Location" location field AND a "Other Unit" field apart, which is a good clue for understand it.
 === Result - Failure ===