Difference between revisions of "StandardUnitFilter"
(Add new ability_type key) |
Newfrenchy83 (talk | contribs) |
||
(45 intermediate revisions by 8 users not shown) | |||
Line 11: | Line 11: | ||
You can access the filtered unit within the filter as the ''$this_unit'' variable, see [[SingleUnitWML]] for the possible content of these variables | You can access the filtered unit within the filter as the ''$this_unit'' variable, see [[SingleUnitWML]] for the possible content of these variables | ||
− | The term [[StandardUnitFilter]] means that the set of such keys and tags (see below) can appear at that point. Often a [[StandardUnitFilter]] needs to be included in a [filter] tag. But many tags take the [[StandardUnitFilter]] directly as an argument, like [kill] and [have_unit]. See [[Special:WhatLinksHere/StandardUnitFilter]] for tags which can contain a StandardUnitFilter. | + | The term [[StandardUnitFilter]] means that the set of such keys and tags (see below) can appear at that point. Often a [[StandardUnitFilter]] needs to be included in a [filter] tag. But many tags take the [[StandardUnitFilter]] directly as an argument, like [[DirectActionsWML#.5Bkill.5D|[kill]]] and [[ConditionalActionsWML#.5Bhave_unit.5D|[have_unit]]] (which each accept a few additional keys of their own). See [[Special:WhatLinksHere/StandardUnitFilter]] for tags which can contain a StandardUnitFilter. |
− | |||
+ | __TOC__ | ||
The following attributes and sub-tags are allowed: | The following attributes and sub-tags are allowed: | ||
Line 22: | Line 22: | ||
* '''type_adv_tree''': {{DevFeature1.13|7}} matches the type name of the unit and all its advancements (can be a list) | * '''type_adv_tree''': {{DevFeature1.13|7}} matches the type name of the unit and all its advancements (can be a list) | ||
* '''race''': the race of the unit type. This can be a comma-separated list; the unit's race must match one of the given races. <br>Mainline races are listed in data/core/units.cfg<br> | * '''race''': the race of the unit type. This can be a comma-separated list; the unit's race must match one of the given races. <br>Mainline races are listed in data/core/units.cfg<br> | ||
− | * '''ability''': unit has an ability with the given id; see [[AbilitiesWML]] | + | * '''variation''': the unit type variation id (can be a list of variation ids) |
− | * '''ability_type''': unit has an ability with the given type (tag name). | + | * '''has_variation''': matches if the unit type for the unit defines at least one of the variation ids provided as a comma-separated list |
− | * '''status''': {{DevFeature1.13|0}} matches if the unit has the specified status active. This can be a comma-separated list, in which case the unit will match as long as it has one of the listed statuses active | + | * '''upkeep''': {{DevFeature1.15|3}} The upkeep of the unit. Can be either a non-negative number or one of the special values ''loyal'', ''free'', ''full''. Note that while ''loyal'' and ''free'' are synonymous with an upkeep of 0, the value ''full'' is not synonymous with any single numeric value – it is equivalent to <code>$this_unit.level</code>. |
+ | * '''ability''': unit has an ability with the given id; see [[AbilitiesWML]]. This can be a comma-separated list. The unit must have at least one of the specified abilities. | ||
+ | * '''ability_type''': {{DevFeature1.13|7}} unit has an ability with the given type (tag name) - eg, ''ability_type=heals'' will match a unit with any healing ability. | ||
+ | * '''ability_type_active''': {{DevFeature1.13|8}} unit has an ''active'' ability with the given type (tag name). | ||
+ | * '''ability_id_active''': {{DevFeature1.15|13}} unit has an ''active'' ability with the given id; see [[AbilitiesWML]] | ||
+ | * '''trait''': {{DevFeature1.13|8}} This can be a comma-separated list. The unit must have at least one of the specified traits. | ||
+ | * '''status''': {{DevFeature1.13|0}} matches if the unit has the specified status active. This can be a comma-separated list, in which case the unit will match as long as it has one of the listed statuses active (note: possible statuses are listed on the [[SingleUnitWML]] page). | ||
* '''side''': the unit is on the given side (can be a list) | * '''side''': the unit is on the given side (can be a list) | ||
* '''has_weapon''': the unit has a weapon with the given name {{DevFeature1.13|5}} Now deprecated | * '''has_weapon''': the unit has a weapon with the given name {{DevFeature1.13|5}} Now deprecated | ||
− | * '''[has_attack]''': {{DevFeature1.13|5}} the unit has a weapon matching the [[StandardWeaponFilter]]. If this is present, '''has_weapon''' is ignored. | + | * {{anchor|has_attack|'''[has_attack]'''}}: {{DevFeature1.13|5}} the unit has a weapon matching the [[StandardWeaponFilter]]. If this is present, '''has_weapon''' is ignored. |
* '''canrecruit''': yes if the unit can recruit (i.e. is a leader) | * '''canrecruit''': yes if the unit can recruit (i.e. is a leader) | ||
* '''gender''': female if the unit is female rather than the default of male | * '''gender''': female if the unit is female rather than the default of male | ||
* '''role''': the unit has been assigned the given role; see '''[role]''', [[InternalActionsWML]] | * '''role''': the unit has been assigned the given role; see '''[role]''', [[InternalActionsWML]] | ||
− | * '''level''': the level of the unit | + | * '''level''': the level of the unit (this can be a comma-separated list). |
* '''defense''': current defense of the unit on current tile (chance to hit %, like in movement type definitions) | * '''defense''': current defense of the unit on current tile (chance to hit %, like in movement type definitions) | ||
− | * '''movement_cost''': current movement cost of the unit on current tile | + | * '''movement_cost''': current movement cost of the unit on current tile. Can be a number, range, or comma separated range. |
− | * '''x,y''': the position of the unit. Note: | + | * '''x,y''': the position of the unit. Note: As a special case '''x,y=recall,recall''' matches units on the recall list. Note that the similar '''search_recall_list=yes''' key is only available as part of the '''[have_unit]''' condition tag, and is not otherwise considered part of a StandardUnitFilter. |
− | * '''find_in''': name of an array or container variable; if present, the unit will not match unless | + | * '''find_in''': name of an array or container variable; if present, the unit will not match unless a unit with the same '''id''' is already stored in the variable |
− | * '''[filter_vision]''': this tests whether or not the unit is currently visible | + | * {{anchor|filter_vision|'''[filter_vision]'''}}: this tests whether or not the unit is currently visible |
** '''visible''': yes or no, default yes. When "yes", this matches units that are not obscured by fog or shroud, and that are not hiding (via the {{tag|AbilitiesWML|hides}} ability). When "no", this matches units that are obscured by fog or shroud, or that are hiding. | ** '''visible''': yes or no, default yes. When "yes", this matches units that are not obscured by fog or shroud, and that are not hiding (via the {{tag|AbilitiesWML|hides}} ability). When "no", this matches units that are obscured by fog or shroud, or that are hiding. | ||
** [[StandardSideFilter]] tags and keys. Filter for who may be able to see (or not see) the unit. If there is *at least one* matching side which can see the unit then the filter matches, and otherwise it fails to match. | ** [[StandardSideFilter]] tags and keys. Filter for who may be able to see (or not see) the unit. If there is *at least one* matching side which can see the unit then the filter matches, and otherwise it fails to match. | ||
− | * '''[filter_wml]''': | + | * {{anchor|filter_wml|'''[filter_wml]'''}}: Converts the unit to WML (as if by '''[store_unit]''') and tests it against a [[FilterWML#Filtering_on_WML_data|WML filter]]. For a list of things in the WML that could be filtered on, see [[SingleUnitWML]] or open a saved game in a text editor. Note that this is slower than other methods, so if possible it's better to use other filter keys and tags; however, if the WML filter contains only a child '''[variables]''', then the unit is not converted to WML and the filter is matched only against the unit's variables (which are already WML). |
* '''[and]''': an extra unit filter. Unless the unit also matches the [and] filter, then it will not count as a match. ''Note: [and],[or], and [not] filters are considered after the containing filter; they are then processed in the order encountered.'' | * '''[and]''': an extra unit filter. Unless the unit also matches the [and] filter, then it will not count as a match. ''Note: [and],[or], and [not] filters are considered after the containing filter; they are then processed in the order encountered.'' | ||
* '''[or]''': an extra unit filter. If a unit matches the [or] filter, then it will count as a match regardless of conditions in previous filters or the containing filter. | * '''[or]''': an extra unit filter. If a unit matches the [or] filter, then it will count as a match regardless of conditions in previous filters or the containing filter. | ||
* '''[not]''': an extra unit filter. If a unit matches the [not] filter, then that unit will not be considered a match by the containing filter. | * '''[not]''': an extra unit filter. If a unit matches the [not] filter, then that unit will not be considered a match by the containing filter. | ||
− | * '''[filter_adjacent]''' with a StandardUnitFilter as argument; do not use a [filter] tag. If present the correct number of adjacent units must match this filter. | + | * {{anchor|filter_adjacent|'''[filter_adjacent]'''}} with a StandardUnitFilter as argument; do not use a [filter] tag. If present the correct number of adjacent units must match this filter. |
**'''StandardUnitFilter''' tags and keys | **'''StandardUnitFilter''' tags and keys | ||
** '''count''': a number, range, or comma separated range; default "1-6" | ** '''count''': a number, range, or comma separated range; default "1-6" | ||
Line 52: | Line 58: | ||
*'''[filter_side]''': The currently filtered unit's side must match this [[StandardSideFilter]] for the unit to match. | *'''[filter_side]''': The currently filtered unit's side must match this [[StandardSideFilter]] for the unit to match. | ||
**[[StandardSideFilter]] tags and keys | **[[StandardSideFilter]] tags and keys | ||
− | * '''formula''': A formula using [[Wesnoth Formula Language]]. The <tt>self</tt> variable is set to the current $this_unit, and the formula should return a boolean. If it returns 0, the filter does not match. Otherwise, the filter does match. {{DevFeature1.13|5}} If the filter has a secondary unit, the formula can access it using the <code>other</code> variable. | + | * '''formula''': A formula using [[Wesnoth Formula Language]]. The <tt>self</tt> variable is set to the current $this_unit, and the formula should return a boolean. If it returns 0, the filter does not match. Otherwise, the filter does match. {{DevFeature1.13|5}} If the filter has a secondary unit, the formula can access it using the <code>other</code> variable. Both the unit and the secondary unit are a '''unit object''', with keys documented [[#Wesnoth_Formula_Language|below]]. Do not surround the formula in <code>$(...)</code>, since that will erase the <tt>self</tt> variable. |
* '''lua_function''': the name of a [[LuaWML|Lua]] function in the global environment that takes a unit as an argument and returns true if the given unit matches the filter. {{DevFeature1.13|5}} Non-global functions can now be used here by building a dot-separated "path". Note that this is not actually interpreted as Lua code even though it superficially resembles it, so using a Lua keyword in the path will work, for example "my_filter_functions.goto" will correctly use the function which in actual Lua code would need to be referenced as <code>my_filter_functions["goto"]</code>. | * '''lua_function''': the name of a [[LuaWML|Lua]] function in the global environment that takes a unit as an argument and returns true if the given unit matches the filter. {{DevFeature1.13|5}} Non-global functions can now be used here by building a dot-separated "path". Note that this is not actually interpreted as Lua code even though it superficially resembles it, so using a Lua keyword in the path will work, for example "my_filter_functions.goto" will correctly use the function which in actual Lua code would need to be referenced as <code>my_filter_functions["goto"]</code>. | ||
+ | * {{anchor|filter_ability|'''[experimental_filter_ability]'''}}: {{DevFeature1.17|17}} [[StandardAbilityFilter]] matches if the unit has an ability with the given properties - eg, ''[experimental_filter_ability]affect_self=yes'' will match a unit with any ability with ''affect_self=yes''. {{DevFeature1.19|5}} [experimental_filter_ability] deprecated, use [filter_ability] instead. | ||
+ | * {{anchor|filter_ability_active|'''[experimental_filter_ability_active]'''}}: {{DevFeature1.17|17}} [[StandardAbilityFilter]] matches if the unit has an ''active'' ability with the given properties - eg, ''[experimental_filter_ability_active]affect_adjacent=yes'' will match a unit with any ''active'' ability with ''[affect_adjacent]''. The attributes checked are the same as for [experimental_filter_ability]. {{DevFeature1.19|5}} [experimental_filter_ability_active] deprecated, use [filter_ability] instead. | ||
+ | * '''[filter_ability]''': {{DevFeature1.19|5}} [[StandardAbilityFilter]] matches if the unit has anability with the given properties - eg, ''[filter_ability]affect_adjacent=yes'' will match a unit with any ability with ''[affect_adjacent]''. | ||
+ | ** '''active''': if active=yes, matches if the unit has an ''active'' ability with the given properties, if active=no, matches if the unit has an ability with the given properties regardless of 'active' or not. '''active''' is false by default. | ||
+ | |||
+ | == [[Wesnoth Formula Language]] == | ||
+ | |||
+ | When using the '''formula''' key, the '''self''' and (if present) '''other''' objects support the following keys: | ||
+ | |||
+ | * '''x''', '''y''', '''loc''' - the latter is a '''location object''' such as what would be returned from [[Wesnoth_Formula_Language#loc|loc()]]. | ||
+ | * '''id''' | ||
+ | * '''type''' | ||
+ | * '''name''' | ||
+ | * '''usage''' | ||
+ | * '''canrecruit''', '''leader''' | ||
+ | * '''undead''' - true if the unit has the ''not_living'' status | ||
+ | * '''attacks''' - a list of '''[[FilterWML#Filtering_Weapons|weapon objects]]''' | ||
+ | * '''abilities''' - a list of the ability IDs the unit possesses | ||
+ | * '''hitpoints''', '''max_hitpoints''' | ||
+ | * '''experience''', '''max_experience''' | ||
+ | * '''moves''', '''max_moves''' | ||
+ | * '''attacks_left''', '''max_attacks''' | ||
+ | * '''level''', '''full''' - '''full''' refers to the unit's level to support the formula <syntaxhighlight lang=wfl inline>upkeep = full</syntaxhighlight> | ||
+ | * '''traits''' - a list of the trait IDs | ||
+ | * '''objects''' {{DevFeature1.19|0}} - a list of the objects IDs | ||
+ | * '''advancements_taken''' {{DevFeature1.19|0}} - a list of the advancements taken IDs | ||
+ | * '''traits_count''' {{DevFeature1.19|0}} - number of traits used by unit regardless of IDs | ||
+ | * '''objects_count''' {{DevFeature1.19|0}} - number of objects used by unit regardless of IDs | ||
+ | * '''advancements_taken_count''' {{DevFeature1.19|0}} - number of advancements taken used by unit regardless of IDs | ||
+ | * '''extra_recruit''' | ||
+ | * '''advances_to''' | ||
+ | * '''status''' - a list of active statuses | ||
+ | * '''side_number''' | ||
+ | * '''cost''' | ||
+ | * '''upkeep''' | ||
+ | * '''loyal''' - a constant 0 to support the formula <syntaxhighlight lang=wfl inline>upkeep = loyal</syntaxhighlight> | ||
+ | * '''hidden''' | ||
+ | * '''petrified''' - true if the unit has the '''petrified''' status | ||
+ | * '''resting''' | ||
+ | * '''role''' | ||
+ | * '''race''' | ||
+ | * '''gender''' | ||
+ | * '''variation''' | ||
+ | * '''zoc''' | ||
+ | * '''alignment''' | ||
+ | * '''facing''' | ||
+ | * '''resistance''', '''movement_cost''', '''vision_cost''', '''jamming_cost''', '''defense''' - {{DevFeature1.15|3}} Maps containing the basic movetype data. The '''defense''' and '''resistance''' maps contain the actual defense and resistance values, rather than the values specified in the WML, so you do not need to subtract them from 100. | ||
+ | * '''flying''' {{DevFeature1.15|3}} | ||
+ | * '''fearless''', '''healthy''' {{DevFeature1.19|4}} | ||
+ | * '''vars''' - WFL variables owned by the unit, which can be set and used by FormulaAI | ||
+ | * '''wml_vars''' - the WML variables stored in the unit | ||
+ | * '''n''', '''s''', '''ne''', '''se''', '''nw''', '''sw''', '''lawful''', '''chaotic''', '''neutral''', '''liminal''', '''male''', '''female''' - these are all defined to be the equivalent string so that, for example, you can write a formula like <syntaxhighlight lang=wfl inline>alignment = liminal and gender = female</syntaxhighlight> without needing to quote the alignment and gender strings. | ||
== A Note about Re-Using the Same Attribute == | == A Note about Re-Using the Same Attribute == | ||
You are limited to having each attribute, such as '''id''', appear once or less in a [[StandardUnitFilter]]. However, this can be worked around. If you have several specific units you want excepted from matching, use a separate [or] subfilters for each one. Also you can use [not] subfilters. For example to kill ([kill] uses the standard unit filter) all units except Gwiti Ha'atel and Tanar you can do the following: | You are limited to having each attribute, such as '''id''', appear once or less in a [[StandardUnitFilter]]. However, this can be worked around. If you have several specific units you want excepted from matching, use a separate [or] subfilters for each one. Also you can use [not] subfilters. For example to kill ([kill] uses the standard unit filter) all units except Gwiti Ha'atel and Tanar you can do the following: | ||
− | + | ||
+ | <syntaxhighlight lang='wml'> | ||
+ | [kill] | ||
[not] | [not] | ||
− | + | id=Gwiti Ha'atel | |
[/not] | [/not] | ||
[not] | [not] | ||
− | + | id=Tanar | |
[/not] | [/not] | ||
− | + | [/kill] | |
− | + | </syntaxhighlight> | |
− | + | ||
+ | And similarly if you wanted to kill both Gwiti Ha'atel and Tanar, but no one else you could do the following: | ||
+ | |||
+ | <syntaxhighlight lang='wml'> | ||
+ | [kill] | ||
id=Gwiti Ha'atel | id=Gwiti Ha'atel | ||
[or] | [or] | ||
− | + | id=Tanar | |
[/or] | [/or] | ||
− | + | [/kill] | |
+ | </syntaxhighlight> | ||
+ | |||
+ | == Tutorial == | ||
+ | |||
+ | * [[FilterWML/Examples_-_How_to_use_Filter|How To Use Filter (with examples)]] | ||
== See Also == | == See Also == | ||
− | * [ | + | * [[FilterWML]] |
− | + | * [[ReferenceWML]] | |
[[Category: WML Reference]] | [[Category: WML Reference]] |
Latest revision as of 17:12, 3 November 2024
From FilterWML, this is the standard way of filtering units.
When a unit filter is applied to a map, first it applies to all units on the field, based on their coordinates. Next it applies to units in the recall list. This is important to remember as it means, for example, that the tag [kill] can be used to kill units in the recall list.
You can access the filtered unit within the filter as the $this_unit variable, see SingleUnitWML for the possible content of these variables
The term StandardUnitFilter means that the set of such keys and tags (see below) can appear at that point. Often a StandardUnitFilter needs to be included in a [filter] tag. But many tags take the StandardUnitFilter directly as an argument, like [kill] and [have_unit] (which each accept a few additional keys of their own). See Special:WhatLinksHere/StandardUnitFilter for tags which can contain a StandardUnitFilter.
Contents
The following attributes and sub-tags are allowed:
- id: unit matches the given id. This is the same as id in the [unit] tag. Note that it is independent of a unit's user-visible name, which can be internationalized independent of this (see SingleUnitWML). id= can be a comma-separated list, every unit with one of these ids matches.
- speaker: alias for id (no comma-separated list supported)
- type: matches the unit's type name (can be a list of types)
- type_adv_tree: (Version 1.13.7 and later only) matches the type name of the unit and all its advancements (can be a list)
- race: the race of the unit type. This can be a comma-separated list; the unit's race must match one of the given races.
Mainline races are listed in data/core/units.cfg - variation: the unit type variation id (can be a list of variation ids)
- has_variation: matches if the unit type for the unit defines at least one of the variation ids provided as a comma-separated list
- upkeep: (Version 1.15.3 and later only) The upkeep of the unit. Can be either a non-negative number or one of the special values loyal, free, full. Note that while loyal and free are synonymous with an upkeep of 0, the value full is not synonymous with any single numeric value – it is equivalent to
$this_unit.level
. - ability: unit has an ability with the given id; see AbilitiesWML. This can be a comma-separated list. The unit must have at least one of the specified abilities.
- ability_type: (Version 1.13.7 and later only) unit has an ability with the given type (tag name) - eg, ability_type=heals will match a unit with any healing ability.
- ability_type_active: (Version 1.13.8 and later only) unit has an active ability with the given type (tag name).
- ability_id_active: (Version 1.15.13 and later only) unit has an active ability with the given id; see AbilitiesWML
- trait: (Version 1.13.8 and later only) This can be a comma-separated list. The unit must have at least one of the specified traits.
- status: (Version 1.13.0 and later only) matches if the unit has the specified status active. This can be a comma-separated list, in which case the unit will match as long as it has one of the listed statuses active (note: possible statuses are listed on the SingleUnitWML page).
- side: the unit is on the given side (can be a list)
- has_weapon: the unit has a weapon with the given name (Version 1.13.5 and later only) Now deprecated
- [has_attack]: (Version 1.13.5 and later only) the unit has a weapon matching the StandardWeaponFilter. If this is present, has_weapon is ignored.
- canrecruit: yes if the unit can recruit (i.e. is a leader)
- gender: female if the unit is female rather than the default of male
- role: the unit has been assigned the given role; see [role], InternalActionsWML
- level: the level of the unit (this can be a comma-separated list).
- defense: current defense of the unit on current tile (chance to hit %, like in movement type definitions)
- movement_cost: current movement cost of the unit on current tile. Can be a number, range, or comma separated range.
- x,y: the position of the unit. Note: As a special case x,y=recall,recall matches units on the recall list. Note that the similar search_recall_list=yes key is only available as part of the [have_unit] condition tag, and is not otherwise considered part of a StandardUnitFilter.
- find_in: name of an array or container variable; if present, the unit will not match unless a unit with the same id is already stored in the variable
- [filter_vision]: this tests whether or not the unit is currently visible
- visible: yes or no, default yes. When "yes", this matches units that are not obscured by fog or shroud, and that are not hiding (via the [hides] ability). When "no", this matches units that are obscured by fog or shroud, or that are hiding.
- StandardSideFilter tags and keys. Filter for who may be able to see (or not see) the unit. If there is *at least one* matching side which can see the unit then the filter matches, and otherwise it fails to match.
- [filter_wml]: Converts the unit to WML (as if by [store_unit]) and tests it against a WML filter. For a list of things in the WML that could be filtered on, see SingleUnitWML or open a saved game in a text editor. Note that this is slower than other methods, so if possible it's better to use other filter keys and tags; however, if the WML filter contains only a child [variables], then the unit is not converted to WML and the filter is matched only against the unit's variables (which are already WML).
- [and]: an extra unit filter. Unless the unit also matches the [and] filter, then it will not count as a match. Note: [and],[or], and [not] filters are considered after the containing filter; they are then processed in the order encountered.
- [or]: an extra unit filter. If a unit matches the [or] filter, then it will count as a match regardless of conditions in previous filters or the containing filter.
- [not]: an extra unit filter. If a unit matches the [not] filter, then that unit will not be considered a match by the containing filter.
- [filter_adjacent] with a StandardUnitFilter as argument; do not use a [filter] tag. If present the correct number of adjacent units must match this filter.
- StandardUnitFilter tags and keys
- count: a number, range, or comma separated range; default "1-6"
- adjacent: a comma separated list of directions; default "n,ne,se,s,sw,nw" (see notes)
- is_enemy: a boolean specifying whether the adjacent unit must be an enemy or an ally (optional)
- $other_unit: (Version 1.13.2 and later only) Within [filter_adjacent], the special variable $other_unit refers to the filtered unit from the enclosing filter, while $this_unit refers (as with all StandardUnitFilters) to the unit being filtered on.
- [filter_location]: StandardLocationFilter - the tile that the unit is standing on matches the location filter.
- [filter_side]: The currently filtered unit's side must match this StandardSideFilter for the unit to match.
- StandardSideFilter tags and keys
- formula: A formula using Wesnoth Formula Language. The self variable is set to the current $this_unit, and the formula should return a boolean. If it returns 0, the filter does not match. Otherwise, the filter does match. (Version 1.13.5 and later only) If the filter has a secondary unit, the formula can access it using the
other
variable. Both the unit and the secondary unit are a unit object, with keys documented below. Do not surround the formula in$(...)
, since that will erase the self variable. - lua_function: the name of a Lua function in the global environment that takes a unit as an argument and returns true if the given unit matches the filter. (Version 1.13.5 and later only) Non-global functions can now be used here by building a dot-separated "path". Note that this is not actually interpreted as Lua code even though it superficially resembles it, so using a Lua keyword in the path will work, for example "my_filter_functions.goto" will correctly use the function which in actual Lua code would need to be referenced as
my_filter_functions["goto"]
. - [experimental_filter_ability]: (Version 1.17.17 and later only) StandardAbilityFilter matches if the unit has an ability with the given properties - eg, [experimental_filter_ability]affect_self=yes will match a unit with any ability with affect_self=yes. (Version 1.19.5 and later only) [experimental_filter_ability] deprecated, use [filter_ability] instead.
- [experimental_filter_ability_active]: (Version 1.17.17 and later only) StandardAbilityFilter matches if the unit has an active ability with the given properties - eg, [experimental_filter_ability_active]affect_adjacent=yes will match a unit with any active ability with [affect_adjacent]. The attributes checked are the same as for [experimental_filter_ability]. (Version 1.19.5 and later only) [experimental_filter_ability_active] deprecated, use [filter_ability] instead.
- [filter_ability]: (Version 1.19.5 and later only) StandardAbilityFilter matches if the unit has anability with the given properties - eg, [filter_ability]affect_adjacent=yes will match a unit with any ability with [affect_adjacent].
- active: if active=yes, matches if the unit has an active ability with the given properties, if active=no, matches if the unit has an ability with the given properties regardless of 'active' or not. active is false by default.
Wesnoth Formula Language
When using the formula key, the self and (if present) other objects support the following keys:
- x, y, loc - the latter is a location object such as what would be returned from loc().
- id
- type
- name
- usage
- canrecruit, leader
- undead - true if the unit has the not_living status
- attacks - a list of weapon objects
- abilities - a list of the ability IDs the unit possesses
- hitpoints, max_hitpoints
- experience, max_experience
- moves, max_moves
- attacks_left, max_attacks
- level, full - full refers to the unit's level to support the formula
upkeep = full
- traits - a list of the trait IDs
- objects (Version 1.19.0 and later only) - a list of the objects IDs
- advancements_taken (Version 1.19.0 and later only) - a list of the advancements taken IDs
- traits_count (Version 1.19.0 and later only) - number of traits used by unit regardless of IDs
- objects_count (Version 1.19.0 and later only) - number of objects used by unit regardless of IDs
- advancements_taken_count (Version 1.19.0 and later only) - number of advancements taken used by unit regardless of IDs
- extra_recruit
- advances_to
- status - a list of active statuses
- side_number
- cost
- upkeep
- loyal - a constant 0 to support the formula
upkeep = loyal
- hidden
- petrified - true if the unit has the petrified status
- resting
- role
- race
- gender
- variation
- zoc
- alignment
- facing
- resistance, movement_cost, vision_cost, jamming_cost, defense - (Version 1.15.3 and later only) Maps containing the basic movetype data. The defense and resistance maps contain the actual defense and resistance values, rather than the values specified in the WML, so you do not need to subtract them from 100.
- flying (Version 1.15.3 and later only)
- fearless, healthy (Version 1.19.4 and later only)
- vars - WFL variables owned by the unit, which can be set and used by FormulaAI
- wml_vars - the WML variables stored in the unit
- n, s, ne, se, nw, sw, lawful, chaotic, neutral, liminal, male, female - these are all defined to be the equivalent string so that, for example, you can write a formula like
alignment = liminal and gender = female
without needing to quote the alignment and gender strings.
A Note about Re-Using the Same Attribute
You are limited to having each attribute, such as id, appear once or less in a StandardUnitFilter. However, this can be worked around. If you have several specific units you want excepted from matching, use a separate [or] subfilters for each one. Also you can use [not] subfilters. For example to kill ([kill] uses the standard unit filter) all units except Gwiti Ha'atel and Tanar you can do the following:
[kill]
[not]
id=Gwiti Ha'atel
[/not]
[not]
id=Tanar
[/not]
[/kill]
And similarly if you wanted to kill both Gwiti Ha'atel and Tanar, but no one else you could do the following:
[kill]
id=Gwiti Ha'atel
[or]
id=Tanar
[/or]
[/kill]