The Battle for Wesnoth Wiki - User contributions [en]

GermanTranslationErrors

2026-01-01T01:14:56Z

Spixi: /* Karten-/Szenarioeditor */ Wieder rausgenommen, die Wiki-Seite scheint inaktiv zu sein, habe es auf dem Discord gepostet

Hier bitte die in der Übersetzung gefundenen Fehler eintragen.

== Generelles ==

Hinweis v. Espreon: Die Fertigkeit "feeding" ist im Deutschen - sehr spezifisch - als "Kanibalismus" übersetzt. Dies sei aber vielleicht zu spezifisch, und "fressen" sei generischer
IRC: "And since ability names can pretty much go anywhere thanks to UMC,they ought to have names that are generic as possible"

-------------------------
Wesnoth 1.10.0

:Ist es so richtig, dass auf der Landkarte von Wesnoth (die im Hauptmenü) das eine Gebirge "Erzgebierge" heißt? Müsste es nicht "Erzgebirge" heißen? Gruß Michieru

:[Anmerkung: die "Heart Mountain" wurden im Deutschen zum Erzgebirge, da "Herzgebirge" sich in der Ork-Kampagne irgendwie nicht richtig angefühlt hatte. Änderungen sind natürlich, nach IRC-Diskussion, wie immer, möglich. Crommy, 22.06.2014]

: Übrigens liest sich "Schwarzwasser Hafen" ein bisschen merkwürdig. Das klingt IMO so, als hätte es mal einen König "Schwarzwas" gegeben, der dort einen Hafen errichtet hat. Die Betonung liegt bei dieser Schreibweise auf "Haf-".

: Wenn man "Schwarzwasserhafen" ohne Leerzeichen schreiben würde, dann liegt die Betonung auf "Schwarz-". Dies ist sowohl einfacher zu lesen, als auch grammatikalisch korrekter.
: --[[User:Spixi|Spixi]] 21:07, 30 March 2012 (UTC)

== Benutzeroberfläche ==

=== Hauptmenü und Unterfenster ===

=== Im Spiel ===

=== Karten-/Szenarioeditor ===

== Hilfe ==

Das Terrain "Tropischer Meeresabgrund" klingt gut, wird aber sicher nicht nur für Meere benutzt.

Das Terrain "Dry Mountains" war früher als "Wüstengebirge" übersetzt, nun wurde mit 1.14 ein richtiges Wüstengebirge eingeführt - vll findet jmd einen passenderen Namen für das alte Terrain, was dem normalen Gebirge auch sehr ähnlich sieht.

== Einheitenbeschreibungen ==

Die Dunevolk Einheiten benötigen ein neues Namenskonzept.

Soll in viele Platz der Saurianen Einheiten "-in" oder "-innen" gestellt werden, weil die ausschließlich Weiblich sind? "Kulturell gibt es klare Aufteilung der Geschlechterrolle. ... Die Jagd und Nahrungsbeschaffung ist die Aufgabe der Weibchen, die dabei erlernten Fähigkeiten eignen sich auch im Kampf – sie sind die von anderen Völkern so gefürchteten Plänkler, Hinterlistlinge oder Flänkler."

== Mehrspieler ==

== Einführung ==

== Kampagnen ==

=== Das Zepter des Feuers ===

=== Die dunklen Künste ===

=== Die Geschichte zweier Brüder ===

=== Die Südwacht ===

=== Der Thronerbe ===
Es wird nicht korrekt geihrzt bei Gesprächen mit der Prinzessin.

=== Der Aufstieg Wesnoths ===
Die Level 2 und 3 Version der Verbannten des Wesfolks heißen beide "Wesfolk Adlige".

=== Die Legende von Wesmere ===

=== Freiheit ===

=== Invasion der Finsternis ===

=== Schwarzauges Sohn ===

=== Unter brennenden Sonnen ===

=== Wiedergeburt des Nordens ===

=== Der Hammer von Thursagan ===
Beim Ihrzen werden die Wörter fälschlicherweise klein geschrieben.
Korrigiert bis zu dem Scenario mit den Draken und Magiern.

=== Delfadors Memoiren ===

=== Stille Wasser ===

=== Steigt hinab in die Dunkelheit ===

=== Geheimnisse der Ahnen ===

Bei Nachrichten die direkt an den Spieler (anstatt an Charaktere) sollte wie im restlichen Spiel der Spieler geihrzt anstatt geduzt werden.

== Manpages ==

== Siehe auch ==

* [[GermanTranslation|Hauptseite für deutsche Übersetzung]]

[[Category:Translations]]

GermanTranslationErrors

2026-01-01T01:07:08Z

Spixi: /* Karten-/Szenarioeditor */

Hier bitte die in der Übersetzung gefundenen Fehler eintragen.

== Generelles ==

Hinweis v. Espreon: Die Fertigkeit "feeding" ist im Deutschen - sehr spezifisch - als "Kanibalismus" übersetzt. Dies sei aber vielleicht zu spezifisch, und "fressen" sei generischer
IRC: "And since ability names can pretty much go anywhere thanks to UMC,they ought to have names that are generic as possible"

-------------------------
Wesnoth 1.10.0

:Ist es so richtig, dass auf der Landkarte von Wesnoth (die im Hauptmenü) das eine Gebirge "Erzgebierge" heißt? Müsste es nicht "Erzgebirge" heißen? Gruß Michieru

:[Anmerkung: die "Heart Mountain" wurden im Deutschen zum Erzgebirge, da "Herzgebirge" sich in der Ork-Kampagne irgendwie nicht richtig angefühlt hatte. Änderungen sind natürlich, nach IRC-Diskussion, wie immer, möglich. Crommy, 22.06.2014]

: Übrigens liest sich "Schwarzwasser Hafen" ein bisschen merkwürdig. Das klingt IMO so, als hätte es mal einen König "Schwarzwas" gegeben, der dort einen Hafen errichtet hat. Die Betonung liegt bei dieser Schreibweise auf "Haf-".

: Wenn man "Schwarzwasserhafen" ohne Leerzeichen schreiben würde, dann liegt die Betonung auf "Schwarz-". Dies ist sowohl einfacher zu lesen, als auch grammatikalisch korrekter.
: --[[User:Spixi|Spixi]] 21:07, 30 March 2012 (UTC)

== Benutzeroberfläche ==

=== Hauptmenü und Unterfenster ===

=== Im Spiel ===

=== Karten-/Szenarioeditor ===
wesnoth-lib
msgid "Royal Rug"
msgstr "Königklicher Teppich" -> "Königlicher Teppich"

== Hilfe ==

Das Terrain "Tropischer Meeresabgrund" klingt gut, wird aber sicher nicht nur für Meere benutzt.

Das Terrain "Dry Mountains" war früher als "Wüstengebirge" übersetzt, nun wurde mit 1.14 ein richtiges Wüstengebirge eingeführt - vll findet jmd einen passenderen Namen für das alte Terrain, was dem normalen Gebirge auch sehr ähnlich sieht.

== Einheitenbeschreibungen ==

Die Dunevolk Einheiten benötigen ein neues Namenskonzept.

Soll in viele Platz der Saurianen Einheiten "-in" oder "-innen" gestellt werden, weil die ausschließlich Weiblich sind? "Kulturell gibt es klare Aufteilung der Geschlechterrolle. ... Die Jagd und Nahrungsbeschaffung ist die Aufgabe der Weibchen, die dabei erlernten Fähigkeiten eignen sich auch im Kampf – sie sind die von anderen Völkern so gefürchteten Plänkler, Hinterlistlinge oder Flänkler."

== Mehrspieler ==

== Einführung ==

== Kampagnen ==

=== Das Zepter des Feuers ===

=== Die dunklen Künste ===

=== Die Geschichte zweier Brüder ===

=== Die Südwacht ===

=== Der Thronerbe ===
Es wird nicht korrekt geihrzt bei Gesprächen mit der Prinzessin.

=== Der Aufstieg Wesnoths ===
Die Level 2 und 3 Version der Verbannten des Wesfolks heißen beide "Wesfolk Adlige".

=== Die Legende von Wesmere ===

=== Freiheit ===

=== Invasion der Finsternis ===

=== Schwarzauges Sohn ===

=== Unter brennenden Sonnen ===

=== Wiedergeburt des Nordens ===

=== Der Hammer von Thursagan ===
Beim Ihrzen werden die Wörter fälschlicherweise klein geschrieben.
Korrigiert bis zu dem Scenario mit den Draken und Magiern.

=== Delfadors Memoiren ===

=== Stille Wasser ===

=== Steigt hinab in die Dunkelheit ===

=== Geheimnisse der Ahnen ===

Bei Nachrichten die direkt an den Spieler (anstatt an Charaktere) sollte wie im restlichen Spiel der Spieler geihrzt anstatt geduzt werden.

== Manpages ==

== Siehe auch ==

* [[GermanTranslation|Hauptseite für deutsche Übersetzung]]

[[Category:Translations]]

GermanTranslationErrors

2026-01-01T01:06:30Z

Spixi: /* Karten-/Szenarioeditor */

Hier bitte die in der Übersetzung gefundenen Fehler eintragen.

== Generelles ==

Hinweis v. Espreon: Die Fertigkeit "feeding" ist im Deutschen - sehr spezifisch - als "Kanibalismus" übersetzt. Dies sei aber vielleicht zu spezifisch, und "fressen" sei generischer
IRC: "And since ability names can pretty much go anywhere thanks to UMC,they ought to have names that are generic as possible"

-------------------------
Wesnoth 1.10.0

:Ist es so richtig, dass auf der Landkarte von Wesnoth (die im Hauptmenü) das eine Gebirge "Erzgebierge" heißt? Müsste es nicht "Erzgebirge" heißen? Gruß Michieru

:[Anmerkung: die "Heart Mountain" wurden im Deutschen zum Erzgebirge, da "Herzgebirge" sich in der Ork-Kampagne irgendwie nicht richtig angefühlt hatte. Änderungen sind natürlich, nach IRC-Diskussion, wie immer, möglich. Crommy, 22.06.2014]

: Übrigens liest sich "Schwarzwasser Hafen" ein bisschen merkwürdig. Das klingt IMO so, als hätte es mal einen König "Schwarzwas" gegeben, der dort einen Hafen errichtet hat. Die Betonung liegt bei dieser Schreibweise auf "Haf-".

: Wenn man "Schwarzwasserhafen" ohne Leerzeichen schreiben würde, dann liegt die Betonung auf "Schwarz-". Dies ist sowohl einfacher zu lesen, als auch grammatikalisch korrekter.
: --[[User:Spixi|Spixi]] 21:07, 30 March 2012 (UTC)

== Benutzeroberfläche ==

=== Hauptmenü und Unterfenster ===

=== Im Spiel ===

=== Karten-/Szenarioeditor ===
wesnoth-lib
msgid "Royal Rug"
msgstr "Königklicher Teppich" -> "Königlicher Teppich"

== Hilfe ==

Das Terrain "Tropischer Meeresabgrund" klingt gut, wird aber sicher nicht nur für Meere benutzt.

Das Terrain "Dry Mountains" war früher als "Wüstengebirge" übersetzt, nun wurde mit 1.14 ein richtiges Wüstengebirge eingeführt - vll findet jmd einen passenderen Namen für das alte Terrain, was dem normalen Gebirge auch sehr ähnlich sieht.

== Einheitenbeschreibungen ==

Die Dunevolk Einheiten benötigen ein neues Namenskonzept.

Soll in viele Platz der Saurianen Einheiten "-in" oder "-innen" gestellt werden, weil die ausschließlich Weiblich sind? "Kulturell gibt es klare Aufteilung der Geschlechterrolle. ... Die Jagd und Nahrungsbeschaffung ist die Aufgabe der Weibchen, die dabei erlernten Fähigkeiten eignen sich auch im Kampf – sie sind die von anderen Völkern so gefürchteten Plänkler, Hinterlistlinge oder Flänkler."

== Mehrspieler ==

== Einführung ==

== Kampagnen ==

=== Das Zepter des Feuers ===

=== Die dunklen Künste ===

=== Die Geschichte zweier Brüder ===

=== Die Südwacht ===

=== Der Thronerbe ===
Es wird nicht korrekt geihrzt bei Gesprächen mit der Prinzessin.

=== Der Aufstieg Wesnoths ===
Die Level 2 und 3 Version der Verbannten des Wesfolks heißen beide "Wesfolk Adlige".

=== Die Legende von Wesmere ===

=== Freiheit ===

=== Invasion der Finsternis ===

=== Schwarzauges Sohn ===

=== Unter brennenden Sonnen ===

=== Wiedergeburt des Nordens ===

=== Der Hammer von Thursagan ===
Beim Ihrzen werden die Wörter fälschlicherweise klein geschrieben.
Korrigiert bis zu dem Scenario mit den Draken und Magiern.

=== Delfadors Memoiren ===

=== Stille Wasser ===

=== Steigt hinab in die Dunkelheit ===

=== Geheimnisse der Ahnen ===

Bei Nachrichten die direkt an den Spieler (anstatt an Charaktere) sollte wie im restlichen Spiel der Spieler geihrzt anstatt geduzt werden.

== Manpages ==

== Siehe auch ==

* [[GermanTranslation|Hauptseite für deutsche Übersetzung]]

[[Category:Translations]]

InterfaceActionsWML

2024-05-29T14:09:41Z

Spixi: revert last change, but clarified the default value

{{WML Tags}}
== Interface actions ==

Part of [[ActionWML]], interface actions are actions that do not have a direct effect on gameplay;
instead, they show something to the player. The main interface tags
are '''[message]''' and '''[objectives]''', but several other tags affect
the interface also.

== [inspect] ==
This user interface instantly displays the gamestate inspector dialog at the current scenario state (the same one that can be brought up with [[CommandMode|the ''':inspect''' command]]), which can be used to inspect the values of WML variables, AI configuration, recall lists, and more.

* '''name''': optional attribute to specify the name of this gamestate inspector dialog. It is just a label to help differentiate between different invocations of gamestate inspector dialog.

== [message] ==
The most commonly used interface action is [message], which displays a message to the user in a dialog box. It can also be used to take input from the user.

The following key/tags are accepted for [message]:
* [[StandardUnitFilter]]: The unit whose profile and name are displayed. Do not use a [filter] tag. If no unit matching this filter is found, the message is not displayed (The unit has probably been killed).<br>[message] elements should be constructed so that it is either guaranteed that a certain unit is alive, or so that dialog flows smoothly even if the message isn't displayed.

* '''speaker''': an alternative to standard unit filter. You may specify as the value of the speaker attribute a unit id or any of the following special values:
** '''narrator''': the dialog box is displayed without a caption for the unit speaking or a unit image
** '''unit''': the primary unit for the event is speaking
** '''second_unit''': the secondary unit for the event is speaking

* '''message''': (translatable) the text to display to the right of the image. ''message'' is sometimes multiple lines; if it is, be sure to use quotes(''' ' ''' or ''' " ''')
* '''male_message''', '''female_message''': {{DevFeature1.13|2}} (translatable) Used instead of ''message'' if the unit's gender matches. Never used if there is no unit (ie ''speaker=narrator''). {{DevFeature1.13|6}} This matches the primary unit, not the secondary unit.
* '''wait_description''': {{DevFeature1.13|2}} the description of this message displayed when other players in a mp game wait for one player doing input in a [message] (with [option]s or [text_input]).
* '''[show_if]''': if present then this message will only be displayed if the conditional statement in this tag is passed (see [[ConditionalActionsWML#Condition_Tags|ConditionalActionsWML]])
* '''side_for''': (default: all sides) comma-separated list of sides for who message is shown. This will <b>not</b> work with messages that take user input ([option]/[text_input]), which can only ever be shown to the current player. {{DevFeature1.13|0}} side_for= is now also accepted for messages with user input, it specifies on which side the message is shown (defaults to the currently playing side). For messages with input it does not accept a comma seperated list only a single number.
* '''image''': (default: profile image of speaker) the image to display to the left of the message text. Append ~RIGHT() if you want the image to appear on the right side.
** {{DevFeature1.13|0}} <b>none:</b> display no image
* '''mirror''': {{DevFeature1.13|5}}whether to mirror the image specified by the '''image''' attribute.
* '''second_image''': {{DevFeature1.13|6}}same as the '''image''' attribute, but the image is displayed on the right of the message text.
* '''second_mirror''': {{DevFeature1.13|6}}same as '''mirror''', but for the '''second_image''' attribute.
* '''image_pos''': {{DevFeature1.13|5}} whether to show the image on the left or right; supercedes the use of ~RIGHT() described above
* '''caption''': (default: name of speaker) the caption to display beside the image. Name to be displayed. Note: use a translation mark to avoid wmllint errors.
* '''scroll''': Boolean specifying whether the game view should scroll to the speaking unit. Defaults to ''yes''.
* '''highlight''': {{DevFeature1.13|5}} Boolean specifying whether to highlight the speaker. Defaults to ''yes''.
* '''sound''': a sound effect (wav file) to play as the message is displayed. This can be a comma-separated list, from which one will be randomly chosen.
* '''voice''', '''male_voice''', '''female_voice''': {{DevFeature1.13|?}} a sound to be played as the message is displayed. This can also be a comma-separated list, from which one will be randomly chosen. This is intended for voiceovers for the message. The gendered forms are applied the same as for '''message'''. They are never used when the speaker is the narrator - only '''voice''' is used in that case.
* {{anchor|message-option|'''[option]'''}}: No '''[option]''' elements have to be used. If '''[option]''' elements are present, then each option will be displayed in a menu for the user to select one option. ''Note: Messages with options will not be shown at all in prestart events''
** '''message''': (translatable) the text displayed for the option. {{DevFeature1.15|1}} This is now a synonym for '''description='''.
** '''image''', '''label''', '''description''', '''default''': See [[DescriptionWML#WML_Format|DescriptionWML]].
** '''value''': {{DevFeature1.13|?}} Gives the option a value to be stored in a variable.
** '''[show_if]''': if present then this option will only be displayed if the conditional statement in this tag is passed (see [[ConditionalActionsWML#Condition_Tags|ConditionalActionsWML]])
** '''[command]''': an element containing actions which are executed if the option is selected.
* '''variable''': {{DevFeature1.13|?}} If present, either the index or the value of the chosen option will be stored in the specified variable. Option indexing starts from 1. If option has '''[show_if]''' condition evaluated as false, then it is hidden and excluded from the indexing.
* {{anchor|message-text_input|'''[text_input]'''}}: there can be only one [text_input] tag. this adds a text input field to the message. ''Note: Messages with text_input will not be shown at all in prestart events''
** '''variable''': the variable that the user's input will be written to
** '''label''': a text label to the left of the input field
** '''max_length''': the maximum number of characters that may be typed into the field
** '''text''': text that is written into the field in the beginning
* Check [[EventWML#Multiplayer_safety]] to find out in which events you can safely use '''[option]''' and '''[text_input]''' without causing OOS.

=== Formatting ===
'''[message]''' and other tags such as unit names (user_description), objectives, and floating text can make use of [https://docs.gtk.org/Pango/pango_markup.html#pango-markup Pango markup formatting codes].

Prefer to use single quotes (') instead of double quotes (") within the formatting string, as double quotes would need to be escaped in WML (""). Escaping markup can be done with [https://github.com/wesnoth/wesnoth/blob/9daa10a9f27c5a95520e871417bbd72aa52aa688/src/font/pango/escape.hpp#L38-L42 HTML entities].

For example, if you wanted to write "You are victorious!" in large, italic, gold letters, you might write it this way:

<nowiki><span color='#BCB088' size='large' font-style='italic'>You are victorious!</span></nowiki>

These are the codes taken from the Pango markup formatting guide:

*'''font''', '''font_desc''': A font description string, such as "Sans Italic 12".
*'''font_family''', '''face''': A font family name.
*'''font_size''', '''size''': Font size in 1024ths of a point, or one of the absolute sizes 'xx-small', 'x-small', 'small', 'medium', 'large', 'x-large', 'xx-large', or one of the relative sizes 'smaller' or 'larger'.
*'''font_style''', '''style''': One of 'normal', 'oblique', 'italic'.
*'''font_weight''', '''weight''': One of 'ultralight', 'light', 'normal', 'bold', 'ultrabold', 'heavy', or a numeric weight.
*'''font_variant''', '''variant''': One of 'normal' or 'smallcaps'.
*'''font_stretch''', '''stretch''': One of 'ultracondensed', 'extracondensed', 'condensed', 'semicondensed', 'normal', 'semiexpanded', 'expanded', 'extraexpanded', 'ultraexpanded'.
*'''foreground''', '''fgcolor''', '''color''': An RGB color specification such as '#00FF00' or a color name such as 'red'. The full list of color names may be found in Pango's [https://github.com/GNOME/pango/blob/main/tools/rgb.txt rgb.txt] file.
*'''background, bgcolor''': An RGB color specification such as '#00FF00' or a color name such as 'red'.
*'''underline''': One of 'none', 'single', 'double', 'low', 'error'.
*'''underline_color''': The color of underlines; an RGB color specification such as '#00FF00' or a color name such as 'red'.
*'''rise''': Vertical displacement, in 10000ths of an em. Can be negative for subscript, positive for superscript.
*'''strikethrough''': 'true' or 'false' whether to strike through the text.
*'''strikethrough_color''': The color of strikethrough lines; an RGB color specification such as '#00FF00' or a color name such as 'red'
*'''fallback''': 'true' or 'false' whether to enable fallback. If disabled, then characters will only be used from the closest matching font on the system. No fallback will be done to other fonts on the system that might contain the characters in the text. Fallback is enabled by default. Most applications should not disable fallback.
*'''letter_spacing''': Inter-letter spacing in 1024ths of a point.
*'''gravity''': One of 'south', 'east', 'north', 'west', 'auto'.
*'''gravity_hint''': One of 'natural', 'strong', 'line'.

The following pango attributes are also available directly as attributes of the '''[message]''' tag:
{{DevFeature1.13|4}}

*'''font'''
*'''font_family'''
*'''font_size'''
*'''font_style'''
*'''font_weight'''
*'''font_variant'''
*'''font_stretch'''
*'''color'''
*'''bgcolor'''
*'''underline'''
*'''underline_color'''
*'''rise'''
*'''strikethrough'''
*'''strikethrough_color'''
*'''fallback'''
*'''letter_spacing'''
*'''gravity'''
*'''gravity_hint'''

== [objectives] ==
The other tag used for plot development is '''[objectives]'''.
The '''[objectives]''' tag overwrites any previously set objectives,
and displays text which should describe the objectives of the scenario.
Scenario objectives are displayed on the player's first turn after the tag is used,
or as part of the event if it triggers during that player's turn.
Objectives can also be accessed at any time in a scenario using the
"Scenario Objectives" game menu option, making this tag useful for
scenario-specific information that the player may need to refer to during play.

Attributes of '''[objectives]''':
* '''side''': Default '0'. The side to set the objectives for. A value of 0 sets objectives for all sides. note: There are side-specific objectives and default objectives, which are used in case a side doesn't have specific ones. Specifying 0 sets the default ones.
* '''[[StandardSideFilter]]''' tags and keys: Sets the objectives of all matching sides to these passed specifications (the rest of this [objectives] tag). If no sides (such as when passing side=0) or all sides match, sets the default objectives, and the side specific ones for the matching sides otherwise.
* '''bullet''': Default '• '. Replaces the default bullet, with whatever is passed, for all objectives, gold carryover notes, and notes defined with [note].
* '''summary''': Displayed first in the objectives text, this should describe the basic objective for the overall scenario. Can be omitted.
* '''note''': Displayed last in the objectives text, this is sometimes used for hints or additional information. Can be omitted.
* '''victory_string''': Default ' _ "Victory:"', this text precedes the victory objectives. Can be set to "" too.
* '''defeat_string''': Default ' _ "Defeat:"', this text precedes the defeat objectives. Can be set to "" too.
* '''gold_carryover_string''': Default ' _ "Gold carryover:"', this text precedes the gold carryover information.
* '''notes_string''': Default ' _ "Notes:"', this text precedes the notes.
* '''silent''': Default: not present. If set to "yes", the objectives are silently changed. Else, they will be shown to the user when appropriate.
* '''delayed_variable_substitution''': {{DevFeature1.13|8}} If set to yes, any variables or [insert_tag] are not substituted right away. Instead, they are substituted whenever the objectives are actually viewed.

Tags of '''[objectives]''':
* {{anchor|objectives-objective|'''[objective]'''}}: describes a win or loss condition. Most scenarios have multiple win or loss conditions, so use a separate [objective] subtag for each line; this helps with translations.
** '''bullet''': Default '• ' or whatever is set in the parent [objectives] block. Replaces the default bullet, with whatever is provided, for the objective defined by the [objective] block.
** '''red''': Default '0' for winning objectives, '255' for losing objectives. Overrides the default red coloring of the entire objective, including the bullet.
** '''green''': Default '255' for winning objectives, '0' for losing objectives. Overrides the default green coloring of the entire objective, including the bullet.
** '''blue''': Default '0'. Overrides the default blue coloring of the entire objective, including the bullet.
** '''description''': text for the specific win or loss condition.
** '''caption''': a text which will be displayed above the ''description''. This can be used to display a subcategory of objectives below ''victory_string'' or ''defeat_string''.
** '''condition''': The color and placement of the text. Values are 'win'(colored green, placed after ''victory_string'') and 'lose'(colored red, placed after ''defeat_string'').
** '''show_turn_counter''': If set to yes, displays the number of turns remaining in the scenario. Default is no.
** '''[show_if]''': A condition that disables the objective if it doesn't hold. Conditional objectives are refreshed at '''[show_objectives]''' time only, or when manually opening the scenario objectives.
* {{anchor|objectives-gold_carryover|'''[gold_carryover]'''}}: describes how the gold carryover works in this scenario. This is intended to be a more convenient way of displaying carryover information than using the note= key in [objectives].
** '''bullet''': Default '• ' or whatever is set in the parent [objectives] block. Replaces the default bullet with whatever is provided.
** '''red''': Default '255'. Overrides the default red coloring of the entire objective, including the bullet.
** '''green''': Default '255'. Overrides the default green coloring of the entire objective, including the bullet.
** '''blue''': Default '192'. Overrides the default blue coloring of the entire objective, including the bullet.
** '''bonus''' (boolean): whether an early finish bonus is granted. If omitted, early finish bonus is not mentioned.
** '''carryover_percentage''': the amount of carryover gold. If omitted, the amount is not mentioned.
** '''[show_if]''': {{DevFeature1.13|11}} Gold carryover will not be shown if the specified condition isn't met. Conditional gold carryover is refreshed at '''[show_objectives]''' time only.
* {{anchor|objectives-note|'''[note]'''}}: describes a note, usually used for hints or additional information. This is an easier way of adding several notes than concatenating them together into a single string to use with the ''note='' key.
** '''bullet''': Default '• ' or whatever is set in the parent [objectives] block. Replaces the default bullet with whatever is provided for the note defined by the [note] block.
** '''red''': Default '255'. Overrides the default red coloring of the entire note, including the bullet.
** '''green''': Default '255'. Overrides the default green coloring of the entire note, including the bullet.
** '''blue''': Default '255'. Overrides the default blue coloring of the entire note, including the bullet.
** '''description''': the text of the note.
** '''[show_if]''': The note will not be shown if the specified condition isn't met. Conditional notes are refreshed at '''[show_objectives]''' time only.

== [set_menu_item] ==
This tag is used to add a custom option in the right-click context menu which can then be used to trigger arbitrary WML commands. The menu items can be set and modified during any event, for example during "start" or "prestart" events. The user can also assign hotkeys to these WML commands unless specified otherwise. When the hotkey is pressed the event will be fired/filtered at the current mouse position.

'''Note:''' Due to limitations in portable devices where there are no scroll bars for context menus, there is a hard-coded limit of 7 custom WML menu items. If you really need to have more than 7 menu items, try combining some of them in a submenu. {{DevFeature1.13|0}} This limitation is being removed in a [http://forums.wesnoth.org/viewtopic.php?p=572554#p572554 future version] of Wesnoth.

* '''id''': the unique id for this menu item. If a menu item with this id already exists, it allows you to set specific changes to that item. All menus will be sorted lexicographically by the id string. The ordering is underscores, digits, and finally letters.
* '''description''': the in-game text that will appear for this item in the menu.
* '''image''': the image to display next to this item, defaults to "buttons/WML-custom.png"
* '''needs_select''': if ''yes'' (default ''no''), then the latest select event (see [[EventWML]]) that triggered before this menu item was chosen will be transmitted over the network before this menu item action will be. This only has any effect in networked multiplayer, and is intended to allow more elaborate menu item behaviour there without causing out of sync errors. If you don't know what this means, just leave it. {{DevFeature1.13|6}} ''needs_select=yes'' is deprecated, consider using manual variable syncing with [sync_variable].
* '''synced''' {{DevFeature1.13|1}}: if ''no'' (default ''yes'') the command handler will only be run on the client that invoked the menu item; this means that changing the gamestate in a command handler of a menu item with ''synced=no'' will cause OOS
* '''use_hotkey''': if ''no'' (default ''yes''), then the user cannot assign hotkeys to this menu item. If ''only'', the menu item is only accessible via hotkeys, not via right-click context; you can use this in combination with [default_hotkey] if you want custom hotkeys in your campaign/mp.
* '''[show_if]''': If present, the menu item will only be available if the conditional statement (see [[ConditionalActionsWML#Condition_Tags|ConditionalActionsWML]]) within evaluates to true. When this is evaluated, the WML variables ''$x1'' and ''$y1'' will point to the location on which the context menu was invoked, so it's possible to for example only enable the option on empty hexes or on a particular unit.
* '''[filter_location]''': contains a [[StandardLocationFilter]] similar to the one found inside Single Unit Filters. The menu item will only be available on matching locations.
* '''[default_hotkey]''': contains a hotkey WML to specify what hotkey to assign to this, '''if the user has no hotkey assigned to this yet'''. (Unlike the rest of a menu item definition, modifying this tag has no effect on the game; it is only effective when initially defining a menu item.) Hotkey WML matches the format in the preferences file and contains the following keys:
** '''key''': a string that contains the key to assign to this.
** '''alt''', '''shift''', '''cmd'''(apple only), '''ctrl''': boolean values.
** '''repeat_on_hold''' {{DevFeature1.13|12}}: if ''yes'' (default ''no''), holding the hotkey will repeat the action continuously, unless it blocks input with something like '''[message]'''. Due to a bug, versions older than 1.13.12 always repeat the action, with no way to disable it.
* '''[command]''': contains the WML actions to be executed when the menu item is selected. Again, the WML variables ''$x1'' and ''$y1'' will point to the location on which the context menu was invoked on.
** '''delayed_variable_substitution ''' (boolean yes|no, default: yes): If no, forces a variable substitution run onto the wml included in this [command] block. Use this, if you want variables which are to substitute to get the values they have at execution time of the event where this set_menu_item appears. Other than that, they get the values they have at invocation time of the menu item.

== [clear_menu_item] ==

Removes a menu item from the scenario.
Normally menu items are, including all their defining wml, automatically carried over between scenarios. This tag prevents this. (The behavior is comparable to set_variable/clear_variable).
* '''id''': (string): id of the menu item to clear. Can be a comma-separated list.

== Other interface tags ==

The following tags are also action tags:

=== [change_theme] ===

{{DevFeature1.13|8}}

Change the current interface theme.

* '''theme''': The ID of the new theme. Use <code>theme=</code> (empty key) to switch back to the theme that the player has selected in Preferences. On <b>1.14.2</b> and later it is also possible to omit the key entirely to achieve the same effect (on previous versions this will crash the Lua engine).

=== [item] ===
Makes a graphical item appear on a certain hex. Note this only places the graphics for an item. It does not make the item do anything. Use a moveto event to make moving onto the item do something. <tt>''('''Hint:''' There are a number of predefined items that are used in various campaigns that you can make use of. You can find [http://www.wesnoth.org/macro-reference.xhtml#file:items.cfg a list of them] if you look into the items.cfg file in the wesnoth install directory (under /data/core/macros).)''</tt>
* '''x''', '''y''': the location to place the item. (only for [event][item]: full [[StandardLocationFilter|SLF]] support)
* '''image''': the image (in ''images/'' as .png) to place on the hex. This image is aligned with the top-left of the hex (which is 72 pixels wide and 72 pixels tall). It is drawn underneath units. ''('''Hint:''' If using an image smaller than 72x72, then it might be useful to [[ImagePathFunctions#Blit_Function|BLIT]] the image onto <tt>misc/blank-hex.png</tt> (a blank 72x72 image).)''
* '''halo''': an image to place centered on the hex. It is drawn on top of units. Use this instead of ''image'' if the image is bigger than the hex or if you want to animate an image (https://github.com/wesnoth/wesnoth/issues/1219).
* '''name''' an id that can be used to remove the item.
''Example (where the integer after the colon is the duration of each frame or square bracket expansion as per AnimationWML is used): halo=scenery/fire1.png:100,scenery/fire2.png:100,scenery/fire3.png:100,scenery/fire4.png:100,scenery/fire5.png:100,scenery/fire6.png:100,scenery/fire7.png:100,scenery/fire8.png:100''
or equivalently (requires Wesnoth 1.11.2+):
''halo=scenery/fire[1~8].png:100''
* '''team_name''': name of the team for which the item is to be displayed (hidden for others). For multiple teams just put all the names in one string, for example separated by commas. {{DevFeature1.15|0}} In 1.14 the '''[side]team_name''' attribute was expected to be a substring of this '''team_name'''. In 1.15 both are expected to be comma-separated lists of names and the item is visible if the lists intersect. ([[https://github.com/wesnoth/wesnoth/pull/3533|#3533]])
* '''visible_in_fog''': whether the item should be visible through fog or not. Default yes.
* '''redraw''': (boolean yes|no, default: yes): If no, disables implicit calls to [[InterfaceActionsWML#.5Bredraw.5D|[redraw]]] when placing the items.
* '''[filter_team]''': {{DevFeature1.15|0}} A [[StandardSideFilter]]. Set '''team_name''' to the union of all '''[side]team_name''' attributes of all sides that match the SSF. ([[https://github.com/wesnoth/wesnoth/pull/3533|#3533]])
* {{DevFeature1.15|0}} If both '''team_name''' and '''[filter_team]''' are set, '''team_name''' is ignored.

=== [remove_item] ===
Removes any graphical items on a given hex.
* [[StandardLocationFilter]]: the hexes to remove items from
* '''image''': if specified, only removes the given item if one of its 'image', 'halo' or 'name' attributes is exactly this value. (for 'halo' and 'image' this in particular means that the image name must include any [[ImagePathFunctions|image path functions]] appended to the original image name.)

=== [print] ===
Displays a message across the screen. The message will disappear after a certain time, or when another [print] tag is encountered.
* '''text''': (translatable) the text to display. Can be an empty string to remove a previous message without showing a new one.
* '''size''': (default=12) the pointsize of the font to use
* '''duration''': the length of time to display the text for.
** (Before 1.15.4) This is measured in the number of 'frames', and the default is 50. A frame in Wesnoth is usually displayed for around 30ms.
** {{DevFeature1.15|4}} This is measured in milliseconds. Don't use the default value, because it's a mere 50ms.
** {{DevFeature1.15|14}} The default is 5000 milliseconds.
** {{DevFeature1.15|14}} The string '''unlimited''' displays the text until it's removed by another [print] tag.
* '''color''': (default '''0,0,0''') three comma-separated values giving the red, green and blue values (0-255).
* '''red''', '''green''', '''blue''': deprecated, use color=0,0,0 instead.

=== [move_unit_fake] ===
Moves an image of a unit along a certain path on the map. The path does not need to be a continuous list of adjacent hexes, so for example only the start and end points can be given, in which case the straightest line between those points will be calculated and used.
* '''type''': the type of the unit whose image to use
* '''x''': a comma-separated list of x locations to move along
* '''y''': a comma-separated list of y locations to move along (x and y values are matched pairs)
* '''side''': the side of the fake unit, used for team-coloring the fake unit
* '''gender''': the gender of the fake unit. Example: gender=female
* '''variation''': the variation of the fake unit. Example: variation=undead
* '''image_mods''': [[ImagePathFunctions|image path functions]] sequence to be applied on the fake unit.
* '''force_scroll''': Whether to scroll the map or not even when [[#.5Block_view.5D|[lock_view]]] is in effect or ''Follow Unit Actions'' is disabled in ''Advanced Preferences''. Defaults to ''yes'' starting with version '''1.11.6'''; the attribute did not exist in previous versions and this action behaved as if ''no'' was passed instead.

=== [move_units_fake] ===
moves multiple images of units along paths on the map. These units are moved in lockstep.
* '''force_scroll''': {{DevFeature1.15|0}} Has the same meaning as in [move_unit_fake] but a different default.
* '''[fake_unit]''': A fake unit to move
** '''type''': the type of unit whose image to use
** '''x''': a comma-separated list of x locations to move along
** '''y''': a comma-separated list of y locations to move along (x and y values are matched pairs)
** '''side''': the side of the fake unit, used for team-coloring the fake unit
** '''skip_steps''': the number of steps to skip before this unit starts moving

=== [hide_unit] ===
Temporarily prevents the engine from displaying the given unit. The unit does not become invisible, as it would be with the '''[hides]''' ability; it is still the same plain unit, but without an image. Useful in conjunction with '''[move_unit_fake]''': to move a leader unit into position on-screen. Until 1.8 each '''[hide_unit]''' tag only hides one unit.
* [[StandardUnitFilter]]: All matching units will be hidden

=== [unhide_unit] ===
Stops the currently hidden units from being hidden.
* [[StandardUnitFilter]]: Only the matching units will be unhidden

=== [lock_view] ===
Locks gamemap view scrolling for human players, so they cannot scroll the gamemap view until it is unlocked. WML or Lua actions such as '''[scroll_to]''' will continue to work normally, as they ignore this restriction; the locked/unlocked state is preserved when saving the current game.

This feature is generally intended to be used in cutscenes to prevent the player scrolling away from scripted actions.

{{DevFeature1.13|8}} This now also blocks the player from zooming the gamemap view. WML or Lua zoom will continue to work normally.

=== [unlock_view] ===
Unlocks gamemap view scrolling for human players.

=== [scroll] ===
Scroll a certain number of pixels in a given direction. Useful for earthquake/shaking effects.
* '''x''', '''y''': the number of pixels to scroll along the x and y axis
* '''side''': the side or sides for which this should happen. By default, the [scroll] happens for everyone.
* '''[filter_side]''': a [[StandardSideFilter]] to select the sides for which this should happen. By default, the [scroll] happens for everyone.

=== [scroll_to] ===
Scroll to a given hex
* [[StandardLocationFilter]], do not use a [filter_location] sub-tag. If more than one location matches the filter, only the first matching location will be used.
* '''check_fogged''': whether to scroll even to locations covered in fog or shroud. Possible values ''yes'' (don't scroll to fog) and ''no'' (scroll even to fog), with ''no'' as the default.
* '''immediate''': whether to instantly warp to the target hex regardless of the scroll speed setting in Preferences (defaults to ''no'').
* '''highlight''': {{DevFeature1.13|5}} Whether to highlight the hex being scrolled to (defaults to ''no'').
* '''side''': the side or sides for which this should happen. By default, the [scroll_to] happens for everyone.
* '''[filter_side]''': a [[StandardSideFilter]] to select the sides for which this should happen. By default, the [scroll_to] happens for everyone.

=== [scroll_to_unit] ===
Scroll to a given unit
* [[StandardUnitFilter]]; do not use a [filter] subtag.
* '''check_fogged''': whether to scroll even to locations covered in fog or shroud. Possible values ''yes'' (don't scroll to fog) and ''no'' (scroll even to fog), with ''no'' as the default.
* '''immediate''': whether to instantly warp to the target hex regardless of the scroll speed setting in Preferences (defaults to ''no'').
* '''highlight''': {{DevFeature1.13|5}} Whether to highlight the hex the unit is on (defaults to ''no'').
* '''for_side''': the side or sides for which this should happen. By default, the [scroll_to_unit] happens for everyone.
* '''[for_side]''': a [[StandardSideFilter]] to select the sides for which this should happen. By default, the [scroll_to_unit] happens for everyone.

=== [select_unit] ===
Selects a given unit.
* [[StandardUnitFilter]]: The first unit found will be selected.
* '''fire_event''': whether a ''select'' event should be triggered or not (def. ''no''). (Note that select events aren't multiplayer save.)
* '''highlight''': whether the unit's current hex should be highlighted (def. ''yes'').

'''Note:''' fire_event does not appear to work in 1.14 or 1.16.

=== [sound]===
Plays a sound
* '''name''': the filename of the sound to play (in ''sounds/'' as .wav or .ogg). This can be a comma-separated list, from which one sound will be chosen randomly.
* '''repeat''': repeats the sound for a specified additional number of times (default=0)

=== [sound_source] ===
Creates a sound source. "Sound sources" is a general name for a mechanism which makes possible for map elements to emit sounds according to some rules, where "map elements" can be specific locations or terrain types. For now, only sound sources tied to locations are supported.
* '''id''': a unique identification key of the sound source
* '''sounds''': a list of comma separated, randomly played sounds associated with the sound source
* '''delay''': a numerical value (in milliseconds) of the minimal delay between two playbacks of the source's sound if the source remains visible on the screen; if one scrolls out and back in, the source will be considered as ready to play
* '''chance''': a percentage (a value from 0 to 100) describing the chance of the source being activated every second after the delay has passed or when the source's location appears on the screen (note that it cannot play more than one file at the same time)
* '''check_fogged''': possible values ''yes'' and ''no'' - ''yes'' means the source will not play if its locations are fogged
* '''check_shrouded''': possible values ''yes'' and ''no'' - ''yes'' means the source will not play if its locations are shrouded
* '''x,y''': similar to x,y as found in a [[StandardLocationFilter]], these are the locations associated with the sound source
* '''fade_range''' (default = 3): distance in hexes that determines a "circular" area around the one specified by '''full_range''' where sound volume fades out linearly
* '''full_range''' (default = 14): distance in hexes that determines a "circular" area where source plays with full volume, relative to screen center
* '''loop''': number of times a sound sample should be looped if it stays visible. -1 means infinite (~65000)

=== [story] ===
{{DevFeature1.13|8}}

Shows the story screen.
* '''title''': Default title used if a part does not specify one — unlike the intro storyscreen, the scenario name is not used as a default title.
* '''[part]''', '''[if]''', '''[switch]''', '''[wml_message]''', '''[deprecated_message]''' : See [[IntroWML]].

=== [remove_sound_source] ===
Removes a previously defined sound source.
* '''id''': the identification key of the sound source to remove

=== [music] ===
Switches to playing different music
* '''name''': the filename of the music to play (in ''music/'' as .ogg)
* see [[MusicListWML]] for the correct syntax

=== [volume] ===
Changes the game volume to a percent of the preferences volume for the game being played. Values can go from 0 to 100:
* '''music''': Changes the music volume.
* '''sound''': Changes the sound volume.

=== [color_adjust] ===
Adjust the color tint of terrain, by adjusting time-of-day coloring.
* '''red''', '''green''', '''blue''': values from -255 to 255, the amount to tint by for each color

=== [screen_fade] ===
{{DevFeature1.17|6}}

Overlay the game display with the given color, fading over the specified duration. This can be used for screen fade effects.
* '''red''', '''green''', '''blue''': values from 0 to 255, the final overlay color (defaults to 0,0,0)
* '''alpha''': value from 0 to 255, the strength of the effect. 0 means no effect and can be used to fade in. 255 means fully opaque and can be used to fully fade out to the given color. Intermediate values will end up with a partial overlay tint on the game screen.
* '''duration''': the length of time it will take to complete the fade, in milliseconds. If 0 the effect is immediate.

=== [delay] ===
Pauses the game.
* '''time''': the time to pause in milliseconds
* '''accelerate ''' (boolean yes|no, default no): {{DevFeature1.13|0}} whether the delay is affected by acceleration. When [delay] is used to make an animation, this should be set to yes so that your animation matches the ones generated by the game.

=== [redraw] ===
Redraws the screen (this normally isn't done during events, although some of the other interface actions cause the screen or parts of it to be redrawn).
* '''clear_shroud''' (boolean yes|no, default no): If yes, clears fog and shroud around existing units. Useful if you, for example, spawn friendly units in the middle of an event and want the shroud to update accordingly (otherwise units that spawn inside fog would remain invisible for the duration of the event, since the fog would not automatically get cleared around them).
* '''[[StandardSideFilter]]''': the sides for which to recalculate fog and shroud.
* '''side''': If used (forces clear_shroud=yes), clears fog and shroud for that side.

=== [unit_overlay] ===
Sets an image that will be drawn over a particular unit, and follow it around
* [[StandardUnitFilter]]: All matching units will get the overlay (do not use [filter])
* '''image''': the image to place on the unit
* '''object_id''': object id to use, defaults to the '''image''' key with an "overlay_" prefix; this allows using [[DirectActionsWML#.5Bremove_object.5D|'''[remove_object]''']]
* '''duration''': object duration

=== [remove_unit_overlay] ===
Removes a particular overlayed image from a unit
* [[StandardUnitFilter]]: The overlay will get removed from all matching units (do not use [filter])
* '''image''': the image to remove from the unit
* '''object_id''': object id to use
Using [[DirectActionsWML#.5Bremove_object.5D|'''[remove_object]''']] is also possible, see https://github.com/wesnoth/wesnoth/commit/26c2f941f2bcdd89528481e114c0375ad2a46271

=== [animate_unit] ===
Uses an animation of a unit to animate it on screen (if the unit has the corresponding animation).
* '''flag''': The key to find the custom animation in the unit description (see the '''[extra_anim]''' description in [[AnimationWML]]). Standard animations can be triggered with the following keywords: ''leading recruited standing idling levelout levelin healing healed poisoned movement defend attack death victory pre_teleport post_teleport''
* '''[filter]''' with a [[StandardUnitFilter]] as argument, see [[FilterWML]]. By default, the unit at the event location will be animated. You can use this tag to choose any other unit to animate.
* '''[primary_attack]''': If this tag is not present, the filter for animation will be triggered with no attack. If it is here, all attacks from the unit will be filtered, and a matching one will be used to filter the animation. Takes a weapon filter as argument, see [[FilterWML]].
* '''[secondary_attack]''': Similar to '''[primary_attack]'''. May be needed to trigger a defense animation correctly, if there are more than one animations available for the defending unit.
* '''hits''': yes/no/hit/miss/kill: which according variation of a attack/defense animation shall be chosen (required)
* '''text''': a text to hover during the animation
* '''male_text''', '''female_text''': {{DevFeature1.13|2}} (translatable) gender-specific versions of the above
* '''red''': red value for the text color (0-255)
* '''green''': green value for the text color
* '''blue''': blue value for the text color
* '''with_bars''': yes/no: whether to display the status bars during the animation (e.g. the hitpoint bar)
* '''[animate]''': a sub block with the same syntax as '''[animate_unit]''' except that the '''[filter]''' block is mandatory to find the unit. This block will find and animate another unit simultaneously.
* '''[facing]''': a [[StandardLocationFilter]] specifying what hex the unit should be facing when animated

=== [label] ===
Places a label on the map.
* '''x''', '''y''': the location of the label. {{DevFeature1.13|1}} (only for [event][label]: full [[StandardLocationFilter|SLF]] support)
* '''text''': what the label should say. If you put an empty string <code>""</code> as an argument, the label will be completely removed. Use this method if you want to remove a specific label from any location.
* '''team_name''': if specified, the label will only be visible to the given team.
* '''color''': color of the label. The format is r,g,b; r, g and b are numbers between 0 and 255.
* '''visible_in_fog''': whether the label should be visible through fog or not. Default yes.
* '''visible_in_shroud''': whether the label should be visible through shroud or not. Default no.
* '''immutable''': whether this label is protected from being removed or changed by players. Default yes.
* '''category''': the Show/Hide Labels dialog allows showing/hiding all labels of a given category by toggling a checkbox.
* '''tooltip''': A tooltip visible when mouseovering the hex the label is on
* '''side''': the number of the side that placed the label. Can be 0 for labels placed by WML.

=== [floating_text]===
Floats text (similar to the damage and healing numbers) on the given locations.
* [[StandardLocationFilter]]: the text will be floated on all matching locations simultaneously (do not use [filter] unless you intend to match one or more units).
* '''text''': the text to display.

The default text color is <span style="color: #6b8cff;">'''#6b8cff'''</span>. To change the color, use [[#Formatting|Pango markup]]. For example:

<pre>
# Float some golden yellow text at 20,20.
[floating_text]
x,y=20,20
text="<span color='#cccc33'>" + _ "Your text here" + "</span>"
[/floating_text]
</pre>

=== [deprecated_message] ===
Shows a deprecated message in the message area, this feature is only intended to be used to warn about deprecated macros in mainline. The message is not translatable.
* '''message''': the message to show.
* '''level''': {{DevFeature1.13|10}} The deprecation level, a number from 1 to 3.
* '''what''': {{DevFeature1.13|10}} The name of the thing being deprecated. Use this instead of '''message''' if possible; a stock message will be generated from it. Use '''message''' only if more information is required; it will be appended to the stock message. This should not be translatable
* '''version''': {{DevFeature1.13|10}} For deprecation levels 2 and 3, this indicates the version in which the feature could be removed. It does ''not'' indicate the version in which it became deprecated.

The meanings of the deprecation levels are as follows:

# Deprecated, but will only be removed if absolutely necessary. The '''version''' key is ignored.
# It will be removed no earlier than a specified version.
# It will be removed in the next stable version
# It has already been removed, leaving just a stub to inform users of how to update their code.

Note that as of 1.13.11, deprecation messages show only in the log, not in the chat message area. The '''message''' can be translatable, but does not need to be.

=== [wml_message] ===
Outputs a message to Wesnoth's console output. Intended for campaign designers to output silent text to the console, without annoying the player; then, that text might contain information useful for later bug-reporting. The log domain for it is '''wml''', and the '''debug/dbg''' log level is available for use with the '''logger''' attribute. Depending on the current log level ('''error''' by default), which may be changed with the in-game :log command, or the --log-<level>=wml command line switch, the messages are echoed to the in-game chat.
* '''message''': the message to show.
* '''logger''': the Wesnoth engine output logger that should catch the text; this might be 'err' (the errors log level), 'warn'/'wrn' (the warnings log level) or anything else (the information log level). Not all information will be displayed depending on the log level chosen when starting Wesnoth.

Note: As of 1.9.4/1.9.5 (r48805) the following "loggers" should work: If in [wml_message]: err/error, warn/wrn/warning, debug/dbg; using the :log command: Only the long forms error, warning, info and debug (this part gathered by trying rather than source inspecting). The long forms are most likely also the only ones working when starting wesnoth with --log-<level>=wml.
For log level warning or error (as during normal play), only wml_messages with logger error or warning display (for both). With logger info or debug, additionally wml_messages with logger info or debug display (for both).

=== [test_condition] ===

{{DevFeature1.13|2}}

Evaluates the contained conditional tags. If they evaluate to the expected value, it prints out a message to the console explaining which part of the condition caused this result in a way similar to [wml_message]. This can be used if your conditional test is failing and you're not sure why.

* '''result''': Whether you expect the conditions to fail or succeed. If no (the default), a message will be printed if the conditional tags fail. If yes, a message will instead be printed if the conditional tags pass.
* '''logger''': Same as for [wml_message]. Defaults to "warning".

=== [open_help] ===
Opens the in-game help.
* '''topic''': the id of the topic to open

Examples of ids:
* unit_Mage
* unit_Dark Adept
* weaponspecial_charge
* terrain_human_castle

The engine will print the topic ids if run from the command line with the ''--log-debug=help'' option.

=== [show_objectives] ===
refreshes the objectives defined by [objectives] and its [show_if] tags, and displays them. (It is also called whenever the user explicitly asks for the objectives; this matters only if the tag was overridden by a [[LuaWML#register_wml_action|Lua]] script.)
* '''side''': the side to show the objectives. If not set, all sides are used.
* '''[[StandardSideFilter]]''' tags and keys: Tag affects the matching sides instead of just all or the one given by the integer value of the side= key.

=== [chat] ===
Displays a message in the chat area, not visible for observers. Alternative unconditionally visible for everyone: [[LuaWML:Display#wesnoth.message]]. {{DevFeature1.13|9}} can be visible for observers.
* '''speaker''': (default="WML") A string for the name of the sender of the message.
* '''message''': The message that should be displayed.
* '''observable''' (boolean yes|no, default yes): {{DevFeature1.13|9}} Whether the message is displayed for observers.
* '''[[StandardSideFilter]]''' tags and keys as argument; if the same client controls multiple sides that match, then the message will only be displayed once.

=== [zoom] ===

{{DevFeature1.13|8}}

Changes the zoom level of the map.

* '''factor''': The new zoom factor, measured as a multiple of the base zoom.
* '''relative''': If yes, zoom relative to current zoom level. Otherwise, set the absolute zoom level. Default no.

== Useful Macros ==
There are some predefined macros that you find useful for interface actions. You can find a complete list along with a detailed explanation of how they work [http://www.wesnoth.org/macro-reference.xhtml here].
* '''{HIGHLIGHT_UNIT}''' Highlight a unit on the map. Use this to show important units
* '''{HIGHLIGHT_IMAGE}''' Places and highlights an image on the map. Use this to show important items or locations
* '''{SET_IMAGE}''' Places an image on the map which has no other function.
* '''{QUAKE <soundfile>}''' Creates a tremor-like screenshake and plays <soundfile>. For example, '''{QUAKE (rumble.ogg)}'''.
* '''{FLASH_WHITE}''' Flash the screen white momentarily. You can also replace WHITE with RED, BLUE or GREEN for a different colour.

== See Also ==
* [[DirectActionsWML]]
* [[InternalActionsWML]]
* [[EventWML]]
* [[ReferenceWML]]

[[Category: WML Reference]]
[[Category: ActionsWML]]

InterfaceActionsWML

2024-05-29T12:33:43Z

Spixi: Added undocumented image key

{{WML Tags}}
== Interface actions ==

Part of [[ActionWML]], interface actions are actions that do not have a direct effect on gameplay;
instead, they show something to the player. The main interface tags
are '''[message]''' and '''[objectives]''', but several other tags affect
the interface also.

== [inspect] ==
This user interface instantly displays the gamestate inspector dialog at the current scenario state (the same one that can be brought up with [[CommandMode|the ''':inspect''' command]]), which can be used to inspect the values of WML variables, AI configuration, recall lists, and more.

* '''name''': optional attribute to specify the name of this gamestate inspector dialog. It is just a label to help differentiate between different invocations of gamestate inspector dialog.

== [message] ==
The most commonly used interface action is [message], which displays a message to the user in a dialog box. It can also be used to take input from the user.

The following key/tags are accepted for [message]:
* [[StandardUnitFilter]]: The unit whose profile and name are displayed. Do not use a [filter] tag. If no unit matching this filter is found, the message is not displayed (The unit has probably been killed).<br>[message] elements should be constructed so that it is either guaranteed that a certain unit is alive, or so that dialog flows smoothly even if the message isn't displayed.

* '''speaker''': an alternative to standard unit filter. You may specify as the value of the speaker attribute a unit id or any of the following special values:
** '''narrator''': the dialog box is displayed without a caption for the unit speaking or a unit image
** '''unit''': the primary unit for the event is speaking
** '''second_unit''': the secondary unit for the event is speaking

* '''message''': (translatable) the text to display to the right of the image. ''message'' is sometimes multiple lines; if it is, be sure to use quotes(''' ' ''' or ''' " ''')
* '''male_message''', '''female_message''': {{DevFeature1.13|2}} (translatable) Used instead of ''message'' if the unit's gender matches. Never used if there is no unit (ie ''speaker=narrator''). {{DevFeature1.13|6}} This matches the primary unit, not the secondary unit.
* '''wait_description''': {{DevFeature1.13|2}} the description of this message displayed when other players in a mp game wait for one player doing input in a [message] (with [option]s or [text_input]).
* '''[show_if]''': if present then this message will only be displayed if the conditional statement in this tag is passed (see [[ConditionalActionsWML#Condition_Tags|ConditionalActionsWML]])
* '''side_for''': (default: all sides) comma-separated list of sides for who message is shown. This will <b>not</b> work with messages that take user input ([option]/[text_input]), which can only ever be shown to the current player. {{DevFeature1.13|0}} side_for= is now also accepted for messages with user input, it specifies on which side the message is shown (defaults to the currently playing side). For messages with input it does not accept a comma seperated list only a single number.
* '''image''': (default: profile image of speaker) the image to display to the left of the message text. Append ~RIGHT() if you want the image to appear on the right side.
** {{DevFeature1.13|0}} <b>none:</b> display no image
* '''mirror''': {{DevFeature1.13|5}}whether to mirror the image specified by the '''image''' attribute.
* '''second_image''': {{DevFeature1.13|6}}same as the '''image''' attribute, but the image is displayed on the right of the message text.
* '''second_mirror''': {{DevFeature1.13|6}}same as '''mirror''', but for the '''second_image''' attribute.
* '''image_pos''': {{DevFeature1.13|5}} whether to show the image on the left or right; supercedes the use of ~RIGHT() described above
* '''caption''': (default: name of speaker) the caption to display beside the image. Name to be displayed. Note: use a translation mark to avoid wmllint errors.
* '''scroll''': Boolean specifying whether the game view should scroll to the speaking unit. Defaults to ''yes''.
* '''highlight''': {{DevFeature1.13|5}} Boolean specifying whether to highlight the speaker. Defaults to ''yes''.
* '''sound''': a sound effect (wav file) to play as the message is displayed. This can be a comma-separated list, from which one will be randomly chosen.
* '''voice''', '''male_voice''', '''female_voice''': {{DevFeature1.13|?}} a sound to be played as the message is displayed. This can also be a comma-separated list, from which one will be randomly chosen. This is intended for voiceovers for the message. The gendered forms are applied the same as for '''message'''. They are never used when the speaker is the narrator - only '''voice''' is used in that case.
* {{anchor|message-option|'''[option]'''}}: No '''[option]''' elements have to be used. If '''[option]''' elements are present, then each option will be displayed in a menu for the user to select one option. ''Note: Messages with options will not be shown at all in prestart events''
** '''message''': (translatable) the text displayed for the option. {{DevFeature1.15|1}} This is now a synonym for '''description='''.
** '''image''', '''label''', '''description''', '''default''': See [[DescriptionWML#WML_Format|DescriptionWML]].
** '''value''': {{DevFeature1.13|?}} Gives the option a value to be stored in a variable.
** '''[show_if]''': if present then this option will only be displayed if the conditional statement in this tag is passed (see [[ConditionalActionsWML#Condition_Tags|ConditionalActionsWML]])
** '''[command]''': an element containing actions which are executed if the option is selected.
* '''variable''': {{DevFeature1.13|?}} If present, either the index or the value of the chosen option will be stored in the specified variable. Option indexing starts from 1. If option has '''[show_if]''' condition evaluated as false, then it is hidden and excluded from the indexing.
* {{anchor|message-text_input|'''[text_input]'''}}: there can be only one [text_input] tag. this adds a text input field to the message. ''Note: Messages with text_input will not be shown at all in prestart events''
** '''variable''': the variable that the user's input will be written to
** '''label''': a text label to the left of the input field
** '''max_length''': the maximum number of characters that may be typed into the field
** '''text''': text that is written into the field in the beginning
* Check [[EventWML#Multiplayer_safety]] to find out in which events you can safely use '''[option]''' and '''[text_input]''' without causing OOS.

=== Formatting ===
'''[message]''' and other tags such as unit names (user_description), objectives, and floating text can make use of [https://docs.gtk.org/Pango/pango_markup.html#pango-markup Pango markup formatting codes].

Prefer to use single quotes (') instead of double quotes (") within the formatting string, as double quotes would need to be escaped in WML (""). Escaping markup can be done with [https://github.com/wesnoth/wesnoth/blob/9daa10a9f27c5a95520e871417bbd72aa52aa688/src/font/pango/escape.hpp#L38-L42 HTML entities].

For example, if you wanted to write "You are victorious!" in large, italic, gold letters, you might write it this way:

<nowiki><span color='#BCB088' size='large' font-style='italic'>You are victorious!</span></nowiki>

These are the codes taken from the Pango markup formatting guide:

*'''font''', '''font_desc''': A font description string, such as "Sans Italic 12".
*'''font_family''', '''face''': A font family name.
*'''font_size''', '''size''': Font size in 1024ths of a point, or one of the absolute sizes 'xx-small', 'x-small', 'small', 'medium', 'large', 'x-large', 'xx-large', or one of the relative sizes 'smaller' or 'larger'.
*'''font_style''', '''style''': One of 'normal', 'oblique', 'italic'.
*'''font_weight''', '''weight''': One of 'ultralight', 'light', 'normal', 'bold', 'ultrabold', 'heavy', or a numeric weight.
*'''font_variant''', '''variant''': One of 'normal' or 'smallcaps'.
*'''font_stretch''', '''stretch''': One of 'ultracondensed', 'extracondensed', 'condensed', 'semicondensed', 'normal', 'semiexpanded', 'expanded', 'extraexpanded', 'ultraexpanded'.
*'''foreground''', '''fgcolor''', '''color''': An RGB color specification such as '#00FF00' or a color name such as 'red'. The full list of color names may be found in Pango's [https://github.com/GNOME/pango/blob/main/tools/rgb.txt rgb.txt] file.
*'''background, bgcolor''': An RGB color specification such as '#00FF00' or a color name such as 'red'.
*'''underline''': One of 'none', 'single', 'double', 'low', 'error'.
*'''underline_color''': The color of underlines; an RGB color specification such as '#00FF00' or a color name such as 'red'.
*'''rise''': Vertical displacement, in 10000ths of an em. Can be negative for subscript, positive for superscript.
*'''strikethrough''': 'true' or 'false' whether to strike through the text.
*'''strikethrough_color''': The color of strikethrough lines; an RGB color specification such as '#00FF00' or a color name such as 'red'
*'''fallback''': 'true' or 'false' whether to enable fallback. If disabled, then characters will only be used from the closest matching font on the system. No fallback will be done to other fonts on the system that might contain the characters in the text. Fallback is enabled by default. Most applications should not disable fallback.
*'''letter_spacing''': Inter-letter spacing in 1024ths of a point.
*'''gravity''': One of 'south', 'east', 'north', 'west', 'auto'.
*'''gravity_hint''': One of 'natural', 'strong', 'line'.

The following pango attributes are also available directly as attributes of the '''[message]''' tag:
{{DevFeature1.13|4}}

*'''font'''
*'''font_family'''
*'''font_size'''
*'''font_style'''
*'''font_weight'''
*'''font_variant'''
*'''font_stretch'''
*'''color'''
*'''bgcolor'''
*'''underline'''
*'''underline_color'''
*'''rise'''
*'''strikethrough'''
*'''strikethrough_color'''
*'''fallback'''
*'''letter_spacing'''
*'''gravity'''
*'''gravity_hint'''

== [objectives] ==
The other tag used for plot development is '''[objectives]'''.
The '''[objectives]''' tag overwrites any previously set objectives,
and displays text which should describe the objectives of the scenario.
Scenario objectives are displayed on the player's first turn after the tag is used,
or as part of the event if it triggers during that player's turn.
Objectives can also be accessed at any time in a scenario using the
"Scenario Objectives" game menu option, making this tag useful for
scenario-specific information that the player may need to refer to during play.

Attributes of '''[objectives]''':
* '''side''': Default '0'. The side to set the objectives for. A value of 0 sets objectives for all sides. note: There are side-specific objectives and default objectives, which are used in case a side doesn't have specific ones. Specifying 0 sets the default ones.
* '''[[StandardSideFilter]]''' tags and keys: Sets the objectives of all matching sides to these passed specifications (the rest of this [objectives] tag). If no sides (such as when passing side=0) or all sides match, sets the default objectives, and the side specific ones for the matching sides otherwise.
* '''bullet''': Default '• '. Replaces the default bullet, with whatever is passed, for all objectives, gold carryover notes, and notes defined with [note].
* '''summary''': Displayed first in the objectives text, this should describe the basic objective for the overall scenario. Can be omitted.
* '''note''': Displayed last in the objectives text, this is sometimes used for hints or additional information. Can be omitted.
* '''victory_string''': Default ' _ "Victory:"', this text precedes the victory objectives. Can be set to "" too.
* '''defeat_string''': Default ' _ "Defeat:"', this text precedes the defeat objectives. Can be set to "" too.
* '''gold_carryover_string''': Default ' _ "Gold carryover:"', this text precedes the gold carryover information.
* '''notes_string''': Default ' _ "Notes:"', this text precedes the notes.
* '''silent''': Default: not present. If set to "yes", the objectives are silently changed. Else, they will be shown to the user when appropriate.
* '''delayed_variable_substitution''': {{DevFeature1.13|8}} If set to yes, any variables or [insert_tag] are not substituted right away. Instead, they are substituted whenever the objectives are actually viewed.

Tags of '''[objectives]''':
* {{anchor|objectives-objective|'''[objective]'''}}: describes a win or loss condition. Most scenarios have multiple win or loss conditions, so use a separate [objective] subtag for each line; this helps with translations.
** '''bullet''': Default '• ' or whatever is set in the parent [objectives] block. Replaces the default bullet, with whatever is provided, for the objective defined by the [objective] block.
** '''red''': Default '0' for winning objectives, '255' for losing objectives. Overrides the default red coloring of the entire objective, including the bullet.
** '''green''': Default '255' for winning objectives, '0' for losing objectives. Overrides the default green coloring of the entire objective, including the bullet.
** '''blue''': Default '0'. Overrides the default blue coloring of the entire objective, including the bullet.
** '''description''': text for the specific win or loss condition.
** '''caption''': a text which will be displayed above the ''description''. This can be used to display a subcategory of objectives below ''victory_string'' or ''defeat_string''.
** '''condition''': The color and placement of the text. Values are 'win'(colored green, placed after ''victory_string'') and 'lose'(colored red, placed after ''defeat_string'').
** '''show_turn_counter''': If set to yes, displays the number of turns remaining in the scenario. Default is no.
** '''[show_if]''': A condition that disables the objective if it doesn't hold. Conditional objectives are refreshed at '''[show_objectives]''' time only, or when manually opening the scenario objectives.
* {{anchor|objectives-gold_carryover|'''[gold_carryover]'''}}: describes how the gold carryover works in this scenario. This is intended to be a more convenient way of displaying carryover information than using the note= key in [objectives].
** '''bullet''': Default '• ' or whatever is set in the parent [objectives] block. Replaces the default bullet with whatever is provided.
** '''red''': Default '255'. Overrides the default red coloring of the entire objective, including the bullet.
** '''green''': Default '255'. Overrides the default green coloring of the entire objective, including the bullet.
** '''blue''': Default '192'. Overrides the default blue coloring of the entire objective, including the bullet.
** '''bonus''' (boolean): whether an early finish bonus is granted. If omitted, early finish bonus is not mentioned.
** '''carryover_percentage''': the amount of carryover gold. If omitted, the amount is not mentioned.
** '''[show_if]''': {{DevFeature1.13|11}} Gold carryover will not be shown if the specified condition isn't met. Conditional gold carryover is refreshed at '''[show_objectives]''' time only.
* {{anchor|objectives-note|'''[note]'''}}: describes a note, usually used for hints or additional information. This is an easier way of adding several notes than concatenating them together into a single string to use with the ''note='' key.
** '''bullet''': Default '• ' or whatever is set in the parent [objectives] block. Replaces the default bullet with whatever is provided for the note defined by the [note] block.
** '''red''': Default '255'. Overrides the default red coloring of the entire note, including the bullet.
** '''green''': Default '255'. Overrides the default green coloring of the entire note, including the bullet.
** '''blue''': Default '255'. Overrides the default blue coloring of the entire note, including the bullet.
** '''description''': the text of the note.
** '''[show_if]''': The note will not be shown if the specified condition isn't met. Conditional notes are refreshed at '''[show_objectives]''' time only.

== [set_menu_item] ==
This tag is used to add a custom option in the right-click context menu which can then be used to trigger arbitrary WML commands. The menu items can be set and modified during any event, for example during "start" or "prestart" events. The user can also assign hotkeys to these WML commands unless specified otherwise. When the hotkey is pressed the event will be fired/filtered at the current mouse position.

'''Note:''' Due to limitations in portable devices where there are no scroll bars for context menus, there is a hard-coded limit of 7 custom WML menu items. If you really need to have more than 7 menu items, try combining some of them in a submenu. {{DevFeature1.13|0}} This limitation is being removed in a [http://forums.wesnoth.org/viewtopic.php?p=572554#p572554 future version] of Wesnoth.

* '''id''': the unique id for this menu item. If a menu item with this id already exists, it allows you to set specific changes to that item. All menus will be sorted lexicographically by the id string. The ordering is underscores, digits, and finally letters.
* '''description''': the in-game text that will appear for this item in the menu.
* '''image''': the image to display next to this item.
* '''needs_select''': if ''yes'' (default ''no''), then the latest select event (see [[EventWML]]) that triggered before this menu item was chosen will be transmitted over the network before this menu item action will be. This only has any effect in networked multiplayer, and is intended to allow more elaborate menu item behaviour there without causing out of sync errors. If you don't know what this means, just leave it. {{DevFeature1.13|6}} ''needs_select=yes'' is deprecated, consider using manual variable syncing with [sync_variable].
* '''synced''' {{DevFeature1.13|1}}: if ''no'' (default ''yes'') the command handler will only be run on the client that invoked the menu item; this means that changing the gamestate in a command handler of a menu item with ''synced=no'' will cause OOS
* '''use_hotkey''': if ''no'' (default ''yes''), then the user cannot assign hotkeys to this menu item. If ''only'', the menu item is only accessible via hotkeys, not via right-click context; you can use this in combination with [default_hotkey] if you want custom hotkeys in your campaign/mp.
* '''[show_if]''': If present, the menu item will only be available if the conditional statement (see [[ConditionalActionsWML#Condition_Tags|ConditionalActionsWML]]) within evaluates to true. When this is evaluated, the WML variables ''$x1'' and ''$y1'' will point to the location on which the context menu was invoked, so it's possible to for example only enable the option on empty hexes or on a particular unit.
* '''[filter_location]''': contains a [[StandardLocationFilter]] similar to the one found inside Single Unit Filters. The menu item will only be available on matching locations.
* '''[default_hotkey]''': contains a hotkey WML to specify what hotkey to assign to this, '''if the user has no hotkey assigned to this yet'''. (Unlike the rest of a menu item definition, modifying this tag has no effect on the game; it is only effective when initially defining a menu item.) Hotkey WML matches the format in the preferences file and contains the following keys:
** '''key''': a string that contains the key to assign to this.
** '''alt''', '''shift''', '''cmd'''(apple only), '''ctrl''': boolean values.
** '''repeat_on_hold''' {{DevFeature1.13|12}}: if ''yes'' (default ''no''), holding the hotkey will repeat the action continuously, unless it blocks input with something like '''[message]'''. Due to a bug, versions older than 1.13.12 always repeat the action, with no way to disable it.
* '''[command]''': contains the WML actions to be executed when the menu item is selected. Again, the WML variables ''$x1'' and ''$y1'' will point to the location on which the context menu was invoked on.
** '''delayed_variable_substitution ''' (boolean yes|no, default: yes): If no, forces a variable substitution run onto the wml included in this [command] block. Use this, if you want variables which are to substitute to get the values they have at execution time of the event where this set_menu_item appears. Other than that, they get the values they have at invocation time of the menu item.
* '''image''': image shown next to the menu item, defaults to "buttons/WML-custom.png"

== [clear_menu_item] ==

Removes a menu item from the scenario.
Normally menu items are, including all their defining wml, automatically carried over between scenarios. This tag prevents this. (The behavior is comparable to set_variable/clear_variable).
* '''id''': (string): id of the menu item to clear. Can be a comma-separated list.

== Other interface tags ==

The following tags are also action tags:

=== [change_theme] ===

{{DevFeature1.13|8}}

Change the current interface theme.

* '''theme''': The ID of the new theme. Use <code>theme=</code> (empty key) to switch back to the theme that the player has selected in Preferences. On <b>1.14.2</b> and later it is also possible to omit the key entirely to achieve the same effect (on previous versions this will crash the Lua engine).

=== [item] ===
Makes a graphical item appear on a certain hex. Note this only places the graphics for an item. It does not make the item do anything. Use a moveto event to make moving onto the item do something. <tt>''('''Hint:''' There are a number of predefined items that are used in various campaigns that you can make use of. You can find [http://www.wesnoth.org/macro-reference.xhtml#file:items.cfg a list of them] if you look into the items.cfg file in the wesnoth install directory (under /data/core/macros).)''</tt>
* '''x''', '''y''': the location to place the item. (only for [event][item]: full [[StandardLocationFilter|SLF]] support)
* '''image''': the image (in ''images/'' as .png) to place on the hex. This image is aligned with the top-left of the hex (which is 72 pixels wide and 72 pixels tall). It is drawn underneath units. ''('''Hint:''' If using an image smaller than 72x72, then it might be useful to [[ImagePathFunctions#Blit_Function|BLIT]] the image onto <tt>misc/blank-hex.png</tt> (a blank 72x72 image).)''
* '''halo''': an image to place centered on the hex. It is drawn on top of units. Use this instead of ''image'' if the image is bigger than the hex or if you want to animate an image (https://github.com/wesnoth/wesnoth/issues/1219).
* '''name''' an id that can be used to remove the item.
''Example (where the integer after the colon is the duration of each frame or square bracket expansion as per AnimationWML is used): halo=scenery/fire1.png:100,scenery/fire2.png:100,scenery/fire3.png:100,scenery/fire4.png:100,scenery/fire5.png:100,scenery/fire6.png:100,scenery/fire7.png:100,scenery/fire8.png:100''
or equivalently (requires Wesnoth 1.11.2+):
''halo=scenery/fire[1~8].png:100''
* '''team_name''': name of the team for which the item is to be displayed (hidden for others). For multiple teams just put all the names in one string, for example separated by commas. {{DevFeature1.15|0}} In 1.14 the '''[side]team_name''' attribute was expected to be a substring of this '''team_name'''. In 1.15 both are expected to be comma-separated lists of names and the item is visible if the lists intersect. ([[https://github.com/wesnoth/wesnoth/pull/3533|#3533]])
* '''visible_in_fog''': whether the item should be visible through fog or not. Default yes.
* '''redraw''': (boolean yes|no, default: yes): If no, disables implicit calls to [[InterfaceActionsWML#.5Bredraw.5D|[redraw]]] when placing the items.
* '''[filter_team]''': {{DevFeature1.15|0}} A [[StandardSideFilter]]. Set '''team_name''' to the union of all '''[side]team_name''' attributes of all sides that match the SSF. ([[https://github.com/wesnoth/wesnoth/pull/3533|#3533]])
* {{DevFeature1.15|0}} If both '''team_name''' and '''[filter_team]''' are set, '''team_name''' is ignored.

=== [remove_item] ===
Removes any graphical items on a given hex.
* [[StandardLocationFilter]]: the hexes to remove items from
* '''image''': if specified, only removes the given item if one of its 'image', 'halo' or 'name' attributes is exactly this value. (for 'halo' and 'image' this in particular means that the image name must include any [[ImagePathFunctions|image path functions]] appended to the original image name.)

=== [print] ===
Displays a message across the screen. The message will disappear after a certain time, or when another [print] tag is encountered.
* '''text''': (translatable) the text to display. Can be an empty string to remove a previous message without showing a new one.
* '''size''': (default=12) the pointsize of the font to use
* '''duration''': the length of time to display the text for.
** (Before 1.15.4) This is measured in the number of 'frames', and the default is 50. A frame in Wesnoth is usually displayed for around 30ms.
** {{DevFeature1.15|4}} This is measured in milliseconds. Don't use the default value, because it's a mere 50ms.
** {{DevFeature1.15|14}} The default is 5000 milliseconds.
** {{DevFeature1.15|14}} The string '''unlimited''' displays the text until it's removed by another [print] tag.
* '''color''': (default '''0,0,0''') three comma-separated values giving the red, green and blue values (0-255).
* '''red''', '''green''', '''blue''': deprecated, use color=0,0,0 instead.

=== [move_unit_fake] ===
Moves an image of a unit along a certain path on the map. The path does not need to be a continuous list of adjacent hexes, so for example only the start and end points can be given, in which case the straightest line between those points will be calculated and used.
* '''type''': the type of the unit whose image to use
* '''x''': a comma-separated list of x locations to move along
* '''y''': a comma-separated list of y locations to move along (x and y values are matched pairs)
* '''side''': the side of the fake unit, used for team-coloring the fake unit
* '''gender''': the gender of the fake unit. Example: gender=female
* '''variation''': the variation of the fake unit. Example: variation=undead
* '''image_mods''': [[ImagePathFunctions|image path functions]] sequence to be applied on the fake unit.
* '''force_scroll''': Whether to scroll the map or not even when [[#.5Block_view.5D|[lock_view]]] is in effect or ''Follow Unit Actions'' is disabled in ''Advanced Preferences''. Defaults to ''yes'' starting with version '''1.11.6'''; the attribute did not exist in previous versions and this action behaved as if ''no'' was passed instead.

=== [move_units_fake] ===
moves multiple images of units along paths on the map. These units are moved in lockstep.
* '''force_scroll''': {{DevFeature1.15|0}} Has the same meaning as in [move_unit_fake] but a different default.
* '''[fake_unit]''': A fake unit to move
** '''type''': the type of unit whose image to use
** '''x''': a comma-separated list of x locations to move along
** '''y''': a comma-separated list of y locations to move along (x and y values are matched pairs)
** '''side''': the side of the fake unit, used for team-coloring the fake unit
** '''skip_steps''': the number of steps to skip before this unit starts moving

=== [hide_unit] ===
Temporarily prevents the engine from displaying the given unit. The unit does not become invisible, as it would be with the '''[hides]''' ability; it is still the same plain unit, but without an image. Useful in conjunction with '''[move_unit_fake]''': to move a leader unit into position on-screen. Until 1.8 each '''[hide_unit]''' tag only hides one unit.
* [[StandardUnitFilter]]: All matching units will be hidden

=== [unhide_unit] ===
Stops the currently hidden units from being hidden.
* [[StandardUnitFilter]]: Only the matching units will be unhidden

=== [lock_view] ===
Locks gamemap view scrolling for human players, so they cannot scroll the gamemap view until it is unlocked. WML or Lua actions such as '''[scroll_to]''' will continue to work normally, as they ignore this restriction; the locked/unlocked state is preserved when saving the current game.

This feature is generally intended to be used in cutscenes to prevent the player scrolling away from scripted actions.

{{DevFeature1.13|8}} This now also blocks the player from zooming the gamemap view. WML or Lua zoom will continue to work normally.

=== [unlock_view] ===
Unlocks gamemap view scrolling for human players.

=== [scroll] ===
Scroll a certain number of pixels in a given direction. Useful for earthquake/shaking effects.
* '''x''', '''y''': the number of pixels to scroll along the x and y axis
* '''side''': the side or sides for which this should happen. By default, the [scroll] happens for everyone.
* '''[filter_side]''': a [[StandardSideFilter]] to select the sides for which this should happen. By default, the [scroll] happens for everyone.

=== [scroll_to] ===
Scroll to a given hex
* [[StandardLocationFilter]], do not use a [filter_location] sub-tag. If more than one location matches the filter, only the first matching location will be used.
* '''check_fogged''': whether to scroll even to locations covered in fog or shroud. Possible values ''yes'' (don't scroll to fog) and ''no'' (scroll even to fog), with ''no'' as the default.
* '''immediate''': whether to instantly warp to the target hex regardless of the scroll speed setting in Preferences (defaults to ''no'').
* '''highlight''': {{DevFeature1.13|5}} Whether to highlight the hex being scrolled to (defaults to ''no'').
* '''side''': the side or sides for which this should happen. By default, the [scroll_to] happens for everyone.
* '''[filter_side]''': a [[StandardSideFilter]] to select the sides for which this should happen. By default, the [scroll_to] happens for everyone.

=== [scroll_to_unit] ===
Scroll to a given unit
* [[StandardUnitFilter]]; do not use a [filter] subtag.
* '''check_fogged''': whether to scroll even to locations covered in fog or shroud. Possible values ''yes'' (don't scroll to fog) and ''no'' (scroll even to fog), with ''no'' as the default.
* '''immediate''': whether to instantly warp to the target hex regardless of the scroll speed setting in Preferences (defaults to ''no'').
* '''highlight''': {{DevFeature1.13|5}} Whether to highlight the hex the unit is on (defaults to ''no'').
* '''for_side''': the side or sides for which this should happen. By default, the [scroll_to_unit] happens for everyone.
* '''[for_side]''': a [[StandardSideFilter]] to select the sides for which this should happen. By default, the [scroll_to_unit] happens for everyone.

=== [select_unit] ===
Selects a given unit.
* [[StandardUnitFilter]]: The first unit found will be selected.
* '''fire_event''': whether a ''select'' event should be triggered or not (def. ''no''). (Note that select events aren't multiplayer save.)
* '''highlight''': whether the unit's current hex should be highlighted (def. ''yes'').

'''Note:''' fire_event does not appear to work in 1.14 or 1.16.

=== [sound]===
Plays a sound
* '''name''': the filename of the sound to play (in ''sounds/'' as .wav or .ogg). This can be a comma-separated list, from which one sound will be chosen randomly.
* '''repeat''': repeats the sound for a specified additional number of times (default=0)

=== [sound_source] ===
Creates a sound source. "Sound sources" is a general name for a mechanism which makes possible for map elements to emit sounds according to some rules, where "map elements" can be specific locations or terrain types. For now, only sound sources tied to locations are supported.
* '''id''': a unique identification key of the sound source
* '''sounds''': a list of comma separated, randomly played sounds associated with the sound source
* '''delay''': a numerical value (in milliseconds) of the minimal delay between two playbacks of the source's sound if the source remains visible on the screen; if one scrolls out and back in, the source will be considered as ready to play
* '''chance''': a percentage (a value from 0 to 100) describing the chance of the source being activated every second after the delay has passed or when the source's location appears on the screen (note that it cannot play more than one file at the same time)
* '''check_fogged''': possible values ''yes'' and ''no'' - ''yes'' means the source will not play if its locations are fogged
* '''check_shrouded''': possible values ''yes'' and ''no'' - ''yes'' means the source will not play if its locations are shrouded
* '''x,y''': similar to x,y as found in a [[StandardLocationFilter]], these are the locations associated with the sound source
* '''fade_range''' (default = 3): distance in hexes that determines a "circular" area around the one specified by '''full_range''' where sound volume fades out linearly
* '''full_range''' (default = 14): distance in hexes that determines a "circular" area where source plays with full volume, relative to screen center
* '''loop''': number of times a sound sample should be looped if it stays visible. -1 means infinite (~65000)

=== [story] ===
{{DevFeature1.13|8}}

Shows the story screen.
* '''title''': Default title used if a part does not specify one — unlike the intro storyscreen, the scenario name is not used as a default title.
* '''[part]''', '''[if]''', '''[switch]''', '''[wml_message]''', '''[deprecated_message]''' : See [[IntroWML]].

=== [remove_sound_source] ===
Removes a previously defined sound source.
* '''id''': the identification key of the sound source to remove

=== [music] ===
Switches to playing different music
* '''name''': the filename of the music to play (in ''music/'' as .ogg)
* see [[MusicListWML]] for the correct syntax

=== [volume] ===
Changes the game volume to a percent of the preferences volume for the game being played. Values can go from 0 to 100:
* '''music''': Changes the music volume.
* '''sound''': Changes the sound volume.

=== [color_adjust] ===
Adjust the color tint of terrain, by adjusting time-of-day coloring.
* '''red''', '''green''', '''blue''': values from -255 to 255, the amount to tint by for each color

=== [screen_fade] ===
{{DevFeature1.17|6}}

Overlay the game display with the given color, fading over the specified duration. This can be used for screen fade effects.
* '''red''', '''green''', '''blue''': values from 0 to 255, the final overlay color (defaults to 0,0,0)
* '''alpha''': value from 0 to 255, the strength of the effect. 0 means no effect and can be used to fade in. 255 means fully opaque and can be used to fully fade out to the given color. Intermediate values will end up with a partial overlay tint on the game screen.
* '''duration''': the length of time it will take to complete the fade, in milliseconds. If 0 the effect is immediate.

=== [delay] ===
Pauses the game.
* '''time''': the time to pause in milliseconds
* '''accelerate ''' (boolean yes|no, default no): {{DevFeature1.13|0}} whether the delay is affected by acceleration. When [delay] is used to make an animation, this should be set to yes so that your animation matches the ones generated by the game.

=== [redraw] ===
Redraws the screen (this normally isn't done during events, although some of the other interface actions cause the screen or parts of it to be redrawn).
* '''clear_shroud''' (boolean yes|no, default no): If yes, clears fog and shroud around existing units. Useful if you, for example, spawn friendly units in the middle of an event and want the shroud to update accordingly (otherwise units that spawn inside fog would remain invisible for the duration of the event, since the fog would not automatically get cleared around them).
* '''[[StandardSideFilter]]''': the sides for which to recalculate fog and shroud.
* '''side''': If used (forces clear_shroud=yes), clears fog and shroud for that side.

=== [unit_overlay] ===
Sets an image that will be drawn over a particular unit, and follow it around
* [[StandardUnitFilter]]: All matching units will get the overlay (do not use [filter])
* '''image''': the image to place on the unit
* '''object_id''': object id to use, defaults to the '''image''' key with an "overlay_" prefix; this allows using [[DirectActionsWML#.5Bremove_object.5D|'''[remove_object]''']]
* '''duration''': object duration

=== [remove_unit_overlay] ===
Removes a particular overlayed image from a unit
* [[StandardUnitFilter]]: The overlay will get removed from all matching units (do not use [filter])
* '''image''': the image to remove from the unit
* '''object_id''': object id to use
Using [[DirectActionsWML#.5Bremove_object.5D|'''[remove_object]''']] is also possible, see https://github.com/wesnoth/wesnoth/commit/26c2f941f2bcdd89528481e114c0375ad2a46271

=== [animate_unit] ===
Uses an animation of a unit to animate it on screen (if the unit has the corresponding animation).
* '''flag''': The key to find the custom animation in the unit description (see the '''[extra_anim]''' description in [[AnimationWML]]). Standard animations can be triggered with the following keywords: ''leading recruited standing idling levelout levelin healing healed poisoned movement defend attack death victory pre_teleport post_teleport''
* '''[filter]''' with a [[StandardUnitFilter]] as argument, see [[FilterWML]]. By default, the unit at the event location will be animated. You can use this tag to choose any other unit to animate.
* '''[primary_attack]''': If this tag is not present, the filter for animation will be triggered with no attack. If it is here, all attacks from the unit will be filtered, and a matching one will be used to filter the animation. Takes a weapon filter as argument, see [[FilterWML]].
* '''[secondary_attack]''': Similar to '''[primary_attack]'''. May be needed to trigger a defense animation correctly, if there are more than one animations available for the defending unit.
* '''hits''': yes/no/hit/miss/kill: which according variation of a attack/defense animation shall be chosen (required)
* '''text''': a text to hover during the animation
* '''male_text''', '''female_text''': {{DevFeature1.13|2}} (translatable) gender-specific versions of the above
* '''red''': red value for the text color (0-255)
* '''green''': green value for the text color
* '''blue''': blue value for the text color
* '''with_bars''': yes/no: whether to display the status bars during the animation (e.g. the hitpoint bar)
* '''[animate]''': a sub block with the same syntax as '''[animate_unit]''' except that the '''[filter]''' block is mandatory to find the unit. This block will find and animate another unit simultaneously.
* '''[facing]''': a [[StandardLocationFilter]] specifying what hex the unit should be facing when animated

=== [label] ===
Places a label on the map.
* '''x''', '''y''': the location of the label. {{DevFeature1.13|1}} (only for [event][label]: full [[StandardLocationFilter|SLF]] support)
* '''text''': what the label should say. If you put an empty string <code>""</code> as an argument, the label will be completely removed. Use this method if you want to remove a specific label from any location.
* '''team_name''': if specified, the label will only be visible to the given team.
* '''color''': color of the label. The format is r,g,b; r, g and b are numbers between 0 and 255.
* '''visible_in_fog''': whether the label should be visible through fog or not. Default yes.
* '''visible_in_shroud''': whether the label should be visible through shroud or not. Default no.
* '''immutable''': whether this label is protected from being removed or changed by players. Default yes.
* '''category''': the Show/Hide Labels dialog allows showing/hiding all labels of a given category by toggling a checkbox.
* '''tooltip''': A tooltip visible when mouseovering the hex the label is on
* '''side''': the number of the side that placed the label. Can be 0 for labels placed by WML.

=== [floating_text]===
Floats text (similar to the damage and healing numbers) on the given locations.
* [[StandardLocationFilter]]: the text will be floated on all matching locations simultaneously (do not use [filter] unless you intend to match one or more units).
* '''text''': the text to display.

The default text color is <span style="color: #6b8cff;">'''#6b8cff'''</span>. To change the color, use [[#Formatting|Pango markup]]. For example:

<pre>
# Float some golden yellow text at 20,20.
[floating_text]
x,y=20,20
text="<span color='#cccc33'>" + _ "Your text here" + "</span>"
[/floating_text]
</pre>

=== [deprecated_message] ===
Shows a deprecated message in the message area, this feature is only intended to be used to warn about deprecated macros in mainline. The message is not translatable.
* '''message''': the message to show.
* '''level''': {{DevFeature1.13|10}} The deprecation level, a number from 1 to 3.
* '''what''': {{DevFeature1.13|10}} The name of the thing being deprecated. Use this instead of '''message''' if possible; a stock message will be generated from it. Use '''message''' only if more information is required; it will be appended to the stock message. This should not be translatable
* '''version''': {{DevFeature1.13|10}} For deprecation levels 2 and 3, this indicates the version in which the feature could be removed. It does ''not'' indicate the version in which it became deprecated.

The meanings of the deprecation levels are as follows:

# Deprecated, but will only be removed if absolutely necessary. The '''version''' key is ignored.
# It will be removed no earlier than a specified version.
# It will be removed in the next stable version
# It has already been removed, leaving just a stub to inform users of how to update their code.

Note that as of 1.13.11, deprecation messages show only in the log, not in the chat message area. The '''message''' can be translatable, but does not need to be.

=== [wml_message] ===
Outputs a message to Wesnoth's console output. Intended for campaign designers to output silent text to the console, without annoying the player; then, that text might contain information useful for later bug-reporting. The log domain for it is '''wml''', and the '''debug/dbg''' log level is available for use with the '''logger''' attribute. Depending on the current log level ('''error''' by default), which may be changed with the in-game :log command, or the --log-<level>=wml command line switch, the messages are echoed to the in-game chat.
* '''message''': the message to show.
* '''logger''': the Wesnoth engine output logger that should catch the text; this might be 'err' (the errors log level), 'warn'/'wrn' (the warnings log level) or anything else (the information log level). Not all information will be displayed depending on the log level chosen when starting Wesnoth.

Note: As of 1.9.4/1.9.5 (r48805) the following "loggers" should work: If in [wml_message]: err/error, warn/wrn/warning, debug/dbg; using the :log command: Only the long forms error, warning, info and debug (this part gathered by trying rather than source inspecting). The long forms are most likely also the only ones working when starting wesnoth with --log-<level>=wml.
For log level warning or error (as during normal play), only wml_messages with logger error or warning display (for both). With logger info or debug, additionally wml_messages with logger info or debug display (for both).

=== [test_condition] ===

{{DevFeature1.13|2}}

Evaluates the contained conditional tags. If they evaluate to the expected value, it prints out a message to the console explaining which part of the condition caused this result in a way similar to [wml_message]. This can be used if your conditional test is failing and you're not sure why.

* '''result''': Whether you expect the conditions to fail or succeed. If no (the default), a message will be printed if the conditional tags fail. If yes, a message will instead be printed if the conditional tags pass.
* '''logger''': Same as for [wml_message]. Defaults to "warning".

=== [open_help] ===
Opens the in-game help.
* '''topic''': the id of the topic to open

Examples of ids:
* unit_Mage
* unit_Dark Adept
* weaponspecial_charge
* terrain_human_castle

The engine will print the topic ids if run from the command line with the ''--log-debug=help'' option.

=== [show_objectives] ===
refreshes the objectives defined by [objectives] and its [show_if] tags, and displays them. (It is also called whenever the user explicitly asks for the objectives; this matters only if the tag was overridden by a [[LuaWML#register_wml_action|Lua]] script.)
* '''side''': the side to show the objectives. If not set, all sides are used.
* '''[[StandardSideFilter]]''' tags and keys: Tag affects the matching sides instead of just all or the one given by the integer value of the side= key.

=== [chat] ===
Displays a message in the chat area, not visible for observers. Alternative unconditionally visible for everyone: [[LuaWML:Display#wesnoth.message]]. {{DevFeature1.13|9}} can be visible for observers.
* '''speaker''': (default="WML") A string for the name of the sender of the message.
* '''message''': The message that should be displayed.
* '''observable''' (boolean yes|no, default yes): {{DevFeature1.13|9}} Whether the message is displayed for observers.
* '''[[StandardSideFilter]]''' tags and keys as argument; if the same client controls multiple sides that match, then the message will only be displayed once.

=== [zoom] ===

{{DevFeature1.13|8}}

Changes the zoom level of the map.

* '''factor''': The new zoom factor, measured as a multiple of the base zoom.
* '''relative''': If yes, zoom relative to current zoom level. Otherwise, set the absolute zoom level. Default no.

== Useful Macros ==
There are some predefined macros that you find useful for interface actions. You can find a complete list along with a detailed explanation of how they work [http://www.wesnoth.org/macro-reference.xhtml here].
* '''{HIGHLIGHT_UNIT}''' Highlight a unit on the map. Use this to show important units
* '''{HIGHLIGHT_IMAGE}''' Places and highlights an image on the map. Use this to show important items or locations
* '''{SET_IMAGE}''' Places an image on the map which has no other function.
* '''{QUAKE <soundfile>}''' Creates a tremor-like screenshake and plays <soundfile>. For example, '''{QUAKE (rumble.ogg)}'''.
* '''{FLASH_WHITE}''' Flash the screen white momentarily. You can also replace WHITE with RED, BLUE or GREEN for a different colour.

== See Also ==
* [[DirectActionsWML]]
* [[InternalActionsWML]]
* [[EventWML]]
* [[ReferenceWML]]

[[Category: WML Reference]]
[[Category: ActionsWML]]

GermanTranslationUnitNames

2023-05-09T22:11:04Z

Spixi: typo und Korrektur USK

== Hinweise zur Übersetzung ==

Auf dieser Seite fassen wir alle wichtigen Informationen zusammen, so dass inoffizielle Erweiterungen und der offizielle Inhalt des Spiels weitestgehend synchron sind. Hier findet ihr die deutschen Namen der Einheiten und Informationen, die für sie wichtig sind, ebenso wie bedeutende Orte oder gebräuchliche Formulierungen, die fast in jeder Kampagne vorkommen.

=== Generelles ===

Die Übersetzung sollte vom Stil her der Sprache des Mittelalters entsprechen. Das bedeutet beispielsweise, dass man statt "Sie" "Ihr" verwendet. Zudem müsst und solltet ihr euch nicht strikt an das Original halten. Wenn euch eine Formulierung einfällt, die euch besser gefällt, solltet ihr diese auch verwenden, solange evtl. wichtige Informationen erhalten bleiben.

=== Zeichensetzung und Ähnliches ===

Es werden die typografisch richtigen Satzzeichen verwendet:

* Anführungszeichen: »Text«, nicht "Text" oder 'Text'
* Bindestrich: normales Minuszeichen
* Gedankenstrich: "Text – Einschub", nicht "Text - Einschub" oder "Text -- Einschub" (Halb- statt Viertel-Geviertstrich)
** Im Englischen wird stattdessen der Geviertstrich benutzt (auch bekannt als "em dash", so lang wie ein m). Dabei werden dort keine Leerzeichen davor oder danach gesetzt. Im Deutschen werden um den Halbgeviertstrich (auch "en dash") Leerzeichen eingefügt.
** Für die passende Tastenkombination, siehe hier: http://de.wikipedia.org/wiki/Halbgeviertstrich#Eingabe_bei_Computersystemen_und_-programmen
* Apostroph: "Geht’s", nicht "Geht's".
* Anrede (groß- bzw. kleingeschriebene Personal-/Possessivpronomen):
** Unterhaltung im Spiel - je nach Situation und Charakter:
*** Kleinschreibung beim Duzen (richtig: "Meiner Treu, du bist ein Lump!", falsch: "Meiner Treu, Du bist ein Lump!").
*** Großschreibung beim Ihrzen (richtig: "Meiner Treu, Ihr seid ein Lump!", falsch: "Meiner Treu, ihr seid ein Lump!").
*** Ob geduzt oder geihrzt wird, sollte für die einzelnen Charaktere über die Kampagne hinweg konsistent sein.
** Wird der Spieler angesprochen:
*** Ihrzen + Großschreibung (richtig: "Bewegt Euren Anführer über die Brücke.", falsch: "Bewegt euren Anrührer über die Brücke.").
*** Niemals Siezen!
* Die vollständige (englische) Typografie-Anleitung gibt es [[Typography_Style_Guide|hier]]; Bash-Scripts zum automatisierten Anpassen der Sonderzeichen [[TranslatorShellscript|hier]].
* Das Dach"^" ist eine Übersetzerhilfe: Alles vor diesem Zeichen wird in der Übersetzung ignoriert. Beispiel: "rod of justice^Take it!" – Der zu übersetzende String heißt eigentlich nur "Take it". Damit der Bezug von "it" klar wird, spezifiziert der Programmierer, dass es sich auf "rod of justice" bezieht. Die Übersetzung könnte also sein: "Schnapp dir das Ding!".
* $Variablen müssen im übersetzten Text genau gleich sein.
* Bei formatiertem Text (z.B. <italic>text='Battle for Wesnoth'</italic>) handelt es sich um Pango Markup. Achtet darauf, dass es für jedes öffnende < bzw. ' auch ein schließendes gibt, da solche Fehler oft schwer zu finden sind. Auch zusätzliche Leerzeichen sind innerhalb einer solchen Auszeichnung beim Übersetzen nicht erlaubt – vergesst aber nicht, dass außerhalb davon zur Worttrennung i.d.R. eins dazugehört.

== Mainline (offizieller Inhalt des Spiels) ==

=== Einheiten ===

Details zum letzten Namensüberarbeitungsprojekt finden sich [[GermanTranslationNameRework|hier]].
Die Übersetzungen wurden in die Entwicklerversion eingearbeitet.

Damit niemand 'Goblin' mit 'Goblin' übersetzt oder 'Wose' mit 'Baummensch', orientiert euch bitte an folgenden Übersichten:

[http://units.wesnoth.org/trunk/mainline/de_DE/mainline.html Mainline]

[http://units.wesnoth.org/trunk/mainline/de_DE/Sceptre_of_Fire.html Das Zepter des Feuers]

[http://units.wesnoth.org/trunk/mainline/de_DE/Delfadors_Memoirs.html Delfadors Memoiren]

[http://units.wesnoth.org/trunk/mainline/de_DE/The_Rise_of_Wesnoth.html Der Aufstieg Wesnoths]

[http://units.wesnoth.org/trunk/mainline/de_DE/The_Hammer_of_Thursagan.html Der Hammer von Thursagan]

[http://units.wesnoth.org/trunk/mainline/de_DE/Heir_To_The_Throne.html Der Thronerbe]

[http://units.wesnoth.org/trunk/mainline/de_DE/Descent_into_Darkness.html Die dunklen Künste]

[https://units.wesnoth.org/trunk/mainline/de_DE/Two_Brothers.html Die Geschichte zweier Brüder]

[http://units.wesnoth.org/trunk/mainline/de_DE/LOW.html Die Legende von Wesmere]

[http://units.wesnoth.org/trunk/mainline/de_DE/The_South_Guard.html Die Südwacht]

[https://units.wesnoth.org/trunk/mainline/de_DE/An_Orcish_Incursion.html Ein Einmarsch der Orks]

[http://units.wesnoth.org/trunk/mainline/de_DE/Liberty.html Freiheit]

[https://units.wesnoth.org/trunk/mainline/de_DE/Secrets%20of%20the%20Ancients.html Geheimnisse der Alten]

[http://units.wesnoth.org/trunk/mainline/de_DE/Eastern_Invasion.html Invasion der Finsternis]

[http://units.wesnoth.org/trunk/mainline/de_DE/Son_of_the_Black-Eye.html Schwarzauges Sohn]

[http://units.wesnoth.org/trunk/mainline/de_DE/Dead_Water.html Stille Wasser]

[http://units.wesnoth.org/trunk/mainline/de_DE/Under_the_Burning_Suns.html Unter brennenden Sonnen]

[http://units.wesnoth.org/trunk/mainline/de_DE/Northern_Rebirth.html Wiedergeburt des Nordens]

=== Gruppierungen ===
==== Rassen / Ethnien ====

{| class="wikitable"
| style="width: 300px;" | Drakes
| style="width: 300px;" | Draken
|-
| Dunefolk
| Menschen (Dünenvolk)
|-
| Dwarves
| Zwerge
|-
| Elves
| Elfen
|-
| Goblins
| Kobolde
|-
| Humans
| Menschen (Wesnoth)
|-
| Khalifate*
| Menschen (Kalifat)
|-
| Merfolk, Mermen**
| Meervolk (Rasse)
Wasserleute, -männer/-frauen (Dialoge etc.)
|-
| Mechanical
| Kriegsgerät
|-
| Monsters
| Monster
|-
| Nagas
| Nagas
|-
| Ogres
| Oger
|-
| Orcs
| Orks
|-
| Saurians / Lizards
| Saurianer / Echsen
|-
| Trolls
| Trolle
|-
| Undead
| Untote
|-
| Woses
| Waldschrate
|}

'''*''' Mit Wesnoth 1.14 wurden die 'Khalifate' in 'Dunefolk' umbenannt.<br />
'''**''' Im englischen Text wird als Bezeichnung für die Rasse "Merfolk" statt "Mermen" bevorzugt, aber siehe: [https://github.com/wesnoth/wesnoth/issues/2940 Issue 2940].

==== Fraktionen ====
{| class="wikitable"
| style="width: 300px;" | Alliance of Darkness
| style="width: 300px;" | Allianz der Finsternis
|-
| Alliance of Light
| Allianz des Lichtes
|-
| Drakes
| Draken
|-
| Knalgan Alliance
| Knalga Allianz
|-
| Loyalists
| Loyalisten
|-
| Northerners
| Nordmannen
|-
| Rebels
| Rebellen
|-
| Undead
| Untote
|}

=== Bedeutende Orte ===
Details zur Geographie von Wesnoth sind auf der Seite [[WesnothGeography]] zu finden (nicht auf neustem Stand).
==== Gewässer / Inseln ====
{| class="wikitable"
| style="width: 300px;" | Arkan-thoria
| style="width: 300px;" | Arkan-thoria (Fluss)
|-
| Bay of Pearls
| Perlenbucht
|-
| Bilheld (isle)
| Bilheld (Insel)
|-
| Black River
| Schwarzer Fluss
|-
| Great River
| Großer Fluss
|-
| Green Isle
| Grüne Insel
|-
| Island Vrug
| Insel von Vrug
|-
| Isle of Alduin
| Insel Alduin
|-
| Lake Aelin
| Aelin-See
|-
| River Aethen
| Aethen (Fluss)
|-
| River Bork
| Bork (Fluss)
|-
| River Listra
| Listra (Fluss)
|-
| River Oumph
| Oumph (Fluss)
|-
| River Weldyn
| Weldyn (Fluss)
|-
| Shimmering Isle
| Insel des Glanzes
|-
| Sleepless Sea
| Ruheloses Meer
|-
| The Far Sea
| Das Ferne Meer
|-
| The Ford of Abez
| Furt von Abez
|-
| The Great Ocean
| Der Große Ozean
|-
| The Lake Vrug
| Vrugsee
|-
| The Three Sisters (isle)
| Die Drei Schwestern (Insel)
|}

==== Wälder ====
{| class="wikitable"
| style="width: 300px;" | Aethenwood
| style="width: 300px;" | Aethenwälder
|-
| Black Forest
| Schwarzer Wald
|-
| Forest of Thelien
| Thelien-Wald
|-
| Glyn's Forest
| Glyns Gehölz
|-
| Greenwood
| Grüner Hain
|-
| Grey Woods
| Grauer Wald
|-
| Lintanir Forest
| Lintanir-Forst
|-
| Silent Forest
| Stiller Wald
|-
| Southwood
| Südwald
|-
| Wesmere Forest
| Wesmerewälder
|-
| Oldwood (Green Isle)
| Alter Wald (Grüne Insel)
|}

==== Gebirge / Höhlen / Täler ====
{| class="wikitable"
| style="width: 300px;" | Broken Mountains (Green Isle)
| style="width: 300px;" | Splittergebirge (Grüne Insel)
|-
| Brown Hills
| Braune Hügel
|-
| Caverns of Chaincolt
| Chaincolt-Höhlen
|-
| Caves of Knalga
| Knalga
|-
| Dulatus Hills
| Dulatushügel
|-
| Estmark Hills
| Ostmarken
|-
| Gryphon Mt.
| Berg der Greifen
|-
| Heart Mountains
| Erzgebirge
|-
| Mountains of Dorth
| Dorth-Gebirge
|-
| Mountains of Haag
| Haager Berge
|-
| Mountains of Peril
| Tückische Gipfel
|-
| Mourned Hills
| Trauerhügel
|-
| Shorbear caves
| Shorbear Höhlen
|-
| The Vale (of Blossoming Trees)
| Tal der blühenden Bäume
|}

==== Sümpfe / Moore ====
{| class="wikitable"
| style="width: 300px;" | Bitter Swamp
| style="width: 300px;" | Sumpf der Tränen
|-
| Black Marshes
| Schwarzes Moor
|-
| Swamp of Dread
| Sumpf der Furcht
|-
| Swamp of Esten (Green Isle)
| Sümpfe von Esten (Grüne Insel)
|}

=== Wüsten / Ebenen ===
{| class="wikitable"
| style="width: 300px;" | Barren Plains
| style="width: 300px;" | Karge Steppe
|-
| Desert of Death
| Todeswüste
|-
| Frosty Wastes
| Frostwüste
|-
| Horse Plains
| Ebene der Pferde
|-
| North Plains
| Nördlichen Ebenen
|}

==== Städte / Dörfer / Festen ====
{| class="wikitable"
| style="width: 300px;" | Blackmore (Green Isle)
| style="width: 300px;" | Mortingen (Grüne Insel)
|-
| Blackwater Port
| Schwarzwasserhafen
|-
| Clearwater Port (Green Isle)
| Klarwasserhafen (Grüne Insel)
|-
| Dwarven Doors
| Zwergenpforte
|-
| Elensefar
| Elensefar
|-
| Dorest
| Dorest
|-
| Fort Kerlath
| Fort Kerlath
|-
| Fort Than
| Fort Than
|-
| Halstead
| Halstead (Festung)
|-
| Jeyvan's Haven (Green Isle)
| Jeyvans Rast (Grüne Insel)
|-
| Prestim
| Prestim
|-
| Saurgrath
| Saurgrath
|-
| Shorbear Hold
| Feste Shorbear
|-
| Soradoc
| Soradoc
|-
| Southbay (Green Isle)
| Südbucht (Grüne Insel)
|-
| Spellkeep
| Bannheim
|-
| Stormvale (Green Isle)
| Sturmtal (Grüne Insel)
|-
| Weldyn
| Weldyn
|}

==== Sonstige ====
{| class="wikitable"
| style="width: 300px;" | Estmark
| style="width: 300px;" | Ostmarken
|-
| Fallen Lich Point (Green Isle)
| Platz zum gefallenen Lich (Grüne Insel)
|-
| Irdya – the wide green world
| Irdya – die weite grüne Welt
|-
| Far North
| Weiter Norden
|-
| land of the Clans
| Lande der Sippen
|-
| Midlands (Green Isle)
| Mittellande (Grüne Insel)
|-
| Northlands
| Nordlande
|-
| old eastern mines
| östliche Minen
|-
| Southern / Northern Outpost
| Südlicher / Nördlicher Außenposten
|-
| the Great Continent
| der Große Kontinent
|}

=== Waffen und Gegenstände ===

==== Waffen ====
{| class="wikitable"
| style="width: 300px;" | axe
| style="width: 300px;" | Axt
|-
| ballista
| Balliste
|-
| baneblade
| Spektralklinge
|-
| battle axe
| Streitaxt
|-
| battle claws
| Kampfkralle
|-
| beak
| Schnabelhieb
|-
| buckler
| Rundschild
|-
| berserker frenzy
| Raserei
|-
| bite
| Biss
|-
| bow
| Bogen
|-
| chill tempest
| Schattenpfeile
|-
| chill wave
| Frostwelle
|-
| claws
| Klauen
|-
| cleaver
| Fleischerbeil
|-
| club
| Keule
|-
| crossbow
| Armbrust
|-
| crush
| Zermalmen
|-
| curse
| Fluch
|-
| dagger
| Dolch
|-
| dragonstaff
| Drachenstab
|-
| ensnare
| Zorn des Waldes
|-
| entangle
| Efeumantel
|-
| faerie fire
| Feenfeuer
|-
| faerie touch
| Feenhauch
|-
| fangs
| Fänge
|-
| fire claws
| Feuerklauen
|-
| fire breath
| Feueratem
|-
| fireball
| Feuerball
|-
| fist
| Faust
|-
| gossamer
| Spinnfäden
|-
| greatsword
| Krummschwert
|-
| halberd
| Hellebarde
|-
| hammer
| Hammer
|-
| hatchet
| Wurfbeil
|-
| ink
| Tinte
|-
| javelin
| Wurfspeer
|-
| jaw
| Kiefer
|-
| knife
| Messer
|-
| lance
| Lanze
|-
| lightbeam
| Heiliges Licht
|-
| lightning bolt
| Blitzschlag
|-
| longbow
| Langbogen
|-
| mace
| Streitkolben
|-
| missile
| Magiegeschoss
|-
| morning star
| Morgenstern
|-
| mud glob
| Schlammklumpen
|-
| naia touch
| Naias Berührung
|-
| net
| Netz
|-
| pike
| Pike
|-
| pincers
| Scheren
|-
| pitchfork
| Mistforke
|-
| plague staff
| Stab der Plagen
|-
| ram
| Mauerbrecher
|-
| runic hammer
| Runenhammer
|-
| sabre
| Säbel
|-
| scimitar
| Krummsäbel
|-
| shadow wave
| Schattenwelle
|-
| short sword
| Kurzschwert
|-
| slam
| Sturzflug
|-
| sling
| Schleuder
|-
| smash (Eyestalk)
| Rankenhieb (Augenranke)
|-
| spear
| Speer
|-
| staff
| Stab
|-
| sting
| Stachel
|-
| sword
| Schwert
|-
| tail
| Schwanz
|-
| tentacle
| Tentakel
|-
| thorns
| Dornen
|-
| throwing knives
| Wurfmesser
|-
| thunderstick
| Donnerstock
|-
| torch
| Fackel
|-
| touch
| Berührung
|-
| trident
| Dreizack
|-
| wail
| Klage
|-
| war blade
| Kriegsklinge
|-
| war talon
| Kriegsklaue
|-
| water spray
| Peitschende Gischt
|-
| web
| Netz
|}

==== Waffenfähigkeiten ====
{| class="wikitable"
| style="width: 300px;" | backstab
| style="width: 300px;" | Hinterlistiger Angriff
|-
| berserk
| Kampfrausch
|-
| charge
| Ansturm
|-
| daze
|
|-
| drains
| Lebensentzug
|-
| first strike
| Erstschlag
|-
| magical
| Magie
|-
| marksman
| Treffsicherheit
|-
| petrifies
| Versteinerung
|-
| plague
| Untote Plage
|-
| poison
| Gift
|-
| slows
| Verlangsamung
|-
| swarm
| Schwarm
|-
| shock
| Blitzangriff
|-
| stun
| Lähmung
|-
|}

==== Schadenstypen ====
{| class="wikitable"
| style="width: 300px;" | arcane
| style="width: 300px;" | Arkan
|-
| blade
| Klinge
|-
| cold
| Kälte
|-
| fire
| Feuer
|-
| impact
| Wucht
|-
| pierce
| Stich
|}

=== Gegenstände===
{| class="wikitable"
| style="width: 300px;" | Flaming Sword
| style="width: 300px;" | Flammenschwert
|-
| Holy Water
| Weihwasser
|-
| Poison
| Gift
|-
| Potion of Decay
| Trank des Verfalls
|-
| Potion of Healing
| Trank der Heilung
|-
| Potion of Strength
| Trank der Stärke
|-
| Ring of Regeneration
| Ring der Regeneration
|-
| Ring of Power
| Ring der Kraft
|-
| Ring of Slowness
| Ring der Langsamkeit
|-
| Rod of Justice
| Stab der Gerechtigkeit
|-
| Sceptre of Fire
| Zepter des Feuers / Feuerzepter
|-
| Staff of righteous Flame
| Stab aufflammender Gerechtigkeit
|-
| Staff of Swiftness
| Stab der Geschwindigkeit
|-
| Storm Trident
| Dreizack des Sturms
|-
| Void Armor
| Rüstung der Leere
|}

=== Charakteristiken, Fertigkeiten ===

==== Charakteristiken ====
{| class="wikitable"
| style="width: 300px;" | aged
| style="width: 300px;" | Gealtert
|-
| dextrous
| Geschickt
|-
| dim
| Tumb
|-
| elemental
| Elementar
|-
| fearless
| Furchtlos
|-
| leral
| Wild
|-
| healthy
| Vital
|-
| intelligent
| Intelligent
|-
| loyal
| Loyal
|-
| mechanical
| Mechanisch
|-
| quick
| Schnell
|-
| resilient
| Robust
|-
| slow
| Lahm
|-
| strong
| Kräftig
|-
| undead
| Untot
|-
| weak
| Schwächlich
|}

==== Fertigkeiten ====
{| class="wikitable"
| style="width: 300px;" | ambush
| style="width: 300px;" | Waldkenntnis
|-
| concealment
| Gassenwissen
|-
| cures
| Kurieren
|-
| feeding
| Kanibalismus
|-
| heals +X
| Heilen +x
|-
| illuminates
| Lichtaura
|-
| leadership
| Führungsqualitäten
|-
| nightstalk
| Schemen
|-
| regenerates
| Regeneration
|-
| skirmisher
| Plänkler
|-
| steadfast
| Unerschütterlich
|-
| submerge
| Abtauchen
|-
| teleport
| Teleportation
|-
| disengage
|
|-
| distract
| Ablenken
|-
| formation
|
|-
| initiative
| Kampfgespür
|-
| inspire
| Begeistern
|-
| support
|
|-
| teaching
|
|}

=== Gebräuchliche Formulierungen ===

==== Missionsziele ====
{| class="wikitable"
| style="width: 300px;" | Death of X (or Y)
| style="width: 300px;" | X (oder Y) fällt in der Schlacht
|-
| Turns run out
| Rundenlimit überschritten
|-
| Defeat all enemy leaders
| Besiegt alle gegnerischen Anführer
|-
| Move X to the signpost in the Y
| Führt X zum Wegweiser im Y
|-
| Move X to the sign
| Führt X zur Markierung
|-
| Early finish bonus
| Bonus für frühzeitiges Ende
|-
| Alternative objective
| Alternative Mission
|-
| Bonus objective
| Bonusmission
|-
| Optional (objective)
| Optional / Optionale Mission
|-
| Optional Scenario
| Optionales Szenario
|}

==== Schwierigkeitsgrade / Beschreibungen ====
{| class="wikitable"
| style="width: 300px;" | (Novice / Beginner level, xx scenarios.)
| style="width: 300px;" | (Einstufung: Einfach, xx Szenarien)
|-
| (Intermediate level, xx scenarios.)
| (Einstufung: Mittel, xx Szenarien)
|-
| (Expert level, xx scenarios.)
| (Einstufung: Schwierig, xx Szenarien)
|-
| Beginner
| Sehr einfach
|-
| Easy
| Einfach
|-
| Normal
| Normal
|-
| Challenging
| Herausfordernd
|-
| Difficult
| Schwierig
|-
| Nightmare
| Alptraum
|-
| X scenarios (X story-only / dialog-only)
| x Szenarien + x Erzählung / Dialog
|-
| All scenarios are playable, but there may be bugs or balancing issues
| Alle Szenarien sind spielbar, vereinzelt können aber Fehler auftreten. Auch die Abstimmung der Schwierigkeitsgrade ist noch nicht abgeschlossen.
|-
| rated PG-13 (Parental Guidance)
| USK ab 6 (Unterhaltungssoftware Selbstkontrolle)
|-
| This campaign contains mature themes, some of which may be unsuitable for children.
This campaign depicts explicit violence which may not be appropriate for younger children.
| In dieser Kampagne werden Gewaltszenen dargestellt, die besonders für Spieler im Kindesalter ungeeignet sind!
|}

==== Credits (Herausgeber, Mitarbeiter, Danksagung) ====
{| class="wikitable"
| style="width: 300px;" | And special thanks to everyone else who I forgot to mention.
| style="width: 300px;" | Und besonderen Dank an alle, die ich vergessen habe zu erwähnen.
|-
| Artwork Support
| Mitwirkung grafische Gestaltung
|-
| Artwork and Graphics Design
| Grafik
|-
| Author (of this campaign)
| Autor (der Kampagne)
|-
| Campaign Design
| Kampagnengestaltung
|-
| Campaign Epilog and Continuity
| Kampagnenepilog und -fortsetzung
|-
| Campaign Maintenance
| Betreuung
|-
| Co-author
| Mitautor
|-
| Code
| Programmierung / Kodierung
|-
| Completion, Porting and Maintenance
| Fertigstellung, Portierung und Betreuung
|-
| Conception and Original
| Design Konzeption
|-
| Contributions Images
| Beiträge Grafiken
|-
| Contributors
| Mitwirkende
|-
| Current Maintainer
| Betreuung
|-
| Custom AI Development
| Anpassung und Entwicklung KI
|-
| Forum Support and Feedback
| Support und Rückmeldung aus dem Forum
|-
| Miscellaneous
| Verschiedenes
|-
| Music Development
| Musikkomposition
|-
| Porting
| Anpassung an aktuelle BfW-Versionen / Portierung
|-
| Prose and Grammatical Assistance
| Prosatext und Sprachhilfe
|-
| Proofreading
| Korrekturlesen
|-
| Sprites and Portraits
| Grafikdateien und Portraits
|-
| Story Art
| Handlungsillustrierung
|-
| Story Development / Corrections
| Handlungsausarbeitung
|-
| Technical Adviser
| Technischer Berater
|-
| (Gameplay) Testing / Test Beta-Version
| Testspieler
|-
| Text Revision
| Textrevision
|-
| Translators / Translations
| Übersetzungen
|-
| Translation Assistance
| Übersetzungshilfe
|-
| Unit Sprites, Halo & Animation Art
| Grafikdateien, Lichteffekte und Animationen
|-
| WML / Code Contributors
| WML Code / Code-Beiträge
|-
| WML Assistance
| WML-Entwicklung
|}

==== Verschiedenes ====
{| class="wikitable"
| style="width: 300px;" | (whispered), (whispers)
| style="width: 300px;" | (geflüstert), (flüstert)
|-
| BW (Before Wesnoth)
| im Jahr x vor Wesnoth
|-
| YW (Years Wesnoth)
| im Jahre x Wesnoths (JW)
|-
| Lord / Lady
| Ehrenanrede für Titelträger des Hochadels:
Herr/Frau + Titel (Graf/Gräfin, Herzog, Baron(in) ...)
u. U. auch: Gebieter(in), Herrscher(in), Landes- / Stadtherr(in)
|-
| mylord, my lord, milord
| (gnädiger) Herr, mein Gebieter
|-
| mylady, my lady, dear lady, milady
| gnädige Dame, meine Herrin
|-
| Minister
| (Stadt)Ratsmitglied, Hofrat
|-
| AI (Artificial Intelligence)
| KI (Künstliche Intelligenz), computergesteuerte Akteure
|-
| AMLA (After Maximum Level Advancement)
| AMLA (Sonderbonus statt Stufenaufstieg)
|-
| campaign
| Kampagne
|-
| cutscene
| Zwischensequenz
|-
| era
| Epoche
|-
| faction
| Fraktion
|-
| level
| Spielabschnitt, Stufe
|-
| mission
| Mission, Aufgabe
|-
| MP (Multiplayer) mode
| Mehrspieler- / Koop-Modus
|-
| Multiplayerlobby
| Mehrspielerlobby
|-
| NPC (non-player character)
| Nicht-Spieler-Charakter (NSC), computergesteuerte Einheit
|-
| quest
| Auftrag, Suche, Jagd, Herausforderung
|-
| scenario
| Szenarium, Szenario, Partie, (Episode, Teil)
|-
| SP (single-player) mode
| Einzelspieler- / Solo-Modus
|-
| side
| Partei
|-
| team
| Allianz (Bei »Team« wäre nicht eindeutig ob Partei/Allianz)
|-
| Whiteboard
| Planungsmodus
|-
| WML (Wesnoth Markup Language)
| WML (Wesnoth Auszeichnungssprache)
|-
| ZoC / Zone of Control
| Kontrollzone (KonZ), Sicherheitszone
|}

== AddOns (inoffizielle Erweiterungen) ==

Der folgende Bereich zeigt gängige Namen/Begriffe aus Übersetzungen von Beiträgen anderer Benutzer (UMC). Damit die gleiche Einheit/Sache möglichst nicht unter verschiedenen Bezeichnungen im Umlauf ist, könnt ihr hier Bezeichnungen veröffentlichen.

=== Einheiten ===
{| class="wikitable"
| style="width: 300px;" | Abomination (LotI L4 Ghul)
| style="width: 300px;" | Widerling
|-
| Bison
| Wisent (NF)
|-
| Mosquito
| Stechmücke (S)
|-
| Saurian Haruspex (RotW)
| Saurianischer Opferpriester
|-
| Shark (BW)
| Hai
|-
| Vampire
| Vampir
|}

=== Rassen / Ethnie / Fraktionen ===
{| class="wikitable"
| style="width: 300px;" | Animal
| style="width: 300px;" | Getier
|-
| Aquatics (BW)
| Wassertiere
|-
| Carapaces (BW)
| Panzertiere
|-
| Dark Elves
| Dunkelelfen / Dunkle Elfen
|-
| Elementals
| Elementargeister / Urgeschöpfe (FoaP)
|-
| Faerie
| Feenwesen
|-
| Northern Barbarians
| Nordbarbaren
|-
| Ungulate (FoaP)
| Huftiere
|-
| Steelhive Robots
| Geschmiedete (LotI)
|}

=== Geographie ===
{| class="wikitable"
| style="width: 300px;" | Black Isle (Far Sea, TRs)
| style="width: 300px;" | Schwarze Insel (Fernes Meer)
|-
|Oxbow Swamp (RotW)
|Sumpf der stillen Wasser
|-
| Pogo Bog (S)
| Pogo Sumpf
|-
| Xaffrasz (S - Saurian city)
| Xaffrasz
|}

=== Waffen ===
{| class="wikitable"
| style="width: 300px;" | crystal fire (BW)
| style="width: 300px;" | Kristallfeuer (BW)
|-
| explosion (S)
| Explosion
|-
| horns (FoaP)
| Hörner
|-
| quarterstaff
| Kampfstab
|-
| shield
| Schild
|}

=== Waffenfähigkeiten ===
{| class="wikitable"
| style="width: 300px;" | petrifies
| style="width: 300px;" | Versteinerung
|}
=== Gegenstände ===
{| class="wikitable"
| style="width: 300px;" | armor
| style="width: 300px;" | Rüstung
|-
| altar
| Opfertisch
|-
| caravan
| Planwagen
|-
| storm orb (BW)
| Sturmkugel
|}
=== Fertigkeiten ===
{| class="wikitable"
| style="width: 300px;" | darkens
| style="width: 300px;" | Verdunkeln
|-
| invisible
| Unsichtbar
|-
| penetrate
| Unterwandern
|}
=== Charakteristiken ===
{| class="wikitable"
| style="width: 300px;" | horrid
| style="width: 300px;" | Grauenerregend
|-
| loot (S)
| Stehlen
|}

== Siehe auch ==

* [[GermanTranslation|Hauptseite für deutsche Übersetzung]]

[[Category:Translations]]

How to play Dunefolk

2023-02-06T23:52:39Z

Spixi: fix typos

{{Factionbox}}

All informations is made for Wesnoth 1.15.x and later. Dunefolk/Khaliphate is much different in 1.14 and older versions.

<div class="tright" style="width: 300px; height: 300px;">https://units.wesnoth.org/1.15/pics/core%24images%24portraits%24dunefolk%24herbalist.png</div>

==Dunefolk units==
<b>Dune Burner</b> is the only unit with fire from the Dunefolk faction. Use him to attack skeletons or woses. Compared to mages, they are generally better in defense, cheaper and not as strong when using ranged attack.
<div class="thumb tleft">https://units.wesnoth.org/1.15/pics/core%24images%24units%24dunefolk%24burner%24burner.png</div>
* <b>good defense in mountains and villages</b>
* lawful, slight vulnerability to blade attacks
* <b>strong</b> vs skeletons, woses and saurians; <b>weak</b> vs cavalry, ulfserkers and grunts
* average melee attack (blade), strong ranged attack (fire)

<b>Dune Herbalist</b> can heal himself and all adjancement units. Basically a healer with melee impact damage.
<div class="thumb tleft">https://units.wesnoth.org/1.15/pics/core%24images%24units%24dunefolk%24herbalist%24herbalist.png</div>
* <b>good defense in mountains and villages</b>
* liminal, slight vulnerability to blade attacks
* <b>strong</b> vs goblins and skeleton archers; <b>weak</b> vs almost everyone, especially ghosts and archers/mages
* average melee attack (impact)

<b>Dune Rover</b> is a good, balanced fighter, usable in most situations.
<div class="thumb tleft">https://units.wesnoth.org/1.15/pics/core%24images%24units%24dunefolk%24rover%24rover.png</div>
* <b>good defense in mountains and villages</b>
* liminal, no vulnerabilities. Also better on sands then other units.
* <b>strong</b> vs most enemies when massed; <b>weak</b> vs skeletons and heavy infandry
* medium melee attack (blade), medium ranged attack (pierce)

<b>Dune Skirmisher</b> is your fast unit, important in difficult fights against important targets.
<div class="thumb tleft">https://units.wesnoth.org/1.15/pics/core%24images%24units%24dunefolk%24skirmisher%24skirmisher.png</div>
* <b>good defense in almost any terrain, but low hitpoints</b>
* lawful, slight vulnerability to blade, pierce and impact attacks
* <b>strong</b> vs wounded units, mages and healers; <b>weak</b> vs any unit good in melee fighting (grunts, cavalry...)
* strong melee attack (pierce), weak ranged attack (impact)

<b>Dune Soldier</b> is the Dunefolk version of the grunt or wose. Strong, melee oriented unit for both attack and defense.
<div class="thumb tleft">https://units.wesnoth.org/1.15/pics/core%24images%24units%24dunefolk%24soldier%24soldier.png</div>
* <b>good defense only in castles, average in most terrains</b>
* lawful, slight vulnerability to impact attacks, good against pierce and blade. Can be upgraded into 3 useful units.
* <b>strong</b> vs saurians, mages, archers; <b>weak</b> vs skeletons, trolls
* strong melee attack (blade)

<b>Dune Rider</b> is very fast on flat terrain. They are simply horse archers.
<div class="thumb tleft" style="width: 72px; height: 72px;">https://units.wesnoth.org/1.15/pics/core%24images%24units%24dunefolk%24rider%24rider.png</div>
* <b>good defense in mountains and villages</b>
* liminal, vulnerability to pierce attacks. Can be upgraded into 3 useful units.
* <b>strong</b> vs wounded units and drakes; <b>weak</b> vs spearmen, saurians and skeleton archers.
* average melee attack (impact), strong ranged attack (pierce)

<b>Naga Dirkfang</b> is both melee and ranged attacker, that can be good even on dry lands when leveled up. Both attacks are blade.
<div class="thumb tleft">https://units.wesnoth.org/1.15/pics/core%24images%24units%24nagas%24dirkfang.png</div>
* <b>good defense in water (50-70%) and swamps</b>
* neutral, Can be upgraded into 2 more powerful units.
* <b>strong</b> vs anyone in water; <b>weak</b> vs anyone on dry land
* average melee attack (blade), average ranged attack (blade)

==Starting troops - random opponent==
<span style="width: 72px; height: 72px;">https://units.wesnoth.org/1.15/pics/core%24images%24units%24dunefolk%24rider%24rider.png</span>
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dunefolk%24rover%24rover.png
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dunefolk%24rover%24rover.png
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dunefolk%24burner%24burner.png
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dunefolk%24herbalist%24herbalist.png
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dunefolk%24soldier%24soldier.png

(96 gold)

On the maps with a lot of water, recruit one or even two naga dirkfang in the first turn.

Probably the best possible way is to go for '''Dune Apothecary''', who can heal wounds, but cannot remove poison from friendly units. Some units, like Dune Shieldguard, can be useful only against some enemies. '''Dune Explorer''' is your guys, if you need a fast leader for some reason.

==General Dunefolk Strategies==

[[Dunefolk]] is a new faction in Battle for Wesnoth. They have variety of useful units, but you can also mass a lot of their cheap and powerful Dune Rovers to ensure good progress. They have multiple ranged attackers, while some can do a lot of damage in melee combat (Dune Soldiers). Remember, that you can always heal your units, but your Dune Herbalists are very different from other healers, because they can heal themselves. Upgrade at least one to get a powerful level 2 healer.

Dunefolk defend well in mountains, but they are not very mobile there. However, they are good in desert sands and beaches. They can be good against any enemy, if proper strategy is applied. They do not like mages very well, so use your fast horse archers (Dune Riders) to hunt them down on open plains or use Dune Skirmishers to chase them, if they are not well protected from every corner.

Dunefolk have access to healing via herbalists, charge with powerful Dune Cataphracts and together 5 (!) units with skirmisher speciality. Dune Soldiers can became very defensive, very offensive and also very motivating with leadership, if they get to level 2. While this looks nice, Dunefolk have also disadvantages. They are not good in forcing enemies to retreat from their favourite terrain. With no magic attacks and very limited poison and marksman attacks, it is hard to defeat factions line Knalgan Alliance.

Dune Skirmisher is good for finishing enemies and that way gaining lots of experience. They need less experience than others to promote to level 2, so your strategy can be focused on using Dune Striders, that are stronger and can slow in ranged combat, or with Falconers. Falconers can make enemy unit weaker, if placed properly.

Dunefolk have access to blade, pierce and impact attacks, same as any other faction. However, their burners can use '''fire''' attack.

==Villages==
<div class="thumb tleft">https://raw.github.com/wesnoth/wesnoth/master/data/core/images/terrain/village/human3.png</div>
Almost every unit in Dunefolk army is good in defending villages. You need villages to help you with poison, because your healers can cure it only on level 3. Riders can move to enemy villages quickly and use their arrows to harm anyone who will try to capture it back. Universally usable Dune Rovers are the best guardians of the villages.

==Dunefolk vs Loyalists==
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dunefolk%24rover%24rover.png A
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dunefolk%24soldier%24soldier.png A
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dunefolk%24herbalist%24herbalist.png A
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dunefolk%24burner%24burner.png B
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dunefolk%24skirmisher%24skirmisher.png B-
<span style="width: 72px; height: 72px;">https://units.wesnoth.org/1.15/pics/core%24images%24units%24dunefolk%24rider%24rider.png</span> C
https://units.wesnoth.org/1.15/pics/core%24images%24units%24nagas%24dirkfang.png C

<div class="thumb tleft">https://units.wesnoth.org/1.15/pics/core%24images%24units%24human-loyalists%24horseman%24horseman.png</div>
Loyalists and Dunefolk are similar. To defeat them, you must use your strenghts against their weaknesses. Both armies have access to cavalry and numerous foot soldiers. Loyalists have more melee units, while you can use your fast units with ranged attack to engage them first.

One of the main problems are mages. They can be killed very fast, but they can also kill your units quickly. So, if they can defend mages, there is a big problem for you. With army of skirmishers, you can do a lot of damage and get out of there if needed.

Loyalists are also known for their simply spearmen strategy. Only your riders are vulnerable to them. Also, with lots of spearmen, your skirmishers are useless. Dune soldiers can defeat spearmen, bowmen, fencers and cavaliers.

* '''Burner:''' No one from loyalists faction is vulnerable to fire. Burners are generally a good unit, but they are not needed in this match.

* '''Herbalist:''' As always, these guys are needed to heal wounds. Loyalists will probably do not get a lot of ranged units, so they can be relatively safe and heal your guys for longer time.

* '''Rover:''' General purpose infantry with good cost is always usable option. They can both attack and defend.

* '''Skirmisher:''' These guys are good against some enemies. They are very similar to fencers and can harm horsemen. Their most important job is to neutralize mages or wounded units. They can also get some villages.

* '''Soldier:''' Very important front-line unit. Use their strengh to advance and do not forget to heal them. They are your anti spearman weapon, and they can kill other units as well.

* '''Rider:''' Much faster than many loyalist units. Good to take some villages. Also, they have good ranged attack, that can be used against other cavalry. Spearmen and horsemen can kill them fast, so move quickly between villages.

* '''Naga Dirkfang:''' Good in water. They have ranged attacks, what can be useful.

==Dunefolk vs Rebels==
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dunefolk%24soldier%24soldier.png A
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dunefolk%24rover%24rover.png A-
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dunefolk%24herbalist%24herbalist.png B
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dunefolk%24skirmisher%24skirmisher.png B
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dunefolk%24burner%24burner.png B-
https://units.wesnoth.org/1.15/pics/core%24images%24units%24nagas%24dirkfang.png B-
<span style="width: 72px; height: 72px;">https://units.wesnoth.org/1.15/pics/core%24images%24units%24dunefolk%24rider%24rider.png</span> C-

<div class="thumb tleft">https://units.wesnoth.org/1.15/pics/core%24images%24units%24elves-wood%24archer.png</div>
Dunefolk can fight rebels in an interesting battle. Two factions with good ranged units, healing and even the (more or less) balanced fighter costs 14 gold in each faction.

Everyone know, that rebels love forests. Can you force them out? Probably no. At least with basic units. Elves does not have complicated vulnerabilities, with exception of a wose. But will they use woses if you can cut them down with your blade weapons and also burn them with burners?

Elvish fighters might be dangerous. They are good against your skirmishers, burners and herbalists, but they are generally weak against your dune soldiers. So, logically, rebels will use someone good against your soldiers. But who? 4 elvish units use mostly blade and pierce damage, so they will need to attack your strong, sturdy soldiers with mages. Kill mages, fighters and everyone else with a combination of soldiers, rovers, skirmishers and herbalists. You will need also some burners for extra ranged damage and to prevent enemy from using woses. As always, dunes rider are important to get villages, but they can be attacked by faster elvish scouts and gravely injured or slowed by archers and shamans.

Battle plan: Kill elves outside of forests. Shamans might be a priority with archers and mages. Use soldiers as a front-line units and reinforce them with cheaper rovers and herbalists. Get villages and if possible, fight far from forests.

* '''Burner:''' Fighters can do a lot of damage to them. Even archers and scouts in melee attack. Use them, to get rid of the woses and to attack during the day, because they are lawful.

* '''Herbalist:''' Essential healer with impact damage. No enemy in this battle have vulnerability to impact and killing rebels have priority over healing. Pick one or two of them, not more.

* '''Rover:''' Good, because they are stronger than elvish archers in melee and stronger than elvish fighters in ranged. Thats about it. Plus, they can attack woses, mages etc.

* '''Skirmisher:''' Suprisingly, this unit is very good against Rebels. Rebels have low HP, so you can attack a lot with skirmishers. Do not recruit too many, but they can make sure, that wounded elves or woses will not get to the forest hexes. Also, good skirmisher is always good against mages.

* '''Soldier:''' Rebels are good in blade and pierce. This guy is resistant to blade and pierce and can survive long and hit hard. Your main unit.

* '''Rider:''' Effective, but not as much as in other duels.

* '''Naga Dirkfang:''' Similar unit to mermens, but they have blade attack. So, they can help cutting down woses.

==Dunefolk vs Northerners==
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dunefolk%24rover%24rover.png A
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dunefolk%24soldier%24soldier.png A
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dunefolk%24herbalist%24herbalist.png A-
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dunefolk%24burner%24burner.png B+
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dunefolk%24skirmisher%24skirmisher.png C
<span style="width: 72px; height: 72px;">https://units.wesnoth.org/1.15/pics/core%24images%24units%24dunefolk%24rider%24rider.png</span> C
https://units.wesnoth.org/1.15/pics/core%24images%24units%24nagas%24dirkfang.png C

<div class="thumb tleft">https://units.wesnoth.org/1.15/pics/core%24images%24units%24orcs%24grunt.png</div>
Northerners are cheap. Cheaper than you, but generally similar. They can prepare attack with lots of strong units, so this is generally a balanced scenario.

As always, some units are better. As Dunefolk, pierce and blade is no problem, you have anough of it. But the troll whelps are resistant. While generally it is not very hard to hit troll whelps, they regenerate even when fighting and getting them out of the mountains might be complicated. However, there is a unit, you can use - dune burners.

Most of the northerners are good only in melee attack, so shoot them with your multiple ranged units - rider, burner, rover, naga dirkfang and if needed (mostly to get some free experience), even skirmishers.

Because you are alive, poison will harm you a lot. For dunefolk, it is very hard to get a powerful level 3 healer, who can cure poison, and northerner player knows that. He will probably make several assassins to harm your forces. Deal with them, when they are in the open places. Assassins have vulnerabilities to blade (-30%), impact and pierce (-20%), so hit them with your units, that are generally good in these. Remember, that 1HP assassin can still poison any of your units. To deal with them, soldiers looks a good idea, but they do not have any ranged attack to retaliate. So, rovers can be better in the hunt for assassins.

* '''Burner:''' Burner burn enemies. Simple. Goblin spearman, grunts, whelps and everyone else can be killed by fire. Just do not attack assassins with them, if villages are far away.

* '''Herbalist:''' Useful, as always. They can also effectively attack assassins or even troll whelps, two of the most annoying enemies in this match. Definetly get them!

* '''Rover:''' Good against everything with exception of whelps - and they can still harm them with their ranged attack.

* '''Skirmisher:''' Specialised assasin, who costs more than most enemy unit. Not a very good idea, but they can be used to kill assassins. Weak against grunts and other units with full health. They can also steal villages, what hurts a lot - but generally whelps do no need them. Do not over-recruit them.

* '''Soldier:''' Solid, strong unit, that can hold the line. When poisoned, they do not need to get away ASAP and can fight a while. Their resistances helps them against assassins, archers, grunts and wolf riders, but they are generally not that great against whelps. In simply words, whelps are good against blade and soldiers are weak against impact.

* '''Rider:''' Dune Rider is a prime enemy of Wolf Rider. Wolves are faster, but lack ranged attack. Your dune riders are vulnerable only to pierce, while wolf riders use blade. However, wolf rider is one of the few fast units without weakness for pierce. Dune riders are also good to finish grunts and prevent injured assassins to get away.

* '''Naga Dirkfang:''' Like in most battles, these water units are great. Even against other nagas. Because they have ranged attack, they can work well with your riders and skirmishers to hunt down enemies that comes close to water.

==Dunefolk vs Undead==
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dunefolk%24herbalist%24herbalist.png A
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dunefolk%24burner%24burner.png A
<span style="width: 72px; height: 72px;">https://units.wesnoth.org/1.15/pics/core%24images%24units%24dunefolk%24rider%24rider.png</span> B+
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dunefolk%24skirmisher%24skirmisher.png C
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dunefolk%24rover%24rover.png C
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dunefolk%24soldier%24soldier.png C
https://units.wesnoth.org/1.15/pics/core%24images%24units%24nagas%24dirkfang.png D

<div class="thumb tleft">https://units.wesnoth.org/1.15/pics/core%24images%24units%24undead-skeletal%24skeleton%24skeleton.png</div>
Undead skeletons are good against your pierce and blade damage. Dark Adepts can make a lot of damage and ghosts can attack your lawful/liminal/neutral units during the night and heal themselves. So, undead are strong. On the other hand, you have units, that are especially good against them. Keep a good mix of units to cover your weaknesses.

Because all of your units are living, undead (and orcs) will try to use poison. Ghouls are a problem, because they can force your units to flee, you can cure your units only with level 3 healers and 3 your units are vulnerable to poison. Burn them or shoot them with ranged attack. That unit is surprisingly strong in defense, so you might need to focus fire.

Your strategy is centered on Dune Burners. You simple need fire to defeat skeletons, ghouls and to retaliate against their strong ranged attack. Burners are not invulnerable, so mix them with other units and of course, try to get enemy villages. Because of your burners, it is possible that you will not face many ghosts in this battle.

* '''Burner:''' Good ranged damage that is especially effective against skeletons and skeleton archers. Very important unit, use a lot of them.

* '''Herbalist:''' This healer have impact damage, what is nice and useful. It is possible that enemy will try to poison them, so they need protection. Feel free to crush skeleton archers any time, especially during day.

* '''Rover:''' All-around unit, that can be used against adepts and even against ghouls. Weak to skeletons, but cheap. Good to have, but you should buy 1 or 2, because you need gold elsewhere.

* '''Skirmisher:''' Good against adepts, weak against everyone else. Same as rover, do not mass them. 1 or 2 should be enough.

* '''Soldier:''' Another nice and powerful unit, that can be used against other enemies than undead. They are lawful, so their attack will be much stronger during the day. While weak in attacking during night, you can use them as a shield for other units. However, if you somehow manage to get a captain, it will be great help for other your units.

* '''Rider:''' Horse archers are an interesting choice. Their attack is pierce and impact, so he and herbalist is the only unit with impact attack in your army. You need a unit to get villages, because enemy ghosts and bats will try to get yours. Riders are also great when winning, because they can block a way of the enemy leader to his own keep.

* '''Naga Dirkfang:''' As usual, these nagas are good. Blade attack is not what you need, so use them only in maps with lots of water.

==Dunefolk vs Knalgans==
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dunefolk%24rover%24rover.png A
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dunefolk%24soldier%24soldier.png A
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dunefolk%24herbalist%24herbalist.png A-
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dunefolk%24burner%24burner.png B+
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dunefolk%24skirmisher%24skirmisher.png C
<span style="width: 72px; height: 72px;">https://units.wesnoth.org/1.15/pics/core%24images%24units%24dunefolk%24rider%24rider.png</span> C
https://units.wesnoth.org/1.15/pics/core%24images%24units%24nagas%24dirkfang.png C

<div class="thumb tleft">https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24fighter.png</div>
This is tough, maybe the most frustrating match in Battle for Wesnoth. Defeating knalgans is problematic for a number of reasons.

First, they are much better and faster on hills and mountains. They can easily attack your units and exploit your vulnerabilities. Last and not least, you do not have magic attacks. While you have access to poison and marksman attacks, it all comes with level 2 units, and you can always upgrade to unit that might be better or more needed.

You have to use your solid melee attackers to fight dwarves and outlaws - but they will fire at you with poachers. You can also try to find a perfect unit against poachers, but you will find none in your arsenal. At the end, both factions will fight with a strange mix of units. Dunefolk can use classic blade/impact/pierce attacks, but dwarves are good against them. So even your nagas with blade attack will have limited use. It is possible, that enemy will recruit a fast moving gryphon rider, who can also make things worse, if he collect some villages from you. To make it even more horrific, even cheap thieves that costs only 13 gold can kill your fighters and healers at night.

So... what can you do? Mixing units a lot and using the cheapest and most versatile unit you got - dune rovers. Your biggest advantage is healing, so try to heal more than 1 your unit every turn. Also, you will need to upgrade dune soldiers to get a really powerful unit - or a captain with leadership. In general, your units are faster in flat plains, so you can use hexes just out of reach of the dwarves.

* '''Burner:''' Fire damage? Nice! But blade vulnerability is not what you want against dwarvish fighters, ulfserkers and gryphon riders. Use them to kill enemies, but do not use them a lot, because they might die quickly.

* '''Herbalist:''' You can heal your units, knalgans cannot. So these guys will be the primary target. While not very useful in combat, in closed maps these guys are a must. Make sure to cover them, because gryphons can attack them from far away. Also, as a melee only unit, poachers and even thunderers might come to get some free damage.

* '''Rover:''' All-around unit with balanced ratio of attack and defense. Keep them in front. They are a good unit, but not perfect. Use other units as well, based on what your enemy will do.

* '''Skirmisher:''' Great for units, that knalgans do not have. Vulnerable to everything knalgans have. On the other hand, they have good defenses in terrain and knalgans cannot use marksman/magic attacks, so they can be of some use. While you do not need them very much, they are fast and can help finish some outlaw or dwarf.

* '''Soldier:''' Lots of HP, good melee attacks. They are your meat shield. They are a little vulnerable to hammers from dwarvish fighters, while having good resistances to pierce and blade. A trio of soldiers, rovers and herbalists is a good strategy, where soldier is your "tank". Upgrade one to a captain.

* '''Rider:''' Use them to both grab villages and add additional ranged attack. They are good in flat plains, but dwarves will try to use difficult terrain against you. Beware of the thunderers.

* '''Naga Dirkfang:''' Good in water. Dwarves are good against blade, so try to attack thieves and footpads that come close to water. They are okay against gryphons and much cheaper.
==Dunefolk vs Drakes==
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dunefolk%24herbalist%24herbalist.png A
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dunefolk%24rover%24rover.png A
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dunefolk%24skirmisher%24skirmisher.png A-
https://units.wesnoth.org/1.15/pics/core%24images%24units%24nagas%24dirkfang.png B-
<span style="width: 72px; height: 72px;">https://units.wesnoth.org/1.15/pics/core%24images%24units%24dunefolk%24rider%24rider.png</span> C+
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dunefolk%24burner%24burner.png C
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dunefolk%24soldier%24soldier.png D

<div class="thumb tleft">https://units.wesnoth.org/1.15/pics/core%24images%24units%24drakes%24fighter.png</div>
Drakes like fire. Saurians do not like fire at all. Your only unit with fire is terrible against drakes and wonderful against saurians. So, as many others, you have to deal pierce damage to drakes and blade to saurians.

Drakes do a lot of damage and none of your units is resistant to fire or anything else. In comparison, dunefolk units are more "normal", while drakes and saurians have both strenghts and weaknesses. Make sure to use more units than drake player, because in 1v1 their units are more powerful.

Mobile drakes, crashers and augurs will be your enemies in this battle, but they can (same as you) change their tactics if needed. Drakes can use units to exploit your vulnerabilities. You should know, that you have multiple good units against saurians, so enemy will probably use mostly drakes.

Will some drake gliders come to your territory to steal your villages? You bet they will come. Skirmishers and riders are the best way to stop them. Do not forget to use ZOCing with your units.

* '''Burner:''' Great against saurians. Blade is good, fire is good... but drakes are good against both. So, use them to make sure, your enemy will not use saurians. Or simply make this guys when you see that enemy uses a lot of them.

* '''Herbalist:''' Good, important and fragile. They will try to kill him and with their offensive capabilities, you will simple need a few of them.

* '''Rover:''' This is your miracle guy. Good against drakes, solid against saurians and cheap. What else can you need? Much cheaper than Drake Clasher, so if you face them, you must have at least one more unit than your enemy.

* '''Skirmisher:''' Wounded drake killer, additional damage dealer with pierce damage and a useful specialist. Still, they are not your main fighters and overrecruiting can be bad in many reasons, because their HPs are low. Attack with other units, like rovers, finish with skirmishers. Try to upgrade one of these guys.

* '''Soldier:''' Strong unit with lots of HP, but only average defenses. If you recruit him, he will not be a primary target and drakes will simply find another targets. You can use them in closed maps to guard important route, but other than that, you should use another units. They are good against saurians.

* '''Rider:''' Fast unit for village grabbing and provide good ranged attack. Good, very good, but not so much against a combination of clashers and saurians. Do not over-recruit.

* '''Naga Dirkfang:''' Based on water. They are also good in marshes and can defeat saurians there, so definetly a good unit to have. Almost useless against drakes.

==Dunefolk vs Dunefolk==
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dunefolk%24rover%24rover.png A
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dunefolk%24soldier%24soldier.png A
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dunefolk%24herbalist%24herbalist.png A
<span style="width: 72px; height: 72px;">https://units.wesnoth.org/1.15/pics/core%24images%24units%24dunefolk%24rider%24rider.png</span> B+
https://units.wesnoth.org/1.15/pics/core%24images%24units%24nagas%24dirkfang.png B
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dunefolk%24burner%24burner.png C-
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dunefolk%24skirmisher%24skirmisher.png D

<div class="thumb tleft">https://units.wesnoth.org/1.15/pics/core%24images%24units%24dunefolk%24soldier%24soldier.png</div>
Strategy to defeating dunefolk as dunefolk is simple. Dunefolk have some advantages and disadvantages, but it have also a good unit for everything - dune rover. Other units are good as well, but there is no single good target for your skirmishers.

Because your will probably see a lot of rovers, take also units who are good against rovers - dune soldiers. Especially with healing from herbalists. In fights between two dunefolk leaders, speed is important - and it is possible that more riders will be used. Do not let your enemy have more mobile cavalry than you have.

* '''Burner:''' Fire damage is nice, but no one have vulnerability to fire. However, vulnerability to blade can be a problem against massed rovers. Do not buy this guys, unless you are a skilled player who know how to use them effectively in this match.

* '''Herbalist:''' Impact damage is not very useful, while their healing is nice. If you can heal more than 1 unit every turn, take them. If not, take a single one.

* '''Rover:''' Good for everything, with exception of fighting soldiers. use them a lot.

* '''Skirmisher:''' Same as burner. Use them if you are a skilled player. Otherwise, one should be enough.

* '''Soldier:''' This is your rover killer and he is also good against burners, herbalists and riders. Use them together with herbalists and rovers.

* '''Rider:''' You need them, probably more than in other matches.

* '''Naga Dirkfang:''' Surprisingly, they are awesome fighters. If you play small multiplayer map with shallow water, even small rivers, they can guard other units, when combined with herbalists.

== Specialists ==
How to play specialists: [[How to play Horseman|Horseman]] - [[How to play Mages|Mages]] - [[How to play Skirmishers|Skirmishers]]

[[Category:How to Play]]

ImagePathFunctions

2023-01-31T21:15:48Z

Spixi: Add RIGHT function and section about pseudo IPFs

Image Path Functions provide a simple method for WML coders to alter the way their specified images will be displayed in the game. All of the function parameters are included at the end of an image path and should not contain any spaces or special characters (other than those specified here).

If you need to practice it without having to reload all WML, you can use an add-on named ''Image loading tester''. It is available on the 1.9, 1.10, 1.11, 1.12 and 1.14 add-on servers.

All functions are applied in left-to-right order, with the exception of RC(), TC() and PAL() which are applied always before any other functions. Standard team coloring for a unit is applied after all custom RC(), TC() and PAL() functions but before any other functions.
That is, stuff like
"units/elves-wood/fighter.png~CROP(20,20,40,40)~CROP(10,10,10,10)"
would result in taking a crop to a 40x40 rectangle whose top-left corner is x=20, y=20; and then taking a crop from ''that'' rectangle with x=10, y=10, w=10, h=10. The result is the area x=30, y=30, w=10, h=10 from the original graphic.

== Changing the colors ==

=== BLEND: Color-blend function ===
Blends the image with the given color to produce a more controlled tinting effect than color-shifting, independently of the image's contents.

'''~BLEND(r,g,b,o)'''

The color is defined by the ''r'', ''g'', and ''b'' parameters (integers ranging from 0 to 255). The ''o'' (opacity) parameter controls the amount by which the given color will be blended into the image, and may be specified either as a factor from 0.0 to 1.0, or percentage up to 100%. Thus, ~BLEND(r,g,b,0.5) and ~BLEND(r,g,b,50%) are equivalent.

=== BW: Black and White function ===
{{devfeature1.13|1}}
May be used to convert the image to pure black and white, without grey pixels.

'''~BW(threshold)'''
* ''threshold'': a value between 0 and 255 (both limits included). All pixels are converted as greyscale first, and if their average value is greater than the threshold they become white, otherwise they become black.

=== CS: Color-shift function ===
Performs simple per-channel color shifts by adding the arguments to the respective color channels.

''Multi-channel:'' '''~CS(r,g,b)'''
''Single-channel:'' '''~R(v)''', '''~G(v)''', '''~B(v)'''

The multichannel syntax assumes all arguments are set to zero initially, so one can use, e.g. ~CS(2,4) to add +2 and +4 units to the red and green channels respectively, leaving the blue channel intact. Arguments may be negative to diminish a channel's value; this can be used to change an image's brightness. Checks for out-of-range arguments or results (less than 0 or greater than 255) are made, so the resultant values are truncated if necessary.

The single channel syntax behaves exactly the same, except that only single-channel modifications are made per function. However, one can stack them to produce the same behavior as ~CS(), e.g. ~R(r)~G(g)~B(b), but that tends to be just a performance loss.

=== GS: Greyscale function ===
May be used to greyscale the image (turn to black and white)

'''~GS( )'''

=== L: Lightmap color-shift function ===
Performs per-pixel and per-channel color shifts using another image (a "lightmap") as source, allowing to create textured light effects.

'''~L(lightmap)'''

For each pixel of the original image, it checks the RGB values from the corresponding pixel of the lightmap, slightly transform them, then add these values to the original pixel.

The transformation involved is done to convert the (0,255) spectrum to (-255,255), allowing to add or subtract color. The formula is (x-128)*2, which means that 0 gives -256, 128 gives 0 and 255 gives 254. So, the no-effect lightmap is a fully grey image (RGB = 128,128,128) and any non-grey pixel will shift the colors of the original.

Note that the lightmap will be scaled to the same dimensions as the original image.

=== NEG: Negative function ===
{{devfeature1.13|0}}
Also known as ''invert'', it negates all the RGB values of the image, giving it an effect similar to a photographic negative.

'''~NEG( )'''

Inverts the image, giving it an effect like a photographic negative.

{{devfeature1.13|1}} '''~NEG(''' ''threshold'' ''')'''

If a channel has a value greater than the threshold, the channel will be inverted, performing an effect known as ''solarization''.
Threshold must be between -1 and 255, with -1 equivalent to full inversion and 255 as no-op value.

{{devfeature1.13|1}} '''~NEG(''' ''threshold_red, threshold_green, threshold_blue'' ''')'''

If a channel has a value greater than the corresponding threshold, the channel will be inverted.
Each threshold must be between -1 and 255, with -1 equivalent to full inversion and 255 as no-op value.

=== PAL: Palette-switch function ===
May be used to change colors in an image following the specifications of a source and target (new) palette.

'''~PAL(''' ''source color palette'' '''>''' ''target color palette'' ''')'''
*''source color palette'' - the first parameter is a source color palette, such as magenta. Do not surround this parameter with quotes.
*''target color palette'' - the new palette to take the place of the source colors in the image.

=== RC: Re-Color function ===
May be used to change some colors in an image. It is possible to use ''RC'' more than once on the same image, with different source palettes.

'''~RC(''' ''source color palette'' '''>''' ''destination color range'' ''')'''

==== source color palette ====
The first parameter is a set of colors, usually the magenta palette. Do not surround this parameter with quotes. The three standard palettes are:

* '''magenta''' - the 19 colors described in [[Team_Color_Shifting]]
* '''ellipse_red''' - all 255 colors with RGB value (n,0,0)
* '''flag_green''' - all 255 colors with RGB value (0,n,0)

The palette can also be given inline as a set of hexadecimal RGB values.

The named palettes are defined using the '''[[GameConfigWML#Color_Palettes|[color_palette]]]''' tag, and you can also define your own custom color palette using that tag.

Warning: the RC function will also accept (and not give a warning about) '''red''', '''green''' and any other defined '''[color_range]'''; however the set of RGB values for those aren't guaranteed. Using '''red''' instead of '''ellipse_red''' might be equivalent to the palette 030000,060000,0a0000,...,ff0000,ff0a0a,...,fff0f0.

==== destination color range ====
This is the second parameter, signifying the ID of a color range defined in the file [http://github.com/wesnoth/wesnoth/blob/master/data/core/team-colors.cfg data/core/team-colors.cfg] (or it may be a custom ID for a color range defined locally). You can also define a custom color range inline (the rgb key from [[GameConfigWML#Color_Palettes]]; note that RC does not use the fourth color for anything).

For this destination color range, using '''red''' or '''green''' makes sense.

==== Example ====
In the following example, the magenta regions in an elvish captain's image are turned a healthy shade of green:

[message]
speaker=narrator
image=units/elves-wood/captain.png~RC(magenta>green)
message=_ "Now I am on the green team."
[/message]

The following example replaces a few of the '''magenta''' pixels with green ones:

misc/orb.png~RC(690039,c30074,ec008c > 007f00,00ff00,000000,000000)

The IDs of the color ranges may be the lowercased English name of the palette's base color (e.g. 'red', 'brown', etc.). They may also be numeric color indices from the palette WML included with the game, but this is not recommended.

=== SEPIA: Sepia function ===
{{devfeature1.13|0}}
May be used to give to the image a sepia tint (like in old pictures).

'''~SEPIA()'''

=== SWAP: Channel Swap function ===
{{devfeature1.13|1}}
May be used to swap the RGBA channels of an image.

'''~SWAP(''' ''r, g, b'' ''')'''
'''~SWAP(''' ''r, g, b, a'' ''')'''
* ''r'', ''g'', ''b'', ''a'': each of these arguments may have a value equal to ''red'', ''green'', ''blue'' or ''alpha''. The RGBA channels of the original image will be exchanged accordingly (for example, <tt>~SWAP(blue,green,red)</tt> swaps the blue and red channels).

=== TC: Team-Color function ===
In Wesnoth version 1.2, the only Image Path Function was '''~TC()''', which took two comma-separated parameters: the team number and the source color palette. The valid values for both of these parameters are defined in the file ''data/team-colors.cfg''

'''~TC(''' ''team number'' ''',''' ''source color palette'' ''')'''
*''team number'' - this is the first parameter, a number 1-9 signifying the team number of a unit. Number 1 typically means the red team, 2 typically means the blue team, and so on (unless the scenario color settings for any side have been altered).
*''source color palette'' - the second parameter is a source color palette, usually magenta. Do not surround this parameter with quotes.

== Transformations ==

=== FL: Flip function ===
May be used to flip an image horizontally and/or vertically.

'''~FL(''' ''optional argument list'' ''')'''
*''vertical'' - if the string "vert" is found anywhere in the argument list, the image will be flipped vertically.
*''horizontal'' - if the string "horiz" is found anywhere in the argument list, the image will be flipped horizontally.
*if the argument list is empty, the image will only be flipped horizontally.

=== ROTATE: Rotate function ===
May be used to rotate an image.

'''~ROTATE(''' ''degrees'' ''')'''
* ''degrees'' - The number of degrees by which the image will be rotated. Positive numbers indicate clockwise rotation, while negative numbers indicate counter-clockwise. (Zero indicates no rotation.)
If the number of degrees is omitted, a quarter turn (90 degrees) clockwise is assumed.

=== SCALE: Image-scaling function ===
Scales a graphic up or down.

'''~SCALE( ''new_width'', ''new_height'' )

The ''new_width'' and ''new_height'' parameters are taken as the image's original width or height, respectively, if one of them happens to be zero. Negative values are treated in the same way, but an error is printed in stderr. This uses the bilinear interpolation algorithm.

=== SCALE_INTO function ===
{{DevFeature1.13|5}}

Similar to SCALE, but preserves aspect aspect ratio, scaling to the minimum extent required to fit into the specified area. The resulting image will have the specified width or the specified height, but not necessarily both.

=== SCALE_SHARP function ===

{{DevFeature1.13|0}}

Scales functions using a nearest neighbor algorithm. Specify width and height. (It has the same syntax as ~SCALE.)

'''~SCALE_SHARP(200,300)'''

=== SCALE_INTO_SHARP function ===
{{DevFeature1.13|5}}

Like SCALE_INTO, but uses nearest neighbor algorithm instead of bilinear interpolation.

=== XBRZ function ===

{{DevFeature1.13|0}}

Scales functions using the XBRZ algorithm. You may scale things up either 2x, 3x, 4x, or 5x. The scaling tries to preserve the pixel art nature.

'''~XBRZ(n)'''

== Cut-and-paste ==

=== BLIT: Blit function ===
Blit the parameter image on the main image. Example: peasant.png~BLIT(hat.png,30,10)

'''~BLIT(src,x,y)'''
* ''src'': an image file used as source for the blit, other image path functions can be used there.
* ''x'',''y'': top-left corner coordinates where to blit. If missing assume (0,0).

=== CROP: Crop function ===
Extracts a rectangular section of an image file.

'''~CROP(x,y,width,height)'''
* ''x'',''y'': top-left corner coordinates for the rectangular section extracted. Must be greater or equal than zero, and inside the image's bounds.
* ''width'': width of the selected region. Must be less than or equal to the original image's width, and must not be negative.
* ''height'': height of the selected region. Must be less than or equal to the original image's height, and must not be negative.

=== MASK: Mask function ===
Remove parts of the main image using the parameter image as a mask. Example: grass.png~MASK(circle.png) will give a circle of grass.

'''~MASK(mask,x,y)'''
* ''mask'': an image file used as mask, other image path functions can be used there.
* ''x'',''y'': top-left corner coordinates where to put the mask. Parts ouside of the mask are considered transparent. If missing assume (0,0).

Only the alpha channel of the mask is used and each alpha value will be the maximum alpha of the resulting image. This means that the fully-transparent parts of the mask will erase the corresponding parts of the image, but also that a semi-transparent mask will create a semi-transparent image.

== Opacity ==

=== ADJUST_ALPHA ===

{{DevFeature1.13|?}}

Alters the alpha of the image according to a WFL formula. The formula must output an integer from 0 to 255 giving the alpha across the canvas. It is evaluated for every pixel and may use the following variables: x, y, red, green, blue, alpha, width, height. {{DevFeature1.15|0}} The variables u and v are also supported now, evaluating to normalized texture coordinates (in the range 0..1); these are equivalent to <tt>x/width</tt> and <tt>y/height</tt> respectively.

'''~ADJUST_ALPHA(formula)'''.

The context object for the formula is a '''[[#CHAN:_General_function|pixel object]]'''.

=== O: Opacity modifying function ===
Changes an image's opacity at render time.

'''~O( ''factor or percentage%'' )'''

If the argument includes the percentage symbol (''%''), it will be treated as a percentage of full (real) opacity; an image will be displayed at its native opacity with ~O(100%).

Without the percentage symbol, the argument is assumed to be a factor by which the image's native opacity should be multiplied. Thus, ~O(0.5) and ~O(50%) are equivalent forms of specifying to reduce an image's opacity by half.

=== PLOT_ALPHA ===

{{DevFeature1.13|0}}

At each pixel, the color is replaced with a grey-tone reflecting the alpha value at that pixel, and the new image is fully opaque. Useful for plotting the alpha to help debug an IPF or inspect a sprite.

'''~PLOT_ALPHA()'''

=== WIPE_ALPHA ===

{{DevFeature1.13|0}}

At each pixel, the alpha value is discarded and the pixel is made fully opaque. Useful again for diagnostics.

'''~WIPE_ALPHA()'''

=== Background coloring function ===
Sets the color of all the (semi-)transparent pixels of the image.

'''~BG(r,g,b)'''

== Miscellaneous ==

=== BL: Blurring function ===

Blurs a graphic at render time using the same algorithm used for in-game dialogs.

'''~BL( ''radius'' )'''

=== CHAN: General function ===

{{DevFeature1.13|7}}

This function allows you to do pretty much anything. It takes up to four comma-separated formulas, one each for the red, green, blue, and alpha channels. Each formula functions exactly the same as the formula for '''ADJUST_ALPHA''', but the output integer is used for the corresponding channel rather than always the alpha channel. Do not surround the formula in <code>$(...)</code>, since that will erase the <tt>self</tt> variable.

'''~CHAN(formula, formula, formula)'''

The context object for each of the formulas is a '''pixel object''' with the following properties:

* '''x''', '''y''': coordinates of the pixel, from the top left
* '''u''', '''v''': {{DevFeature1.15|0}} normalized coordinates in the range [0,1]
* '''width''', '''height''': size of the image canvas
* '''red''', '''green''', '''blue''', '''alpha''': components of the pixel colour

=== DARKEN: Removed function ===

{{DevFeature1.13|7}} This function has been removed. Use a ~BLIT(misc/tod-dark.png) call instead.

Puts a time-of-day schedule overlay (misc/tod-dark.png) on the image, which must be large enough to accommodate it.

'''~DARKEN()'''

=== BRIGHTEN: Removed function ===

{{DevFeature1.13|7}} This function has been removed. Use a ~BLIT(misc/tod-bright.png) call instead.

Puts a time-of-day schedule overlay (misc/tod-bright.png) on the image, which must be large enough to accommodate it.

'''~BRIGHTEN()'''

=== NOP: Null function ===

Does nothing.

'''~NOP()'''

=== Pseudo IPFs ===

The following functions are ignored by the IPF image modification module, but used by other Wesnoth components. They only work in special areas.

==== NO_TOD_SHIFT: Disabling ToD ====

{{DevFeature1.13|8}}

This is used by the terrain renderer and prevents terrain and item images from being affected by ToD lighting. This is in particular useful when placing unit images as items, as they will look the same as when placed as unit.

'''~NO_TOD_SHIFT()'''

==== RIGHT: Display portraits on the right ====

'''''([[DevFeature|Version 1.5.8 and later only]])'''''

This is used by the [[InterfaceActionsWML#.5Bmessage.5D|'''[message]''']] interface action and can be used to show a portrait on the right side of the screen.

'''~RIGHT()'''

== Creating an image file from IPFs ==

The big advantage of Image Path Functions is that they allow you to alter an image without needing a new image file. However, you can also save the result into a new image file using Wesnoth's command line option ''--render-image'.

Assuming you find a way to open your computer's terminal:
wesnoth --render-image "units/human-peasants/ruffian.png~RC(magenta>green)~BLIT(units/human-peasants/woodsman.png~RC(magenta>lightblue),18,12)" /tmp/new_image_file.png

Or on Windows:
"C:\Path\to\Battle for Wesnoth\wesnoth.exe" --render-image "units/human-peasants/ruffian.png~RC(magenta>green)~BLIT(units/human-peasants/woodsman.png~RC(magenta>lightblue),18,12)" new_image_file.png

Use cases include:
* Experimenting with Image Path Functions. If none of the images are from an add-on, adding ''--noaddons'' will speed this up.
* If a new Image Path Function is added to the development version of Wesnoth, add-ons for older Wesnoth versions can use a generated image instead.
* In case you want to use this anywhere out of Wesnoth. On a website, in Project Haldric, …
== See Also ==

* [[FancyAddonIcons]] - Tips and tricks for advanced Image Path Function manipulation
* [[DataURI]] - An image path may also contain the image directly, as a Base64 encoded string
* [http://shadowm.ai0867.net/projects/wesnoth-rcx Wesnoth RCX] - Tool to preview unit recoloring. Covers the effects of the [[#RC:_Re-Color_Function|RC]], [[#TC: Team-Color Function|TC]] and [[#PAL:_Palette-switch_Function|PAL]] functions.
[[Category:WML Reference]]

How to play Knalgans

2021-06-13T00:33:59Z

Spixi: typo

{{Factionbox}}

<div class="tright" style="width: 300px; height: 300px;>https://units.wesnoth.org/1.15/pics/core%24images%24portraits%24dwarves%24fighter.png</div>

==Dwarvish units==
<b>Dwarvish Fighter</b> is important unit with two melee attacks, so he can choose which one is better. Also, strong front-line unit.
<div class="thumb tleft">https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24fighter.png</div>
* <b>maximum defense and speed in mountains (70%)</b>
* neutral
* <b>strong</b> vs mages, woses, outlaws, ulfserkers; <b>weak</b> vs nobody, usable in any match
* strong melee attack (blade and impact)

<b>Dwarvish Ulfserker</b> is your specialist. He will be killed easily, but he can also kill someone not good in melee fighting.
<div class="thumb tleft">https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24ulfserker.png</div>
* <b>average defenses everywhere</b>, but moves fast in complicated terrain.
* neutral
* <b>strong</b> vs mages, saurians, archers and enemy leaders; <b>weak</b> vs grunts, ghosts, drake clashers
* strong melee attack with '''berserk''' (blade)

<b>Dwarvish Thunderer</b> is a strange unit with powerful, but only one ranged attack.
<div class="thumb tleft">https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24thunderer%24thunderer.png</div>
* <b>maximum defense and speed in mountains (70%)</b>
* neutral
* <b>strong</b> vs drakes and units on wrong terrain; <b>weak</b> vs skeletons
* average melee attack (blade), strong ranged attack (pierce)

<b>Dwarvish Guardsman</b> is a solid defensive unit. When you need someone to guard important hexes, he is your guy. Not very good in attacking. Make sure he can use his steadfast ability.
<div class="thumb tleft">https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24guard.png</div>
* <b>average defenses everywhere</b>
* neutral
* <b>strong</b> vs melee attackers; <b>weak</b> vs ranged attackers
* average melee attack with steadfast (pierce), weak ranged attack (pierce)

<b>Gryphon Rider</b> is very fast, moving quickly in every terrain. Most expensive unit in game.
<div class="thumb tleft">https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24gryphon-rider.png</div>
* <b>good defense in mountains, average on every other terrain, what is awesome.</b>
* neutral
* <b>strong</b> vs retreating wounded units; <b>weak</b> vs multiple enemies, heavy infantry and archers
* strong melee attack (blade)

==Outlaw units==

<b>Footpad</b> is fast. That is his main strength. Better in scouting than in fighting.
<div class="thumb tleft">https://units.wesnoth.org/1.15/pics/core%24images%24units%24human-outlaws%24footpad.png</div>
* <b>maximum defenses (70%) in many terrains</b>, but vulnerable to pierce, blade and impact weapons
* chaotic
* <b>strong</b> as a blocking and fast moving unit; <b>weak</b> in fighting
* weak melee attack (impact), average ranged attack (impact)

<b>Poacher</b> is a chaotic version of classic human bowman, capable to fight even in swamps. They have much more ranged hits than dwarvish thunderers.
<div class="thumb tleft">https://units.wesnoth.org/1.15/pics/core%24images%24units%24human-outlaws%24poacher.png</div>
* <b>good defenses in many terrains</b>
* chaotic
* <b>strong</b> against drakes and units with no ranged attack; <b>weak</b> in melee fighting
* weak melee attack (blade), strong ranged attack (pierce)

<b>Thief</b> is a very special outlaw. He (or she) can do minimal damage during the day and a lot of damage during the night, when well placed. Also thieves are very cheap.
<div class="thumb tleft">https://units.wesnoth.org/1.15/pics/core%24images%24units%24human-outlaws%24thief.png</div>
* <b>maximum defenses (70%) in many terrains</b>, low hitpoints and vulnerable to pierce, blade and impact weapons
* chaotic
* <b>strong</b> when well placed at night; <b>weak</b> in fighting when backstab cannot be used
* average melee attack with '''backstab''' (blade)

==Starting troops - random opponent==
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24gryphon-rider.png
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24fighter.png
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24fighter.png
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24thunderer%24thunderer.png
https://units.wesnoth.org/1.15/pics/core%24images%24units%24human-outlaws%24footpad.png
https://units.wesnoth.org/1.15/pics/core%24images%24units%24human-outlaws%24thief.png

(100 gold)

Main thing to condider is the price of Gryphons. If you need more of them, than you will have less units in total. With less or no gryphons, you can recruit more powerful dwarves. You can also switch gryphon for ulfserker and thief for a poacher. This combination cost 96 gold.

'''Rogue''' is probably the best leader for the Knalgans. These men and women are very agile, so they can move fast and also run from danger. They can also work wonders with their backstab and skirmisher abilities.

==General Knalgan strategies==

The Knalgans have perhaps the greatest tactical flexibility of any faction. Because of this, there is no one way to play the Knalgans. This can be a good thing or a bad thing, depending on your personality. You can use dwarves for power and defense and outlaws for movement and low prices.

* '''Dwarvish Fighter:''' It can take more hits than most units, making it a great defender. It also has two damage types, making it offensively versatile. It shares the downsides of all dwarves: slow movement (though few terrains slow it down) and low defense on non-specialized terrain.<br>
* '''Dwarvish Thunderer:''' Although powerful, it can just as easily do no damage at all, making this a tricky unit to know how to use. Fortunately, it is almost as durable as the fighter.<br>
* '''Dwarvish Ulfserker:''' This utility unit has value in many match-ups. It will ensure that either its opponent or it dies. Thus, it has a 100% kill chance against a non-melee unit such as the dark adept, and a very high kill chance against many non-melee-centric units, such as the Mage, Saurian Augur, Bowman, Elvish Shaman, and a wide variety of others. The problem is that your opponent can very easily kill an Ulfserker: they will lose to any dedicated melee unit unless very exceptional circumstances are in play (remember that the ulf cannot get nearly as high defensive values as the Dwarvish fighter, for example), starting hitpoints, time of day, or a combination of the above. Since it is an expensive unit, letting an elvish fighter kill your ulf out of the blue is unwise: however if he just killed a Mage and in killing the ulf the fighter is severely weakened, this is obviously a good trade for you. When using Ulfs, plan how you want them to kill and how you want them to die.
* '''Footpad:''' Opinions on the footpad vary widely. In this guide you will not see them recommended often, but many good players consider these a staple unit of the Knalgans. Regardless, this is not a unit you should overrecruit or your offensive power will be very low. It has excellent defense where your dwarves might be very vulnerable and you might not want to risk your more costly riders. Use it for it's great ZoC abilities even if its offense isn't high-powered.<br>
* '''Poacher:''' Also a very useful unit for the Knalgans, this unit provides a reliable ranged attack to counterbalance the power of the thunderer, plus it fills many useful hexes (notably forests and swamps) well.<br>
* '''Thief:''' This unit is possibly the highest damage-dealing unit in your arsenal when used correctly. A strong thief at night does 12-3 damage: the equivalent of a level 2's damage output. However, they have very few hitpoints and their low resists compound this problem. High defense and low cost offset these disadvantages. Remember to backstab with it whenever possible.
* '''Gryphon Rider:''' Possibly the best scout in the game in terms of combat, this is tempered by its high cost. Use it as a lookout for enemy advances and pick off weak or wounded units that are retreating behind enemy lines.<br>

Keep in mind that that the dwarves should stay in mountains, hills, and other high-defense terrain and the outlaws should stay in any non-grassland terrain, if possible. Keep in mind that since your footpads and thieves have 60 defence on grassland, and your enemy will often have 40 or even 30, it can often be to your benefit if the enemy chooses to attack them on open ground.

==Villages==
<div class="thumb tleft">https://raw.github.com/wesnoth/wesnoth/master/data/core/images/terrain/village/human3.png</div>
Outlaws have 70% defense in villages, so they will get little hits. If hitted, they can heal rapidly. Another good unit for holding villages are guardsmen, but only against melee enemies. Use your fastest unit, gryphon rider, to quickly collect villages. If you need gold, you can also recruit a footpad for this job.

==Knalgans vs Loyalists==
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24fighter.png A
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24guard.png A
https://units.wesnoth.org/1.15/pics/core%24images%24units%24human-outlaws%24poacher.png A
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24ulfserker.png B
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24thunderer%24thunderer.png B
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24gryphon-rider.png C
https://units.wesnoth.org/1.15/pics/core%24images%24units%24human-outlaws%24footpad.png C
https://units.wesnoth.org/1.15/pics/core%24images%24units%24human-outlaws%24thief.png C

<div class="thumb tleft">https://units.wesnoth.org/1.15/pics/core%24images%24units%24human-loyalists%24horseman%24horseman.png</div>
Defend in day, strike at night. That's how the battle will go. Beware the Horseman and Mage and be prepared to counter these heavy daytime hitters. Again, an Ulfserker can be your best friend, especially if you can catch a Horseman at night, or a Mage/Bowman anytime.

Recruit a Fighter, a Thunderer, a Guardsman, and a Gryphon depending on the layout of villages. Fill out your army with what you think will serve you best for that particular battle. Water battles will be nearly pointless. Cheap Mermen with higher defense will easily rout your Gryphon(s). Avoid sea battles unless you can taunt a Merman within range of a ranged unit (who can stand on decent terrain). A Gryphon's extra sight is good for spotting long range Horsemen, so it usually is worth having one around, but recruit no more than one. They don't counter any unit very cost-efficiently, so use it primarily as a scout and utility unit.

* '''Dwarvish Ulfserker:''' If you get one, don't get it until turn two or later. Grabbing one in your initial recruit will only make him impotent during the first few turns of daytime. Ulfserkers are what you will use to kill Mages, grind up horse meat at night, and get rid of Bowmen - though they shouldn't be recruiting many. You shouldn't need more than 1 unless they go mad with Mages.

* '''Dwarvish Fighter:''' Good to fight Spearmen, having these guys is a necessity. These are also your best unit to defend against Heavy Infantry.

* '''Dwarvish Guardsman:''' Get one of these guys. These will make your front line immune to Horsemen. Also useful to counter-attack Cavalry, Mages, and Bowmen. If HI get close enough, milk XP off of them with your ranged attack. The level will come faster than you expect.

* '''Dwarvish Thunderer:''' Get one or two. Good against essentially all of the Loyalist units, the pierce ranged is even better against the two mounted units.

* '''Thief:''' These guys can be used against most Loyalist units at night, but avoid trying to backstab Spearmen. Even at night their firststrike can get nasty on this low HP unit. I recommend the Poacher instead of this guy. They might kill mages quickly if well placed.

* '''Poacher:''' A great unit to counterattack Loyalists and press the attack at night. His multiple strikes are of better use against the high defense Fencer, though his ranged pierce is best against the mounted units. His attack does a modest 3-4 to Heavy Infantry at night (compared to a Thunderers 11-1), and you'll want to use this unit against Spearmen outside of day as well. Although they are weak in daytime, they serve many purposes and are well worth the 14 gold.

* '''Footpad:''' Do not recruit this unit when fighting Loyalists. This unit is very useful against heavy infrantrymen, while their low cost and speed allows them to pin enemy units down and occupy terrain. When fighting as a loyalist commander, I find them annoying. Still, the lack of offensive power is a real problem. It is possible that some fights between footpads and fencers will happen. Block during the day, attack during night.

* '''Gryphon Rider:''' Useful as scouts mainly, you can use these to run down hurt horses, go for 1-attack-kills on Fencers (9% chance if they have no bonus hp), or again, to try to hold important grassland hexes. Beware during day though, as HI, Mages, and Horsemen can all tear Gryphons apart quickly. Recruit no more than 1.

You'll want to press as hard as you can at night, more so than even against Drakes. The reason for this is that Loyalists have no level 1 Neutral or Chaotic units. Every unit the opposing player has will suffer a penalty at night - unless he has a Lieutenant behind his front line. Because of this possibility, don't press too close to his castle until you have gained a monetary advantage, as you will start losing units more rapidly when he comes back at you with an additional +25%. Put your Guardsman up front - this will dissuade any charge attacks. Keep a Dwarvish Fighter or Dwarvish Ulfserker nearby in case the player chooses to besiege you with Mages. Spearmen that attack a Guardsman in day will deal nearly equal damage to each other, which can add up quickly. Counter any advance with Thunderers and Poachers. Don't expose your Dwarves to poor terrain or they will die.

You'll want to whittle away at Heavy Infantry with Poachers and Thunderers and you'll want to give the killing blow to a Fighter. Upgrading Dwarvish Fighters should be your main priority as they are your best defense and counter to the easy Spearman-wave attack. Once leveled up, the massive HP on the Steelclad will also give it the ability to withstand attacking Heavy Infantry and Mages.

Basically, Loyalists have an incredible amount of versatility. You'll have to play smart and counterattack very well in order to win. Deal free damage when you can, and limit the number of hexes you can be attacked from - especially during day. Start commencing your attack before night actually breaks. You'll want to maximize your advantage over those 2 turns, so make sure they don't creep away before night hits. As always, stay on good terrain, and make sure Fencers can't skirmish around to kill any weak units you may be hiding.

==Knalgans vs Rebels==
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24fighter.png A
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24ulfserker.png B
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24thunderer%24thunderer.png B
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24gryphon-rider.png B
https://units.wesnoth.org/1.15/pics/core%24images%24units%24human-outlaws%24poacher.png B
https://units.wesnoth.org/1.15/pics/core%24images%24units%24human-outlaws%24thief.png B
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24guard.png D
https://units.wesnoth.org/1.15/pics/core%24images%24units%24human-outlaws%24footpad.png E

<div class="thumb tleft">https://units.wesnoth.org/1.15/pics/core%24images%24units%24elves-wood%24archer.png</div>
This is one of the trickiest match-ups to play. Both factions are Neutral, so neither has an advantageous time of day to attack (with their main units). To win this battle you will need smart recruits and good unit placement, as well as a little luck; the same goes for your opponent. Knalgans may have a slight advantage with the "one unit must die" Ulfserker, but Rebel defense as well as heal, slow, and magic are serious counters. Look for opportunities to grab mountains and hills, especially if they have no forest next to them. ''Forests are your biggest enemy'', so occupy them with your Outlaw counterparts or Gryphons.

* '''Dwarvish Fighter:''' Again, these will be the meat of your forces. Any front without one of these will succumb to Elvish Fighters. Dwarfs beat Elves 1-on-1, but they are more expensive. They are good damage soakers and damage dealers. Stay on preferred terrain at all times.

* '''Dwarvish Ulfserker:''' counters Mages, Elvish Shamans, and oftentimes Elvish Archers. Again, don't recruit too many of these, as Elvish Fighters will easily come back to finish them off, and they are 5 gold cheaper. If you get a chance to take out a Mage, do so. Not only will you gain 1 gold in attrition, but another unit will likely have to expose itself or get hurt to finish you off. Elvish Archers should be #2 on the "to kill" list, and they are sometimes worth jeopardizing your Ulfserker for if you catch one of them off of forest. Again, the reasoning is you only lose 2 gold in the trade and the opponent must waste moves and usually HP in order to finish you. Again, they may also expose themselves. You might be able to get away with ulfing Woses if it's nighttime and you're in a mountain. Make sure he isn't a Quick, Intelligent Ulf, and check the CTK as always.

* '''Dwarvish Thunderer:''' Another staple. This unit is good against Rebels with luck. Stick him on a mountain and Elves will hurt themselves trying to remove you. They aren't so great for dependable offense against the high defense of the elves, but their counter-attacks are great.

* '''Dwarvish Guardsman:''' Guardsmen are great for holding frontline villages and chokepoints - with backup. A lone Guardsman can hold out for a turn, if lucky 2 or 3, while on a town. He deals very little damage in return, especially against the ranged specialized Rebels. Recruit 1 if necessary, and no more than 2. They just aren't worth the lack of offensive/counter-attack units.

* '''Thief:''' You'll want 1 or 2 of these guys depending on your play style. At night, a combo of thieves can destroy Woses, Elvish Archers, Mages, and Shaman. Keep them in the forest hexes your opponent will want, but not in daytime. They can be quickly killed by mages and sharpshooters - if you do not kill them first.

* '''Poacher:''' Poachers are useful to fill up forest hexes and to attack Elvish Fighters. Their main usefulness is as a counter-attacking utility unit to grab forest and press at night. They are cheap, somewhat weak, but deal more dependable offensive damage than the Thunderer. 5-4 at night is equivalent to a 17 gold Elvish Archer, and you only spend 14.

* '''Footpad:''' Don't recruit this unit when fighting Rebels. It lacks both firepower and hitpoints even while in the forests Footpads and Elves both enjoy.<br>

* '''Gryphon Rider:''' These monsters are incredible useful against Rebels. Their utility lies in fighting any water battles against the weak Merman Hunters, scouting, taking opportunistic attacks against poorly placed Elves, and if you find a hurt Wose, you may consider attacking one - even though Gryphons have a weakness for Impact. At night they do essentially equal damage to each other, and you may not be able to get the finishing blow with one of your slower units. Do so as a calculated risk when you only need 1 hit to kill. Otherwise it's quite a risk.

Generally you'll want a healthy dose of Dwarvish Fighters and Thunderers, along with several gryphons for map control. An Ulfserker, perhaps a Guardsman, and some Outlaws will provide added flexibility. Whichever chaotic units (if any) you recruit, make sure to protect them at day.

If your opponent purchases scouts, feel lucky - they are next to useless against you. Beware of ambushes, and don't scout unsure forests with your Gryphon in daytime. Take as much tactical forest as you can with the appropriate units, and make a stranglehold on mountains. Ulf when you get a good chance, and be ready to counter in day as well as pressing at night. Each battle will play out differently in this matchup according to what your opponent recruits, so see what he has early, and keep track of any Woses. Also, do not let your Ulfs be slowed or they are certainly dead.

==Knalgans vs Northerners==
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24fighter.png A
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24ulfserker.png A-
https://units.wesnoth.org/1.15/pics/core%24images%24units%24human-outlaws%24poacher.png A-
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24guard.png A-
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24thunderer%24thunderer.png B
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24gryphon-rider.png B
https://units.wesnoth.org/1.15/pics/core%24images%24units%24human-outlaws%24footpad.png B-
https://units.wesnoth.org/1.15/pics/core%24images%24units%24human-outlaws%24thief.png D-

<div class="thumb tleft">https://units.wesnoth.org/1.15/pics/core%24images%24units%24orcs%24grunt.png</div>
The biggest problem you will have with Northerners will be their numbers. Northies will gladly trade units with you and gain a monetary advantage. Make them depend on luck by staying on good terrain, and their high upkeep may start to become a factor. Both factions are melee-oriented, so they will not have many classic ranged units.

Recruit a Dwarvish Fighter and a mix of other good units. Stay on villages or mountains for the first assault to minimize the effect any poison will have and reduce the chance of it hitting. Let your opponent attack you, and then counter-attack with your Poachers and Thunderers if you have them - even a Guardsman's ranged attack will add up. Send Ulfserkers against Assassins whenever you get a decent chance, as the Poison will hurt more than their melee attacks. If the northerner overrecruits assassins, you should be able to power through his ranks, so normally eliminating an assassin removes the immediate threat of poison.

* '''Dwarvish Ulfserker:''' Recruit one of these guys if you're really having a problem finishing their units off, or your opponent likes to use Assassins. He's expensive, and Northerners are melee oriented, so most of their units will be able to take a majority of this unit's HP away, if not kill him outright. Assassins' Poison will quickly erode your army's HP though, so having one may prove valuable. Since Assassins cost 17 gold you'll only lose 2 in attrition, and you'll likely take lots of hp from another unit with you.

* '''Dwarvish Fighter:''' Again a necessity. His damage dealt in defense is how you'll deal a majority of your damage. If possible, get a rotation of these guys in the front line. You'll deal more damage than your opponent on average, but he will come with more units - 4 Grunts cost the same as 3 DFs.

* '''Dwarvish Guardsman:''' Another good guy to have one of if not more. He can survive nighttime assaults better than the fighter, and will still do respectable damage back to the enemy. Use your ranged attack on Grunts to make them turn around and heal.

* '''Dwarvish Thunderer:''' Nice to have. Their combination of good resistances and ranged damage make them good counter-attackers. For cheaper ranged counter-attackers, use Poachers as they will also be used to hold forest hexes. Recruiting DTs may crowd your hill hexes, especially since that's what the Northies will be grabbing.

* '''Thief:''' Not a great buy against Northies. His melee-only nature along with his Chaotic alignment make him most effective in the same way Northeners are. Avoid the urge to recruit these guys. Also, no costly priority targets from your enemy make this units almost worthless.

* '''Poacher:''' Again, these guys you'll want to recruit a few of. When the Northies come after you at night, you can make a strong counter-attack with their 5-4 ranged.

* '''Footpad:''' This guy can be a utility unit against Northerners, but the money is better spent elsewhere. Footpads can harass Grunts and Wolfs, take forest hexes, and block Assassins from poisoning your Dwarves. Not the best buy, but you may be able to get your money's worth.

* '''Gryphon Rider:''' Again, it's usually good to have one of these guys to scout, plug up grassland, and be a defensive damage dealer. He's also good for trapping/killing Assassins and being a target for their poison. He is very costly, compared to your outlaws and enemy grunts.

The biggest thing you need to worry about will be poison; this cannot be overemphasized. If you get a good foothold on mountains and hills, poison will be the weapon of choice to knock you off your perch. Be ready to fill in with a replacement unit, and try to kill assassins before any other units. Melee strikes will have to get through your resistance - poison does not. You also don't deal any damage back when poison hits you. If you know you're going to be facing poison on the next turn, have a plan for how you will be rotating units to villages to detox and heal.

Allow your opponent to attack you from forest hexes if they are next to mountains that you occupy. Your 70% defense will outdo his 50% defense, and his confidence will be higher to attack since he won't be on grass. Even if an Assassin uses that hex, if an Ulfserker is within reach, he should be able to take him out from on top the mountain.

To kill Trolls, you will want to focus exclusively on them until they die. Thus it is best to ignore them and kill others than to only do a minimal amount of damage to Trolls each turn. Their regeneration will give them essentially limitless HP if you do this. Kill his friends and then focus on him. If there are several, take them out one at a time. Try to avoid water battles with Nagas, unless there is only one. You won't want any Gryphons you get to be pinned, especially where you cannot help them, so be cautious with water battles.

To sum up, kill poisoners fast, get units that deal good melee damage in defense, and get good counter-attacking ranged units

==Knalgans vs Undead==
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24fighter.png A
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24ulfserker.png A
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24thunderer%24thunderer.png B
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24gryphon-rider.png C
https://units.wesnoth.org/1.15/pics/core%24images%24units%24human-outlaws%24footpad.png C
https://units.wesnoth.org/1.15/pics/core%24images%24units%24human-outlaws%24thief.png C
https://units.wesnoth.org/1.15/pics/core%24images%24units%24human-outlaws%24poacher.png D
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24guard.png E

<div class="thumb tleft">https://units.wesnoth.org/1.15/pics/core%24images%24units%24undead-skeletal%24skeleton%24skeleton.png</div>
If you know you're playing against Undead, the smartest thing to do is to recruit a Dwarvish Ulfserker. He will automatically kill any Dark Adept that he attacks. He is also good for taking on Ghouls and Skeleton Archers. Beware of ghosts: at night the phantoms can kill your ulf, although at day your ulf will come out victorious. Here are the units you will want to recruit to counter Undead units:

* '''Dwarvish Ulfserker:''' counters Dark Adepts, and most other undead units in daytime. Don't recruit many unless the opponent has no Skeletons. Skeletons can kill an Ulfserker even in day. Ulfs are also expensive, so you don't want to trade them 1-for-1 with Undead units unless you get a Ghost. Be mindful of what can counterattack them on your opponent's next turn.

* '''Dwarvish Fighter:''' counters Skeletons, Skeleton Archers, and is a generally high HP unit that can soak up nighttime damage for your front line. Dwarvish Fighters are probably the best all-around L1 heavy infantry in the game. If your opponent is smart, however, they will spam ghouls—and the dwarvish fighter really sucks against poison. Their lack of mobility is a major disadvantage; their armor is also ineffective against poison.

* '''Dwarvish Guardsman:''' Do not recruit this unit if you are fighting Undead. His Pierce damage is less useful than even Blade against Undead. His low damage also makes him a bad unit to counter-attack with. Even for pure defense you can use better units in this match.

* '''Dwarvish Thunderer:''' This is a good unit to have in your front line in mountains. His high defense and good resistances should keep him alive from nighttime Skeleton attacks, and his 18-1 ranged will make it very risky for Dark Adepts to come after you. Thunderers are also good to attack Ghosts, as 2 ranged hits will kill a Ghost - this even works at night.

* '''Thief:''' They are only good against dark adepts. Attack adept with thief and finish him with ulfserker or gryphon. Or attack skeleton archer with thief and finish with ulfserker/gryphon/fighter again. Thieves will be much more useful on level 2 as rogues. Still, not the best unit you can have. Ghouls are a real nuisance for you—and the thieves’ high defence (= much better chance to not get poisoned) and higher mobility (= much less time to get to a village and heal) make them ideal for finishing off the toxic undead. Their combination of arcane resistances and high defence are handy against ghosts, especially at night; Like many knalgan units, the thief is situational, and works to fill a particular niche. Do not use them against skeletons, for which you are much better off with fighters.

* '''Poacher:''' A utility unit versus Undead. It's good for finishing Ghosts and killing Walking Corpses. It can also be used to pick at Skeletons and Ghouls. Money is spent better on other units, but don't forget that he may be useful.

* '''Footpad:''' This weak character is really only useful versus Undead as a cheap scout. His Impact damage is good against Skeletons and Skeleton Archers, and he has the added bonuses of being Chaotic (which deals more damage when Undead try to advance at night), and being hard to hit. His best feature is his ranged attack versus Skeletons at night, and that's only 6-2. Recruiting 1 on your first turn to grab villages is likely the only use you'll get from this guy, unless you need a unit to occupy forest hexes (which dwarves do very poorly at 30% defense).

* '''Gryphon Rider:''' Probably not the best expenditure of gold versus Undead, but they do serve many purposes that can justify their cost: they give extended view of battle, allowing you to know what is coming and to counter appropriately; they are good for getting behind enemy lines to finish hurt Dark adepts; and they serve as good ZoC units for plains and forest hexes. Note that this unit is much more useful against ghouls and adepts than against skeletons — the latter’s 40% blade resistance is what really makes them ineffective. But their speed makes them very handy against the former, as they can threaten adepts, work in conjunction with thieves, and heal quickly after being poisoned by a ghoul.

Generally you'll want a good dose of Dwarvish Fighters, a few Thunderers, a Gryphon for vision/utility, an ulf or two, and maybe a Poacher or Footpad. Dwarves are really what you want to use, for their high HP and decent resists. This helps them survive the nighttime onslaught, and their neutrality will give them good damage in defense and also the ability to press the attack in daytime. Don't be afraid to send an Ulfserker at a ghost in daytime - make sure to check the CTK, but it should be good if your Ulfserker is at high hp: bonus if you can get great terrain. Defeat for the Ghost will be nearly certain if the Ulfserker is Strong.

Dark adepts will, as always, be the main danger to your army: they'll knock dwarves out of their mountains, footpads out of wherever, and even gryphons are in danger from them. Be especially mindful of where her dark adepts will most likely attack next turn.

==Knalgans vs Knalgans==
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24fighter.png A
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24guard.png A
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24gryphon-rider.png A-
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24thunderer%24thunderer.png B
https://units.wesnoth.org/1.15/pics/core%24images%24units%24human-outlaws%24poacher.png B
https://units.wesnoth.org/1.15/pics/core%24images%24units%24human-outlaws%24thief.png C
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24ulfserker.png C
https://units.wesnoth.org/1.15/pics/core%24images%24units%24human-outlaws%24footpad.png E

<div class="thumb tleft">https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24fighter.png</div>
A tough battle. Dwarves have great defense, and no way to combat great defense. The high HP and the resistances will make this a game needing a lot of strikes to kill. Don't think you'll be able to rush in and win - you're going to need intelligent unit placement and again, some luck. Focus on levelling (non-Gryphon) units if possible as the added damage will be needed.

Recruit a Gryphon, a Guardsman, a Thunderer, a Fighter, an Ulfserker, and a mix of other useful units. This game will be won through fighting from hills and mountains, getting and keeping a money advantage, leveling a unit, and waiting for your opponent to take a risk that they shouldn't. Keep them off of your mountains at any cost. If they get there you will spend precious moves, attacks, and HP trying to take them off. It's usually better to ignore enemies on mountains than to fight them.

* '''Dwarvish Ulfserker:''' As always, one of these utility guys isn't a bad buy. Catch a Thunderer off his perch, or a Thief or Poacher in daytime, and that's one less unit to deal with. However, Fighters and other units can defeat Ulfserkers

* '''Dwarvish Fighter:''' These guys are a must. Use it against any unit. These guys are hard to kill.

* '''Dwarvish Guardsman:''' Use these to hold villages and frustrate your opponent.

* '''Dwarvish Thunderer:''' Use these to besiege enemy villages or poke at DFs or Gryphons.

* '''Thief:''' Not a good buy unless used to counter Thunderers and Poachers. Their blade attack does little to Dwarves unless backstabbing at night (8-3). Better to use Dwarvish Fighters for melee. No good target for thieves and only costly unit, gryphons, are too strong.

* '''Poacher:''' An alright cheap buy for ranged forest grabbing.

* '''Footpad:''' Don't buy this unit even if your opponent is bothering you with Gryphons. You can get 3+ Footpads for the price of 2 Gryphons, but it's not worth it. The weakness to Impact guarantees at least a 4-2 attack with these guys even in daytime, but unfortunately, unless you get bonus hp from traits, they will die in 2 hits from Gryphons, so it is still a risky buy - especially since they are useless against all other Knalgans. Just say no once again.

* '''Gryphon Rider:''' Useful as your only scout unit. Use these to get behind enemy lines to village steal, kill the wounded, or to pin a Dwarf on bad terrain. These guys are also good forest and plains holders for crucial areas that your Dwarves will fare poorly on.

== Knalgans vs Drakes ==
https://units.wesnoth.org/1.15/pics/core%24images%24units%24human-outlaws%24poacher.png A
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24thunderer%24thunderer.png A
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24guard.png A-
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24fighter.png B
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24ulfserker.png B
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24gryphon-rider.png B
https://units.wesnoth.org/1.15/pics/core%24images%24units%24human-outlaws%24thief.png D
https://units.wesnoth.org/1.15/pics/core%24images%24units%24human-outlaws%24footpad.png E

<div class="thumb tleft">https://units.wesnoth.org/1.15/pics/core%24images%24units%24drakes%24fighter.png</div>
These guys are big and nasty. They will burn you, while saurians may try to freeze you as well. Thunderers and poachers will be your main weapon against drakes, but they will require support units as well. Dwarves are generally better against physical damage than against elemental ones.

Recruit a Gryphon and a good mix of Dwarvish Thunderers, Dwarvish Guardsmen, a Poacher or two, and maybe a Dwarvish Fighter. Your opponent will likely get some Saurian Augurs to take away your high defense advantage, so having that Dwarvish Fighter around to take them out is usually quite helpful along with the Gryphon. Basically, recruit Pierce, Pierce, and more Pierce.

* '''Dwarvish Ulfserker:''' Good for killing Augurs, scouts, and maybe Burners. Not really a good choice against Drakes in general (because drakes can damage it faster than it can damage them), but can serve some purposes. One ranged attack from burner may drop their health low, so they will have to heal themselves and not attack for a turn or two.

* '''Dwarvish Fighter:''' A good unit to use against saurians, but generally the Fighter is not how you want to go against Drakes.

* '''Dwarvish Guardsman:''' Guardsmen are worth the price against Drakes. Their Pierce goes right through Drake resistances, and a Strong one actually gets an additional point of damage. They are not that great against Clashers of course, but they can survive hits from them. A couple of these are a good buy, especially if you plop them on villages.

* '''Dwarvish Thunderer:''' This should be your unit of choice versus Drakes. A Thunderer does 20-1 damage to Drakes in ranged, and Burners will do (6/5/3)-4 damage in return. Thunderers have much better defense than Burners, but do suffer from having 8 less HP. Thunderers have the benefit of costing 4 less gold. You'll want to use their "luck" attack on the easily hit Drakes as much as possible. Thunderers should be the meat of your army.

* '''Thief:''' Not really useful against the Drakes, they are best used to counter Saurian Augurs, which are better countered by using Dwarvish Fighters.

* '''Poacher:''' Another great unit against Drakes. Their attack at night deals a good 5-4 against all Drakes. Having better defense on Forest and villages, 1 or 2 of these guys aren't a bad idea. Another possibility is to mass them and clear everything with exception of saurians, which can be killed with ulfserkers.

* '''Footpad:''' Don't recruit this unit when fighting Drakes, with exception of taking villages from drakes.

* '''Gryphon Rider:''' Useful for early village grabbing, Gryphons also can be used against the weak Saurians or Drake Burners. These fliers are probably the only way you'll hunt down retreating hurt Drakes. Don't recruit too many due to their cost and lack of a ranged defensive weapon. Drakes can pin these units far better than any other faction.

Maintain your advantageous defensive terrain as much as possible, because if you don't, and you put yourself on an even playing field in that respect, you will quickly be torn apart by the Drakes superior daytime damage and HP. The daytime onslaught will be brutal, so prepare for a counter-attack and try to keep your Guardsmen up front to get best use of their Steadfast. It will be the difference between 7-4 and 6-4 daytime Burner damage and 6-4 to 5-4 daytime non-strong Clasher damage. The Guardsmen also have 8 more HP than the Thunderers. If you can level a Guardsman (with 4 kills at 70% xp, or 3 kills and 1 battle if he's Intelligent), you will have a serious roadblock to use at your disposal. Also upgraded Poachers to Trappers might be great for improved ranged, melee and HPs.

==Knalgans vs Dunefolk==
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24fighter.png A
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24ulfserker.png B-
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24thunderer%24thunderer.png A
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24guard.png C+
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24gryphon-rider.png
https://units.wesnoth.org/1.15/pics/core%24images%24units%24human-outlaws%24footpad.png E
https://units.wesnoth.org/1.15/pics/core%24images%24units%24human-outlaws%24poacher.png C
https://units.wesnoth.org/1.15/pics/core%24images%24units%24human-outlaws%24thief.png D

<div class="thumb tleft">https://units.wesnoth.org/1.15/pics/core%24images%24units%24dunefolk%24soldier%24soldier.png</div>
Dunefolk is faster than your dwarves, but slower than footpads and gryphons. Dunefolk is a ranged oriented faction, so you will suffer a lot by their attack. There is only one thing you can do - kill them with melee attacks and have better economy.

Both factions have a good unit for many situation, but only you have a unit with berserk. Knalgans are good in defense, so keep your villages from enemy fast dune riders.

* '''Dwarvish Ulfserker:''' Skirmishers, Burners and Herbalists are vulnerable to blade and not the best melee fighters overall. Use Ulfs against them. However, many Dunefolk guys are lawful or liminal, so use time of the day to your advantage. Dune Soldiers are a big threat, as well as Rovers, when time is right for them.

* '''Dwarvish Fighter:''' Good against pierce, blade and impact damage make them your main unit. Similar to ulfserkers, you can use their blade attack against three units vulnerable to blade.

* '''Dwarvish Guardsman:''' Defending villages? Sure. And they are even good against Dune Riders. Weak in attacking.

* '''Dwarvish Thunderer:''' Generally well usable unit. They can retaliate against ranged attacks, so enemy will probably attack other units. Use it to your advantage and keep them in front.

* '''Thief:''' Another good melee attacker against Burners and Herbalists. They are very vulnerable to ranged attack, so probably the best way to use them is when you have only 13 gold and need a unit.

* '''Poacher:''' Ranged unit with very weak melee damage. Use them if you can find good terrain, but they are not something you really need in this match. Also use them if Dune Riders become a problem.

* '''Footpad:''' Too weak to do a lot of damage. Enemy have skirmishers, so as a blocking unit this guys are even less important.

* '''Gryphon Rider:''' Fast, strong and expensive. Use them on bigger maps and try to not lose them to the enemy. Gryphons are also good against Burners and Herbalists. It is possible that enemy will try to limit your movement with Dune Riders and Dune Skirmishers.

Recruit a Gryphon, a Guardsman, a Thunderer, a Fighter, an Ulfserker, and a mix of other useful units. This game will be won through fighting from hills and mountains, getting and keeping a money advantage, leveling a unit, and waiting for your opponent to take a risk that they shouldn't. Keep them off of your mountains at any cost. If they get there you will spend precious moves, attacks, and HP trying to take them off. It's usually better to ignore enemies on mountains than to fight them.

You do not have any magic, same as your enemy. So it can be difficult to get to the important enemy units. Frontal attack with ulfserker can kill a herbalist, but ranged attack from enemy units will be deadly and they will also get XP from your dying Ulfserker.

== Specialists ==
How to play specialists: [[How to play Horseman|Horseman]] - [[How to play Mages|Mages]] - [[How to play Skirmishers|Skirmishers]]

[[Category: How to Play]]

How to play Knalgans

2021-06-13T00:33:31Z

Spixi: typo

{{Factionbox}}

<div class="tright" style="width: 300px; height: 300px;>https://units.wesnoth.org/1.15/pics/core%24images%24portraits%24dwarves%24fighter.png</div>

==Dwarvish units==
<b>Dwarvish Fighter</b> is important unit with two melee attacks, so he can choose which one is better. Also, strong front-line unit.
<div class="thumb tleft">https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24fighter.png</div>
* <b>maximum defense and speed in mountains (70%)</b>
* neutral
* <b>strong</b> vs mages, woses, outlaws, ulfserkers; <b>weak</b> vs nobody, usable in any match
* strong melee attack (blade and impact)

<b>Dwarvish Ulfserker</b> is your specialist. He will be killed easily, but he can also kill someone not good in melee fighting.
<div class="thumb tleft">https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24ulfserker.png</div>
* <b>average defenses everywhere</b>, but moves fast in complicated terrain.
* neutral
* <b>strong</b> vs mages, saurians, archers and enemy leaders; <b>weak</b> vs grunts, ghosts, drake clashers
* strong melee attack with '''berserk''' (blade)

<b>Dwarvish Thunderer</b> is a strange unit with powerful, but only one ranged attack.
<div class="thumb tleft">https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24thunderer%24thunderer.png</div>
* <b>maximum defense and speed in mountains (70%)</b>
* neutral
* <b>strong</b> vs drakes and units on wrong terrain; <b>weak</b> vs skeletons
* average melee attack (blade), strong ranged attack (pierce)

<b>Dwarvish Guardsman</b> is a solid defensive unit. When you need someone to guard important hexes, he is your guy. Not very good in attacking. Make sure he can use his steadfast ability.
<div class="thumb tleft">https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24guard.png</div>
* <b>average defenses everywhere</b>
* neutral
* <b>strong</b> vs melee attackers; <b>weak</b> vs ranged attackers
* average melee attack with steadfast (pierce), weak ranged attack (pierce)

<b>Gryphon Rider</b> is very fast, moving quickly in every terrain. Most expensive unit in game.
<div class="thumb tleft">https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24gryphon-rider.png</div>
* <b>good defense in mountains, average on every other terrain, what is awesome.</b>
* neutral
* <b>strong</b> vs retreating wounded units; <b>weak</b> vs multiple enemies, heavy infantry and archers
* strong melee attack (blade)

==Outlaw units==

<b>Footpad</b> is fast. That is his main strenght. Better in scouting than in fighting.
<div class="thumb tleft">https://units.wesnoth.org/1.15/pics/core%24images%24units%24human-outlaws%24footpad.png</div>
* <b>maximum defenses (70%) in many terrains</b>, but vulnerable to pierce, blade and impact weapons
* chaotic
* <b>strong</b> as a blocking and fast moving unit; <b>weak</b> in fighting
* weak melee attack (impact), average ranged attack (impact)

<b>Poacher</b> is a chaotic version of classic human bowman, capable to fight even in swamps. They have much more ranged hits than dwarvish thunderers.
<div class="thumb tleft">https://units.wesnoth.org/1.15/pics/core%24images%24units%24human-outlaws%24poacher.png</div>
* <b>good defenses in many terrains</b>
* chaotic
* <b>strong</b> against drakes and units with no ranged attack; <b>weak</b> in melee fighting
* weak melee attack (blade), strong ranged attack (pierce)

<b>Thief</b> is a very special outlaw. He (or she) can do minimal damage during the day and a lot of damage during the night, when well placed. Also thieves are very cheap.
<div class="thumb tleft">https://units.wesnoth.org/1.15/pics/core%24images%24units%24human-outlaws%24thief.png</div>
* <b>maximum defenses (70%) in many terrains</b>, low hitpoints and vulnerable to pierce, blade and impact weapons
* chaotic
* <b>strong</b> when well placed at night; <b>weak</b> in fighting when backstab cannot be used
* average melee attack with '''backstab''' (blade)

==Starting troops - random opponent==
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24gryphon-rider.png
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24fighter.png
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24fighter.png
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24thunderer%24thunderer.png
https://units.wesnoth.org/1.15/pics/core%24images%24units%24human-outlaws%24footpad.png
https://units.wesnoth.org/1.15/pics/core%24images%24units%24human-outlaws%24thief.png

(100 gold)

Main thing to condider is the price of Gryphons. If you need more of them, than you will have less units in total. With less or no gryphons, you can recruit more powerful dwarves. You can also switch gryphon for ulfserker and thief for a poacher. This combination cost 96 gold.

'''Rogue''' is probably the best leader for the Knalgans. These men and women are very agile, so they can move fast and also run from danger. They can also work wonders with their backstab and skirmisher abilities.

==General Knalgan strategies==

The Knalgans have perhaps the greatest tactical flexibility of any faction. Because of this, there is no one way to play the Knalgans. This can be a good thing or a bad thing, depending on your personality. You can use dwarves for power and defense and outlaws for movement and low prices.

* '''Dwarvish Fighter:''' It can take more hits than most units, making it a great defender. It also has two damage types, making it offensively versatile. It shares the downsides of all dwarves: slow movement (though few terrains slow it down) and low defense on non-specialized terrain.<br>
* '''Dwarvish Thunderer:''' Although powerful, it can just as easily do no damage at all, making this a tricky unit to know how to use. Fortunately, it is almost as durable as the fighter.<br>
* '''Dwarvish Ulfserker:''' This utility unit has value in many match-ups. It will ensure that either its opponent or it dies. Thus, it has a 100% kill chance against a non-melee unit such as the dark adept, and a very high kill chance against many non-melee-centric units, such as the Mage, Saurian Augur, Bowman, Elvish Shaman, and a wide variety of others. The problem is that your opponent can very easily kill an Ulfserker: they will lose to any dedicated melee unit unless very exceptional circumstances are in play (remember that the ulf cannot get nearly as high defensive values as the Dwarvish fighter, for example), starting hitpoints, time of day, or a combination of the above. Since it is an expensive unit, letting an elvish fighter kill your ulf out of the blue is unwise: however if he just killed a Mage and in killing the ulf the fighter is severely weakened, this is obviously a good trade for you. When using Ulfs, plan how you want them to kill and how you want them to die.
* '''Footpad:''' Opinions on the footpad vary widely. In this guide you will not see them recommended often, but many good players consider these a staple unit of the Knalgans. Regardless, this is not a unit you should overrecruit or your offensive power will be very low. It has excellent defense where your dwarves might be very vulnerable and you might not want to risk your more costly riders. Use it for it's great ZoC abilities even if its offense isn't high-powered.<br>
* '''Poacher:''' Also a very useful unit for the Knalgans, this unit provides a reliable ranged attack to counterbalance the power of the thunderer, plus it fills many useful hexes (notably forests and swamps) well.<br>
* '''Thief:''' This unit is possibly the highest damage-dealing unit in your arsenal when used correctly. A strong thief at night does 12-3 damage: the equivalent of a level 2's damage output. However, they have very few hitpoints and their low resists compound this problem. High defense and low cost offset these disadvantages. Remember to backstab with it whenever possible.
* '''Gryphon Rider:''' Possibly the best scout in the game in terms of combat, this is tempered by its high cost. Use it as a lookout for enemy advances and pick off weak or wounded units that are retreating behind enemy lines.<br>

Keep in mind that that the dwarves should stay in mountains, hills, and other high-defense terrain and the outlaws should stay in any non-grassland terrain, if possible. Keep in mind that since your footpads and thieves have 60 defence on grassland, and your enemy will often have 40 or even 30, it can often be to your benefit if the enemy chooses to attack them on open ground.

==Villages==
<div class="thumb tleft">https://raw.github.com/wesnoth/wesnoth/master/data/core/images/terrain/village/human3.png</div>
Outlaws have 70% defense in villages, so they will get little hits. If hitted, they can heal rapidly. Another good unit for holding villages are guardsmen, but only against melee enemies. Use your fastest unit, gryphon rider, to quickly collect villages. If you need gold, you can also recruit a footpad for this job.

==Knalgans vs Loyalists==
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24fighter.png A
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24guard.png A
https://units.wesnoth.org/1.15/pics/core%24images%24units%24human-outlaws%24poacher.png A
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24ulfserker.png B
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24thunderer%24thunderer.png B
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24gryphon-rider.png C
https://units.wesnoth.org/1.15/pics/core%24images%24units%24human-outlaws%24footpad.png C
https://units.wesnoth.org/1.15/pics/core%24images%24units%24human-outlaws%24thief.png C

<div class="thumb tleft">https://units.wesnoth.org/1.15/pics/core%24images%24units%24human-loyalists%24horseman%24horseman.png</div>
Defend in day, strike at night. That's how the battle will go. Beware the Horseman and Mage and be prepared to counter these heavy daytime hitters. Again, an Ulfserker can be your best friend, especially if you can catch a Horseman at night, or a Mage/Bowman anytime.

Recruit a Fighter, a Thunderer, a Guardsman, and a Gryphon depending on the layout of villages. Fill out your army with what you think will serve you best for that particular battle. Water battles will be nearly pointless. Cheap Mermen with higher defense will easily rout your Gryphon(s). Avoid sea battles unless you can taunt a Merman within range of a ranged unit (who can stand on decent terrain). A Gryphon's extra sight is good for spotting long range Horsemen, so it usually is worth having one around, but recruit no more than one. They don't counter any unit very cost-efficiently, so use it primarily as a scout and utility unit.

* '''Dwarvish Ulfserker:''' If you get one, don't get it until turn two or later. Grabbing one in your initial recruit will only make him impotent during the first few turns of daytime. Ulfserkers are what you will use to kill Mages, grind up horse meat at night, and get rid of Bowmen - though they shouldn't be recruiting many. You shouldn't need more than 1 unless they go mad with Mages.

* '''Dwarvish Fighter:''' Good to fight Spearmen, having these guys is a necessity. These are also your best unit to defend against Heavy Infantry.

* '''Dwarvish Guardsman:''' Get one of these guys. These will make your front line immune to Horsemen. Also useful to counter-attack Cavalry, Mages, and Bowmen. If HI get close enough, milk XP off of them with your ranged attack. The level will come faster than you expect.

* '''Dwarvish Thunderer:''' Get one or two. Good against essentially all of the Loyalist units, the pierce ranged is even better against the two mounted units.

* '''Thief:''' These guys can be used against most Loyalist units at night, but avoid trying to backstab Spearmen. Even at night their firststrike can get nasty on this low HP unit. I recommend the Poacher instead of this guy. They might kill mages quickly if well placed.

* '''Poacher:''' A great unit to counterattack Loyalists and press the attack at night. His multiple strikes are of better use against the high defense Fencer, though his ranged pierce is best against the mounted units. His attack does a modest 3-4 to Heavy Infantry at night (compared to a Thunderers 11-1), and you'll want to use this unit against Spearmen outside of day as well. Although they are weak in daytime, they serve many purposes and are well worth the 14 gold.

* '''Footpad:''' Do not recruit this unit when fighting Loyalists. This unit is very useful against heavy infrantrymen, while their low cost and speed allows them to pin enemy units down and occupy terrain. When fighting as a loyalist commander, I find them annoying. Still, the lack of offensive power is a real problem. It is possible that some fights between footpads and fencers will happen. Block during the day, attack during night.

* '''Gryphon Rider:''' Useful as scouts mainly, you can use these to run down hurt horses, go for 1-attack-kills on Fencers (9% chance if they have no bonus hp), or again, to try to hold important grassland hexes. Beware during day though, as HI, Mages, and Horsemen can all tear Gryphons apart quickly. Recruit no more than 1.

You'll want to press as hard as you can at night, more so than even against Drakes. The reason for this is that Loyalists have no level 1 Neutral or Chaotic units. Every unit the opposing player has will suffer a penalty at night - unless he has a Lieutenant behind his front line. Because of this possibility, don't press too close to his castle until you have gained a monetary advantage, as you will start losing units more rapidly when he comes back at you with an additional +25%. Put your Guardsman up front - this will dissuade any charge attacks. Keep a Dwarvish Fighter or Dwarvish Ulfserker nearby in case the player chooses to besiege you with Mages. Spearmen that attack a Guardsman in day will deal nearly equal damage to each other, which can add up quickly. Counter any advance with Thunderers and Poachers. Don't expose your Dwarves to poor terrain or they will die.

You'll want to whittle away at Heavy Infantry with Poachers and Thunderers and you'll want to give the killing blow to a Fighter. Upgrading Dwarvish Fighters should be your main priority as they are your best defense and counter to the easy Spearman-wave attack. Once leveled up, the massive HP on the Steelclad will also give it the ability to withstand attacking Heavy Infantry and Mages.

Basically, Loyalists have an incredible amount of versatility. You'll have to play smart and counterattack very well in order to win. Deal free damage when you can, and limit the number of hexes you can be attacked from - especially during day. Start commencing your attack before night actually breaks. You'll want to maximize your advantage over those 2 turns, so make sure they don't creep away before night hits. As always, stay on good terrain, and make sure Fencers can't skirmish around to kill any weak units you may be hiding.

==Knalgans vs Rebels==
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24fighter.png A
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24ulfserker.png B
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24thunderer%24thunderer.png B
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24gryphon-rider.png B
https://units.wesnoth.org/1.15/pics/core%24images%24units%24human-outlaws%24poacher.png B
https://units.wesnoth.org/1.15/pics/core%24images%24units%24human-outlaws%24thief.png B
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24guard.png D
https://units.wesnoth.org/1.15/pics/core%24images%24units%24human-outlaws%24footpad.png E

<div class="thumb tleft">https://units.wesnoth.org/1.15/pics/core%24images%24units%24elves-wood%24archer.png</div>
This is one of the trickiest match-ups to play. Both factions are Neutral, so neither has an advantageous time of day to attack (with their main units). To win this battle you will need smart recruits and good unit placement, as well as a little luck; the same goes for your opponent. Knalgans may have a slight advantage with the "one unit must die" Ulfserker, but Rebel defense as well as heal, slow, and magic are serious counters. Look for opportunities to grab mountains and hills, especially if they have no forest next to them. ''Forests are your biggest enemy'', so occupy them with your Outlaw counterparts or Gryphons.

* '''Dwarvish Fighter:''' Again, these will be the meat of your forces. Any front without one of these will succumb to Elvish Fighters. Dwarfs beat Elves 1-on-1, but they are more expensive. They are good damage soakers and damage dealers. Stay on preferred terrain at all times.

* '''Dwarvish Ulfserker:''' counters Mages, Elvish Shamans, and oftentimes Elvish Archers. Again, don't recruit too many of these, as Elvish Fighters will easily come back to finish them off, and they are 5 gold cheaper. If you get a chance to take out a Mage, do so. Not only will you gain 1 gold in attrition, but another unit will likely have to expose itself or get hurt to finish you off. Elvish Archers should be #2 on the "to kill" list, and they are sometimes worth jeopardizing your Ulfserker for if you catch one of them off of forest. Again, the reasoning is you only lose 2 gold in the trade and the opponent must waste moves and usually HP in order to finish you. Again, they may also expose themselves. You might be able to get away with ulfing Woses if it's nighttime and you're in a mountain. Make sure he isn't a Quick, Intelligent Ulf, and check the CTK as always.

* '''Dwarvish Thunderer:''' Another staple. This unit is good against Rebels with luck. Stick him on a mountain and Elves will hurt themselves trying to remove you. They aren't so great for dependable offense against the high defense of the elves, but their counter-attacks are great.

* '''Dwarvish Guardsman:''' Guardsmen are great for holding frontline villages and chokepoints - with backup. A lone Guardsman can hold out for a turn, if lucky 2 or 3, while on a town. He deals very little damage in return, especially against the ranged specialized Rebels. Recruit 1 if necessary, and no more than 2. They just aren't worth the lack of offensive/counter-attack units.

* '''Thief:''' You'll want 1 or 2 of these guys depending on your play style. At night, a combo of thieves can destroy Woses, Elvish Archers, Mages, and Shaman. Keep them in the forest hexes your opponent will want, but not in daytime. They can be quickly killed by mages and sharpshooters - if you do not kill them first.

* '''Poacher:''' Poachers are useful to fill up forest hexes and to attack Elvish Fighters. Their main usefulness is as a counter-attacking utility unit to grab forest and press at night. They are cheap, somewhat weak, but deal more dependable offensive damage than the Thunderer. 5-4 at night is equivalent to a 17 gold Elvish Archer, and you only spend 14.

* '''Footpad:''' Don't recruit this unit when fighting Rebels. It lacks both firepower and hitpoints even while in the forests Footpads and Elves both enjoy.<br>

* '''Gryphon Rider:''' These monsters are incredible useful against Rebels. Their utility lies in fighting any water battles against the weak Merman Hunters, scouting, taking opportunistic attacks against poorly placed Elves, and if you find a hurt Wose, you may consider attacking one - even though Gryphons have a weakness for Impact. At night they do essentially equal damage to each other, and you may not be able to get the finishing blow with one of your slower units. Do so as a calculated risk when you only need 1 hit to kill. Otherwise it's quite a risk.

Generally you'll want a healthy dose of Dwarvish Fighters and Thunderers, along with several gryphons for map control. An Ulfserker, perhaps a Guardsman, and some Outlaws will provide added flexibility. Whichever chaotic units (if any) you recruit, make sure to protect them at day.

If your opponent purchases scouts, feel lucky - they are next to useless against you. Beware of ambushes, and don't scout unsure forests with your Gryphon in daytime. Take as much tactical forest as you can with the appropriate units, and make a stranglehold on mountains. Ulf when you get a good chance, and be ready to counter in day as well as pressing at night. Each battle will play out differently in this matchup according to what your opponent recruits, so see what he has early, and keep track of any Woses. Also, do not let your Ulfs be slowed or they are certainly dead.

==Knalgans vs Northerners==
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24fighter.png A
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24ulfserker.png A-
https://units.wesnoth.org/1.15/pics/core%24images%24units%24human-outlaws%24poacher.png A-
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24guard.png A-
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24thunderer%24thunderer.png B
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24gryphon-rider.png B
https://units.wesnoth.org/1.15/pics/core%24images%24units%24human-outlaws%24footpad.png B-
https://units.wesnoth.org/1.15/pics/core%24images%24units%24human-outlaws%24thief.png D-

<div class="thumb tleft">https://units.wesnoth.org/1.15/pics/core%24images%24units%24orcs%24grunt.png</div>
The biggest problem you will have with Northerners will be their numbers. Northies will gladly trade units with you and gain a monetary advantage. Make them depend on luck by staying on good terrain, and their high upkeep may start to become a factor. Both factions are melee-oriented, so they will not have many classic ranged units.

Recruit a Dwarvish Fighter and a mix of other good units. Stay on villages or mountains for the first assault to minimize the effect any poison will have and reduce the chance of it hitting. Let your opponent attack you, and then counter-attack with your Poachers and Thunderers if you have them - even a Guardsman's ranged attack will add up. Send Ulfserkers against Assassins whenever you get a decent chance, as the Poison will hurt more than their melee attacks. If the northerner overrecruits assassins, you should be able to power through his ranks, so normally eliminating an assassin removes the immediate threat of poison.

* '''Dwarvish Ulfserker:''' Recruit one of these guys if you're really having a problem finishing their units off, or your opponent likes to use Assassins. He's expensive, and Northerners are melee oriented, so most of their units will be able to take a majority of this unit's HP away, if not kill him outright. Assassins' Poison will quickly erode your army's HP though, so having one may prove valuable. Since Assassins cost 17 gold you'll only lose 2 in attrition, and you'll likely take lots of hp from another unit with you.

* '''Dwarvish Fighter:''' Again a necessity. His damage dealt in defense is how you'll deal a majority of your damage. If possible, get a rotation of these guys in the front line. You'll deal more damage than your opponent on average, but he will come with more units - 4 Grunts cost the same as 3 DFs.

* '''Dwarvish Guardsman:''' Another good guy to have one of if not more. He can survive nighttime assaults better than the fighter, and will still do respectable damage back to the enemy. Use your ranged attack on Grunts to make them turn around and heal.

* '''Dwarvish Thunderer:''' Nice to have. Their combination of good resistances and ranged damage make them good counter-attackers. For cheaper ranged counter-attackers, use Poachers as they will also be used to hold forest hexes. Recruiting DTs may crowd your hill hexes, especially since that's what the Northies will be grabbing.

* '''Thief:''' Not a great buy against Northies. His melee-only nature along with his Chaotic alignment make him most effective in the same way Northeners are. Avoid the urge to recruit these guys. Also, no costly priority targets from your enemy make this units almost worthless.

* '''Poacher:''' Again, these guys you'll want to recruit a few of. When the Northies come after you at night, you can make a strong counter-attack with their 5-4 ranged.

* '''Footpad:''' This guy can be a utility unit against Northerners, but the money is better spent elsewhere. Footpads can harass Grunts and Wolfs, take forest hexes, and block Assassins from poisoning your Dwarves. Not the best buy, but you may be able to get your money's worth.

* '''Gryphon Rider:''' Again, it's usually good to have one of these guys to scout, plug up grassland, and be a defensive damage dealer. He's also good for trapping/killing Assassins and being a target for their poison. He is very costly, compared to your outlaws and enemy grunts.

The biggest thing you need to worry about will be poison; this cannot be overemphasized. If you get a good foothold on mountains and hills, poison will be the weapon of choice to knock you off your perch. Be ready to fill in with a replacement unit, and try to kill assassins before any other units. Melee strikes will have to get through your resistance - poison does not. You also don't deal any damage back when poison hits you. If you know you're going to be facing poison on the next turn, have a plan for how you will be rotating units to villages to detox and heal.

Allow your opponent to attack you from forest hexes if they are next to mountains that you occupy. Your 70% defense will outdo his 50% defense, and his confidence will be higher to attack since he won't be on grass. Even if an Assassin uses that hex, if an Ulfserker is within reach, he should be able to take him out from on top the mountain.

To kill Trolls, you will want to focus exclusively on them until they die. Thus it is best to ignore them and kill others than to only do a minimal amount of damage to Trolls each turn. Their regeneration will give them essentially limitless HP if you do this. Kill his friends and then focus on him. If there are several, take them out one at a time. Try to avoid water battles with Nagas, unless there is only one. You won't want any Gryphons you get to be pinned, especially where you cannot help them, so be cautious with water battles.

To sum up, kill poisoners fast, get units that deal good melee damage in defense, and get good counter-attacking ranged units

==Knalgans vs Undead==
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24fighter.png A
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24ulfserker.png A
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24thunderer%24thunderer.png B
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24gryphon-rider.png C
https://units.wesnoth.org/1.15/pics/core%24images%24units%24human-outlaws%24footpad.png C
https://units.wesnoth.org/1.15/pics/core%24images%24units%24human-outlaws%24thief.png C
https://units.wesnoth.org/1.15/pics/core%24images%24units%24human-outlaws%24poacher.png D
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24guard.png E

<div class="thumb tleft">https://units.wesnoth.org/1.15/pics/core%24images%24units%24undead-skeletal%24skeleton%24skeleton.png</div>
If you know you're playing against Undead, the smartest thing to do is to recruit a Dwarvish Ulfserker. He will automatically kill any Dark Adept that he attacks. He is also good for taking on Ghouls and Skeleton Archers. Beware of ghosts: at night the phantoms can kill your ulf, although at day your ulf will come out victorious. Here are the units you will want to recruit to counter Undead units:

* '''Dwarvish Ulfserker:''' counters Dark Adepts, and most other undead units in daytime. Don't recruit many unless the opponent has no Skeletons. Skeletons can kill an Ulfserker even in day. Ulfs are also expensive, so you don't want to trade them 1-for-1 with Undead units unless you get a Ghost. Be mindful of what can counterattack them on your opponent's next turn.

* '''Dwarvish Fighter:''' counters Skeletons, Skeleton Archers, and is a generally high HP unit that can soak up nighttime damage for your front line. Dwarvish Fighters are probably the best all-around L1 heavy infantry in the game. If your opponent is smart, however, they will spam ghouls—and the dwarvish fighter really sucks against poison. Their lack of mobility is a major disadvantage; their armor is also ineffective against poison.

* '''Dwarvish Guardsman:''' Do not recruit this unit if you are fighting Undead. His Pierce damage is less useful than even Blade against Undead. His low damage also makes him a bad unit to counter-attack with. Even for pure defense you can use better units in this match.

* '''Dwarvish Thunderer:''' This is a good unit to have in your front line in mountains. His high defense and good resistances should keep him alive from nighttime Skeleton attacks, and his 18-1 ranged will make it very risky for Dark Adepts to come after you. Thunderers are also good to attack Ghosts, as 2 ranged hits will kill a Ghost - this even works at night.

* '''Thief:''' They are only good against dark adepts. Attack adept with thief and finish him with ulfserker or gryphon. Or attack skeleton archer with thief and finish with ulfserker/gryphon/fighter again. Thieves will be much more useful on level 2 as rogues. Still, not the best unit you can have. Ghouls are a real nuisance for you—and the thieves’ high defence (= much better chance to not get poisoned) and higher mobility (= much less time to get to a village and heal) make them ideal for finishing off the toxic undead. Their combination of arcane resistances and high defence are handy against ghosts, especially at night; Like many knalgan units, the thief is situational, and works to fill a particular niche. Do not use them against skeletons, for which you are much better off with fighters.

* '''Poacher:''' A utility unit versus Undead. It's good for finishing Ghosts and killing Walking Corpses. It can also be used to pick at Skeletons and Ghouls. Money is spent better on other units, but don't forget that he may be useful.

* '''Footpad:''' This weak character is really only useful versus Undead as a cheap scout. His Impact damage is good against Skeletons and Skeleton Archers, and he has the added bonuses of being Chaotic (which deals more damage when Undead try to advance at night), and being hard to hit. His best feature is his ranged attack versus Skeletons at night, and that's only 6-2. Recruiting 1 on your first turn to grab villages is likely the only use you'll get from this guy, unless you need a unit to occupy forest hexes (which dwarves do very poorly at 30% defense).

* '''Gryphon Rider:''' Probably not the best expenditure of gold versus Undead, but they do serve many purposes that can justify their cost: they give extended view of battle, allowing you to know what is coming and to counter appropriately; they are good for getting behind enemy lines to finish hurt Dark adepts; and they serve as good ZoC units for plains and forest hexes. Note that this unit is much more useful against ghouls and adepts than against skeletons — the latter’s 40% blade resistance is what really makes them ineffective. But their speed makes them very handy against the former, as they can threaten adepts, work in conjunction with thieves, and heal quickly after being poisoned by a ghoul.

Generally you'll want a good dose of Dwarvish Fighters, a few Thunderers, a Gryphon for vision/utility, an ulf or two, and maybe a Poacher or Footpad. Dwarves are really what you want to use, for their high HP and decent resists. This helps them survive the nighttime onslaught, and their neutrality will give them good damage in defense and also the ability to press the attack in daytime. Don't be afraid to send an Ulfserker at a ghost in daytime - make sure to check the CTK, but it should be good if your Ulfserker is at high hp: bonus if you can get great terrain. Defeat for the Ghost will be nearly certain if the Ulfserker is Strong.

Dark adepts will, as always, be the main danger to your army: they'll knock dwarves out of their mountains, footpads out of wherever, and even gryphons are in danger from them. Be especially mindful of where her dark adepts will most likely attack next turn.

==Knalgans vs Knalgans==
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24fighter.png A
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24guard.png A
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24gryphon-rider.png A-
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24thunderer%24thunderer.png B
https://units.wesnoth.org/1.15/pics/core%24images%24units%24human-outlaws%24poacher.png B
https://units.wesnoth.org/1.15/pics/core%24images%24units%24human-outlaws%24thief.png C
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24ulfserker.png C
https://units.wesnoth.org/1.15/pics/core%24images%24units%24human-outlaws%24footpad.png E

<div class="thumb tleft">https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24fighter.png</div>
A tough battle. Dwarves have great defense, and no way to combat great defense. The high HP and the resistances will make this a game needing a lot of strikes to kill. Don't think you'll be able to rush in and win - you're going to need intelligent unit placement and again, some luck. Focus on levelling (non-Gryphon) units if possible as the added damage will be needed.

Recruit a Gryphon, a Guardsman, a Thunderer, a Fighter, an Ulfserker, and a mix of other useful units. This game will be won through fighting from hills and mountains, getting and keeping a money advantage, leveling a unit, and waiting for your opponent to take a risk that they shouldn't. Keep them off of your mountains at any cost. If they get there you will spend precious moves, attacks, and HP trying to take them off. It's usually better to ignore enemies on mountains than to fight them.

* '''Dwarvish Ulfserker:''' As always, one of these utility guys isn't a bad buy. Catch a Thunderer off his perch, or a Thief or Poacher in daytime, and that's one less unit to deal with. However, Fighters and other units can defeat Ulfserkers

* '''Dwarvish Fighter:''' These guys are a must. Use it against any unit. These guys are hard to kill.

* '''Dwarvish Guardsman:''' Use these to hold villages and frustrate your opponent.

* '''Dwarvish Thunderer:''' Use these to besiege enemy villages or poke at DFs or Gryphons.

* '''Thief:''' Not a good buy unless used to counter Thunderers and Poachers. Their blade attack does little to Dwarves unless backstabbing at night (8-3). Better to use Dwarvish Fighters for melee. No good target for thieves and only costly unit, gryphons, are too strong.

* '''Poacher:''' An alright cheap buy for ranged forest grabbing.

* '''Footpad:''' Don't buy this unit even if your opponent is bothering you with Gryphons. You can get 3+ Footpads for the price of 2 Gryphons, but it's not worth it. The weakness to Impact guarantees at least a 4-2 attack with these guys even in daytime, but unfortunately, unless you get bonus hp from traits, they will die in 2 hits from Gryphons, so it is still a risky buy - especially since they are useless against all other Knalgans. Just say no once again.

* '''Gryphon Rider:''' Useful as your only scout unit. Use these to get behind enemy lines to village steal, kill the wounded, or to pin a Dwarf on bad terrain. These guys are also good forest and plains holders for crucial areas that your Dwarves will fare poorly on.

== Knalgans vs Drakes ==
https://units.wesnoth.org/1.15/pics/core%24images%24units%24human-outlaws%24poacher.png A
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24thunderer%24thunderer.png A
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24guard.png A-
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24fighter.png B
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24ulfserker.png B
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24gryphon-rider.png B
https://units.wesnoth.org/1.15/pics/core%24images%24units%24human-outlaws%24thief.png D
https://units.wesnoth.org/1.15/pics/core%24images%24units%24human-outlaws%24footpad.png E

<div class="thumb tleft">https://units.wesnoth.org/1.15/pics/core%24images%24units%24drakes%24fighter.png</div>
These guys are big and nasty. They will burn you, while saurians may try to freeze you as well. Thunderers and poachers will be your main weapon against drakes, but they will require support units as well. Dwarves are generally better against physical damage than against elemental ones.

Recruit a Gryphon and a good mix of Dwarvish Thunderers, Dwarvish Guardsmen, a Poacher or two, and maybe a Dwarvish Fighter. Your opponent will likely get some Saurian Augurs to take away your high defense advantage, so having that Dwarvish Fighter around to take them out is usually quite helpful along with the Gryphon. Basically, recruit Pierce, Pierce, and more Pierce.

* '''Dwarvish Ulfserker:''' Good for killing Augurs, scouts, and maybe Burners. Not really a good choice against Drakes in general (because drakes can damage it faster than it can damage them), but can serve some purposes. One ranged attack from burner may drop their health low, so they will have to heal themselves and not attack for a turn or two.

* '''Dwarvish Fighter:''' A good unit to use against saurians, but generally the Fighter is not how you want to go against Drakes.

* '''Dwarvish Guardsman:''' Guardsmen are worth the price against Drakes. Their Pierce goes right through Drake resistances, and a Strong one actually gets an additional point of damage. They are not that great against Clashers of course, but they can survive hits from them. A couple of these are a good buy, especially if you plop them on villages.

* '''Dwarvish Thunderer:''' This should be your unit of choice versus Drakes. A Thunderer does 20-1 damage to Drakes in ranged, and Burners will do (6/5/3)-4 damage in return. Thunderers have much better defense than Burners, but do suffer from having 8 less HP. Thunderers have the benefit of costing 4 less gold. You'll want to use their "luck" attack on the easily hit Drakes as much as possible. Thunderers should be the meat of your army.

* '''Thief:''' Not really useful against the Drakes, they are best used to counter Saurian Augurs, which are better countered by using Dwarvish Fighters.

* '''Poacher:''' Another great unit against Drakes. Their attack at night deals a good 5-4 against all Drakes. Having better defense on Forest and villages, 1 or 2 of these guys aren't a bad idea. Another possibility is to mass them and clear everything with exception of saurians, which can be killed with ulfserkers.

* '''Footpad:''' Don't recruit this unit when fighting Drakes, with exception of taking villages from drakes.

* '''Gryphon Rider:''' Useful for early village grabbing, Gryphons also can be used against the weak Saurians or Drake Burners. These fliers are probably the only way you'll hunt down retreating hurt Drakes. Don't recruit too many due to their cost and lack of a ranged defensive weapon. Drakes can pin these units far better than any other faction.

Maintain your advantageous defensive terrain as much as possible, because if you don't, and you put yourself on an even playing field in that respect, you will quickly be torn apart by the Drakes superior daytime damage and HP. The daytime onslaught will be brutal, so prepare for a counter-attack and try to keep your Guardsmen up front to get best use of their Steadfast. It will be the difference between 7-4 and 6-4 daytime Burner damage and 6-4 to 5-4 daytime non-strong Clasher damage. The Guardsmen also have 8 more HP than the Thunderers. If you can level a Guardsman (with 4 kills at 70% xp, or 3 kills and 1 battle if he's Intelligent), you will have a serious roadblock to use at your disposal. Also upgraded Poachers to Trappers might be great for improved ranged, melee and HPs.

==Knalgans vs Dunefolk==
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24fighter.png A
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24ulfserker.png B-
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24thunderer%24thunderer.png A
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24guard.png C+
https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24gryphon-rider.png
https://units.wesnoth.org/1.15/pics/core%24images%24units%24human-outlaws%24footpad.png E
https://units.wesnoth.org/1.15/pics/core%24images%24units%24human-outlaws%24poacher.png C
https://units.wesnoth.org/1.15/pics/core%24images%24units%24human-outlaws%24thief.png D

<div class="thumb tleft">https://units.wesnoth.org/1.15/pics/core%24images%24units%24dunefolk%24soldier%24soldier.png</div>
Dunefolk is faster than your dwarves, but slower than footpads and gryphons. Dunefolk is a ranged oriented faction, so you will suffer a lot by their attack. There is only one thing you can do - kill them with melee attacks and have better economy.

Both factions have a good unit for many situation, but only you have a unit with berserk. Knalgans are good in defense, so keep your villages from enemy fast dune riders.

* '''Dwarvish Ulfserker:''' Skirmishers, Burners and Herbalists are vulnerable to blade and not the best melee fighters overall. Use Ulfs against them. However, many Dunefolk guys are lawful or liminal, so use time of the day to your advantage. Dune Soldiers are a big threat, as well as Rovers, when time is right for them.

* '''Dwarvish Fighter:''' Good against pierce, blade and impact damage make them your main unit. Similar to ulfserkers, you can use their blade attack against three units vulnerable to blade.

* '''Dwarvish Guardsman:''' Defending villages? Sure. And they are even good against Dune Riders. Weak in attacking.

* '''Dwarvish Thunderer:''' Generally well usable unit. They can retaliate against ranged attacks, so enemy will probably attack other units. Use it to your advantage and keep them in front.

* '''Thief:''' Another good melee attacker against Burners and Herbalists. They are very vulnerable to ranged attack, so probably the best way to use them is when you have only 13 gold and need a unit.

* '''Poacher:''' Ranged unit with very weak melee damage. Use them if you can find good terrain, but they are not something you really need in this match. Also use them if Dune Riders become a problem.

* '''Footpad:''' Too weak to do a lot of damage. Enemy have skirmishers, so as a blocking unit this guys are even less important.

* '''Gryphon Rider:''' Fast, strong and expensive. Use them on bigger maps and try to not lose them to the enemy. Gryphons are also good against Burners and Herbalists. It is possible that enemy will try to limit your movement with Dune Riders and Dune Skirmishers.

Recruit a Gryphon, a Guardsman, a Thunderer, a Fighter, an Ulfserker, and a mix of other useful units. This game will be won through fighting from hills and mountains, getting and keeping a money advantage, leveling a unit, and waiting for your opponent to take a risk that they shouldn't. Keep them off of your mountains at any cost. If they get there you will spend precious moves, attacks, and HP trying to take them off. It's usually better to ignore enemies on mountains than to fight them.

You do not have any magic, same as your enemy. So it can be difficult to get to the important enemy units. Frontal attack with ulfserker can kill a herbalist, but ranged attack from enemy units will be deadly and they will also get XP from your dying Ulfserker.

== Specialists ==
How to play specialists: [[How to play Horseman|Horseman]] - [[How to play Mages|Mages]] - [[How to play Skirmishers|Skirmishers]]

[[Category: How to Play]]

How to play Drakes

2021-06-13T00:25:09Z

Spixi: fix copy paste error

{{Factionbox}}

<div class="tright" style="width: 300px; height: 300px;>https://units.wesnoth.org/1.15/pics/core%24images%24portraits%24drakes%24fighter.png</div>

==Drake units==
<b>Drake Glider</b> is the fastest scouting unit. Gliders are quick, can breath fire and they have better defenses in terrain than other drakes.
<div class="thumb tleft">https://units.wesnoth.org/1.15/pics/core%24images%24units%24drakes%24glider.png</div>
* <b>average defences</b>, low hitpoints, can move quickly over almost any terrain.
* lawful
* <b>strong</b> vs wounded units and skeletons; <b>weak</b> vs archers, dark mages and saurians
* weak melee attack (impact), weak ranged attack (fire)

<b>Drake Burner</b> have great fire attack, so he can burn his enemies. Even more powerful during day.
<div class="thumb tleft">https://units.wesnoth.org/1.15/pics/core%24images%24units%24drakes%24burner.png</div>
* <b>low defences</b>, also expensive and vulnerable.
* lawful, can be upgraded into 2 useful units (leader or stronger drake)
* <b>strong</b> against anyone with no ranged attack; <b>weak</b> vs archers, dark mages and saurians
* weak melee attack (blade), strong ranged attack (fire)

<b>Drake Clasher</b> is armored, without inner breath or ability to fly. They are good in hand-to-hand combat.
<div class="thumb tleft">https://units.wesnoth.org/1.15/pics/core%24images%24units%24drakes%24clasher.png</div>
* <b>low defenses</b>, but slowed only by forests
* lawful, can be upgraded into 2 useful units (Thrasher or Arbiter)
* <b>strong</b> in 1v1 battles; <b>weak</b> vs archers, dark mages and saurians
* strong melee attack (blade AND pierce)

<b>Drake Fighter</b> is a mixture of Crasher and Burner. Fast attacker with powerful swords, that can fly and use fire.
<div class="thumb tleft">https://units.wesnoth.org/1.15/pics/core%24images%24units%24drakes%24fighter.png</div>
* <b>low defenses</b>, all around useful unit
* lawful, can be upgraded into a useful unit (Warrior)
* <b>strong</b> against outlaws, assassins and mages; <b>weak</b> vs archers, dark mages and saurians
* strong melee attack (blade), weak ranged attack (fire)

==Saurian units==
<b>Saurian Skirmisher</b> is fast and very agile. Can ignore ZOC (Zone of Control) and attack even units protected by another units.
<div class="thumb tleft">https://units.wesnoth.org/1.15/pics/core%24images%24units%24saurians%24skirmisher%24skirmisher.png</div>
* <b>good defenses</b>, but low hitpoints
* chaotic
* <b>strong</b> against drakes, cavalry and mages; <b>weak</b> against almost everyone and vulnerable to blade attack
* strong melee attack (pierce), weak ranged attack (pierce)

<b>Saurian Augur</b> is a fragile, yet very useful unit. Augurs can heal other units and use rare cold damage.
<div class="thumb tleft">https://units.wesnoth.org/1.15/pics/core%24images%24units%24saurians%24augur%24augur.png</div>
* <b>good defenses</b>, but low hitpoints
* chaotic, can be upgraded into 2 2 useful units (stronger Oracle or a better healer)
* <b>strong</b> against against anyone with no ranged attack; <b>weak</b> in 1vs1 fights
* weak melee attack (impact), medium magical ranged attack (cold)

==Starting troops - random opponent==

https://units.wesnoth.org/1.15/pics/core%24images%24units%24drakes%24glider.png
https://units.wesnoth.org/1.15/pics/core%24images%24units%24drakes%24clasher.png
https://units.wesnoth.org/1.15/pics/core%24images%24units%24drakes%24fighter.png
https://units.wesnoth.org/1.15/pics/core%24images%24units%24drakes%24fighter.png
https://units.wesnoth.org/1.15/pics/core%24images%24units%24saurians%24skirmisher%24skirmisher.png
https://units.wesnoth.org/1.15/pics/core%24images%24units%24saurians%24augur%24augur.png
<br>(100 gold)

Two fighters have both advantages and disadvantages, yet this is the best setup you can have for 100 gold. Units like Drake Burners are good against random opponent, but they are very expensive (and you will have only 5 units). On big maps, you can also change one Fighter for another Glider.

Drakes have three rational choices about leaders. Warriors, like '''Fire Drake''' or '''Drake Crasher''', are useful, if you really plan to attack with them. If not, '''Drake Flare''' is a good choice with his leadership. If villages are sparse or you have to defend early on, '''Saurian Soothsayer''' is good for you. He must be protected, because he is both a good healer and a terrible fragile unit.

== General Drake Strategies ==
Drakes generally win by dealing the most damage. Your units are big and deadly, but they're also more expensive than most; also, they're relatively fragile for their cost and many have a specific vulnerability to piercing weapons. Take advantage of having the best mobility in the game by placing your units in hard-to-access places such as behind mountains or across water from your opponent. You'll then have the advantage by being able to decide when and where battles will happen. Your major disadvantage is how easily your units will take damage. Because of this you'll usually want to be the aggressor in battle to kill a unit or two, get damaged, and then flee to heal. Having a mobile healer helps with this if villages are sparse.

Since you trade your defense for other abilities, fighting battles where your opponent has low defense will give you a greater advantage than it will for any other faction. If your opponent refuses to leave 70% defensive terrain, go heavy on the saurians rather than the drakes and attack at night.

It's good to note that the drake faction has exceptional potential for leader-kill situations. This is due to their high damage and mobility, combined with low defense, and also the availability of skirmisher units.

Drakes have access to blade, pierce and impact attacks, same as any other faction. However, their saurian augurs can use '''cold''' attack. Multiple drakes can use '''fire''' attack.

==Villages==
<div class="thumb tleft">https://raw.github.com/wesnoth/wesnoth/master/data/core/images/terrain/village/human3.png</div>
Take villages with your flying drakes or agile saurians, but you should know, that sometimes you cannot hold them. Use your mobility. Take another village. And another. In battle, your drakes will get hits very often, so make sure some villages are close to the battleline. Also, you can get your saurian leaders to the villages, where they have 50% defense (more than drakes).

==Drakes vs Loyalists==
https://units.wesnoth.org/1.15/pics/core%24images%24units%24saurians%24skirmisher%24skirmisher.png A
https://units.wesnoth.org/1.15/pics/core%24images%24units%24drakes%24clasher.png A-
https://units.wesnoth.org/1.15/pics/core%24images%24units%24saurians%24augur%24augur.png A-
https://units.wesnoth.org/1.15/pics/core%24images%24units%24drakes%24fighter.png B
https://units.wesnoth.org/1.15/pics/core%24images%24units%24drakes%24glider.png B
https://units.wesnoth.org/1.15/pics/core%24images%24units%24drakes%24burner.png D

<div class="thumb tleft">https://units.wesnoth.org/1.15/pics/core%24images%24units%24human-loyalists%24horseman%24horseman.png</div>
Drakes' weaknesses are so obvious that it seems the enemy barely has to think to come up with an effective strategy. So things like massing armies of only spearmen or dark adepts have some chance of succeeding.

But, that doesn't necessarily mean the drakes are weaker - they are just harder to play correctly. The key to playing drakes vs loyalist is carefully managing the HP of your units. Get a lot of use out of them before retreating/rotating. This means you will need to carefully plan the formation of your offensive wedges, for example, considering the optimal location for '''Saurian Augurs'''.

'''Tactics'''

Fighting a '''spearmen''' rush with drakes is one of the big problems for a drake player - massing '''spearmen''' gives them at least 10% more strenght per gold than anything you can muster (the spearmen are cheap and they have pierce weapons), and the loyalist player can win the game by playing pretty straighforwardly - while the drakes can still win - but only if they play it smart, because the spearmen also have their drawbacks.
The biggest weakness of the loyalists (and in the same time the biggest advantage of the drakes) is their mobility. Of course, '''horsemen''' are fast too, but you have pretty good counters for the horsemen - clashers and skirmishers (the later only when they are on good terain). Sure, horsemen deal 18-2 base charge on dusk/dawn but your cheaper '''clashers''' and '''skirmishers''' will strike 14-4 and 10-4 back respectfuly when charged, so your oponnent will take a big, unacceptable risk charging them unless he has spearmen or other units to soften them first. So the real problem are the spearmen, not the horsemen.

Note that the because of this mobility issue the outcome of the drakes vs loyalists duel is somewhat dependant on the size of the map - 2 loyalists v 2 drakes on Isar's Cross gives a significant advantage for the Loyalists, while on big maps like Cynsaun Battlefield the drakes are the ones having an advantage.

The second thing that the drakes have over the loyalists is ther dual alighnment, while the loyals are all lawful. You can use that to your advantage as well.

To fight a bunch of '''spearman''', you have to (and if you play it right, you should always be capable to do so) attack first, under favourable condtions. You can play without buying too many '''burners''', only a few to initiate the attack without taking much retaliation and then you have a good chance to cover them with other units, because if a burner can be attacked from 3 or even 2 sides by spearmen it will likely die in a single turn. '''Burners''' are too expensive to throw away that way. You can either buy mostly '''Saurians''', in which case you can skip the burners all together and buy '''augurs''' for range which is magical. In that case you should attack at night and pull back at day, preferably out of reach of the spearmen. You should be very careful about the terrain you put your saurians on - both '''augurs''' and '''skirmishers''' - and also about the placement of the units, namely the augurs attack from the middle so that they can be attacked from as few sides as possible and that they are able to heal both each other and the other units around them. '''Drake clashers''' and '''fighters''' are also necessary as meatshields although you should think carefully before attacking the spearmen with them, even as finishers - remember the firststrike. The choice between clashers and fighters is yours. Remember that the '''fighters''' are generally better on larger maps and maps that have water on them, cause they can fly quickly from one side to another with their 6 movement, but they have a pierce vulnerabilty and less HP; while '''clashers''' are both more durable and also more expensive and slower - but although they have only 5 movement, same as the '''spearmen''', '''clashers''' have a better movetype than the spearmen or other loyalists - '''spearmen''' get slowed down in forest, hills, mountains and sand, while clashers get slowed only when moving through the forest. That means that in most cases - but not always - the clasher can safely escape from the battle if the oponnent doesn't have any fast units.

The other way is to recuit mostly drakes and but a few saurians. In this case, some '''burners''' are necessary. Then the plan again is to strike first and to strike when the oportunity arises. Ignore the time of day. Dont get involved in a protracted everyone vs. everyone battles - thats what the spearmen want - that way they can easily use their advantages - good HP, good attack and cheapness in their favour and your more expensive (and fewer) drakes have a good chance of being overrun in several turns. Try to attack their weak spots - places where a unit is on bad tearain or, even better, far from the others - but as always think ahead of the possible enemy retaliation - attack only when the possible gain is bigger that the possible loss, and run when needed. If there aren't any weak spots, be creative and try to make some depending upon the current situation - put your '''drake fighters''' in positions that threatens the unguarded enemy villages to strech their line thin so that you can attack and run before helps arrives or if you think its worth it, sneak a '''skirmisher''' in the enemy rear on a suicide mision to steal villages.

* '''Drake Burner''': If opponent has horsemen around, then burners will be like big red target signs; but still, you probably need one of them, so keep it behind the main army until it can be used safely. Good unit against Heavy Infandryman, but expensive.

* '''Drake Glider''': Steal villages. Finish of fencers with precise attack, if loyalists recruits some. Do not fight for villages, fly to others. Loyalists does not have any cheap units to send after you.

* '''Drake Clasher''': They kill infandry and protect weaker units. Use their ZOC to cover for your more offensive (and also fragile) units.

* '''Drake Fighter''': Strong unit, but can be easily killed by horsemen and mass of spearman. Do not recruit a lot of them, unless enemy does not have any good counter.

* '''Saurian Skirmisher''': Very agile, your main unit to fight during the night. Make sure they will not fight Heavy Infandryman. They are also your best unit to defend villages.

* '''Saurian Augur''': Weak, but not as weak against spearman, your main enemy. You can use his attack to harm or even kill fencers or other units with good defences.

'''Team game'''

If you happen to be playing a team game and face a '''spearmen''' rush with drakes a good thing is to ask your ally to send you a couple units which have good pierce ressistance like '''HI/Wose/Skeletons'''.
He/she wont mind, especially if you send a few good drakes in return. Then your oponnent will be sorry of recruiting in such a one-minded way. Sure he can get counters to those units as well but those are mostly units with fire which are on the other side weak against the drakes. So the threats of some of his '''spearmen''' being pwned by the '''wose''' or the '''mage''' being torn apart by your '''clasher''' would be stronger than the possibility of your drakes being overrun by his spearmen on the long run.

==Drakes vs Rebels==
https://units.wesnoth.org/1.15/pics/core%24images%24units%24drakes%24clasher.png A
https://units.wesnoth.org/1.15/pics/core%24images%24units%24saurians%24augur%24augur.png A
https://units.wesnoth.org/1.15/pics/core%24images%24units%24drakes%24glider.png B
https://units.wesnoth.org/1.15/pics/core%24images%24units%24drakes%24burner.png B
https://units.wesnoth.org/1.15/pics/core%24images%24units%24drakes%24fighter.png B
https://units.wesnoth.org/1.15/pics/core%24images%24units%24saurians%24skirmisher%24skirmisher.png B

<div class="thumb tleft">https://units.wesnoth.org/1.15/pics/core%24images%24units%24elves-wood%24archer.png</div>
Playing Drakes in this matchup can be difficult. Your units have low defense and are weak to Pierce where the Rebels have high defense and use Pierce. You'll want to recruit a mix of drakes and saurians so that their neutrality doesn't become an advantage at any time of day. Take cheap shots when you can, because they will always be taking cheap shots at you. Rebels are neutral, what is good for you. Your drakes will get the same damage, so it is easier to calculate. During day, it is your time and if you do not do a lot of damage, they will hard press you during the night.

* '''Drake Burner''': This unit is a great weapon to take out Elvish Fighters and they absolutely massacre Woses. Effective in both melee and ranged combat, this unit is always useful against Rebels on attack or defense. He costs 21g though, and there are other units you will need to recruit to be successful. Rebels will surely recruit a lot of archers, if they see that you have a lot of burners.

* '''Drake Clasher''': The only drake without a weakness to Pierce, this unit is great against Rebels. He will tear through Archers and he will beat EFs in a fight. He will overpower any Rebel and it's essential to have these guys in your force.

* '''Drake Glider''': Good for their movement, and can be useful to get to those hard to reach hexes to get extra shots at Archers or Shamans. Recruit according to map need for scouts.

* '''Drake Fighter''': Useful as a mobile fighter, the Fighter is what you'll want if there are 2 separate battlefields within close flying range of each other. The ability to leave one battle to help the other is quite useful, which is true of Burners as well, though they move slower. For pure fighting power the Clasher is better, and he is hardier. If mobility is necessary on the map though, get 1 or 2 of these guys. They can be easily slowed and killed with arrows. They are good against woses and mages, but generally taking woses against drakes is not a good idea.

* '''Saurian Augur''': These guys are essential to fighting Rebels. They are the only easy way you'll have of taking elves out in forest terrain. Augurs have distressingly low HP, so keep them behind the line to heal your power units, or fort him up in forest hexes your opponent will want. Using these guys as your first attackers at night will allow you to get their damage in and then move other units in front of them and consequently heal.

* '''Saurian Skirmisher''': Useful mainly against Scouts, Archers, and Mages at night, don't recruit too many of this unit even if you're tempted. They're fragile units. Elvish fighters kills saurians easily, but if opponent use much more archers than fighters, this unit can be good.

'''Tactics'''

On the first turn you'll want to recruit a Clasher, a Burner, an Augur, and a mix of other units like another Clasher, or a Skirmisher. During daytime you'll want to deal as much damage as possible, as that's when you'll have the advantage. Elves fighting you will suffer massive return damage during the day. Keep your units away from places where the Rebels can use forest to attack you from, and remember to have your Augur(s) heal.

At night you can still be aggressive with Augurs. You'll probably want to retreat your drakes slightly and put any Skirmishers (or even Clashers) you have up front on good terrain. Don't be afraid to keep a mobile unit up front either if it can survive 1 round of attacks; if it can do this and survive it will slow the progress of your enemy and you can easily fly the unit back behind your line to heal. Always make sure that the front line cannot be attacked from forest hexes if possible, though this won't be as big a deal if you have several Augurs to cut through their defense. Don't be afraid to trade a Skirmisher for an Archer if you get a chance to kill one on poor terrain: you'll get a gold advantage as well as taking out the most dangerous unit the Rebels have against you.

Another strategy is to strike hard at day and then completely retreat at night. Keep your units just out of reach of your opponent and allow them to come closer to your recruits to make your counter-attack swifter and more deadly. This strategy is often quite effective as it prevents your drakes from fighting at unfavorable TOD and it allows you to decide how the first battle takes place.

Generally your targets to kill will start with Archers, as they are the most deadly unit to your forces (especially to Clashers). Next you'll want to get rid of any low-HP units your opponent has and any units on poor terrain making themselves targets. Try to keep your Clashers away from Shamans if possible (Slow seriously messes them up), and ignore Fighters if another unit presents itself as an equally appealing target. Elvish Fighters (or even Elish Heroes) can't deal significant damage to your drakes without taking a good amount of return damage, so let them hurt themselves on you while you take out units that you won't receive much return damage from (Burners on Fighters at day though can be quite devastating).

Generally, pick your spots where the advantage presents itself that you can deal the most damage with little return damage if possible. Keep Elves from Forest hexes if possible, and use your advantageous mobility. And, what is important, do not let Shaman to advance, because your enemy will get a good healing or a very powerful unit with arcane attack against you.

==Drakes vs Northerners==
https://units.wesnoth.org/1.15/pics/core%24images%24units%24drakes%24clasher.png A
https://units.wesnoth.org/1.15/pics/core%24images%24units%24saurians%24augur%24augur.png A
https://units.wesnoth.org/1.15/pics/core%24images%24units%24drakes%24fighter.png A-
https://units.wesnoth.org/1.15/pics/core%24images%24units%24drakes%24burner.png B+
https://units.wesnoth.org/1.15/pics/core%24images%24units%24drakes%24glider.png B
https://units.wesnoth.org/1.15/pics/core%24images%24units%24saurians%24skirmisher%24skirmisher.png C

<div class="thumb tleft">https://units.wesnoth.org/1.15/pics/core%24images%24units%24orcs%24grunt.png</div>
This matchup can be rather interesting. The main thing you generally worry about is the cheap northerner units and the expensive drake units. Drakes have much better units but unfortunately they are expensive. Often when you lose vs. Northerners it is because of the sheer number of units they are capable of sending. Grunts, Whelps, Goblin Spearmen and Orcish Archers are cheaper than any unit of your own.

* '''Drake Burner''': A very useful unit during the day and even effective at night vs Grunts and Troll Whelps and Wolf Riders due to their lack of ranged defense. And with at least 7-2 melee, they have the ability to defend their melee attacks. Be very careful with the number of burners you recruit though, because they are rather expensive and you need to be able to defend against the sheer number of units Northerners are able to send.

* '''Drake Clasher''': The Drake Clasher is preferable over the Drake Fighter in most cases, and especially when playing against Northerners. The Clasher is best to defeat those pesky and annoying assassins. Even though they cannot defend against ranged attacks, their 6-4 pierce attack will definitely hurt an assassin as the assassin has -20% to pierce. Clashers have high amounts of HP and can be very effective in fighting northerners, even though it will normally be melee against melee much of the time. Clashers can be cured from poison with help from Saurian healers.

* '''Drake Glider''': You can often use maybe one or two gliders in the original recruiting to get to villages quickly. They can also be useful as a very mobile though small increment of damage that can aid in damage in setting up kills to level other units. I'll also use them for gaining info on recruits.

* '''Drake Fighter''': If you need a unit and can't wait for an extra turn, Drake Fighters are good to recruit because they are quicker then Clashers and have at least minor defense with their ranged attack, and occasionally offense when you just need to deal that little bit of extra damage to make the kill and can't afford to risk a melee attack. They can be easily poisoned, but can also move quickly to near villages.

* '''Saurian Augur''': These units are pretty effective and very useful, but do not keep them in the front of the battle. Use them behind other units to heal and to finish off with magical attacks. These units are easy to level and very effective with 8-3 magical and heal. Be careful in general with saurians because they do not have large amounts of HP. Grunts and Wolf Riders are a primary threat.

* '''Saurian Skirmisher''': Because of their small amount of HP you should try to refrain from using Skirmishers; however they can be helpful at times. They are pretty effective level 2 units. Saurians are cheap, but Grunts are even cheaper and have more HP. Skirmishers are vulnerable to both blade and to impact of the Trolls.

'''Tactics'''

Your first turn depends highly on the map, experience percentage, and gold per village. Try to get all villages on the 3rd turn and then recruit depending on the units you see from your opponent.

==Drakes vs Undead==
https://units.wesnoth.org/1.15/pics/core%24images%24units%24saurians%24skirmisher%24skirmisher.png A
https://units.wesnoth.org/1.15/pics/core%24images%24units%24drakes%24burner.png A-
https://units.wesnoth.org/1.15/pics/core%24images%24units%24drakes%24clasher.png A-
https://units.wesnoth.org/1.15/pics/core%24images%24units%24drakes%24fighter.png A-
https://units.wesnoth.org/1.15/pics/core%24images%24units%24drakes%24glider.png B
https://units.wesnoth.org/1.15/pics/core%24images%24units%24saurians%24augur%24augur.png E or B+ (based on variant)

<div class="thumb tleft">https://units.wesnoth.org/1.15/pics/core%24images%24units%24undead-skeletal%24skeleton%24skeleton.png</div>
Playing as Drakes in this matchup is dramatic, bloody fun. The deadliest matchup in Wesnoth, this game will quickly result in lots of casualties. Both factions are incredibly offensive and of opposite alignment. Skeletons are vulnerable to fire, Dark Adepts have no melee attack, and Drakes are vulnerable to pierce and cold. Whoever is left standing wins. You have to know what exactly is going your way.

* '''Drake Burner''': You'll want a couple of these to burn Skeletons, Ghosts and Ghouls mainly -- but don't pit them against Adepts. Even burning Skeleton Archers at daytime isn't a bad idea as it's the most effective way to kill them. The most expensive unit you can recruit, you'll want to recruit them sparingly and be careful to keep them alive. It is important to get a '''Drake Flare''', because your units under leadership are GREAT against low health Dark Adepts.

* '''Drake Clasher''': With strong Clashers dealing an awesome 9-4 Pierce damage during the day, these are great at butchering Adepts, as well as being damage soakers. Due to their price, you'll need to avoid recruiting too many. Level one of these into a Thrasher and Skeletons won't pose a major threat any more, even at night. Clashers are the slowest of the Drakes, though, and may have trouble catching quick Adepts at daytime or escaping them at night.

* '''Drake Glider''': Dealing Impact melee and Fire ranged damage, these guys won't be worthless at any point, but their damage is still very weak compared to what the rest of your army can do. Recruiting too many of them isn't smart. As in any other match-up, their main role is scouting. Their defense on terrain is better than for other drakes, but magical attacks from adepts is an exception.

* '''Drake Fighter''': Cheaper and faster than the Clasher, the Fighter is a good Adept-killer, with good melee damage in the form of 9-3 or 10-3 war blades at daytime. Their speed and ability to fly make them better at catching the retreating Undead at day, and escaping from them at night. The Fire ranged attack also gives them a bit of flexibility in their usage. They die quickly to concentrated attack from multiple dark adepts, so kill them before they kill you. Also their weak ranged attack can help other units, like saurians, to defeat the adepts. Do not attack skeletons and ghouls in melee combat.

* '''Saurian Augur''':

''VARIANT A'': Don't recruit this unit when fighting Undead. It's too fragile against melee.

''VARIANT B'': Buy at least 2 of them, so they can heal/cure each other and also help all your drakes to fight longer. Undead have access to poison and they can steal your villages with bats, so a mobile healer is a must, if you can protect them from multiple sides. Very effective on semi closed maps, less effective on open maps with lots of flat lands.

* '''Saurian Skirmisher''': This little guy actually plays a very crucial role in your army against Undead. If the Undead didn't have Adepts you'd simply roll right over them. But since Adepts are such a necessary unit in their attack against you you'll need to take them out, and you'll need to be able to do that under any circumstances. The Skirmisher gives you a weapon that not only can hustle around enemy units to strike protected Adepts, but he also gets better at night - the time when you'll want them to be dead the fastest. Having a couple of these guys around can really save your butt.

'''Tactics'''

On the first turn you'll want a couple Burners, a Fighter or Clasher, a Skirmisher, and another useful unit. If your opponent gets mass Skeleton Archers, get Clashers and Burners. If he gets lots of Adepts get Skirmishers and Fighters. If he likes Ghouls & Ghosts, you'll want Burners.

Deal as much damage as you can at day, because you won't be dealing much at night. Keep Burners in front as they'll do great return damage to any Adepts that try to counter-attack you during your daytime assault: they'll do 12-2 while you do 7-4. Adepts have 28 base hp.

At night simply retreat out of Adept range and have Skirmishers ready to take out any that get too close. Even if you have to retreat from a village to avoid Adepts it's worth it. You may lose a few gold, but it shouldn't add up to the 16+ you'd lose for a lost Drake. If your opponent takes the village and moves closer he'll also be closer to your new recruits to counter-attack. As day turns chase them away and you should net some gold for the units your opponent will have to replace.

Also, use Gliders to get villages. Enemy bats does not have ZOC, so you can easily get more and more villages. Remember, that your units are very expensive and you need more villages than your enemy.
==Drakes vs Knalgans==
https://units.wesnoth.org/1.15/pics/core%24images%24units%24drakes%24clasher.png A
https://units.wesnoth.org/1.15/pics/core%24images%24units%24saurians%24augur%24augur.png A
https://units.wesnoth.org/1.15/pics/core%24images%24units%24drakes%24burner.png B
https://units.wesnoth.org/1.15/pics/core%24images%24units%24drakes%24fighter.png B
https://units.wesnoth.org/1.15/pics/core%24images%24units%24saurians%24skirmisher%24skirmisher.png C
https://units.wesnoth.org/1.15/pics/core%24images%24units%24drakes%24glider.png D

<div class="thumb tleft">https://units.wesnoth.org/1.15/pics/core%24images%24units%24dwarves%24fighter.png</div>
Knalgans have some unpleasant surprises for you. Thunderers are dangerous, because drakes does not have good deffense in any terrain. But they are not the only problem. Poachers are very fast, very cheap and very good when attacking drakes. You should try to outmanuver your opponent, what is sometimes easier said than done.

To destroy drakes, Knalgans need only few units. So the biggest threats are '''thunderers''' (against drakes), '''poachers''' (same) and '''ulfserkers''' (against saurians and almost dead drakes). They will probably do not mass guardsman (because you have a lot of ranged units), thieves (because they are better against saurians, but other units are deployed with same thing in mind) or gryphon riders (because of the price). Footpads are useless against drakes.

* '''Drake Burner''': Burners are useful, because most dwarves only have 10% resistance to fire, and against fighters and 2/3rds of the outlaws you will not take retaliation damage. They are also fast. Just be careful not to lose them, as they are 21 gold and the knalgan player will happily trade an ulfserker or fighter for him.

* '''Drake Clasher''': Clashers uses are twofold. Firstly, use them to defend your villages from fast moving footpads and poachers. Secondly, add them to your attacking force with Drake Fighters to deal a good amount of damage. Clashers are okay as long as you don't get them in Thunderer range, which is hard considering their slow speed.

* '''Drake Glider''': Use for village grabbing. They can also take down weakened ulfserkers and then flight to village.

* '''Drake Fighter''': Cheaper and faster than the Clasher, the Fighter has a decent ranged attack. Though they are created as a melee based unit, use both, as the Knalgans are primarily melee.

* '''Saurian Augur''': This unit should be used for healing. If you get the chance, use one of them to land the killing blow on another unit. Don't leave them out on Flat, though.

* '''Saurian Skirmisher''': Good for killing injured units and for its +30% pierce resistance, but isn't that durable. Do not get them close to ulfserkers and dwarvish fighters.

'''Tactics''': If your opponent spams Thunderers, you can usually outmaneuver him with your drakes, or if he sends them out, you can kill them easily. Thunderers are also surprisingly good in melee fight against saurians. Try to kill them with multiple clashers.

'''Team play''': Ally with slow (like elvish shamans) or poison (like orcish assassins) are very useful against the knalgans.

== Drakes vs Drakes ==
https://units.wesnoth.org/1.15/pics/core%24images%24units%24drakes%24clasher.png A
https://units.wesnoth.org/1.15/pics/core%24images%24units%24saurians%24augur%24augur.png A
https://units.wesnoth.org/1.15/pics/core%24images%24units%24saurians%24skirmisher%24skirmisher.png A
https://units.wesnoth.org/1.15/pics/core%24images%24units%24drakes%24fighter.png B-
https://units.wesnoth.org/1.15/pics/core%24images%24units%24drakes%24glider.png D
https://units.wesnoth.org/1.15/pics/core%24images%24units%24drakes%24burner.png E

<div class="thumb tleft">https://units.wesnoth.org/1.15/pics/core%24images%24units%24drakes%24fighter.png</div>
This is possibly the deadliest mirror match in the game.

Saurians have low HP, but deal good damage to their Drake counterparts. You'll want a balanced mix of both races as you'll likely be fighting at all times of the day and night. In this match, you need pierce (and blade against saurians) damage more than fire.

* '''Drake Burner''': Generally a bad recruit in this matchup. Burners cannot do significant damage to other Drakes, though they do get free shots on Clashers. They can also torch any Saurians found on bad terrain, which is unlikely, though this is probably their greatest use. Burners cost a lot.

* '''Drake Clasher''': This unit should make up the bulk of your forces. Dealing heavy Pierce damage and having the most hp out of any recruit (as well as not having a negative Pierce resistance), makes him the beast of burden in this matchup. Hope that yours get the Strong and Resilient traits and his get the Quick and Intelligent traits. The Clasher will beat Fighters and Burners 1v1, and the only units he needs to fear are Augurs and other Clashers, and Skirmishers at night.

* '''Drake Glider''': As with the Burner, this unit is a poor recruit. It has no upside other than the inconsequential Marksman on his breath attack. Do not recruit them unless the map is huge and mobility becomes critically important.

* '''Drake Fighter''': Not the best recruit, but he can be handy if the map makes Clashers slow. They can also tear Augurs to pieces, so if Augurs become a problem a few of these are an alright recruit. Also good as a replacement for the Glider for village grabbing, especially if Quick. Fight between Fighters and Skirmishers is usually very quick, so if you decide to go for it, make sure you attack first.

* '''Saurian Augur''': An essential unit. Their Cold magic deals 9-3 damage to Drakes at night, ripping them to pieces. Their healing will also be essential if used properly, as this is a bloody fight. Be careful not to over-recruit these guys, as they are quite weak in defense against any unit. Two Augurs can heal one another.

* '''Saurian Skirmisher''': These guys are also a good troop type to have, but again, don't recruit too many. Your Pierce damage should mainly come from your Clashers, but a couple of Skirmishers to attack opposing Augurs as well as Drakes at night can prove very valuable, especially with their high defense. Their ability to get behind the enemy lines gives you more hexes to attack the enemy from. They can kill retreating costly drakes and upgraded version can work as a shield for your expensive drakes, when placed on good terrain.

'''Tactics'''

On the first turn you'll want several Clashers, a couple Saurians, and possibly a Fighter or Glider to grab villages. Village distribution will determine if you need a Glider or not, as well as map size.

At night, use your Augurs on the opposing Clashers first, using your Clashers and Skirmishers to finish up. Make sure to protect your Augurs though, as they die easily, even at night. Killing a Clasher will remove a major threat come daytime, as well as net you 19 gold. If you must trade a Skirmisher to kill a Clasher at night, it can often be worth it.

At day you'll want to attack first with your Augurs again. Their Cold magic will do 6-3 in daytime to Drakes, which is still quite powerful. Follow up with your now incredibly deadly Clashers: Strong Clashers in day will deal 10-4 to any non-Clasher Drake.

Generally, this is the danger level of your enemy units: Clasher, Augur, Skirmisher, Fighter, Burner, Glider. You may choose to either target the deadliest units first (Clashers being easy targets for Augurs), or go for the weaker units first to give yourself a monetary advantage quickly, while receiving little retaliation damage. Either strategy can work, and levelling an Augur can prove exceptionally deadly to your opponent. Intelligent Augurs level within 2 kills. Whichever strategy you use, be sure to kill, and not just hurt your opponent, because your opponent will flee and have the unit return to fight again.

==Drakes vs Dunefolk==
https://units.wesnoth.org/1.15/pics/core%24images%24units%24drakes%24clasher.png A
https://units.wesnoth.org/1.15/pics/core%24images%24units%24saurians%24augur%24augur.png A
https://units.wesnoth.org/1.15/pics/core%24images%24units%24drakes%24glider.png B
https://units.wesnoth.org/1.15/pics/core%24images%24units%24drakes%24fighter.png C+
https://units.wesnoth.org/1.15/pics/core%24images%24units%24saurians%24skirmisher%24skirmisher.png C+
https://units.wesnoth.org/1.15/pics/core%24images%24units%24drakes%24burner.png D

<div class="thumb tleft">https://units.wesnoth.org/1.15/pics/core%24images%24units%24dunefolk%24soldier%24soldier.png</div>
Dunefolk is similar to loyalists or rebels. They have enough pierce to kill your drakes and enough blade, impact and fire to kill your saurians. They have fast and dangerous cavalry. But they do not have what you have - wings. Be careful, dunefolk units are fast in desert hexes.

* '''Drake Burner''': Good, but not great. Dune riders are faster, cheaper and have pierce. Skirmishers and rowers are also good against this strong, but vulnerable and expensive drake.

* '''Drake Clasher''': Clashers are great. Dunefolk have some strange vulnerabilities, so strong unit with multiple types of attack is exactly what you want. Take them to the battlefield!

* '''Drake Glider''': Fast, good for village grabbing, but not resilient enough. Many dunefolk units are effective against them.

* '''Drake Fighter''': Similar weaknesses like burners and gliders. Do not recruit a lot of them. Good against herbalists.

* '''Saurian Augur''': Don't leave them out on Flat, because fast cavalry can kill them easily. If you are going for a slow push with lots of Clashers, these are your guys. Weak to Dune Burners, but who will go for dune burners against drakes?

* '''Saurian Skirmisher''': They can kill or at least force riders to pull back. Good skirmisher against Dune skirmishers and herbalists. Do not take too many.

'''Tactics''': Two possibilities. Play with everything, or go for slowpush. Slowpush with clashers, augurs and 2-3 fast units (gliders or fighters) might work well on maps with small quantity of water.

== Specialists ==
How to play specialists: [[How to play Horseman|Horseman]] - [[How to play Mages|Mages]] - [[How to play Skirmishers|Skirmishers]]

[[Category: How to Play]]

EasyCoding

2016-08-12T22:50:39Z

Spixi: /* Enhancements to Existing Actions */ Implemented by PR#170

'''We are permanently updating this page. Parts marked by <s>strikeout</s> will likely be deleted shortly.

This page is here to document easy to do coding tasks. It is not here to double the feature request database, and should only be filled by people that know the code well enough to judge the difficulty of a given task.

If you are such a person, you should feel free to edit this page.

If you're not, you should post a feature request and discuss your idea on the forum or IRC. A coder with better knowledge of the code might give you the green light to add your feature here.

Anybody should feel free to add "clues" to any tasks, that is entry points, traps to avoid, person to contact to discuss and so on.

If you plan to work on a feature, write your name at the bottom of the feature, with the date. Note that if you are too long at working on a feature we'll "free" it back (that is if you're not working on it. If you have problems implementing it, just tell us....)

If none of these are to your liking, feel free to check our [http://gna.org/bugs/?group=wesnoth bug tracker] with a broad spectrum of tasks.

== Engine related features ==

=== Make a "map diff" tool to visualizes changes between two version of a map ===

Maintainers of maps often make small tweaks for balance purposes. For someone who doesn't know the map like the back of their hand it may be very difficult to spot exactly what changed. There isn't any really good way to do this right now -- using the 'diff' tool at command line doesn't give good results for .map files.

Such a tool would be helpful for someone who maintains a map pool containing maps made by others, also for someone who wants to browse a repository and examine balance changes on several maps, which could be instructive for someone who wants to make and balance their own maps.

There's any number of ways to actually do this, one might be to have a feature in the map editor that takes the name of another map and adds map labels to indicate what hexes changed. It could also be a command accessible in debug mode when playing the game, or it could be an additional command-line argument (--diff [map1] [map2] ?) for the game. (It could be a standalone application but that's probably going to end up with much more work for you.)

Henry Stone (3/17/16)

== MP related features ==

=== Add possibility to switch off mod dependency checking ===
MP modifications can define dependencies. Currently there's no way to force a "broken" configuration, although overzealous use of the system by UMC authors could make this feature useful. Add an option to the MP game creation screen to switch on/off dependency checking. Ask lipk (forum)/lipkab (IRC).

=== Make a header for the add-on when we organize scenarios by add-on in the MP create dialog ===

Using an established GUI technique to signal when one block of scenarios for an add-on ends and the next begins would make it much easier to use this dialog, if the user has several add-ons.

See one proposal here:
https://gna.org/bugs/?21653

Note that we still intend to move the mp lobby to gui2, it might make sense to adress this while doing that porting (which is not easy)

=== Timer pause button ===

Longstanding feature request here:
https://gna.org/bugs/?16733

Request is for either a button, or a simple chat command like :pause, :unpause, to allow players to put the timer on hold if they are interrupted.

Ideally would be accompanied with a multiplayer-only scenario attribute "number_of_pauses" which decreases each time a client pauses the game. Pause should use a blindfold object to black out the screen, and send a chat message automatically when it occurs / resume occurs. For an example of how it might look, start a local hotseat mp game and enable the Preferences->General->Turn Dialog option. (This behavior was introduced in this commit: https://github.com/wesnoth/wesnoth/commit/bab03d554bea92f1ce6f585ef1123202173a3491)

Wintermute/happygrue also has other ideas about how the timer should/could work. For example, instead of their client ending their turn, the networked opponents could be required to "confirm" the time out. (This is probably a networked MP-only idea.)

A very fancy implementation might instead of a counter, allow the other players to vote on whether a pause request is granted.

Make sure that the paused client still responds to network commands, so that it is possible to kick a person who pauses and then doesn't ever unpause.

=== Add a "concede" button ===

Often times in mp, players concede the game before their leader is actually killed. When the game ends 'officially' the map is revealed, which can sometimes be instructive for the losing player. Additionally, it makes it easier to analyze the results of many games, for purposes of balancing, or for maintaining a ladder. So while it may seem small, this would actually be a pretty useful feature.

== WML-related features ==

=== Support variable village healing, variable poison properties ===

See a feature request here:

https://gna.org/bugs/index.php?20919

=== Enhancements to Existing Actions ===

<s>* [fire_event] id=X - allow firing an event by id instead of by name</s>

=== Events Manipulation ===

* [event] recognized at the root level of the WML document (outside [scenario]) to define event handlers that are registered for the entirety of a campaign, as opposed to specific scenarios
* [event] persistent="yes" - creates an event that lasts for the rest of the campaign
* [disable_event][/disable_event] disables the event within which it appears (useful with conditionals). A more complex take on first_time_only=yes/no.
''This is largely possible with event IDs, but could be useful when multiple copies of an event should be floating around''

=== Game Information ===

* [query_location] - queries a location from the user
** variable
** [filter_location]
''Regarding [query_location]: probably a better name would be choose_location. This is used when a wml event is running and needs to get a target location hex from the user. For example, you right click on a catapult unit and choose the menu item "fire Catapult." Now a [message] says to click on any target within 5 hexes. Now [choose_location] is encountered and the mouse cursor changes to a target sign (possibly customizable). If the user's mouse drifts outside of the allowed locations it changes to a cancel icon. If the operation is cancelled then the variable is cleared and no location stored. --Sapient''

''This can be implemented in lua by using wesnoth.game_events.on_mouse_action and wesnoth.syncronize_choice''

==== Automatically stored variables ====

* $side_info - auto-stored side information
* $game_info - auto-stored game information
* $map_info - auto-stored map information

== Improvements to AI ==

=== Existing bugs or undesirable features ===

Most of these are probably relatively easy to fix, although we can, of course, not guarantee that.

* Feature: Make the (old) simple aspect syntax work when the Lua engine is defined for a side. Setting aspects in the [side] tag like this:
[ai]
aggression=0.123
[/ai]
does not work if a Lua engine is defined in the tag. You either need to use the [aspect] tag in the [side] tag with 'engine=lua', or use the code above in a [modify_side] tag in an event. Making the above syntax available (as it is with the C++ engine) would be nice. The same also applies to the FAI engine and to aspects set for AI sides in MP games.

* Bug: AI units with 0/0 moves will not attack adjacent enemies: http://gna.org/bugs/?23720

* Feature: Convert E_NOT_REACHED_DESTINATION from an error to a warning.

* Bug of sorts: AI move evaluation on maps with many guardians (units with ai_special=guardian) can take a very long time, even though those guardians don't move at all most of the time.

* Bug: Adding a candidate action mid-term does not include it where it belongs in terms of its evaluation score. Instead, it gets added at the end of the candidate action list and might not be executed on the current turn, because other CAs with lower scores get evaluated first.

*Bug?: not all options/parameters of wesnoth.find_cost_map() work as described [[LuaWML:Pathfinder#wesnoth.find_cost_map|here]]. I don't know if that is a bug in the code or if the description on that page is wrong.

* Mix of bugs and features: ai.get_new_enemy_dst_src and related functions have several problems:
** They use the current moves of the enemy units, which generally are all zero.
** Hexes occupied by other enemy units count as not reachable.
** Units with zero moves are not listed at all, not even for the hex they are on.
** Working around this with a Lua wrapper makes this actually slower than ai_helper.get_enemy_dst_src, which makes the functions pretty much useless, as speed is the only thing speaking for them.

=== Add new features to the AI ===

* Add a cost function to the C++ path finding code that takes avoided hexes into account, that is, hexes defined in an [ai][avoid] tag onto which the AI never moves. Also add an option to the Lua wesnoth.find_path() function with which using this cost functions can be turned on and off.
** The background behind this task is the way how the default AI's move-to-targets candidate action works. It does path finding for units without taking avoided hexes into account, and ''afterwards'' eliminates moves for which the end point falls onto an avoided hex. As a result, some units might not move at all, even if it is, in principle, easily possible to move around an avoided area. The inclusion of the new path-finding in the AI's move-to-targets phase could therefore be a follow-up task.

* Add a Lua function ai.get_individual_attacks() that returns all the single attacks the side can do (as opposed to attack combinations). This needs to include an option to recalculate and take the current situation on the map into account (making the function believe that the game state has changed).

* Set up an option the allows us to exclude units from the move-to-targets phase similar to [filter_own] for the combat phase (other than setting ai_special=guardian, which has a number of other side effects). Actually, having this option for all CA's would be nice.

* Change the aspects "passive_leader", "passive_leader_shares_keep", "leader_ignores_keep" to work with multiple leaders. The idea is to change the type of those aspects from yes/no to string so both "passive_leader=yes" and "passive_leader=leader_id_1,leader_id_2" is possible.

* Add new options (keys or tags) to the Micro AIs. As an example, some (but certainly not all) Micro AIs might benefit from taking some (but certainly not all) of the default AI aspects into account.

* Write a script that automatically changes WML from the deprecated [ai][target] to the new [ai][goal] syntax. Ideally, this would be part of wmllint.
** There are [http://wiki.wesnoth.org/AiWML#Deprecated_AI_Targeting_Aspects more deprecated AI aspect] which should eventually be added to this, but the [target] -> [goal] change would be a good and important start.

== GUI1 features ==

=== Widget changes ===

* Make games sortable in the lobby (open slots, total number of players, era, XP modifier, gold per village, fog/shroud)
* Input history and completion (for in-game and lobby chat, commands, etc.)

== GUI2 features ==

Although mordante developed a new GUI system, GUI2, some dialogs still use the older GUI1 and could be improved or transferred. mordante has since disappeared, leaving GUI2's core code unmaintained; shadowm and vultraz should be able to answer most GUI2 (and even GUI1) related questions in his absence.

* Information on the wiki can be found under [[GUIToolkit]] on the wiki.
* The source code is under src/gui/
* All mainline GUI2 WML resides in data/gui/default/

=== Port the random map generator dialog to GUI2 ===

The map generator currently doesn't use the GUI2 framework, but there's no reason why it couldn't.

== Miscellaneous ==

=== Debug mode ===

* New debug command functionality (setting additional status.variables, possibly terrain)

=== wesnoth-optipng ===

For lossless png compression we use wesnoth-optipng, a script using an external toolchain (ImageMagick, OptiPNG, Advdef). Perhaps the performance could be improved by using PNGOut instead of advdef. This task includes
* a quick profiling of compression ratio and decompression speed for both tools
* if it provides a higher compression while not significantly slowing down decompression, adapt wesnoth-optipng to use PNGOut

== Bugs ==

== See Also ==

[[NotSoEasyCoding]]

[[Category:Development]]
[[Category:Future]]

LuaWML/Events

2016-08-12T22:49:41Z

Spixi: /* wesnoth.fire_event_by_id */ fixed function signature

This page describes the [[LuaWML]] functions and helpers for interacting with events and action handlers.

==== wesnoth.fire ====

* '''wesnoth.fire(''wml_action_name'', ''wml_action_contents'')'''

Fires a [[ActionWML|WML action]]. Argument 1 is the name of the action. Argument 2 is the WML table describing the action. Note: WML variables are substituted.

wesnoth.fire("message", { speaker="narrator", message=_ "Hello World!" })

==== wesnoth.wml_actions ====

This is not a function but an associative table indexed by WML action names. It contains functions performing the corresponding actions. Using these functions is similar to calling [[#wesnoth.fire]], while setting entries of the table is similar to calling [[#wesnoth.register_wml_action]].

function wesnoth.wml_actions.freeze_unit(cfg)
local unit_id = cfg.id or helper.wml_error "[freeze_unit] expects an id= attribute."
helper.modify_unit({ id = unit_id }, { moves = 0 })
end

The new tag can now be used in plain WML code.
[freeze_unit]
id=Delfador
[/freeze_unit]

You can override functions already assigned to the table. This is useful if you need to extend functionality of core tags. For instance, the following script overrides the [[InterfaceActionsWML#Other interface tags|[print]]] tag so that messages are displayed with a bigger font.

function wesnoth.wml_actions.print(cfg)
cfg.size = (cfg.size or 12) + 10
wml_actions.print(cfg)
end

Note: When calling an action handler directly through its function stored in ''wesnoth.wml_actions'', the engine is not involved. As a consequence, whether variable substitution will happen is up to the handler. In particular, if the argument is a plain table, the caller should have substituted WML variables beforehand to be on the safe side. Moreover, table arguments might be modified by the action handler, so they should usually not be reused for consecutive calls. If variable substitution should happen and/or table content should be preserved, one can call [[#wesnoth.tovconfig]] and pass its result to the handler. Calling [[#wesnoth.fire]] is another possibility.

==== wesnoth.wml_conditionals ====

{{DevFeature1.13|0}}

This is an associative table like wesnoth.wml_actions. You can use it to define new conditional wml tags that will be recognized in WML when using [if], [show_if], [while], etc., or more generally when '''wesnoth.eval_conditional''' is run.

Use it like

function wesnoth.wml_conditionals.foo(cfg)
local bar = cfg.bar or error("[foo] tag did not have 'bar' attribute")

return (bar == "baz")
end

If this lua code is executed, it would make the following syntax be valid WML in your add-on:

[if]
[foo]
bar = $X
[/foo]
[then]
[message]
...
[/message]
[/then]
[/if]

You cannot override the meaning of any core conditional tags.

==== wesnoth.game_events ====

This is not a function but an associative table indexed by engine action names. It contains function hooks the engine calls whenever it performs a particular action.

* '''on_save''': function called when the engine (auto)saves a scenario file; it should return a WML table and the children of this table are added to the savefile.
* '''on_load''': function called when the engine loads a scenario file; its argument is a WML table that contains all the children of the savefile that the engine did not handle.
* '''on_event''': function called before each WML event is executed; its argument is the event name; other event arguments can be recovered from [[LuaWML:Misc#wesnoth.current|wesnoth.current.event_context]].

The ''on_save'' and ''on_load'' hooks can be used to manipulate data that are neither meant to be forwarded to the next level nor substituted on the fly. (For either of these two purposes, WML variables are the best choice.) For instance, toplevel tags like [item], [event], [time_area], and so on, could typically be handled by such hooks.

-- some value that survives save/load cycles, but that is not forwarded to the next level
local level_local_data = 0

local old_on_load = wesnoth.game_event.on_load
function wesnoth.game_event.on_load(cfg)
for i = 1,#cfg do
if cfg[i][1] == "my_data" then
-- recover the value stored in the savefile
level_local_data = cfg[i][2].value
-- erase the child, since it has been handled
table.remove(cfg, i)
break
end
end
-- call the previous hook, in case there are still some containers in the savefile
old_on_load(cfg)
end

local old_on_save = wesnoth.game_events.on_save
function wesnoth.game_events.on_save()
-- call the previous hook, in case it had some containers to store
local cfg = old_on_save()
-- add our own container to them
table.insert(cfg, { "my_data", { value = level_local_data } })
-- tell the engine to store them in the savefile
return cfg
end

Note: since the ''on_load'' hook is called very early in the scenario, it cannot be set inside a [lua] tag in an [event], not even a ''preload'' one. It has to be set inside a [lua] tag outside or at [scenario] level.

Note: Some tag names are reserved for engine use and should not be modified using the above on_save/on_load method. These tag names are:
"color_palette", "color_range", "era", "event", "generator",
"label", "lua", "menu_item", "music", "side", "sound_source", "story",
"terrain_graphics", "time", "time_area", "tunnel", "variables"

Note: a on_event handler will not prevent undoing of that event, so usually you need to add an event to diallow undo to prevent OOS. You can add an event handler for that event inside a on_event callback. A possible way to define a disallow_undo function is:
function disallow_undo()
wesnoth.wml_actions.event { name = wesnoth.current.event_context.name }
end
Which should then be called from every on_event callback which changes the gamestate.

{{DevFeature1.13|5}}:
The event names passed to ''on_event'' always use underscores instead of spaces

==== wesnoth.fire_event ====

* '''wesnoth.fire_event(''event_name'', [''x1'', ''y1'', [''x2'', ''y2'']], [''first_weapon'', [''second_weapon'']])'''

Fires all the WML events with the given name. Optional parameters allow passing two locations and two tables. These parameters will be matched against the [filter], [filter_second], [filter_attack], and [filter_second_attack] of any event handler, and are used to fill the WML variables "unit", "second_unit", "weapon", and "second_weapon". These parameters can also be read through ''current.event_context''. The function returns a boolean indicating whether the game state was modified.

wesnoth.fire_event("explosion", 17, 42, { damage = "fire" })

==== wesnoth.fire_event_by_name ====
{{DevFeature1.13|6}}

* Preferred alias of [[#wesnoth.fire_event|wesnoth.fire_event]] to make it more distinguishable from the new function [[#wesnoth.fire_event_by_id|wesnoth.fire_event_by_id]]

==== wesnoth.fire_event_by_id ====
{{DevFeature1.13|6}}

* '''wesnoth.fire_event_by_id(''event_id'', [''x1'', ''y1'', [''x2'', ''y2'']], [''first_weapon'', [''second_weapon'']])'''

Fires a single WML event with the given id. Optional parameters allow passing two locations and two tables. These parameters will be matched against the [filter], [filter_second], [filter_attack], and [filter_second_attack] of the event handler, and are used to fill the WML variables "unit", "second_unit", "weapon", and "second_weapon". These parameters can also be read through ''current.event_context''. The function returns a boolean indicating whether the game state was modified.

wesnoth.fire_event_by_id("explosion_1", 17, 42, { damage = "fire" })

==== wesnoth.add_event_handler ====

* '''wesnoth.add_event_handler(''cfg'')'''

{{DevFeature1.13|0}}

Registers a new event handler. This takes a WML table containing the same information normally used by the [[EventWML#The_.5Bevent.5D_Tag|[event]]] tag.

==== wesnoth.remove_event_handler ====

* '''wesnoth.remove_event_handler(''id'')'''

{{DevFeature1.13|0}}

Removes an event handler. This requires the event handler to have been assigned an [[EventWML#id|id]] at creation time.

==== wesnoth.eval_conditional ====

* '''wesnoth.eval_conditional(''conditional_tags'')'''

Returns true if the conditional described by the WML table passes. Note: WML variables are substituted.

local result = wesnoth.eval_conditional {
{ "have_unit", { id = "hero" } },
{ "variable", { name = "counter", numerical_equals = "$old_counter" } }
}

==== wesnoth.tovconfig ====

* '''wesnoth.tovconfig(''config'')'''

Converts a WML table into a proxy object which performs variable substitution on the fly.

wesnoth.set_variable("varname", "to_be_deleted")
wesnoth.wml_actions.clear_variable { name = "to_be_deleted" } -- correct
wesnoth.wml_actions.clear_variable { name = "$varname" } -- error: try to delete a variable literally called "$varname"
wesnoth.wml_actions.clear_variable(wesnoth.tovconfig { name = "$varname" }) -- correct: "$varname" is replaced by "to_be_deleted" at the right time

==== helper.set_wml_action_metatable ====

* '''helper.set_wml_action_metatable{}'''

Sets the metatable of a table so that it can be used to fire WML actions. Returns the table. The fields of the table are then simple wrappers around a call to [[#wesnoth.fire]].

local W = helper.set_wml_action_metatable {}
W.message { speaker = "narrator", message = "?" }

==== helper.wml_error ====

* '''helper.wml_error(''message'')'''

Interrupts the current execution and displays a chat message that looks like a WML error.

local names = cfg.name or helper.wml_error("[clear_variable] missing required name= attribute.")

==== helper.literal ====

* '''helper.literal(''config'')'''

Returns the ''__literal'' field of its argument if it is a userdata, the argument itself otherwise. This function is meant to be called when a WML action handler can be called indifferently from WML (hence receiving a userdata) or from Lua (hence possibly receiving a table).

function wml_actions.display_literal_value(cfg)
cfg = helper.literal(cfg)
wesnoth.message(tostring(cfg.value))
end

Note: when the argument is a plain table, the function returns it as is. In particular, modifying the fields of the returned table causes the original table to be modified too.

==== helper.parsed ====

* '''helper.parsed(''config'')'''

Returns the ''__parsed'' field of its argument if it is a userdata, the argument itself otherwise. See also [[#helper.literal]].

==== helper.shallow_literal ====

* '''helper.shallow_literal(''config'')'''

Returns the ''__shallow_literal'' field of its argument if it is a userdata, the argument itself otherwise. See also [[#helper.literal]].

==== helper.shallow_parsed ====

* '''helper.shallow_parsed(''config'')'''

Returns the ''__shallow_parsed'' field of its argument if it is a userdata, the argument itself otherwise. See also [[#helper.literal]].

[[Category: Lua Reference]]

LuaWML/Events

2016-08-12T22:48:44Z

Spixi: removed unneccessary newlines

This page describes the [[LuaWML]] functions and helpers for interacting with events and action handlers.

==== wesnoth.fire ====

* '''wesnoth.fire(''wml_action_name'', ''wml_action_contents'')'''

Fires a [[ActionWML|WML action]]. Argument 1 is the name of the action. Argument 2 is the WML table describing the action. Note: WML variables are substituted.

wesnoth.fire("message", { speaker="narrator", message=_ "Hello World!" })

==== wesnoth.wml_actions ====

This is not a function but an associative table indexed by WML action names. It contains functions performing the corresponding actions. Using these functions is similar to calling [[#wesnoth.fire]], while setting entries of the table is similar to calling [[#wesnoth.register_wml_action]].

function wesnoth.wml_actions.freeze_unit(cfg)
local unit_id = cfg.id or helper.wml_error "[freeze_unit] expects an id= attribute."
helper.modify_unit({ id = unit_id }, { moves = 0 })
end

The new tag can now be used in plain WML code.
[freeze_unit]
id=Delfador
[/freeze_unit]

You can override functions already assigned to the table. This is useful if you need to extend functionality of core tags. For instance, the following script overrides the [[InterfaceActionsWML#Other interface tags|[print]]] tag so that messages are displayed with a bigger font.

function wesnoth.wml_actions.print(cfg)
cfg.size = (cfg.size or 12) + 10
wml_actions.print(cfg)
end

Note: When calling an action handler directly through its function stored in ''wesnoth.wml_actions'', the engine is not involved. As a consequence, whether variable substitution will happen is up to the handler. In particular, if the argument is a plain table, the caller should have substituted WML variables beforehand to be on the safe side. Moreover, table arguments might be modified by the action handler, so they should usually not be reused for consecutive calls. If variable substitution should happen and/or table content should be preserved, one can call [[#wesnoth.tovconfig]] and pass its result to the handler. Calling [[#wesnoth.fire]] is another possibility.

==== wesnoth.wml_conditionals ====

{{DevFeature1.13|0}}

This is an associative table like wesnoth.wml_actions. You can use it to define new conditional wml tags that will be recognized in WML when using [if], [show_if], [while], etc., or more generally when '''wesnoth.eval_conditional''' is run.

Use it like

function wesnoth.wml_conditionals.foo(cfg)
local bar = cfg.bar or error("[foo] tag did not have 'bar' attribute")

return (bar == "baz")
end

If this lua code is executed, it would make the following syntax be valid WML in your add-on:

[if]
[foo]
bar = $X
[/foo]
[then]
[message]
...
[/message]
[/then]
[/if]

You cannot override the meaning of any core conditional tags.

==== wesnoth.game_events ====

This is not a function but an associative table indexed by engine action names. It contains function hooks the engine calls whenever it performs a particular action.

* '''on_save''': function called when the engine (auto)saves a scenario file; it should return a WML table and the children of this table are added to the savefile.
* '''on_load''': function called when the engine loads a scenario file; its argument is a WML table that contains all the children of the savefile that the engine did not handle.
* '''on_event''': function called before each WML event is executed; its argument is the event name; other event arguments can be recovered from [[LuaWML:Misc#wesnoth.current|wesnoth.current.event_context]].

The ''on_save'' and ''on_load'' hooks can be used to manipulate data that are neither meant to be forwarded to the next level nor substituted on the fly. (For either of these two purposes, WML variables are the best choice.) For instance, toplevel tags like [item], [event], [time_area], and so on, could typically be handled by such hooks.

-- some value that survives save/load cycles, but that is not forwarded to the next level
local level_local_data = 0

local old_on_load = wesnoth.game_event.on_load
function wesnoth.game_event.on_load(cfg)
for i = 1,#cfg do
if cfg[i][1] == "my_data" then
-- recover the value stored in the savefile
level_local_data = cfg[i][2].value
-- erase the child, since it has been handled
table.remove(cfg, i)
break
end
end
-- call the previous hook, in case there are still some containers in the savefile
old_on_load(cfg)
end

local old_on_save = wesnoth.game_events.on_save
function wesnoth.game_events.on_save()
-- call the previous hook, in case it had some containers to store
local cfg = old_on_save()
-- add our own container to them
table.insert(cfg, { "my_data", { value = level_local_data } })
-- tell the engine to store them in the savefile
return cfg
end

Note: since the ''on_load'' hook is called very early in the scenario, it cannot be set inside a [lua] tag in an [event], not even a ''preload'' one. It has to be set inside a [lua] tag outside or at [scenario] level.

Note: Some tag names are reserved for engine use and should not be modified using the above on_save/on_load method. These tag names are:
"color_palette", "color_range", "era", "event", "generator",
"label", "lua", "menu_item", "music", "side", "sound_source", "story",
"terrain_graphics", "time", "time_area", "tunnel", "variables"

Note: a on_event handler will not prevent undoing of that event, so usually you need to add an event to diallow undo to prevent OOS. You can add an event handler for that event inside a on_event callback. A possible way to define a disallow_undo function is:
function disallow_undo()
wesnoth.wml_actions.event { name = wesnoth.current.event_context.name }
end
Which should then be called from every on_event callback which changes the gamestate.

{{DevFeature1.13|5}}:
The event names passed to ''on_event'' always use underscores instead of spaces

==== wesnoth.fire_event ====

* '''wesnoth.fire_event(''event_name'', [''x1'', ''y1'', [''x2'', ''y2'']], [''first_weapon'', [''second_weapon'']])'''

Fires all the WML events with the given name. Optional parameters allow passing two locations and two tables. These parameters will be matched against the [filter], [filter_second], [filter_attack], and [filter_second_attack] of any event handler, and are used to fill the WML variables "unit", "second_unit", "weapon", and "second_weapon". These parameters can also be read through ''current.event_context''. The function returns a boolean indicating whether the game state was modified.

wesnoth.fire_event("explosion", 17, 42, { damage = "fire" })

==== wesnoth.fire_event_by_name ====
{{DevFeature1.13|6}}

* Preferred alias of [[#wesnoth.fire_event|wesnoth.fire_event]] to make it more distinguishable from the new function [[#wesnoth.fire_event_by_id|wesnoth.fire_event_by_id]]

==== wesnoth.fire_event_by_id ====
{{DevFeature1.13|6}}

* '''wesnoth.fire_event(''event_id'', [''x1'', ''y1'', [''x2'', ''y2'']], [''first_weapon'', [''second_weapon'']])'''

Fires a single WML event with the given id. Optional parameters allow passing two locations and two tables. These parameters will be matched against the [filter], [filter_second], [filter_attack], and [filter_second_attack] of the event handler, and are used to fill the WML variables "unit", "second_unit", "weapon", and "second_weapon". These parameters can also be read through ''current.event_context''. The function returns a boolean indicating whether the game state was modified.

wesnoth.fire_event_by_id("explosion_1", 17, 42, { damage = "fire" })

==== wesnoth.add_event_handler ====

* '''wesnoth.add_event_handler(''cfg'')'''

{{DevFeature1.13|0}}

Registers a new event handler. This takes a WML table containing the same information normally used by the [[EventWML#The_.5Bevent.5D_Tag|[event]]] tag.

==== wesnoth.remove_event_handler ====

* '''wesnoth.remove_event_handler(''id'')'''

{{DevFeature1.13|0}}

Removes an event handler. This requires the event handler to have been assigned an [[EventWML#id|id]] at creation time.

==== wesnoth.eval_conditional ====

* '''wesnoth.eval_conditional(''conditional_tags'')'''

Returns true if the conditional described by the WML table passes. Note: WML variables are substituted.

local result = wesnoth.eval_conditional {
{ "have_unit", { id = "hero" } },
{ "variable", { name = "counter", numerical_equals = "$old_counter" } }
}

==== wesnoth.tovconfig ====

* '''wesnoth.tovconfig(''config'')'''

Converts a WML table into a proxy object which performs variable substitution on the fly.

wesnoth.set_variable("varname", "to_be_deleted")
wesnoth.wml_actions.clear_variable { name = "to_be_deleted" } -- correct
wesnoth.wml_actions.clear_variable { name = "$varname" } -- error: try to delete a variable literally called "$varname"
wesnoth.wml_actions.clear_variable(wesnoth.tovconfig { name = "$varname" }) -- correct: "$varname" is replaced by "to_be_deleted" at the right time

==== helper.set_wml_action_metatable ====

* '''helper.set_wml_action_metatable{}'''

Sets the metatable of a table so that it can be used to fire WML actions. Returns the table. The fields of the table are then simple wrappers around a call to [[#wesnoth.fire]].

local W = helper.set_wml_action_metatable {}
W.message { speaker = "narrator", message = "?" }

==== helper.wml_error ====

* '''helper.wml_error(''message'')'''

Interrupts the current execution and displays a chat message that looks like a WML error.

local names = cfg.name or helper.wml_error("[clear_variable] missing required name= attribute.")

==== helper.literal ====

* '''helper.literal(''config'')'''

Returns the ''__literal'' field of its argument if it is a userdata, the argument itself otherwise. This function is meant to be called when a WML action handler can be called indifferently from WML (hence receiving a userdata) or from Lua (hence possibly receiving a table).

function wml_actions.display_literal_value(cfg)
cfg = helper.literal(cfg)
wesnoth.message(tostring(cfg.value))
end

Note: when the argument is a plain table, the function returns it as is. In particular, modifying the fields of the returned table causes the original table to be modified too.

==== helper.parsed ====

* '''helper.parsed(''config'')'''

Returns the ''__parsed'' field of its argument if it is a userdata, the argument itself otherwise. See also [[#helper.literal]].

==== helper.shallow_literal ====

* '''helper.shallow_literal(''config'')'''

Returns the ''__shallow_literal'' field of its argument if it is a userdata, the argument itself otherwise. See also [[#helper.literal]].

==== helper.shallow_parsed ====

* '''helper.shallow_parsed(''config'')'''

Returns the ''__shallow_parsed'' field of its argument if it is a userdata, the argument itself otherwise. See also [[#helper.literal]].

[[Category: Lua Reference]]

LuaWML/Events

2016-08-12T22:47:09Z

Spixi: /* wesnoth.fire_event */ See PR#710

This page describes the [[LuaWML]] functions and helpers for interacting with events and action handlers.

==== wesnoth.fire ====

* '''wesnoth.fire(''wml_action_name'', ''wml_action_contents'')'''

Fires a [[ActionWML|WML action]]. Argument 1 is the name of the action. Argument 2 is the WML table describing the action. Note: WML variables are substituted.

wesnoth.fire("message", { speaker="narrator", message=_ "Hello World!" })

==== wesnoth.wml_actions ====

This is not a function but an associative table indexed by WML action names. It contains functions performing the corresponding actions. Using these functions is similar to calling [[#wesnoth.fire]], while setting entries of the table is similar to calling [[#wesnoth.register_wml_action]].

function wesnoth.wml_actions.freeze_unit(cfg)
local unit_id = cfg.id or helper.wml_error "[freeze_unit] expects an id= attribute."
helper.modify_unit({ id = unit_id }, { moves = 0 })
end

The new tag can now be used in plain WML code.
[freeze_unit]
id=Delfador
[/freeze_unit]

You can override functions already assigned to the table. This is useful if you need to extend functionality of core tags. For instance, the following script overrides the [[InterfaceActionsWML#Other interface tags|[print]]] tag so that messages are displayed with a bigger font.

function wesnoth.wml_actions.print(cfg)
cfg.size = (cfg.size or 12) + 10
wml_actions.print(cfg)
end

Note: When calling an action handler directly through its function stored in ''wesnoth.wml_actions'', the engine is not involved. As a consequence, whether variable substitution will happen is up to the handler. In particular, if the argument is a plain table, the caller should have substituted WML variables beforehand to be on the safe side. Moreover, table arguments might be modified by the action handler, so they should usually not be reused for consecutive calls. If variable substitution should happen and/or table content should be preserved, one can call [[#wesnoth.tovconfig]] and pass its result to the handler. Calling [[#wesnoth.fire]] is another possibility.

==== wesnoth.wml_conditionals ====

{{DevFeature1.13|0}}

This is an associative table like wesnoth.wml_actions. You can use it to define new conditional wml tags that will be recognized in WML when using [if], [show_if], [while], etc., or more generally when '''wesnoth.eval_conditional''' is run.

Use it like

function wesnoth.wml_conditionals.foo(cfg)
local bar = cfg.bar or error("[foo] tag did not have 'bar' attribute")

return (bar == "baz")
end

If this lua code is executed, it would make the following syntax be valid WML in your add-on:

[if]
[foo]
bar = $X
[/foo]
[then]
[message]
...
[/message]
[/then]
[/if]

You cannot override the meaning of any core conditional tags.

==== wesnoth.game_events ====

This is not a function but an associative table indexed by engine action names. It contains function hooks the engine calls whenever it performs a particular action.

* '''on_save''': function called when the engine (auto)saves a scenario file; it should return a WML table and the children of this table are added to the savefile.
* '''on_load''': function called when the engine loads a scenario file; its argument is a WML table that contains all the children of the savefile that the engine did not handle.
* '''on_event''': function called before each WML event is executed; its argument is the event name; other event arguments can be recovered from [[LuaWML:Misc#wesnoth.current|wesnoth.current.event_context]].

The ''on_save'' and ''on_load'' hooks can be used to manipulate data that are neither meant to be forwarded to the next level nor substituted on the fly. (For either of these two purposes, WML variables are the best choice.) For instance, toplevel tags like [item], [event], [time_area], and so on, could typically be handled by such hooks.

-- some value that survives save/load cycles, but that is not forwarded to the next level
local level_local_data = 0

local old_on_load = wesnoth.game_event.on_load
function wesnoth.game_event.on_load(cfg)
for i = 1,#cfg do
if cfg[i][1] == "my_data" then
-- recover the value stored in the savefile
level_local_data = cfg[i][2].value
-- erase the child, since it has been handled
table.remove(cfg, i)
break
end
end
-- call the previous hook, in case there are still some containers in the savefile
old_on_load(cfg)
end

local old_on_save = wesnoth.game_events.on_save
function wesnoth.game_events.on_save()
-- call the previous hook, in case it had some containers to store
local cfg = old_on_save()
-- add our own container to them
table.insert(cfg, { "my_data", { value = level_local_data } })
-- tell the engine to store them in the savefile
return cfg
end

Note: since the ''on_load'' hook is called very early in the scenario, it cannot be set inside a [lua] tag in an [event], not even a ''preload'' one. It has to be set inside a [lua] tag outside or at [scenario] level.

Note: Some tag names are reserved for engine use and should not be modified using the above on_save/on_load method. These tag names are:
"color_palette", "color_range", "era", "event", "generator",
"label", "lua", "menu_item", "music", "side", "sound_source", "story",
"terrain_graphics", "time", "time_area", "tunnel", "variables"

Note: a on_event handler will not prevent undoing of that event, so usually you need to add an event to diallow undo to prevent OOS. You can add an event handler for that event inside a on_event callback. A possible way to define a disallow_undo function is:
function disallow_undo()
wesnoth.wml_actions.event { name = wesnoth.current.event_context.name }
end
Which should then be called from every on_event callback which changes the gamestate.

{{DevFeature1.13|5}}:
The event names passed to ''on_event'' always use underscores instead of spaces

==== wesnoth.fire_event ====

* '''wesnoth.fire_event(''event_name'', [''x1'', ''y1'', [''x2'', ''y2'']], [''first_weapon'', [''second_weapon'']])'''

Fires all the WML events with the given name. Optional parameters allow passing two locations and two tables. These parameters will be matched against the [filter], [filter_second], [filter_attack], and [filter_second_attack] of any event handler, and are used to fill the WML variables "unit", "second_unit", "weapon", and "second_weapon". These parameters can also be read through ''current.event_context''. The function returns a boolean indicating whether the game state was modified.

wesnoth.fire_event("explosion", 17, 42, { damage = "fire" })

==== wesnoth.fire_event_by_name ====
{{DevFeature1.13|6}}

* Preferred alias of [[#wesnoth.fire_event|wesnoth.fire_event]] to make it more distinguishable from the new function [[#wesnoth.fire_event_by_id|wesnoth.fire_event_by_id]]

==== wesnoth.fire_event_by_id ====
{{DevFeature1.13|6}}

* '''wesnoth.fire_event(''event_id'', [''x1'', ''y1'', [''x2'', ''y2'']], [''first_weapon'', [''second_weapon'']])'''

Fires a single WML event with the given id. Optional parameters allow passing two locations and two tables. These parameters will be matched against the [filter], [filter_second], [filter_attack], and [filter_second_attack] of the event handler, and are used to fill the WML variables "unit", "second_unit", "weapon", and "second_weapon". These parameters can also be read through ''current.event_context''. The function returns a boolean indicating whether the game state was modified.

wesnoth.fire_event_by_id("explosion_1", 17, 42, { damage = "fire" })

==== wesnoth.add_event_handler ====

* '''wesnoth.add_event_handler(''cfg'')'''

{{DevFeature1.13|0}}

Registers a new event handler. This takes a WML table containing the same information normally used by the [[EventWML#The_.5Bevent.5D_Tag|[event]]] tag.

==== wesnoth.remove_event_handler ====

* '''wesnoth.remove_event_handler(''id'')'''

{{DevFeature1.13|0}}

Removes an event handler. This requires the event handler to have been assigned an [[EventWML#id|id]] at creation time.

==== wesnoth.eval_conditional ====

* '''wesnoth.eval_conditional(''conditional_tags'')'''

Returns true if the conditional described by the WML table passes. Note: WML variables are substituted.

local result = wesnoth.eval_conditional {
{ "have_unit", { id = "hero" } },
{ "variable", { name = "counter", numerical_equals = "$old_counter" } }
}

==== wesnoth.tovconfig ====

* '''wesnoth.tovconfig(''config'')'''

Converts a WML table into a proxy object which performs variable substitution on the fly.

wesnoth.set_variable("varname", "to_be_deleted")
wesnoth.wml_actions.clear_variable { name = "to_be_deleted" } -- correct
wesnoth.wml_actions.clear_variable { name = "$varname" } -- error: try to delete a variable literally called "$varname"
wesnoth.wml_actions.clear_variable(wesnoth.tovconfig { name = "$varname" }) -- correct: "$varname" is replaced by "to_be_deleted" at the right time

==== helper.set_wml_action_metatable ====

* '''helper.set_wml_action_metatable{}'''

Sets the metatable of a table so that it can be used to fire WML actions. Returns the table. The fields of the table are then simple wrappers around a call to [[#wesnoth.fire]].

local W = helper.set_wml_action_metatable {}
W.message { speaker = "narrator", message = "?" }

==== helper.wml_error ====

* '''helper.wml_error(''message'')'''

Interrupts the current execution and displays a chat message that looks like a WML error.

local names = cfg.name or helper.wml_error("[clear_variable] missing required name= attribute.")

==== helper.literal ====

* '''helper.literal(''config'')'''

Returns the ''__literal'' field of its argument if it is a userdata, the argument itself otherwise. This function is meant to be called when a WML action handler can be called indifferently from WML (hence receiving a userdata) or from Lua (hence possibly receiving a table).

function wml_actions.display_literal_value(cfg)
cfg = helper.literal(cfg)
wesnoth.message(tostring(cfg.value))
end

Note: when the argument is a plain table, the function returns it as is. In particular, modifying the fields of the returned table causes the original table to be modified too.

==== helper.parsed ====

* '''helper.parsed(''config'')'''

Returns the ''__parsed'' field of its argument if it is a userdata, the argument itself otherwise. See also [[#helper.literal]].

==== helper.shallow_literal ====

* '''helper.shallow_literal(''config'')'''

Returns the ''__shallow_literal'' field of its argument if it is a userdata, the argument itself otherwise. See also [[#helper.literal]].

==== helper.shallow_parsed ====

* '''helper.shallow_parsed(''config'')'''

Returns the ''__shallow_parsed'' field of its argument if it is a userdata, the argument itself otherwise. See also [[#helper.literal]].

[[Category: Lua Reference]]

LuaWML

2016-08-12T22:39:07Z

Spixi: /* Events and WML actions */ See PR#710

{{WML Tags}}

== The '''[lua]''' tag ==

This tag is a part of [[ActionWML]], thus can be used inside [event] and at other places where [[ActionWML]] can be used. It makes it possible to write actions with the [http://www.lua.org Lua 5.2] language.

It is also possible to put this tag inside a [scenario] [[ScenarioWML]], those tags will be executed immideately when the lua engine loads which is even before the scenario preload event is fired.

{{DevFeature1.13|0}}
[lua] is now also allowed in [era] and [modification] those [lua] tags are then copied into the [scenario]/[multiplayer] when it is played just like [event]s inside [era] or [modification]

The tag supports only the '''code''' key, which is a string containing the Lua scripts. Since Lua makes usage of the quotes and the { and } symbols, it is certainly wise to enclose the script between stronger quotes, as they prevent the preprocessor from performing macro expansion and tokenization.

[lua]
code = << wesnoth.message "Hello World!" >>
[/lua]

The Lua kernel can also be accessed from the [[CommandMode|command mode]]:

:lua local u = wesnoth.get_units({ id = "Konrad" })[1]; u.moves = 5

The '''[args]''' sub-tag can be used to pass a WML object to the script via its variadic local variable "'''...'''".

[lua]
code = << local t = ...; wesnoth.message(tostring(t.text)) >>
[args]
text = _ "Hello world!"
[/args]
[/lua]

== Global environment ==

All the Lua scripts of a scenario share the same global environment (aka Lua state). For instance, a function defined in an event can be used in all the events that happen after it.

[event]
name = preload
first_time_only = no
[lua]
code = <<
function narrator(t)
-- Behave like the [message] tag.
wesnoth.fire("message",
{ speaker = "narrator", message = t.sentence })
end
>>
[/lua]
[/event]

[event]
name = turn 1
[lua]
code = << narrator(...) >>
[args]
sentence = _ "Hello world!"
[/args]
[/lua]
[lua]
code = << narrator(...) >>
[args]
sentence = _ "How are you today?"
[/args]
[/lua]
[/event]

In the example above, the redundant structure could be hidden behind macros. But it may be better to simply define a new WML tag.

[event]
name = preload
first_time_only = no
[lua]
code = <<
-- The function is now placed in the wesnoth.wml_actions table
-- The tag is [narrator], same as the function name
function wesnoth.wml_actions.narrator(t)
-- Behave like the [message] tag.
wesnoth.fire("message",
{ speaker = "narrator", message = t.sentence })
end
>>
[/lua]
[/event]

[event]
name = turn 1
[narrator]
sentence = _ "Hello world!"
[/narrator]
[narrator]
sentence = _ "How are you today?"
[/narrator]
[/event]

The global environment is not preserved over save/load cycles. Therefore, storing values in the global environment is generally a bad idea (unless it has been redirected to WML variables, see [[LuaWML:Variables#set_wml_var_metatable|helper.set_wml_var_metatable]]). The only time assigning global variables (including function definitions) makes sense is during a [[EventWML#Predefined 'name' Key Values|preload]] event, as this event is always run. Therefore, helper functions defined at that time will be available to all the later scripts.

The global environment initially contains the following modules: [http://www.lua.org/manual/5.1/manual.html#5.1 basic] (no name), [http://www.lua.org/manual/5.1/manual.html#5.4 string], [http://www.lua.org/manual/5.1/manual.html#5.5 table], and [http://www.lua.org/manual/5.1/manual.html#5.6 math]. {{DevFeature1.13|0}} The [http://www.lua.org/manual/5.2/manual.html#6.7 bit32] library is supported as well. A '''wesnoth''' module is also available, it provides access to the [[#Interface to the C++ engine|C++ engine]]. Additionally, the functions clock, date, time and difftime from the [http://www.lua.org/manual/5.1/manual.html#5.8 os] library (keep in mind that they aren't multiplayer- and replay-safe), as well as traceback from the [http://www.lua.org/manual/5.1/manual.html#5.9 debug] library are also available.

At the start of a script, the variadic local variable '''...''' (three dots) is a proxy table representing [[#Encoding WML objects into Lua tables|WML data]]. This table is the content of the '''[args]''' sub-tag of the '''[lua]''' tag, if any.

== Examples ==

The following WML event is taken from Wesnoth' tutorial. It will serve as an example to present how Lua scripts are embedded into Wesnoth. The event is fired whenever a unit from side 1 (that is, the hero controlled by the user) moves to a tile that is not the one set in the WML variable ''target_hex''.

# General catch for them moving to the wrong place.
[event]
name=moveto
first_time_only=no
[allow_undo][/allow_undo]
[filter]
side=1
[/filter]

[if]
[variable]
name=target_hex.is_set
equals=yes
[/variable]
[then]
[if]
[variable]
name=x1
equals=$target_hex.x
[/variable]
[variable]
name=y1
equals=$target_hex.y
[/variable]
[then]
[/then]
[else]
[redraw][/redraw]
[message]
speaker=narrator
message=_ "*Oops!
You moved to the wrong place! After this message, you can press 'u' to undo, then try again." +
_ "
*Left click or press spacebar to continue..."
[/message]
[/else]
[/if]
[/then]
[/if]
[/event]

A Lua script that performs the same action is presented below.

[event]
name=moveto
first_time_only=no
[allow_undo][/allow_undo]
[filter]
side=1
[/filter]

[lua]
code = <<
local event_data = wesnoth.current.event_context
if V.target_hex.is_set and
(event_data.x1 ~= V.target_hex.x or event_data.y1 ~= V.target_hex.y)
then
W.redraw()
narrator_says(_ "*Oops!\nYou moved to the wrong place! After this message, you can press 'u' to undo, then try again.")
end
>>
[/lua]
[/event]

Here is a more detailed explanation of the Lua code. Its first line

<syntaxhighlight lang='lua'>
local event_data = wesnoth.current.event_context
</syntaxhighlight>

puts the event data into the ''event_data'' local variable. Since it is a ''moveto'' event, the ''event_data'' table contains the destination of the unit in the ''x1'' and ''y1'' fields.

The next two lines then test

<syntaxhighlight lang='lua'>
if V.target_hex.is_set and
(event_data.x1 ~= V.target_hex.x or event_data.y1 ~= V.target_hex.y)
</syntaxhighlight>

whether the variable ''V.target_hex'' matches the event parameters. Since ''V'' is not a local variable, it is taken from the global environment. Usually, variables from the global environment are not persistent (they get lost on reloading), so it shouldn't be used to store data. In order to have an easy way to access the usual persistent Wml variables, the global variable ''V'' was mapped to the storage of WML variables by the following ''preload'' event.

[event]
name=preload
first_time_only=no
[lua]
code = <<
H = wesnoth.require "lua/helper.lua"
-- skipping some other initializations
-- ...
V = H.set_wml_var_metatable {}
>>
[/lua]
[/event]

Without a prelude redirecting ''V'', the conditional would have been written

<syntaxhighlight lang='lua'>
if wesnoth.get_variable("target_hex.is_set") and
(event_data.x1 ~= wesnoth.get_variable("target_hex.x") or event_data.y1 ~= wesnoth.get_variable("target_hex.y")
</syntaxhighlight>

The body of the conditional then performs the [[InterfaceActionsWML#Other interface tags|[redraw]]] action.

<syntaxhighlight lang='lua'>
W.redraw()
</syntaxhighlight>

Again, this short syntax is made possible by a line of the prelude that makes ''W'' a proxy for performing WML actions.

<syntaxhighlight lang='lua'>
W = H.set_wml_action_metatable {}
</syntaxhighlight>

Without this shortcut, the first statement would have been written

<syntaxhighlight lang='lua'>
wesnoth.fire("redraw")
</syntaxhighlight>

Finally the script displays a message by

<syntaxhighlight lang='lua'>
narrator_says(_ "*Oops!\nYou moved to the wrong place! After this message, you can press 'u' to undo, then try again.")
</syntaxhighlight>

The ''narrator_says'' function is defined in the prelude too, since the construct behind it occurs several times in the tutorial. In plain WML, macros would have been used instead. The definition of the function is

<syntaxhighlight lang='lua'>
function narrator_says(m)
W.message { speaker="narrator",
message = m .. _ "\n*Left click or press spacebar to continue..." }
end
</syntaxhighlight>

The function fires a [[InterfaceActionsWML#.5Bmessage.5D|[message]]] action and passes a WML object containing the usual two fields to it. The second field is initialized by concatenating the function argument with another string. Both strings are prefixed by the ''_'' symbol to mark them as translatable. (Note that ''_'' is just a unary function, not a keyword.) Again, this is made possible by a specific line of the prelude:

<syntaxhighlight lang='lua'>
_ = wesnoth.textdomain "wesnoth-tutorial"
</syntaxhighlight>

A longer translation of the tutorial is available at [https://gna.org/patch/download.php?file_id=5483].

== Interface to the engine and helper functions ==

Functionalities of the game engine are available through the functions contained in the '''wesnoth''' global table. Some of these functions return proxy tables. Writes to fields marked "read-only" are ignored. The '''__cfg''' fields return plain tables; in particular, writes do not modify the original object, and reads return the values from the time the dump was performed.

Some helper functions are provided by the '''lua/helper.lua''' library. They are stored inside a table that is returned when loading the library with [[LuaWML:Files#wesnoth.require|wesnoth.require]].

<syntaxhighlight lang='lua'>
helper = wesnoth.require "lua/helper.lua"
</syntaxhighlight>

=== WML variables ===

* [[LuaWML:Variables#wesnoth.get_variable|wesnoth.get_variable]]
* [[LuaWML:Variables#wesnoth.set_variable|wesnoth.set_variable]]
* [[LuaWML:Variables#wesnoth.get_all_vars|wesnoth.get_all_vars]] {{DevFeature1.13|0}}
* [[LuaWML:Variables#helper.set_wml_var_metatable|helper.set_wml_var_metatable]]
* [[LuaWML:Variables#helper.get_child|helper.get_child]]
* [[LuaWML:Variables#helper.get_nth_child|helper.get_nth_child]] {{DevFeature1.13|2}}
* [[LuaWML:Variables#helper.child_count|helper.child_count]] {{DevFeature1.13|2}}
* [[LuaWML:Variables#helper.child_range|helper.child_range]]
* [[LuaWML:Variables#helper.child_array|helper.child_array]] {{DevFeature1.13|2}}
* [[LuaWML:Variables#helper.get_variable_array|helper.get_variable_array]]
* [[LuaWML:Variables#helper.get_variable_proxy_array|helper.get_variable_proxy_array]]
* [[LuaWML:Variables#helper.set_variable_array|helper.set_variable_array]]

=== Events and WML actions ===

* [[LuaWML:Events#wesnoth.fire|wesnoth.fire]]
* [[LuaWML:Events#wesnoth.wml_actions|wesnoth.wml_actions]]
* [[LuaWML:Events#wesnoth.wml_actions|wesnoth.wml_conditionals]] {{DevFeature1.13|0}}
* [[LuaWML:Events#wesnoth.game_events|wesnoth.game_events]]
* [[LuaWML:Events#wesnoth.fire_event|wesnoth.fire_event]]
* [[LuaWML:Events#wesnoth.fire_event_by_name|wesnoth.fire_event_by_name]] {{DevFeature1.13|6}}
* [[LuaWML:Events#wesnoth.fire_event_by_id|wesnoth.fire_event_by_id]] {{DevFeature1.13|6}}
* [[LuaWML:Events#wesnoth.add_event_handler|wesnoth.add_event_handler]] {{DevFeature1.13|0}}
* [[LuaWML:Events#wesnoth.remove_event_handler|wesnoth.remove_event_handler]] {{DevFeature1.13|0}}
* [[LuaWML:Events#wesnoth.eval_conditional|wesnoth.eval_conditional]]
* [[LuaWML:Events#wesnoth.tovconfig|wesnoth.tovconfig]]
* [[LuaWML:Events#helper.set_wml_action_metatable|helper.set_wml_action_metatable]]
* [[LuaWML:Events#helper.wml_error|helper.wml_error]]
* [[LuaWML:Events#helper.literal|helper.literal]]
* [[LuaWML:Events#helper.parsed|helper.parsed]]
* [[LuaWML:Events#helper.shallow_literal|helper.shallow_literal]]
* [[LuaWML:Events#helper.shallow_parsed|helper.shallow_parsed]]

=== User interface ===

* [[LuaWML:Display#wesnoth.message|wesnoth.message]]
* [[LuaWML:Display#wesnoth.clear_messages|wesnoth.clear_messages]]
* [[LuaWML:Display#wesnoth.textdomain|wesnoth.textdomain]]
* [[LuaWML:Display#wesnoth.delay|wesnoth.delay]]
* [[LuaWML:Display#wesnoth.float_label|wesnoth.float_label]]
* [[LuaWML:Display#wesnoth.select_unit|wesnoth.select_hex]]
* [[LuaWML:Display#wesnoth.select_unit|wesnoth.select_unit]]
* [[LuaWML:Display#wesnoth.highlight_hex|wesnoth.highlight_hex]]
* [[LuaWML:Display#wesnoth.deselect_hex|wesnoth.deselect_hex]] {{DevFeature1.13|2}}
* [[LuaWML:Display#wesnoth.scroll_to_tile|wesnoth.scroll_to_tile]]
* [[LuaWML:Display#wesnoth.lock_view|wesnoth.lock_view]]
* [[LuaWML:Display#wesnoth.view_locked|wesnoth.view_locked]]
* [[LuaWML:Display#wesnoth.play_sound|wesnoth.play_sound]]
* [[LuaWML:Display#wesnoth.set_music|wesnoth.set_music]]
* [[LuaWML:Display#wesnoth.show_message_dialog|wesnoth.show_message_dialog]] {{DevFeature1.13|2}}
* [[LuaWML:Display#wesnoth.show_popup_dialog|wesnoth.show_popup_dialog]] {{DevFeature1.13|2}}
* [[LuaWML:Display#wesnoth.show_dialog|wesnoth.show_dialog]]
* [[LuaWML:Display#wesnoth.set_dialog_value|wesnoth.set_dialog_value]]
* [[LuaWML:Display#wesnoth.get_dialog_value|wesnoth.get_dialog_value]]
* [[LuaWML:Display#wesnoth.set_dialog_active|wesnoth.set_dialog_active]]
* [[LuaWML:Display#wesnoth.set_dialog_callback|wesnoth.set_dialog_callback]]
* [[LuaWML:Display#wesnoth.set_dialog_markup|wesnoth.set_dialog_markup]]
* [[LuaWML:Display#wesnoth.set_dialog_focus|wesnoth.set_dialog_focus]] {{DevFeature1.13|2}}
* [[LuaWML:Display#wesnoth.set_dialog_visible|wesnoth.set_dialog_visible]] {{DevFeature1.13|2}}
* [[LuaWML:Display#wesnoth.set_dialog_canvas|wesnoth.set_dialog_canvas]]
* [[LuaWML:Display#wesnoth.add_dialog_tree_node|wesnoth.add_dialog_tree_node]] {{DevFeature1.13|0}}
* [[LuaWML:Display#wesnoth.remove_dialog_item|wesnoth.remove_dialog_item]] {{DevFeature1.13|1}}
* [[LuaWML:Display#wesnoth.get_displayed_unit|wesnoth.get_displayed_unit]]
* [[LuaWML:Display#wesnoth.theme_items|wesnoth.theme_items]]
* [[LuaWML:Display#helper.get_user_choice|helper.get_user_choice]]
* [[LuaWML:Display#wesnoth.is_skipping_messages|wesnoth.is_skipping_messages]] {{DevFeature1.13|2}}
* [[LuaWML:Display#wesnoth.skip_messages|wesnoth.skip_messages]] {{DevFeature1.13|2}}
* [[LuaWML:Display#wesnoth.log|wesnoth.log]] {{DevFeature1.13|5}}

=== Map and terrains ===

* [[LuaWML:Tiles#wesnoth.get_map_size|wesnoth.get_map_size]]
* [[LuaWML:Tiles#wesnoth.get_terrain|wesnoth.get_terrain]]
* [[LuaWML:Tiles#wesnoth.set_terrain|wesnoth.set_terrain]]
* [[LuaWML:Tiles#wesnoth.get_terrain_info|wesnoth.get_terrain_info]]
* [[LuaWML:Tiles#wesnoth.get_selected_tile|wesnoth.get_selected_tile]]
* [[LuaWML:Tiles#wesnoth.get_locations|wesnoth.get_locations]]
* [[LuaWML:Tiles#wesnoth.get_villages|wesnoth.get_villages]]
* [[LuaWML:Tiles#wesnoth.match_location|wesnoth.match_location]]
* [[LuaWML:Tiles#wesnoth.add_tile_overlay|wesnoth.add_tile_overlay]]
* [[LuaWML:Tiles#wesnoth.remove_tile_overlay|wesnoth.remove_tile_overlay]]
* [[LuaWML:Tiles#wesnoth.add_fog|wesnoth.add_fog]] {{DevFeature1.13|5}}
* [[LuaWML:Tiles#wesnoth.remove_fog|wesnoth.remove_fog]] {{DevFeature1.13|5}}
* [[LuaWML:Tiles#wesnoth.add_sound_source|wesnoth.add_sound_source]] {{DevFeature1.13|5}}
* [[LuaWML:Tiles#wesnoth.remove_sound_source|wesnoth.remove_sound_source]] {{DevFeature1.13|5}}
* [[LuaWML:Tiles#wesnoth.get_sound_source|wesnoth.get_sound_source]] {{DevFeature1.13|5}}
* [[LuaWML:Tiles#items.place_image|items.place_image]]
* [[LuaWML:Tiles#items.place_halo|items.place_halo]]
* [[LuaWML:Tiles#items.remove|items.remove]]

=== Time of day schedule ===

* [[LuaWML:Time#wesnoth.get_time_of_day|wesnoth.get_time_of_day]]
* [[LuaWML:Time#wesnoth.add_time_area|wesnoth.add_time_area]] {{DevFeature1.13|0}}
* [[LuaWML:Time#wesnoth.remove_time_area|wesnoth.remove_time_area]] {{DevFeature1.13|0}}

=== Units ===

* [[LuaWML:Units#wesnoth.get_units|wesnoth.get_units]]
* [[LuaWML:Units#wesnoth.get_unit|wesnoth.get_unit]]
* [[LuaWML:Units#wesnoth.match_unit|wesnoth.match_unit]]
* [[LuaWML:Units#wesnoth.put_unit|wesnoth.put_unit]]
* [[LuaWML:Units#wesnoth.erase_unit|wesnoth.erase_unit]] {{DevFeature1.13|2}}
* [[LuaWML:Units#wesnoth.get_recall_units|wesnoth.get_recall_units]]
* [[LuaWML:Units#wesnoth.put_recall_unit|wesnoth.put_recall_unit]]
* [[LuaWML:Units#wesnoth.create_unit|wesnoth.create_unit]]
* [[LuaWML:Units#wesnoth.copy_unit|wesnoth.copy_unit]]
* [[LuaWML:Units#wesnoth.extract_unit|wesnoth.extract_unit]]
* [[LuaWML:Units#wesnoth.add_modification|wesnoth.add_modification]]
* [[LuaWML:Units#wesnoth.unit_resistance|wesnoth.unit_resistance]]
* [[LuaWML:Units#wesnoth.unit_defense|wesnoth.unit_defense]]
* [[LuaWML:Units#wesnoth.unit_movement_cost|wesnoth.unit_movement_cost]]
* [[LuaWML:Units#wesnoth.unit_vision_cost|wesnoth.unit_vision_cost]]
* [[LuaWML:Units#wesnoth.unit_jamming_cost|wesnoth.unit_jamming_cost]]
* [[LuaWML:Units#wesnoth.unit_ability|wesnoth.unit_ability]]
* [[LuaWML:Units#wesnoth.unit_types|wesnoth.unit_types]]
* [[LuaWML:Units#wesnoth.races|wesnoth.races]]
* [[LuaWML:Units#wesnoth.get_traits|wesnoth.get_traits]]
* [[LuaWML:Units#wesnoth.simulate_combat|wesnoth.simulate_combat]]
* [[LuaWML:Units#wesnoth.transform_unit|wesnoth.transform_unit]]
* [[LuaWML:Units#wesnoth.effects|wesnoth.effects]] {{DevFeature1.13|2}}

=== Sides ===

* [[LuaWML:Sides#wesnoth.sides|wesnoth.sides]]
* [[LuaWML:Sides#wesnoth.get_sides|wesnoth.get_sides]]
* [[LuaWML:Sides#wesnoth.get_village_owner|wesnoth.get_village_owner]]
* [[LuaWML:Sides#wesnoth.set_village_owner|wesnoth.set_village_owner]]
* [[LuaWML:Sides#wesnoth.is_enemy|wesnoth.is_enemy]]
* [[LuaWML:Sides#wesnoth.match_side|wesnoth.match_side]]
* [[LuaWML:Sides#wesnoth.get_starting_location|wesnoth.get_starting_location]]
* [[LuaWML:Sides#helper.all_teams|helper.all_teams]]

=== Pathfinder ===

* [[LuaWML:Pathfinder#wesnoth.find_path|wesnoth.find_path]]
* [[LuaWML:Pathfinder#wesnoth.find_vacant_tile|wesnoth.find_vacant_tile]]
* [[LuaWML:Pathfinder#wesnoth.find_reach|wesnoth.find_reach]]
* [[LuaWML:Pathfinder#wesnoth.find_cost_map|wesnoth.find_cost_map]]
* [[LuaWML:Pathfinder#helper.distance_between|helper.distance_between]]
* [[LuaWML:Pathfinder#helper.adjacent_tiles|helper.adjacent_tiles]]

=== Lua files ===

* [[LuaWML:Files#wesnoth.dofile|wesnoth.dofile]]
* [[LuaWML:Files#wesnoth.require|wesnoth.require]]
* [[LuaWML:Files#wesnoth.read_file|wesnoth.read_file]] {{DevFeature1.13|5}}

=== Location sets ===

* [[LuaWML:Location_set#location_set.create|location_set.create]]
* [[LuaWML:Location_set#location_set.of_pairs|location_set.of_pairs]]
* [[LuaWML:Location_set#location_set.of_wml_var|location_set.of_wml_var]]
* [[LuaWML:Location_set#location_set:empty|location_set:empty]]
* [[LuaWML:Location_set#location_set:size|location_set:size]]
* [[LuaWML:Location_set#location_set:clear|location_set:clear]]
* [[LuaWML:Location_set#location_set:get|location_set:get]]
* [[LuaWML:Location_set#location_set:insert|location_set:insert]]
* [[LuaWML:Location_set#location_set:remove|location_set:remove]]
* [[LuaWML:Location_set#location_set:of_pairs|location_set:of_pairs]]
* [[LuaWML:Location_set#location_set:of_wml_var|location_set:of_wml_var]]
* [[LuaWML:Location_set#location_set:to_pairs|location_set:to_pairs]]
* [[LuaWML:Location_set#location_set:to_stable_pairs|location_set:to_stable_pairs]]
* [[LuaWML:Location_set#location_set:to_wml_var|location_set:to_wml_var]]
* [[LuaWML:Location_set#location_set:union|location_set:union]]
* [[LuaWML:Location_set#location_set:inter|location_set:inter]]
* [[LuaWML:Location_set#location_set:iter|location_set:iter]]
* [[LuaWML:Location_set#location_set:stable_iter|location_set:stable_iter]]
* [[LuaWML:Location_set#location_set:filter|location_set:filter]]
* [[LuaWML:Location_set#location_set:union_merge|location_set:union_merge]]
* [[LuaWML:Location_set#location_set:inter_merge|location_set:inter_merge]]

=== Miscellaneous ===

* [[LuaWML:Misc#wesnoth.game_config|wesnoth.game_config]]
* [[LuaWML:Misc#wesnoth.get_era|wesnoth.get_era]]
* [[LuaWML:Misc#wesnoth.current|wesnoth.current]]
* [[LuaWML:Misc#wesnoth.synchronize_choice|wesnoth.synchronize_choice]]
* [[LuaWML:Misc#wesnoth.get_image_size|wesnoth.get_image_size]]
* [[LuaWML:Misc#wesnoth.compare_versions|wesnoth.compare_versions]]
* [[LuaWML:Misc#wesnoth.have_file|wesnoth.have_file]]
* [[LuaWML:Misc#wesnoth.debug|wesnoth.debug]]
* [[LuaWML:Misc#wesnoth.get_time_stamp|wesnoth.get_time_stamp]]
* [[LuaWML:Misc#wesnoth.random|wesnoth.random]] {{DevFeature1.13|2}}
* [[LuaWML:Misc#wesnoth.eval_formula|wesnoth.eval_formula]] {{DevFeature1.13|5}}
* [[LuaWML:Misc#wesnoth.compile_formula|wesnoth.compile_formula]] {{DevFeature1.13|5}}
* [[LuaWML:Misc#wesnoth.name_generator|wesnoth.name_generator]] {{DevFeature1.13|5}}
* [[LuaWML:Misc#wesnoth.set_next_scenario|wesnoth.set_next_scenario]] {{DevFeature1.13|5}}
* [[LuaWML:Misc#helper.set_wml_tag_metatable|helper.set_wml_tag_metatable]]
* [[LuaWML:Misc#helper.modify_unit|helper.modify_unit]]
* [[LuaWML:Misc#helper.move_unit_fake|helper.move_unit_fake]]
* [[LuaWML:Misc#helper.rand|helper.rand]]
* [[LuaWML:Misc#helper.round|helper.round]]
* [[LuaWML:Misc#helper.shuffle|helper.shuffle]]

== Encoding WML objects into Lua tables ==

Function [[LuaWML:Events#wesnoth.fire|wesnoth.fire]] expects a table representing a WML object as its second argument (if needed). Function [[LuaWML:Variables#wesnoth.set_variable|wesnoth.set_variable]] allows to modify whole WML objects, again by passing it a table. Function [[LuaWML:Variables#wesnoth.get_variable|wesnoth.get_variable]] transforms a WML object into a table, if its second argument is not set to ''true''. All these tables have the same format.

Scalar fields are transformed into WML attributes. For instance, the following Lua table

<syntaxhighlight lang='lua'>
{
a_bool = true,
an_int = 42,
a_float = 1.25,
a_string = "scout",
a_translation = _ "Hello World!"
}
</syntaxhighlight>

is equivalent to the content of the following WML object

<syntaxhighlight lang='wml'>
[dummy]
a_bool = "yes"
an_int = "42"
a_float = "1.25"
a_string = "scout"
a_translation = _ "Hello World!"
[/dummy]
</syntaxhighlight>

WML child objects are not stored as Lua named fields, since several of them can have the same tag. Moreover, their tags can conflict with the attribute keys. So child objects are stored as pairs string + table in the unnamed fields in definition order. This means that for every subtag appearing in the wml code there is an additional table "layer" in the corresponding WML table of the form <code>{[1] = "tag_name", [2] = {}}</code> which is equivalent to <code>{"tag_name", {}}</code>. [1] etc are the unnamed fields (as opposed to wml attributes). The table under [2] in this subtable then holds the wml attributes from inside the wml subtag. So every subtag other than the toplevel tag corresponds to two nested tables each. For instance, the following Lua table

<syntaxhighlight lang='lua'>
{
foo = 42,
{ "bar", { v = 1, w = 2 } },
{ "foo", { x = false } },
{ "bar", { y = "foo" } },
{ "foobar", { z = 5, { "barfoo", {} } } }
}
</syntaxhighlight>

is equivalent to the content of the following WML object

<syntaxhighlight lang='wml'>
[dummy]
foo = 42
[bar]
v = 1
w = 2
[/bar]
[foo]
x = no
[/foo]
[bar]
y = foo
[bar]
[foobar]
z = 5
[barfoo]
[/barfoo]
[/foobar]
[/dummy]
</syntaxhighlight>

Both tables above are also equivalent to this WML table, where all unnamed fields are displayed:

<syntaxhighlight lang='lua'>
{
foo = 42,
[1] = { [1] = "bar", [2] = { v = 1, w = 2 } },
[2] = { [1] = "foo", [2] = { x = false } },
[3] = { [1] = "bar", [2] = { y = "foo" } },
[4] = { [1] = "foobar", [2] = { z = 5, [1] = { [1] = "barfoo", [2] = {} } } }
}
</syntaxhighlight>

So assuming ''cfg'' contains the above WML object, the following accesses are possible:

<syntaxhighlight lang=lua>
a_int = cfg.foo -- "dummy.foo", 42
a_string = cfg[3][2].y -- "dummy.bar[1].y", "foo"
a_table = cfg[4][2] -- "dummy.foobar", { z = 5, { "barfoo", {} } }
</syntaxhighlight>

For creating valid wml table in lua it is usully easier to use ''T = helper.set_wml_tag_metatable {}'' asuming you did that you can create the above wml document with
<syntaxhighlight lang=lua>
{
foo = 42,
T.bar {
v = 1,
w = 1,
},
T.foo {
x = false,
},
T.bar {
y = "foo",
},
T.foobar {
z = 5,
T.barfoo {
},
},
}
</syntaxhighlight>

Consider using the [[LuaWML:Variables#helper.get_child|helper.get_child]] and [[LuaWML:Variables#helper.child_range|helper.child_range]] to ease the access to subtags.

{{DevFeature1.13|5}} As a convenience, attributes with array values (tables with only integer keys) are concatenated into a string when converting a Lua table into WML. For example, the following Lua code:

<syntaxhighlight lang=lua>
{
x = {1, 2, 3, 4},
y = {7, 8, 9, 10}
}
</syntaxhighlight>

produces the following WML table:

<syntaxhighlight lang=wml>
[dummy]
x=1,2,3,4
y=7,8,9,10
[/dummy]
</syntaxhighlight>

Functions registered in [[LuaWML:Events#wesnoth.wml_actions|wesnoth.wml_actions]] receive their data in a userdata object which has the exact same structure as above. It is read-only however. Accessing fields or children performs variable substitution on the fly. Its '''__parsed''' and '''__literal''' fields provide translations to plain tables (therefore writable). '''__literal''' returns the original text of the data (including dollar symbols in attributes and [insert_tag] children), while '''__parsed''' performs a variable substitution.

For instance, if you cannot stand any longer the fact that '''first_time_only''' is set to yes by default for the '''[event]''' tag, you can redefine it. But we have to be careful not to cause variable substitution, since the engine would perform a second variable substitution afterwards.

<syntaxhighlight lang=lua>
local old_event_handler = wesnoth.wml_actions.event
function wesnoth.wml_actions.event(cfg)
-- Get the plain text from the user.
local new_cfg = cfg.__literal
-- The expression below is equivalent to cfg.__parsed.first_time_only,
-- only faster. It is needed, since the first_time_only attribute may
-- reference variables.
local first = cfg.first_time_only
-- Modify the default behavior of first_time_only.
if first == nil then first = false end
new_cfg.first_time_only = first
-- Call the engine handler.
old_event_handler(new_cfg)
end
</syntaxhighlight>

(Note: The above example will only affect nested events. Toplevel events will still default to ''first_time_only=yes''.)


Note that, since the object is a userdata and not a table, '''pairs''' and '''ipairs''' are unfortunately not usable on it. So scripts have to work at a lower level. For instance, the following function returns the first sub-tag with a given name and it works both on WML tables and WML userdata:

<syntaxhighlight lang=lua>
function get_child(cfg, name)
for i = 1, #cfg do
local v = cfg[i]
if v[1] == name then return v[2] end
end
end
</syntaxhighlight>

{{DevFeature1.13|2}} '''pairs''' and '''ipairs''' now work on vconfig objects (contrary to the above statement). However, '''pairs''' works a little differently than on plain configs (tables) - it returns only string keys (attributes in WML terms) and not integer keys (tags in WML terms).

Another approach for handling userdata and tables in the same way, would be to convert the former into the latter beforehand:

<syntaxhighlight lang=lua>
if getmetatable(cfg) == "wml object" then cfg = cfg.__parsed end
</syntaxhighlight>

The WML userdata provides two other special fields: '''__shallow_parsed''' and '''__shallow_literal'''. They return a table corresponding to the WML userdata with variable substitution performed on the attributes (or not). [insert_tag] tags have also been parsed, so the number of children is faithful. But contrarily to '''__parsed''' and '''__literal''', the process is not recursive: all the children are still WML userdata and variable substitution can still happen for them. These shallow translators are meant as optimized versions of the deep ones, when only the toplevel attributes need to be writable.

== Skeleton of a preload event ==

The following event is a skeleton for a prelude enabling Lua in your WML events. It creates a table ''H'' containing the functions from helper.lua and a table ''W'' that serves as a proxy for firing WML actions. It sets up a table ''T'' so be used for easier creation of valid WML tables. It also sets up a table ''V'' so that any access to it is redirected to the persistent WML storage. Finally, it loads a textdomain to be accessed through the ''_'' variable.

<syntaxhighlight lang='wml'>
[event]
name=preload
first_time_only=no
[lua]
code = <<
H = wesnoth.require "lua/helper.lua"
W = H.set_wml_action_metatable {}
T = H.set_wml_tag_metatable {}
V = H.set_wml_var_metatable {}
_ = wesnoth.textdomain "my-campaign"

-- Define your global constants here.
-- ...

-- Define your global functions here.
-- ...
>>
[/lua]
[/event]
</syntaxhighlight>

It may be worth putting the whole Lua script above inside a separate file and having the ''preload'' event load it:

<syntaxhighlight lang='wml'>
[event]
name=preload
first_time_only=no
[lua]
code = << wesnoth.dofile "~add-ons/Whatever/file.lua" >>
[/lua]
[/event]
</syntaxhighlight>

== Remarks on Random Numbers ==

The math.random function is not safe for replays and multiplayer games, since the random values will be different each time and on all the clients. Instead, the Lua code should use the [[LuaWML:Misc#helper.rand|helper.rand()]] function to synchronize random values. It takes the same argument in the same format as [[InternalActionsWML#.5Bset_variable.5D|[set_variable]]] rand=.

local random_variable = helper.rand("1,2,3")

Also available is [[LuaWML:Misc#wesnoth.random|wesnoth.random]], which has the same interface as math.random but is multiplayer-safe.

[[Category: Lua Reference|*]]
[[Category: WML Reference]]

InternalActionsWML

2016-08-12T22:36:09Z

Spixi: /* [fire_event] */

{{WML Tags}}

Part of [[ActionWML]], Internal actions are actions that WML uses internally that do not directly affect game play (or, at least, are not readily apparent to the player). For example, storing a variable is an internal action.

== Variable Actions ==

These actions are focused, in one way or another, on [[VariablesWML|variables]]. Creating them, modifying them, capturing game data to them, you name it, these actions are all about the variables.

=== [set_variable] ===

The '''[set_variable]''' tag is used to create and manipulate WML variables. The [http://www.wesnoth.org/macro-reference.xhtml#VARIABLE VARIABLE] macro is a quick syntactic shortcut for simple variable creation and the [http://www.wesnoth.org/macro-reference.xhtml#VARIABLE_OP VARIABLE_OP] macro is a quick syntactic shortcut for performing simple mathematical operations on variables.

* '''name''': the name of the variable to manipulate

* '''value''': set the variable to the given value (can be numeric or string).Use literal for no substitution. (see [[VariablesWML]])

* '''literal''': set the variable to the given value (can be numeric or string). This does not interpret any dollar signs.

* '''to_variable''': set the variable to the value of the given variable, e.g. 'to_variable=temp' would be equivalent to 'value=$temp'.

* '''add''': add the given amount to the variable.

* '''sub''': subtract the given amount from the variable.

* '''multiply''': multiply the variable by the given number. The result is a float.<br />To negate a number, multiply by -1. If you negate 0, the result is a floating-point negative zero -0. To display -0 as 0, use a second tag with add=0; it will flip -0 to 0 but not affect other numbers.

* '''divide''': divide the variable by the given number. The result is a float. Wesnoth 1.9 and later no longer uses integer division. Use a second tag with round=floor if you relied on this.

* '''modulo''': returns the remainder of a division.

* '''rand''': the variable will be randomly set.<br>You may provide a comma separated list of possibilities, e.g. 'rand=Bob,Bill,Bella'.<br>You may provide a range of numbers (integers), e.g. 'rand=3..5'.<br>You may combine these, e.g. 'rand=100,1..9', in which case there would be 1/10th chance of getting 100, just like for each of 1 to 9. If a number or item is repeated, it is sampled more frequently as appropriate. See [[MultiplayerContent]] for more info on the MP case.<br>Using rand= will automatically result in the current action being non undoable. Ignoring possible [allow_undo].

* '''time=stamp''': Retrieves a timestamp in milliseconds since wesnoth was started, can be used as timing aid. Don't try to use this as random value in MP since it will cause an OOS.

* '''string_length''': Retrieves the length in characters of the string passed as this attribute's value; such string is parsed and variable substitution applied automatically (see [[VariablesWML]] for details).

* '''[join]''' joins an array of strings to create a textual list
** '''variable''': name of the array
** '''key''': the key of each array element(array[$i].foo) in which the strings are stored
** '''separator''': separator to connect the elements
** '''remove_empty''': whether to ignore empty elements

* '''ipart''': Assigns the integer part (the part to the left of the decimal point) of the referenced variable.

* '''fpart''': Assigns the decimal part (the part to the right of the decimal point) of the referenced variable.

* '''round''': Rounds the variable to the specified number of digits of precision. Negative precision works as expected (rounding 19517 to -2 = 19500). Special values:
**'''round=ceil''': Rounds upward to the nearest integer.
**'''round=floor''': Rounds down to the nearest integer.

=== [set_variables] ===

Manipulates a WML array or container

* '''name''': the name of the array or container to manipulate

* '''mode''': one of the following values:
** ''replace'': will clean the array '''name''' and replace it with given data
** ''append'': will append given data to the current array
** ''merge'': will merge in the given data into '''name'''
** ''insert'': will insert the given data at the index specified in the '''name''' attribute, such as name=my_array[1]. The default index is zero, which will insert to the front of the array. '''Note:''' if an invalid index is used, empty containers will be created before the insertion is performed. In other words, do not attempt to insert at an index greater than (or equal to) the array's current length. This limitation may be removed in future versions.

* '''to_variable''': data will be set to the given array

* '''[value]''': the WML inside the [value] tags will be stored in data, variables will be interpolated directly, use $| in order to escape the $ sign, you can store arrays of WML by supplying multiple [value] tags. ([[#Using_.5Bset_variables.5D_to_Create_Arrays_of_WML|See Example]])

* '''[literal]''': same as '''[value]''', but variables will not be substituted, '''[literal]''' and '''[value]''' can not be used in the same [set_variables] tag, i.e. you can not create arrays by piling a mix of '''[value]''' and '''[literal]''' tags

*'''[split]''' splits a textual list into an array which will then be set to data
** '''list''': textual list to split
** '''key''': the key of each array element(array[$i].foo) in which the strings are stored
** '''separator''': separator to separate the elements
** '''remove_empty''': whether to ignore empty elements

{{DevFeature1.13|4}} You can now mix '''[value]''', '''[literal]''', and '''[split]''' in the same '''[set_variables]''' tag. They will be processed in order of appearance. Multiple instances of [split] are also supported now.

=== Capturing Game Data ===

These actions capture different bits of game data and store them to variables so they can be examined and/or manipulated.

==== [store_gold] ====

Stores a side's gold into a variable.

* '''[[StandardSideFilter]]''': The first matching side's gold will be stored in the variable "variable".
* '''variable''': (default='gold') the name of the variable to store the gold in

==== [store_locations] ====

Stores a series of locations that pass certain criteria into an array. Each member of the array has members 'x' and 'y' (the position) and 'terrain' (the terrain type) and 'owner_side' (villages only). The array will include any unreachable border hexes, if applicable.

* [[StandardLocationFilter]]: a location or location range which specifies the locations to store. By default, all locations on the map are stored.

* '''variable''': the name of the variable (array) into which to store the locations.

==== [store_reachable_locations] ====

Stores locations reachable by the given units. Can store either the movement, attack or vision ranges.

* '''[filter]''': a [[StandardUnitFilter]]. The locations reachable by any of the matching units will be stored.
* '''[filter_location]''': (optional) a [[StandardLocationFilter]]. Only locations which also match this filter will be stored.
* '''range''': possible values ''movement'' (default), ''attack'', ''vision''. If ''movement'', stores the locations within the movement range of the unit, taking Zone of Control into account. If ''attack'', stores the attack range (movement range + 1 hex). If ''vision'', stores the vision range (movement range ignoring Zone of Control + 1 hex).
* '''moves''': possible values ''current'' (default), ''max''. Specifies whether to use the current or maximum movement points when calculating the range.
* '''viewing_side''': (optional) the side whose vision to use when calculating the reach. This only has meaning in the presence of fog, shroud, or units with the ambush ability. If left out, then fog, shroud and ambushers are ignored and the real reach of the units is stored.
* '''variable''': the name of the variable (array) into which to store the locations.

==== [store_map_dimensions] ====

Stores the map dimensions in a variable.

* '''variable''': the name of the variable where the values will be saved into. If it is skipped, a variable 'map_size' is used, and its contents overridden, if they existed already. The result is a container variable, with members ''width'' and ''height''.

==== [store_side] ====

Stores information about a certain side in a variable.

'''Keys:'''
* '''[[StandardSideFilter]]''': All matching sides are stored. (An array is created if several sides match - access it with side[2].team_name and so on.)
* '''variable''': the name of the variable to store the information in (default: "side")

'''Result'''

Variable will contain following members:
* '''color''': It indicates team color. Can be one of the following:
{| border = 1
| ''color''
| red
| blue
| green
| purple
| black
| brown
| orange
| white
| teal
|-
| ''value''
| 1
| 2
| 3
| 4
| 5
| 6
| 7
| 8
| 9
|}
* '''controller''': Indicates type of player that control this side. ''In networked multiplayer, the controller attribute is ambiguous. Be very careful or you have OOS errors.''
** '''human''': Human player
** '''ai''': If players assigns "Computer Player" to "Player/Type" in game lobby
** '''network''': In multiplayer for sides that client does not control, both what would normally be human and ai. For host values are as usual, this is where OOS comes from.
** '''null''': If players assigns "Empty" to "Player/Type" in game lobby
* '''fog''': Indicates whether this side is affected by fog of war.
* '''gold''': The amount of gold the side have.
* '''hidden''': (boolean) If 'yes', side is not shown in status table.
* '''income''': Base income for this side (without villages).
* '''name''': Name of player.
* '''recruit''': A comma-separated list of unit types that can be recruited by this side.
* '''shroud''': Whether this side is affected by shroud.
* '''side''': The $side_number of the side belonging to this container
* '''team_name''': String representing the team's description.
* '''user_team_name''': Translated string representing the team's description.
* '''village_gold''': The amount of gold given to this side per village it controls per turn.
* '''scroll_to_leader''': (boolean) Whether the game view scrolls to the side leader at the start of their turn.
* '''flag''': Flag animation for villages owned by this side (see [[SideWML|[side]]]). Unless previously specified in [side] or changed with WML (see [[DirectActionsWML#.5Bmodify_side.5D|[modify_side]]]), this value may be empty for the default flag animation.
* '''flag_icon''': Flag icon for the status bar for this side (see [[SideWML|[side]]]). Unless previously specified in [side] or changed with WML (see [[DirectActionsWML#.5Bmodify_side.5D|[modify_side]]]), this value may be empty for the default flag icon.
* '''village_support''': The number of unit levels this side is able to support (does not pay upkeep on) per village it controls.

==== [store_starting_location] ====

Stores the starting location of a side's leader in a variable. The variable is a composite type which will have members 'x', 'y', 'terrain' and 'owner_side' (villages only)

* [[StandardSideFilter]]: The starting locations of all matching sides will be stored. If multiple sides are matched, a WML array will be created.
* '''variable''': (default='location'): the name of the variable to store the location in

==== [store_time_of_day] ====

Stores time of day information from the current scenario into a WML variable container.

* '''x, y''': Location to store the time for. [[DirectActionsWML#.5Btime_area.5D|Time areas]] matter; illumination does not. If this is omitted, the global (location-independent) time is stored.

* '''variable''': (default='time_of_day') name of the container on which to store the information. The container will be filled with the same attributes found on [[TimeWML]].

* '''turn''': (defaults to the current turn number) changes the turn number for which time of day information should be retrieved.

==== [store_turns] ====

Stores the turn limit (the maximum number of turns). If there is no limit, this stores ''-1''.

* '''variable''': (default='turns') the name of the variable in which to store the turn limit.

==== [store_unit] ====

Stores details about units into a [[VariablesWML#Container|container]] variable. When a unit is stored, all keys and tags in the unit definition may be manipulated, including some others, with [[InternalActionsWML#.5Bset_variable.5D|[set_variable]]]. A sample '''list of these tags and keys''' can be found at [[InternalActionsWMLUnitTags]].

If you have a doubt about what keys are valid or what the valid value range is for each key, code a [store_unit] event, save the game, and examine what keys are in the file (or just examine the '''[unit]''' tag(s) in any save file). One can also use the [[CommandMode|:inspect]] command or the [[InterfaceActionsWML#.5Binspect.5D|[inspect]]] tag to open a game-state inspector dialog, which can be used to view unit properties.

Common usage is to manipulate a unit by using '''[store_unit]''' to store it into a variable, followed by manipulation of the variable, and then [[DirectActionsWML#.5Bunstore_unit.5D|[unstore_unit]]] to re-create the unit with the modified variables.

''Note: stored units also exist on the field, and modifying the stored variable will not automatically change the stats of the units. You need to use [unstore_unit]. See also [[DirectActionsWML#.5Bunstore_unit.5D|[unstore_unit]]] and [http://www.wesnoth.org/macro-reference.xhtml#FOREACH FOREACH].''

* '''[filter]''' with a [[StandardUnitFilter]] as argument. All units matching this filter will be stored. If there are multiple units, they will be stored into an array of variables. The units will be stored in order of their internal ''underlying_id'' attribute, which is usually in creation order (but you normally should not depend on the order).

* '''variable''': the name of the variable into which to store the unit(s)

* '''mode''': defaults to ''always_clear'', which clears the variable, whether or not a match is found. If mode is set to ''replace'', the variable will not be cleared, and units which match the filter will overwrite existing elements at the start of the array, leaving any additional elements intact if the original array contained more elements than there are units matching the filter. If mode is set to ''append'', the variable will not be cleared, and units which match the filter will be added to the array after the existing elements.

* '''kill''': if 'yes' the units that are stored will be removed from play. This is useful for instance to remove access to a player's recall list, with the intent to restore the recall list later.

==== [store_unit_type] ====

* '''type''': (required) the defined ID of the unit type, for example "Goblin Knight". Do not use a translation mark or it will not work correctly for different languages. A comma-separated list of IDs may also be used to store an array of unit types.

* '''variable''': the name of the variable into which to store the unit type information (default "unit_type")

==== [store_unit_type_ids] ====

* '''variable''': the name of the variable into which to store a comma-separated list of all unit type IDs including all from all loaded addons

==== [store_villages] ====

Stores a series of locations of villages that pass certain criteria into an array. Each member of the result array will have members 'x' and 'y' (the position) and 'terrain' (the terrain type) and 'owner_side'. note: The only advantage/difference this tag has, in comparison to using [store_locations]terrain=*^V*, is that the amount of hexes which are considered for a possible match is previously restricted to those with villages.

* '''variable''': the name of the variable (array) into which to store the locations (default: "location")
* '''[[StandardLocationFilter]]''' tags and keys as arguments

==== [store_items] ====

Stores current items in the scenario into an array. Each entry has at least members x and y and can have all of the other keys listed in the documentation of [[InterfaceActionsWML#.5Bitem.5D|[item]]] (depending on what was set during creating the item).

*'''variable''': name of the wml variable array to use (default "items")
*'''[[StandardLocationFilter]]''' keys as arguments: only items on locations matching this [[StandardLocationFilter]] will be stored

==== [store_relative_direction] ====

{{DevFeature1.13|0}}

Gets the relative direction from one hex to another. This is an interface to the function wesnoth uses to decide how a unit will face while it is moving / attacking / defending.

* '''[source]''' x and y must describe a map location
* '''[destination]''' similar
* '''variable''' name of the variable to store string result in (one of 'n', 'nw', 'ne', 's', 'sw', 'se')
* '''mode''' optional. 0 is the default setting corresponding to default wesnoth implementation used in animations. 1 is an alternate "radially symmetric" mode. The default mode breaks ties in the direction of south, since this makes more units face the player directly on screen. The radially symmetric mode breaks ties in the direction of counter-clockwise, and might be more appropriate in some cases.

==== [find_path] ====

A WML interface to the pathfinder. Calculates the path between a unit and a location and returns the result in a WML variable, that contains also an array for every step of the path.

*'''[traveler]''': [[StandardUnitFilter]], only the first matching unit will be used for calculation
*'''[destination]''': [[StandardLocationFilter]], only the first matching nearest hex will be used
*'''variable''': the variable name where the result will be stored, if no value is supplied 'path' will be used as default name. Each step will be stored in a [step] array inside that variable.
*'''allow_multiple_turns''': default no, if yes also moves that require more than one turn will be calculated.
*'''check_visibility''': default no, if yes the path will not be computed if some hexes are not visible due to shroud.
*'''check_teleport''': default yes; if no, teleport won't be taken in account while computing path.
*'''check_zoc''': default yes; if no, unit ZOCs won't be considered while calculating the path.
This is the structure of the variable returned by [find_path]:
[path]
hexes = the total length of the path
if the path is calculated to an impassable hex, or the move requires multiple turns
and allow_multiple_turns is no, its value will be 0.
from_x, from_y = location of the unit
to_x, to_y = destination
movement_cost = total movement cost required by unit to reach that hex
required_turns = total turns required by unit to reach that hex
[step]
x, y = location of the step
terrain = terrain of the step
movement_cost = movement cost required by unit to reach that hex
required_turns = turns required by unit to reach that hex
[/step]
[/path]

==== [unit_worth] ====
Takes only an inline [[StandardUnitFilter]] (only the first matching unit will be used for calculation) and outputs the following variables:
*''cost'', the current unit cost;
*''next_cost'', the cost of the most expensive advancement;
*''health'', the health of the unit in percentage;
*''experience'', current experience in percentage;
*''unit_worth'', how much the unit is worth.

Mainly used for internal AI checks, but one could in theory just do anything with it.

[event]
name=moveto
[unit_worth]
x,y=$x1,$y1
[/unit_worth]
[message]
id=$unit.id
message=_"I cost $cost gold, with $health|% of my hitpoints and $experience|% on the way to cost $next_cost|.
I am estimated to be worth $unit_worth"
[/message]
[clear_variable]
name=cost,next_cost,health,experience,unit_worth
[/clear_variable]
[/event]

=== [clear_variable] ===

This will delete the given variable. This tag can delete a scalar or an entire array; it can also delete one container at an array index. The macro [http://www.wesnoth.org/macro-reference.xhtml#CLEAR_VARIABLE CLEAR_VARIABLE] is a shortcut for this tag.

This action is good to use to clean up the set of variables; for example, a well-behaved scenario will delete any variables that should not be kept for the next scenario before the end of the scenario. One can also clear tags and variables of stored units; for example, one can remove [trait]s and [object]s.

* '''name''': the name of the variable to clear. This can also be a comma-separated list of multiple variable names.
** If a name ends with an array index, then it deletes that one container, and shifts the indexes of all subsequent containers. For example, <code>{CLEAR_VARIABLE my_awesome_array[2]}</code> deletes <code>my_awesome_array[2]</code>, but then moves <code>my_awesome_array[3]</code> to <code>my_awesome_array[2]</code>, moves <code>my_awesome_array[4]</code> to <code>my_awesome_array[3]</code>, and so on until the end of the array.
** Note that <code>{CLEAR_VARIABLE my_awesome_array}</code> deletes the entire array, but <code>{CLEAR_VARIABLE my_awesome_array[0]}</code> deletes only the first container.

=== [sync_variable] ===

{{DevFeature1.13|0}}

Sets one or multiple variables to the same value as on all clients and also on replays, it uses the value from the currently active side.
* '''name''' the name of the variable to synchonize this can be a comma seperated list.

== Other Internal Actions ==

Believe it or not, there are some internal actions that are not focused primarily on variables. They are all grouped here.

=== [fire_event] ===

Trigger a WML event (used often for [[EventWML#Custom_events|custom events]])

* '''name''': the name of event to trigger
** ''(Optional)'' {{DevFeature1.13|6}}

* '''id''': ''(Optional)'' the id of a single event to trigger {{DevFeature1.13|6}}

* '''[primary_unit]''': ''(Optional)'' Primary unit for the event. Will never match on a recall list unit. The first unit matching the filter will be chosen.
**[[StandardUnitFilter]] as argument. Do not use a [filter] tag.

* '''[secondary_unit]''': ''(Optional)'' Same as '''[primary_unit]''' except for the secondary unit.
**[[StandardUnitFilter]] as argument. Do not use a [filter] tag.

* '''[primary_attack]''': Information passed to the primary attack filter and $weapon variable on the new event.

* '''[secondary_attack]''': Information passed to the second attack filter and $second_weapon variable on the new event.

=== [remove_event] ===
{{DevFeature1.13|0}}

Removes the event with the specified id. Equivalent to <i>[event] id=foo remove=yes</i>. See [[EventWML#remove|EventWML]].

* '''id''': the id of the event to remove. May be a comma separated list.

=== [insert_tag] ===

Inserts a variable as WML. In other words, the value of the passed [[VariablesWML#Container|container variable]] will be injected into the game as if they had been written out in WML form. ([[#.5Binsert_tag.5D_Example|See Example]]).

Tag insertion is a special case in that it can be used in places where other ActionWML cannot be used. The basic rule is that anywhere that $variable syntax works, tag insertion will also work. In practice this means pretty much everywhere except directly within top-level scenario tags.

*'''name''': The ["name"] to be given to the tag. This must be a tag which would be valid at the place where [insert_tag] is used, for anything to happen. (For example, if used as ActionWML, it should be a [[ActionWML]] tag name, and it may be a recognized subtag such as "option" when used within a [message]).

*'''variable''': Name of the container variable which will have its value inserted into the tag.

=== [role] ===

Tries to find a unit to assign a role to.<br>This is useful if you want to choose a non-major character to say some things during the game. Once a role is assigned, you can use '''role=''' in a unit filter to identify the unit with that role (See [[FilterWML]]).<br>However, there is no guarantee that roles will ever be assigned. You can use '''[have_unit]''' (see [[ConditionalActionsWML#Condition_Tags|Condition Tags]]) to see whether a role was assigned. This tag uses a [[StandardUnitFilter]] (without [filter]) with the modification to order the search by type, mark only the first unit found with the role, and the role attribute is not used in the search. If for some reason you want to search for units that have or don't have existing roles, you can use one or more [not] filters. The will check recall lists in addition to units on the map. In normal use, you will probably want to include a ''side'' attribute to force the unit to be on a particular side.

* '''role''': the value to store as the unit's role. This role is not used in the [[StandardUnitFilter]] when doing the search for the unit to assign this role to.

* '''type''': a comma-separated list of possible types the unit can be. If any types are given, then units will be searched by type in the order listed. If no type is given, then no particular order with respect to type is guaranteed.

* '''search_recall_list''': {{DevFeature1.13|5}} whether to consider units on the recall list when assigning the role. Can be either yes or no, defaults to yes. {{DevFeature1.13|6}} If set to 'only', then units on the map are not considered when assigning the role - only units on the recall list can receive it.

* '''[else]''' {{DevFeature1.13|5}} ActionWML to execute if the game is unable to find a unit to assign the role to. For example, this could be used to create a new unit satisfying the role.

* '''[auto_recall]''' {{DevFeature1.13|6}} If present, and the role is assigned to a unit on the recall list, then that unit is recalled. Supports all unique keys of [[DirectActionsWML#.5Brecall.5D|[recall]]], but no [[StandardUnitFilter]].

* [[StandardUnitFilter]], do not use a [filter] sub-tag. SUF's role= and type= keys are not used: if you want to use them, use a nested SUF wrapped inside a [and] tag.

=== [random_placement] ===
{{DevFeature1.13|2}}

Selects randomly a given number of locations from a given set of locations and exectutes the given code for each of those locations.

* '''[filter_location]''': a [[StandardLocationFilter]].
* '''[command]''': contains ActionWml that is executed for each of the locations.
* '''num_items''': the number of locations that should be selected, this can be a (lua) expression to calculate the number of locations based on the number of locations that match the filter, for example (size * 0.5) will execute the command for exactly half of the locations (rounded down)
* '''variable''': The name of the variable that contains the current location during the execution of [command]. This is a container with the attributes x and y.
* '''min_distance''': The minimum distance of 2 chosen locations, a value less than 0 means that the same locations can be chosen more than one time.
* '''allow_less''': If yes, the tag will not show an error in case there were less than num_items locations available.

=== Flow control actions ===

{{DevFeature1.13|2}}

There are three actions that alter the flow of execution. They are '''[break]''', '''[continue]''', and '''[return]'''. All of them take no arguments.

* '''[break]''': The nearest enclosing loop immediately stops executing, and control continues with the next action after the end of that loop. If there is no enclosing loop, this is equivalent to '''[return]'''.
* '''[continue]''': The nearest enclosing loop immediately stops executing, and control continues at the beginning of that loop, with any iteration variables updated for the next iteration. If there is no enclosing loop, this is an error.
* '''[return]''': Control immediately returns to the Wesnoth engine. No further WML actions are executed in this context. If there was another event queued, that event will be run as usual.

== Examples ==

=== Using [set_variables] to Create Arrays of WML ===

[set_variables]
name=arr
mode=replace
[value]
foo=bar
[/value]
[value]
foo=more
[/value]
[/set_variables]
{DEBUG_MSG $arr[0].foo}
{DEBUG_MSG $arr[1].foo}

This will produce two output messages, first one saying '''bar''' and next one saying '''more'''.

=== [insert_tag] Example ===

[event]
name=moveto

[set_variable]
name=temp.speaker
value=Konrad
[/set_variable]

[set_variable]
name=temp.message
value= _ "Yo Kalenz!"
[/set_variable]

[insert_tag]
name=message
variable=temp
[/insert_tag]
[/event]

This is effectively identical to:

[event]
name=moveto

[message]
speaker=Konrad
message= _ "Yo Kalenz!"
[/message]
[/event]

== See Also ==
* [[VariablesWML]]
* [[ActionWML]]
** [[ConditionalWML]]
** [[DirectActionsWML]]
** [[InterfaceActionsWML]]
* [[EventWML]]
* [[ReferenceWML]]

[[Category: WML Reference]]
[[Category: ActionsWML]]

MapGeneratorWML

2016-08-07T14:32:19Z

Spixi: removed confusing examples and added a note to the cave generator

Map Generator WML is used to create scenarios which are randomly generated. Of course, any scenario may reconfigure itself during a start / prestart event as much as it likes, using randomness, but the Map Generator WML has the following advantages:

* Wesnoth has several built-in map generators which can be configured with options, and these are much better developed than any existing pure WML options.
* Map generation occurs before the scenario is even loaded, something which is not possible for WML events. In an mp game, the map generator code will run only on the host, side-stepping any synchronization issues, and keeping your scenario code as simple as possible.
* For scenarios with "allow_new_game=yes" and which use map generators, the generator may be reconfigured in the mp create screen (assuming that someone has coded a dialog for it). The user can also select to regenerate the map and get instant feedback from the minimap display.

== Scenario vs map generation ==

Every map generator can be used in either '''scenario_generation''' mode or '''map_generation''' mode. In map_generation mode, the generator is only used to replace the map_data of your scenario. In scenario_generation mode, the entire [scenario] tag is replaced.

To select a map generator and mode, in your [scenario] tag you must place '''one of'''
* '''scenario_generation=algorithm'''
* '''map_generation=algorithm'''
where '''algorithm''' is the generator algorithm you want to use. Note that not every algorithm is designed to be use with both of these options.

You must additionally place a [generator] tag in your scenario, which contains the options to the map generator.

== [generator] ==

The exact things that should be placed in [generator] depend on what algorithm you pick. There are three kinds of generators, '''default''', '''cave''', '''lua''' {{DevFeature1.13|0}}, and '''yamg''' {{DevFeature1.13|0}}.

For which key to use and what value, see the section for the generator you want to use.

===The lua generator===
The lua generator type specifies a custom map generator, which you provide via lua scripts.

The following keys are recognized for '''[generator]''' when the lua generator is used:
* '''create_map''' : A lua routine which returns a string containing the new map_data. The entire contents of the '''[generator]''' are passed to the script in a lua table (see [[LuaWML]]), via the argument '''...''' (see http://www.lua.org/pil/5.2.html).
* '''create_scenario''' : The same, but returning a '''[scenario]''' tag for the new scenario, as a lua table.

Any other keys are used only by the lua script.

The following keys of the output [scenario] are specifically watched by the mp create screen:
* '''id'''
* '''name'''
* '''description'''
* '''error_message'''

====Available Lua API====
Most of the usual in-game API, in the table '''wesnoth''', is not available to lua scripts. However the usual standard lua libs are available, and a random number generator object is available from the Rng table. This is an instance of the Mersenne Twister 19937 random number generator from the C++11 standard.

* '''rng = Rng:create()''' : creates a new rng object
* '''rng:seed()''' : seed an rng, expects a string in hexadecimal format
* '''rng:draw()''' : draw a 32-bit random integer from the rng

It is highly recomended NOT to use the math.random function in random map generators, becasue math.random breaks the 'seed' function for random map generators in the editor.

===The Default Generator===
The default generator can be used to generate map data for any scenario. The data in this section is inferred from “data/multiplayer/scenarios/Random_Scenario.cfg”, usage in add-on content, and inspection of mapgen.cpp

'''Excerpt from mapgenerator comments:'''

* Basically we generate alot of hills, each hill being centered at a certain point, with a certain radius - being a half sphere. Hills are combined additively to form a bumpy surface. The size of each hill varies randomly from 1-hill_size. We generate 'iterations' hills in total. The range of heights is normalized to 0-1000. 'island_size' controls whether or not the map should tend toward an island shape, and if so, how large the island should be. Hills with centers that are more than 'island_size' away from the center of the map will be inverted (i.e. be valleys). 'island_size' as 0 indicates no island.

To use the default '''[generator]''' your '''[scenario]''' tag must contain one of the following keys:
* '''scenario_generation=default'''
* '''map_generation=default'''
If ‘scenario_generation’ is used, the engine will expect for your entire '''[scenario]''' sub tags to be inside a '''[scenario]''' tag inside '''[generator]'''. Tags outside of this will be ignored. There may be value in this, but at this writing, it’s not clear.
‘map_generation=default’ is simpler and more commonly used. It is also necessary to use this key so that you can regenerate a map in MP game creation.
In its use only generator data is in the '''[generator]''' tag, all other '''[scenario]''' data is placed outside of it. The exception is if you are making an initial MP scenario available in MP game creation, for this a '''[scenario]''' tag must appear inside of '''[generator]''', containing the '''[scenario]''' subtags you want to use. See “data/multiplayer/scenarios/Random_Scenario.cfg” for an example.

The following key/tags are recognized for '''[generator]''' when the default generator is used:
* '''[scenario]''': See [[ScenarioWML]]
* '''name'''
** '''default'''
* '''map_width''','''map_height''': size of the map to generate
* '''iterations''': the number of times an attempt is being made to generate a hill
* '''hill_size''': hills will have a random size between 1 and ''hill_size''
* '''max_lakes''': the number of times an attempt is being made to generate a lake
* '''min_lake_height''': lakes are the starting point of rivers and need to start above a certain height
* '''lake_size''': the size of a lake still randomly generated
* '''river_frequency''': determine how much a river can run uphill and thus generate more rivers

* '''villages''': villages per 1,000 hexes
* '''players''': Number of starting locations for the map.
* '''castle_size''': Number of castle tiles (including the keep), per player.
* '''temperature_iterations''': Same as iterations, but for the temperature map.
* '''temperature_size''': Same as hill_size, but for the temperature map. (Temperature map is generated the same way as a hill map, but is hard coded with a island_size of 0.)
* '''roads''': number of roads the generator will attempt to make
* '''road_windiness''': Use 1 for the road to be made using the cheapest path (based on [road_cost] tags), higher values introduce randomness to make the road wind a bit.
* '''island_size''': Use 1-5 for coastal maps and 6-10 for island maps. Bigger values may crash map generation process. Bigger numbers makes more water (and less land)
* '''default_flatland''': If not specified, is Grassland. If your height tags don't go down to 0, the default_flatland will be used (possibly in other cases as well).
* '''[height]''': list of common terrain types that come in at different heights, from highest to lowest. Good WML will have the range of 1000-0 covered.
** '''height''': the terrain specified below will appear at this height and up.
** '''terrain''': 1 terrain code
* '''[convert]''': used to make terrain conversions. For example, water becomes ice at low temperatures, grass snow, etc. If the terrain is between the min_x and max_x it will be converted. If min_x is not defined it will default to a large negative number. If max_x is not defined it will default to a large positive number
** '''min_height'''
** '''max_height'''
** '''min_temperature'''
** '''max_temperature'''
** '''from''': a comma separated terrains to convert from
** '''to''': The terrain to convert these terrains to
* '''[road_cost]'''
** '''terrain''' 1 terrain code
** '''cost''': how expensive it is the create a road on this terrain, this influences the odds of this terrain getting a road
** '''convert_to_bridge''': a comma separated list of terrains; N/S, then NE/SW, then NW/SE.
** '''convert_to''': 1 terrain code (note using both ''convert_to_bridge'' and ''convert_to'' might result in unwanted results)
* '''[village]''': The conversion of terrains to villages
** '''terrain''': 1 terrain code which will be converted to a village
** '''convert_to''': 1 terrain code for the village
** '''adjacent_liked''': a comma separated terrain list. This list increases the rating for a certain location, every tile around the location will be tested against this list and for every match the rating of the location is increased. The same terrain twice in the list will double the rating increase for that location.
** '''rating''': chance of appearing
* '''[castle]''': the conversion of castles
** '''valid_terrain''': a comma-separated terrain list with terrains which are allowed to be converted to a castle.
** '''min_distance''': all castles generated must be this number of hexes apart from each other
* '''[naming]''': The names used to label landscape features (forests, lakes, etc.). This controls, for example, the "Sal" part of "Sal's Crossing". If this tag is empty, those labels should be suppressed. (Due to a bug, they are not suppressed prior to 1.11.1.) The predefined macro VILLAGE_NAMES is one option for the contents of this tag. If that macro is not used, this tag takes one key.
** '''Changes in release 1.13.5''':
*** The new [[Context-free grammar|Context-free grammar name]] (CFG) generator is now supported
*** '''male_names''' is now deprecated. Use '''base_names''' for the Markov-chain based or '''base_name_generator''' for the CFG generator instead
*** It is now possible to have generator-specific overrides of the default naming rules which are defined in "data/english.cfg". You may override the following naming rules by adding them to the [naming] tag of your generator instance:
{| class="wikitable"
!Key
!Supported variables
|-
|bridge_name_generator=
|$base
|-
|road_name_generator=
|$base
|-
|river_name_generator=
|$base
|-
|forest_name_generator=
|$base
|-
|lake_name_generator=
|$base
|-
|mountain_name_generator=
|$base
|-
|swamp_name_generator=
|$base
|}

* '''[village_naming]''': The names used to label villages. This controls, for example, the "Fox" part of "Foxham". If this tag is empty, those labels should be suppressed. (Due to a bug, they are not suppressed prior to 1.11.1.) The predefined macro VILLAGE_NAMES is one option for the contents of this tag. If that macro is not used, this tag takes one key. The village naming depends on the adjacent landscape features, e.g. a village near a forest with the name "Rock Forest" may be named "Rockwood".
** '''male_names'''
** '''Changes in release 1.13.5''':
*** The new [[Context-free grammar|Context-free grammar name]] (CFG) generator is now supported
*** '''male_names''' is now deprecated. Use '''base_names''' for the Markov-chain based or '''base_name_generator''' for the CFG generator instead
*** It is now possible to have generator-specific overrides of the default village naming rules which are defined in "data/english.cfg". You may override the following village naming rules by adding them to the [village_naming] tag of your generator instance:
{| class="wikitable"
!Key
!Supported variables
|-
|name_generator=
|$base
|-
|lake_name_generator=
|$base, $lake
|-
|river_name_generator=
|$base, $river
|-
|bridge_name_generator=
|$base, $river, $bridge
|-
|grassland_name_generator=
|$base
|-
|forest_name_generator=
|$base, $forest
|-
|hill_name_generator=
|$base
|-
|mountain_name_generator=
|$base, $mountain
|-
|mountain_anon_name_generator=
|$base
|-
|road_name_generator=
|$base, $road
|-
|swamp_name_generator=
|$base, $swamp
|}

===The Cave Generator===
The cave generator generates a system of chambers and passages similar to the levels in dungeon crawling games like Rogue. It does not appear to have been written for multiplayer scenario game creation like the default generator was. It is used in '''campaigns\Sceptre_of_Fire\scenarios\4_Gathering_Materials.cfg''' & '''campaigns\Heir_To_The_Throne\scenarios\ 17_Scepter_of_Fire.cfg '''. The data here is inferred from those scenarios and an inspection of cavegen.cpp

To use the cave '''[generator]''' your '''[scenario]''' tag must contain one of the following keys:
* '''scenario_generation=cave'''
* '''map_generation=cave'''
Here it is recommend you use ‘scenario_generation’ as there are examples to follow, though it may be possible to use’ map_generation’.

The following key/tags are recognized for '''[generator]''' when the cave generator is used:
* '''[settings]''': behaves as if '''[scenario]''', See [[ScenarioWML]]
* '''map_width''','''map_height''': size of the map to generate
* '''village_density''': influences number of villages
* '''flipx_chance''': Chance to flip x coordinates, that meens the map is mirrored at the vertical axis in its midth.
* '''flipy_chance''': Chance to flip y coordinates, that meens the map is mirrored at the horizontal axis in its midth.
* '''[chamber]''': for underground maps
** '''id''': a name used to identify where the passages lead. See the [passage] tag, below.
** '''x''','''y''': approximate location of the center hex of the chamber. Unfortunately it isn't always exact. Can be a single number (x=5) or a range (x=10-20)
** '''size''': circular radius of the chamber, including the center hex
** '''jagged''': a good value is probably between 0-50 (not sure exactly)
** '''chance''': chance for the chamber to be generated, between 0 and 100, 100 if key not present
** '''[items]''': See [[ScenarioWML]]. This can contain tags normally found under [scenario] like [side], [item], and [event]. Moveto events definitely work here (using the same_location_as_previous key instead of a location filter). Other events can be placed in the [settings] tag, above. Locations of items will be generated randomly. The attribute '''same_location_as_previous=yes''' means that the filter for a moveto event (see [[EventWML]]) is the same as the location of the previous item.
** '''[passage]''': defines a pathway between chambers
*** '''destination''': the id key of the destination chamber
*** '''windiness''': a good value is probably between 1-10
*** '''laziness''':
*** '''width''': number of hexes
*** '''jagged''': a good value is probably between 1-10
*** '''chance''': chance for the passage to be generated, between 0 and 100, 100 if key not present

=== YAMG generator ===

*** Please document me! ***

== Infrastructure ==

* The default generator settings are loaded from a scenario file under data/multiplayer/scenarios.
* mapgen_dialog overwrites these values if necessary.
* The create_map / create_scenario function is called by one of the following
** multiplayer_create_engine.cpp:394
** context_manager.cpp:648
** map_create.cpp:56
* A map buffer is written to res["map_data"]
* the config res is passed to the calling function.

== See Also ==

* [[ScenarioWML]]
* [[ReferenceWML]]

[[Category: WML Reference]]

MapGeneratorWML

2016-08-07T00:07:20Z

Spixi: /* The Default Generator */ Added changes of release 1.13.5

Map Generator WML is used to create scenarios which are randomly generated. Of course, any scenario may reconfigure itself during a start / prestart event as much as it likes, using randomness, but the Map Generator WML has the following advantages:

* Wesnoth has several built-in map generators which can be configured with options, and these are much better developed than any existing pure WML options.
* Map generation occurs before the scenario is even loaded, something which is not possible for WML events. In an mp game, the map generator code will run only on the host, side-stepping any synchronization issues, and keeping your scenario code as simple as possible.
* For scenarios with "allow_new_game=yes" and which use map generators, the generator may be reconfigured in the mp create screen (assuming that someone has coded a dialog for it). The user can also select to regenerate the map and get instant feedback from the minimap display.

== Scenario vs map generation ==

Every map generator can be used in either '''scenario_generation''' mode or '''map_generation''' mode. In map_generation mode, the generator is only used to replace the map_data of your scenario. In scenario_generation mode, the entire [scenario] tag is replaced.

To select a map generator and mode, in your [scenario] tag you must place '''one of'''
* '''scenario_generation=algorithm'''
* '''map_generation=algorithm'''
where '''algorithm''' is the generator algorithm you want to use. Note that not every algorithm is designed to be use with both of these options.

You must additionally place a [generator] tag in your scenario, which contains the options to the map generator.

== [generator] ==

The exact things that should be placed in [generator] depend on what algorithm you pick. There are three kinds of generators, '''default''', '''cave''', '''lua''' {{DevFeature1.13|0}}, and '''yamg''' {{DevFeature1.13|0}}.

For which key to use and what value, see the section for the generator you want to use.

===The lua generator===
The lua generator type specifies a custom map generator, which you provide via lua scripts.

The following keys are recognized for '''[generator]''' when the lua generator is used:
* '''create_map''' : A lua routine which returns a string containing the new map_data. The entire contents of the '''[generator]''' are passed to the script in a lua table (see [[LuaWML]]), via the argument '''...''' (see http://www.lua.org/pil/5.2.html).
* '''create_scenario''' : The same, but returning a '''[scenario]''' tag for the new scenario, as a lua table.

Any other keys are used only by the lua script.

The following keys of the output [scenario] are specifically watched by the mp create screen:
* '''id'''
* '''name'''
* '''description'''
* '''error_message'''

====Available Lua API====
Most of the usual in-game API, in the table '''wesnoth''', is not available to lua scripts. However the usual standard lua libs are available, and a random number generator object is available from the Rng table. This is an instance of the Mersenne Twister 19937 random number generator from the C++11 standard.

* '''rng = Rng:create()''' : creates a new rng object
* '''rng:seed()''' : seed an rng, expects a string in hexadecimal format
* '''rng:draw()''' : draw a 32-bit random integer from the rng

It is highly recomended NOT to use the math.random function in random map generators, becasue math.random breaks the 'seed' function for random map generators in the editor.

===The Default Generator===
The default generator can be used to generate map data for any scenario. The data in this section is inferred from “data/multiplayer/scenarios/Random_Scenario.cfg”, usage in add-on content, and inspection of mapgen.cpp

'''Excerpt from mapgenerator comments:'''

* Basically we generate alot of hills, each hill being centered at a certain point, with a certain radius - being a half sphere. Hills are combined additively to form a bumpy surface. The size of each hill varies randomly from 1-hill_size. We generate 'iterations' hills in total. The range of heights is normalized to 0-1000. 'island_size' controls whether or not the map should tend toward an island shape, and if so, how large the island should be. Hills with centers that are more than 'island_size' away from the center of the map will be inverted (i.e. be valleys). 'island_size' as 0 indicates no island.

To use the default '''[generator]''' your '''[scenario]''' tag must contain one of the following keys:
* '''scenario_generation=default'''
* '''map_generation=default'''
If ‘scenario_generation’ is used, the engine will expect for your entire '''[scenario]''' sub tags to be inside a '''[scenario]''' tag inside '''[generator]'''. Tags outside of this will be ignored. There may be value in this, but at this writing, it’s not clear.
‘map_generation=default’ is simpler and more commonly used. It is also necessary to use this key so that you can regenerate a map in MP game creation.
In its use only generator data is in the '''[generator]''' tag, all other '''[scenario]''' data is placed outside of it. The exception is if you are making an initial MP scenario available in MP game creation, for this a '''[scenario]''' tag must appear inside of '''[generator]''', containing the '''[scenario]''' subtags you want to use. See “data/multiplayer/scenarios/Random_Scenario.cfg” for an example.

The following key/tags are recognized for '''[generator]''' when the default generator is used:
* '''[scenario]''': See [[ScenarioWML]]
* '''name'''
** '''default'''
* '''map_width''','''map_height''': size of the map to generate
* '''iterations''': the number of times an attempt is being made to generate a hill
* '''hill_size''': hills will have a random size between 1 and ''hill_size''
* '''max_lakes''': the number of times an attempt is being made to generate a lake
* '''min_lake_height''': lakes are the starting point of rivers and need to start above a certain height
* '''lake_size''': the size of a lake still randomly generated
* '''river_frequency''': determine how much a river can run uphill and thus generate more rivers

* '''villages''': villages per 1,000 hexes
* '''players''': Number of starting locations for the map.
* '''castle_size''': Number of castle tiles (including the keep), per player.
* '''temperature_iterations''': Same as iterations, but for the temperature map.
* '''temperature_size''': Same as hill_size, but for the temperature map. (Temperature map is generated the same way as a hill map, but is hard coded with a island_size of 0.)
* '''roads''': number of roads the generator will attempt to make
* '''road_windiness''': Use 1 for the road to be made using the cheapest path (based on [road_cost] tags), higher values introduce randomness to make the road wind a bit.
* '''island_size''': Use 1-5 for coastal maps and 6-10 for island maps. Bigger values may crash map generation process. Bigger numbers makes more water (and less land)
* '''default_flatland''': If not specified, is Grassland. If your height tags don't go down to 0, the default_flatland will be used (possibly in other cases as well).
* '''[height]''': list of common terrain types that come in at different heights, from highest to lowest. Good WML will have the range of 1000-0 covered.
** '''height''': the terrain specified below will appear at this height and up.
** '''terrain''': 1 terrain code
* '''[convert]''': used to make terrain conversions. For example, water becomes ice at low temperatures, grass snow, etc. If the terrain is between the min_x and max_x it will be converted. If min_x is not defined it will default to a large negative number. If max_x is not defined it will default to a large positive number
** '''min_height'''
** '''max_height'''
** '''min_temperature'''
** '''max_temperature'''
** '''from''': a comma separated terrains to convert from
** '''to''': The terrain to convert these terrains to
* '''[road_cost]'''
** '''terrain''' 1 terrain code
** '''cost''': how expensive it is the create a road on this terrain, this influences the odds of this terrain getting a road
** '''convert_to_bridge''': a comma separated list of terrains; N/S, then NE/SW, then NW/SE.
** '''convert_to''': 1 terrain code (note using both ''convert_to_bridge'' and ''convert_to'' might result in unwanted results)
* '''[village]''': The conversion of terrains to villages
** '''terrain''': 1 terrain code which will be converted to a village
** '''convert_to''': 1 terrain code for the village
** '''adjacent_liked''': a comma separated terrain list. This list increases the rating for a certain location, every tile around the location will be tested against this list and for every match the rating of the location is increased. The same terrain twice in the list will double the rating increase for that location.
** '''rating''': chance of appearing
* '''[castle]''': the conversion of castles
** '''valid_terrain''': a comma-separated terrain list with terrains which are allowed to be converted to a castle.
** '''min_distance''': all castles generated must be this number of hexes apart from each other
* '''[naming]''': The names used to label landscape features (forests, lakes, etc.). This controls, for example, the "Sal" part of "Sal's Crossing". If this tag is empty, those labels should be suppressed. (Due to a bug, they are not suppressed prior to 1.11.1.) The predefined macro VILLAGE_NAMES is one option for the contents of this tag. If that macro is not used, this tag takes one key.
** '''Changes in release 1.13.5''':
*** The new [[Context-free grammar|Context-free grammar name]] (CFG) generator is now supported
*** '''male_names''' is now deprecated. Use '''base_names''' for the Markov-chain based or '''base_name_generator''' for the CFG generator instead
*** It is now possible to have generator-specific overrides of the default naming rules which are defined in "data/english.cfg". You may override the following naming rules by adding them to the [naming] tag of your generator instance:
{| class="wikitable"
!Key
!Supported variables
!Default
|-
|bridge_name_generator=
|$base
|<nowiki>_ << main=$base{!}’s Bridge|$base{!}’s Crossing >></nowiki>
|-
|road_name_generator=
|$base
|<nowiki>_ << main=$base{!}’s Highway|$base{!}’s Pass|Path of $base >></nowiki>
|-
|river_name_generator=
|$base
|<nowiki>_ << main=$base River|River $base >></nowiki>
|-
|forest_name_generator=
|$base
|<nowiki>_ << main=$base Forest|$base{!}’s Forest >></nowiki>
|-
|lake_name_generator=
|$base
|_ << main=$base{!} Lake >>
|-
|mountain_name_generator=
|$base
|<nowiki>_ << main=$base{!}’s Peak|Mount $base >></nowiki>
|-
|swamp_name_generator=
|$base
|<nowiki>_ << main=$base{!}’s Swamp|$base{!}marsh|$base{!}fen >></nowiki>
|}

* '''[village_naming]''': The names used to label villages. This controls, for example, the "Fox" part of "Foxham". If this tag is empty, those labels should be suppressed. (Due to a bug, they are not suppressed prior to 1.11.1.) The predefined macro VILLAGE_NAMES is one option for the contents of this tag. If that macro is not used, this tag takes one key. The village naming depends on the adjacent landscape features, e.g. a village near a forest with the name "Rock Forest" may be named "Rockwood".
** '''male_names'''
** '''Changes in release 1.13.5''':
*** The new [[Context-free grammar|Context-free grammar name]] (CFG) generator is now supported
*** '''male_names''' is now deprecated. Use '''base_names''' for the Markov-chain based or '''base_name_generator''' for the CFG generator instead
*** It is now possible to have generator-specific overrides of the default village naming rules which are defined in "data/english.cfg". You may override the following village naming rules by adding them to the [village_naming] tag of your generator instance:
{| class="wikitable"
!Key
!Supported variables
!Default
|-
|name_generator=
|$base
|<nowiki>_ << main = $base{!}bury|$base{!}ham|$base{!}ton|$base{!}bury >></nowiki>
|-
|lake_name_generator=
|$base, $lake
|<nowiki>_ << main=$base{!}harbor|$base{!}port|$lake{!}port|$lake{!}harbor >></nowiki>
|-
|river_name_generator=
|$base, $river
|<nowiki>_ << main=$base{!}ham|$base{!}ford|$base{!}cross|$river{!}ford|$river{!}cross|$base on $river >></nowiki>
|-
|bridge_name_generator=
|$base, $river, $bridge
|<nowiki>_ << main=$river{!}bridge|$river{!}bridge|$river{!}bridge|$base{!}ham|$base{!}bridge|$bridge{!}ham|$bridge{!}ton >></nowiki>
|-
|grassland_name_generator=
|$base
|<nowiki>_ << main=$base{!}ham|$base{!}ton|$base{!}field >></nowiki>
|-
|forest_name_generator=
|$base, $forest
|<nowiki>_ << main=$base{!}ham|$base{!}ton|$base{!}wood|$base Forest|$forest{!}wood|$forest{!}ham|$forest{!}ton >></nowiki>
|-
|hill_name_generator=
|$base
|<nowiki>_ << main=$base{!}ham|$base{!}bury|$base{!}ton|$base{!}hill|$base{!}crest >></nowiki>
|-
|mountain_name_generator=
|$base, $mountain
|<nowiki>_ << main=$mountain{!}mont|$mountain{!}cliff|$mountain{!}bury|$mountain{!}ham >></nowiki>
|-
|mountain_anon_name_generator=
|$base
|<nowiki>_ << main=$base{!}ham|$base{!}bury|$base{!}ton|$base{!}mont|$base{!}mont|$base{!}cliff|$base{!}cliff >></nowiki>
|-
|road_name_generator=
|$base, $road
|<nowiki>_ << main=$road{!}’s Rest|$road{!}’s Waypoint|$road{!}bury|$road{!}ham|$base{!}bury|$base{!}ham >></nowiki>
|-
|swamp_name_generator=
|$base, $swamp
|<nowiki>_ << main=$base{!}bury|$base{!}ham|$base{!}ton|$swamp{!}bury|$swamp{!}ham|$swamp{!}ton >></nowiki>
|}

===The Cave Generator===
The cave generator does not appear to have been written for multiplayer scenario game creation like the default generator was. It is used in '''campaigns\Sceptre_of_Fire\scenarios\4_Gathering_Materials.cfg''' & '''campaigns\Heir_To_The_Throne\scenarios\ 17_Scepter_of_Fire.cfg '''. The data here is inferred from those scenarios and an inspection of cavegen.cpp

To use the cave '''[generator]''' your '''[scenario]''' tag must contain one of the following keys:
* '''scenario_generation=cave'''
* '''map_generation=cave'''
Here it is recommend you use ‘scenario_generation’ as there are examples to follow, though it may be possible to use’ map_generation’.

The following key/tags are recognized for '''[generator]''' when the cave generator is used:
* '''[settings]''': behaves as if '''[scenario]''', See [[ScenarioWML]]
* '''map_width''','''map_height''': size of the map to generate
* '''village_density''': influences number of villages
* '''flipx_chance''': Chance to flip x coordinates, that meens the map is mirrored at the vertical axis in its midth.
* '''flipy_chance''': Chance to flip y coordinates, that meens the map is mirrored at the horizontal axis in its midth.
* '''[chamber]''': for underground maps
** '''id''': a name used to identify where the passages lead. See the [passage] tag, below.
** '''x''','''y''': approximate location of the center hex of the chamber. Unfortunately it isn't always exact. Can be a single number (x=5) or a range (x=10-20)
** '''size''': circular radius of the chamber, including the center hex
** '''jagged''': a good value is probably between 0-50 (not sure exactly)
** '''chance''': chance for the chamber to be generated, between 0 and 100, 100 if key not present
** '''[items]''': See [[ScenarioWML]]. This can contain tags normally found under [scenario] like [side], [item], and [event]. Moveto events definitely work here (using the same_location_as_previous key instead of a location filter). Other events can be placed in the [settings] tag, above. Locations of items will be generated randomly. The attribute '''same_location_as_previous=yes''' means that the filter for a moveto event (see [[EventWML]]) is the same as the location of the previous item.
** '''[passage]''': defines a pathway between chambers
*** '''destination''': the id key of the destination chamber
*** '''windiness''': a good value is probably between 1-10
*** '''laziness''':
*** '''width''': number of hexes
*** '''jagged''': a good value is probably between 1-10
*** '''chance''': chance for the passage to be generated, between 0 and 100, 100 if key not present

=== YAMG generator ===

*** Please document me! ***

== Infrastructure ==

* The default generator settings are loaded from a scenario file under data/multiplayer/scenarios.
* mapgen_dialog overwrites these values if necessary.
* The create_map / create_scenario function is called by one of the following
** multiplayer_create_engine.cpp:394
** context_manager.cpp:648
** map_create.cpp:56
* A map buffer is written to res["map_data"]
* the config res is passed to the calling function.

== See Also ==

* [[ScenarioWML]]
* [[ReferenceWML]]

[[Category: WML Reference]]

LuaWML/Sides

2016-08-06T18:49:25Z

Spixi: small typo

This page describes the [[LuaWML]] functions and helpers for handling sides and villages.

==== wesnoth.sides ====

This is not a function but a table indexed by side numbers. Its elements are proxy tables with these fields:
* '''side''': the side number
* '''gold''', '''village_gold''', '''base_income''': integers (read/write)
* '''total_income''': integer (read only)
* '''objectives''', '''user_team_name''': translatable strings (read/write)
* '''objectives_changed''': boolean (read/write)
* '''team_name''': string (read/write)
* '''controller''': string (read/write) :
:''note: In networked multiplayer, the controller attribute is ambiguous (won't be the same on all clients). Be very careful or you'll have OOS errors.''
: The controller attribute has 6 possible values: human, network, ai, network_ai, null, idle.

: A local human should always be "human", a local ai should always be "ai", a remote human should always be "network". and a remote ai should always be "network_ai". An empty side should be null on all clients.

: An idle side should appear similarly as a "human" side for all sides that don't own the idle side, i.e. as "network".

: These values may be checked using lua, or the :controller command in game.

: This value can only be set to 'human', 'ai' or 'null'.
* '''fog''': boolean (read)
* '''shroud''': boolean (read)
* '''hidden''': boolean (read/write)
* '''name''': string (read)
* '''faction''': {{DevFeature1.13|5}} id of the selected faction, string (multiplayer-only, read)
* '''faction_name''': {{DevFeature1.13|5}} name of the selected faction, string (multiplayer-only, read)
* '''color''': string (read/write)
* '''recruit''': table of strings (read/write)
* '''scroll_to_leader''': boolean (read/write)
* '''village_support''': string (read/write)
* '''flag''': string (read)
* '''flag_icon''': string (read)
* '''defeat_condition''': string (read/write) See description at [[SideWML]], [[ScenarioWML#Scenario_End_Conditions]]
* '''lost''': bool (read/write) If lost=true this side will be removed from the persitent list at the end of the scenario. This key can also be used to stop the engine from removing a side by setting it to false. Writing this key only works in a victory/defeat event.
* '''persistent''' {{DevFeature1.13|5}}: boolean (read/write)
* '''__cfg''': WML table (dump)

The metatable of these proxy tables appears as '''"side"'''.

local team = wesnoth.sides[1]
team.gold = team.gold + 50
wesnoth.message(string.format("%d sides", #wesnoth.sides))

==== wesnoth.get_sides ====

* '''wesnoth.get_sides(''filter'')'''

Returns a table array containing proxy tables for these sides matching the passed [[StandardSideFilter]]. The output is the same format as the wesnoth.sides table, above.
--set gold to 0 for all sides with a leader
local sides = wesnoth.get_sides({ {"has_unit", { canrecruit = true }} })
for i,v in ipairs(sides) do
v.gold = 0
end

==== wesnoth.get_village_owner ====

* '''wesnoth.get_village_owner(''x'', ''y'')'''

Returns the side that owns the village at the given location.

local owned_by_side_1 = wesnoth.get_village_owner(12, 15) == 1

==== wesnoth.set_village_owner ====

* '''wesnoth.set_village_owner(''x'', ''y'', ''side'', [''fire_events''])'''

Gives ownership of the village at the given location to the given side (or remove ownership if none). Ownership is also removed if nil or 0 is passed for the third parameter, but no capture events are fired in this case.
An optional 4th parameter (boolean true|false, default: false) can be passed determining whether to fire any capture events.

wesnoth.set_village_owner(12, 15, 1)

==== wesnoth.is_enemy ====

* '''wesnoth.is_enemy(''side1'', ''side2'')'''

Returns true if side A is enemy of side B, false otherwise.

local enemy_flag = wesnoth.is_enemy(1, 3)

==== wesnoth.match_side ====

* '''wesnoth.match_side(''side'', ''filter'')'''

Matches a side against a given [[StandardSideFilter]].

wesnoth.message(tostring(wesnoth.match_side(1, {{"has_unit", { type = "Troll" }}})))

==== wesnoth.get_starting_location ====

* '''wesnoth.get_starting_location(''side'')'''

Returns the starting location of the given side.

local loc = wesnoth.get_starting_location(1)
wesnoth.message(string.format("side 1 starts at (%u, %u)", loc[1], loc[2]))

==== helper.all_teams ====

* '''helper.all_teams()'''

Returns an iterator over teams that can be used in a for-in loop.

for team in helper.all_teams() do team.gold = 200 end

[[Category: Lua Reference]]

LuaWML/Sides

2016-08-06T18:48:55Z

Spixi: /* wesnoth.sides */ Commit a8f625f: Added faction and faction name to Lua Side proxy

This page describes the [[LuaWML]] functions and helpers for handling sides and villages.

==== wesnoth.sides ====

This is not a function but a table indexed by side numbers. Its elements are proxy tables with these fields:
* '''side''': the side number
* '''gold''', '''village_gold''', '''base_income''': integers (read/write)
* '''total_income''': integer (read only)
* '''objectives''', '''user_team_name''': translatable strings (read/write)
* '''objectives_changed''': boolean (read/write)
* '''team_name''': string (read/write)
* '''controller''': string (read/write) :
:''note: In networked multiplayer, the controller attribute is ambiguous (won't be the same on all clients). Be very careful or you'll have OOS errors.''
: The controller attribute has 6 possible values: human, network, ai, network_ai, null, idle.

: A local human should always be "human", a local ai should always be "ai", a remote human should always be "network". and a remote ai should always be "network_ai". An empty side should be null on all clients.

: An idle side should appear similarly as a "human" side for all sides that don't own the idle side, i.e. as "network".

: These values may be checked using lua, or the :controller command in game.

: This value can only be set to 'human', 'ai' or 'null'.
* '''fog''': boolean (read)
* '''shroud''': boolean (read)
* '''hidden''': boolean (read/write)
* '''name''': string (read)
* '''faction''': {{DevFeature1.13|5}} id of the selected faction, string (multiplayer-only, read)
* '''faction_name''': {{DevFeature1.13|5}} name of the selected faction, string(multiplayer-only, read)
* '''color''': string (read/write)
* '''recruit''': table of strings (read/write)
* '''scroll_to_leader''': boolean (read/write)
* '''village_support''': string (read/write)
* '''flag''': string (read)
* '''flag_icon''': string (read)
* '''defeat_condition''': string (read/write) See description at [[SideWML]], [[ScenarioWML#Scenario_End_Conditions]]
* '''lost''': bool (read/write) If lost=true this side will be removed from the persitent list at the end of the scenario. This key can also be used to stop the engine from removing a side by setting it to false. Writing this key only works in a victory/defeat event.
* '''persistent''' {{DevFeature1.13|5}}: boolean (read/write)
* '''__cfg''': WML table (dump)

The metatable of these proxy tables appears as '''"side"'''.

local team = wesnoth.sides[1]
team.gold = team.gold + 50
wesnoth.message(string.format("%d sides", #wesnoth.sides))

==== wesnoth.get_sides ====

* '''wesnoth.get_sides(''filter'')'''

Returns a table array containing proxy tables for these sides matching the passed [[StandardSideFilter]]. The output is the same format as the wesnoth.sides table, above.
--set gold to 0 for all sides with a leader
local sides = wesnoth.get_sides({ {"has_unit", { canrecruit = true }} })
for i,v in ipairs(sides) do
v.gold = 0
end

==== wesnoth.get_village_owner ====

* '''wesnoth.get_village_owner(''x'', ''y'')'''

Returns the side that owns the village at the given location.

local owned_by_side_1 = wesnoth.get_village_owner(12, 15) == 1

==== wesnoth.set_village_owner ====

* '''wesnoth.set_village_owner(''x'', ''y'', ''side'', [''fire_events''])'''

Gives ownership of the village at the given location to the given side (or remove ownership if none). Ownership is also removed if nil or 0 is passed for the third parameter, but no capture events are fired in this case.
An optional 4th parameter (boolean true|false, default: false) can be passed determining whether to fire any capture events.

wesnoth.set_village_owner(12, 15, 1)

==== wesnoth.is_enemy ====

* '''wesnoth.is_enemy(''side1'', ''side2'')'''

Returns true if side A is enemy of side B, false otherwise.

local enemy_flag = wesnoth.is_enemy(1, 3)

==== wesnoth.match_side ====

* '''wesnoth.match_side(''side'', ''filter'')'''

Matches a side against a given [[StandardSideFilter]].

wesnoth.message(tostring(wesnoth.match_side(1, {{"has_unit", { type = "Troll" }}})))

==== wesnoth.get_starting_location ====

* '''wesnoth.get_starting_location(''side'')'''

Returns the starting location of the given side.

local loc = wesnoth.get_starting_location(1)
wesnoth.message(string.format("side 1 starts at (%u, %u)", loc[1], loc[2]))

==== helper.all_teams ====

* '''helper.all_teams()'''

Returns an iterator over teams that can be used in a for-in loop.

for team in helper.all_teams() do team.gold = 200 end

[[Category: Lua Reference]]

Talk:TheDarkHordes

2012-10-07T21:27:23Z

Spixi: Created page with 'This article seems to be orphaned - it would be great to add a link to this article in this wiki anywhere. --~~~~'

This article seems to be orphaned - it would be great to add a link to this article in this wiki anywhere. --[[User:Spixi|Spixi]] 21:27, 7 October 2012 (UTC)

GermanTranslationErrors

2012-05-16T23:26:33Z

Spixi: /* Hilfe */

Hier bitte die in der Uebersetzung gefundenen Fehler eintragen.

== Generelles ==
Bitte entfernt doch die ganzen Deppenleerzeichen aus dem Spiel! Es ist kein Zwergen Kämpfer, sondern ein Zwergenkämpfer. Dies betrifft fast alle Einheiten, und einige andere Teile des Spiels.

-------------------------
Wesnoth 1.10.0

Ist es so richtig, dass auf der Landkarte von Wesnoth (die im Hauptmenü) das eine Gebirge "Erzgebierge" heißt?
Müsste es nicht "Erzgebirge" heißen?

Gruß Michieru

: "Erzgebirge" wäre "Ore Mountains" auf englisch.
: Im Original (en-US) heißt es jedoch "Heart Mountains".
: Die korrekte wörtliche Übersetzung müsste also "Herzgebirge" lauten.
: Die ensprechende Datei dazu ist:
: <pre>/data/core/images/maps/l10n/de/wesnoth--overlay.png</pre>

: Übrigens liest sich "Schwarzwasser Hafen" ein bisschen merkwürdig. Das klingt IMO so, als hätte es mal einen König "Schwarzwas" gegeben, der dort einen Hafen errichtet hat. Die Betonung liegt bei dieser Schreibweise auf "Haf-".

: Wenn man "Schwarzwasserhafen" ohne Leerzeichen schreiben würde, dann liegt die Betonung auf "Schwarz-". Dies ist sowohl einfacher zu lesen, als auch grammatikalisch korrekter.
: --[[User:Spixi|Spixi]] 21:07, 30 March 2012 (UTC)

==Einstellungen-Dialog==
Wesnoth 1.10.0

Allgemein -> "Planungsmodus bei Start aktivieren" [http://img1.bildupload.com/e70d2099c321144bc357ebc5c8c0728d.jpg]

Gruß Michieru

==Hilfe==
Beschreibung der Fähigkeit Heilen +4

Ist: "Angrenzende eigene oder verbündete Einheiten werden zu ihres Zuges geheilt."
Soll: "Angrenzende eigene oder verbündete Einheiten werden zu Beginn ihres Zuges geheilt."
Dieser Bug tritt nur bei Heilen +4 auf, der Text bei Teilen +8 ist richtig.
--[[User:Spixi|Spixi]] 23:26, 16 May 2012 (UTC)

==Einheitenbeschreibungen==

==Mehrspielerkarten==
Wesnoth 1.10.0

Kartenbeschreibungen

"Isars Kreuz" [http://img1.bildupload.com/9461bf044c3bc44ccd468510e673efba.jpg]

"Freies Land" [http://img1.bildupload.com/ac9ed4edaaa8457bf327f4d5e7dd1c93.jpg]

Gruß Michieru

==Einführung==

== Kampagnen ==

=== Das Zepter des Feuers ===

=== Die dunklen Künste ===

=== Die Geschichte zweier Brüder ===

=== Die Südwacht ===

=== Der Thronerbe ===

=== Der Aufstieg Wesnoths ===

=== Die Legende von Wesmere ===
Wesnoth 1.10.0

Beschreibung der Kampagne im Kampagnenmenü: [http://img1.bildupload.com/0a919dbd2fbe973bf8fb8bf8bb3c13b1.jpg]

Gruß Michieru

=== Ein Einmarsch der Orks ===

=== Freiheit ===
Mission "Ringen um Recht":

Fehler im Intro-Dialog von Maddock. Ein falsches "wären", siehe [http://imageshack.us/f/838/wesnothtranslation.png/ hier]

wären -> währen (im Sinne "Ehrlich währt am Längsten"). Gruß Crommy

=== Invasion der Finsternis ===

=== Schwarzauges Sohn ===

=== Unter brennenden Sonnen ===

=== Wiedergeburt des Nordens ===

=== Der Hammer von Thursagan ===

=== Delfadors Memoiren ===

=== Stille Wasser ===
Beim Durchspielen fiel mir im SKlavenhalterszenario folgendes auf:

Telöe ist im Bild ein Mann, Krellis spricht von einer "Meerjungfrau" also besser hier mit "Meermensch" übersetzen.

Im selben Dialog - Gwabbo "ihr habt eurem Volk aus der Seele gesprochen" besser "Ihr sprecht eurem Volk aus der Seele"

Im selben Dialog: Sprecher "hießen das Ultimatum willkommen" kommt irgednwie aus dem nichts - besser " akzeptierten das Unausweichliche und " usw.

Gruß Crommy

== Siehe auch ==

* [[GermanTranslation|Hauptseite für deutsche Übersetzung]]

[[Category:Translations]]

GermanTranslationErrors

2012-03-30T21:07:32Z

Spixi: /* Generelles */

Hier bitte die in der Uebersetzung gefundenen Fehler eintragen.

== Generelles ==
Bitte entfernt doch die ganzen Deppenleerzeichen aus dem Spiel! Es ist kein Zwergen Kämpfer, sondern ein Zwergenkämpfer. Dies betrifft fast alle Einheiten, und einige andere Teile des Spiels.

-------------------------
Wesnoth 1.10.0

Ist es so richtig, dass auf der Landkarte von Wesnoth (die im Hauptmenü) das eine Gebirge "Erzgebierge" heißt?
Müsste es nicht "Erzgebirge" heißen?

Gruß Michieru

: "Erzgebirge" wäre "Ore Mountains" auf englisch.
: Im Original (en-US) heißt es jedoch "Heart Mountains".
: Die korrekte wörtliche Übersetzung müsste also "Herzgebirge" lauten.
: Die ensprechende Datei dazu ist:
: <pre>/data/core/images/maps/l10n/de/wesnoth--overlay.png</pre>

: Übrigens liest sich "Schwarzwasser Hafen" ein bisschen merkwürdig. Das klingt IMO so, als hätte es mal einen König "Schwarzwas" gegeben, der dort einen Hafen errichtet hat. Die Betonung liegt bei dieser Schreibweise auf "Haf-".

: Wenn man "Schwarzwasserhafen" ohne Leerzeichen schreiben würde, dann liegt die Betonung auf "Schwarz-". Dies ist sowohl einfacher zu lesen, als auch grammatikalisch korrekter.
: --[[User:Spixi|Spixi]] 21:07, 30 March 2012 (UTC)

==Einstellungen-Dialog==
Wesnoth 1.10.0

Allgemein -> "Planungsmodus bei Start aktivieren" [http://img1.bildupload.com/e70d2099c321144bc357ebc5c8c0728d.jpg]

Gruß Michieru

==Hilfe==

==Einheitenbeschreibungen==

==Mehrspielerkarten==
Wesnoth 1.10.0

Kartenbeschreibungen

"Isars Kreuz" [http://img1.bildupload.com/9461bf044c3bc44ccd468510e673efba.jpg]

"Freies Land" [http://img1.bildupload.com/ac9ed4edaaa8457bf327f4d5e7dd1c93.jpg]

Gruß Michieru

==Einführung==

== Kampagnen ==

=== Das Zepter des Feuers ===

=== Die dunklen Künste ===

=== Die Geschichte zweier Brüder ===

=== Die Südwacht ===

=== Der Thronerbe ===

=== Der Aufstieg Wesnoths ===

=== Die Legende von Wesmere ===
Wesnoth 1.10.0

Beschreibung der Kampagne im Kampagnenmenü: [http://img1.bildupload.com/0a919dbd2fbe973bf8fb8bf8bb3c13b1.jpg]

Gruß Michieru

=== Ein Einmarsch der Orks ===

=== Freiheit ===
Mission "Ringen um Recht":

Fehler im Intro-Dialog von Maddock. Ein falsches "wären", siehe [http://imageshack.us/f/838/wesnothtranslation.png/ hier]

wären -> währen (im Sinne "Ehrlich währt am Längsten"). Gruß Crommy

=== Invasion der Finsternis ===

=== Schwarzauges Sohn ===

=== Unter brennenden Sonnen ===

=== Wiedergeburt des Nordens ===

=== Der Hammer von Thursagan ===

=== Delfadors Memoiren ===

=== Stille Wasser ===
Beim Durchspielen fiel mir im SKlavenhalterszenario folgendes auf:

Telöe ist im Bild ein Mann, Krellis spricht von einer "Meerjungfrau" also besser hier mit "Meermensch" übersetzen.

Im selben Dialog - Gwabbo "ihr habt eurem Volk aus der Seele gesprochen" besser "Ihr sprecht eurem Volk aus der Seele"

Im selben Dialog: Sprecher "hießen das Ultimatum willkommen" kommt irgednwie aus dem nichts - besser " akzeptierten das Unausweichliche und " usw.

Gruß Crommy

== Siehe auch ==

* [[GermanTranslation|Hauptseite für deutsche Übersetzung]]

[[Category:Translations]]

SpellingMistakes

2012-03-30T18:44:31Z

Spixi: Titel screen: German overlay

This page is meant to be a list of spelling mistakes in campaigns and other translatable texts in the en_US development version of the game.

Note: The house style of Wesnoth uses a good many words and constructions that are archaic, poetic, or dialectal. If you speak modern English as a second language you may incorrectly read these as errors. Please see [[NotSpellingMistakes]] for a list of things you will encounter that may look like spelling or usage errors but are not. Note that the mainline campaigns are now using correct typography, including sexed quotes and en and em dashes. These will appear as three byte sequences if you are not using a viewer that supports UTF-8.

==Mainline Campaigns==

===An Orcish Incursion===

===Dead Water===

===Delfador’s Memoirs===

===Descent into Darkness===

===Eastern Invasion===

===Heir to the Throne===

===Liberty===

===Northern Rebirth===

===Sceptre of Fire===

===Son of the Black Eye===

===The Hammer of Thursagan===

===The Legend of Wesmere===

===The Rise of Wesnoth===

===The South Guard===

===Two Brothers===

===Under the Burning Suns===

S6a, line 685 in the .cfg: seems to be missing a verb: ''"[...] but I will '''''???''''' once you finish your mission."'' Maybe "return"?

==Wesnoth Game==

===Editor===

===Help===

===Tutorial===

===Manual===

===Manpages===

===Units===

===1.10 Announcement===

===Other (unit descriptions, ...)===
src/tools/validator/validator_tool.cpp:46 an extra ] appearing in the help of the schema validator tool (<tt>schema_validator -h</tt>):
usage: ./schema_validator [-hV] [-s <schema_file>] ]
The line 46 should be:
<< " [-hV] [-i <input_file>] [-s <schema_file>]\n"

====Title screen overlay: /data/core/images/maps/l10n/de/wesnoth--overlay.png====
In the German map overlay "Heart Mountains" is translated with "Erzgebierge".
* As a native German speaker I know that "Gebirge" is spelled with a single "i", not with an "ie".
* Translated literally "Erzgebirge" means "Ore Mountains".
* However I feel that the correct translation must be "Herzgebirge", since "Herz" is the German word for "heart".

===Multiplayer maps===

===Translation code bugs===

==Unofficial campaigns==

===Invasion from the Unknown===