Difference between revisions of "UnitsWML"
(→[race]) |
(→[trait]) |
||
(33 intermediate revisions by 8 users not shown) | |||
Line 3: | Line 3: | ||
The '''[units]''' tag is a [[ReferenceWML#WML_toplevel_tags|top-level WML tag]] which defines the unit types that will be available in the game. | The '''[units]''' tag is a [[ReferenceWML#WML_toplevel_tags|top-level WML tag]] which defines the unit types that will be available in the game. | ||
− | A [units] tag primarily contains [[UnitTypeWML|[unit_type]]] tags, each of which defines one unit type, and can also contain other tags, which mostly provide definitions of things like races and movement types that are used in unit type definitions. | + | A '''[units]''' tag primarily contains [[UnitTypeWML|[unit_type]]] tags, each of which defines one unit type, and can also contain other tags, which mostly provide definitions of things like races and movement types that are used in unit type definitions. |
== Subtags of [units] == | == Subtags of [units] == | ||
− | The following tags can be used as subtags of a [units] tag. | + | The following tags can be used as subtags of a '''[units]''' tag. |
=== [unit_type] === | === [unit_type] === | ||
Line 13: | Line 13: | ||
{{Main|UnitTypeWML}} | {{Main|UnitTypeWML}} | ||
− | In a [units] tag, a [unit_type] tag defines a unit type. | + | In a '''[units]''' tag, a '''[unit_type]''' tag defines a unit type. |
=== [trait] === | === [trait] === | ||
− | The [trait] tag describes a trait. When it appears in the [units] toplevel, it describes a global trait, and all races with the attribute '''ignore_global_traits=no''' will have this trait.; it may also appear in other places. | + | The '''[trait]''' tag describes a trait. When it appears in the '''[units]''' toplevel, it describes a global trait, and all races with the attribute '''ignore_global_traits=no''' will have this trait.; it may also appear in other places. |
− | * '''id''': unique identifier | + | * '''id''': unique identifier; needed for random trait generation to work properly |
− | * '''availability''': describes whether a trait is "musthave" for a race or is available to "any" unit | + | * '''availability''': describes whether a trait is "musthave" for a race/unit type or is available to "any" unit, including leaders. The default is for a trait to only be available to nonleaders. Currently "any" should not be used for traits available in multiplayer. It can be used for campaign specific traits. |
* '''male_name''': text displayed in the status of unit with the trait if the unit is male. | * '''male_name''': text displayed in the status of unit with the trait if the unit is male. | ||
* '''female_name''': text displayed in the status of unit with the trait if the unit is female. | * '''female_name''': text displayed in the status of unit with the trait if the unit is female. | ||
* '''name''': text displayed in the status of unit with the trait if none of the two above is used. | * '''name''': text displayed in the status of unit with the trait if none of the two above is used. | ||
− | * '''description''': text displayed for the description of the trait. | + | * '''description''': text displayed for the description of the trait when moving the cursor over the trait. |
+ | * '''help_text''': {{DevFeature1.13|6}} text displayed for the description of the trait in the help. Defaults to ''description'' if not specified. | ||
* '''[effect]''': described in [[EffectWML]]. More than one of these can be used. | * '''[effect]''': described in [[EffectWML]]. More than one of these can be used. | ||
+ | * '''require_traits''': {{DevFeature1.17|13}} An optional comma-separated list of trait id keys that represent traits that are required by this one. Order is not important. If the unit not already has all of the traits that appear in this list, then this trait will not be generated for this unit. | ||
+ | * '''exclude_traits''': {{DevFeature1.17|13}} An optional comma-separated list of trait id keys that represent traits that are mutually exclusive to this one. Order is not important. If the unit already has any of the traits that appear once in this list, then this trait will not be generated for this unit. Of course, for this to really make two traits mutually exclusive, you need to add exclude_traits to both trait definitions. | ||
=== [movetype] === | === [movetype] === | ||
− | The [movetype] tag is used to make shortcuts to describe units with similar terrain handicaps. Units from the same advancement tree should generally have the same movetype. | + | The '''[movetype]''' tag is used to make shortcuts to describe units with similar terrain handicaps. Units from the same advancement tree should generally have the same movetype. |
* '''name''': an ID for this movetype. Units with the attribute '''movement_type=''name''''' will be assigned this movetype. | * '''name''': an ID for this movetype. Units with the attribute '''movement_type=''name''''' will be assigned this movetype. | ||
− | * '''flies''': either ' | + | * '''flies''' or {{DevFeature1.15|0}} '''flying''': either 'yes' or 'no' (default). A unit with ''flying=yes'' does not have its image's height adjusted for different terrains. |
− | * '''[movement_costs]''': describes how fast the unit moves on different terrains. The attribute '''terrain='' | + | ** This key corresponds to [unit]'s '''flying''' key. |
− | * '''[vision_costs]''': describes how far the unit clears fog and shroud on different terrains. The attribute '''terrain=''cost''''' means that the unit will need to use ''cost'' vision points to view into | + | ** In Wesnoth 1.12 and 1.14, the value of '''flying''' sometimes overrides the value of '''flies''', but in other times '''flying''' is ignored |
− | * '''[defense]''': describes how likely the unit is to be hit on different terrains. The attribute '''terrain=''defense''''' means that the unit will be hit ''defense'' percent of the time in | + | ** {{DevFeature1.15|0}} '''flying''' always overrides the '''flies''' value, with the intention that '''flies''' will be deprecated. |
− | + | * '''[special_note]''' {{DevFeature1.15|14}} note=Translatable string, which can be set if there’s something special about this movetype. It will be displayed in the unit's help page. For typical movetypes this is not set. An example are horses with the ''mounted'' movetype. See also [[UnitTypeWML#Special_Notes]]. | |
+ | * {{anchor|resistance|'''[resistance]'''}}: describes how much damage the unit takes from different types of attacks. The attribute '''''type''=''resistance''''' makes the unit receive ''resistance'' percent of damage, or resist '''100-resistance''' percent of damage from attacks with '''type=''type'''''. So for example, a resistance of fire=110 means, this unit will receive 110% of damage, or have a resistance of -10% as displayed in-game. A value of fire=0 would mean, the unit receives no damage and therefore has a resistance of 100%.<br> The available attack types in mainline are blade, pierce, impact, fire, cold, and arcane. | ||
+ | * {{anchor|movement_costs|'''[movement_costs]'''}}: describes how fast the unit moves on different terrains. The attribute '''''terrain''=''cost''''' means that the unit will need to use ''cost'' move points to move onto that ''terrain''. | ||
+ | * {{anchor|vision_costs|'''[vision_costs]'''}}: describes how far the unit clears fog and shroud on different terrains. The attribute '''''terrain''=''cost''''' means that the unit will need to use ''cost'' vision points to view into that ''terrain''. (If not specified for a particular terrain, the vision cost defaults to the movement cost.) | ||
+ | * {{anchor|jamming_costs|'''[jamming_costs]'''}}: {{DevFeature1.13|0}} describes how far the unit interferes with the vision of other units over different terrains. This works the same as movement and vision costs. [https://forums.wesnoth.org/viewtopic.php?f=21&t=44577&p=644985#p644985 Example of jamming] | ||
+ | * {{anchor|defense|'''[defense]'''}}: describes how likely the unit is to be hit on different terrains. The attribute '''''terrain''=''defense''''' means that the unit will be hit ''defense'' percent of the time in that ''terrain''. If the defense value is negative, then that specifies an upper limit. The number in absolute terms is then also the best defense that the unit may have if there is more than one terrain type involved. For example '''forest=-70''' common for mounted units means the unit cannot get more than 30% defense on forest terrain. Regardless what other terrain the forest is on. | ||
− | + | The available keys for the '''[movement_costs]''', '''[vision_costs]''', '''[jamming_costs]''' and '''[defense]''' tags are the '''id'''s of archetype terrains (those not aliased to any other terrain, see [[TerrainWML]]).<br> | |
+ | In mainline that encompasses deep_water, shallow_water, reef, swamp_water, flat, sand, forest, hills, mountains, village, castle, cave, frozen, unwalkable, fungus, and impassable. | ||
=== [race] === | === [race] === | ||
− | The [race] tag is used to make shortcuts to describe units with similar names. Units from the same advancement tree should generally have the same race. Also, units with the same race should generally be recruitable by the same sides/factions. | + | The '''[race]''' tag is used to make shortcuts to describe units with similar names. Units from the same advancement tree should generally have the same race. Also, units with the same race should generally be recruitable by the same sides/factions. 'id' and 'plural_name' and ('name' or ('male_name' and 'female_name')) '''must''' be supplied. |
* '''id''': ID for this race. Units with the attribute '''race=''id''''' will be assigned this race. In older versions of WML, the value of the name key was used as id if the id field was missing, but this is no longer the case. | * '''id''': ID for this race. Units with the attribute '''race=''id''''' will be assigned this race. In older versions of WML, the value of the name key was used as id if the id field was missing, but this is no longer the case. | ||
* '''plural_name''': user-visible name for its people (e.g. "Merfolk" or "Elves"). Currently only used in the in-game help. | * '''plural_name''': user-visible name for its people (e.g. "Merfolk" or "Elves"). Currently only used in the in-game help. | ||
* '''male_name''': user-visible name for the race of the male units (e.g. "Merman"). Currently only used in the in-game unit status. | * '''male_name''': user-visible name for the race of the male units (e.g. "Merman"). Currently only used in the in-game unit status. | ||
* '''female_name''': user-visible name for the race of the female units (e.g. "Mermaid"). Currently only used in the in-game unit status. | * '''female_name''': user-visible name for the race of the female units (e.g. "Mermaid"). Currently only used in the in-game unit status. | ||
− | * '''name''': the default value for the three keys above. The 'name' key is the default for 'male_name' and 'female_name'. ' | + | * '''name''': the default value for the three keys above. The 'name' key is the default for 'male_name' and 'female_name'. |
− | * ''' | + | * '''description''': text used in the in-game help. |
+ | * '''help_taxonomy''': {{DevFeature1.15|5}} in the help browser, show this race as a group of units from another race; the value of this attribute should be the other race's '''id''' attribute. This only affects the help browser, for all other purposes (such as WML filters) the two races are completely separate. (How this is visualised in the help browser is a GUI design decision, this attribute merely tells the engine that the relationship exists.) | ||
* '''name_generator''' {{DevFeature1.13|5}}: [[Context-free grammar]] describing unit names, if absent or invalid, falls back to male_names or female_names | * '''name_generator''' {{DevFeature1.13|5}}: [[Context-free grammar]] describing unit names, if absent or invalid, falls back to male_names or female_names | ||
* '''male_name_generator''' {{DevFeature1.13|5}}: Like name_generator, but specific for male names | * '''male_name_generator''' {{DevFeature1.13|5}}: Like name_generator, but specific for male names | ||
Line 60: | Line 70: | ||
=== [resistance_defaults] === | === [resistance_defaults] === | ||
− | + | Note: broken in 1.14.8, fixed in 1.14.16 and 1.15.9 ([https://github.com/wesnoth/wesnoth/issues/5308 issue #5308]) | |
− | The [resistance_defaults] tag allows you to add resistance for custom damage types to already-defined movetypes (such as core movetypes). | + | The '''[resistance_defaults]''' tag allows you to add resistance for custom damage types to already-defined movetypes (such as core movetypes). |
* '''id''': The damage type you want to apply resistance defaults for. | * '''id''': The damage type you want to apply resistance defaults for. | ||
− | * '''default''': The default resistance for all movetypes. You can set it to a number, or to a [[Wesnoth Formula Language|formula]] (enclosed in parentheses) which can reference any of the default resistance types - arcane, fire, etc. A common usage for formulas might be to set it to be equal to another resistance, eg '''default="(impact)"'''. | + | * '''default''': The default resistance for all movetypes. You can set it to a number, or to a [[Wesnoth Formula Language|formula]] (enclosed in parentheses, but with no preceding dollar sign <code>$</code>) which can reference any of the default resistance types - arcane, fire, etc. A common usage for formulas might be to set it to be equal to another resistance, eg '''default="(impact)"'''. |
− | * Other keys reference the '''name=''' attribute of a defined movetype. For example, 'smallfoot=50' will set the resistance to 50 for the smallfoot movement type. ''Note:'' The '''default=''' key and other keys are handled slightly differently. A '''default=''' value will never override an explicitly specified value either in the same [resistance_defaults] tag or in a [movetype] definition, but other keys always take priority over values specified in a [movetype] definition. | + | * Other keys reference the '''name=''' attribute of a defined movetype. For example, 'smallfoot=50' will set the resistance to 50 for the smallfoot movement type. Formulas can also be used here, for example 'smallfoot=(impact)'. |
+ | |||
+ | ''Note:'' The '''default=''' key and other keys are handled slightly differently. A '''default=''' value will never override an explicitly specified value either in the same '''[resistance_defaults]''' tag or in a '''[movetype]''' definition, but other keys always take priority over values specified in a '''[movetype]''' definition. | ||
+ | |||
+ | {{DevFeature1.15|9}} The formulas can now access other parts of the movetype, for example "(resistance.arcane)" or "(movement_costs.flat)". For [resistance_defaults], "(arcane)" is shorthand for, and equivalent to, "(resistance.arcane)". See the documentation in the [terrain_defaults] section for more details about this. | ||
=== [terrain_defaults] === | === [terrain_defaults] === | ||
− | + | Note: broken in 1.14.8, fixed in 1.14.16 and 1.15.11 ([https://github.com/wesnoth/wesnoth/issues/5308 issue #5308]) | |
− | The [terrain_defaults] tag allows you to add costs and defenses for custom terrain types to already-defined movetypes (such as core movetypes). | + | The '''[terrain_defaults]''' tag allows you to add costs and defenses for custom terrain types to already-defined movetypes (such as core movetypes). |
* '''id''': The '''id=''' attribute of the terrain type you want to apply cost and defense defaults for. | * '''id''': The '''id=''' attribute of the terrain type you want to apply cost and defense defaults for. | ||
− | * '''[movement]''', '''[defense]''', '''[ | + | * Subtags are used to specify the values using the same syntax as [resistance_defaults] - an optional default key, and subsequent keys which are movetype names. As with [resistance_defaults], you can use [[Wesnoth Formula Language|formulas]] if you enclose them in parentheses (but with no preceding dollar sign <code>$</code>). |
+ | * Short names for the subtags are '''[movement]''', '''[jamming]''', '''[vision]''', and '''[defense]'''. | ||
+ | * Long names for the subtags are '''[movement_costs]''', '''[vision_costs]''', '''[jamming_costs]''', and '''[defense]'''. | ||
+ | |||
+ | 1.14.16 and 1.15.11 recognise both the short and long names above. 1.15.9 and 1.15.10 only recognised the long names, and all other prior versions only recognised the short names. | ||
+ | |||
+ | {{DevFeature1.14|16}} {{DevFeature1.15|9}} The formulas can now access other parts of the movetype, for example '''(resistance.arcane)''' or '''(movement_costs.swamp_water)'''. Simply using '''(swamp_water)''' is shorthand for the value in whichever subtag is being patched. Formulas only recognise the long names. | ||
+ | |||
+ | The '''[terrain_defaults]''' tags are processed before any calculations of mixed terrains happen, and can only access the values for the basic terrain types. It's not useful to set a value for a mixed terrain type, as the calculations of mixed terrains' values decompose the mixed terrain to its base terrains before calculating the result, thus ignoring any patched values for mixed terrains. | ||
+ | |||
+ | Setting a '''default=''' value for '''[vision_costs]''' or '''[jamming_costs]''' means that that value will be used instead of falling back to using the movement_costs for calculating vision. For this reason, it's likely that '''default=''' should only be used when patching the '''[movement_costs]''' and '''[defense]''', not for vision or jamming. | ||
+ | |||
+ | A formula may use data added in a previous '''[terrain_defaults]'''. However, relying on data in the same '''[terrain_defaults]''' that creates or changes it is unsupported, because no guarantee is made of the order in which the subtags are processed. | ||
+ | |||
+ | While '''[terrain_defaults]''' formulas can use resistances, and '''[resistance_defaults]''' formulas can use movement costs, no guarantee is made of whether '''[terrain_defaults]''' tags will be processed before or after '''[resistance_defaults]''' tags. Therefore, formulas should only use base terrains and not rely on data added by the other kind of movetype-patching tag. | ||
=== [hide_help] === | === [hide_help] === | ||
− | The [hide_help] tag allows you to hide some units from the help. Mainly useful if you can't change these units (e.g. mainline units) and thus can't add a 'hide_help=yes' key to them. Only really useful for campaigns, not for eras. The following keys and their contents uses an 'OR' logic between them. | + | The '''[hide_help]''' tag allows you to hide some units from the help. Mainly useful if you can't change these units (e.g. mainline units) and thus can't add a 'hide_help=yes' key to them. Only really useful for campaigns, not for eras. The following keys and their contents uses an 'OR' logic between them. |
* '''type''': list of unit types. | * '''type''': list of unit types. | ||
* '''race''': list of races. Equivalent to all unit types of these races. | * '''race''': list of races. Equivalent to all unit types of these races. | ||
Line 83: | Line 111: | ||
* '''all''': 'yes' or 'no' (default). 'yes' is equivalent to all unit types (useful before [not]) | * '''all''': 'yes' or 'no' (default). 'yes' is equivalent to all unit types (useful before [not]) | ||
* '''[not]''': all the previous keys (except 'all') can also be used in [not] sub-tags. And you can use [not] recursively. For example, if you want to only show the Yeti and the human race except the mage tree, use: | * '''[not]''': all the previous keys (except 'all') can also be used in [not] sub-tags. And you can use [not] recursively. For example, if you want to only show the Yeti and the human race except the mage tree, use: | ||
− | + | <syntaxhighlight lang=wml> | |
− | + | [hide_help] | |
− | + | all=yes | |
− | + | [not] | |
− | + | type=Yeti | |
− | + | race=human | |
− | + | [not] | |
− | + | type_adv_tree=Mage | |
− | + | [/not] | |
− | + | [/not] | |
+ | [/hide_help] | ||
+ | </syntaxhighlight> | ||
== See Also == | == See Also == |
Latest revision as of 11:58, 18 September 2024
The [units] tag is a top-level WML tag which defines the unit types that will be available in the game.
A [units] tag primarily contains [unit_type] tags, each of which defines one unit type, and can also contain other tags, which mostly provide definitions of things like races and movement types that are used in unit type definitions.
Contents
Subtags of [units]
The following tags can be used as subtags of a [units] tag.
[unit_type]
In a [units] tag, a [unit_type] tag defines a unit type.
[trait]
The [trait] tag describes a trait. When it appears in the [units] toplevel, it describes a global trait, and all races with the attribute ignore_global_traits=no will have this trait.; it may also appear in other places.
- id: unique identifier; needed for random trait generation to work properly
- availability: describes whether a trait is "musthave" for a race/unit type or is available to "any" unit, including leaders. The default is for a trait to only be available to nonleaders. Currently "any" should not be used for traits available in multiplayer. It can be used for campaign specific traits.
- male_name: text displayed in the status of unit with the trait if the unit is male.
- female_name: text displayed in the status of unit with the trait if the unit is female.
- name: text displayed in the status of unit with the trait if none of the two above is used.
- description: text displayed for the description of the trait when moving the cursor over the trait.
- help_text: (Version 1.13.6 and later only) text displayed for the description of the trait in the help. Defaults to description if not specified.
- [effect]: described in EffectWML. More than one of these can be used.
- require_traits: (Version 1.17.13 and later only) An optional comma-separated list of trait id keys that represent traits that are required by this one. Order is not important. If the unit not already has all of the traits that appear in this list, then this trait will not be generated for this unit.
- exclude_traits: (Version 1.17.13 and later only) An optional comma-separated list of trait id keys that represent traits that are mutually exclusive to this one. Order is not important. If the unit already has any of the traits that appear once in this list, then this trait will not be generated for this unit. Of course, for this to really make two traits mutually exclusive, you need to add exclude_traits to both trait definitions.
[movetype]
The [movetype] tag is used to make shortcuts to describe units with similar terrain handicaps. Units from the same advancement tree should generally have the same movetype.
- name: an ID for this movetype. Units with the attribute movement_type=name will be assigned this movetype.
- flies or (Version 1.15.0 and later only) flying: either 'yes' or 'no' (default). A unit with flying=yes does not have its image's height adjusted for different terrains.
- This key corresponds to [unit]'s flying key.
- In Wesnoth 1.12 and 1.14, the value of flying sometimes overrides the value of flies, but in other times flying is ignored
- (Version 1.15.0 and later only) flying always overrides the flies value, with the intention that flies will be deprecated.
- [special_note] (Version 1.15.14 and later only) note=Translatable string, which can be set if there’s something special about this movetype. It will be displayed in the unit's help page. For typical movetypes this is not set. An example are horses with the mounted movetype. See also UnitTypeWML#Special_Notes.
- [resistance]: describes how much damage the unit takes from different types of attacks. The attribute type=resistance makes the unit receive resistance percent of damage, or resist 100-resistance percent of damage from attacks with type=type. So for example, a resistance of fire=110 means, this unit will receive 110% of damage, or have a resistance of -10% as displayed in-game. A value of fire=0 would mean, the unit receives no damage and therefore has a resistance of 100%.
The available attack types in mainline are blade, pierce, impact, fire, cold, and arcane. - [movement_costs]: describes how fast the unit moves on different terrains. The attribute terrain=cost means that the unit will need to use cost move points to move onto that terrain.
- [vision_costs]: describes how far the unit clears fog and shroud on different terrains. The attribute terrain=cost means that the unit will need to use cost vision points to view into that terrain. (If not specified for a particular terrain, the vision cost defaults to the movement cost.)
- [jamming_costs]: (Version 1.13.0 and later only) describes how far the unit interferes with the vision of other units over different terrains. This works the same as movement and vision costs. Example of jamming
- [defense]: describes how likely the unit is to be hit on different terrains. The attribute terrain=defense means that the unit will be hit defense percent of the time in that terrain. If the defense value is negative, then that specifies an upper limit. The number in absolute terms is then also the best defense that the unit may have if there is more than one terrain type involved. For example forest=-70 common for mounted units means the unit cannot get more than 30% defense on forest terrain. Regardless what other terrain the forest is on.
The available keys for the [movement_costs], [vision_costs], [jamming_costs] and [defense] tags are the ids of archetype terrains (those not aliased to any other terrain, see TerrainWML).
In mainline that encompasses deep_water, shallow_water, reef, swamp_water, flat, sand, forest, hills, mountains, village, castle, cave, frozen, unwalkable, fungus, and impassable.
[race]
The [race] tag is used to make shortcuts to describe units with similar names. Units from the same advancement tree should generally have the same race. Also, units with the same race should generally be recruitable by the same sides/factions. 'id' and 'plural_name' and ('name' or ('male_name' and 'female_name')) must be supplied.
- id: ID for this race. Units with the attribute race=id will be assigned this race. In older versions of WML, the value of the name key was used as id if the id field was missing, but this is no longer the case.
- plural_name: user-visible name for its people (e.g. "Merfolk" or "Elves"). Currently only used in the in-game help.
- male_name: user-visible name for the race of the male units (e.g. "Merman"). Currently only used in the in-game unit status.
- female_name: user-visible name for the race of the female units (e.g. "Mermaid"). Currently only used in the in-game unit status.
- name: the default value for the three keys above. The 'name' key is the default for 'male_name' and 'female_name'.
- description: text used in the in-game help.
- help_taxonomy: (Version 1.15.5 and later only) in the help browser, show this race as a group of units from another race; the value of this attribute should be the other race's id attribute. This only affects the help browser, for all other purposes (such as WML filters) the two races are completely separate. (How this is visualised in the help browser is a GUI design decision, this attribute merely tells the engine that the relationship exists.)
- name_generator (Version 1.13.5 and later only): Context-free grammar describing unit names, if absent or invalid, falls back to male_names or female_names
- male_name_generator (Version 1.13.5 and later only): Like name_generator, but specific for male names
- female_name_generator (Version 1.13.5 and later only): Like name_generator, but specific for female names
- male_names, female_names: lists of names (i.e. non-translatable strings). They are inputted into the Markov name generator to generate random names. male_names describes units with gender=male; female_names describes units with gender=female.
- markov_chain_size: (default 2) number of letters per "syllable". "Syllables" are groupings of names that the Markov name generator uses to determine names. It does this by running a probability algorithm to guess from the name list which syllables fit well together, which can start or end a name, etc.
- num_traits: is the number of non-repeating traits each unit of this race can be assigned.
- ignore_global_traits: 'yes' or 'no' (default). Determines whether global traits (see [traits] above) are applied.
- undead_variation: sets the default undead variation for members of this race.
- [topic]: describes extra help topics for this race.
- [trait]: describes a trait for this race. See above for syntax.
[resistance_defaults]
Note: broken in 1.14.8, fixed in 1.14.16 and 1.15.9 (issue #5308)
The [resistance_defaults] tag allows you to add resistance for custom damage types to already-defined movetypes (such as core movetypes).
- id: The damage type you want to apply resistance defaults for.
- default: The default resistance for all movetypes. You can set it to a number, or to a formula (enclosed in parentheses, but with no preceding dollar sign
$
) which can reference any of the default resistance types - arcane, fire, etc. A common usage for formulas might be to set it to be equal to another resistance, eg default="(impact)". - Other keys reference the name= attribute of a defined movetype. For example, 'smallfoot=50' will set the resistance to 50 for the smallfoot movement type. Formulas can also be used here, for example 'smallfoot=(impact)'.
Note: The default= key and other keys are handled slightly differently. A default= value will never override an explicitly specified value either in the same [resistance_defaults] tag or in a [movetype] definition, but other keys always take priority over values specified in a [movetype] definition.
(Version 1.15.9 and later only) The formulas can now access other parts of the movetype, for example "(resistance.arcane)" or "(movement_costs.flat)". For [resistance_defaults], "(arcane)" is shorthand for, and equivalent to, "(resistance.arcane)". See the documentation in the [terrain_defaults] section for more details about this.
[terrain_defaults]
Note: broken in 1.14.8, fixed in 1.14.16 and 1.15.11 (issue #5308)
The [terrain_defaults] tag allows you to add costs and defenses for custom terrain types to already-defined movetypes (such as core movetypes).
- id: The id= attribute of the terrain type you want to apply cost and defense defaults for.
- Subtags are used to specify the values using the same syntax as [resistance_defaults] - an optional default key, and subsequent keys which are movetype names. As with [resistance_defaults], you can use formulas if you enclose them in parentheses (but with no preceding dollar sign
$
). - Short names for the subtags are [movement], [jamming], [vision], and [defense].
- Long names for the subtags are [movement_costs], [vision_costs], [jamming_costs], and [defense].
1.14.16 and 1.15.11 recognise both the short and long names above. 1.15.9 and 1.15.10 only recognised the long names, and all other prior versions only recognised the short names.
(Version 1.14.16 and later only) (Version 1.15.9 and later only) The formulas can now access other parts of the movetype, for example (resistance.arcane) or (movement_costs.swamp_water). Simply using (swamp_water) is shorthand for the value in whichever subtag is being patched. Formulas only recognise the long names.
The [terrain_defaults] tags are processed before any calculations of mixed terrains happen, and can only access the values for the basic terrain types. It's not useful to set a value for a mixed terrain type, as the calculations of mixed terrains' values decompose the mixed terrain to its base terrains before calculating the result, thus ignoring any patched values for mixed terrains.
Setting a default= value for [vision_costs] or [jamming_costs] means that that value will be used instead of falling back to using the movement_costs for calculating vision. For this reason, it's likely that default= should only be used when patching the [movement_costs] and [defense], not for vision or jamming.
A formula may use data added in a previous [terrain_defaults]. However, relying on data in the same [terrain_defaults] that creates or changes it is unsupported, because no guarantee is made of the order in which the subtags are processed.
While [terrain_defaults] formulas can use resistances, and [resistance_defaults] formulas can use movement costs, no guarantee is made of whether [terrain_defaults] tags will be processed before or after [resistance_defaults] tags. Therefore, formulas should only use base terrains and not rely on data added by the other kind of movetype-patching tag.
[hide_help]
The [hide_help] tag allows you to hide some units from the help. Mainly useful if you can't change these units (e.g. mainline units) and thus can't add a 'hide_help=yes' key to them. Only really useful for campaigns, not for eras. The following keys and their contents uses an 'OR' logic between them.
- type: list of unit types.
- race: list of races. Equivalent to all unit types of these races.
- type_adv_tree: list of unit types. Equivalent to all these types and their advancement trees.
- all: 'yes' or 'no' (default). 'yes' is equivalent to all unit types (useful before [not])
- [not]: all the previous keys (except 'all') can also be used in [not] sub-tags. And you can use [not] recursively. For example, if you want to only show the Yeti and the human race except the mage tree, use:
[hide_help]
all=yes
[not]
type=Yeti
race=human
[not]
type_adv_tree=Mage
[/not]
[/not]
[/hide_help]