The Battle for Wesnoth Wiki - User contributions [en]

ReplayWML

2025-05-04T21:12:55Z

Dwarftough: fix replace_map name and adding a link to it

{{WML Tags}}
== The [command] tag ==

The '''[command]''' tag is used to specify an action in a replay. It has the following attributes:

* '''dependent''' if true, this command is not a lone-standing command and instead belongs to an earlier command, for example an advancement choice for an earlier attack command which issued an advancement.
* '''from_side''' the side which issued the command. Only present for dependent commands.
* '''sent''' used internally in networked mp, to know which commands were already sent to the other clients.
The following tags are recognized for dependent=no(default):
* {{anchor|start|'''[start]'''}}: is used to initialize the replay so that generated random numbers can be saved.
* {{anchor|move|'''[move]'''}}: the player moved a unit.
** '''x,y''': the path the unit walks.
** '''skip_sighted''': whether the unit doesn't stop when discovering another unit, possible values are 'only_ally', 'all' or no, (default no).
* {{anchor|recruit|'''[recruit]'''}}: the player recruited a unit.
** '''type''': the id of the type of unit recruited.
** '''x''' and '''y''': the castle tile the unit is recruited on.
** '''[from]'''
*** '''x''' and '''y''': the keep tile the unit is recruited from.
* {{anchor|recall|'''[recall]'''}}: the player recalled a unit. Same keys as [recruit], except that '''value''' is the id of the unit being recalled.
* {{anchor|attack|'''[attack]'''}}: the player attacked.
** '''weapon''': the index number of the weapon. Weapons are indexed by the unit designer.
** '''defender_weapon''': the index number of the defenders weapon. Weapons are indexed by the unit designer, '-1' to choose the best weapon locally. The '-1' option is deprecated because it can cause OOS.
** '''[source]''': the location of the attacking unit.
** '''[destination]''': the location of the defending unit.
* {{anchor|disband|'''[disband]'''}}: the player removes a unit from his recall list.
** '''value''' the id of the removed unit.
* {{anchor|end_turn|'''[end_turn]'''}}: the player ended his turn.
* {{anchor|init_side|'''[init_side]'''}}: new turn is starting for a side. This fires begin of turn events.
* {{anchor|fire_event|'''[fire_event]'''}}: a specific event was raised. This is mainly used for right-click menu items. ([set_menu_item])
** '''raise''': the name of the event
** '''[source]''': the location of the event
** '''[set_variable]''' (deprecated): set WML variable(s) before firing.
*** '''name''': the name of the variable
*** '''value''': a string value (literal)
* {{anchor|lua_ai|'''[lua_ai]'''}}: {{DevFeature1.13|12}} This has been removed.
** '''code''' the lua code that is executed.
* {{anchor|custom_command|'''[custom_command]'''}}: {{DevFeature1.13|12}} Executes a custom command registered by Lua code
** '''name''': The name of the custom command to run.
** '''[data]''': Arbitrary data to be passed to the custom command.
* {{anchor|auto_shroud|'''[auto_shroud]'''}}: a player toggled delayed shroud update
** '''active''' whether automatic shroud updates will be active.
* {{anchor|update_shroud|'''[update_shroud]'''}}: a player manually updated shroud.

Non dependent commands can have a [checkup] tag which is used to check whether the data generated in the replay matches the data generated during the original game, The [checkup] tag can contain different [result] tags whose content is different for the different actions.
For [attack] commands the [result]s give information about the single hits and can have the following attributes:
** '''chance''': the percent chance that the attack had to hit.
** '''damage''': the amount of damage that the attack would do if it hits.
** '''hits''': whether the attack hits.
** '''dies''': whether the defender dies from the hit.

The following tags are recognized for dependent=true:
* {{anchor|choose|'''[choose]'''}}: the player was given an option by the scenario or for an advancement path.
** '''value''': the index number of the option chosen. Index numbers are given by the scenario designer.
* {{anchor|input|'''[input]'''}}: if a lua code used [[LuaWML:Misc#wesnoth.synchronize_choice]] this tag contains the returned table.
* {{anchor|global_variable|'''[global_variable]'''}}: a WML code used with [get_global_variable]
* {{anchor|random_seed|'''[random_seed]'''}}: a user's actions use the rng and thus a new random seed is needed.
* {{anchor|map_data|'''[map_data]'''}}: contains the map data read from the file when [[DirectActionsWML#.5Breplace_map.5D|'''[replace_map]''']] with the '''map_file=''' argument was invoked.

== See Also ==
* [[SavefileWML]]
* [[ReferenceWML]]

[[Category: WML Reference]]

Template:WML Tags

2025-05-02T14:31:50Z

Dwarftough: Add info about [map_data] tag in replays

{| class="reference-sidebar"
|-
|
<span class="editlink">[[{{SERVER}}{{localurl:Template:WML Tags|action=edit}} edit]]</span>'''[[ReferenceWML|WML Tags]]'''
|-
|''A:''
[[AbilitiesWML#The .5Babilities.5D tag|abilities]],
[[CreditsWML#.5Babout.5D|about]],
[[AchievementsWML#.5Bachievement.5D|achievement]],
[[AchievementsWML#.5Bachievement_group.5D|achievement_group]],
[[Lua_AI_Legacy_Methods_Howto#Behavior_.28Sticky.29_Candidate_Actions|add_ai_behavior]],
[[AdvancedPreferenceWML|advanced_preference]],
[[UnitTypeWML#advancefrom|advancefrom]],
[[UnitTypeWML#After_max_level_advancement_.28AMLA.29|advancement]],
[[StatisticalScenarioWML#The_.5Bteam.5D_tag|advances]],
[[AbilitiesWML#affect_adjacent|affect_adjacent]],
[[Wesnoth_AI_Framework#The_.5Bai.5D_Tag_.E2.80.94_Top-level_Elements|ai]],
[[StandardSideFilter#allied_with|allied_with]],
[[DirectActionsWML#.5Ballow_end_turn.5D|allow_end_turn]],
[[DirectActionsWML#.5Ballow_extra_recruit.5D|allow_extra_recruit]],
[[DirectActionsWML#.5Ballow_recruit.5D|allow_recruit]],
[[DirectActionsWML#.5Ballow_undo.5D|allow_undo]],
[[ConditionalActionsWML#Meta-Condition_Tags|and]],
[[InterfaceActionsWML#.5Banimate_unit.5D|animate]],
[[InterfaceActionsWML#.5Banimate_unit.5D|animate_unit]],
[[AnimationWML#The .5Banimation.5D tag|animation]],
[[Wesnoth_AI_Framework#The_.5Bai.5D_Tag_.E2.80.94_Aspects|aspect]],
attack ([[ReplayWML#attack|replay]], [[UnitTypeWML#Attacks|weapon]]),
[[AnimationWML#short-attack|attack_anim]],
attacks ([[AbilitiesWML#The_.5Bspecials.5D_tag|special]], [[StatisticalScenarioWML#The_.5Bteam.5D_tag|stats]]),
[[AiWML#avoid|avoid]];
|-
|''B:''
[[UnitTypeWML#base_unit|base_unit]],
[[IntroWML#.5Bbackground_layer.5D|background_layer]],
[[AbilitiesWML#The_.5Bspecials.5D_tag|berserk]],
[[BinaryPathWML|binary_path]],
[[InternalActionsWML#Flow_control_actions|break]],
[[EditorWML#The_.5Bbrush.5D_tag|brush]];
|-
|''C:''
[[CampaignWML#The_.5Bcampaign.5D_tag|campaign]],
[[DirectActionsWML#.5Bcancel_action.5D|cancel_action]],
[[Wesnoth_AI_Framework#The_.5Bcandidate_action.5D_Tag|candidate_action]],
[[DirectActionsWML#.5Bcapture_village.5D|capture_village]],
[[ConditionalActionsWML#.5Bswitch.5D|case]],
[[AbilitiesWML#The_.5Bspecials.5D_tag|chance_to_hit]],
[[InterfaceActionsWML#.5Bchange_theme.5D|change_theme]],
[[InterfaceActionsWML#.5Bchat.5D|chat]],
[[OptionWML#checkbox|checkbox]],
[[OptionWML#choice|choice]],
[[ReplayWML#choose|choose]],
[[PersistenceWML#WML Syntax|clear_global_variable]],
[[InterfaceActionsWML#.5Bclear_menu_item.5D|clear_menu_item]],
[[InternalActionsWML#.5Bclear_variable.5D|clear_variable]],
[[InterfaceActionsWML#.5Bcolor_adjust.5D|color_adjust]],
[[GameConfigWML#Color_Palettes|color_palette]],
[[GameConfigWML#Color_Palettes|color_range]],
command ([[ConditionalActionsWML#.5Bcommand.5D|action]], [[ReplayWML|replay]]),
[[InternalActionsWML#Flow_control_actions|continue]],
[[CoreWML|core]],
[[CreditsWML#.5Bcredits_group.5D|credits_group]],
[[AiWML#The_.5Bgoal.5D_Tag|criteria]];
|-
|''D:''
[[AbilitiesWML#The_.5Bspecials.5D_tag|damage]],
[[AbilitiesWML#The_.5Bspecials.5D_tag|damage_type]],
[[AnimationWML#short-death|death]],
[[StatisticalScenarioWML#The_.5Bteam.5D_tag|deaths]],
[[Wesnoth_AI_Framework#The_.5Bai.5D_Tag_.E2.80.94_Aspects|default]],
[[AnimationWML#short-defend|defend]],
[[StatisticalScenarioWML#The_.5Bteam.5D_tag|defends]],
[[UnitsWML#defense|defense]],
[[InterfaceActionsWML#.5Bdelay.5D|delay]],
[[InterfaceActionsWML#.5Bdeprecated_message.5D|deprecated_message]],
[[ReplayWML#attack|destination]],
[[CampaignWML#difficulty|difficulty]],
[[AbilitiesWML#The_.5Bspecials.5D_tag|disable]],
[[DirectActionsWML#.5Bdisallow_end_turn.5D|disallow_end_turn]],
[[DirectActionsWML#.5Bdisallow_extra_recruit.5D|disallow_extra_recruit]],
[[DirectActionsWML#.5Bdisallow_recruit.5D|disallow_recruit]],
[[ConditionalActionsWML#.5Bwhile.5D|do]],
[[DirectActionsWML#.5Bdo_command.5D|do_command]],
[[AbilitiesWML#The_.5Bspecials.5D_tag|drains]],
[[AnimationWML#short-draw_weapon|draw_weapon_anim]];
|-
|''E:''
[[EditorWML#The_.5Beditor_group.5D_tag|editor_group]],
[[EditorWML#The_.5Beditor_music.5D_tag|editor_music]],
[[EditorWML#The_.5Beditor_times.5D_tag|editor_times]],
[[EffectWML|effect]],
else ([[ConditionalActionsWML#.5Bif.5D|action]], [[AnimationWML#Conditional Branches|animation]]), [[ConditionalActionsWML#.5Bif.5D|elseif]],
[[DirectActionsWML#.5Bendlevel.5D|endlevel]],
end_turn ([[DirectActionsWML#.5Bend_turn.5D|action]], [[ReplayWML#end_turn|replay]]),
[[StandardSideFilter#enemy_of|enemy_of]],
[[Wesnoth_AI_Framework#The_.5Bai.5D_Tag_.E2.80.94_Engines|engine]],
entry ([[CreditsWML#.5Bentry.5D|credits]], [[OptionWML#entry|options]]),
[[EraWML|era]],
[[EventWML|event]],
[[StandardUnitFilter#filter_ability|experimental_filter_ability]],
[[StandardUnitFilter#filter_ability_active|experimental_filter_ability_active]],
[[AbilitiesWML#filter_specials|experimental_filter_specials]],
[[AnimationWML#short-extra|extra_anim]];
|-
|''F:''
[[Wesnoth_AI_Framework#The_.5Bai.5D_Tag_.E2.80.94_Aspects|facet]],
[[InterfaceActionsWML#.5Banimate_unit.5D|facing]],
[[InterfaceActionsWML#.5Bmove_units_fake.5D|fake_unit]],
[[ConditionalActionsWML#.5Bfalse.5D|false]],
[[PblWML#.5Bfeedback.5D|feedback]],
[[UnitTypeWML#variation|female]],
filter ([[FilterWML|concept]], [[EventWML#.5Bfilter.5D|event]]),
[[StandardUnitFilter#filter_adjacent|filter_adjacent]],
[[StandardLocationFilter#filter_adjacent_location|filter_adjacent_location]],
[[FilterWML#Filtering_Weapons|filter_attack]],
[[AbilitiesWML#filter_attacker|filter_attacker]],
[[AbilitiesWML#filter_base_value|filter_base_value]],
[[EventWML#.5Bfilter_condition.5D|filter_condition]],
[[AbilitiesWML#filter_defender|filter_defender]],
[[AiWML#Filtering_Combat_with_the_attacks_Aspect|filter_enemy]],
[[StandardLocationFilter|filter_location]],
[[AbilitiesWML#filter_opponent|filter_opponent]],
[[AiWML#Filtering_Combat_with_the_attacks_Aspect|filter_own]],
[[StandardLocationFilter#filter_owner|filter_owner]],
[[StandardLocationFilter#filter_radius|filter_radius]],
[[SingleUnitWML#filter_recall|filter_recall]],
[[StandardUnitFilter|filter_second]],
[[FilterWML#Filtering_Weapons|filter_second_attack]],
[[AbilitiesWML#filter_self|filter_self]],
[[StandardSideFilter|filter_side]],
[[AbilitiesWML#filter_student|filter_student]],
[[FilterWML#Filtering_Vision|filter_vision]],
[[FilterWML#Filtering_Weapons|filter_weapon]],
[[FilterWML#Filtering_on_WML_data|filter_wml]],
[[InternalActionsWML#.5Bfind_path.5D|find_path]],
[[InternalActionsWML#.5Bfire_event.5D|fire_event]],
[[AbilitiesWML#The_.5Bspecials.5D_tag|firststrike]],
[[InterfaceActionsWML#.5Bfloating_text.5D|floating_text]],
[[FontsWML|fonts]],
[[ConditionalActionsWML#.5Bfor.5D|for]],
[[ConditionalActionsWML#.5Bforeach.5D|foreach]],
[[ConditionalActionsWML#.5Bfound_item.5D|found_item]],
[[AnimationWML#The .5Bframe.5D tag|frame]];
|-
|''G:''
[[GameConfigWML|game_config]],
[[PersistenceWML#WML Syntax|get_global_variable]],
[[AiWML#The_.5Bgoal.5D_Tag|goal]],
[[DirectActionsWML#.5Bgold.5D|gold]],
[[InterfaceActionsWML#objectives-gold_carryover|gold_carryover]];
|-
|''H:''
[[DirectActionsWML#.5Bharm_unit.5D|harm_unit]],
[[StandardSideFilter#has_ally|has_ally]],
[[StandardUnitFilter#has_attack|has_attack]],
[[StandardSideFilter#has_unit|has_unit]],
[[ConditionalActionsWML#.5Bhas_achievement.5D|has_achievement]],
[[ConditionalActionsWML#.5Bhave_location.5D|have_location]],
[[ConditionalActionsWML#.5Bhave_side.5D|have_side]],
[[ConditionalActionsWML#.5Bhave_unit.5D|have_unit]],
[[AbilitiesWML#The_.5Bspecials.5D_tag|heal_on_hit]],
[[DirectActionsWML#.5Bheal_unit.5D|heal_unit]],
[[AnimationWML#short-healed|healed_anim]],
[[AnimationWML#short-healing|healing_anim]],
[[AbilitiesWML#The_.5Babilities.5D_tag|heals]],
[[UnitsWML#.5Bhide_help.5D|hide_help]],
[[InterfaceActionsWML#.5Bhide_unit.5D|hide_unit]],
[[AbilitiesWML#The_.5Babilities.5D_tag|hides]];
|-
|''I:''
[[AnimationWML#short-idle|idle_anim]],
if ([[ConditionalActionsWML#.5Bif.5D|action]], [[AnimationWML#Conditional Branches|animation]], [[IntroWML|intro]]),
[[AbilitiesWML#The_.5Babilities.5D_tag|illuminates]],
image ([[IntroWML#.5Bimage.5D|intro]], [[TerrainGraphicsWML#The_.5Bimage.5D_subtag|terrain]]),
[[ReplayWML#init_side|init_side]],
[[VariablesWML#.5Binsert_tag.5D|insert_tag]],
[[InterfaceActionsWML#.5Binspect.5D|inspect]],
[[InterfaceActionsWML#.5Bitem.5D|item]],
[[EditorWML#The_.5Bitem_group.5D_tag|item_group]];
|-
|''J:''
[[UnitsWML#jamming_costs|jamming_costs]],
[[InternalActionsWML#join|join]];
|-
|''K:''
[[DirectActionsWML#.5Bkill.5D|kill]],
[[StatisticalScenarioWML#The_.5Bteam.5D_tag|killed]];
|-
|''L:''
[[InterfaceActionsWML#.5Blabel.5D|label]],
[[LanguageWML|language]],
[[SideWML#leader|leader]],
[[AiWML#leader_goal|leader_goal]],
[[AbilitiesWML#The_.5Babilities.5D_tag|leadership]],
[[AnimationWML#short-leading|leading_anim]],
[[AnimationWML#short-levelin|levelin_anim]],
[[AnimationWML#short-levelout|levelout_anim]],
[[DirectActionsWML#.5Blift_fog.5D|lift_fog]],
[[AI_Recruitment#instructions-limit|limit]],
[[InternalActionsWML#set_variables-literal|literal]],
[[AddonsWML#load_resource|load_resource]],
[[LocaleWML|locale]],
[[InterfaceActionsWML#.5Block_view.5D|lock_view]],
[[LuaWML|lua]];
|-
|''M:''
[[UnitTypeWML#variation|male]],
[[ReplayWML#map_data|map_data]],
[[SavefileWML|menu_item]],
[[InterfaceActionsWML#.5Bmessage.5D|message]],
[[Micro AIs|micro_ai]],
[[AnimationWML#The .5Bframe.5D tag|missile_frame]],
[[ModificationWML|modification]],
[[SingleUnitWML#modifications|modifications]],
[[DirectActionsWML#.5Bmodify_ai.5D|modify_ai]],
[[DirectActionsWML#.5Bmodify_side.5D|modify_side]],
[[DirectActionsWML#.5Bmodify_turns.5D|modify_turns]],
[[DirectActionsWML#.5Bmodify_unit.5D|modify_unit]],
[[AddonsWML#modify_unit_type|modify_unit_type]],
[[ReplayWML#move|move]],
[[DirectActionsWML#.5Bmove_unit.5D|move_unit]],
[[InterfaceActionsWML#.5Bmove_unit_fake.5D|move_unit_fake]],
[[InterfaceActionsWML#.5Bmove_units_fake.5D|move_units_fake]],
[[AnimationWML#short-movement|movement_anim]],
[[UnitsWML#movement_costs|movement costs]],
[[UnitsWML#.5Bmovetype.5D|movetype]],
[[ScenarioWML#The_.5Bmultiplayer.5D_tag|multiplayer]],
[[EraWML#Defining_Factions|multiplayer_side]],
[[MusicListWML#.5Bmusic.5D|music]];
|-
|''N:''
[[ConditionalActionsWML#Meta-Condition_Tags|not]],
[[InterfaceActionsWML#objectives-note|note]];
|-
|''O:''
[[DirectActionsWML#.5Bobject.5D|object]],
[[InterfaceActionsWML#objectives-objective|objective]],
[[InterfaceActionsWML#.5Bobjectives.5D|objectives]],
[[DirectActionsWML#.5Bon_undo.5D|on_undo]],
[[InterfaceActionsWML#.5Bopen_help.5D|open_help]],
[[InterfaceActionsWML#.5Bmessage.5D|option]],
[[OptionWML|options]],
[[ConditionalActionsWML#Meta-Condition_Tags|or]];
|-
|''P:''
[[IntroWML#.5Bpart.5D|part]],
[[AbilitiesWML#The_.5Bspecials.5D_tag|petrifies]],
[[DirectActionsWML#.5Bpetrify.5D|petrify]],
[[DirectActionsWML#.5Bplace_shroud.5D|place_shroud]],
[[AbilitiesWML#The_.5Bspecials.5D_tag|plague]],
[[AbilitiesWML#The_.5Bspecials.5D_tag|poison]],
[[AnimationWML#short-post_movement|post_movement_anim]],
[[AnimationWML#short-pre_movement|pre_movement_anim]],
[[InternalActionsWML#.5Bfire_event.5D|primary_attack]],
[[InternalActionsWML#.5Bfire_event.5D|primary_unit]],
[[InterfaceActionsWML#.5Bprint.5D|print]],
[[DirectActionsWML#.5Bprogress_achievement.5D|progress_achievement]],
[[DirectActionsWML#.5Bput_to_recall_list.5D|put_to_recall_list]];
|-
|''R:''
[[UnitsWML#.5Brace.5D|race]],
[[InternalActionsWML#.5Brandom_placement.5D|random_placement]],
recall ([[DirectActionsWML#.5Brecall.5D|action]], [[ReplayWML#recall|replay]]),
[[StatisticalScenarioWML#The_.5Bteam.5D_tag|recalls]],
[[ReplayWML#recruit|recruit]],
[[AnimationWML#short-recruit|recruit_anim]],
[[AnimationWML#short-recruiting|recruiting_anim]],
[[StatisticalScenarioWML#The_.5Bteam.5D_tag|recruits]],
[[InterfaceActionsWML#.5Bredraw.5D|redraw]],
[[AbilitiesWML#The_.5Babilities.5D_tag|regenerate]],
[[InternalActionsWML#.5Bremove_event.5D|remove_event]],
[[InterfaceActionsWML#.5Bremove_item.5D|remove_item]],
[[DirectActionsWML#.5Bremove_object.5D|remove_object]],
[[DirectActionsWML#.5Bremove_shroud.5D|remove_shroud]],
[[InterfaceActionsWML#.5Bremove_sound_source.5D|remove_sound_source]],
[[DirectActionsWML#.5Bremove_time_area.5D|remove_time_area]],
[[DirectActionsWML#.5Bremove_trait.5D|remove_trait]],
[[InterfaceActionsWML#.5Bremove_unit_overlay.5D|remove_unit_overlay]],
[[ConditionalActionsWML#.5Brepeat.5D|repeat]],
[[DirectActionsWML#.5Breplace_map.5D|replace_map]],
[[DirectActionsWML#.5Breplace_schedule.5D|replace_schedule]],
[[ReplayWML|replay]],
[[SavefileWML|replay_start]],
[[DirectActionsWML#.5Breset_fog.5D|reset_fog]],
resistance ([[AbilitiesWML#The_.5Babilities.5D_tag|ability]], [[UnitsWML#resistance|unit]]),
[[UnitsWML#.5Bresistance_defaults.5D|resistance_defaults]],
[[ThemeWML#The_toplevel_.5Btheme.5D_tag|resolution]],
[[ModificationWML#The_.5Bresource.5D_toplevel_tag|resource]],
[[InternalActionsWML#Flow_control_actions|return]],
[[InternalActionsWML#.5Brole.5D|role]],
[[TerrainMaskWML#rule|rule]];
|-
|''S:''
[[SavefileWML|save]],
[[ScenarioWML#The_.5Bscenario.5D_tag|scenario]],
[[InterfaceActionsWML#.5Bscreen_fade.5D|screen_fade]],
[[InterfaceActionsWML#.5Bscroll.5D|scroll]],
[[InterfaceActionsWML#.5Bscroll_to.5D|scroll_to]],
[[InterfaceActionsWML#.5Bscroll_to_unit.5D|scroll_to_unit]],
[[InternalActionsWML#.5Bfire_event.5D|secondary_attack]],
[[InternalActionsWML#.5Bfire_event.5D|secondary_unit]],
[[HelpWML#section|section]],
[[InterfaceActionsWML#.5Bselect_unit.5D|select_unit]],
[[ReplayWML#sequence|sequence]],
[[DirectActionsWML#.5Bset_achievement.5D|set_achievement]],
[[DirectActionsWML#.5Bset_extra_recruit.5D|set_extra_recruit]],
[[PersistenceWML#WML_Syntax|set_global_variable]],
[[InterfaceActionsWML#.5Bset_menu_item.5D|set_menu_item]],
[[DirectActionsWML#.5Bset_recruit.5D|set_recruit]],
[[EffectWML#set_specials|set_specials]],
[[InternalActionsWML#.5Bset_variable.5D|set_variable]],
[[InternalActionsWML#.5Bset_variables.5D|set_variables]],
[[AnimationWML#short-sheath_weapon|sheath_weapon_anim]],
show_if ([[InterfaceActionsWML#.5Bmessage.5D|message]],
[[InterfaceActionsWML#.5Bobjectives.5D|objective]],
[[InterfaceActionsWML#.5Bset_menu_item.5D|set_menu_item]]),
[[InterfaceActionsWML#.5Bshow_objectives.5D|show_objectives]],
[[SideWML|side]],
[[AbilitiesWML#The_.5Babilities.5D_tag|skirmisher]],
[[OptionWML#slider|slider]],
[[AbilitiesWML#The_.5Bspecials.5D_tag|slow]],
[[SavefileWML|snapshot]],
[[InterfaceActionsWML#.5Bsound.5D|sound]],
[[InterfaceActionsWML#.5Bsound_source.5D|sound_source]],
source ([[ReplayWML#attack|replay]], [[DirectActionsWML#.5Btunnel.5D|teleport]]),
[[UnitTypeWML#Special Notes|special_note]],
[[AbilitiesWML#The_.5Bspecials.5D_tag|specials]],
[[InternalActionsWML#set_variables-split|split]],
[[Wesnoth_AI_Framework#The_.5Bai.5D_Tag_.E2.80.94_Stages|stage]],
[[AnimationWML#short-standing|standing_anim]],
[[StatisticalScenarioWML#The_.5Bstatistics.5D_tag|statistics]],
[[SingleUnitWML#status|status]],
[[InternalActionsWML#.5Bstore_gold.5D|store_gold]],
[[InternalActionsWML#.5Bstore_items.5D|store_items]],
[[InternalActionsWML#.5Bstore_locations.5D|store_locations]],
[[InternalActionsWML#.5Bstore_map_dimensions.5D|store_map_dimensions]],
[[InternalActionsWML#.5Bstore_reachable_locations.5D|store_reachable_locations]],
[[InternalActionsWML#.5Bstore_relative_direction.5D|store_relative_direction]],
[[InternalActionsWML#.5Bstore_side.5D|store_side]],
[[InternalActionsWML#.5Bstore_starting_location.5D|store_starting_location]],
[[InternalActionsWML#.5Bstore_time_of_day.5D|store_time_of_day]],
[[InternalActionsWML#.5Bstore_turns.5D|store_turns]],
[[InternalActionsWML#.5Bstore_unit.5D|store_unit]],
[[InternalActionsWML#.5Bstore_unit_defense.5D|store_unit_defense]],
[[InternalActionsWML#.5Bstore_unit_defense_on.5D|store_unit_defense_on]],
[[InternalActionsWML#.5Bstore_unit_type.5D|store_unit_type]],
[[InternalActionsWML#.5Bstore_unit_type_ids.5D|store_unit_type_ids]],
[[InternalActionsWML#.5Bstore_villages.5D|store_villages]],
[[IntroWML|story]],
[[AbilitiesWML#The_.5Bspecials.5D_tag|swarm]],
[[AchievementsWML#.5Bsub_achievement.5D|sub_achievement]],
[[ConditionalActionsWML#.5Bswitch.5D|switch]],
[[InternalActionsWML#.5Bsync_variable.5D|sync_variable]];
|-
|''T:''
[[DirectActionsWML#.5Btunnel.5D|target]],
[[StatisticalScenarioWML#The_.5Bteam.5D_tag|team]],
teleport ([[AbilitiesWML#Extra_tags_used_by_the_.5Bteleport.5D_ability|ability]], [[DirectActionsWML#.5Bteleport.5D|action]]),
[[AnimationWML#short-teleport|teleport_anim]],
[[DirectActionsWML#.5Bterrain.5D|terrain]],
[[UnitsWML#.5Bterrain_defaults.5D|terrain_defaults]],
[[TerrainGraphicsWML|terrain_graphics]],
[[TerrainMaskWML|terrain_mask]],
[[TerrainWML|terrain_type]],
[[ScenarioWML#The_.5Btest.5D_tag|test]],
[[InterfaceActionsWML#.5Btest_condition.5D|test_condition]],
[[TestWML#The_.5Btest_do_attack_by_id.5D_tag|test_do_attack_by_id]],
[[InterfaceActionsWML#message-text_input|text_input]],
[[GettextForWesnothDevelopers#The_textdomain_tag|textdomain]],
[[ThemeWML|theme]],
[[ConditionalActionsWML#.5Bif.5D|then]],
[[TerrainGraphicsWML#The_.5Btile.5D_subtag|tile]],
[[TimeWML|time]],
[[DirectActionsWML#.5Btime_area.5D|time_area]],
[[HelpWML#topic|topic]],
[[HelpWML#toplevel|toplevel]],
[[UnitsWML#.5Btrait.5D|trait]],
[[DirectActionsWML#.5Btransform_unit.5D|transform_unit]],
[[InternalActionsWML#.5Bfind_path.5D|traveler]],
[[ConditionalActionsWML#.5Btrue.5D|true]],
[[DirectActionsWML#.5Btunnel.5D|tunnel]];
|-
|''U:''
[[InterfaceActionsWML#.5Bunhide_unit.5D|unhide_unit]],
unit ([[DirectActionsWML#.5Bunit.5D|action]], [[SingleUnitWML|scenario]]),
[[InterfaceActionsWML#.5Bunit_overlay.5D|unit_overlay]],
[[UnitTypeWML|unit_type]],
[[InternalActionsWML#.5Bunit_worth.5D|unit_worth]],
[[UnitsWML|units]],
[[InterfaceActionsWML#.5Bunlock_view.5D|unlock_view]],
[[DirectActionsWML#.5Bunpetrify.5D|unpetrify]],
[[DirectActionsWML#.5Bunstore_unit.5D|unstore_unit]],
[[InternalActionsWML#.5Bunsynced.5D|unsynced]];
|-
| ''V:''
[[InternalActionsWML#set_variables-value|value]],
[[ConditionalActionsWML#.5Bvariable.5D|variable]],
[[VariablesWML#The_.5Bvariables.5D_tag|variables]],
[[TerrainGraphicsWML#variant|variant]],
[[UnitTypeWML#variation|variation]],
[[AnimationWML#short-victory|victory_anim]],
[[SideWML#village|village]],
[[UnitsWML#vision_costs|vision_costs]],
[[InterfaceActionsWML#.5Bvolume.5D|volume]];
|-
| ''W:''
[[ConditionalActionsWML#.5Bwhile.5D|while]],
[[InterfaceActionsWML#.5Bwml_message.5D|wml_message]],
[[SchemaWML|wml_schema]];
|-
| ''Z:''
[[InterfaceActionsWML#.5Bzoom.5D|zoom]];
|}<includeonly>[[Category:WML Reference]]</includeonly><noinclude>A box with all the WML tags, each one linking to the page and section they are described in. This box should be included in each of the [[ReferenceWML|WML reference]] pages.</noinclude>

ReplayWML

2025-05-02T14:30:58Z

Dwarftough: Add info about [map_data] tag in replays

{{WML Tags}}
== The [command] tag ==

The '''[command]''' tag is used to specify an action in a replay. It has the following attributes:

* '''dependent''' if true, this command is not a lone-standing command and instead belongs to an earlier command, for example an advancement choice for an earlier attack command which issued an advancement.
* '''from_side''' the side which issued the command. Only present for dependent commands.
* '''sent''' used internally in networked mp, to know which commands were already sent to the other clients.
The following tags are recognized for dependent=no(default):
* {{anchor|start|'''[start]'''}}: is used to initialize the replay so that generated random numbers can be saved.
* {{anchor|move|'''[move]'''}}: the player moved a unit.
** '''x,y''': the path the unit walks.
** '''skip_sighted''': whether the unit doesn't stop when discovering another unit, possible values are 'only_ally', 'all' or no, (default no).
* {{anchor|recruit|'''[recruit]'''}}: the player recruited a unit.
** '''type''': the id of the type of unit recruited.
** '''x''' and '''y''': the castle tile the unit is recruited on.
** '''[from]'''
*** '''x''' and '''y''': the keep tile the unit is recruited from.
* {{anchor|recall|'''[recall]'''}}: the player recalled a unit. Same keys as [recruit], except that '''value''' is the id of the unit being recalled.
* {{anchor|attack|'''[attack]'''}}: the player attacked.
** '''weapon''': the index number of the weapon. Weapons are indexed by the unit designer.
** '''defender_weapon''': the index number of the defenders weapon. Weapons are indexed by the unit designer, '-1' to choose the best weapon locally. The '-1' option is deprecated because it can cause OOS.
** '''[source]''': the location of the attacking unit.
** '''[destination]''': the location of the defending unit.
* {{anchor|disband|'''[disband]'''}}: the player removes a unit from his recall list.
** '''value''' the id of the removed unit.
* {{anchor|end_turn|'''[end_turn]'''}}: the player ended his turn.
* {{anchor|init_side|'''[init_side]'''}}: new turn is starting for a side. This fires begin of turn events.
* {{anchor|fire_event|'''[fire_event]'''}}: a specific event was raised. This is mainly used for right-click menu items. ([set_menu_item])
** '''raise''': the name of the event
** '''[source]''': the location of the event
** '''[set_variable]''' (deprecated): set WML variable(s) before firing.
*** '''name''': the name of the variable
*** '''value''': a string value (literal)
* {{anchor|lua_ai|'''[lua_ai]'''}}: {{DevFeature1.13|12}} This has been removed.
** '''code''' the lua code that is executed.
* {{anchor|custom_command|'''[custom_command]'''}}: {{DevFeature1.13|12}} Executes a custom command registered by Lua code
** '''name''': The name of the custom command to run.
** '''[data]''': Arbitrary data to be passed to the custom command.
* {{anchor|auto_shroud|'''[auto_shroud]'''}}: a player toggled delayed shroud update
** '''active''' whether automatic shroud updates will be active.
* {{anchor|update_shroud|'''[update_shroud]'''}}: a player manually updated shroud.

Non dependent commands can have a [checkup] tag which is used to check whether the data generated in the replay matches the data generated during the original game, The [checkup] tag can contain different [result] tags whose content is different for the different actions.
For [attack] commands the [result]s give information about the single hits and can have the following attributes:
** '''chance''': the percent chance that the attack had to hit.
** '''damage''': the amount of damage that the attack would do if it hits.
** '''hits''': whether the attack hits.
** '''dies''': whether the defender dies from the hit.

The following tags are recognized for dependent=true:
* {{anchor|choose|'''[choose]'''}}: the player was given an option by the scenario or for an advancement path.
** '''value''': the index number of the option chosen. Index numbers are given by the scenario designer.
* {{anchor|input|'''[input]'''}}: if a lua code used [[LuaWML:Misc#wesnoth.synchronize_choice]] this tag contains the returned table.
* {{anchor|global_variable|'''[global_variable]'''}}: a WML code used with [get_global_variable]
* {{anchor|random_seed|'''[random_seed]'''}}: a user's actions use the rng and thus a new random seed is needed.
* {{anchor|map_data|'''[map_data]'''}}: contains the map data read from the file when '''[replaced_map]''' with the '''map_file=''' argument was invoked.

== See Also ==
* [[SavefileWML]]
* [[ReferenceWML]]

[[Category: WML Reference]]

RussianTranslation

2025-04-14T22:47:40Z

Dwarftough:

== Команда русского перевода Russian translation team ==

Координатор перевода (Translation maintainer):

* Artem Khrapov ([[User:kabachuha|kabachuha]]) mailto:artemkhrapov2001АТyandexDОTru

Текущие переводчики (Current translators):

* ([[User:BabylonAS|BabylonAS]]) mailto:BabylonASАТyandexDОTru
* ([[User:Dwarftough|dwarftough, известный в дискорде как catbegemot]]) Дискорд: catbegemot

Благодарим за помощь (Inactive translators):

* ([[User:Aldarisvet|Aldarisvet]]) mailto:rassvetozaaarАТgmailDОTcom (предыдущий координатор/previous maintainer)
* Olga Abramova ([[User:ilanacarra|ilanacarra]]) mailto:ilanacarraАТgmailDОTcom
* Ishayahu Lastov
* Victor Sergienko ([[User:singalen|singalen]]) mailto:singalenАТgmailDОTcom
* Fallen Phoenix
* Fedor Khod'kov (teddy, [[User:Fkhodkov|Fkhodkov]]) mailto:fkhodkovATgmailDOTcom
* Sergey Khlutchin (Khlut) mailto:Sergey.KhlutchinATgmailDOTcom
* Igor mailto:cheer6ATgmailDOTcom
* Valentina Mukhamedzhanova (umi) mailto:umirraATgmailDOTcom
* Fedor Gavrilov (gallowzbird) mailto:the.sun.turns.blackATgmailDOTcom
* Fardeil
* Danila Evstifeyev ([[User:MyOtheHedgeFox|MyOtheHedgeFox]]) mailto:a-ztechATyandexDOTru
* Victor Zabavin (vicza) mailto:viczaATzmailDOTru
* Azamat H. Hackimov ([[User:Winterheart|Winterheart]]) mailto:azamatDOThackimovATgmailDOTcom
* Alexey Khudiakov mailto:alexey.skladnoyATgmailDOTcom
* Alexey Remizov mailto:alexeyATremizovDOTppDOTru
* Ilya Kasnacheev (Ilyak) mailto:ilya.kasnacheevATgmailDOTcom
* Kotov Ilya ([[User:Maddiez|Maddiez]]) mailto:kotov_ilyaATmailDOTru
* O_o mailto:mm-94ATmailDOTru
* Anthony Kolesov ([[User:Kaagle|Kaagle]]) mailto:anthony.kolesovATgmailDOTcom
* Sergey Popov (loonycyborg) mailto:loonycyborgATgmailDOTcom
* Alexandr Menovchicov (VaM) mailto:vamATkypiDOTru (первый координатор/first maintainer)
* Denis Revin (Dut_Norshi) mailto:denis.revinATgmailDOTcom
* Andrey Tikhonov (tiandrey)
* Dmitry Ashkadov (dmitryash) mailto:dmitry.ashkadovATgmailDOTcom
* marat mailto:maratelektronATramblerDOTru, mat (mat@nat), iven, olga_flox — команда перевода «Секретов Древних»

'''Замечание.''' Сочетаниями букв «AT» и «DOT» в адресах электронной почты заменены, соответственно, символы «собачки» и точки, чтобы затруднить сбор данных сетевым ботам.

== Текущее состояние переводов (версия 1.16) ==

[http://www.wesnoth.org/gettext/index.php?view=langs&version=branch&lang=ru Самая свежая информация]

'''TODO''': Данные для 1.16 будут сведены в таблицу в ближайшее время.

'''Примечания'''.
# Если какой-то файл свободен, нуждается в правке/переводе, и Вы хотели бы над ним поработать, то, пожалуйста, заявите об этом при помощи канала #russian официального Дискорд-сервера Веснота или [http://www.wesnoth.org/forum/viewtopic.php?t=964 ветки на форуме] — предпочтительно, первым способом — чтобы не получилось, что два человека работают над одним файлом. Для работы следует брать последнюю версию файла из [http://www.wesnoth.org/gettext/index.php?view=langs&version=branch&lang=ru http://www.wesnoth.org/gettext]. Аналогично, если Вы не хотите/не можете более поддерживать файл, сообщите об этом в чате/на форуме или хотя бы напишите сообщение координатору.
# Если Вы завершили какой-либо перевод основного содержания игры, следует отправить его на вычитку координатору перевода через каналы связи, упомянутые выше. Перевод дополнений обычно обговаривается непосредственно с автором дополнения или с предыдущими ответственными за него переводчиками.
# Если Вы — переводчик и Вы обнаружили непереводимый фрагмент или ошибку в исходном тексте, уведомите об этом самих разработчиков! Как правило, это можно сделать через Дискорд: #development — разработка основной игры, #modding — создание дополнений.
# '''Внимание!''' Любые попытки изменить перевод через запросы слияния (pull-requests) в официальном репозитории Веснота будут заблокированы!

== Устаревшее состояние переводов (версия 1.12) ==

{|border=1
! Название
! Файл
! Примечания
! Поддерживает
! Корректирует
|-
|colspan=5 align="center"|'''Основная ветка игры''' (mainline)
|-
|Интерфейс || [https://raw.github.com/wesnoth/wesnoth/1.12/po/wesnoth/ru.po wesnoth] || || ||
|-
|Интерфейс || [https://raw.github.com/wesnoth/wesnoth/1.12/po/wesnoth-lib/ru.po wesnoth-lib] || требует правки || ||
|-
|Страницы man || [https://raw.github.com/wesnoth/wesnoth/1.12/po/wesnoth-manpages/ru.po wesnoth-manpages] || || - ||
|-
|Руководство || [https://raw.github.com/wesnoth/wesnoth/1.12/po/wesnoth-manual/ru.po wesnoth-manual] || Не cогласованы падежи, нужно вычитать, нужно изменить путь к скриншотам, чтобы ссылались на локализованные в ./ru/ || archdron ||
|-
|Редактор || [https://raw.github.com/wesnoth/wesnoth/1.12/po/wesnoth-editor/ru.po wesnoth-editor] || || - ||
|-
|Рода войск || [https://raw.github.com/wesnoth/wesnoth/1.12/po/wesnoth-units/ru.po wesnoth-units] || || ||
|-
|Сетевая || [https://raw.github.com/wesnoth/wesnoth/1.12/po/wesnoth-multiplayer/ru.po wesnoth-multiplayer]|| || ||
|-
|Обучение || [https://raw.github.com/wesnoth/wesnoth/1.12/po/wesnoth-tutorial/ru.po wesnoth-tutorial] || || ||
|-
|Набег орков || [https://raw.github.com/wesnoth/wesnoth/1.12/po/wesnoth-aoi/ru.po wesnoth-aoi] || || ||
|-
|Спускаясь во тьму || [https://raw.github.com/wesnoth/wesnoth/1.12/po/wesnoth-did/ru.po wesnoth-did] || отредактировано || - ||
|-
|Воспоминания Делфадора || [https://raw.github.com/wesnoth/wesnoth/1.12/po/wesnoth-dm/ru.po wesnoth-dm] || правка || ||
|-
|Мёртвые воды || [https://raw.github.com/wesnoth/wesnoth/1.12/po/wesnoth-dw/ru.po wesnoth-dw] || 77%, в процессе || ||
|-
|Вторжение с востока || [https://raw.github.com/wesnoth/wesnoth/1.12/po/wesnoth-ei/ru.po wesnoth-ei] || || - ||
|-
|Наследник престола || [https://raw.github.com/wesnoth/wesnoth/1.12/po/wesnoth-httt/ru.po wesnoth-httt] || || ||
|-
|Освобождение || [https://raw.github.com/wesnoth/wesnoth/1.12/po/wesnoth-l/ru.po wesnoth-l] || требует правки || ||
|-
|Легенда Весмира || [https://raw.github.com/wesnoth/wesnoth/1.12/po/wesnoth-low/ru.po wesnoth-low] || в процессе || ||
|-
|Северное возрождение || [https://raw.github.com/wesnoth/wesnoth/1.12/po/wesnoth-nr/ru.po wesnoth-nr] || || ||
|-
|Сын Чёрного Глаза || [https://raw.github.com/wesnoth/wesnoth/1.12/po/wesnoth-sotbe/ru.po wesnoth-sotbe] || || ||
|-
|Огненный скипетр || [https://raw.github.com/wesnoth/wesnoth/1.12/po/wesnoth-sof/ru.po wesnoth-sof] || || ||
|-
|Сказание о двух братьях || [https://raw.github.com/wesnoth/wesnoth/1.12/po/wesnoth-tb/ru.po wesnoth-tb] || || ||
|-
|Молот Турсагана || [https://raw.github.com/wesnoth/wesnoth/1.12/po/wesnoth-thot/ru.po wesnoth-thot] || || ||
|-
|На заре Веснота || [https://raw.github.com/wesnoth/wesnoth/1.12/po/wesnoth-trow/ru.po wesnoth-trow] || || ||
|-
|Южная стража || [https://raw.github.com/wesnoth/wesnoth/1.12/po/wesnoth-tsg/ru.po wesnoth-tsg] || || ||
|-
|Под палящими светилами || [https://raw.github.com/wesnoth/wesnoth/1.12/po/wesnoth-utbs/ru.po wesnoth-utbs] || || ||
|-
|Новая земля || [https://raw.github.com/wesnoth/wesnoth/1.12/po/wesnoth-anl/ru.po wesnoth-anl] || || ||
|-
|colspan=5 align="center"|'''Графические файлы''' (карты, скриншоты и др.) [[ImageLocalization#List_of_Images_for_Localization|Список файлов]]
|-
|Помощь || [https://raw.github.com/wesnoth/wesnoth/1.12/data/core/images/help Каталог] || [https://raw.github.com/wesnoth/wesnoth/1.12/data/core/images/help/l10n/ru готово] || teddy ||
|-
|Руководство || [https://raw.github.com/wesnoth/wesnoth/1.12/doc/manual/images Каталог] || - || - ||
|-
|Главная карта || [https://raw.github.com/wesnoth/wesnoth/1.12/data/core/images/maps/wesnoth.png Файл] || [https://raw.github.com/wesnoth/wesnoth/1.12/data/core/images/maps/l10n/ru/wesnoth--overlay.png готово] || singalen ||
|-
|Логотип || [https://raw.github.com/wesnoth/wesnoth/1.12/data/core/images/misc/logo.png Файл] || - || - ||
|-
|Карта AOI || [https://raw.github.com/wesnoth/wesnoth/1.12/data/campaigns/An_Orcish_Incursion/images/an-orcish-incursion-map.png Файл] || [https://raw.github.com/wesnoth/wesnoth/1.12/data/campaigns/An_Orcish_Incursion/images/l10n/ru/an-orcish-incursion-map--overlay.png готово] || - ||
|-
|Карта DID || [https://raw.github.com/wesnoth/wesnoth/1.12/data/campaigns/Descent_Into_Darkness/images/misc/descent-into-darkness.png Файл] || - || - ||
|-
|Карта DW || [https://raw.github.com/wesnoth/wesnoth/1.12/data/campaigns/Dead_Water/images/dead-water-map.png Файл] || - || - ||
|-
|Карта EI || [https://raw.github.com/wesnoth/wesnoth/1.12/data/campaigns/Eastern_Invasion/images/eastern-invasion-map.png Файл] || - || - ||
|-
|Карта L || [https://raw.github.com/wesnoth/wesnoth/1.12/data/campaigns/Liberty/images/maps/liberty-map.png Файл] || - || - ||
|-
|Карта LoW || [https://raw.github.com/wesnoth/wesnoth/1.12/data/campaigns/Legend_of_Wesmere/images/legend-of-wesmere-map.png Файл] || - || - ||
|-
|Карта SotBE || [https://raw.github.com/wesnoth/wesnoth/1.12/data/campaigns/Son_Of_The_Black_Eye/images/farnorth.png Файл] || [https://raw.github.com/wesnoth/wesnoth/1.12/data/campaigns/Son_Of_The_Black_Eye/images/l10n/ru/farnorth--overlay.png готово] || umi ||
|-
|Рисунки из TRoW || [https://raw.github.com/wesnoth/wesnoth/1.12/data/campaigns/The_Rise_Of_Wesnoth/images/story Каталог] || - || - ||
|-
|Мультиплеер || [https://raw.github.com/wesnoth/wesnoth/1.12/data/core/images/lobby Каталог] || - || - ||
|-
|colspan=5 align="center"|'''Проекты из [[WesCamp]]''' (не-mainline. Куда слать, если что - написано на странице WesCamp)
|-
|[[CampaignEpicOfVaniyera|Эпопея Ваньеры]] || Epic_of_Vaniyera || || phantom ||
|}

'''Примечания'''.
# Дата последнего изменения — это дата, когда файл был отправлен разработчикам. Обычно довольно быстро он появляется на SVN. В составе же игры он появится, естественно, лишь с выходом новой подверсии. Если Вы не хотите ждать, Вы всегда можете скачать последний .po файл из SVN, скомпилировать из него .mo (например, с помощью редактора Poedit) и поместить его в директорию \po\ru\LC_MESSAGES.
# Если какой-то файл свободен, нуждается в правке/переводе и Вы хотели бы над ним поработать, то, пожалуйста, добавьте своё имя в соотв. колонку — чтобы не получилось, что два человека работают над одним файлом. Для работы следует брать последнюю версию файла из SVN. Аналогично, если Вы не хотите/не можете более поддерживать файл, уберите своё имя из таблицы, чтобы люди видели, что файл свободен.

== Типографика ==

Мы стараемся использовать символы типографики везде, где они необходимы. Это буква "ё", правые и левые двойные кавычки, длинное тире.

В Windows их можно использовать, установив [http://ilyabirman.ru/projects/typography-layout типографскую раскладку] либо вводя код нужного символа:
* включите NumLock;
* тире (—): Alt—0151 (0151 наберите на цифровой клавиатуре);
* кавычки («»): Alt—0171 и Alt—0187;
* дефис ("чёрточка", через которую пишутся слова, например, "каляки-маляки"): обычный "минус".

кому интересно — [http://tlt.its.psu.edu/suggestions/international/accents/codealt.html здесь больше]

А ещё мы пишем "Вы" с большой буквы — там, где обращаемся к одному пользователю. Множественное число пишется с маленькой буквы.

== Как не надо переводить ==

Признаки плохого перевода:
* примитивные кальки с английского: слова "имеет", "является";
* порядок слов, как в английском предложении, но нехарактерный для русского;
* слова, более бледные, чем в оригинале;
* канцелярит.

== См. также ==

* [[RussianGlossary|Глоссарий русского перевода]]
* [[RussianTranslationDictionary|Словарь имён и названий]]
** [[RussianTranslationDictionaryGeography|География]]
** [[RussianListOfUnits|Рода войск]]
* Перевод кампаний:
** [[CampaignBurningSuns:RussianTranslation|Under the Burning Suns]]
** [[CampaignANewOrder:RussianTranslation|A New Order]]
* Вспомогательные материалы:
** [[GettextForTranslators|Как работать с po-файлами (англ.)]]
** [[ProseStyle|Стиль речи (англ.)]]
* [http://www.wesnoth.org/forum/viewtopic.php?t=964 Ветка на форуме, посвященная русскому переводу]
* [http://gettext.wesnoth.org/index.lang.php?lang=ru&version=trunk Статистика перевода для русского языка]

== Внешние ссылки ==
[http://lib.rus.ec/b/74970 Нора Галь, "Слово живое и мёртвое"] - всем, кто что-либо переводит, читать обязательно. И тем, кто хоть что-то пишет по-русски.

[[Category:Russian]]
[[Category:Translations]]

Microtactics, or let's learn to analyze

2025-01-03T23:35:02Z

Dwarftough:

More than once I've seen how decent, not bad strategists get lost in situations that require an efficient use of microtactics on the field.

Let's start with what it actually means. A microtactic in Wesnoth is a capability to control your forces rationally in offense or defense depending on a particular situation. Here I'm not going to describe all possible situations or give you specific instructions what to do. Instead I'll try to teach you how to set up the basic point of your offense or defense.

The key of success in this matter is an ability to prioritize. Priorities may differ, starting from killing a particular unit and up to taking the key point on the map.

== Unit priorities ==
# Enemy leader
# Close-to-level-up unit (less than 9 xp to level)
# Half-dead unit
# Units with great damage (poisoners > ranged > melee)
# Healers
# Scouts
# Any other

Let's examine each of those

''' Leader '''

As each map is based on destroying the enemy leader (the articles talks about default MP scenarios - the translator's note), this unit has the greatest priority for us. Dead leader = victory

''' Close-to-level-up units '''

One of the main rules of good players is that your opponent should have the only second level unit, which is the leader, and it shouldn't last long. This is especially important about close-to-level units from the 4th category (great damage units)

''' Half-dead units '''

We always try to reduce the number of enemy units, units not killed in time could become a hindrance later.

''' Units with great damage'''

This group is one of the most important. By killing those units we deny the enemy his means of offense and defense.

''' Healers '''

A very important target as well. Healers often reduce to zero results of our attacks.

''' Scouts '''

Eyes and ears of the enemy. Expensive units, usually easy to kill. We try to get rid of them or control them.

''' Others '''

In this category we include all "cannon fodder" which the enemy uses in his formation. Through them we usually make our way to the prioritized targets, so there is no much sense to add more details here.

<hr>

Of course, each point has its exceptions. But they appear in particular tactical situations. For example, sometimes it's better to let the enemy level up his unit (increasing his upkeep costs) if this unit doesn't benefit the enemy significantly. Or, sometimes you may let a half-dead unit go if it has little value in the battle (the enemy will place the unit to heal and will pay upkeep costs for it). So, think and analyze, and the points above are just the basis for your thought work.

== Terrain priorities ==
# Place of enemy recruiting (i.e. the enemy keep)
# Places that "lock" enemy units
# Villages
# Mountains
# Terrain adjacent to flat, water, or any other terrain that don't give the enemy a defense bonus

''' Enemy keep '''

Taking this point, we prevent the enemy getting reinforcements. This also gives more time for our own expansion.

''' Places that "lock" enemy units '''

A vague point that includes various isthmuses, arches and alike. Placing our unit here we block a massive attack of the enemy. This is especially relevant when we need to buy time (in case of lawful/chaotic enemies)

''' Villages '''

Don't think I need to say much here. Economy and healing.

''' Mountains '''

That is also an important point. A mountain point benefits many units of each faction.

''' Adjacent to terrain that doesn't give the enemy a defense bonus '''

Creating a front with conditions favourable for us we create opportunities for better RNG.

<hr>
Please note that each of the... TODO

{{Wesnothlife|py6aka, Feb 26, 2012}}

15 tips for new players

2024-12-29T22:08:00Z

Dwarftough:

# NEVER rely on luck.
# Don't fight in an unfavourable time of day.
# Calculate your defensive placement in such a way that the minimal number of enemy units could attack you.
# For a defensive line better put a unit with a lot of hp or a unit with great resistances instead of units with high dodge.
# Attack in your favourable time of day.
# Attack units that are more vulnerable to a given type of damage.
# Don't attack units with strong melee in melee, don't attack units with strong ranged in ranged.
# Plan an attack in such a way that the maximal number of your units could participate in it.
# Don't rush at the enemy leader if chances of a leaderkill are slim and your units suffer great retaliation.
# Try to lure your opponent on [[terrain]] where he had less defense.
# If you have an overwhelming advantage in the number of units and economy, continue attacking even in an unfavourable time of day/
# Don't forget to take villages (it's the basic element of economy).
# Don't harass enemy villages if your unit can be trapped.
# When you harass, don't forget that with each village you take from your opponent, you win 4-6 gold per turn (consider the harassing unit's cost to not get into disadvantage).
# Prioritize economy over the number of units (but wisely).

P.S. And don't forget that each rule has exceptions :)

{{Wesnothlife|ReNoM, Sep 11, 2011}}

15 tips for new players

2024-12-29T22:06:59Z

Dwarftough:

# NEVER rely on luck.
# Don't fight in an unfavourable time of day.
# Calculate your defensive placement in such a way that the minimal number of enemy units could attack you.
# For a defensive line better put a unit with a lot of hp or a unit with great resistances instead of units with high dodge.
# Attack in your favourable time of day.
# Attack units that are more vulnerable to a given type of damage.
# Don't attack units with strong melee in melee, don't attack units with strong ranged in ranged.
# Plan an attack in such a way that the maximal number of your units could participate in it.
# Don't rush at the enemy leader if chances of leaderkill are slim and your units suffer great retaliation.
# Try to lure your opponent on [[terrain]] where he had less defense.
# If you have an overwhelming advantage in the number of units and economy, continue attacking even in an unfavourable time of day/
# Don't forget to take villages (it's the basic element of economy).
# Don't harass enemy villages if your unit can be caught.
# When you harass, don't forget that with each village you take from your opponent, you win 4-6 gold per turn (consider the harassing unit's cost to not get into disadvantage).
# Prioritize economy over the number of units (but wisely).

P.S. And don't forget that each rule has exceptions :)

{{Wesnothlife|ReNoM, Sep 11, 2011}}

SideWML

2024-05-26T23:08:39Z

Dwarftough: /* Multiplayer Keys */

{{WML Tags}}

The term "side" refers to a single player in the Wesnoth turn order, which can be controlled by either a human or an AI. Every [[ScenarioWML|scenario]] must have at least one side. There is no hard limit on the number of sides a single scenario can have.

Usually the number of sides in a scenario is fixed. However, the Lua function [[LuaAPI/wesnoth/sides#wesnoth.sides.create|wesnoth.sides.create]] can be used to dynamically add new sides if required.

Sides in a scenario are described by the '''[side]''' tag, which recognizes the following keys and tags.

== Common Keys ==

These keys are always permitted in a '''[side]''' tag.

* '''side''': a number. The leader of this side is placed on the tile represented by this number (see [[BuildingMaps]]). When defining sides, they must be defined in order since the side number is checked against the number of sides seen so far. Currently, the Multiplayer server rejects entering a scenario with more than 9 sides, even if those extra sides are AI sides. {{DevFeature1.13|2}} The server doesn't limit the number of sides anymore.

* '''controller''' (required): how moves for this side should be inputted.
** '''ai''': the Wesnoth AI makes this side's moves.
** '''human''': a player controls this side's moves.
** '''null''': the side doesn't get a turn to move. Events that would usually occur on the side's turn will not take place. This includes healing (ability, villages and rest) and ''side turn'' events.
** '''a number''': gives this side's control to a side with '''side''' matching the number (multiplayer only). {{DevFeature1.13|2}} using a number is deprecated, use previous_save_id= instead.
** Note: in multiplayer, when reading the side's data with ''[store_side]'', the value may differ between clients and using it for conditional actions may cause OOS. Discussion in https://r.wesnoth.org/p643343

* '''type''': if present, the keys describing a unit (including '''type''') which will begin on the side's keep will be the remainder of the '''[side]''' tag, See [[SingleUnitWML]]. Note that if the keys '''x''', '''y''' are included, the leader will begin there regardless of keep location. If this side has a recall list from a previous level, then the recall list will be searched for a leader (using ''canrecruit=yes'') and if one is found it will be used instead of the one described in the '''[side]''' tag. Typical keys used for defining the leader unit are ''id'', ''name'' and ''unrenamable=yes'', see [[SingleUnitWML]]. The unit will automatically be set to be able to recruit.

* '''recruit''': a list of unit types. At the beginning of the scenario, the side gains recruitment of these units. Units in the side recruit list can always be recruited by a leader on this side, in addition to any units in the individual leader's '''extra_recruit''' list. {{DevFeature1.13|?}} in multiplayer, unless you specify ''faction=Custom'', this will be overwritten by the recruit list from the faction.

* '''gold''': the starting gold for this side. Default: 100. (If gold is carried over from a previous scenario, this value is the minimum starting gold.)

* '''income''': the base income for this side. Default: 0. This is added to ''base_income'', '''[game_config]''' to determine the side's base income. (see [[GameConfigWML]]).

* '''hidden''': if 'yes', side is not shown in status table.

* '''fog''': if 'yes', this side cannot see any tiles it is not within vision of, except at the start. Please note that the AI currently ignores the fog.

* '''fog_data''': describes the area which this team has de-fogged, using the same format as shroud_data. (This is not particularly useful when defining a side, though, as the game will recalculate fog as turns begin and end.) It is used in saved games.

* {{anchor|fog_override|'''[fog_override]'''}}: With keys x= and y=, this records the hexes that have been cleared (multiturn) with {{tag|DirectActionsWML|lift_fog}}.

* '''shroud''': if 'yes', this side cannot see any tiles it has not moved within sight of. Please note that the AI currently ignores the shroud. NOTE: with shroud=no, this team *ignores* shroud, so it is not possible to modify it using place_shroud and remove_shroud tags. If you want to do so, use "shroud=yes" and place_shroud/remove_shroud tags.

* '''shroud_data''': describes the area which this team has de-shrouded. An example:
|
|00011111000
:This would leave the first column on the map unaltered and would change the second column for 11 tiles. A '0' means: shrouded, '1' means unshrouded. You can either call an external file using {@filename} (see [[PreprocessorRef]]) or place the data in quotes. For making an external file see [[ShroudDataWML]].

* '''persistent''': whether the side exists in any other scenarios. If 'yes', then ''save_id'' (see below) is used to identify the side in other scenarios. Defaults to 'yes' for sides with a human controller, and 'no' for ai controlled sides.

* '''save_id''': defaults to the leader's ''id'' if available, 'Unknown' otherwise. The ID of the side with respect to the previous and next scenarios. Used to carry over the side's recall list (including the side's leader), recruitment list, and starting gold from scenario to scenario. Also used for the side's displayed name in the victory gold-calculation dialog.

* '''previous_save_id''': {{DevFeature1.13|2}} defaults to ''save_id''. Only used in mp games, specially mp campaigns. This attribute specifies which user should play this side by default. For example if a side has previous_save_id="Konrad" then the side will be assigned to that player who played the side with the save_id="Konrad" in the previous level. If used in the first scenario, multiple sides with the same ''previous_save_id'' will be assigned to the same player.

* '''team_name''': a non translatable string representing the team's description. Sides with the same team_name are allied. Default ''side''. ''team_name'' is now a comma-separated list of teams that the side is on.

* '''user_team_name''': a translatable string representing the team's description. This has no effect on alliances. Default ''team_name''.

* '''current_player''': a translatable string representing the player's or leader's name. Defaults to the leader's id; if the side's leader is a human player in multiplayer, the default is the player's username. {{DevFeature1.13|0}} This field is now always the player name (mp server nick) it impossible to change it with wml/lua. {{DevFeature1.13|5}} You can use ''side_name'' instead to specify the name for the side (which is then used in new turn dialogs, statisitc dialogs etc.)

* '''side_name''': {{DevFeature1.13|5}} a translatable string representing the name of the side, used for example in the new turn dialog. Defaults to ''name'' if the side was inside a '''[scenario]''' and to the player's name if the side was inside a '''[multiplayer]'''.

* '''color''': May be either a numeric color index or a color name (e.g. 'blue', 'purple', 'orange', etc.). The numeric form is deprecated. The default list of numbers and corresponding colors can be found in data/core/team_colors.cfg. Can also be an inline color range (the rgb key from [[GameConfigWML#Color_Palettes]]).

* '''flag''': a custom flag animation to use instead of the default one to mark captured villages. An automatic side-coloring is applied.
** Example animation that has three frames and loops every 750ms: ''flag=misc/myflag-[1~3].png:750''

* '''flag_icon''': a custom flag icon to indicate the side playing in the statusbar (a size of 24x16 is recommended). An automatic side-coloring is applied.

* '''village_gold''': the amount of gold given to this side per village it controls per turn. Default specified in ''village_income'', '''[game_config]''' ([[GameConfigWML]]).

* '''village_support''': the number of unit levels this side is able to support (does not pay upkeep on) per village it controls. Default specified in ''village_support'', '''[game_config]''' ([[GameConfigWML]]).

* '''recall_cost''': the amount of gold it costs to recall a unit. Default specified in ''recall_cost'', '''[game_config]''' ([[GameConfigWML]]). {{DevFeature1.15|0}} Units are now recalled for AI sides even if the recall_cost is larger than the unit's worth (essentially its cost, plus potentially a bonus for experience points). In 1.14 and earlier, units were not recalled by the AI in this case even if this was the only recall/recruit action possible to the AI.

* '''share_maps''': whether sides allied with this side see all terrains that this side sees, if they are on shroud. {{DevFeature1.13|1}} This has been deprecated in favor of share_vision (see below).

* '''share_view''': whether sides allied with this side see the units that this side sees, if they are on FoW (fog). {{DevFeature1.13|1}} This has been deprecated in favor of share_vision (see below).

* '''share_vision''': {{DevFeature1.13|1}} all/shroud/none. If ''all'', both shroud and fog view will be shared by this side. If ''shroud'', only shroud view will be shared. If ''none'', the view is not shared.

* '''scroll_to_leader''': optional. If 'no', scroll to the leader is not performed on the start of each turn. (default: yes)

* '''suppress_end_turn_confirmation''': If "yes", then the player will not be asked to confirm ending their turn even if they have not done anything. This is provided for some (probably few) user-made scenarios in which players often skip their turns. (default: no)

* {{anchor|ai|'''[ai]'''}}: if '''controller=ai''', gives parameters to the AI. See [[AiWML]].

* {{anchor|village|'''[village]'''}}: describes a village the side begins in control of.
** ''x'', ''y'' the location of the village. If the pair of coordinates is not a village or is duplicated in another '''[village]''' tag, behaviour is undefined. Recent game engine or wmllint should warn about these.

* {{anchor|unit|'''[unit]'''}}: describes a unit which begins on the side. See [[SingleUnitWML]]. If the side has a recall list and the unit is not given a location, it will start on the recall list. Note that the ''side'' attribute under '''[unit]''' will be ignored, as the side will come from the ''side'' attribute of '''[side]'''.

* {{anchor|leader|'''[leader]'''}}: describes the leader for the side, basically same as '''[unit]''' except that ''canrecruit'' will default to yes and current position to the side starting location if not specified. {{DevFeature1.17|17}} Furthermore, if left out, the '''name''' and '''save_id''' attributes in '''[side]''' will be set to the '''name''' and '''id''' attributes in the first '''[leader]''' tag.

* {{anchor|defeat_condition|'''defeat_condition'''}}: Specifies when a side is considered ''defeated'' this is checked ''for all sides'', after every player action and at the beginning of every turn.
** '''no_leader_left''': (default) The side is considered defeated if it has no units with canrecruit=yes
** '''no_units_left''': The side is defeated as soon as it has no units left.
** '''never''': The side is never considered defeated.
** '''always''': The side is always considered defeated.

: For the meaning and significance of ''defeated'', see [[ScenarioWML#Scenario_End_Conditions]]

== Multiplayer Keys ==

These keys are only permitted in a '''[side]''' tag for a '''[multiplayer]''' scenario.

* '''allow_player''': if false then this side will not be allowed to be modified and will be hidden during game creation. False also prevents this side from being included in shuffle sides. Defaults to yes.

* '''disallow_observers''': prevents observers from seeing this side turn. (default: no)

* '''disallow_shuffle''': {{DevFeature1.13|0}} do not shuffle this side if the "shuffle sides" option is used. (Usually all playable sides are shuffled.) (default: no)

* '''chose_random''': {{DevFeature1.13|0}} indicates if a side chose a random faction during creation

* '''controller_lock''': if true then this side's controller ("Player/Type") modification is limited. It is bound to the '''controller''' attribute in [[SideWML]].

* '''team_lock''': if true then this side's team is not allowed to be modified.

* '''color_lock''': if true then this side's color is not allowed to be modified.

* '''gold_lock''': if true then this side's gold is not allowed to be modified.

* '''income_lock''': if true then this side's income is not allowed to be modified.

* '''faction_lock''': if true then this side's faction is not allowed to be modified.

* '''no_leader''': if 'yes', prevents the engine from generating a leader from the multiplayer faction, basically an alias of '''leader_lock'''

* '''leader_lock''': if true then this side's leader (type or gender) is not allowed to be modified. Note that if ''type='' key is missing, ''leader_lock=yes'' means the side will have no leader.

* '''faction''': if a valid faction id is provided then this side's faction will default to it in the game setup screen. {{DevFeature1.13|?}} if this key isn't included in the ''[side]'' then a random faction will be chosen, and the side's recruit list set from the faction. To use a custom ''recruit'' list, you must also specify ''faction=Custom''.

* '''faction_from_recruit''': if true then this side will be locked to the faction that matches the recruits better.

N.B. the ''lock'' attributes use [[ScenarioWML]] '''force_lock_settings''' as their default value. I.e. if no value to ''lock'' was set, it will take '''force_lock_settings''' value.

== See Also ==
* [[EraWML]]
* [[ScenarioWML]]
* [[ReferenceWML]]

[[Category: WML Reference]]

Competitive Gaming

2024-05-26T23:05:59Z

Dwarftough:

{{Translations}}
{| style="float:right;"
|
__TOC__
|}
For those interested in competitive multiplayer games on a more formal and organized level there are some unofficial options that are made available by the Wesnoth Community. Have a look to see if anything fits your shoe, and please help us keep the list updated by adding/removing alternatives.

== Ladders ==

*[http://wesnoth.gamingladder.info/ Ladder of Wesnoth]
:A 1 vs 1 ladder that uses an [http://en.wikipedia.org/wiki/ELO_rating_system Elo rating] and the Ladder Era.

== Events ==

Ongoing and past events can be found in the [https://forums.wesnoth.org/viewforum.php?f=70 Tournaments Subforum].

Currently ongoing (May 2024):
* [https://forums.wesnoth.org/viewtopic.php?t=55186 Afterlife Rated] (1.16 Wesnoth)
* [https://forums.wesnoth.org/viewtopic.php?t=57990 Mini Maps League] (1.18 Wesnoth, Matchmaking tab)
* [https://forums.wesnoth.org/viewtopic.php?t=58209 Igor's Dunes Festival] (1.18 Wesnoth, Matchmaking tab)

== Notes about possible cheating ==

=== The Facts ===
The following is true for all games that are played remotely & multiplayer in Wesnoth.

There is currently ''no method'' to ''guarantee'' that a persons doesn't cheat in multiplayer. Some of the more obvious ways to cheat are:
* The editing of save files, granted they're used to load a game.
* Observing the opponent with another instance of Wesnoth running, which of course only matters if you play with fog and also allow observers into the game. (Or if you save the game and reload it on a local instance to get vision.)
* Creating and using a version of the game that gives ''any'' kind of imaginable noticeable and unnoticeable advantages (e.g. by having an AI assist in your decision making). Since the project is open source this only requires some programming skills and the will, as there is currently no way for a normal and official version of the game to know for sure that it's connected to another official version.

Knowing this makes you able to take it into account when participating in or arranging competitive events. As explained, the system as it is today doesn't offer a 100% certainty that your opponent(s) don't cheat. With that said it's perhaps also true that most players you'll come across don't have the skills to deal with the more advanced ways of cheating, and it might be the case that most cheaters are easily discovered if you watch a replay, know the rules of the game and have a decent idea of what the opponent is up to on the map. After all, the game math is known by all of us and all large deviations will get noticed.

=== Effects on competitive play ===
It's hard to know the exact effects that these kinds of problems have on the competitive gaming. For some players this is more than enough to not engage in competitions. For others it doesn't matter, since they themselves don't cheat and trust that most players don't. There are only two sure and interlinked things we can say about the phenomenon:

* There are a few who cheat.
* A great majority doesn't.

The logic behind those statements lead us to the conclusion that competitive gaming is fully possible in Wesnoth and that it should be considered a serious option by those interested in it. Most games will be legit because of the following reasons:

*Discovery - The most common ways of cheating can be spotted and/or prevented.

*Knowledge - A really small minority of the players have the knowledge ''and'' will to alter the source code in order to cheat.

*Your psychology - If you stumble across a cheater and don't discover her/him, it's not certain that this will really affect you since you're not aware that they cheated.

*Cheaters' psychology - There are very few people that play a game for a long time if they're in the need to always cheat when things get rough. Their victory is almost a paradox - they cheat to win, but know them self that they didn't. Most cheaters quit the game pretty fast because of that and other self-evident psychological facts.

*Effect - Even if you don't discover cheaters the number of times you'll play against them are relatively limited, making their overall impact on your gaming experience small or non-existent in the long run.

=== Resolving Cheating Disputes ===
These are two suggested actions:

1) Submit your replay to the administrator of the competitive framework (ladder or tournament admin, etc).
If an RNG cheat was used, speak with Dave about implementing the anti-cheat code.
2) If your replay is different from your rivals:
One of you altered a replay, and its impossible to know who. As the admins of the competitive framework can not tell for sure who is being honest in this case, they can simply record that the game's winner was disputed by both parties. While this gets you nothing as the victim, anyone cheating in this manner more than once will effectively be "caught". As his or her disputes pile up no one will accept matches with them. If the competitive framework uses some kind of identification the cheater will have to create a new account and spend spend time on getting their rating back.
3) Don't make a mess if you can avoid it: If this has only happened to you once it might be an idea to just ignore it as it may not be worth all the hassle, depending on the specifics in the case.

==== What not to do ====
If you ''know'' your opponent has cheated please make sure that you really have evidence that can prove it 100% before claiming that you ''know'' that he/she did. Keep in mind that real evidence would ''prove'' something. If, for example, both of you have a different version of the save file there is no way to prove which one of you faked his/her, hence, the files are not proof of who the cheater is - they only prove that there is one.

Don't ever give an impression about you ''knowing'' the facts if you can't prove them! It matters a lot what words you use since the allegations are very serious and could destroy a player's reputation which he/she has invested a great amount of time in building within the community.

====Reasonable questioning====
In most competitive frameworks you are probably entitled to question something which you don't fully understand, in order to learn more about it, or something which seems odd and could possibly be a bug and/or a cheat. If you suspect that there is something strange going on then please start by talking with the person you suspect is cheating, if there is one. If the answer doesn't calm you down or you get even more suspicious and still don't understand what's going on, you would be best of contacting the admin/mods for the competitive framework you participate in, if any. If the framework is ''the Ladder of Wesnoth'', then please ''don't'' post in the Wesnoth forum about it.

If you're not participating in a competitive framework and just played a casual game then you could post your questions in the official Wesnoth forum along with as much info as possible and preferably a replay.

Remember that if you go public with your questioning, wherever you do it, you're expected to do it like an adult and in a mature manner. Try to be objective and calm, and present your case and thoughts in a way which doesn't insult or in any other way harm the supposed cheater. If you just had a fight with the person it is always a very bad idea to post right away. It could perhaps also be a good idea to not mention the other player's name until some kind of conclusion had been reached ''if'' keeping that player anonymous would help protect his/her integrity. After all, it can't be very pleasant to be accused of something in the open.

Keep in mind that there is no "Wesnoth Court Room" and that nobody is expected to deal with your problems. Players who choose to discuss the matter with you do it as representatives of them self and ''there are no official rulers'', unless of course, this all happens in a competitive framework which happens to have some. You ask for help to get more clarity into what has happened. Some times the answers will be of help, other times they won't.

====Warning====
If English is not your native tongue and you want to express complicated arguments or be sure to be understood correctly but feel uncomfortable using the English language please ask a friend to help you write it all up in proper English.

Finally we'd like to warn you once more about the act of accusation: For many people it is ''very'' stigmatizing and unsettling to be accused, and would maybe become even more so if the person happened to be innocent. Please think things through thoroughly before presenting an accusation of something. Especially what language you use, what you claim, where and why.

Also understand that players who have been around for longer than yourself will ''usually'' have much greater credibility than you, especially if they've been a part of the Wesnoth community for several years.

With all this said, there ''can'' still arise situations that need the extra attention and that a healthy questioning could help resolve. Questioning something is, if done in a proper way, nothing dangerous or harmful at all. Done wrong however it could start tearing apart the community piece by piece. Keep that in mind of moderators react.

[[Category:Playing Wesnoth]]

LuaAPI/wesnoth

2024-04-11T21:17:58Z

Dwarftough: /* wesnoth.scenario */

<div class="tright"> __TOC__ </div>

The <tt>wesnoth</tt> module contains most of the core Wesnoth API. It is always loaded and available.

== Functions ==

=== wesnoth.dofile ===

* '''wesnoth.dofile'''(''file_path'', [...]) → ...

Loads and executes a file. The rules for locating the files are the same as for WML files, except that they require a ''.lua'' extension instead of ''.cfg.'' Any extra parameters to '''dofile''' are forwarded to the script (which can access them via the special <tt>...</tt> variable), and '''dofile''' returns all the values returned by the script.

=== wesnoth.require ===

* '''wesnoth.require'''(''module'') → ''module_contents''

Returns the contents of the specified module, loading it if necessary. The module can either be a simple name or a file path similar to that used by '''wesnoth.dofile'''. In addition, the ''.lua'' extension will automatically be appended if necessary. The module script is invoked with no arguments, and '''wesnoth.require''' then passes back its first return value, discarding any additional ones. If the module is a directory, then all lua files are loaded, and a table containing the resulting modules is returned, with the keys being the filenames minus the ''.lua'' extension.

'''wesnoth.require''' returns nil on failure, for example if it could not locate the module. If it did locate the module, but the module did not return anything (or returned nil), then '''wesnoth.require''' returns an empty table with a metatable that raises an error on any attempt to access it.

=== wesnoth.textdomain ===

* '''wesnoth.textdomain'''(''domain'') → ''textdomain_constructor''

Returns a callable userdata that can be used to construct translatable strings. A typical use is:

<syntaxhighlight lang=lua>
local _ = wesnoth.textdomain "example"
wesnoth.alert(_ "This is an example translated string!")
</syntaxhighlight>

The full syntax for using the result of this function is:

* ''textdomain_constructor''(''string'', [''string_plural'', ''number'']) → ''translatable_string''

By passing the optional arguments, you can vary the string based on a number that will be substituted into it. As with all Lua functions, the parentheses are optional when passing a single string argument, as in the above example. This plural syntax returns a form of the string that's grammatically suitable for the indicated number, but doesn't actually substitute the number in – you need to do that yourself with either '''string.format''' or '''stringx.vformat'''.

The returned translatable string can be treated in many ways like a regular string. Translatable strings can be compared with other translatable strings or concatenated with each other or with regular strings or integers. The length operator also works, though it should be noted that its value may change if the language is changed. If you need to pass a translatable string to a function that doesn't understand them, it can be converted to a regular string with tostring.

=== wesnoth.log ===

* '''wesnoth.log'''([''logger''], ''message'', ''in_chat'')

Logs a message to the console. These messages are normally not visible unless Wesnoth is run from the command-line or (in Windows) with the --wconsole switch. The in_chat argument, however, can be set to true to also echo the message to the in-game chat area.

''logger'' is the log level.

In any context, ''logger'' can be the standard log levels of '''info''', '''debug''', '''warning''', or '''error'''. Various abbreviations of the standard four are also recognised. The default logger is '''info'''.

In the game context, you can also set the ''logger'' to '''wml'''. The '''wml''' log level is special and is intended for WML errors; it always goes to chat, so the in_chat argument is ignored and can be omitted.

The logdomain to enable these logs depends on the context. In the game context, they are written to the '''wml''' logdomain. In other contexts, the logdomain is '''scripting/lua/user'''.

=== wesnoth.as_text ===

{{DevFeature1.15|10}}

* {{LuaGameOnly}} '''wesnoth.as_text'''(''value1'', ''value2'', ...)

Accept one or more values as arguments and returns them as a string. This is intended for use as an easy way to view the contents of lua tables. Using the returned string for any other purpose is not supported.

{{DevFeature1.17|0}} This is now available in all contexts.

=== wesnoth.simulate_combat ===

* {{LuaGameOnly}} '''wesnoth.simulate_combat'''(''attacker'', [''attacker_weapon_index''], ''defender'', [''defender_weapon_index'']) → ''attacker stats evaluation'', ''defender stats evaluation'', ''attacker weapon evaluation'', ''defender weapon evaluation''

Computes the hitpoint distribution and status chance after a combat between two units. The first unit is the attacker. The attacker does not have to be on the map, but its location should be meaningful - that is, it can be a private-to-Lua clone of a unit with the '''x''' and '''y''' values changed, but whatever it is has to have '''x''' and '''y''' values that allow attacking the defender. The second unit is the defender; it has to be on the map.

Optional integers can be passed after each unit to select a particular weapon, otherwise the "best" one is selected. When giving the weapon, the parameter is the weapon number (integer, starting at 1) and not the attack definition.

The function returns four tables describing the evaluation of the combat. The first two contain an evaluation of the combatant's stats over the course of the fight, while the second two contains more detailed information on their weapons.

The stats evaluation tables contain the following keys:

* ''stats''.'''poisoned''' → ''probability''
* ''stats''.'''slowed''' → ''probability''
* ''stats''.'''untouched''' → ''probability''

The probability that the unit will be poisoned or slowed, or that it will survive with no damage taken. (A scenario where the unit's hitpoints increase counts as untouched.)

* ''stats''.'''average_hp''' → ''number''

The expected value of the unit's hitpoints after the fight.

* ''stats''.'''hp_chance''' → ''array of probabilities''

The probability that the unit's hitpoints will be at a specific value after the fight. Unlike normal arrays in Lua, this one begins at index 0, which represents the chance that the unit will die.

The weapon evaluation tables contain the following keys:

num_blows, damage, chance_to_hit, poisons, slows, petrifies, plagues, plague_type, backstabs, rounds, firststrike, drains, drain_constant, drain_percent, attack_num, name

<syntaxhighlight lang='lua'>
local function display_stats(n, t)
wesnoth.interface.add_chat_message(string.format(
"Chance for the %s\n to be slowed: %f,\n to be poisoned: %f,\n to die: %f.\nAverage HP: %f.",
n, t.slowed, t.poisoned, t.hp_chance[0], t.average_hp))
end
local att_stats, def_stats = wesnoth.simulate_combat(att, att_weapon, def, def_weapon)
display_stats("attacker", att_stats)
display_stats("defender", def_stats)

local att_stats, def_stats, att_weapon, def_weapon = wesnoth.simulate_combat(attacker, att_weapon_number, defender)
wesnoth.interface.add_chat_message(string.format(
"The attack %s should be countered with %s, which does %d damage, has %d%% chance to hit and forces %d attack rounds due to its berserk ability.",
att_weapon.name, def_weapon.name or "no weapon", def_weapon.damage, def_weapon.chance_to_hit, def_weapon.rounds))
</syntaxhighlight>

=== wesnoth.name_generator ===

* '''wesnoth.name_generator'''('''"markov"''', ''definition'', [''chain_size'', [''max_length'']]) → ''generator function''
* '''wesnoth.name_generator'''('''"cfg"''', ''definition'') → ''generator function''
* ''generator function''() → ''random name''

Constructs a name generator for use in generating names using either the Markov chain algorithm used in older versions of Wesnoth or the context-free grammar generator used since 1.13.5. The type parameter indicates which algorithm to use (either markov or cfg). The definition can be a string, just like it would be in a config file, or it can be formatted as a table. Additional parameters may be passed, depending on the type of generator. The function returns a callable userdata, which will return a new name each time it is called (with no parameters).

* '''Markov chain''': A Markov chain generator works by analyzing a list of input names and noticing tendencies in the way the letters are strung together. It can then apply those tendencies to produce new similar names that were not in the original list. Longer lists give better results. The definition is a list of names, formatted either as a comma-separated string or as an array-like table. The Markov generator can take two additional parameters.
** ''chain_size'': A value greater than 1 for the ''chain_size'' causes the analyzer to consider the words in chunks, which is similar to analyzing them syllable by syllable instead of letter by letter. The default chain size is 2, meaning that the analyzer treats words as consisting of 2-character syllables.
** ''max_length'': Places a cap on the total length of the name. The default value is 12 characters.
<syntaxhighlight lang=lua>
local markov_names = wesnoth.name_generator('markov', {'Kaasa', 'Kayya', 'Keyya', 'Kiira', 'Korra'}, 1)
print(markov_names(), markov_names(), markov_names())
</syntaxhighlight>
* '''Context-free grammar''': A [[context-free grammar]] is a way of specifying how strings can be constructed. The definition may be specified as a multi-line string, just as described in the preceding link, or it can be formatted as a table where the keys are non-terminals and the values are what they expand to. The expansion of each non-terminal can be formatted either as a |-separated list as described in the preceding link, or as an array-like table. (Mixing the two forms is permissible too.) The context-free generator has no additional parameters.
<syntaxhighlight lang=lua>
local cfg_names = wesnoth.name_generator('cfg', {
main = {'{prefix}{suffix}', '{prefix}{centre}{suffix}'},
prefix = 'Kaa|Ka|Ke|Kuu|Ko',
suffix = 'sa|yya|ra|rra',
centre = 'err|aash|eez|azz'
})
print(cfg_names(), cfg_names(), cfg_names())
</syntaxhighlight>

=== wesnoth.compile_formula ===

* '''wesnoth.compile_formula'''(''formula'') → ''compiled formula''

Compiles a [[Wesnoth Formula Language]] formula into a Lua callable userdata. A compiled formula can be converted back to valid code using the built-in <code>tostring</code> function.

=== wesnoth.eval_formula ===

* '''wesnoth.eval_formula'''(''formula'', [''variables'']) → ''result''
* ''compiled formula''([''variables'']) → ''result''

Evaluate a [[Wesnoth Formula Language]] formula and return the result it computed (which can be '''nil''').

The passed in variables can be an arbitrary Lua table, which defines variables available to the formula. Unlike with WML tables, there is no restriction on the format of this table. The formula can access the variables as a list using the special WFL variable '''__list''', or as a map using the special WFL variable '''__map'''. Directly accessing keys on the table is also possible.

It is also possible to pass a unit proxy as the variables, which evaluates the formula in that unit's context just as if it had been used in a [[StandardUnitFilter]].

When calling '''wesnoth.eval_formula''', the first argument may either be an already-compiled formula or a string, in which case it will be automatically compiled on the fly.

<syntaxhighlight lang=lua>
local f = wesnoth.compile_formula('if(x > y, x - y, x + y)')

print(f{x=1,y=2}) -- prints 3.0
print(f{x=1,y=3}) -- prints 4.0
print(f{x=2,y=3}) -- prints 5.0
print(f{x=1,y=1}) -- prints 2.0
print(f{x=3,y=1}) -- prints 2.0
print(f{x=3,y=2}) -- prints 1.0
</syntaxhighlight>

=== wesnoth.version ===

* '''wesnoth.version'''(''version string'') → ''version''
* '''wesnoth.version'''(''major'', [''minor'', [''patch'']], [''suffix'')) → ''version''

Creates a version object, either by parsing a string or by building it from its component parts. The resulting version object can be compared with other version objects using the standard Lua comparison operators, which follows the same rules as the [[PreprocessorRef#.23ifver_and_.23ifnver|#ifver]] preprocessor statement. It can also be decomposed by accessing the following keys on the object:

* ''integer'': Grab any integer version component by index. A non-canonical version may have more than three components.
* '''major''': The major version number (index 1).
* '''minor''': The minor version number (index 2).
* '''revision''': The patch revision number (index 3).
* '''is_canonical''': True if the version has at most three components (plus an optional suffix).
* '''sep''': The character that separates the version components from the suffix (usually either + or nil).
* '''special''': The version suffix, for example the "dev" in "1.15.14+dev".

The version can be converted to a string using the built-in '''tostring''' function.

<syntaxhighlight lang=lua>
local function version_is_sufficient(required)
return wesnoth.current_version() >= required
end
local required = wesnoth.version "1.9.6"
if not version_is_sufficient(required) then
gui.alert(string.format("Your BfW version is insufficient, please get BfW %s or greater!", tostring(required)))
end
</syntaxhighlight>

=== wesnoth.current_version ===

* '''wesnoth.current_version'''() → ''current version''

Returns the current version of Wesnoth as a version object.

=== wesnoth.ms_since_init ===

* '''wesnoth.ms_since_init'''() → ''milliseconds''

This function returns the amount of milliseconds that have passed since Wesnoth started up the current session. Its only use is to track the passage of real time.

'''WARNING:''' this function uses the same code as [set_variable] time=stamp, and so it is MP-unsafe. It is provided only for benchmark purposes and AI development, although it should work inside wesnoth.synchronize_choice() as well.

=== wesnoth.deprecated_message ===

* '''wesnoth.deprecated_message'''(''element_name'', ''level'', ''version'', ''detail_message'')

Displays a deprecation warning in the Lua console. The level is an integer from 1 to 4 inclusive, and the version can be left nil for levels 1 and 4. Otherwise it must be a version ''string'' (not a version object from [[#wesnoth.version|wesnoth.version]]).

=== wesnoth.deprecate_api ===

* '''wesnoth.deprecate_api'''(''original_name'', ''new_name'', ''level'', ''version'', ''element'', ''detail_message'') → ''deprecated wrapper''

Creates a deprecated wrapper for a function or table. A deprecated function will raise the deprecated message the first time it's called, and then suppress it thereafter. A deprecated table will raise the deprecated message the first time a key is read or assigned, and then suppress it thereafter.

The ''element'' is the function or table to wrap. It can be the original function or the new function (which may happen if the function was renamed without any interface changes), or a wrapper function that calls the new function while providing the interface of the old function. The ''level'' and ''version'' are as in [[#wesnoth.deprecated_message|wesnoth.deprecated_message]].

If ''level'' is 4, then the ''element'' is ignored (you can pass '''nil''') and a generic deprecated wrapper is returned that does nothing but raises the deprecated message the first time you call it, assign a key, or read a key, and suppresses it thereafter. This is intended for a function that was removed without deprecation, to leave behind a more informative message if someone still attempts to use it.

If Wesnoth is run with the <tt>--strict-lua</tt> command-line option, this function will return '''nil''' instead of the deprecated wrapper. Since the normal use-case of this function is to assign the deprecated wrapper to the original name, this has the effect of erasing any deprecated functions from the API.

The result of this function always contains a '''__deprecated''' attribute set to true, which can allow identifying if something is deprecated.

=== wesnoth.type ===

{{DevFeature1.17|?}}

* '''wesnoth.type'''(''value'') → ''type name''

Returns a string describing the value's type. This is the same as the built-in type function, except that it returns a more specific string in the case of userdata or tables, based on the metatable. For example, it would return 'unit' if called on a unit.

=== wesnoth.named_tuple ===

{{DevFeature1.17|?}}

* '''wesnoth.named_tuple'''(''array'', ''names'') → ''named tuple''

Decorates a numeric based array so that the indices can be accessed by name instead of by index. This function is used internally for a number of things, most notably map locations and WML tags. Most end-users will not need to use it, but it could be useful if you wish to build a Lua API that returns locations (or similar data) in the engine-standard format.

For example:

<syntaxhighlight lang=lua>
local t = wesnoth.named_tuple({42,21,36}, {'x', 'y', 'z'})

print(t[1]) -- prints 42
print(t[2]) -- prints 21
print(t[3]) -- prints 36
print(t.x) -- prints 42
print(t.y) -- prints 21
print(t.z) -- prints 36
</syntaxhighlight>

=== wesnoth.get_language ===

* '''wesnoth.get_language'''() → ''string''

Gets the language the UI is currently set to. Note that this may return an empty string if using the system default language.

=== wesnoth.print_attributes ===

* '''wesnoth.print_attributes'''(''object'', [''function''])

Prints out a list of attributes that can be accessed on the object, excluding deprecated functionality. The function defaults to '''print''', and receives a formatted line usually containing multiple attributes. They are annotated by type – &fnof; for a function, &dagger; for a table, ! if there was an error attempting to determine the type (which includes write-only attributes). Other types are unannotated.

For tables, by default this iterates the table using '''pairs''' to discover the attributes available, walking the metatable hierarchy if there is an '''__index''' table and filtering out anything that contains a '''__deprecated''' attribute set to '''true'''. However, if finds a function as the '''__index''', and the table's metatable also has a member '''__dir''', it will be used instead. The '''__dir''' can either be an array of strings, or a function that returns an array of strings. It will automatically be sorted and have any duplicates filtered out.

For custom objects defined by the engine, there is special handling so that this function shows the correct result. For example, if used on a GUI2 widget object, it will show the attributes available for that type of widget, as well as the IDs of any sub-widgets that can be accessed by name.

In the Lua console only, this function can also be referenced by a shorter alias, '''dir'''.

== Hooks ==

=== wesnoth.persistent_tags ===

* {{LuaGameOnly}} '''wesnoth.persistent_tags'''.''action''.'''read''' ↔ '''function'''(''wml content'')
* {{LuaGameOnly}} '''wesnoth.persistent_tags'''.''action''.'''write''' ↔ '''function'''(''add_tag_function'')

This is an associative table defining tags that should be persisted in saved games. Each tag is itself a table containing two functions, read and write. The write function is called in <tt>on_load</tt> and passed a function as a parameter which takes a WML table and adds it to the saved game under the specified tag; the read function is called once per matching tag found in the saved game, and is passed a WML table of its contents. Note the asymmetry here: if you're saving an array, the write function is responsible for saving the entire array (and is only called once), while the read function is only responsible for loading one item (and is called several times).

Example:

<syntaxhighlight lang=lua>
local inventory = {}

function wesnoth.persistent_tags.inventory.read(cfg)
inventory[cfg.side] = cfg
end

function wesnoth.persistent_tags.inventory.write(add)
for i = 1, #wesnoth.sides do
add(inventory[i])
end
end
</syntaxhighlight>

Notice that you don't need to create <tt>wesnoth.persistent_tags.inventory</tt> as an empty table first; you can simply define the read and write functions.

=== wesnoth.wml_actions ===

* {{LuaGameOnly}} '''wesnoth.wml_actions'''.''action'' ↔ '''function'''(''wml parameters table'')

This is a hook table that exposes and defines WML actions. Each function in this table corresponds to a single ActionWML tag, allowing you to invoke tags, define custom tags, and even modify the behavior of built-in tags. The single argument to these functions is a WML table, the content of the tag.

<syntaxhighlight lang=lua>
function wesnoth.wml_actions.freeze_unit(cfg)
local unit_id = cfg.id or wml.error "[freeze_unit] expects an id= attribute."
local unit = wesnoth.units.get(unit_id)
if unit then unit.moves = 0 end
wesnoth.units.modify({ id = unit_id }, { moves = 0 })
end
</syntaxhighlight>

The new tag can now be used in plain WML code.

<syntaxhighlight lang=wml>
[freeze_unit]
id=Delfador
[/freeze_unit]
</syntaxhighlight>

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.

<syntaxhighlight lang=lua>
function wesnoth.wml_actions.print(cfg)
local modified_cfg = setmetatable({}, {__index = cfg})
modified_cfg.size = (cfg.size or 12) + 10
wesnoth.wml_actions.print(modified_cfg)
end
</syntaxhighlight>

An action handler should be able to handle being called with either a WML table or a WML vconfig userdata. It is recommended to pass the argument through ''wml.tovconfig'' before doing anything with it, both in the action's definition and when calling it directly (in case its definition did not do that). The engine always passes a vconfig when calling a WML action.

=== wesnoth.wml_conditionals ===

* {{LuaGameOnly}} '''wesnoth.wml_conditionals'''.''action'' ↔ '''function'''(''wml parameters table'') → ''boolean result''

This is a hook table like wesnoth.wml_actions. You can use it to define new ConditionalWML tags that will be recognized in WML when using [if], [show_if], [while], etc., or more generally when [[../wml#wml.eval_conditional|'''wml.eval_conditional''']] is run.

Use it like this:

<syntaxhighlight lang=lua>
function wesnoth.wml_conditionals.foo(cfg)
local bar = cfg.bar or wml.error("[foo] tag did not have 'bar' attribute")

return (bar == "baz")
end
</syntaxhighlight>

If this lua code is executed, it would make the following syntax be valid WML in your add-on:

<syntaxhighlight lang=wml>
[if]
[foo]
bar = $X
[/foo]
[then]
[message]
# ...
[/message]
[/then]
[/if]
</syntaxhighlight>

Note that the basic logic tags of ConditionalWML (true, false, and, or, not) do not pass through this table and cannot be overridden.

=== wesnoth.effects ===

* {{LuaGameOnly}} '''wesnoth.effects'''.''name'' ↔ '''function'''(''unit'', ''wml table'')
* {{LuaGameOnly}} '''wesnoth.effects'''.''name''.'''__descr''' ↔ ''description''
* {{LuaGameOnly}} '''wesnoth.effects'''.''name''.'''__descr''' ↔ '''function'''(''unit'', ''wml table'') → ''description''

This table contains the implementation of [[EffectWML|[effect]]]s. Each value is a callable value that takes a unit and the effect config. It can be a function or a callable table. If it is a callable table, its metatable may have a '''__descr''' field which is either a string or a function. Built-in effects are present in this table, and you may register your own custom effects too.

<syntaxhighlight lang='lua'>
function wesnoth.effects.min_resistance(u, cfg)
local resistance_new = {}
local resistance_old = wml.parsed(wml.get_child(cfg, "resistance"))
for k,v in pairs(resistance_old) do
if type(k) == "string" and type(v) == "number" and u:resistance_to(k) >= v then
resistance_new[k] = v
end
end
wesnoth.effects.resistance(u, {
apply_to = "resistance",
replace = true,
T.resistance (resistance_new),
})
end
</syntaxhighlight>

The code above adds a new <code>min_resistance</code> effect that will set the resistances to specific values if they are currently below that value. It can then be used like this (for example, in [[DirectActionsWML#.5Bobject.5D|[object]]]):

<syntaxhighlight lang='wml'>
[effect]
apply_to=min_resistance
[resistance]
cold=50
[/resistance]
[/effect]
</syntaxhighlight>

Note that in order work properly, effects must be registered before any units are created. This means it must be placed into a global or scenario level [lua] tag. In particular, the preload event is too late.

You can also specify description modifiers, which will be used if a custom effect is placed in a <code>[trait]</code> tag. Instead of setting a function as the effect, you set a table with a <code>__call</code> metafunction which does what the function would have done. The table can then have an additional <code>__descr</code> metafunction which updates descriptions as necessary. The built-in effects all use this structure. This metafunction takes the same arguments as the regular effect function, but should not modify the unit. Instead, it returns a string to be appended to the trait's effect description.

=== wesnoth.micro_ais ===

* {{LuaGameOnly}} '''wesnoth.micro_ais'''.''ai_name'' ↔ ''function''(''cfg'') → ''required'', ''optional'', ''ca_params''

Registers a new [[Micro_AIs#Custom_Micro_AIs|MicroAI]] with '''ai_type'''=''ai_name''. The function will be called by the [micro_ai] tag to set up the AI. See the link for more details on how this works.

=== wesnoth.custom_synced_commands ===

* {{LuaGameOnly}} '''wesnoth.custom_synced_commands'''.''command_name'' ↔ ''function''(''cfg'')

Registers a custom synced command, which can be invoked by AI to enable unusual behaviour. The command can do basically anything, and is guaranteed to run on all clients. The WML table passed to the callback is the same table passed to [[LuaAPI/wesnoth/sync#wesnoth.sync.invoke_command|wesnoth.sync.invoke_command]].

== Data ==

Access to most of the game data is available via various tables in the <tt>wesnoth</tt> module.

=== wesnoth.colors ===

{{DevFeature1.15|4}}

* {{LuaGameOnly}} '''wesnoth.colors'''.''color_name'' → ''color info''

Access defined [[GameConfigWML#Color_Palettes|color ranges]]. This can be used to translate the color name available from '''wesnoth.sides[n].color''' to RGB values.

Each color info table contains the following keys:

* '''mid''' - average shade for recoloring with the team color
* '''min''' - minimum shade for recoloring with the team color (this is likely to be black)
* '''max''' - maximum shade for recoloring with the team color (this is likely to be almost white)
* '''minimap''' - representative color to use on the mini-map
* '''pango_color''' - {{DevFeature1.15|13}} a hex string such as '''#ff0000''' suitable for use in formatted text

Each of '''mid''', '''min''', '''max''' and '''minimap''' have the following keys:

* '''r''' - red component of that color
* '''g''' - green component of that color
* '''b''' - blue component of that color
* '''a''' - alpha component of that color (probably fully opaque)

Reference usage in mainline: see data/multiplayer/eras.lua

=== wesnoth.current ===

Contains various information about the current game and event state.

* {{LuaGameOnly}} '''wesnoth.current.side''' → ''side number''

The number of the currently active side.

* {{LuaGameOnly}} '''wesnoth.current.turn''' → ''turn number''

The current turn number.

* {{LuaGameOnly}} '''wesnoth.current.synced_state''' → ''state''

Allows you to determine whether the current code runs in a synced context. Returns one of the following strings:

:* '''synced''' - The current code runs on all mp clients. This is the normal context, in which all gamestate changing actions should take place.
:* '''unsynced''' - The current code runs only on the local machine, so changing the gamestate here will cause out-of-sync errors. For example, during '''select''' events or during the calculation of a [[LuaAPI/wesnoth/interface#wesnoth.interface.game_display|game_display]] hook. Typical things to do here are UI related things, or entering the synced state via '''[do_command]'''.
:* '''local_choice''' - The current code was invoked by [[#wesnoth.synchronize_choice|synchronize_choice]] and runs only on one local client to calculate the return value for the choice. You cannot enter the synced context with '''[do_command]''' now.
:* '''preload''' - We are currently running a preload event or an even earlier event. This behaves similar to '''local_choice'''.

* {{LuaGameOnly}} '''wesnoth.current.user_can_invoke_commands''' → ''boolean''

Indicates whether the player is currently able to take actions in the game.

* {{LuaGameOnly}} '''wesnoth.current.map''' → ''map userdata''

The current active game map. See [[LuaAPI/types/map]] and [[LuaAPI/wesnoth/map]] for information on how this data can be used.

* {{LuaGameOnly}} '''wesnoth.current.schedule''' → ''schedule userdata''

The current global time schedule. This is a special object with the following properties:

:* #''schedule''
:The Lua length operator will return the number of turns in the schedule.

:* ''schedule''[''index''] ↔ ''time of day info''
:Get the information for a particular time of day, or replace it with new info.

:* ''schedule''.'''time_of_day''' ↔ ''id''
:Get the ID of the current active time of day, or switch to a new one. If the time of day occurs more than once in the schedule, the time will be set to the first occurrence.

:* ''schedule''.'''liminal_bonus''' ↔ ''bonus''
:Get the maximum bonus for liminal units in the current schedule. You can also override the default by assigning a different value, or revert to the default by assigning nil.

* {{LuaGameOnly}} '''wesnoth.current.event_context''' → ''table''

Contains information on the current active event. Returns a table with the following keys:

:* '''name''' - The event name. This is the actual event that fired, not the name in the [event] tag, so it never contains commas or variables.
:* '''id''' - The event's unique ID, if it has one.
:* '''weapon''' - The first weapon relevant to the event, if any.
:* '''second_weapon''' - The second weapon relevant to the event, if any.
:* '''damage_inflicted''' - The damage inflicted in the event, if applicable.
:* '''x1''', '''y1''' - The first location relevant to the event, if any.
:* '''x2''', '''y2''' - The second location relevant to the event, if any.
:* '''unit_x''', '''unit_y''' - The location of the first unit relevant to the event, if any. This is the same as '''x1''', '''y1''' in most cases. Currently the only exceptions are enter and exit hex events.
:* '''data''' - {{DevFeature1.17|6}} The event data. Can contain anything at all if the event was fired by [[LuaAPI/wesnoth/game_events#wesnoth.game_events.fire|wesnoth.game_events.fire]]. In a village capture event, '''owner_side''' will contain the former owner of the village.

=== wesnoth.game_config ===

Contains static global information about the game. Some of this information can also be modified on the fly, but only in the game context, not in the plugin or map generator context.

* '''wesnoth.game_config.base_income''' ↔ ''integer''
* '''wesnoth.game_config.village_income''' ↔ ''integer''
* '''wesnoth.game_config.village_support''' ↔ ''integer''
* '''wesnoth.game_config.poison_amount''' ↔ ''integer''
* '''wesnoth.game_config.rest_heal_amount''' ↔ ''integer'
* '''wesnoth.game_config.recall_cost''' ↔ ''integer''
* '''wesnoth.game_config.combat_experience''' ↔ ''integer''
* '''wesnoth.game_config.kill_experience''' ↔ ''integer''

Values of various game settings.

* '''wesnoth.game_config.global_traits'''[''trait id''] →

A table with named fields (trait id strings) holding the wml tables defining the traits. This contains all global traits the engine knows about, but race-specific traits are not included. The known fields and subtags of each element are the ones which were given in the wml definition of the [[SingleUnitWML|trait]].

<syntaxhighlight lang=lua>
print(wesnoth.game_config.global_traits.strong.male_name)
</syntaxhighlight>

* {{LuaGameOnly}} '''wesnoth.game_config.do_healing''' ↔ ''boolean''

Whether healing will occur at the beginning of each side's turn.

* {{LuaGameOnly}} '''wesnoth.game_config.theme''' ↔ ''theme id''

The currently active in-game theme.

* '''wesnoth.game_config.debug''' → ''boolean''

Whether debug mode is currently active. Debug mode is activated by the --debug command-line parameter or the :debug in-game command.

* '''wesnoth.game_config.debug_lua''' → ''boolean''

Whether Lua debug is enabled. Lua debug is activated by the --debug-lua command-line parameter. This does not seem to do anything by default.

* '''wesnoth.game_config.mp_debug''' → ''boolean''

Whether MP debug is enabled. MP debug is activated in the same way as debug mode, but is only active in multiplayer games.

* '''wesnoth.game_config.strict_lua''' → ''boolean''

Whether strict Lua mode is enabled. Strict Lua mode is activated by the --strict-lua command-line parameter and causes all deprecated Lua APIs to be completely removed from the engine.

=== wesnoth.races ===

* {{LuaGameOnly}} '''wesnoth.races'''.''id'' → ''race info''

Access defined [[UnitsWML#.5Brace.5D|races]]. Returns a [[LuaAPI/types#Race|race userdata]].

=== wesnoth.scenario ===

Contains information about the current scenario

* {{LuaGameOnly}} '''wesnoth.scenario.turns''' ↔ ''turn limit''

The current turn limit of the scenario.

* {{LuaGameOnly}} '''wesnoth.scenario.next''' ↔ ''scenario id''

The ID of the scenario to transition to when this scenario ends.

* {{LuaGameOnly}} '''wesnoth.scenario.id''' → ''scenario id''

The ID of the current scenario.

* {{LuaGameOnly}} '''wesnoth.scenario.name''' →

The name of the current scenario.

* {{LuaGameOnly}} '''wesnoth.scenario.defeat_music''' ↔ ''list of music tracks''

The music to play if you lose this scenario.

* {{LuaGameOnly}} '''wesnoth.scenario.victory_music''' ↔ ''list of music tracks''

The music to play if you win this scenario.

* {{LuaGameOnly}} '''wesnoth.scenario.show_credits''' ↔ ''boolean''

Whether credits should be shown when this scenario ends. Only relevant if '''wesnoth.scenario.next''' is nil.

* {{LuaGameOnly}} '''wesnoth.scenario.end_text''' ↔ ''text''

The end text to show when the scenario ends. Only relevant if '''wesnoth.scenario.next''' is nil.

* {{LuaGameOnly}} '''wesnoth.scenario.end_text_duration''' ↔ ''duration''

How long to show the end text for when the scenario ends. Only relevant if '''wesnoth.scenario.next''' is nil.

* {{LuaGameOnly}} '''wesnoth.scenario.difficulty''' → ''difficult''

The difficulty level this scenario is being played on.

* {{LuaGameOnly}} '''wesnoth.scenario.type''' → ''tag name''

The type of this scenario. One of the strings '''scenario''', '''multiplayer''', or '''test'''.

* {{LuaGameOnly}} '''wesnoth.scenario.era''' → ''era tag''

The [era] tag active in this scenario. Accessing this will throw an error in single-player games.

* {{LuaGameOnly}} '''wesnoth.scenario.campaign''' → ''campaign tag''

The [campaign] tag active in this scenario. Accessing this will throw an error in multiplayer or test games, so be sure to check '''wesnoth.scenario.type''' first in generic code.

* {{LuaGameOnly}} '''wesnoth.scenario.resources''' → ''list of resource tags''

A list of [resource] tags active in this scenario.

* {{LuaGameOnly}} '''wesnoth.scenario.modifications''' → ''list of modification tags''

A list of [modification] tags active in this scenario.

* {{LuaGameOnly}} '''wesnoth.scenario.mp_settings''' → ''table''

In a multiplayer game, this is a proxy table which gives read only access to all MP-only configuration options which appear as attributes of [multiplayer] tag in a save game file. This allows accessing basically everything that can be set in the create game screen. The following keys exist in the returned table:

* '''active_mods''' - A list of all active modification IDs
* '''hash''' - A hash of mp data
* '''mp_campaign''' - Name of mp campaign
* '''mp_scenario''' - ID of this mp scenario
* '''mp_scenario_name''' - Name of this mp scenario
* '''scenario''' - MP lobby title
* '''difficulty_define''' - The campaign difficulty string for an mp campaign
* '''mp_village_gold'''
* '''mp_village_support'''
* '''mp_num_turns'''
* '''mp_era''' - The id of the chosen era
* '''mp_eras''' - A list of all era ids
* '''mp_fog'''
* '''mp_shroud'''
* '''mp_random_start_time'''
* '''experience_modifier'''
* '''mp_use_map_settings'''
* '''mp_countdown''' - Whether the timer is enabled
* '''mp_countdown_action_bonus'''
* '''mp_countdown_init_time'''
* '''mp_countdown_reservoir_time'''
* '''mp_countdown_turn_bonus'''
* '''observer'''
* '''shuffle_sides'''
* '''savegame''' - Whether this is a reloaded game
* '''side_users''' - List of how sides are assigned to users (at game start)

=== wesnoth.terrain_types ===

{{DevFeature1.15|12}}

* {{LuaGameOnly}} '''wesnoth.terrain_types'''[''code''] → ''terrain info''

Access defined [[TerrainWML|terrain types]] by their terrain code. Returns a table with the following keys:

* '''id'''
* '''name'''
* '''editor_name'''
* '''description'''
* '''icon'''
* '''editor_image'''
* '''light'''
* '''village'''
* '''castle'''
* '''keep'''
* '''healing'''

=== wesnoth.unit_types ===

* {{LuaGameOnly}} '''wesnoth.unit_types'''[''id''] → ''unit type info''

Access defined [[UnitTypeWML|unit types]] by their ID. Returns a [[LuaAPI/types#Unit_Type|unit type userdata]].

== Submodules ==

The <tt>wesnoth</tt> module also contains a number of submodules for working with particular aspects of the game.

=== wesnoth.audio ===

A [[LuaAPI/wesnoth/audio|submodule]] containing functions for playing music and sound effects.

=== wesnoth.achievements ===

A [[LuaAPI/wesnoth/achievements|submodule]] containing functions for working with in-game achievements.

=== wesnoth.game_events ===

A [[LuaAPI/wesnoth/game_events|submodule]] containing functions for working with event handlers.

=== wesnoth.map ===

{{DevFeature1.15|11}}

A [[LuaAPI/wesnoth/map|submodule]] containing functions for querying and manipulating the game map.

=== wesnoth.interface ===

{{DevFeature1.15|0}}

A [[LuaAPI/wesnoth/interface|submodule]] containing functions pertaining to the in-game UI.

=== wesnoth.paths ===

{{DevFeature1.15|0}}

A [[LuaAPI/wesnoth/paths|submodule]] containing functions related to pathfinding.

=== wesnoth.schedule ===

{{DevFeature1.15|14}}

A [[LuaAPI/wesnoth/schedule|submodule]] containing functions to manipulate the time of day schedule.

=== wesnoth.sides ===

{{DevFeature1.15|3}}

A [[LuaAPI/wesnoth/sides|submodule]] containing functions for manipulating the sides of a scenario.

=== wesnoth.sync ===

{{DevFeature1.15|14}}

A [[LuaAPI/wesnoth/sync|submodule]] containing functions to deal with multiplayer synchronization.

=== wesnoth.units ===

{{DevFeature1.15|0}}

A [[LuaAPI/wesnoth/units|submodule]] containing functions to manipulate units on the map.

[[Category: Lua Reference]]

== Unsupported Functions ==

The following functions exist in the '''wesnoth''' module but are not intended to be used:

* wesnoth.allow_undo
* wesnoth.cancel_action
* wesnoth.clear_menu_item
* wesnoth.set_menu_item
* wesnoth.kernel_type
* wesnoth.log_replay
* wesnoth.print
* wesnoth.redraw
* wesnoth.add_known_unit
* wesnoth.get_era
* wesnoth.get_resource

Some of these have WML equivalents, so if you need the functionality you should call the WML action directly (via [[#wesnoth.wml_actions|wml_actions]] or [[LuaAPI/wml#wml.fire|wml.fire]]). Others are internal functionality used in core Lua scripts, which are not intended for general use. These functions ''may'' be removed or changed without warning or going through a deprecation cycle.

Examination of the '''wesnoth''' module will also reveal two additional subtables - the '''package''' table, which is where packages loaded by [[#wesnoth.require|wesnoth.require]] persist (meaning you can force '''wesnoth.require''' to reload a file by nulling out its entry in this table), and the '''experimental''' module, which contains functions that are available for use but without warranty - they may change without warning or going through a deprecation cycle. Use of both of these tables is unsupported.

TerrainWML

2024-01-04T14:04:06Z

Dwarftough: /* the toplevel [terrain_type] tag */

{{WML Tags}}
== the toplevel [terrain_type] tag ==

The [terrain_type] tag describes a terrain in WML.
Terrains are usually described in the terrain.cfg file

the [terrain_type] tag has the following keys and subtags
* '''symbol_image''': an image used for this terrain in the minimap
* '''editor_image''': an image used for this terrain in the map editor; if not defined uses symbol_image. This image will also be displayed in the help page for this terrain.
* '''icon_image''': an image used for this terrain to indicate defence/movement; shown in the help, and in the sidebar when the terrain is highlighted
* '''id''': a non-translatable string identifying this terrain. It is used as the key for attributes in some parts of WML, such as {{tag|UnitsWML|movetype}} (but see also the aliasof= attribute below; not all ids need to be listed under movetypes).
* '''name''': the name of the terrain, a translatable string used for the display of terrain type in the game and the map editor
* '''description''': the detailed description of the terrain, a translatable string used for the display of terrain type in the game and the map editor. If this is not present, the game and editor will fall back to the '''name''' attribute. The difference is that the name tends to describe the game effect of the terrain type (e.g., "Forest") but the description attribute also carries information about visual subtype (e.g. "Summer Deciduous Forest").
* '''editor_name''': a detailed name for the terrain used only in the map editor. Terrains are presented in the editor as "''<editor_name>''/''<name>'' (''<aliases>'')" when this attribute is used.
* '''string''': this is the string that represents the terrain in maps and scenarios
* '''unit_height_adjust''': how much the unit graphic should be moved up or down when on that terrain
* '''submerge''': float, between 0 and 1: specifies how much of the unit graphic should be submerged by the terrain
* '''light''': signed value: this will modify the local light level on that hex by that amount for gameplay.
* '''max_light''': signed value: this is the maximum local light level that may be indicated by light=. Defaults to the value of light= and is effectively overridden by the time-of-day lighting, if that is higher. If this is higher than the time-of-day lighting then the local light level can stack in addition to the TOD light - for example, lava (light=25, max_light=35) provides a 35% boost for lawful units at daytime.
* '''min_light''': signed value: this is the minimum local light level that may be indicated by light=. Defaults to the value of light= and is effectively overridden by the time-of-day lighting, if that is lower.
* '''heals''': positive value: the amount of HP a unit on this terrain will be healed at the start of every turn.
* '''gives_income''': if set to true, this terrain will give income every turn when flagged, as if it were a village
* '''recruit_onto''': if set to true, it is possible to recruit or recall on that terrain
* '''recruit_from''': if set to true it is possible to recruit when a unit that can recruit is on that terrain
* '''aliasof''': comma separated string of terrains of which this terrain will be an alias. This is a list of terrains, with + and - signs having special meanings. The string is read left to right taking the best value until a minus sign is encountered, after which it takes the worst value instead. The plus sign reverts to best value. (Note: after a + or - a comma is also required. In order to include a + sign the entire line must be placed between double quotes.)
* '''def_alias''': like ''aliasof'' but overides it for defense calculation only
* '''mvt_alias''': like ''aliasof'' but overides it for movement calculation only
* '''vision_alias''': has no effect, see [https://github.com/wesnoth/wesnoth/pull/4278 PR #4278].
* '''income_description''': for terrains with ''gives_income'' and owned by nobody this text is shown in the terrain description in the top bar before the brackets. This tag is optional, if not supplied Wesnoth will assume the terrain is a village and sets an appropriate message.
* '''income_description_ally''': like ''income_description'' but if owned by an ally
* '''income_description_enemy''': like ''income_description'' but if owned by an enemy
* '''income_description_own''': like ''income_description'' but if owned by yourself
* '''editor_group''': a comma separated list of editor_group ids to which this terrain belongs (about editor groups see https://wiki.wesnoth.org/EditorWML#The_.5Beditor_group.5D_tag )
* '''help_topic_text''': a long description, which will be shown as part of the help page for this terrain.
* '''hide_if_impassable''':
* '''hidden''': (boolean) if set to 'yes', makes this terrain not appear in the map editor palettes. A side effect of setting this is that the editor_image will be empty.
* '''hide_help''': (boolean) if set to 'yes', makes this terrain not appear in the terrain help browser.

== See Also ==

* [[ReferenceWML]]
* [[TerrainCodesWML]]
* [[EditorWML]]

[[Category: WML Reference]]

DirectActionsWML

2023-09-03T11:49:51Z

Dwarftough: /* [replace_schedule] */

{{WML Tags}}
== Direct actions ==

Direct actions are actions that have a direct effect on gameplay. They can be used inside of [[EventWML|events]].

The following tags are actions:

=== [endlevel] ===
Ends the scenario.
* '''result''': before the scenario is over, all events with ''name=result'' are triggered. If ''result=victory'', the player progresses to the next level (i.e., the next scenario in single player); if ''result=defeat'', the game returns to the main menu.

When the result is "victory" the following keys can be used:
* '''bonus''': whether the player should get bonus gold (maximum possible gold that could have been earned by waiting the level out). The default is bonus=yes. {{DevFeature1.13|2}} Alternatively, a number, defining the bonus multiple (1.0 meaning full).
* '''carryover_report''': whether the player should receive a summary of the scenario outcome, the default is carryover_report=yes.
* '''save''': whether a start-of-scenario save should be created for the next scenario, the default is save=yes. Do not confuse this with saving of replays for the current scenario.
* '''replay_save''': whether a replay save for the current scenario is allowed, the default is replay_save=yes. If yes, the player's settings in preferences will be used to determine if a replay is saved. If no, will override and not save a replay.
* '''linger_mode''': If ...=yes, the screen is greyed out and there's the possibility to save before advancing to the next scenario, the default is linger_mode=yes.
* '''reveal_map''': (Multiplayer only) (Default is 'yes') If 'no', shroud doesn't disappear when game ended.
* '''next_scenario''': (default specified in '''[scenario]''' tag) the ID of the next scenario that should be played. All units that side 1 controls at this point become available for recall in ''next_scenario''.
* '''carryover_percentage''': by default 80% of the gold is carried over to the next scenario, with this key the amount can be changed.
* '''carryover_add''': if yes the gold will be added to the starting gold the next scenario, if no the next scenario will start with the amount of the current scenario (after taxes) or the minimum in the next scenario. Default is no.
* '''music''': (default specified in '''[scenario]''' or '''[game_config]''' tags) a comma-separated list of music tracks from which one will be chosen and played once after any events related to the end of level result are executed; by default, victory_music is used on victory, and defeat_music on defeat.
* '''end_credits''': Whether to display the credits screen at the end of a single-player campaign. Defaults to ''yes''. Note that this has cumulative effects over the campaign - it persists even if the endlevel does not trigger the end of the campaign. See also [[CampaignWML]].
* '''end_text''': (translatable) Text that is shown centered in a black screen at the end of a campaign. Defaults to "The End". Note that this has cumulative effects over the campaign - it persists even if the endlevel does not trigger the end of the campaign. See also [[CampaignWML]].
* '''end_text_duration''': Delay, in milliseconds, before displaying the game credits at the end of a campaign. In other words, for how much time '''end_text''' is displayed on screen. Defaults to 3500. Note that this has cumulative effects over the campaign - it persists even if the endlevel does not trigger the end of the campaign. See also [[CampaignWML]].
* <strike>'''[next_scenario_settings]''': Any tags or attribute children of this optional argument to [endlevel] are merged into the scenario/multiplayer tag of the *next* scenario. This allows you to e.g. reconfigure the [side] tags or settings, just before load. </strike> This feature was removed in 1.11.17, it might be redesigned and reintroduced.
* <strike>'''[next_scenario_append]''': Any tags of this optional argument are appended at high level to the next scenario. This is most appropriate for [event] tags, although you may find other uses. Example test scenario for these features: https://gna.org/support/download.php?file_id=20119 </strike> This feature was removed in 1.11.17, it might be redesigned and reintroduced.
* '''[result]''' {{DevFeature1.13|0}} Allows specification of a side specific result, this is for competitive multiplayer scenarios/campaigns where it might happen that one player wins but another player loses. The following attributes are accepted and have the same effect as in '''[endlevel]''':
** '''result'''
** '''bonus'''
** '''carryover_percentage'''
** '''carryover_add'''

And there is also
** '''side''' The number of the side for which these results should apply.

=== [unit] ===
Creates a unit (either on the map, on a recall list, or into a variable for later use.) For syntax see [[SingleUnitWML]].
* {{Short Note:Predefined Macro|GENERIC_UNIT}}

This tag can also recall an existing unit, which happens when:
* the '''id=''' attribute is used
* a unit with that '''id=''' already exists
* (might be unnecessary) the existing unit is on the side's recall list
in this case, the unit is recalled at the '''x,y=''' or '''location_id=''' given, and any other data in the tag is ignored.

Campaign authors: a usual way to recall plot-necessary heroes is to use a macro with the data for creating that hero. This helps during debugging, because you can skip to scenarios and the recall-or-create functionality means that any units which are normally met in a previous scenario are automatically created (otherwise some scenarios may be an instant loss). This can only be used for units that must survive the previous scenarios, as it would recreate units if they died in a previous scenario.
For example,
[https://github.com/wesnoth/wesnoth/blob/1.14.7/data/campaigns/Heir_To_The_Throne/utils/httt_utils.cfg#L685 HttT's NEED_DELFADOR macro].

=== [recall] ===
Recalls a unit taking into account any [[SingleUnitWML|filter_recall]] of the leader. The unit is recalled free of charge, and is placed near its leader, e.g., if multiple leaders are present, near the first found which would be able to normally recall it.

If neither a valid map location is provided nor a leader on the map would be able to recall it, the tag is ignored.

* [[StandardUnitFilter]]: the first matching unit will be recalled. If no units match this tag is ignored. Do not use a [filter] tag. If a comma separated list is given, every unit currently considered for recall is checked against all the types (not each single one of the types against all units).
* '''x,y''': the unit is placed here instead of next to the leader.
* '''location_id''': {{DevFeature1.15|0}} the name of a special map location to recall to. Used instead of '''x,y'''.
* '''show''': yes/no, default yes: whether the unit is animated (faded in) or instantly displayed
* '''fire_event''': boolean yes|no (default no); whether any according prerecall or recall events shall be fired.
* '''check_passability''': (boolean yes|no, default yes): If yes, checks for terrain passability when placing the unit (a nearby passable hex is chosen).
* '''[secondary_unit]''': {{DevFeature1.13|?}} If present and show=yes, a matching unit will be chosen and their recruiting animation played.

=== [teleport] ===
Teleports a unit on map. {{Short Note:Predefined Macro|TELEPORT_UNIT}}
* '''[filter]''': [[StandardUnitFilter]] the first unit matching this filter will be teleported.
* '''x,y''': the hex to teleport to. If that hex is occupied, the closest unoccupied hex will be used instead.
* '''location_id''': {{DevFeature1.15|0}} the name of a special map location to teleport to. Used instead of '''x,y'''.
* '''clear_shroud''': should shroud be cleared on arrival
* '''animate''': should a teleport animation be played (if the unit doesn't have a teleport animation, it will fade out/fade in)
* '''check_passability''': (boolean yes|no, default yes): normally, units will not be teleported into terrain that is impassable for them. Setting this attribute to "no" permits it.

(Note: There is also a ability named teleport, see [[AbilitiesWML]].)

=== [terrain_mask] ===
Changes the terrain on the map. See [[TerrainMaskWML]].

=== [terrain] ===
Changes the terrain on the map.
* '''terrain''': the character of the terrain to use. See [[TerrainCodesWML]] to see what letter a type of terrain uses.
* [[StandardLocationFilter]]. This [[StandardLocationFilter]]'s terrain= key is used for the new terrain, filtering by terrain can be done with a nested [[StandardLocationFilter]]: [and]terrain=terrain_string_to_be_filtered_for.
* '''layer''': (overlay|base|both, default=both) only change the specified layer.
* '''replace_if_failed''': (default=no) When replacing just one layer failed, try to replace the whole terrain. If '''terrain''' is an overlay only terrain, use the default_base as base layer. If the terrain has no default base, do nothing.
* '''location_id''': This key sets a string as a way to mark the hex or hexes for later reference. It is very similar to the leader starting position, and can also be set that way in the map editor.

If you want to remove the overlays from a terrain and leave only the base, use:
layer=overlay
terrain="^"

<b>Note:</b> When a hex changes from a village terrain to a non-village terrain, and a team owned that village it loses that village. When a hex changes from a non-village terrain to a village terrain and there is a unit on that hex it does not automatically capture the village. The reason for not capturing villages is that there are too many choices to make; should a unit lose its movement points, should capture events be fired. It is easier to do this as wanted by the author in WML.

=== [gold] ===
Gives sides gold.
* '''amount''': the amount of gold to give.
* '''side''': (default=1) the number of the side to give the gold to. Can be a comma-separated list of sides. note: Default side=1 for empty side= is deprecated.
* [[StandardSideFilter]] tags and keys; default for empty side= is all sides, as usual in a SSF.

=== [unstore_unit] ===
Creates a unit from a game variable, and activates it on the playing field or recall list. This must be a specific variable describing a unit, and may not be an array (if it is, only the first unit will be unstored).

This may be useful in different contexts:
* To update a unit on the map after having edited its WML. This usage is common, but discouraged - if possible, you should use [[#.5Bmodify_unit.5B|[modify_unit]]] or [[#.5Bobject.5B|[object]]] instead.
* To place a previously-defined unit into the scenario, if it was directly defined in a WML variable, using [unit] with the key '''to_variable'''. This usage is rather uncommon.
* To place a unit back into the game that was removed earlier, for example a hero that leaves the party for awhile and then comes back.

The variable is not cleared. To unstore units from an array variable, iterate over the array. See [[SyntaxWML]] and [[VariablesWML/How to use variables]] for more information about variable usage. See also [[InternalActionsWML#.5Bstore_unit.5D|[store_unit]]], [[ConditionalActionsWML|For]], [[ConditionalActionsWML#.5Bwhile.5D|[while]]] and [[InternalActionsWML#.5Bclear_variable.5D|[clear_variable]]].

The tag takes the following keys:
* '''variable''': This is required to indicate the name of the variable to read the unit from.
* '''Placement keys''':
** '''x''' ,'''y''': By default, the unit will be placed at the location specified in the variable, but if these keys are present, the unit will be placed at that location instead. To place the unit on the recall list of its side, use '''x,y=recall,recall'''. (If you want to change the said, you need to first update ''$unit.side'' in the variable before unstoring.)
** '''location_id''': {{DevFeature1.15|0}} The name of a special map location to unstore to. Used instead of '''x,y'''.
** '''find_vacant''' (yes|no, default no): Whether the unit should be placed on the nearest vacant tile to its specified location. If this is set to 'no' (default), then any unit on the same tile as the unit being unstored will be destroyed.
** '''check_passability''' (yes|no, default yes): Only relevant if '''find_vacant=yes'''. In that case, this determines whether game will try to find a passable tile for the unit. If set to no, the unit may be placed on an impassable tile. Note that if both '''find_vacant''' and '''check_passability''' are set, then the unit's position may be shifted even if there is not a unit on the target space, if that space is not passable for the unit.
* '''Animation keys''' (these determine the visual effect of how the unit is placed or updated):
** '''text''': (translatable) A floating text to display above the unit, such as a damage amount.
** '''male_text''', '''female_text''': {{DevFeature1.13|2}} (translatable) gender-specific versions of the above
** '''red''', '''green''', '''blue''': (default=0,0,0) the color of the text. Values vary from 0-255. You may find it convenient to use the {COLOR_HARM} or {COLOR_HEAL} macro instead. (Use {COLOR_HARM} or {COLOR_HEAL} instead of the whole red,green,blue= line.)
** '''animate''': (boolean yes|no, default yes) Determines whether to play any animations associated with the unstore. Currently this only affects the advancement animation ("levelout" and "levelin", defaulting to a fade to white and back) if the unit ends up advancing.
* '''Side-effect keys''' (these directly modify the behaviour of the action):
** '''advance''': (default=yes) if yes the unit is advanced if it has enough XP. When modifying XP, make sure to do it from inside a [[EventWML#Multiplayer_safety|synchronized event]] or it may lead to OOS errors, especially when several advancement paths exist. Note that advance and post advance events are called, so infinite loops can happen.
** '''fire_event''' (yes|no, default no): Whether any advance/post advance events shall be fired if an advancement takes place. This also affects whether the unit placed event is fired.

Units can be unstored with negative (or zero) hit points. This can be useful if modifying a unit in its last_breath event (as the unit's death is already the next step), but tends to look wrong in other cases. In particular, it is possible to have units with negative hit points in play. Such units are aberrations, subject to unusual behavior as the game compensates for them. (For example, such units are currently automatically hit–and killed–in combat.) The details of the unusual behavior are subject to change between stable releases without warning.

=== [allow_recruit] ===
Allows a side to recruit units it couldn't previously recruit. Any leader on this side will now be able to recruit the new units.
* '''type''': the types of units that the side can now recruit.
* '''side''': (default=1) the number of the side that is being allowed to recruit the units. This can be a comma-separated list note: Default side=1 for empty side= is deprecated.
* [[StandardSideFilter]] tags and keys; default for empty side= is all sides, as usual in a SSF.

=== [allow_extra_recruit] ===
Allows a leader to recruit units it couldn't previously recruit.
These types are in addition to the types the leader can recruit because of '''[side]recruit=''' and '''[allow_recruit]'''.
* '''extra_recruit''': the types of units that the leader can now recruit.
* '''[[StandardUnitFilter]]''': All units matching this filter are modified. Does not match on recall list units.

=== [disallow_recruit] ===
Prevents a side from recruiting units it could previously recruit. No leader on this side will be able to recruit the specified units anymore, unless that leader has the same unit in their personal '''extra_recruit''' list.
* '''type''': the types of units that the side can no longer recruit. {{DevFeature1.13|0}} If omitted, all recruits for matching sides will be disallowed.
* '''side''': (default=1) the number of the side that may no longer recruit the units. This can be a comma-separated list note: Default side=1 for empty side= is deprecated.
* [[StandardSideFilter]] tags and keys; default for empty side= is all sides, as usual in a SSF.

=== [disallow_extra_recruit] ===
Prevents a leader from recruiting units it could previously recruit. This won't prevent the leader from recruiting that unit if the unit is in the '''[side]recruit=''' list – you must use '''[disallow_recruit]''' in that case.
* '''extra_recruit''': the types of units that the leader can no longer recruit.
* '''[[StandardUnitFilter]]''': All units matching this filter are modified. Does not match on recall list units.

=== [set_recruit] ===
Sets the units a side can recruit. Any leader on this side will now be able to recruit these units.
* '''recruit''': the types of units that the side can now recruit.
* '''side''': The number of the side that is having its recruitment set. This can be a comma-separated list.
* [[StandardSideFilter]] tags and keys; default for empty side= is all sides, as usual in a SSF.

=== [set_extra_recruit] ===
Sets the units a leader can recruit.
These types are in addition to the types the leader can recruit because of '''[side]recruit=''' and '''[set_recruit]'''.
* '''extra_recruit''': the types of units that the leader can now recruit.
* '''[[StandardUnitFilter]]''': All units matching this filter are modified. Does not match on recall list units.

=== [modify_side] ===
Modifies some details of a given side in the middle of a scenario. '''The following listed properties are the only properties that [modify_side] can affect!'''
* '''side''': (default=1) the number of the side that is to be changed. note: Default side=1 for empty side= is deprecated.
* '''[filter_side]''' with a [[StandardSideFilter]] as argument
* '''income''': the income given at the begining of each turn.
* '''recruit''': a list of unit types, replacing the side's current recruitment list.
* '''team_name''': the team in which the side plays the scenario.
* '''user_team_name''': a translatable string representing the team's description. This has no effect on alliances. Defaults to ''team_name''.
* '''side_name''': {{DevFeature1.13|?}} a translatable string representing the side leader's description.
* '''gold''': the amount of gold the side owns.
* '''village_gold''': the income setting per village for the side.
* '''controller''': the identifier string of the side's controller. Uses the same syntax of the ''controller'' key in the [[SideWML|[side]]] tag. warning: in multiplayer, changing the controller of a side might result in OOS during some events like, for example 'side_turn_end'; see [https://github.com/wesnoth/wesnoth/issues/2563 issue #2563].
* '''fog''': a boolean string (yes/no) describing the status of Fog for the side.
* '''shroud''': a boolean string describing the status of Shroud for the side.
* '''hidden''': a boolean string specifying whether side is shown in status table.
* '''color''': a team color range specification, name (e.g. "red", "blue"), or number (e.g. "1", "2") for this side. The default color range names, numbers, and definitions can be found in data/core/team_colors.cfg.
* '''[ai]''': sets/changes AI parameters for the side. Only parameters that are specified in the tag are changed, this does not reset others to their default values. Uses the same syntax as described in [[AiWML]]. Note that [modify_side][ai] works for all simple AI parameters and some, but not all, of the composite ones. If in doubt, use [[AiWML#Adding_and_Deleting_Aspects_with_the_.5Bmodify_ai.5D_Tag|[modify_ai]]]] instead, which always works. {{DevFeature1.13|?}} If this contains an '''ai_algorithm''', the AI parameters will be reset to those of the indicated AI before adding any additional parameters included in the tag. In other words, this allows replacing the AI config rather than appending to it.
* '''switch_ai''': replaces a side ai with a new AI from specified file(ignoring those AI parameters above). Path to file follows the usual WML convention.
* '''reset_maps''': If set to "yes", then the shroud is spread to all hexes, covering the parts of the map that had already been explored by the side, including hexes currently seen. (Seen hexes will be cleared at the end of most events; they can also be manually cleared with {{tag|InterfaceActionsWML|redraw}}.) This is only effective if shroud is on, but this is evaluated after shroud= (and before shroud_data=).
* '''reset_view''': If set to "yes", then the fog of war is spread to all hexes, covering the parts of the map that had already been seen this turn by the side, including hexes currently seen, excluding hexes affected by multi-turn {{tag|DirectActionsWML|lift_fog}}. (Seen hexes will be cleared at the end of most events; they can also be manually cleared with {{tag|InterfaceActionsWML|redraw}}.) This is only effective if fog is on, but this is evaluated after fog=.
* '''share_maps''': change the share_maps side attribute. Be sure to use shroud=yes for that side and have it as an ally
* '''share_view''': change the share_view side attribute. Be sure to use fog=yes for that side and have it as an ally
* '''share_vision''': change both the above at the same time
* '''shroud_data''': changes to the side's shroud, using the same format as when defining the [side].
* '''suppress_end_turn_confirmation''': Boolean value controlling whether or not a player is asked for confirmation when skipping a turn.
* '''scroll_to_leader''': Boolean value controlling whether or not the game view scrolls to the side leader at the start of their turn when present.
* '''flag''': Flag animation for villages owned by this side (see [[SideWML|[side]]]).
* '''flag_icon''': Flag icon used for this side in the status bar (see [[SideWML|[side]]]).
* '''village_support''': The number of unit levels this side is able to support (does not pay upkeep on) per village it controls.
* '''defeat_condition''' {{DevFeature1.13|0}}: When the side is considered defeated (see [[SideWML|[side]]]).
* '''[set_variable]''', '''[clear_variable]''' {{DevFeature1.15|3}} Sets or clears a variable within the side; uses the same syntax as [[InternalActionsWML#.5Bset_variable.5D|[set_variable]]] or [[InternalActionsWML#.5Bclear_variable.5D|[clear_variable]]] in ActionWML.
* '''[variables]''' {{DevFeature1.15|3}} The contents of this tag is merged into the side's variables.

=== [modify_turns] ===
Modifies the turn limit in the middle of a scenario.
* '''value''': the new turn limit.
* '''add''': if used instead of ''value'', specifies the number of turns to add to the current limit (can be negative).
* '''current''': changes the current turn number after applying turn limit modifications, if any. It is not possible to change the turn number to exceed the turn limit (1 <= current turns <= max turns).

=== [allow_end_turn] ===
Allows human players to end their turn through the user interface if they were previously affected by the '''[disallow_end_turn]''' action. This action doesn't take any arguments.

=== [disallow_end_turn] ===
Disallows human players to end their turn through the user interface. This action doesn't require arguments.
* '''reason''' (translatable): {{DevFeature1.15|0}} Allows to optionally specify a reason.

=== [capture_village] ===
Changes the ownership of a village.
* [[StandardLocationFilter]]: all village locations matching the filter are affected.
* '''side''': the side that takes control of the village. This side needs to have a leader (canrecruit=yes). If the side key is not given, the village will become neutral (unless [filter_side] is present, in which case that side fiter decides, see below).
* '''[filter_side]''' with [[StandardSideFilter]] tags and keys as arguments; if both this tag and inline side= are present it's an error. Otherwise, the first matching side gets ownership (or the village becomes neutral if none match).
* '''fire_event''' (boolean yes|no, default: no): Whether any capture events shall be fired.

=== [kill] ===
Removes all units (including units in a recall list) that match the filter from the game.
* [[StandardUnitFilter]]: Selection criterion; do not use a [filter] tag.
* '''animate''' (default 'no'): if 'yes', displays the unit dying (fading away). {{DevFeature1.13|8}} If '''[secondary_unit]''' is given, also plays the victory animation of that unit.
* '''fire_event''' (default 'no'): if 'yes', triggers any appropriate 'die' events (See [[EventWML]]). Note that events are only fired for killed units that have been on the map (as opposed to recall list).
* '''[secondary_unit]''' with a [[StandardUnitFilter]] as argument. Do not use a [filter] tag. Has an effect only if fire_event=yes ({{DevFeature1.13|8}} or if it has a victory animation and animate=yes). The first on-map unit matching the filter becomes second_unit in any fired die and last breath events. If an on-map unit matches and if there are several units killed with a single [kill] tag, second_unit is this same unit for all of them. If no on-map unit matches or [secondary_unit] isn't present, the variable second_unit in each of the die and last breath events is always the same as the variable unit (the dying unit).
* '''[primary_attack]''' {{DevFeature1.13|8}} The attacker's weapon to use for matching the animation. Useful for example on the wose, whose death animation depends on the damage type it was killed by. If a secondary unit is specified, this is taken as a [[StandardWeaponFilter]] and used to find a matching weapon on the unit. However, if there is no secondary unit specified, it is instead treated as an [[UnitTypeWML#Attacks|weapon definition]], and the animation will be run as if an imaginary unit possessing that weapon was the attacker.
* '''[secondary_attack]''' {{DevFeature1.13|8}} Similar to the above, but for the defender's weapon. This is taken as a [[StandardWeaponFilter]] and used to find a matching weapon on the dying unit.

=== [move_unit] ===
Moves a unit along a path on the map. The path can be specified exactly, or as a series of waypoints that the unit will pass through.
* [[StandardUnitFilter]] as argument; do not use a [filter] tag. All units matching the filter are moved. If the target location is occupied, the nearest free location is chosen.
* '''to_x''' (unsigned integer): The units are moved to this x coordinate. Can be a comma-separated list, in which case the unit follows this given path during the move.
* '''to_y''' (unsigned integer): The units are moved to this y coordinate. Can be a comma-separated list.
* '''dir''' (string): {{DevFeature1.15|0}} Performs a relative movement instead of an absolute movement. For example, dir=n,n,nw will move two spaces north and then one space to the northwest. This is used instead of '''to_x''' and '''to_y'''.
* '''to_location''': {{DevFeature1.15|0}} Moves matching units to locations placed in the map editor with the "New Location" button. Can be a comma-separated list. This is used instead of '''to_x''' and '''to_y'''.
* '''check_passability''' (boolean yes|no, default yes): Whether the terrain the unit is moved to should be checked for suiting the unit. (If it does not, a nearby suitable hex is chosen.)
* '''force_scroll''': Whether to scroll the map or not even when [[InterfaceActionsWML#.5Block_view.5D|[lock_view]]] is in effect or ''Follow Unit Actions'' is disabled in ''Advanced Preferences''. Defaults to using [[InterfaceActionsWML#.5Bmove_unit_fake.5D|[move_unit_fake]]]'s default value.
* '''clear_shroud''': {{DevFeature1.15|0}} (boolean yes|no, default no) Whether to remove shroud and fog after the unit was moved, but before events are fired. It will not clear all alongside the path, only around the target destination.
* '''fire_event''' (boolean yes|no, default no): Whether any according moveto events shall be fired. The target location ($x1, $y1 in the event) may not be the same location that the unit was tried to be moved to, if the original target location is occupied or impassable.

=== [modify_ai] ===
Changes AI objects (aspects, goals, candidate actions or stages) for a specified side. See [[Modifying_AI_Components#The_.5Bmodify_ai.5D_Tag|Modifying AI Components]] for full description.

* '''action''' (string): Takes values 'add', 'change', 'delete' or 'try_delete' to do just that for the AI object.
* '''path''' (string): Describes which AI object is to be modified.
* '''[facet]''', '''[goal]''', '''[candidate_action]''' or '''[stage]''': Details about the AI object to be modified.
* [[StandardSideFilter]] tags and keys; default for empty side= is all sides, as usual in a SSF.

=== [modify_unit] ===
works similar to the MODIFY_UNIT macro.
* '''[filter]''' with a [[StandardUnitFilter]] as argument. All units matching this filter are modified. Matches on recall list units too.
* '''[object]''', '''[trait]''', {{DevFeature1.13|5}} '''[advancement]''' - The given modifications will be immediately applied to all units matching the filter. ([object] is described further [[#.5Bobject.5D|below]])
** '''delayed_variable_substitution''' {{DevFeature1.13|5}} (boolean yes|no, default no): If set to "yes", the wml block contained in this [object], [trait], or [advancement] is not variable-substituted at execution time of the event containing this [modify_unit]. You need this for any effect that uses variable substitution or when using [effect][filter] with a $this_unit. {{DevFeature1.13|9}} This is no longer needed when adding ABILITY_TELEPORT, ABILITY_LEADERSHIP or SPECIAL_BACKSTAB.
** Do not use a '''[modifications]''' tag, as this may skip some of the special-case handling for newly added objects, traits and advancements, and will potentially overwrite existing modifications.
* '''[effect]''' {{DevFeature1.13|6}} Applies the effect directly to the unit. See [[EffectWML]].
* '''[set_variable]''', '''[clear_variable]''' {{DevFeature1.15|3}} Sets or clears a variable within the unit (saved inside the unit's [variables] tag); uses the same syntax as [[InternalActionsWML#.5Bset_variable.5D|[set_variable]]] or [[InternalActionsWML#.5Bclear_variable.5D|[clear_variable]]] in ActionWML.
* Accepts generally the syntax inside of wml unit variables created by [store_unit] which can be viewed in a savefile or by using the [[CommandMode|inspect command]]. Cannot remove things or add/alter unit animations. Subtags with the same name must be written in the correct order to match them with the tag they are supposed to modify. Note that keys will be processed in arbitrary order, which may cause problems if you use formulas that depend on other formulas. To work around this you may need to use the tag twice with the same filter.
example usage (see also the test scenario):
<syntaxhighlight lang='wml'>
[modify_unit]
[filter]
x,y=38,6
[/filter]
hitpoints=10
{TRAIT_HEALTHY}
[/modify_unit]
</syntaxhighlight>

The unit which is currently modified is accessible via $this_unit, e.g. hitpoints = "$($this_unit.hitpoints / 2)" to set the hitpoints of all units to half of their particular maxima. This this_unit variable is independent from the this_unit variable available in the SUF used to determine which units to modify (first all matching units are gathered, and then all those are modified).

'''Note:''' Some some properties of the units are reset sometimes (for example when the unit advances or when [remove_object] is called), so it's usually better to change them with [object] ([object] inside [modify_unit]) than to change those properties directly via [modify_unit]. The following properties are _not_ reset in [remove_object] and are thus safe to use directly in [modify_unit]:
* '''side'''
* '''gender'''
* '''name'''
* '''canrecruit'''
* '''unrenamable'''
* '''extra_recruit'''
* '''[variables]'''
* '''facing'''
* '''x, y'''
* '''goto_x, goto_y'''
* '''hitpoints'''
* '''experience'''
* '''moves'''
* '''[status]'''
* '''attacks_left'''
* '''role'''

=== [transform_unit] ===
Transforms every unit on the map matching the filter to the given unit type. Keeps intact hit points, experience and status. If the unit is transformed to a non-living type (undead or mechanical), it will be also unpoisoned. Hit points will be changed if necessary to respect the transformed unit's maximum hit points. Regardless of anything else, the unit will be rebuilt. Thus, transforming a unit to its current type is a way to force a rebuild, for example after manually removing a modification.
* [[StandardUnitFilter]]: do not use a [filter] tag.
* '''transform_to''': the unit type in which all the units matching the filter will be transformed. If missing, the units will follow their normal advancement.

=== [petrify] ===

* [[StandardUnitFilter]] as an argument. Do not use a [filter] tag. All units matching this filter are petrified. Recall list units are included.

=== [unpetrify] ===
* [[StandardUnitFilter]] as an argument. Do not use a [filter] tag. All units matching this filter are unpetrified. Recall list units are included.

=== [object] ===
Gives some unit an object which modifies their stats in some way. This tag can also be used in places that don't support ActionWML, such as [[#.5Bmodify_unit.5D|[modify_unit]]] or [[SingleUnitWML|[unit][modifications]]]. The following is supported in all these places:
* '''[effect]''': one or more effect elements may be listed. See [[EffectWML]] for a description of [effect].
* '''duration''':
**if 'scenario', effects only last until the end of the scenario.
**if 'forever' or not set, effects never wear off.
** if 'turn', effects only last until the start of the unit's next turn (when the unit refreshes movement and attacks). (Like other start-of-turn behavior, objects with a duration of "turn" won't expire before turn 2.)
** {{DevFeature1.13|1}} if 'turn end' or 'turn_end', effects only last until the end of the unit's next turn (exactly like the slowed status).
* Other keys, such as '''id''', may be used to remove the object later, but are not used by the engine. An '''[object]''' tag can contain any arbitrary data that may be helpful to identify the object to remove later using a [[FilterWML#Filtering_on_WML_data|WML filter]].

The following is supported only when using '''[object]''' as ActionWML:
* '''id''': (Optional) By default, an object with a defined ID can only be picked up once per scenario, even if it is removed later or first_time_only=no is set for the event. You can remove this restriction by setting take_only_once=no. For filtering objects, it might be simpler to use a custom key such as item_id. The id string can contain only letters, numbers and underscores. The ID is also commonly used to manually remove the object later, for example with [[#.5Bremove_object.5D|[remove_object]]].
* '''take_only_once''': (default yes) {{DevFeature1.13|6}} If set to "no", the object's ID does not prevent it from being taken more than once.
* '''delayed_variable_substitution''' (boolean yes|no, default no): If set to "yes", the wml block contained in this [object] is not variable-substituted at execution time of the event where this [object] is within. You need this for any effect that uses variable substitution or when using [effect][filter] with a $this_unit. {{DevFeature1.13|9}} This is no longer needed when adding ABILITY_TELEPORT, ABILITY_LEADERSHIP or SPECIAL_BACKSTAB.
* '''[filter]''' with a [[StandardUnitFilter]] as argument. The first unit found that matches the filter will be given the object. Only on-map units are considered. If no unit matches or no [filter] is supplied, it tries to apply the object to the unit at the $x1,$y1 location of the event where this [object] is in. The case of no unit being at that spot is handled in the same way as no unit matching a given filter ([else] commands executed, cannot_use_message displayed). Note that units on the recall list will not be checked. To add an [object] to a unit on the recall list you have to use '''[modify_unit][object]'''.
* '''[then]''': a subtag that lets you execute actions if the filter conditions are met. The most common action that should be inside here is a '''[remove_item]''' tag, but you could probably put any tags that otherwise work in a [then] tag.
* '''[else]''': a subtag that lets you execute actions if the filter conditions are *not* met.
* '''silent''': whether or not messages should be suppressed. Default is "no". {{DevFeature1.13|2}} If no description is provided, this defaults to yes, but can still be overridden.
* '''image''': the displayed image of the object.
* '''name''': (translatable) displayed as a caption of the image.
* '''description''': (translatable) displayed as a message of the image.
* '''cannot_use_message''': (translatable) displayed instead of '''description''' if no unit passes the filter test.

=== [remove_object] ===
{{DevFeature1.13|6}}

Removes an object from matching units.

* [[StandardUnitFilter]]: All units on the map (but not the recall list) matching the filter have matching objects removed. Use no [filter] tag.
* '''object_id''': The id of the object to be removed.

Note that some unit properties are not restored ideally, e.g. current unit's health reversion might not work as expected (max_hitpoints will though). {{DevFeature1.15|0}} This was fixed.

Note that [remove_object] works the following way:

# Remove the object from the unit
# Rebuild the unit to make the changes effective.

Step 2 implies that changes done for example via [modify_unit] (or via the [store_unit] + [set_variable] + [unstore_unit] technique) will be reset if those changes change a property that is a property of the unit type. See the note under [[#.5Bmodify_unit.5D|[modify_unit]]] to get a list of properties that can safely be changed via [modify_unit].

=== [remove_trait] ===
{{DevFeature1.15|2}}

* [[StandardUnitFilter]]: All units on the map (but not the recall list) matching the filter have matching traits removed. Use no [filter] tag.
* '''trait_id''': The id of the object to be removed.

=== [remove_shroud] ===
Removes some shroud from the map for a certain side (only relevant for sides that have shroud=yes).
* '''side''': (default=1) the side for which to remove shroud. This can be a comma-separated list of sides. note: Default side=1 for empty side= is deprecated.
* '''[filter_side]''' with a [[StandardSideFilter]] as argument
* [[StandardLocationFilter]]: the range of tiles for which shroud should be removed

=== [place_shroud] ===
Places some shroud on the map for a certain side (only relevant for sides that have shroud=yes).
* '''side''': (default=1) the side for which to place shroud. This can be a comma-separated list. note: Default side=1 for empty side= is deprecated.
* '''[filter_side]''' with a [[StandardSideFilter]] as argument
* [[StandardLocationFilter]]: the range of tiles on which shroud should be placed

=== [lift_fog] ===
Lifts the fog of war from parts of the map for a certain side (only relevant for sides that have fog=yes), allowing a player to witness what occurs there even if that player has no units within vision range.
* '''[filter_side]''' with a [[StandardSideFilter]] indicating which sides should be affected.
* [[StandardLocationFilter]]: the tiles from which fog should be lifted.
* '''multiturn''': ''yes/no, default:no''. The default (not multiturn) causes fog to be removed in the same way that normal vision works; the cleared tiles will remain cleared until fog is recalculated (which normally happens when a side ends its turn). When multiturn is set to "yes", the cleared tiles remain clear until {{tag||reset_fog}} cancels the clearing. This allows tiles to remain clear for multiple turns, or to be refogged before the end of the current turn (without also refogging all tiles). Multiturn lifted fog is not shared with allies (even when share_vision=all).

=== [reset_fog] ===
The primary use of this tag is to remove multiturn lifted fog (created by {{tag||lift_fog}}), which causes the fog to reset to what it would have been had WML not interfered. (That is, hexes that a side's units could not see at any point this turn will be re-fogged, while seen hexes remain defogged.)
* '''[filter_side]''' with a [[StandardSideFilter]] indicating which sides should be affected.
* [[StandardLocationFilter]]: the fog reset will be restricted to these tiles.
* '''reset_view''': ''yes/no, default: no'' If set to "yes", then in addition to removing multiturn fog, the side's current view is canceled (independent of the SLF). This means that all hexes will become fogged for the side unless multiturn fog exists outside the tiles selected by the SLF. Normally, one would want the currently seen hexes to become clear of fog; this is done automatically at the end of many events, and it can be done manually with {{tag|InterfaceActionsWML|redraw}}.
Omitting both the SSF and the SLF would cancel all earlier uses of [lift_fog].
Additionally setting reset_view="yes" would cause the side's entire map to be fogged (unless an ally keeps hexes clear by sharing its view).

=== [allow_undo] ===
Normally when an event with a handler fires, the player's undo stack is cleared, preventing all actions performed so far from being undone. Including this tag in the event handler prevents the stack from being cleared for this reason, allowing the player to undo actions. (However, the stack might still be cleared for other reasons, such as fog being cleared or combat occurring.) In the common cases, this means '''[allow_undo]''' allows the current action to be undone even though an event was handled. There is a less common case, though — specifically when handling a menu item, where there is no current action — and in this case, '''[allow_undo]''' means merely that earlier actions can still be undone.
* Using this tag in a menu item has an additional side effect in 1.11. Starting with version 1.11.1, executing a WML menu item normally counts as doing something as far as the "you have not started your turn yet" dialog is concerned. However, a menu item whose handler includes '''[allow_undo]''' will not count.

The types of actions that can be undone are movement, recalling, and dismissing a unit from the recall list. If an action is undone, only the position (or existence) of the involved unit will be restored; any altered variables or changes to the game will remain changed after the action is undone. It is up to the scenario designer to avoid abusing this command.
* Technically, if '''[allow_undo]''' is inside an '''[event]''' with ''first_time_only=yes'' (the default setting), and the user undoes the event, then the state of the game has changed in this way: the event will not fire a second time, even though the user undid the action the first time.
* Although recalling can be undone, recruitment can not be undone; this seems to apply even when the recruit's traits are not randomly-generated (tested on 1.12.6 and 1.14.4+dev).

If an '''[event]''' uses both '''[allow_undo]''' and [[InternalActionsWML#.5Bfire_event.5D|'''[fire_event]''']] then the '''[allow_undo]''' must be after the '''[fire_event]'''.

Due to a bug in 1.12 ([http://web.archive.org/web/20170330000414/http://gna.org/bugs/?23323 https://gna.org/bugs/?23323]) '''[allow_undo]''' should not be used in events that use one of the following things because it might cause OOS:
* [message] with [option]s
* [get_global_variable]
* wesnoth.synchronize_choice

While in 1.13 using '''[allow_undo]''' together with those things won't give you a guaranteed OOS, there are some non-obvious situations where it will, for example assume the following event:

[event]
name="moveto"
[message]
message = "message"
[option]
label = "option 1"
[command]
[/command]
[/option]
[option]
label = "option 2"
[command]
[/command]
[/option]
[/message]
[allow_undo]
[/allow_undo]
[/event]

It will cause OOS when the message is undone: since the event is already executed (erased) on one client only , the clients will disagree about how many choices happen during the next moveto action.

=== [on_undo] ===
{{DevFeature1.13|2}}
Contains commands to execute when the player undoes the action which triggered the parent event.
*'''delayed_variable_substitution''' {{DevFeature1.13|5}}: ''yes/no, default no (always no before 1.13.5)'' As in [[EventWML]], specifies whether to perform variable substitution when the parent event is run, or when the contents are run. If delayed substitution is used, [[SyntaxWML#Automatically_Stored_Variables|automatically stored variables]] from the parent event context are available, but may occasionally have unexpected values. (In particular, $unit.x and $unit.y may not have the expected value when undoing a move event, though $x1 and $y1 should be correct.)

Note:
It is not clear where whether the actionwml in [on_undo] in executed before or after the action is undone. Also, specially for enter/leave_hex events the units position when executing the [on_undo] code is usually different than when executing the original event. The recommended way to work around these issues is to refer to the unit by id instead of position and store all other needed information variables as 'upvalues'. You can also move the actual undo code to an external event. For example
[event]
name="undo_blah"
first_time_only=no
[store_unit]
id="$moved_unit_id"
[/store_unit]
... do undo stuff stuff
[/event]

...
... in some other event
[on_undo]
# store ''upvalues
{VARIABLE moved_unit_id $unit.id}
# call actual undo handler
[fire_event]
name = "undo_blah"
[/fire_event]
[on_undo]

=== [on_redo] ===
{{DevFeature1.13|2}}
Same as [on_undo], except executes the commands on redo. Note that the parent event is not triggered again on a redo.

{{DevFeature1.13|8}} [on_redo] is deprecated and has no effect anymore.

Note that [on_redo] is not guaranteed to be called when redoing an action, the engine might also decide to just fire the original events again.

=== [cancel_action] ===
Although Wesnoth 1.12 does not have this tag, it is the default behavior of '''enter_hex'''/'''exit_hex''' [event] in that version.

{{DevFeature1.13|9}} In this version, [cancel_action] is recognised, but has no effect (a bug).

{{DevFeature1.13|11}}
In an '''enter_hex'''/'''exit_hex''' [event], interrupt the movement, leaving the unit where it is. This is intended to be used with an event that gives the player new information, to let the player choose whether to change their plans. For example, if the player has commanded a unit to move from (1,1) to (3,3) and attack a unit on (4,4); then a [cancel_action] inside an '''enter_hex''' [event] on (2,2) would make the unit stop on (2,2). A [cancel_action] inside an enter_hex [event] on (3,3) would let the player choose whether to attack.

=== [heal_unit] ===
Heal a unit. The variable '''$heal_amount''' will be set to the exact number of points healed (i.e can be less than the parameter '''amount''' if the unit is fully healed). $heal_amount contains only the number of hitpoints the first unit that was found got healed. When the variable is not needed, use {CLEAR_VARIABLE heal_amount} after this tag.

{{DevFeature1.17|0}} The '''$heal_amount''' variable is no longer set. Use the '''variable''' key instead.
* '''[filter]''': [[StandardUnitFilter]] All matching on-map units are healed. If no filter is supplied, it is tried to take the unit at $x1, $y1.
* '''[filter_second]''': [[StandardUnitFilter]] all the units matching the filter ''and'' having the ''heals'' ability will have their animation played (if ''animate'' is set to yes) for each of the units healed.
* '''amount''': (integer, default full) the maximum points the unit(s) will be healed. This can't be used to set the unit's hitpoints below 1 or above the unit's maximum hitpoints. If "full", it fully heals the unit.
* '''animate''': a boolean which indicate if the healing animations must be played. (default no)
* '''moves''': (integer, default 0) The maximum current movement points the units will be "healed". Can't set below 0 or above max_moves. If "full", sets moves to max_moves.
* '''restore_attacks''': (boolean, default no) Whether the units' attacks_left should be reset to their max_attacks (usually 1).
* '''restore_statuses''': (boolean, default yes) Whether standard statuses should be reset to "no". This affects poisoned, slowed, petrified and unhealable.
* '''variable''': {{DevFeature1.17|0}} creates an array with the given name; each item of the array has two fields, ''id='' (the ID of the unit being healed) and ''heal_amount='' (the amount of HPs the unit has been healed by).

=== [harm_unit] ===
Harms every unit matching the filter, for the specific damage amount. When harming multiple units, the special variable '''$this_unit''' can be used to access the current unit being harmed. This obviously does not work inside the filters though, as they give '''$this_unit''' a different meaning.
* '''[filter]''': [[StandardUnitFilter]] all matching units will be harmed (required).
* '''[filter_second]''': [[StandardUnitFilter]] if present, the first matching unit will attack all the units matching the filter above.
* '''amount''': the amount of damage that will be done (required).
* '''alignment''': (default neutral) applies an alignment to the damage, this means that if alignment=chaotic, the damage will be increased at night and reduced at day.
* '''damage_type''': if present, amount will be altered by unit resistance to the damage type specified.
* '''kill''': (default yes) if yes, when a harmed unit goes to or below 0 HP, it is killed; if no its HP are set to 1.
* '''fire_event''': (default no) if yes, when a unit is killed by harming, the corresponding events are fired. If yes, also the corresponding advance and post advance events are fired.
* '''animate''': (default no) if yes, scrolls to each unit before harming it and plays its defense (or attack, if it's the harmer) and death animations. Special values supported, other than the usual yes and no, are "attacker", that means only the harmer will be animated, and "defender", that means only the harmed units will be animated. If the supplied value is yes, attacker or defender also advancement animations are played.
* '''[primary_attack], [secondary_attack]''': these set the weapon against which the harmed units will defend, and that the harming unit will use to attack, respectively (notice this is the opposite of '''[filter]''' and '''[filter_second]''' above). This allows for playing specific defense and attack animations. Both tags are expected to contain a [[FilterWML#Filtering_Weapons|Standard Weapon Filter]].
* '''delay''': if animate=yes, sets the delay (in milliseconds, default 500) between each unit harming.
* '''variable''': if present, the damage caused to the unit, altered by resistances, will be stored in a WML array with the given name, under the ''harm_amount='' key. {{DevFeature1.17|0}} Each item of the array also has an ''id='' key, which contains the ID of the unit being harmed.
* '''poisoned, slowed, petrified, unhealable''': (default no) if yes, every harmed unit that doesn't already have such status will have it set.
* '''experience''': (default yes) If there is a harmer, experience will be attributed like in regular combat. Set it to no so that it does not generate experience.
* '''resistance_multiplier''': the harmed unit's resistance is multiplied by the supplied value; this means that a value lower than 1 increases it, and a value greater than 1 decreases it. Default value is 1, that means no modification.

=== [time_area] ===
How a day should progress in a given area. Everywhere not specified in a [time_area] tag is affected by the [time] tags in the [scenario] tag.
* [[StandardLocationFilter]]: the locations to affect. ''note: only for [event][time_area]s - at scenario toplevel [time_area] does not support [[StandardLocationFilter]], only location ranges''
* '''[time]''': one or more tags describing the new schedule, see [[TimeWML]].
* '''id''': an unique identifier assigned to a time_area. Optional, unless you want to remove the time_area later or reference it from a location filter elsewhere. Can be a comma-separated list when removing time_areas, see below.
* '''remove''': (boolean) yes/no value. Indicates whether the specified time_area should be removed. Requires an identifier. If no identifier is used, however, all time_areas are removed.
* '''current_time''': The time slot number (starting with zero) active at the creation of the area.

''Example:'' (caves in parts of a map)
<syntaxhighlight lang=wml>
[time_area]
id = cave_area
x = 1-2,4-5
y = 1-2,1-2
{UNDERGROUND}
[/time_area]
</syntaxhighlight>

Specifying an id allows the area to be referenced from location filters. Example:
<syntaxhighlight lang=wml>
[time_area]
id = glyphs
x = 9,14
y = 11,3
[/time_area]
[event]
name = moveto
first_time_only=no
[filter]
side = 1
[filter_location]
area = glyphs
[/filter_location]
[/filter]
# Do something, for example healing the unit
[/event]
</syntaxhighlight>

=== [remove_time_area] ===

{{DevFeature1.13|2}}

This is a syntactic shortcut for [time_area] remove=.
* '''id''': Comma-separated list of time area ids to remove.

=== [end_turn] ===
End the current side's turn. The current event is finished before the turn is ended. Also, if the current event (where the tag appears) has been fired by another event, that event (and the complete stack of other possible parent events) is ended before [end_turn] comes into affect. Also, events following the event stack that fired [end_turn] are not omitted (e.g. [end_turn] is used by a side turn event and a turn refresh event does something afterwards).

=== [replace_map] ===

Replaces the entire map.
* '''map_data''': Content of a wesnoth map file. (This key used to be just '''map='''.) Example:
map_data="{campaigns/Heir_To_The_Throne/maps/01_The_Elves_Besieged.map}"
* '''map_file''': {{DevFeature1.13|?}} Path to a Wesnoth map file; can be used instead of '''map'''. The file will be loaded when the tag is executed, rather than being embedded wholesale in the preprocessed WML. Example:
map_file=campaigns/Heir_To_The_Throne/maps/01_The_Elves_Besieged.map
{{DevFeature1.15|3}} If the file is not found directly, it will be searched for in the [[BinaryPathWML|[binary_path]]]. Assuming a standard campaign or add-on layout, the example above can be replaced by:
map_file=01_The_Elves_Besieged.map
* '''expand''': if 'yes', allows the map size to increase. The expansion direction is currently always bottom-right.
* '''shrink''': if 'yes', allows the map size to decrease. If the map size is reduced, any units that would no longer be on the map due to its coordinates no longer existing will be put into the recall list.
Note: When a hex changes from a village terrain to a non-village terrain, and a team owned that village it loses that village. When a hex changes from a non-village terrain to a village terrain and there is a unit on that hex it does not automatically capture the village. The reason for not capturing villages it that there are too many choices to make; should a unit lose its movement points, should capture events be fired. It is easier to do this as wanted by the author in WML.

=== [replace_schedule] ===
Replace the time of day schedule of the entire scenario.
* [[TimeWML]]: the new schedule.
* '''current_time''': The time slot number (starting with zero) active at schedule replacement. ('''NB''': due to https://github.com/wesnoth/wesnoth/issues/5757 this attribute is ignored in versions 1.16.*. The fix was delivered in 1.17.* but wasn't backported due to backward-compatibility requirements)

=== [tunnel] ===

Create a tunnel between some locations, later usable by units to move from source hex to target hex (using the movement cost of unit on the target terrain).

'''Behavior Change as of Wesnoth 1.13.6:''' Vision is now possible (and enabled by default) through tunnels and allied units on the exit hex do not block a tunnel by default any more. This is done in order for moves through tunnels to be consistent with other moves. The previous behavior can still be accomplished by using the new optional keys listed below.

* '''[filter]''': (required) [[StandardUnitFilter]] the units which can use the tunnel. Leave empty for "all units".
* '''[source]''': (required) [[StandardLocationFilter]] the source hex(es).
* '''[target]''': (required) [[StandardLocationFilter]] the target hex(es).
* '''id''': (optional) identifier for the tunnel, to allow removing.
* '''remove''': (boolean, default: no) If yes, removes all defined tunnels with the same ID (then only id= is necessary).
* '''bidirectional''': (boolean, default: yes) If yes, creates also a tunnel in the other direction.
* '''always_visible''': (boolean, default: no) If yes, the possible movement of enemies under fog can be seen.
* '''allow_vision''': (boolean, default: yes) {{DevFeature1.13|6}} If no, vision through a tunnel is not possible. Note that in that case the tunnel cannot be used if the tunnel exit is under shroud (which previously was ''always'' the case).
* '''pass_allied_units''': (boolean, default: yes) {{DevFeature1.13|6}} If no, allied (including own) units on the exit hex block a tunnel.
* '''delayed_variable_substitution''' (boolean, default: yes): If yes, the WML block contained in this [tunnel] is not variable-substituted at execution time of the event where this [tunnel] is within. Instead, variables are substituted when the tunnel is used by a unit. See [[EventWML#Nested_Events]]

(Note: The tunnel tag can also be used inside the [[AbilitiesWML|[teleport]]] ability, without remove= and id=).

=== [do_command] ===

{{DevFeature1.13|0}}

Executes a command, specified using the same syntax as a [command] tag in [[ReplayWML]]. Not all [command]'s are valid: only these are accepted

* [attack]
* [move]
* [recruit]
* [recall]
* [disband]
* [fire_event]
* [lua_ai] {{DevFeature1.13|12}} This has been removed and is replaced with [custom_command]

The tags corresponding to player actions generally use the same codepath as if a player had ordered it. That means for example that only moves that player would be allowed to do are possible, and movement is interrupted when sighting enemy unit.

One purpose of this tag is to allow scripting of noninteractive scenarios -- without a tag like this, this might require elaborate mechanisms to coerce ais in order to test these code paths.

This command should be replay safe if it is either invoked in a synced context, ''or'' invoked in code that is never synced, like AI code, a select event, or a menu item with `synced = false`. However, if you use desynchronized logic ''during'' an event that is otherwise synced, invoking [do_command] based on that desynchronized logic will result in out-of-sync errors during the replay; in this case, you must explicitly synchronize which command to do using something like the lua function wesnoth.sync.evaluate_single.

=== [put_to_recall_list] ===

{{DevFeature1.13|0}}

Puts a unit to the recall list of its side.
* '''[[StandardUnitFilter]]''': the unit(s) to get put to the recall list.
* '''heal''': (default=no) Whether the unit should be refreshed, similar to the unit moving to the recall list at the end of a scenario.

=== [set_achievement] ===

{{DevFeature1.17|13}}

Sets the specified achievement as completed and shows a popup stating it's been completed. The popup is not shown if the achievement has already been achieved.

* '''content_for''': The [[AchievementsWML|[achievements_group]]] that this achievement is part of.
* '''id''': The id of the achievement.

=== [set_sub_achievement] ===

{{DevFeature1.17|17}}

Sets the specified sub-achievement as completed.

* '''content_for''': The [[AchievementsWML|[achievements_group]]] that this achievement is part of.
* '''id''': The id of the achievement.
* '''sub_id''': The id of the sub-achievement.

=== [progress_achievement] ===

{{DevFeature1.17|13}}

Progress an achievement by the specified amount, with an optional limit for how far the achievement can be progressed.

* '''content_for''': The [[AchievementsWML|[achievements_group]]] that this achievement is part of.
* '''id''': The id of the achievement.
* '''amount''': The amount to increment the achievement.
* '''limit''': (optional) Using this attribute will prevent achievements from progressing past this value.

== Useful Macros ==
There are some predefined macros that you find useful for direct actions. You can find a complete list along with a detailed explanation of how they work [https://www.wesnoth.org/macro-reference.html here].
* '''{MOVE_UNIT}''': Moves a unit to another location in the map and the player sees the movement (unlike [teleport])
* '''{FULL_HEAL}''': Brings a unit to full HP
* '''{LOYAL_UNIT}''': Create a loyal unit
* '''{MODIFY_TERRAIN_MASK}''': Modify an area of terrain

== See Also ==

* [[InternalActionsWML]]
* [[InterfaceActionsWML]]
* [[EventWML]]
* [[ReferenceWML]]

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

MultiplayerServerWML

2023-08-30T02:27:57Z

Dwarftough: Update: it recieved tls support

This page describes the [[WML]] used to communicate with the multiplayer server for Wesnoth, [[wesnothd]].

== The handshake ==

The client sends four bytes, then the server replies with four bytes. To get a new connection number, the client will send these four bytes: 0x00 0x00 0x00 0x00. The server then sends back the connection number (wesnothd calls this number the "socket number"). Since 1.13+ the server no longer is using socket numbers to keep track of clients and always sends the same number to them all. Since 1.15+ client can also send 0x00 0x00 0x00 0x01 instead to request entire connection to be [https://github.com/wesnoth/wesnoth/blob/2f8136951cd77526188cf8d0fb2cf21eaa2ebe63/src/server/common/server_base.hpp#L60-L76 encapsulated in TLS] immediately '''after'''. If the handshake is successful, the server will be the first to send a data package. All packages are in [http://en.wikipedia.org/wiki/Gzip gzip] format and are preceded by four bytes that specify the size of the package to come in '''big-endian''' (network byte order). Below you'll find information about what data the (unzipped) packages contain. Unpacked WML uses utf-8 charset.

== The login procedure ==

* server request (optional)
** '''[version]'''

* client response
** '''[version]'''
*** '''version''': The client's version string.
*** '''client_source''': The client's distribution info. (Steam, SourceForge, App Store, etc.)

* server response (if the server does not accept this version)
** '''[redirect]'''
*** '''host''': The host you should connect to.
*** '''port''': The port you should connect to.
*** '''version''': A comma-separated list of globs that this server should accept (e.g. "1.0*,1.2*,1.4*,1.7*,1.8*")
** or '''[reject]''' (if the version is unknown)
*** '''accepted_versions''': A comma-separated list of globs that this server does accept

* server request
** '''[mustlogin]'''

* client response
** '''[login]'''
*** '''username''': The username the client would like to have.
*** '''password''': The hashed password, created from the password and salt received from the server. More information about how this password is being generated, including a real world example, can be found in the file [http://forum.wesnoth.org/download/file.php?id=41145 HashedPasswords.pdf] (885 KiB). Since version 1.15+ if TLS was successfully established before then password will be passed as is, without hashing, relying on TLS for secrecy. Passing password hashes is no longer supported to free the client from responsibility to support all hash schemes the forum can potentially use. Client will emit error instead of trying to send password if TLS wasn't established.

* server response
** '''[join_lobby]'''
*** '''is_moderator''': "yes" if the user is a moderator, "no" otherwise.
*** '''profile_url_prefix''': The external URL prefix for player profiles (empty if the server doesn't have an attached database)
** or '''[error]'''
*** '''message''': The error message.
*** '''password_request''': If not empty the server asks the client to provide a password for its desired username.
*** '''phpbb_encryption''': If "yes" the client will encrypt the password using phpbb's algorithm.
*** '''random_salt''': Random salt sent to the client for mixing with the password hash.
*** '''hash_seed''': Salt generated from the original hash that is required to recreate it.
*** '''salt''': Salt generated from the original hash that is required to recreate it.
*** '''force_confirmation''': Display an ok/cancel dialog with the content of the 'message' key.

* server response
** '''[gamelist]'''
*** '''[game]''' (repeated)
**** '''id''': A unique id of the game.
**** '''name''': The title of the game.
**** '''mp_scenario''': The id of the scenario.
**** '''mp_era''': The id of the used era.
**** '''mp_use_map_settings''': Does the game use the map settings specified in the scenario.
**** '''mp_fog''': Does the game use fog.
**** '''mp_shroud''': Does the game use shroud.
**** '''mp_village_gold''': The number of gold per village.
**** '''experience_modifier''': The experience setting.
**** '''mp_countdown''': Does the game use a timer.
**** '''mp_countdown_reservoir_time''': Upper limit of the possibly available time.
**** '''mp_countdown_init_time''': Initial time.
**** '''mp_countdown_action_bonus''': Time bonus per action.
**** '''mp_countdown_turn_bonus''': Time bonus per turn.
**** '''map_data''': The map data. ''Notice: not sent to lobby if the game uses shroud''
**** '''hash''': The hash value of the map_data.
**** '''observer''': Are observers allowed or not.
**** '''human_sides''': The number of sides played by humans.
**** '''slots''': The number of vacant/max slots.
**** '''turn''': The current turn/max turn.
** '''[user]''' (repeated)
*** '''name''': The username of the player.
*** '''game_id''': The ID of the game the player is in.
*** '''location''': The name of the game the player is in.
*** '''available''': "yes" if the player is in the lobby; "no" if in a game.
Many of the keys under [game] are described more indepth on the [[ScenarioWML]] page.

== Error messages ==

* '''[error]'''
** '''message''': The error message.

== Chat (lobby and in-game) ==

* '''[message]'''
** '''sender''': (optional - filled by the server) The sender of the message.
** '''message''': The message itself.
** '''room''': The room the message is from/to
* '''[whisper]'''
** '''receiver''': The receiver of the whisper
** '''sender''': (optional - filled by the server) The sender of the whisper.
** '''message''': The message itself.

== Room commands ==
Note: the room commands are in general and are subject to change. Room commands are not implemented on 1.13+ servers.
* '''[room_join]'''
** '''room''': The room name to join
** '''player''': (filled by server in response message sent to all room members) the player that joins the room
** '''[members]''': member list sent to the player that joined
*** '''[member]''': (repeated) members
**** '''name''': This member's name
* '''[room_part]'''
** '''room''': The room name to part (leave). Leaving the lobby is not allowed.
** '''player''': (filled by server in response message sent to all room members) the player that leaves the room
* '''[room_query]''': specific room-related queries.
** '''[rooms]''': List rooms created on the server, or
** '''[names]''': List members of a given room
*** '''room''': The room name (if applicable)
** '''[persist]''': Check or set room persistance
*** '''value''': (optional) set room persistance to this value (yes/no)
* '''[room_query_response]''': contains specific response to a room_query.
** '''message''': optional text message response
** '''room''': room name (if applicable)
** '''[rooms]''': room list
*** '''[room]''': (repeated) rooms
**** '''name''': This room's name
** '''[members]''': member list
*** '''[member]''': (repeated) members
**** '''name''': This member's name

== Nickname registration related commands (lobby and in-game) ==

* '''[nickserv]'''
** '''[info]''': Request info about another username.
*** '''name''': The username.

== Updating the lobby state ==

* '''[gamelist_diff]''': server message - basically a [[DiffWML|diff]] from two gamelists, which also includes the user list.

* '''[observer]''' or '''[observer_quit]''': server message - players joining([observer_quit] - quitting the lobby "game")/quitting([observer] - joining the lobby "game") a game
** '''name''': Username of the player/observer.
* '''[refresh_lobby]''': Request the full gamelist.

== Game setup (the phase from creation to start) ==
To create a game the client sends:
* '''[create_game]'''
** '''name''': The title of the game.

followed by a message with the scenario options as under [game] (see above) plus the scenario data ([time], [era], [side], etc. see [[ScenarioWML]])

* '''[join]'''
** '''id''': The id of the game.
** '''observe''': Join the game as an observer.

* '''[scenario_diff]''': [[DiffWML|diff]] of the [[ScenarioWML]] (side changes, etc.)

* '''[start_game]''': sent by the host to start a game
* '''[leave_game]''': sent by the client when it leaves a game; sent by the server to make a client leave a game

== In-game communication ==

* '''[store_next_scenario]''': sent by the host - the scenario data (see [[ScenarioWML]]) to advance to the next scenario
* '''[notify_next_scenario]''': sent by the server to tell players that the data for the next scenario is available
* '''[load_next_scenario]''': sent by the client to request the data for the next scenario
* '''[next_scenario]''': data for the next scenario (see [[ScenarioWML]]), sent by the server on request

* '''[info]''': sent by the host on game end - info about the game state
** '''type''': "termination"
** '''condition''': the termination reason

* '''[change_controller]''': a player (un)droids one of his sides or assigns control to someone else (The host can assign control for any side.)
** '''side''': the side to change controller
** '''player''': the nickname of the player to take control
** '''controller''': the new controller: "human" or "human_ai"
** '''own_side''': "yes"

If a player leaves this is sent to the host for all sides he owned.
* '''side_drop''': The number of a side that dropped because a player left.
* '''controller''': The controller of that side. ("ai", "network")

* '''[muteall]''': the host mutes/unmutes all observers - toggles
* '''[mute]''': the host mutes an observer - toggles
** '''username''': the username of the observer - if not specified the servers returns a list of muted usernames
* '''[kick]''' or '''[ban]''': the host kicks/bans a player/observer
** '''username''': the username of the player/observer

* '''[turn]'''
** '''[command]''': (repeated) can contain all the tags you can find in a [[ReplayWML|replay]]: [recruit], [move], [end_turn], etc.
*** '''[speak]'''
**** '''message''': text of the message
**** '''id''': the sender
**** '''team_name''': the name of the team the message is for - empty if it's a public message

== Administrative commands ==
* '''[query]'''
** '''type''': The type of query. See [[ServerAdministration]] for details.

== See also ==
[https://github.com/renom/fastbot fastbot] - the bot for tournaments which implements the protocol, can log in into the lobby and host games. Written in Go.
[[Category:WML Reference]]
[[Category:Server Documentation]]

Foreach

2022-11-25T18:11:21Z

Dwarftough: Redirected page to ConditionalActionsWML#.5Bforeach.5D

#REDIRECT [[ConditionalActionsWML#.5Bforeach.5D]]

Allow extra recruit

2022-11-23T03:53:32Z

Dwarftough: Redirected page to DirectActionsWML#.5Ballow extra recruit.5D

#REDIRECT [[DirectActionsWML#.5Ballow_extra_recruit.5D]]

Allow end turn

2022-11-23T03:52:52Z

Dwarftough: Redirected page to DirectActionsWML#.5Ballow end turn.5D

#REDIRECT [[DirectActionsWML#.5Ballow_end_turn.5D]]

Allied with

2022-11-23T03:52:07Z

Dwarftough: Redirected page to StandardSideFilter

#REDIRECT [[StandardSideFilter]]

Affect adjacent

2022-11-23T03:51:04Z

Dwarftough: Redirected page to AbilitiesWML#Common keys and tags for every ability

#REDIRECT [[AbilitiesWML#Common_keys_and_tags_for_every_ability]]

Harm unit

2022-11-23T03:49:53Z

Dwarftough: Redirected page to DirectActionsWML#.5Bharm unit.5D

#REDIRECT [[DirectActionsWML#.5Bharm_unit.5D]]

Advance

2022-11-20T13:38:12Z

Dwarftough: redirect to the actual doc page for easier tag searching

#REDIRECT [[SingleUnitWML]]

Abilities

2022-11-20T01:21:50Z

Dwarftough: redirect to the actual doc for easier tag searching

#REDIRECT [[AbilitiesWML]]

About

2022-11-20T01:18:42Z

Dwarftough: Redirected page to CreditsWML#.5Babout.5D

#REDIRECT
[[CreditsWML#.5Babout.5D]]

Microtactics, or let's learn to analyze

2022-07-20T00:53:32Z

Dwarftough:

More than once I've seen how decent, not bad strategists get lost in situations that require an efficient use of microtactics on the field.

Let's start with what it actually means. A microtactic in Wesnoth is a capability to control your forces rationally in offense or defense depending on a particular situation. Here I'm not going to describe all possible situations or give you specific instructions what to do. Instead I'll try to teach you how to set up the basic point of your offense or defense.

The key of success in this matter is an ability to prioritize. Priorities may differ, starting from killing a particular unit and up to taking the key point on the map.

== Unit priorities ==
# Enemy leader
# Close-to-level-up unit (less than 9 xp to level)
# Half-dead unit
# Units with great damage (poisoners > ranged > melee)
# Healers
# Scouts
# Any other

Let's examine each of those

''' Leader '''

As each map is based on destroying the enemy leader (the articles talks about default MP scenarios - the translator's note), this unit has the greatest priority for us. Dead leader = victory

''' Close-to-level-up units '''

One of the main rules of a good players is that your opponent should have the only second level unit, which is the leader, and it shouldn't last long. This is especially important about close-to-level units from the 4th category (great damage units)

''' Half-dead units '''

We always try to reduce the number of enemy units, units not killed in time could become a hindrance later.

''' Units with great damage'''

This group is one of the most important. Killing those units we deny the enemy his means of offense and defense.

''' Healers '''

A very important target as well. Healers often reduce to zero results of our attacks.

''' Scouts '''

Eyes and ears of the enemy. Expensive units, usually easy to kill. We try to get rid of them or control them.

''' Others '''

In this category we include all "cannon fodder" which the enemy uses in his formation. Through them we usually make our way to the prioritized targets, so there is no much sense to add more details here.

<hr>

Of course, each point has its exceptions. But they appear in particular tactical situations. For example, sometimes it's better to let the enemy level up his unit (increasing his upkeep costs) if this unit doesn't benefit the enemy significantly. Or, sometimes you may let a half-dead unit go if it has little value in the battle (the enemy will place the unit to heal and will pay upkeep costs for it). So, think and analyze, and the points above are just the basis for your thought work.

== Terrain priorities ==
# Place of enemy recruiting (i.e. the enemy keep)
# Places that "lock" enemy units
# Villages
# Mountains
# Terrain adjacent to flat, water, or any other terrain that don't give the enemy a defense bonus

''' Enemy keep '''

Taking this point, we prevent the enemy getting reinforcements. This also gives more time for our own expansion.

''' Places that "lock" enemy units '''

A vague that includes various isthmuses, archs and alike. Placing our unit here we block a massive attack of the enemy. This is especially relevant when we have to buy time (in case of lawful/chaotic enemies)

''' Villages '''

Don't think it's needed to say much here. Economy and healing.

''' Mountains '''

That is also an important point. A height benefits many units of each faction.

''' Adjacent to terrain that doesn't give the enemy a defense bonus '''

Creating a front with conditions favourable for us we create opportunities for better RNG.

<hr>
TODO

{{Wesnothlife|py6aka, Feb 26, 2012}}

Microtactics, or let's learn to analyze

2022-07-20T00:40:28Z

Dwarftough: /* Unit priorities */

More than once I've seen how decent, not bad strategists get lost in situations that require an efficient use of microtactics on the field.

Let's start with what it actually means. A microtactic in Wesnoth is a capability to control your forces rationally in offense or defense depending on a particular situation. Here I'm not going to describe all possible situations or give you specific instructions what to do. Instead I'll try to teach you how to set up the basic point of your offense or defense.

The key of success in this matter is an ability to prioritize. Priorities may differ, starting from killing a particular unit and up to taking the key point on the map.

== Unit priorities ==
# Enemy leader
# Close-to-level-up unit (less than 9 xp to level)
# Half-dead unit
# Units with great damage (poisoners > ranged > melee)
# Healers
# Scouts
# Any other

Let's examine each of those

''' Leader '''

As each map is based on destroying the enemy leader (the articles talks about default MP scenarios - the translator's note), this unit has the greatest priority for us. Dead leader = victory

''' Close-to-level-up units '''

One of the main rules of a good players is that your opponent should have the only second level unit, which is the leader, and it shouldn't last long. This is especially important about close-to-level units from the 4th category (great damage units)

''' Half-dead units '''

We always try to reduce the number of enemy units, units not killed in time could become a hindrance later.

''' Units with great damage'''

This group is one of the most important. Killing those units we deny the enemy his means of offense and defense.

''' Healers '''

A very important target as well. Healers often reduce to zero results of our attacks.

''' Scouts '''

Eyes and ears of the enemy. Expensive units, usually easy to kill. We try to get rid of them or control them.

''' Others '''

In this category we include all "cannon fodder" which the enemy uses in his formation. Through them we usually make our way to the prioritized targets, so there is no much sense to add more details here.

<hr>

Of course, each point has its exceptions. But they appear in particular tactical situations. For example, sometimes it's better to let the enemy level up his unit (increasing his upkeep costs) if this unit doesn't benefit the enemy significantly. Or, sometimes you may let a half-dead unit go if it has little value in the battle (the enemy will place the unit to heal and will pay upkeep costs for it). So, think and analyze, and the points above are just the basis for your thought work.

TODO

{{Wesnothlife|py6aka, Feb 26, 2012}}

Microtactics, or let's learn to analyze

2022-07-19T22:02:12Z

Dwarftough: /* Unit priorities */

More than once I've seen how decent, not bad strategists get lost in situations that require an efficient use of microtactics on the field.

Let's start with what it actually means. A microtactic in Wesnoth is a capability to control your forces rationally in offense or defense depending on a particular situation. Here I'm not going to describe all possible situations or give you specific instructions what to do. Instead I'll try to teach you how to set up the basic point of your offense or defense.

The key of success in this matter is an ability to prioritize. Priorities may differ, starting from killing a particular unit and up to taking the key point on the map.

== Unit priorities ==
# Enemy leader
# Close-to-level-up unit (less than 9 xp to level)
# Half-dead unit
# Units with great damage (poisoners > ranged > melee)
# Healers
# Scouts
# Any other

Let's examine each of those

''' Leader '''

As each map is based on destroying the enemy leader (the articles talks about default MP scenarios - the translator's note), this unit has the greatest priority for us. Dead leader = victory

''' Close-to-level-up units '''

One of the main rules of a good players is that you should have the only second level unit, which is the leader, and it shouldn't last long. This is especially important about close-to-level units from the 4th category (great damage units)

''' Half-dead units '''

We always try to reduce the number of enemy units, units not killed in time could become a hindrance later.

''' Units with great damage'''

This group is one of the most important. Killing those units we deny the enemy his means of offense and defense.

''' Healers '''

A very important target as well. Healers often reduce to zero results of our attacks.

''' Scouts '''

Eyes and ears of the enemy. Expensive units, usually easy to kill. We try to get rid of them or control them.

''' Others '''

In this category we include all "cannon fodder" which the enemy uses in his formation. Through them we usually make our way to the prioritized targets, so there is no much sense to add more details here.

<hr>

Of course, each point has its exceptions. But they appear in particular tactical situations. For example, sometimes it's better to let the enemy level up his unit (increasing his upkeep costs) if this unit doesn't benefit the enemy significantly. Or, sometimes you may let a half-dead unit go if it has little value in the battle (the enemy will place the unit to heal and will pay upkeep costs for it). So, think and analyze, and the points above are just the basis for your thought work.

TODO

{{Wesnothlife|py6aka, Feb 26, 2012}}

Microtactics, or let's learn to analyze

2022-07-19T21:16:31Z

Dwarftough:

Microtactics, or let's learn to analyze

2022-07-19T20:52:43Z

Dwarftough: Starting of translation

LotI Walkthrough-Part2-Chapter08

2022-07-19T01:15:22Z

Dwarftough: /* Jungle Hell */

'''Part II, Into the Light, Chapter 8, Götterdämmerung'''

'''Generally'''

You'll be fighting a lot of units that are liminal, and have good arcane resistance, so have sources of illumination and darkens and a good mix of attack types.

==Mysterious Invasion==
'''[WHU]''' This one is really easy to lose. Your enemies are very tough. Recruit a mob of walking corpses, who will do pretty much nothing but keep the enemies off your leaders while you whittle them down. Do grab easy kills with your corpses to refresh your ranks where possible. The kids should pretty much stay out of the fight, though pick up some cheap XP at the end if you can.

'''[WHU]''' Make sure to read about the corruption special on Vritra's dark blast attack, so you know not to use it, now, or in the future.

==Overpowered==
'''[WHU]''' Recruit a castle of walking corpses, then run. Keep the kids covered, while getting to the next castle quickly to recruit another load of fodder. Repeat as necessary. The family moves well and is well protected in the woods. Go for the early finish.

==United==
'''[WHU]''' Efraim can pretty much take care of the southern enemy single-handedly, though if he gets slowed repeatedly so that he cannot advance it might be useful to send a little help. The demons to the west are kind of nasty. Let your allies weaken them up, and use Lethalia to pick off weak units who don't have a lot of friends in the area. When you're ready to go in for the kill, use overwhelming force, like prophets with unholybane. The demons to the east aren't much of a problem, you should be able to roll right over them when you're done in the west.

==Kidnapped==
'''[WHU]''' One castle of units should be plenty. Follow the path southwest, then southeast.

==Investigations==
'''[WHU]''' Sneak around the woods outside of town. When a single unit comes to the edge of the woods, pop out and redeem him, then get back in the shadows. You should have plenty of turns to redeem everyone, then get on with the primary mission, which is to visit about five specific houses. Don't let any of the guards get next to you.

==Gladiatrix==
'''[WHU]''' Grab the gear to the north. Fight a few units, one at a time.

==Unimportant Revolution==
'''[WHU]''' Use caution. Some of the enemy do a LOT of damage, and you don't want to get surrounded by a few of those. Use the river and your allies to wear the enemy down a bit, then overwhelming force focused on killing his most dangerous units. Be sure to check the enemy resistances before recalling.

==The Desert==
'''[WHU]''' Another long scenario where you encounter large groups of dangerous enemies, plus a steady stream of demons from the northeast. There is a cave that runs along the east side of the map with some gold and some goodies, but I have no idea how you could get to it, through it, and back out to the exit within the turn limit. I recall a couple castles, start south and visit the trader, then continue south and fight off a batch of demons. Then it's east to deal with the saurians and a couple other factions, then follow the road southeast and then south. About the time the road pretty much ends, I notice how few turns I have left considering the progress I've made so far, panic, and send one of my leaders to run right around the various factions, ending quite early with no early finish bonus.

==Gladiatrix - The Path to Glory==
'''[WHU]''' Back to the arena, this time with some friends. Some friends that you really, really, want to keep alive. I try to get four units with a lot of HP so that I can block the entrance to the north building, along with some healing. I also like to advance the battlerager as quickly as possible (thorns/weak reflect/reflect), and increase his number of attacks, or anything else I can just to keep him alive. Slow will be crucial here, probably some clever crafting, and don't forget those potions.

==Ruins of Wesnoth==
'''[WHU]''' Efraim can handle the humans alone. Send powerful elves south. A couple of fast, powerful units with slow may be able to rush down and take out the southern leader (he'll show up in a few turns) while the rest of the army draws his forces away. Lethalia and a few quick, powerful units should be able to get into the northern castle before that enemy shows up, hurt him and he should leave the keep open for you to claim (you may not want to stand on his keep before he arrives, at one time bad things would happen if you did).

==Odd World==
'''[WHU]''' There is no early finish bonus, but you really need to move anyway. Your enemies, demons and imps, will be spawning constantly and coming for you from all directions. A force of 15-20 works well, including healers and flyers. Prophets, or other very hard hitting units, with unholybane would be very useful. Villages don't provide any income, but they heal +16. There are items and gold scattered around the map.

'''[WHU]''' You'll also get a wonderful introduction to the most annoying trait in BFW, temptation. If one of your unit starts its turn next to a unit of the opposite gender with temptation, your unit will be unable to attack that turn (unless maybe you use a greater healing potion, I've never tried it, just thought of it). This is especially frustrating when you've been slowed and can't get out of the way. Unlike most special traits, or even some of the basic ones, I'm pretty well convinced the AI knows EXACTLY how to make optimum use of temptation. Keep a couple of fast prophets with unholybane (or similar) behind the front and rear lines to run out and slaughter those demons whenever you see them.

'''[WHU]''' Start off going south until you get to the mountains. Send Lethalia and some flyers or mountain travellers south through the mountains to take out a boss. Send the rest of the army east, where you will fight in the mountains (there is also a path around the mountains for units that can't go through). About the time you get through the mountains and start north, you'll probably need a rather powerful rear guard. Every turn you spent getting through (and around) the mountains, your enemy was spawning units behind (and in front, and to the side) of you. Use penetrates and hit and run, skirmishers, and flyers to ensure you are constantly making forward progress.

'''[WHU]''' Around the time you make sight of the last enemy boss, and you feel confident that you can spare them, send a couple relatively powerful flyers northeast. Between the mountains is a route over a lake of lava that leads to the exit. Have one of your flyers continue to the northeast into a cavern where there are a couple items.

'''[WHU]''' If you have been actively using your redeem attack, you should have noticed that it is starting to sometimes redeem multiple units, particularly when they are low level. Those big packs of imps are just asking to be redeemed.

==Gladiatrix - The Reckoning==
'''[WHU]''' Move slowly, kill everything. At first you'll be attacked out of the dark, then by a much nastier unit that's initially invisible. There's no turn limit, heal as much as you need. Charge out of the building in force, or draw the enemy into the corridor, depending on your strengths. You'll fight a couple enemy units at a time at first. Take out the boss to the northwest, then head southeast. When you get near the southern end of the map, you'll be taking on a bunch of non-trivial enemies (you'll see why I strongly recommended protecting your friends in the arena). If you still have all your arena allies, and you've geared them well and levelled them, just use your unit-specific strengths against against the enemy weaknesses. If not, good luck.

'''[WHU]''' Once you get into the city, it gets much easier, for a little while. Take out the bosses and anyone who breathes your air. Then head north into the building to fight three batches of those nasty demons before heading to the northwest corner exit. You need to fight them on your terms, where only one of them can attack at a time and you can retreat to heal. Each batch will be a bit harder than the one before. It is not uncommon for me to do a major retreat when fighting the third batch, stringing them out so I can pick them off one at a time, often using my unit with teleport to sneak behind them as they chase me.

==The River of Flame==
'''[WHU]''' This is a scenario I've always played in a manner which I suspect is completely unintended. Recall a few powerful units and a couple healers, and maybe a unit or two you want to give some XP. Block the bridges to your starting location, and pick up convenient kills. Meanwhile, Lethalia flies right over the lava, clockwise around the edges of the map, perhaps killing and/or redeeming a few lone units along the way, to meet the troll in the southeast without ever having to actually work for it. Major early finish bonus. Cheater.

==Finally Together==
'''[WHU]''' Focus on elves if you have them. Make the enemy fight your army while you are in the forest and they are on the path. Use your army and Vritra's team to draw the enemy forces away from their leaders, while a few fast, powerful units circle around and assassinate the leaders.

==Jungle Hell==
'''[WHU]''' It's a jungle, so elves are the obvious choice, and they do fine, but while they have good defenses in forests, their natural forest movement isn't of much value here. This is yet another scenario of huge packs of demons that are triggered by your forward progress, so you don't necessarily need to move that fast, and you'll be standing around most of the time anyway. Also, you can do the 'transport all units' to Efraim every 10 turns thing. A lot of the terrain is impassible, for you, but not for some of the demons.

'''[WHU]''' You'll fight two packs of demons at the beginning. I find that Lethalia casting explosive slow on the pack to the east backed up by a few powerful units can take care of them pretty easily, while Efraim and a lot of support (including explosive slow), work on the pack coming up from the south. Let the enemy come to you, don't chase at them and trigger yet another pack.

'''[WHU]''' Once those two are taken care of, I follow the river south and then west, then south through the gap in the woods, and generally make my way south, moving east and west a little where opportunity presents, always keeping the terrain in my favor as much as possible. I don't know that the actual route matters, I've just always gone that way and it works for me. There are plenty of turns for you to move slowly and not trigger too many packs at once. If you fight the demons in the middle of the forest it will limit the number of them which can attack on any one turn.

'''[dwarftough]''' Masterpace on the forums described a funny way to cheese and skip this scenario if you want to: https://forums.wesnoth.org/viewtopic.php?p=670591#p670591

Briefly, the idea is to craft Nightwalkers for Lethalia, Krux, Vritra and one Deflector of Light for darkening, so they can hide in shadows in the keep for all day long. Then, Efraim takes the Woodland Cloak with ambush, moves strictly through the forest and reaches the south evading any fights.

==Gates of Hell==
'''[WHU]''' No gold carryover, so you may as well spend it. The first three leaders should go down pretty quickly, and then it will get just a bit harder with demons coming from the south, and spawning occasionally from the east and west. When you get to the bottleneck there are two paths, use both of them. Lethalia could use the western path, in case you want to rush the exit. You'll encounter a boss who has a lot of HP and hits hard. Use an explosive slow on an enemy next to him each turn to slow him, then hit him really hard with units that are resistant to impact and cold, perhaps using a holy potion if you don't have unholybane attacks already. You have plenty of turns, in theory you could incinerate him and then draw him into the open where you could hit him many more times per turn, possibly even running Lethalia around behind him to the exit, but I've never found that necessary.

'''[dwarftough]''' An important note, I believe, for higher diffuclties: here you have to think and equip Krux and Vritra in the best items. You will begin Chapter 10 without your main storage, with only a few gems and random items, and the only items you can carry over there are items equipped on Krux and Vritra. It probably makes sense to give them some premier items, ofc you need items for Chapter 9 on Efraim/Lethalia/their soldiers, but they have the whole Inferno to pillage before the most difficult fights. Particularly I think that if you have the heal+40 ring, you'd better equip it on Krux/Vritra. In Chapter 9 you have all your recall list and most likely a lot of healers, in chapter 10 you have quite few against demon hordes, and Krux's the only basic healer

[[LotI_Walkthrough|Back]]

15 tips for new players

2022-07-19T00:44:11Z

Dwarftough: Created page with "# NEVER rely on luck. # Don't fight in an unfavourable time of day. # Calculate your defensive placement in such a way that the minimal number of enemy units could attack you...."

# NEVER rely on luck.
# Don't fight in an unfavourable time of day.
# Calculate your defensive placement in such a way that the minimal number of enemy units could attack you.
# For a defensive line better put a unit with a lot of hp or a unit with great resistances instead of units with high dodge.
# Attack in your favourable time of day.
# Attack units that are more vulnerable to a given type of damage.
# Don't attack units with strong melee in melee, don't attack units with strong ranged in ranged.
# Plan an attack in such a way that the maximal number of your units could participate in it.
# Don't rush at the enemy leader if chances of leaderkill are slim and your units suffer great retaliation.
# Try to lure your opponent on terrain where he had less defense.
# If you have an overwhelming advantage in the number of units and economy, continue attacking even in an unfavourable time of day/
# Don't forget to take villages (it's the basic element of economy).
# Don't harass enemy villages if your unit can be caught.
# When you harass, don't forget that with each village you take from your opponent, you win 4-6 gold per turn (consider the harassing unit's cost to not get into disadvantage).
# Prioritize economy over the number of units (but wisely).

P.S. And don't forget that each rule has exceptions :)

{{Wesnothlife|ReNoM, Sep 11, 2011}}

Template:Wesnothlife

2022-07-19T00:30:58Z

Dwarftough: Created page with "<div class="navtemplate" style="width: auto; max-width: 75%; margin: 0 auto; border: 1px solid #c55; border-left-width: 8px"><p style="margin:0"><strong>This material is taken..."

<div class="navtemplate" style="width: auto; max-width: 75%; margin: 0 auto; border: 1px solid #c55; border-left-width: 8px"><p style="margin:0"><strong>This material is taken from WesnothLife, a Russian Wesnoth community.</strong> <br> Its original author and date of publication: {{{1}}} </p></div><includeonly>[[Category:Wesnothlife Materials]]
</includeonly>
<noinclude>[[Category:Templates]]</noinclude>

AbilitiesWML

2022-01-28T19:28:01Z

Dwarftough: /* Extra keys used by the [leadership] ability */

{{WML Tags}}
== Abilities and their effects ==

There are two types of abilities: ones that apply to units (called ''abilities'') and ones that only apply when using a particular attack (called ''specials'' or ''weapon specials''). A unit may have multiple abilities and an attack can have multiple specials.

== The ''[abilities]'' tag ==

The following tags are used to describe an ability in WML:

* '''[heals]''': modifies the hitpoints of a unit at the beginning of the healer's turn
* '''[regenerate]''': modifies the hitpoints of a unit at the beginning of the unit's turn
* '''[resistance]''': modifies the resistance of a unit to damage
* '''[leadership]''': modifies the damage of a unit
* '''[skirmisher]''': negates enemy zones of control
* '''[illuminates]''': modifies the time of day adjacent to the affected units
* '''[teleport]''': allows the unit to teleport
* '''[hides]''': renders the unit invisible to enemies
* {{DevFeature1.15|0}} A tag matching a [[#The_.5Bspecials.5D_tag|weapon special tag]], [damage] for example, will confer that weapon special to units based on the given conditions. Most weapon specials are supported; however, '''plagues''', '''heal_on_hit''', and '''swarm''' are not.
Any other name is valid (for example '''[dummy]'''), but will result in an ability that does nothing but report it's there. These tags still use the same common keys and tags as every other ability. '''Note:''' a dummy ability must have an id for the name and description to display.

=== Available formula variables in Abilities and Weapon Specials ===

{{DevFeature1.15|?}} When using formulas in abilities and weapon specials, the following formula variables are available:
* '''self''': (unit) the unit that has the ability
* '''student''': (unit) for leadership-like abilities this is the unit that is adjacent to the unit that has the ability.
* '''attacker''': (unit) for attack-related abilities and weapon specials, this is the attacking unit during the attack.
* '''defender''': (unit) for attack-related abilities and weapon specials, this is the defending unit during the attack.
* '''other''': (unit) the unit whose stats get modified from the ability. For abilities without 'apply_to=opponent' this is always the same as 'student'.

=== Common keys and tags for every ability ===

{{DevFeature1.13|?}} All keys inside any ability that expects a numeric value will also accept formulas using
[[Wesnoth Formula Language]]. In order to use a formula in these keys, you must enclose it in parentheses. However, do not precede those parentheses with a dollar sign like <code>$(...)</code>, since that will erase the <tt>self</tt> variable.

* '''name''': the (translatable) name of the ability.
* '''female_name''': the (translatable) name of the ability when possessed by a female unit. Defaults to ''name'' if not specified.
* '''name_inactive''': the (translatable) name of the ability when inactive. Defaults to ''name'' if not specified; if the ability is supposed to be not displayed when inactive, you must explicitly set ''name_inactive'' to an empty string (nothing after the equals sign).
* '''female_name_inactive''': the (translatable) name of the ability when inactive and possessed by a female unit. Defaults to ''name_inactive'' if not specified.
* '''description''': the (translatable) description of the ability.
* '''description_inactive''': the (translatable) description of the ability when inactive. Defaults to ''description'' if not specified.
* '''special_note''' {{DevFeature1.15|14}} Translatable string, which will be displayed in the unit’s help. See also [[UnitTypeWML#Special_Notes]].
* '''affect_self''': if equal to 'yes' (default), the ability will affect the unit that has it.
* '''affect_allies''': if equal to 'yes', the ability will affect units from the same and allied sides in the specified adjacent hexes. If set to 'no' it will not affect own or allied sides. If not set (default) it will affect units on the same side but not from allied sides.
* '''affect_enemies''': if equal to 'yes' (default is 'no'), the ability will affect enemies in the specified adjacent hexes.
* '''cumulative''': if set to 'yes', this ability will be cumulative with the base value for this ability. ''Beware of the bug with cumulative leadership in 1.16 https://github.com/wesnoth/wesnoth/issues/6466 , more info see below, in "Extra keys used by the ''leadership'' ability" section''.
* '''id''': this ability will not be cumulative with other abilities using this id. Must be present if cumulative is anything other than 'yes'.
* '''[filter]''': [[StandardUnitFilter]] If the unit owning the ability does not match this filter, the ability will be inactive.
* '''[affect_adjacent]''': an adjacent unit that does not match this filter will not receive its effects. There can be multiple [affect_adjacent] tags in a single ability; a unit needs to match any one of these to receive the effects. The side requirement of matching units is defined by the '''affect_allies''' and '''affect_enemies''' keys. If there are no [affect_adjacent] tags, then no adjacent units will receive the effects.
** '''adjacent''': a comma separated list of any combination of these directions: '''n''','''ne''','''se''','''s''','''sw''','''nw'''. (See [[StandardLocationFilter#Directions|notes]])
** '''[filter]''': a [[StandardUnitFilter]]. {{DevFeature1.13|2}} The variable $other_unit refers to the unit owning the ability.
* '''[filter_self]''': if the owner of the ability does not match this filter, it will not receive the effects of the ability. [filter_self] takes a [[StandardUnitFilter]] as argument.
* '''[filter_adjacent]''': if an adjacent unit does not match this filter, the ability will not be active and no-one will receive its affects. Takes extra keys ''adjacent'', ''count'', ''is_enemy'', just like in a [[StandardUnitFilter]], with the one difference that, in the absence of a specified ''count'', all listed directions must match (so, with two directiones eg ''adjacent=n,s'', the default is ''count=2''). In fact, it's really a shorthand for a [filter_adjacent] nested within [filter]. The variables $this_unit and {{DevFeature1.13|2}} $other_unit both work as you'd expect. Multiple [filter_adjacent] can be provided, all of which must pass for the ability to activate.
* '''[filter_adjacent_location]''': like [filter_adjacent], but filters on locations instead of units. This is a shorthand for [filter][filter_location][filter_adjacent_location].
* '''[filter_base_value]''': filters on the value before any modifications; uses the keys '''equals''', '''not_equals''', etc. If several keys are used all have to match.

=== Extra keys used by the ''[heals]'' ability ===

* '''value''': the amount healed.
* '''poison''': can be one of ''slowed'',''cured''. ''slowed'' means poison will not take effect for adjacent units (it's not related to the weapon special "slows").

=== Extra keys used by the ''[regenerate]'' ability ===

* '''value''': the amount healed.
* '''poison''': can be one of ''slowed'',''cured''.

=== Extra keys and tags used by the ''[resistance]'' ability ===

* '''value''': set resistance to this value.
* '''max_value''': maximum resistance value. This value '''must''' be set in order for [resistance] to function.
* '''add''': adds to resistance.
* '''sub''': subtracts from resistance.
* '''multiply''': multiplies resistance value.
* '''divide''': divides resistance value.
* '''apply_to''': a list of damage types; if left out, the ability applies to all types.
* '''active_on''': one of 'defense' or 'offense'; if left out, the ability is active on both.
These keys affect the actual resistance (e.g. -20%), not the damage modifier normally used in [resistance] (e.g. 120).
* '''[filter_weapon]''': {{DevFeature1.15|0}} If present, the resistance ability only takes effect when the owner of the ability uses a matching weapon.
* '''[filter_second_weapon]''': {{DevFeature1.15|0}} If present, the resistance ability only takes effect when the opponent uses a matching weapon.
* '''[filter_student]''': {{DevFeature1.15|0}} If present, the ability only takes effect on units matching this filter.

=== Extra keys used by the ''[leadership]'' ability ===

* '''value''': the percentage bonus to damage.
* '''add''': the cumulative percentage bonus to damage.
''Note:'' cumulative leadership with '''cumulative=yes''' and '''value=''' doesn't work in 1.16. To work around use '''add=''' key (it doesn't require cumulative) (https://github.com/wesnoth/wesnoth/issues/6466 ).
* '''[filter_weapon]''': If present, the leadership ability only takes effect when the owner of the ability uses a matching weapon.
* '''[filter_second_weapon]''': If present, the leadership ability only takes effect when the opponent uses a matching weapon.
* '''[filter_student]''': {{DevFeature1.15|0}} If present, the ability only takes effect on units matching this filter.

=== Extra keys used by the ''[illuminates]'' ability ===

Because this ability changes the terrain instead of units on it, affect_self, affect_allies, affect_enemies and [filter_adjacent] have no effect.
* '''value''': the percentage bonus to lawful units. Units with '''alignment=lawful''' do +''value'' % damage when under the influence of a unit with this ability. Units with '''alignment=chaotic''' do -''value'' % damage. Units with '''alignment=neutral''' are unaffected by this ability. Units with '''alignment=liminal''' do -(abs(''value'')) % damage. ''value'' can be a negative number; this is useful if you want to give Chaotic units an advantage instead of Lawful ones.
* '''max_value''': the maximum percentage bonus given.
* '''min_value''': the minimum percentage bonus given.

=== Extra keys used by the ''[hides]'' ability ===

* '''alert''': the displayed text when the unit is discovered. Default "Ambushed!".

=== Extra tags used by the ''[teleport]'' ability ===

* '''[tunnel]''' - a [[DirectActionsWML#.5Btunnel.5D|tunnel tag]] (without the remove key) defining the tunneling source and target hexes, and maybe other conditions. (It automatically applies only to the unit with the ability.) You may use $teleport_unit inside the tunnel tag for filtering purposes.

=== Extra tags and keys used by weapon special abilities ===

* '''[filter_weapon]''': If present, the ability only takes effect when the owner of the ability uses a matching weapon.
* '''[filter_second_weapon]''': If present, the ability only takes effect when the opponent uses a matching weapon.
* '''[filter_student]''': If present, the ability only takes effect on units matching this filter.
* Other keys and tags appropriate to the specific weapon special

=== Macros for common abilities ===

* ABILITY_AMBUSH
* ABILITY_CURES
* ABILITY_HEALS
* ABILITY_ILLUMINATES
* ABILITY_LEADERSHIP_LEVEL_1 to ABILITY_LEADERSHIP_LEVEL_5
* {{DevFeature1.13|2}} ABILITY_LEADERSHIP (replaces the above leadership macros, which are now deprecated)
* ABILITY_NIGHTSTALK
* ABILITY_REGENERATES
* ABILITY_SKIRMISHER
* ABILITY_STEADFAST
* ABILITY_SUBMERGE
* ABILITY_TELEPORT

== The ''[specials]'' tag ==

The '''[specials]''' tag goes inside the '''[attack]''' tag. It can contain the following tags:

* '''[attacks]''': modifies the number of attacks of a weapon
* '''[berserk]''': pushes the attack for more than one combat round
* '''[chance_to_hit]''': modifies the chance to hit of a weapon
* '''[damage]''': modifies the damage of a weapon
* '''[disable]''': disables the weapon
* '''[drains]''': heals the attacker half of the damage dealt
* '''[firststrike]''': forces the weapon to always strike first
* '''[heal_on_hit]''': heals the attacker when an attack connects
* '''[petrifies]''': turns the target to stone
* '''[plague]''': when used to kill an enemy, a friendly unit takes its place
* '''[poison]''': poisons the target
* '''[slow]''': slows the target
* '''[swarm]''': number of strikes decreases as the unit loses hitpoints
Any other name is valid, but will result in an special that does nothing but report it is there.

=== Common keys and tags for every weapon special ===

{{DevFeature1.13|?}} All keys inside any weapon special that expects a numeric value will also accept formulas using [[Wesnoth Formula Language]]. In order to use a formula in these keys, you must enclose it in parentheses.

* '''name''': the (translatable) name of the special.
* '''name_inactive''': the (translatable) name of the special when inactive. Defaults to ''name'' if not specified; if the special is supposed to be not displayed when inactive, you must explicitly set ''name_inactive'' to an empty string (nothing after the equals sign).
* '''description''': the (translatable) description of the special.
* '''description_inactive''': the (translatable) description of the special when inactive. Defaults to ''description'' if not specified.
* '''special_note''' {{DevFeature1.15|14}} Translatable string, which will be displayed in the unit’s help. See also [[UnitTypeWML#Special_Notes]].
* '''id''': this ability will not be cumulative with other specials using this id.
* '''active_on''': one of '''defense''' or '''offense'''; if left out, the special is active on both.
* '''apply_to''': one of '''self''','''opponent''','''attacker''','''defender''','''both''' (default: ''self''). Determines who the effects of this special are applied to.
* '''[filter_adjacent]''': if an adjacent unit does not match this filter, the special will not be active and no-one will receive its effects. Takes extra keys ''adjacent'', ''count'', ''is_enemy'', just like in a [[StandardUnitFilter]]. In fact, it's really a shorthand for a [filter_adjacent] nested within [filter_self], with the one difference that, in the absence of a specified ''count'', all listed directions must match (so, with two directiones eg ''adjacent=n,s'', the default is ''count=2''). The variables $this_unit and {{DevFeature1.13|2}} $other_unit both work as you'd expect. Multiple [filter_adjacent] can be provided, all of which must pass for the ability to activate.
* '''[filter_adjacent_location]''': like [filter_adjacent], but filters on locations instead of units. This is a shorthand for [filter_self][filter_location][filter_adjacent_location].
* '''[filter_self]''': the special will only be active if the owner matches this [[StandardUnitFilter]] (SUF).
** '''[filter_weapon]''': a [[FilterWML#Filtering_Weapons|standard weapon filter]], including special=.
** '''$other_unit''': {{DevFeature1.13|2}} The special variable $other_unit refers to the opponent.
* '''[filter_opponent]''': the special will only be active if the opponent matches this SUF.
** '''[filter_weapon]''': a [[FilterWML#Filtering_Weapons|standard weapon filter]], including special=.
** '''$other_unit''': {{DevFeature1.13|2}} The special variable $other_unit refers to the unit that owns the weapon.
* '''[filter_attacker]''': the special will only be active if the attacker matches this SUF.
** '''[filter_weapon]''': a [[FilterWML#Filtering_Weapons|standard weapon filter]], including special=.
** '''$other_unit''': {{DevFeature1.13|2}} The special variable $other_unit refers to the defender.
* '''[filter_defender]''' the special will only be active if the defender matches this SUF.
** '''[filter_weapon]''': a [[FilterWML#Filtering_Weapons|standard weapon filter]], including special=.
** '''$other_unit''': {{DevFeature1.13|2}} The special variable $other_unit refers to the attacker.

=== Common keys and tags for specials with a value ===

The '''[damage]''', '''[attacks]''', and '''[chance_to_hit]''' specials take values that specify how those specials modify their respective base values. The '''[drains]''' special takes a value specifying the percentage of damage drained (default 50) and '''[heal_on_hit]''' takes the amount to heal (default 0; negative values will harm the attacker, but not kill).

* '''value''': the value to be used.
* '''add''': the number to add to the base value.
* '''sub''': the number to subtract from the base value.
* '''multiply''': this multiplies the base value.
* '''divide''': this divides the base value.
* '''cumulative''': if set to 'yes', this special will be cumulative with the base value.
* '''backstab''': if set to 'yes', this special will only apply to the attacker, and only when there is an enemy on the target's opposite side (i.e. when the standard backstab special applies). {{DevFeature1.13|2}} This is now deprecated. The same functionality can be achieved with a [filter_adjacent] in [filter_opponent]; see the implementation of the default backstab special for details.
* '''[filter_base_value]''': filters on the value before any modifications; uses the keys '''equals''', '''not_equals''', '''less_than''', '''greater_than''', '''less_than_equal_to''', '''greater_than_equal_to'''.

=== Extra keys used by the ''[berserk]'' special ===

* '''value''': the maximum number of combat rounds (default 1).
* '''cumulative''': if set to 'yes', this special will be cumulative with other active berserk specials (on the current combatant, not with an opponent's berserk).

=== Extra keys used by the ''[plague]'' special ===

* '''type''': the unit type to be spawned on kill.

=== Extra keys used by the ''[swarm]'' special ===

* '''swarm_attacks_max''': the maximum number of attacks for the swarm. Defaults to the base number of attacks modified by any applicable [attacks] specials. If this is specified, then the base number of attacks is ignored.
* '''swarm_attacks_min''': the minimum number of attacks for the swarm. Defaults to zero. This can be set higher than swarm_attacks_max to cause a unit to gain attacks as health decreases.
The ratio of the unit's current to maximum hit points will be used to scale the number of attacks between these two values.

Prior to version 1.11, a [swarm] special will cause [attacks] specials to be ignored. In 1.11 and later, [attacks] specials are applied before [swarm].

=== Macros for common weapon specials ===

* WEAPON_SPECIAL_BACKSTAB
* WEAPON_SPECIAL_BERSERK
* WEAPON_SPECIAL_CHARGE
* WEAPON_SPECIAL_DRAIN
* WEAPON_SPECIAL_FIRSTSTRIKE
* WEAPON_SPECIAL_MAGICAL
* WEAPON_SPECIAL_MARKSMAN
* WEAPON_SPECIAL_PLAGUE
* WEAPON_SPECIAL_PLAGUE_TYPE TYPE
* WEAPON_SPECIAL_POISON
* WEAPON_SPECIAL_SLOW
* WEAPON_SPECIAL_STONE
* WEAPON_SPECIAL_SWARM

== See Also ==

* [[UnitTypeWML]]
* [[SingleUnitWML]]
* [[ReferenceWML]]

[[Category:WML Reference]]

AbilitiesWML

2022-01-28T18:53:07Z

Dwarftough:

{{WML Tags}}
== Abilities and their effects ==

There are two types of abilities: ones that apply to units (called ''abilities'') and ones that only apply when using a particular attack (called ''specials'' or ''weapon specials''). A unit may have multiple abilities and an attack can have multiple specials.

== The ''[abilities]'' tag ==

The following tags are used to describe an ability in WML:

* '''[heals]''': modifies the hitpoints of a unit at the beginning of the healer's turn
* '''[regenerate]''': modifies the hitpoints of a unit at the beginning of the unit's turn
* '''[resistance]''': modifies the resistance of a unit to damage
* '''[leadership]''': modifies the damage of a unit
* '''[skirmisher]''': negates enemy zones of control
* '''[illuminates]''': modifies the time of day adjacent to the affected units
* '''[teleport]''': allows the unit to teleport
* '''[hides]''': renders the unit invisible to enemies
* {{DevFeature1.15|0}} A tag matching a [[#The_.5Bspecials.5D_tag|weapon special tag]], [damage] for example, will confer that weapon special to units based on the given conditions. Most weapon specials are supported; however, '''plagues''', '''heal_on_hit''', and '''swarm''' are not.
Any other name is valid (for example '''[dummy]'''), but will result in an ability that does nothing but report it's there. These tags still use the same common keys and tags as every other ability. '''Note:''' a dummy ability must have an id for the name and description to display.

=== Available formula variables in Abilities and Weapon Specials ===

{{DevFeature1.15|?}} When using formulas in abilities and weapon specials, the following formula variables are available:
* '''self''': (unit) the unit that has the ability
* '''student''': (unit) for leadership-like abilities this is the unit that is adjacent to the unit that has the ability.
* '''attacker''': (unit) for attack-related abilities and weapon specials, this is the attacking unit during the attack.
* '''defender''': (unit) for attack-related abilities and weapon specials, this is the defending unit during the attack.
* '''other''': (unit) the unit whose stats get modified from the ability. For abilities without 'apply_to=opponent' this is always the same as 'student'.

=== Common keys and tags for every ability ===

{{DevFeature1.13|?}} All keys inside any ability that expects a numeric value will also accept formulas using
[[Wesnoth Formula Language]]. In order to use a formula in these keys, you must enclose it in parentheses. However, do not precede those parentheses with a dollar sign like <code>$(...)</code>, since that will erase the <tt>self</tt> variable.

* '''name''': the (translatable) name of the ability.
* '''female_name''': the (translatable) name of the ability when possessed by a female unit. Defaults to ''name'' if not specified.
* '''name_inactive''': the (translatable) name of the ability when inactive. Defaults to ''name'' if not specified; if the ability is supposed to be not displayed when inactive, you must explicitly set ''name_inactive'' to an empty string (nothing after the equals sign).
* '''female_name_inactive''': the (translatable) name of the ability when inactive and possessed by a female unit. Defaults to ''name_inactive'' if not specified.
* '''description''': the (translatable) description of the ability.
* '''description_inactive''': the (translatable) description of the ability when inactive. Defaults to ''description'' if not specified.
* '''special_note''' {{DevFeature1.15|14}} Translatable string, which will be displayed in the unit’s help. See also [[UnitTypeWML#Special_Notes]].
* '''affect_self''': if equal to 'yes' (default), the ability will affect the unit that has it.
* '''affect_allies''': if equal to 'yes', the ability will affect units from the same and allied sides in the specified adjacent hexes. If set to 'no' it will not affect own or allied sides. If not set (default) it will affect units on the same side but not from allied sides.
* '''affect_enemies''': if equal to 'yes' (default is 'no'), the ability will affect enemies in the specified adjacent hexes.
* '''cumulative''': if set to 'yes', this ability will be cumulative with the base value for this ability. ''Beware of the bug with cumulative leadership in 1.16 https://github.com/wesnoth/wesnoth/issues/6466 , more info see below, in "Extra keys used by the ''leadership'' ability" section''.
* '''id''': this ability will not be cumulative with other abilities using this id. Must be present if cumulative is anything other than 'yes'.
* '''[filter]''': [[StandardUnitFilter]] If the unit owning the ability does not match this filter, the ability will be inactive.
* '''[affect_adjacent]''': an adjacent unit that does not match this filter will not receive its effects. There can be multiple [affect_adjacent] tags in a single ability; a unit needs to match any one of these to receive the effects. The side requirement of matching units is defined by the '''affect_allies''' and '''affect_enemies''' keys. If there are no [affect_adjacent] tags, then no adjacent units will receive the effects.
** '''adjacent''': a comma separated list of any combination of these directions: '''n''','''ne''','''se''','''s''','''sw''','''nw'''. (See [[StandardLocationFilter#Directions|notes]])
** '''[filter]''': a [[StandardUnitFilter]]. {{DevFeature1.13|2}} The variable $other_unit refers to the unit owning the ability.
* '''[filter_self]''': if the owner of the ability does not match this filter, it will not receive the effects of the ability. [filter_self] takes a [[StandardUnitFilter]] as argument.
* '''[filter_adjacent]''': if an adjacent unit does not match this filter, the ability will not be active and no-one will receive its affects. Takes extra keys ''adjacent'', ''count'', ''is_enemy'', just like in a [[StandardUnitFilter]], with the one difference that, in the absence of a specified ''count'', all listed directions must match (so, with two directiones eg ''adjacent=n,s'', the default is ''count=2''). In fact, it's really a shorthand for a [filter_adjacent] nested within [filter]. The variables $this_unit and {{DevFeature1.13|2}} $other_unit both work as you'd expect. Multiple [filter_adjacent] can be provided, all of which must pass for the ability to activate.
* '''[filter_adjacent_location]''': like [filter_adjacent], but filters on locations instead of units. This is a shorthand for [filter][filter_location][filter_adjacent_location].
* '''[filter_base_value]''': filters on the value before any modifications; uses the keys '''equals''', '''not_equals''', etc. If several keys are used all have to match.

=== Extra keys used by the ''[heals]'' ability ===

* '''value''': the amount healed.
* '''poison''': can be one of ''slowed'',''cured''. ''slowed'' means poison will not take effect for adjacent units (it's not related to the weapon special "slows").

=== Extra keys used by the ''[regenerate]'' ability ===

* '''value''': the amount healed.
* '''poison''': can be one of ''slowed'',''cured''.

=== Extra keys and tags used by the ''[resistance]'' ability ===

* '''value''': set resistance to this value.
* '''max_value''': maximum resistance value. This value '''must''' be set in order for [resistance] to function.
* '''add''': adds to resistance.
* '''sub''': subtracts from resistance.
* '''multiply''': multiplies resistance value.
* '''divide''': divides resistance value.
* '''apply_to''': a list of damage types; if left out, the ability applies to all types.
* '''active_on''': one of 'defense' or 'offense'; if left out, the ability is active on both.
These keys affect the actual resistance (e.g. -20%), not the damage modifier normally used in [resistance] (e.g. 120).
* '''[filter_weapon]''': {{DevFeature1.15|0}} If present, the resistance ability only takes effect when the owner of the ability uses a matching weapon.
* '''[filter_second_weapon]''': {{DevFeature1.15|0}} If present, the resistance ability only takes effect when the opponent uses a matching weapon.
* '''[filter_student]''': {{DevFeature1.15|0}} If present, the ability only takes effect on units matching this filter.

=== Extra keys used by the ''[leadership]'' ability ===

* '''value''': the percentage bonus to damage.
* '''add''': the percentage bonus to damage.
''Note:'' cumulative leadership works only with '''add''' key in 1.16. With '''value''' key it doesn't stack (https://github.com/wesnoth/wesnoth/issues/6466 ).
* '''[filter_weapon]''': If present, the leadership ability only takes effect when the owner of the ability uses a matching weapon.
* '''[filter_second_weapon]''': If present, the leadership ability only takes effect when the opponent uses a matching weapon.
* '''[filter_student]''': {{DevFeature1.15|0}} If present, the ability only takes effect on units matching this filter.

=== Extra keys used by the ''[illuminates]'' ability ===

Because this ability changes the terrain instead of units on it, affect_self, affect_allies, affect_enemies and [filter_adjacent] have no effect.
* '''value''': the percentage bonus to lawful units. Units with '''alignment=lawful''' do +''value'' % damage when under the influence of a unit with this ability. Units with '''alignment=chaotic''' do -''value'' % damage. Units with '''alignment=neutral''' are unaffected by this ability. Units with '''alignment=liminal''' do -(abs(''value'')) % damage. ''value'' can be a negative number; this is useful if you want to give Chaotic units an advantage instead of Lawful ones.
* '''max_value''': the maximum percentage bonus given.
* '''min_value''': the minimum percentage bonus given.

=== Extra keys used by the ''[hides]'' ability ===

* '''alert''': the displayed text when the unit is discovered. Default "Ambushed!".

=== Extra tags used by the ''[teleport]'' ability ===

* '''[tunnel]''' - a [[DirectActionsWML#.5Btunnel.5D|tunnel tag]] (without the remove key) defining the tunneling source and target hexes, and maybe other conditions. (It automatically applies only to the unit with the ability.) You may use $teleport_unit inside the tunnel tag for filtering purposes.

=== Extra tags and keys used by weapon special abilities ===

* '''[filter_weapon]''': If present, the ability only takes effect when the owner of the ability uses a matching weapon.
* '''[filter_second_weapon]''': If present, the ability only takes effect when the opponent uses a matching weapon.
* '''[filter_student]''': If present, the ability only takes effect on units matching this filter.
* Other keys and tags appropriate to the specific weapon special

=== Macros for common abilities ===

* ABILITY_AMBUSH
* ABILITY_CURES
* ABILITY_HEALS
* ABILITY_ILLUMINATES
* ABILITY_LEADERSHIP_LEVEL_1 to ABILITY_LEADERSHIP_LEVEL_5
* {{DevFeature1.13|2}} ABILITY_LEADERSHIP (replaces the above leadership macros, which are now deprecated)
* ABILITY_NIGHTSTALK
* ABILITY_REGENERATES
* ABILITY_SKIRMISHER
* ABILITY_STEADFAST
* ABILITY_SUBMERGE
* ABILITY_TELEPORT

== The ''[specials]'' tag ==

The '''[specials]''' tag goes inside the '''[attack]''' tag. It can contain the following tags:

* '''[attacks]''': modifies the number of attacks of a weapon
* '''[berserk]''': pushes the attack for more than one combat round
* '''[chance_to_hit]''': modifies the chance to hit of a weapon
* '''[damage]''': modifies the damage of a weapon
* '''[disable]''': disables the weapon
* '''[drains]''': heals the attacker half of the damage dealt
* '''[firststrike]''': forces the weapon to always strike first
* '''[heal_on_hit]''': heals the attacker when an attack connects
* '''[petrifies]''': turns the target to stone
* '''[plague]''': when used to kill an enemy, a friendly unit takes its place
* '''[poison]''': poisons the target
* '''[slow]''': slows the target
* '''[swarm]''': number of strikes decreases as the unit loses hitpoints
Any other name is valid, but will result in an special that does nothing but report it is there.

=== Common keys and tags for every weapon special ===

{{DevFeature1.13|?}} All keys inside any weapon special that expects a numeric value will also accept formulas using [[Wesnoth Formula Language]]. In order to use a formula in these keys, you must enclose it in parentheses.

* '''name''': the (translatable) name of the special.
* '''name_inactive''': the (translatable) name of the special when inactive. Defaults to ''name'' if not specified; if the special is supposed to be not displayed when inactive, you must explicitly set ''name_inactive'' to an empty string (nothing after the equals sign).
* '''description''': the (translatable) description of the special.
* '''description_inactive''': the (translatable) description of the special when inactive. Defaults to ''description'' if not specified.
* '''special_note''' {{DevFeature1.15|14}} Translatable string, which will be displayed in the unit’s help. See also [[UnitTypeWML#Special_Notes]].
* '''id''': this ability will not be cumulative with other specials using this id.
* '''active_on''': one of '''defense''' or '''offense'''; if left out, the special is active on both.
* '''apply_to''': one of '''self''','''opponent''','''attacker''','''defender''','''both''' (default: ''self''). Determines who the effects of this special are applied to.
* '''[filter_adjacent]''': if an adjacent unit does not match this filter, the special will not be active and no-one will receive its effects. Takes extra keys ''adjacent'', ''count'', ''is_enemy'', just like in a [[StandardUnitFilter]]. In fact, it's really a shorthand for a [filter_adjacent] nested within [filter_self], with the one difference that, in the absence of a specified ''count'', all listed directions must match (so, with two directiones eg ''adjacent=n,s'', the default is ''count=2''). The variables $this_unit and {{DevFeature1.13|2}} $other_unit both work as you'd expect. Multiple [filter_adjacent] can be provided, all of which must pass for the ability to activate.
* '''[filter_adjacent_location]''': like [filter_adjacent], but filters on locations instead of units. This is a shorthand for [filter_self][filter_location][filter_adjacent_location].
* '''[filter_self]''': the special will only be active if the owner matches this [[StandardUnitFilter]] (SUF).
** '''[filter_weapon]''': a [[FilterWML#Filtering_Weapons|standard weapon filter]], including special=.
** '''$other_unit''': {{DevFeature1.13|2}} The special variable $other_unit refers to the opponent.
* '''[filter_opponent]''': the special will only be active if the opponent matches this SUF.
** '''[filter_weapon]''': a [[FilterWML#Filtering_Weapons|standard weapon filter]], including special=.
** '''$other_unit''': {{DevFeature1.13|2}} The special variable $other_unit refers to the unit that owns the weapon.
* '''[filter_attacker]''': the special will only be active if the attacker matches this SUF.
** '''[filter_weapon]''': a [[FilterWML#Filtering_Weapons|standard weapon filter]], including special=.
** '''$other_unit''': {{DevFeature1.13|2}} The special variable $other_unit refers to the defender.
* '''[filter_defender]''' the special will only be active if the defender matches this SUF.
** '''[filter_weapon]''': a [[FilterWML#Filtering_Weapons|standard weapon filter]], including special=.
** '''$other_unit''': {{DevFeature1.13|2}} The special variable $other_unit refers to the attacker.

=== Common keys and tags for specials with a value ===

The '''[damage]''', '''[attacks]''', and '''[chance_to_hit]''' specials take values that specify how those specials modify their respective base values. The '''[drains]''' special takes a value specifying the percentage of damage drained (default 50) and '''[heal_on_hit]''' takes the amount to heal (default 0; negative values will harm the attacker, but not kill).

* '''value''': the value to be used.
* '''add''': the number to add to the base value.
* '''sub''': the number to subtract from the base value.
* '''multiply''': this multiplies the base value.
* '''divide''': this divides the base value.
* '''cumulative''': if set to 'yes', this special will be cumulative with the base value.
* '''backstab''': if set to 'yes', this special will only apply to the attacker, and only when there is an enemy on the target's opposite side (i.e. when the standard backstab special applies). {{DevFeature1.13|2}} This is now deprecated. The same functionality can be achieved with a [filter_adjacent] in [filter_opponent]; see the implementation of the default backstab special for details.
* '''[filter_base_value]''': filters on the value before any modifications; uses the keys '''equals''', '''not_equals''', '''less_than''', '''greater_than''', '''less_than_equal_to''', '''greater_than_equal_to'''.

=== Extra keys used by the ''[berserk]'' special ===

* '''value''': the maximum number of combat rounds (default 1).
* '''cumulative''': if set to 'yes', this special will be cumulative with other active berserk specials (on the current combatant, not with an opponent's berserk).

=== Extra keys used by the ''[plague]'' special ===

* '''type''': the unit type to be spawned on kill.

=== Extra keys used by the ''[swarm]'' special ===

* '''swarm_attacks_max''': the maximum number of attacks for the swarm. Defaults to the base number of attacks modified by any applicable [attacks] specials. If this is specified, then the base number of attacks is ignored.
* '''swarm_attacks_min''': the minimum number of attacks for the swarm. Defaults to zero. This can be set higher than swarm_attacks_max to cause a unit to gain attacks as health decreases.
The ratio of the unit's current to maximum hit points will be used to scale the number of attacks between these two values.

Prior to version 1.11, a [swarm] special will cause [attacks] specials to be ignored. In 1.11 and later, [attacks] specials are applied before [swarm].

=== Macros for common weapon specials ===

* WEAPON_SPECIAL_BACKSTAB
* WEAPON_SPECIAL_BERSERK
* WEAPON_SPECIAL_CHARGE
* WEAPON_SPECIAL_DRAIN
* WEAPON_SPECIAL_FIRSTSTRIKE
* WEAPON_SPECIAL_MAGICAL
* WEAPON_SPECIAL_MARKSMAN
* WEAPON_SPECIAL_PLAGUE
* WEAPON_SPECIAL_PLAGUE_TYPE TYPE
* WEAPON_SPECIAL_POISON
* WEAPON_SPECIAL_SLOW
* WEAPON_SPECIAL_STONE
* WEAPON_SPECIAL_SWARM

== See Also ==

* [[UnitTypeWML]]
* [[SingleUnitWML]]
* [[ReferenceWML]]

[[Category:WML Reference]]

UnitTypeWML

2022-01-04T17:17:25Z

Dwarftough: /* Unit Type */ upkeep

{{WML Tags}}

__TOC__

== Unit Type ==

Each '''[unit_type]''' tag defines one unit type. (for the use of [unit] to create a unit, see [[SingleUnitWML]])

Unit animation syntax is described in [[AnimationWML]]. In addition to the animation tags described there, the following key/tags are recognized:
* '''[advancefrom]''': Defines the previous unit type on the advancement tree. Allows a campaign-specific unit to be spliced into an already existing advancement tree. It should generally be used only inside a campaign ifdef, to prevent changes to other campaigns. Since all multiplayer content shares MULTIPLAYER define, using advancefrom changes unit type even if the addon is not actively used. For that reason multiplayer advancefrom may only be used with unit types defined in the same addon - then everyone who has the unit has it with same advancements. This tag makes changes to the ''advances_to'' and ''experience'' keys of a base unit to make it advance into this unit. It takes these keys:
** ''unit'': the id of the base unit from which this unit advances. This adds the unit into the list of units which ''unit'' can advance into.
** ''experience'': (optional) If present the experience needed to advance is set to this value. If there are more than one [advancefrom] tags referencing the same base unit within the same preprocessor scope (e.g. a campaign #ifdef) with experience= keys, the lowest value of these is chosen. Note: this will also lower the experience required to advance to other units which the base unit can advance into.
: If the previous unit type makes use of '''[male]''' and/or '''[female]''' tags, then the current (new) unit type is expected to also. That is, the subtypes defined by those tags will only receive this advancement if the new type has a corresponding tag.
{{DevFeature1.15|4}} '''[advancefrom]''' is deprecated since Wesnoth version 1.15.4 and later; UMC authors are expected to use [[ModificationWML|[modify_unit_type]]] instead.
* '''advances_to''': When this unit has ''experience'' greater than or equal to ''experience'', it is replaced by a unit of the type that the value of ''advances_to'' refers to. All modifications that have been done to the unit are applied to the unit it is replaced by. The special value 'null' says that the unit does not advance but gets an AMLA instead. Can be a comma-separated list of units that can be chosen from upon advancing.
* '''alignment''': one of lawful/neutral/chaotic/liminal (See [[TimeWML]]). Default is "neutral".
* '''attacks''': the number of times that this unit can attack each turn. Default is 1.
* '''cost''': when a player recruits a unit of this type, the player loses ''cost'' gold. If this would cause gold to drop below 0, the unit cannot be recruited. Default is 1.
* '''recall_cost''': {{DevFeature1.13|0}} the default recall cost of units of this type, overriding the recall cost set in scenario [[SideWML|[side]]] tags or the global [[GameConfigWML|[game_config]]] value. Individual units may override this value in [[SingleUnitWML|[unit]]]. A value of -1 is equivalent to not specifying this attribute. {{DevFeature1.15|0}} Units are now recalled for AI sides even if the recall_cost is larger than the unit's worth (essentially its cost, plus potentially a bonus for experience points). In 1.14 and earlier, units were not recalled by the AI in this case even if this was the only recall/recruit action possible to the AI.
* '''description''': (translatable) the text displayed in the unit descriptor box for this unit. Default 'No description available...'.
* '''do_not_list''': Not used by the game, but by tools for browsing and listing the unit tree. If this is 'yes', the unit will be ignored by these tools. {{DevFeature1.13|?}} When placing units in debug mode this unit isn't listed (but can still be placed using the :create command). This restriction is lifted in version <b>1.14.3</b>.
* '''ellipse''': the ellipse image to display under the unit, which is normally team-colored. Default is "misc/ellipse". "-nozoc" and "-leader" are automatically appended for units without zone of control and with canrecruit=yes respectively. The [http://www.wesnoth.org/macro-reference.xhtml#IS_HERO IS_HERO]/[http://www.wesnoth.org/macro-reference.xhtml#MAKE_HERO MAKE_HERO]/[http://www.wesnoth.org/macro-reference.xhtml#UNMAKE_HERO UNMAKE_HERO] macros change the ellipse to/back from "misc/ellipse-hero". Finally, setting this to "none" will cause the unit to not have any ellipses displayed under it regardless of the user's preferences.
::WARNING: Be aware that setting this to "misc/ellipse-hero" for a unit with canrecruit=yes will result in the ellipse being "misc/ellipse-hero-leader", which is not a supported combination (it doesn't have a graphic, and will cause error logs that the graphic is missing).
* '''experience''': When this unit has experience greater than or equal to ''experience'', it is replaced by a unit with 0 experience of the type that the value of ''advances_to'' refers to. All modifications that have been done to the unit are applied to the unit it is replaced by.
* '''flag_rgb''': usually set by [http://www.wesnoth.org/macro-reference.xhtml#MAGENTA_IS_THE_TEAM_COLOR MAGENTA_IS_THE_TEAM_COLOR]; specifies the colours in the base flag to use for team-colouring the unit, expressed as a colour name (such as magenta) or a comma-separated list of RGB values (in hex format).
* '''gender''': has a value of either ''male'' or ''female'', and determines which of the keys ''male_names'' and ''female_names'' should be read. When a unit of this type is recruited, it will be randomly assigned a name by the random name generator, which will use these names as a base. If '''gender''' is not specified it defaults to ''male''.
* '''halo''': an image to place centered on the unit. It is drawn on top of the unit, and on top of surrounding units if the image is larger than one hex. It works similarly to the halo attribute of {{tag|InterfaceActionsWML|item}}, and it can be animated with a comma-separated list of images.
* '''hide_help''': (yes|no) default=no. Determines if the unit type will appear in the in-game help.
* '''hitpoints''': the maximum HP that the unit has, and the HP it has when it is created.
* '''id''': the value of the ''type'' key for units of this type. This is required and must be unique among all [unit_type] tags. An ''id'' should consist only of alphanumerics and spaces (or underscores). ''type'' keys are found in [[SingleUnitWML]] and [[FilterWML]]. For example, id=Drake Flare
::WARNING : characters "$", "&", "*", "-", "(" and ")" are illegal for use in the unit type id and must be avoided because they might lead to corrupted saved games
*'''ignore_race_traits''': 'yes' or 'no' (default). Determines whether racial traits (see [[UnitsWML]]) are applied.
* '''image''': sets the base image of the unit, which is used on the map.
* '''image_icon''': sets the image used to represent the unit in areas such as the attack dialog and the unit image box in the sidebar. [[ImagePathFunctions#Crop_Function|~CROP]] function can be useful here. You can see Loyalists Paladin as an example.
* '''level''': the amount of upkeep the unit costs. After this unit fights, its opponent gains ''level'' experience. See also kill_experience ([[GameConfigWML]]), and leadership ([[AbilitiesWML]]).
* '''upkeep''': the amount of upkeep the unit costs if it differs from its level.
* '''movement''': the number of move points that this unit receives each turn.
* '''movement_type''': See [[UnitsWML#.5Bmovetype.5D|movetype]]. Note that the tags '''[movement_costs]''', '''[vision_costs]''', '''[defense]''', and '''[resistance]''' can be used to modify this movetype.
* '''name''':(translatable) displayed in the Status Table for units of this type.
* '''num_traits''': the number of traits that units of this type should receive when they are recruited, overriding the value set in the [race] tag.
* '''profile''': the portrait image to use for this unit type. You can also set a portrait for an individual unit instead of the whole unit type (see [[SingleUnitWML]]). The engine first looks for the image in the transparent subdirectory and if found that image is used. If not found it will use the image as-is. Depending on the size the engine will or will not scale the image, the cutoff currently is at 300x300. For images which should only be shown on the right side in the dialog append ~RIGHT() to the image.
** If "unit_image" is given instead of a filename, uses the unit's base image as the portrait (in the same manner that unit types without portraits do by default).
* '''small_profile''': the image to use when a smaller portrait is needed than the one used for messages (e.g., in the help system). When this attribute is missing, the value of the '''profile''' attribute is used instead. When present, the heuristic for finding a transparent portrait is disabled for the '''profile''' attribute, so the correct '''profile''' should be set too. If '''profile''' is not present, '''small_profile''' is ignored. Note that image modifiers are allowed; they might be useful for cropping and rescaling a portrait:
small_profile="portraits/elves/transparent/marksman+female.png~CROP(0,20,380,380)~SCALE(205,205)"
profile="portraits/elves/transparent/marksman+female.png"
* '''race''': See {{tag|UnitsWML|race}}. Also used in standard unit filter (see [[FilterWML]]). Mainline Wesnoth features following values: bats, drake, dwarf, elf, falcon, goblin, gryphon, human, khalifate, lizard, mechanical, merman, monster, naga, ogre, orc, troll, undead, wolf, wose. They are defined in /data/core/units.cfg.
* '''undead_variation''': When a unit of this type is killed by a weapon with the plague special, this variation is applied to the new plague unit that is created, whatever its type. For example, if the plague special creates Walking Corpses and undead_variation is set to "troll", you'll get a troll Walking Corpse. Defaults to the undead_variation set in this unit type's race.
* '''usage''': the way that the AI should recruit this unit, as determined by the scenario designer. (See ''recruitment_pattern'', [[AiWML]]). The following are conventions on usage:<br> ** ''scout'': Fast, mobile unit meant for exploration and village grabbing.<br> ** ''fighter'': Melee fighter, melee attack substantially more powerful than ranged.<br> ** ''archer'': Ranged fighter, ranged attack substantially more powerful than melee.<br> ** ''mixed fighter'': Melee and ranged fighter, melee and ranged attacks roughly equal.<br> ** ''healer'': Specialty 'heals' or 'cures'.<br>Note that this field primarily affects recruitment. It also has a small effect on unit movement (the AI tries to keep scouts away from enemies, to some extent). It does not affect the AI's behavior in combat; that is always computed from attack power and hitpoints. Non-standard usages may be used as well.
* '''vision''': the number of vision points to calculate the unit's sight range. Defaults to ''movement'' if not present.
* '''jamming''': the number of jamming points. Defaults to ''0'' if not present. See [[UnitsWML#.5Bmovetype.5D|[jamming_costs]]]
* '''zoc''': if "yes" the unit will have a zone of control regardless of level. If present but set to anything other than "yes," the unit will have no zone of control. If the tag is omitted, zone of control is dictated by unit level (level 0 = no zoc, level 1+ = has zoc).
* '''die_sound''': sets the sound, which is used when the unit dies.
* '''healed_sound''': sets the sound used when the unit is healed in any way (default: heal.wav).
* '''hp_bar_scaling''': Overrides the attribute in ([[GameConfigWML]]).
* '''xp_bar_scaling''': Overrides the attribute in ([[GameConfigWML]]).
* '''bar_offset_x''', '''bar_offset_y''': The offset of the hp and xp bars from the normal bar position of 72x72 unit sprite.

== After max level advancement (AMLA) ==
* '''[advancement]''': describes what happens to a unit when it reaches the XP required for advancement. It is considered as an advancement in the same way as advancement described by '''advances_to'''; however, if the player chooses this advancement, the unit will have one or more effects applied to it instead of advancing.
** '''id''': unique identifier for this advancement; ''Required'' if there are multiple advancement options, or if ''strict_amla=no''.
** '''always_display''': if set to true displays the AMLA option even if it is the only available one.
** '''description''': a description displayed as the option for this advancement if there is another advancement option that the player must choose from; otherwise, the advancement is chosen automatically and this key is irrelevant.
** '''image''': an image to display next to the description in the advancement menu.
** '''max_times''': default 1. The maximum times the unit can be awarded this advancement. Pass -1 for "unlimited".
** '''strict_amla''': (yes|no) default=no. Disable the AMLA if the unit can advance to another unit.
** '''major_amla''': (yes|no) default=no. Sets whether the unit's XP bar is blue(=yes) or purple(=no). In case of more [advancement] tags, if there is one with major_amla=yes, the XP bar will be blue.
** '''require_amla''': An optional list of AMLA ''id'' keys that act as prerequisites for this advancement to become available. Order is not important, and an AMLA id can be repeated any number of times to indicate that another advancement must be chosen several times before this advancement option will become available.
*** example: <tt>require_amla=tough,tough,incr_damage</tt> assumes there exist other [advancement] options called ''id=tough'' and ''id=incr_damage''. Once ''tough'' is chosen twice and ''incr_damage'' is chosen once, then the current [advancement] will become available.
*** ''require_amla=tough,incr_damage,tough'' is an equivalent way of expressing this.
** '''exclude_amla''': {{DevFeature1.13|2}} An optional list of AMLA ''id'' keys that represent AMLAs that are mutually exclusive to this one. Order is not important, and an AMLA id can be repeated. If the unit already has any of the AMLAs that appear once in this list, then this AMLA will not be made available. If an AMLA id appears multiple times in the list, then this AMLA will be made available only if the other AMLA has been chosen less than the number of times it appears in the list. Of course, for this to really make two AMLAs mutually exclusive, you need to add ''exclude_amla'' to both AMLA defintions.
** '''[effect]''': A modification applied to the unit whenever this advancement is chosen. See [[EffectWML]]
** '''[filter]''': A [[StandardUnitFilter]], the advancement will only be available when the unit passes this filter during the time the advancement dialog is shown.

== Attacks ==
* '''[attack]''': one of the unit's attacks.
** '''description''': a translatable text for name of the attack, to be displayed to the user.
** '''name''': the name of the attack. Used as a default description, if ''description'' is not present, and to determine the default icon, if ''icon'' is not present (see below). Non-translatable. Used for the ''has_weapon'' key and animation filters; see [[StandardUnitFilter]] and [[AnimationWML]]
** '''type''': the damage type of the attack. Used in determining resistance to this attack (see {{tag|UnitsWML|movetype|resistance}}). Usually this is one of ''blade'', ''pierce'', ''impact'', ''fire'', ''cold'', or ''arcane'', but it can be set to anything (as long as it contains only letters, numbers, and underscores). When using a custom type, you will need to set its user-visible name using [[LanguageWML]]. {{DevFeature1.15|0}} When showing the icon for a custom damage type in the sidebar, the game will look for a file called icons/profiles/''type''.png under your addon's images folder. For example, the icon for a damage type called ''electric'' would be at images/icons/profiles/electric.png.
** '''[specials]''': contains the specials of the attack. See [[AbilitiesWML#The_.5Bspecials.5D_tag|AbilitiesWML]].
** '''icon''': the image to use as an icon for the attack in the attack choice menu, as a path relative to the images directory. Defaults to the attack's name in the attacks directory (Ex. if ''name=sword'' then default is ''icon=attacks/sword.png'').
** '''range''': the range of the attack. Used to determine the enemy's retaliation, which will be of the same type. The range can be anything (as long as it contains only letters, numbers, and underscores), but the standard values are ''melee'' and ''ranged''. Units can only retaliate against attacks for which they have a corresponding attack of the same range. When using a custom range, you will need to set its user-visible name using [[LanguageWML]]. {{DevFeature1.15|0}} When showing the icon for a custom range in the sidebar the game will look for a file called icons/profiles/''range''_attack.png under your addon's images folder. For example, the icon for a range called ''very_long'' would be at images/icons/profiles/very_long_attack.png.
** '''damage''': the damage of this attack
** '''number''': the number of strikes per attack this weapon has
** '''accuracy''': a number added to the chance to hit whenever using this weapon offensively (i.e. during a strike with this attack, regardless of who initiated the combat); negative values work too
** '''parry''': a number deducted from the enemy chance to hit whenever using this weapon defensively (i.e. during the enemy's strike, regardless of who initiated the combat); negative values work too
** '''movement_used''': determines how many movement points using this attack expends. By default all movement is used up, set this to 0 to make attacking with this attack expend no movement.
** '''attack_weight''': helps the AI to choose which attack to use when attacking, setting it to 0 disables the attack on attack. See the note about weights below.
** '''defense_weight''': used to determine which attack is used for retaliation. This affects gameplay, as the player is not allowed to determine his unit's retaliation weapon. Setting it to 0 disable the attacks on defense. See the note about weights below.
Note: For the weight settings, the engine currently (as of 1.14) recognizes only two situations: >0 (normal) and <= 0 (attack completely disabled), so attack_weight=1 and attack_weight=5 have exactly the same chance of being chosen. https://r.wesnoth.org/t49322

== Other tags ==
* '''[base_unit]''': Contains one attribute, '''id''', which must be the ID of a unit type. If specified, the UnitTypeWML for that unit is copied into this one, as if by [[InternalActionsWML#.5Bset_variables.5D|[set_variables]mode=merge]]. Additionally, the unit will be marked as variation of the base unit in its own help page, but not in the help page of the base unit.

* '''[abilities]''': Defines the abilities of a unit. See [[AbilitiesWML]]

* '''[event]''': Any [event] written inside the [unit_type] tag will get included into any scenario where a unit of this type appears in. Note that such events get included when a unit of this type first appears in the scenario, not automatically when the scenario begins (meaning that ''name=prestart'' events, for example, would usually never trigger). See [[EventWML]] and [[WML_Abilities]]

* '''[variation]''': Defines a variation of a unit. Variations are invoked with an [effect] tag or the variation= attribute in [[SingleUnitWML]]. They are currently used for graphical variations (giving character sprites new weapons) but theoretically you could do anything with it.
** '''variation_id''': Mandatory. The value of '''variation=''' used in SingleUnitWML to choose this variant.
** '''variation_name''': Translatable. The name of the variation, which is displayed in the help and in debug mode. Not setting this looks bad unless combined with '''hide_help'''=yes.
** '''inherit''': if ''yes'', inherits all the properties of the base unit, as if by [[InternalActionsWML#.5Bset_variables.5D|[set_variables]mode=merge]]. Defaults to no.
*** The '''id''' key is always inherited, regardless of the value of '''inherit'''.
** All keys and tags of '''[unit_type]''', except ''[advancefrom]'', ''[base_unit]'', ''[female]'', ''[male]'', and ''[variation]''.

* '''[male]''', '''[female]''': These can specify a variation based on gender for a unit. If these are provided, they will automatically apply based upon the gender of a unit.
** '''inherit''': if ''yes'', inherits all the properties of the base unit, as if by [[InternalActionsWML#.5Bset_variables.5D|[set_variables]mode=merge]]. Defaults to yes.
*** The '''id''' key is always inherited, regardless of the value of '''inherit'''.
** All '''[unit_type]''' tags and keys, excluding ''[advancefrom]'', ''[base_unit]'', ''[female]'', and ''[male]''.
* '''[special_note]''' {{DevFeature1.15|2}} see [[UnitTypeWML#Special_Notes]].

== Special Notes ==

Use of the '''[special_note]''' tags and attributes results in a bulleted list of special notes in the unit type's help page and in the sidebar tooltip for the unit type's name. Prior to 1.15.2, the old format for special notes was simply text included in the '''[unit_type]description''' attribute.

Note that the sidebar tooltip shows the notes for the current unit, but opening the help-browser by right-clicking on a unit shows the notes for generic units of that type. These can be different if the unit has '''[modifications]'''.

Text given in the following attributes will be collected and shown as the special notes for units and unit types:

* {{DevFeature1.15|2}} [unit_type][special_note]note=
* {{DevFeature1.15|2}} [unit][special_note]note= (these are used ''instead of'' any defined in the [unit_type])
* {{DevFeature1.15|14}} [movetype][special_note]note=
* {{DevFeature1.15|14}} [''ability tag name'']special_note=
* {{DevFeature1.15|14}} [attack][specials][''special tag name'']special_note=
* {{DevFeature1.15|14}} [language]special_note_damage_type_''TYPE''=

It's no longer necessary to put these notes in each unit_type's .cfg file, and the macros for doing so are now deprecated.

== See Also ==

* [[AnimationWML]]
* [[ReferenceWML]]
* [[TerrainWML]]

[[Category: WML Reference]]

LuaAPI/wesnoth/map

2021-12-26T05:05:00Z

Dwarftough: /* wesnoth.map.iter */ place_label doesn't exist, that's at least a working snippet (I hope)

<div class="tright"> __TOC__ </div>

{{DevFeature1.15|11}}

This module contains functions for working with the game map. Some of the functions can be called as methods of the map itself. In 1.15.11, there exists only one map in the game context, which can be accessed as [[LuaAPI/types/map|'''wesnoth.current.map''']], while in the map generation context, a map can be created with [[#wesnoth.map.create]] or [[#wesnoth.map.generate]]. In future, it may become possible to create maps on the fly or read them from disk.

=== wesnoth.map.find ===

* {{LuaGameOnly}} '''wesnoth.map.find'''(''filter config'') → ''list of hex references''
* {{LuaGameOnly}} '''wesnoth.map.find'''(''filter config'', [''reference_unit'']) → ''list of hex references''
* {{LuaMapOnly}} '''wesnoth.map.find'''(''map'', ''filter userdata'', [''list of locations'']) → ''list of locations''
* {{LuaMapOnly}} '''wesnoth.map.find_in_radius'''(''map'', ''center'', ''radius'', ''filter userdata'') → ''list of locations''

Returns a table containing all the locations matching the given filter. Locations are stored as a ''hex reference'' which has x and y keys along with a variety of other functions. See [[StandardLocationFilter]] for details about location filters. If a unit is passed, it can be referenced from the filter via the $teleport_unit variable, as well as in WFL formulas used in the filter.

'''Note:''' In older versions of Wesnoth, locations returned from a filter were stored as simple pairs, <syntaxhighlight lang=lua inline>{x,y}</syntaxhighlight>. For compatibility purposes, accessing a location this way (as <syntaxhighlight lang=lua inline>loc[1]</syntaxhighlight> and <syntaxhighlight lang=lua inline>loc[2]</syntaxhighlight>) is still supported.

<syntaxhighlight lang=lua>
-- replace all grass terrains by roads
for i,loc in ipairs(wesnoth.map.find{terrain = "Gg"}) do
wesnoth.current.map[loc] = "Rr"
end
</syntaxhighlight>

The mapgen form of this function uses a different format for the filter which is somewhat experimental. An example of its use:

<syntaxhighlight lang=lua>
local map = wesnoth.map.create(18,18,"Gg")

-- Assume there is some generation code here, so the map is no longer just grass

local F, f = wesnoth.map.filter, wesnoth.map.filter_tags

-- Find all elvish villages
local elf_villages = map:find(F(f.terrain('*^Ve')))

-- Find all great trees within 7 tiles of an elvish keep
local elf_keeps = map:find(F(f.terrain('Kv')))
local nearby_trees = map:find_in_radius(elf_keeps, 7, F(f.terrain('*^Fet')))
</syntaxhighlight>

Possible filter tags for this function are: terrain, all, any, none, notall, adjacent, find_in, radius, x, y, is_loc, formula.

=== wesnoth.map.get ===

* {{LuaGameOnly}} '''wesnoth.map.get'''(''location'') → ''hex reference''

Constructs a [[LuaAPI/types/hex|''hex reference'']] for the specified location.

=== wesnoth.map.matches ===

* {{LuaGameOnly}} '''wesnoth.map.matches'''(''location'', ''filter config'', [''reference_unit'']) → ''boolean''
* {{LuaGameOnly}} ''hex'':'''matches'''(''filter config'', [''reference_unit'']) → ''boolean''
* {{LuaMapOnly}} ''map'':'''matches'''(''location'', ''filter userdata'') → ''boolean''

Returns true if the given location passes the filter. The location can be passed either as two separate x and y parameters or as an object with x and y keys (such as a hex reference or a unit). If a ''reference_unit'' is passed, it can be referenced from the filter via the $teleport_unit variable, as well as in WFL formulas used in the filter.

<syntaxhighlight lang=lua>
local b = wesnoth.map.matches(x, y, {
terrain = "Ww",
wml.tag.filter_adjacent_location{terrain = "Ds,*^Bw*"}
})
</syntaxhighlight>

=== wesnoth.map.on_board ===

* {{LuaGameOnly}}{{LuaMapOnly}} '''wesnoth.map.on_board'''(''map'', ''location'', [''include border?'']) → ''boolean''
* {{LuaGameOnly}}{{LuaMapOnly}} ''map'':'''on_board'''(''location'', [''include border?'']) → ''boolean''

Tests if the specified location is on the map. The final parameter determines whether to count the inaccessible map border tiles as being on the map. It defaults to false.

=== wesnoth.map.on_border ===

* {{LuaGameOnly}}{{LuaMapOnly}} '''wesnoth.map.on_border'''(''map'', ''location'') → ''boolean''
* {{LuaGameOnly}}{{LuaMapOnly}} ''map'':'''on_border'''(''location'') → ''boolean''

Tests if the specified location is on the map's border.

=== wesnoth.map.iter ===

* {{LuaGameOnly}}{{LuaMapOnly}} '''wesnoth.map.iter'''(''map'', [''include border?'']) → ''iterator'' ⇒ ''x'', ''y'', ''terrain code''
* {{LuaGameOnly}}{{LuaMapOnly}} ''map'':'''iter'''([''include border?'') → ''iterator'' ⇒ ''x'', ''y'', ''terrain code''

Iterate over the entire map, possibly excluding the border tiles. For example:

<syntaxhighlight lang=lua>
for x, y in wesnoth.current.map:iter() do
wesnoth.map.add_label{x=x, y=y, text=string.format("%d,%d", x, y)}
end
</syntaxhighlight>

=== wesnoth.map.read_location ===

* '''wesnoth.read_location'''(...) → ''location or nil'', ''number of arguments processed''

Extracts a location from the front of a variadic parameter list. The purpose of this is to make it easy for custom user-defined functions to handle locations in the same way as the built-in API functions do. It returns the location (if it was able to find one) and the number of arguments processed, which can be:

* 0 if nothing resembling a location was found.
* 1 if a location-like object was found. A location-like object can be either an array of two integers ''or'' an object that has numeric x and y keys. Note that a unit userdata satisfies the second criteria, so if a unit is found, its location will be returned.
* 2 if the first two arguments in the list were integers. In this case, they will be taken as the x and y coordinates.

==== Usage example ====

Imagine a function foo with the following signature:

* '''foo'''(''bar : string'', [''home : location''], ''mode : string'', [''target : location''], ''moo : boolean'') → ''boolean''

Using read_location it could be implemented as follows:

<syntaxhighlight lang=lua>
function foo(...)
-- First argument goes in bar
local bar = ...
-- Read location starting at the second argument
local home, n = wesnoth.map.read_location(select(2, ...))
-- note: n will be 0 if a location wasn't found at that position
-- This could be an error, or it could be handled as an optional parameter
-- Next argument after that goes in mode
local mode = select(n + 2, ...)
-- Then read a location into target
local target, m = wesnoth.map.read_location(select(n + 2, ...))
-- Finally, read a parameter into moo
local moo = select(m + n + 2, ...)
-- Do stuff with all these parameters
return true
end
</syntaxhighlight>

With that code, all the following invocations of foo work:

<syntaxhighlight lang=lua>
foo('a', 'b', true) -- both optional locations omitted
foo('a', 1, 2, 'q', 5, 6, false) -- locations given as separate integer parameters
foo('a', 'm', {1, 7}, true) -- first location omitted, second given as 2-element array
foo('a', some_unit, 'z', {x = 5, y = 10}, false) -- a unit also functions as a location
foo('a', 7, 12, 'q', my_leader, true) -- mixing different forms also works
</syntaxhighlight>

=== wesnoth.map.split_terrain_code ===

* '''wesnoth.map.split_terrain_code'''(''code'') → ''base'', ''overlay''

Splits a terrain code into a base and an overlay. If the terrain code did not contain a <tt>^</tt>, then the ''overlay'' will be nil. The returned ''overlay'' or ''base'' can be an empty string if the code begins or ends with a <tt>^</tt>, respectively. Splitting the string <tt>'^'</tt> will result in two empty strings.

=== wesnoth.map.make_bitmap ===

* {{LuaGameOnly}} '''wesnoth.map.make_bitmap'''(''array of locations'') → ''shroud data bitmap''

Constructs a shroud data string such that the locations in the array are unshrouded and all other locations are shrouded. The string will be the minimum size required to fit all the locations.

=== wesnoth.map.parse_bitmap ===

* {{LuaGameOnly}} '''wesnoth.map.parse_bitmap'''(''shroud data bitmap'') → ''array of locations''

Parses a shroud data string and returns a list of the locations that are unshrouded.

=== wesnoth.map.terrain_mask ===

* {{LuaGameOnly}}{{LuaMapOnly}} '''wesnoth.map.terrain_mask'''(''map'', ''pivot'', ''mask'', [''options''])
* {{LuaGameOnly}}{{LuaMapOnly}} ''map'':'''terrain_mask'''(''pivot'', ''mask'', [''options''])

Overlays a terrain mask on the map. Possible options:

* ''is_odd'' - if true, then the mask is interpreted as if it was cut out from an odd map location.
* ''ignore_special_locations'' - if true, then special locations on the mask won't be added to the map.
* ''rules'' - an array of rules. See [[TerrainMaskWML]] for the rule format. This is an array of tables, each of which has the content of a [rule] tag.

=== wesnoth.map.add_label ===

* {{LuaGameOnly}} '''wesnoth.map.add_label'''(''options'')

Adds a label to the map. Takes the same options as the [[InterfaceActionsWML#.5Blabel.5D|[label]]] WML tag.

=== wesnoth.map.remove_label ===

* {{LuaGameOnly}} '''wesnoth.map.remove_label'''(''location'')

Removes a label from the map. Normally this removes a global label, but you can also remove team labels with an extra '''team_name''' parameter, for example:

<syntaxhighlight lang=lua>
-- Removes the label on (3,12) owned by team 'rebels'
wesnoth.map.remove_label{x = 3, y = 12, team_name = 'rebels'}
</syntaxhighlight>

=== wesnoth.map.get_label ===

* {{LuaGameOnly}} '''wesnoth.map.get_label'''(''location'', [''side or team_name'']) → ''label info''

Get the full label info for a label on the specified location. With one argument, it returns a global label; otherwise, it returns a label belonging to the specified team. Passing a side (either a side number or a side userdata) uses that side's team. The returned table contains all the possible options that can be passed to '''add_label'''.

=== wesnoth.map.place_area ===

* {{LuaGameOnly}} '''wesnoth.map.place_area'''(''filter'')

Add a new named area to the map. The filter is a [[StandardLocationFilter]], but it can also contain an '''id''' key and '''[time]''' tags. In order to remove the area later, an '''id''' must be provided. An area with no '''[time]''' tags does not affect the schedule.

=== wesnoth.map.remove_area ===

* {{LuaGameOnly}} '''wesnoth.map.remove_area'''(''id'')

Remove the area with the given ID.

=== wesnoth.map.get_area ===

* {{LuaGameOnly}} '''wesnoth.map.get_area'''(''id or location'') → ''area schedule''

Get the named area with the specified ID, or the area that is active on the specified location (if any). This will return nil if no area is found in either case.

The returned object is a userdata object similar to [[LuaAPI/wesnoth#wesnoth.current|wesnoth.current.schedule]], with the following differences:

* ''schedule''.'''liminal_bonus''' → nil

This key is not supported on area schedules.

* ''schedule''.'''id''' ↔ ''id''

Check or alter the ID of the named area.

* ''schedule''.'''hexes''' ↔ ''array of locations''

Get the list of locations the area affects, or assign a new list of locations. The list may be empty, in which case the area has no effect on time of day and cannot be matched by a location filter.

=== wesnoth.map.set_owner ===

* {{LuaGameOnly}} '''wesnoth.map.set_owner'''(''location'', ''side number'')

Set the owner of a village hex. If the specified hex is not a village, this has no effect. Set the owner to 0 to leave it owned by no-one.

=== wesnoth.map.get_owner ===

* {{LuaGameOnly}} '''wesnoth.map.get_owner'''(''location'') → ''side number''

Get the owner of a village hex. If the specified hex is not a village, or if it is an unclaimed village, this returns 0.

=== wesnoth.map.create ===

* {{LuaMapOnly}} '''wesnoth.map.create'''(''width'', ''height'', ''terrain'') → ''map''
* {{LuaMapOnly}} '''wesnoth.map.create'''(''map data string'') → ''map''

Create a new map, either filled with a given terrain or read from a string.

=== wesnoth.map.generate ===

* {{LuaMapOnly}} '''wesnoth.map.generate'''(''width'', ''height'', ''options'') → ''map''

Generate a map using the [[MapGeneratorWML#The_Default_Generator|default generator]]. The following options are supported:

* '''nplayers'''
* '''nvillages'''
* '''iterations'''
* '''hill_size'''
* '''castle_size'''
* '''island_size'''
* '''island_off_center'''
* '''max_lakes'''
* '''link_castles'''
* '''seed'''

=== wesnoth.map.generate_height_map ===

* {{LuaMapOnly}} '''wesnoth.map.generate_height_map'''(''width'', ''height'', ''options'') → ''array of heights''

Generates a height map such as that used by the [[MapGeneratorWML#The_Default_Generator|default generator]]. The following options are supported:

* '''iterations'''
* '''hill_size'''
* '''island_size'''
* '''center_x'''
* '''center_y'''
* '''flip_format'''
* '''seed'''

=== wesnoth.map.get_direction ===

* '''wesnoth.map.get_direction'''(''from'', ''dir'', [''steps'']) → ''location''

Calculates the hex reached by travelling in the specified direction, which should be a string such as "ne" or "s". It will also honor direction modifiers (the prefix <tt>-</tt> and postfix <tt>:cw</tt> or <tt>:ccw</tt>). The optional third parameter ''steps'' is number of steps to travel in specified direction. Negative ''steps'' is supported to travel in the opposite direction.

=== wesnoth.map.get_relative_dir ===

* '''wesnoth.map.get_relative_dir'''(''from'', ''to'') → ''direction''

Calculates the direction from one hex to another. Possible returns are strings "n", "ne", "nw", "s", "se", "sw" or "". The empty string means no direction, which happens if ''from'' and ''to'' are same.

=== wesnoth.map.rotate_right_around_center ===

* '''wesnoth.map.rotate_right_around_center'''(''loc'', ''center'', ''angle'') → ''location''

Calculates the hex obtained from rotating the specified location around the specified center by the specified angle. The angle is an integer in the range 1..6.

=== wesnoth.map.get_adjacent_hexes ===

* '''wesnoth.map.get_adjacent_hexes'''(''loc'') → ''n'', ''ne'', ''se'', ''s'', ''sw'', ''nw''

Return all hexes adjacent to the specified hex, as six separate return values. This doesn't check whether the hexes are on the map.

<syntaxhighlight lang=lua>
local a, b, c, d, e, f = wesnoth.map.get_adjacent_hexes(3, 3)
local a_x = a[1]
local a_y = a[2]
</syntaxhighlight>

=== wesnoth.map.get_hexes_in_radius ===

* '''wesnoth.map.get_hexes_in_radius'''(''center'', ''radius'') → ''list of locations''

Return all hexes within the given radius, as an array of pairs. This doesn't check whether the hexes are on the map.

=== wesnoth.map.are_hexes_adjacent ===

* '''wesnoth.map.are_hexes_adjacent'''(''loc1'', ''loc2'') → ''boolean''

Tests if two hexes are adjacent.

=== wesnoth.map.distance_between ===

* '''wesnoth.map.distance_between'''(''loc1'', ''loc2'') → ''integer''

Calculates the distance between two hexes. The distance is the number of hexes you would need to travel across to get from the start point to the end point.

<syntaxhighlight lang=lua>
local my_distance = wesnoth.map.distance_between({10, 10}, {20, 20})
</syntaxhighlight>

[[Category:Lua Reference]]

LotI Walkthrough-Part2-Chapter08

2021-11-28T01:27:44Z

Dwarftough: /* Gates of Hell */

'''Part II, Into the Light, Chapter 8, Götterdämmerung'''

'''Generally'''

You'll be fighting a lot of units that are liminal, and have good arcane resistance, so have sources of illumination and darkens and a good mix of attack types.

==Mysterious Invasion==
'''[WHU]''' This one is really easy to lose. Your enemies are very tough. Recruit a mob of walking corpses, who will do pretty much nothing but keep the enemies off your leaders while you whittle them down. Do grab easy kills with your corpses to refresh your ranks where possible. The kids should pretty much stay out of the fight, though pick up some cheap XP at the end if you can.

==Overpowered==
'''[WHU]''' Recruit a castle of walking corpses, then run. Keep the kids covered, while getting to the next castle quickly to recruit another load of fodder. Repeat as necessary. The family moves well and is well protected in the woods. Go for the early finish.

==United==
'''[WHU]''' Efraim can pretty much take care of the southern enemy single-handedly, though if he gets slowed repeatedly so that he cannot advance it might be useful to send a little help. The demons to the west are kind of nasty. Let your allies weaken them up, and use Lethalia to pick off weak units who don't have a lot of friends in the area. When you're ready to go in for the kill, use overwhelming force, like prophets with unholybane. The demons to the east aren't much of a problem, you should be able to roll right over them when you're done in the west.

==Kidnapped==
'''[WHU]''' One castle of units should be plenty. Follow the path southwest, then southeast.

==Investigations==
'''[WHU]''' Sneak around the woods outside of town. When a single unit comes to the edge of the woods, pop out and redeem him, then get back in the shadows. You should have plenty of turns to redeem everyone, then get on with the primary mission, which is to visit about five specific houses. Don't let any of the guards get next to you.

==Gladiatrix==
'''[WHU]''' Grab the gear to the north. Fight a few units, one at a time.

==Unimportant Revolution==
'''[WHU]''' Use caution. Some of the enemy do a LOT of damage, and you don't want to get surrounded by a few of those. Use the river and your allies to wear the enemy down a bit, then overwhelming force focused on killing his most dangerous units. Be sure to check the enemy resistances before recalling.

==The Desert==
'''[WHU]''' Another long scenario where you encounter large groups of dangerous enemies, plus a steady stream of demons from the northeast. There is a cave that runs along the east side of the map with some gold and some goodies, but I have no idea how you could get to it, through it, and back out to the exit within the turn limit. I recall a couple castles, start south and visit the trader, then continue south and fight off a batch of demons. Then it's east to deal with the saurians and a couple other factions, then follow the road southeast and then south. About the time the road pretty much ends, I notice how few turns I have left considering the progress I've made so far, panic, and send one of my leaders to run right around the various factions, ending quite early with no early finish bonus.

==Gladiatrix - The Path to Glory==
'''[WHU]''' Back to the arena, this time with some friends. Some friends that you really, really, want to keep alive. I try to get four units with a lot of HP so that I can block the entrance to the north building, along with some healing. I also like to advance the battlerager as quickly as possible (thorns/weak reflect/reflect), and increase his number of attacks, or anything else I can just to keep him alive. Slow will be crucial here, probably some clever crafting, and don't forget those potions.

==Ruins of Wesnoth==
'''[WHU]''' Efraim can handle the humans alone. Send powerful elves south. A couple of fast, powerful units with slow may be able to rush down and take out the southern leader (he'll show up in a few turns) while the rest of the army draws his forces away. Lethalia and a few quick, powerful units should be able to get into the northern castle before that enemy shows up, hurt him and he should leave the keep open for you to claim (you may not want to stand on his keep before he arrives, at one time bad things would happen if you did).

==Odd World==
'''[WHU]''' There is no early finish bonus, but you really need to move anyway. Your enemies, demons and imps, will be spawning constantly and coming for you from all directions. A force of 15-20 works well, including healers and flyers. Prophets, or other very hard hitting units, with unholybane would be very useful. Villages don't provide any income, but they heal +16. There are items and gold scattered around the map.

'''[WHU]''' You'll also get a wonderful introduction to the most annoying trait in BFW, temptation. If one of your unit starts its turn next to a unit of the opposite gender with temptation, your unit will be unable to attack that turn (unless maybe you use a greater healing potion, I've never tried it, just thought of it). This is especially frustrating when you've been slowed and can't get out of the way. Unlike most special traits, or even some of the basic ones, I'm pretty well convinced the AI knows EXACTLY how to make optimum use of temptation. Keep a couple of fast prophets with unholybane (or similar) behind the front and rear lines to run out an slaughter those demons whenever you see them.

'''[WHU]''' Start off going south until you get to the mountains. Send Lethalia and some flyers or mountain travellers south through the mountains to take out a boss. Send the rest of the army east, where you will fight in the mountains (there is also a path around the mountains for units that can't go through). About the time you get through the mountains and start north, you'll probably need a rather powerful rear guard. Every turn you spent getting through (and around) the mountains, your enemy was spawning units behind (and in front, and to the side) or you. Use penetrates and hit and run, skirmishers, and flyers to ensure you are constantly making forward progress.

'''[WHU]''' Around the time you make sight of the last enemy boss, and you feel confident that you can spare them, send a couple relatively powerful flyers northeast. Between the mountains is a route over a lake of lava that leads to the exit. Have one of your flyers continue to the northeast into a cavern where there are a couple items.

'''[WHU]''' If you have been actively using your redeem attack, you should have noticed that it is starting to sometimes redeem multiple units, particularly when they are low level. Those big packs of imps are just asking to be redeemed.

==Gladiatrix - The Reckoning==
'''[WHU]''' Move slowly, kill everything. At first you'll be attacked out of the dark, then by a much nastier unit that's initially invisible. There's no turn limit, heal as much as you need. Charge out of the building in force, or draw the enemy into the corridor, depending on your strengths. You'll fight a couple enemy units at a time at first. Take out the boss to the northwest, then head southeast. When you get near the southern end of the map, you'll be taking on a bunch of non-trivial enemies (you'll see why I strongly recommended protecting your friends in the arena). If you still have all your arena allies, and you've geared them well and levelled them, just use your unit-specific strengths against against the enemy weaknesses. If not, good luck.

'''[WHU]''' Once you get into the city, it gets much easier, for a little while. Take out the bosses and anyone who breathes your air. Then head north into the building to fight three batches of those nasty demons before heading to the northwest corner exit. You need to fight them on your terms, where only one of them can attack at a time and you can retreat to heal. Each batch will be a bit harder than the one before. It is not uncommon for me to do a major retreat when fighting the third batch, stringing them out so I can pick them off one at a time, often using my unit with teleport to sneak behind them as they chase me.

==The River of Flame==
'''[WHU]''' This is a scenario I've always played in a manner which I suspect is completely unintended. Recall a few powerful units and a couple healers, and maybe a unit or two you want to give some XP. Block the bridges to your starting location, and pick up convenient kills. Meanwhile, Lethalia flies right over the lava, clockwise around the edges of the map, perhaps killing and/or redeeming a few lone units along the way, to meet the troll in the southeast without ever having to actually work for it. Major early finish bonus. Cheater.

==Finally Together==
'''[WHU]''' Focus on elves if you have them. Make the enemy fight your army while you are in the forest and they are on the path. Use your army and Vritra's team to draw the enemy forces away from their leaders, while a few fast, powerful units circle around and assassinate the leaders.

==Jungle Hell==
'''[WHU]''' It's a jungle, so elves are the obvious choice, and they do fine, but while they have good defenses in forests, their natural forest movement isn't of much value here. This is yet another scenario of huge packs of demons that are triggered by your forward progress, so you don't necessarily need to move that fast, and you'll be standing around most of the time anyway. Also, you can do the 'transport all units' to Efraim every 10 turns thing. A lot of the terrain is impassible, for you, but not for some of the demons.

'''[WHU]''' You'll fight two packs of demons at the beginning. I find that Lethalia casting explosive slow on the pack to the east backed up by a few powerful units can take care of them pretty easily, while Efraim and a lot of support (including explosive slow), work on the pack coming up from the south. Let the enemy come to you, don't chase at them and trigger yet another pack.

'''[WHU]''' Once those two are taken care of, I follow the river south and then west, then south through the gap in the woods, and generally make my way south, moving east and west a little where opportunity presents, always keeping the terrain in my favor as much as possible. I don't know that the actual route matters, I've just always gone that way and it works for me. There are plenty of turns for you to move slowly and not trigger too many packs at once. If you fight the demons in the middle of the forest it will limit the number of them which can attack on any one turn.

==Gates of Hell==
'''[WHU]''' No gold carryover, so you may as well spend it. The first three leaders should go down pretty quickly, and then it will get just a bit harder with demons coming from the south, and spawning occasionally from the east and west. When you get to the bottleneck there are two paths, use both of them. Lethalia could use the western path, in case you want to rush the exit. You'll encounter a boss who has a lot of HP and hits hard. Use an explosive slow on an enemy next to him each turn to slow him, then hit him really hard with units that are resistant to impact and cold, perhaps using a holy potion if you don't have unholybane attacks already. You have plenty of turns, in theory you could incinerate him and then draw him into the open where you could hit him many more times per turn, possibly even running Lethalia around behind him to the exit, but I've never found that necessary.

'''[dwarftough]''' An important note, I believe, for higher diffuclties: here you have to think and equip Krux and Vritra in the best items. You will begin Chapter 10 without your main storage, with only a few gems and random items, and the only items you can carry over there are items equipped on Krux and Vritra. It probably makes sense to give them some premier items, ofc you need items for Chapter 9 on Efraim/Lethalia/their soldiers, but they have the whole Inferno to pillage before the most difficult fights. Particularly I think that if you have the heal+40 ring, you'd better equip it on Krux/Vritra. In Chapter 9 you have all your recall list and most likely a lot of healers, in chapter 10 you have quite few against demon hordes, and Krux's the only basic healer

[[LotI_Walkthrough|Back]]

LotI Walkthrough-Part2-Chapter10

2021-11-28T01:22:28Z

Dwarftough:

'''Part II, Into the Light, Chapter 10, Dawning of a New Era'''

'''Generally'''

This section needs info.

'''[dwarftough]''' I haven't really played this chapter recently but I believe in the beginning of this chapter a lot depends on which items you carried out from chapter 8 on Vritra and Krux (cause that's the only two with their items who got carried through). So it's worth thinking about it in Chapter 8 and probably equip Krux and Vritra in the best possible items there (for Efraim and Lethalia you have vast Inferno to loot items). For example, I would prefer to carry heal +40 Cactus ring here, not in Chapter 9 (in Chapter 9 you probably have enough heal and healers even without this ring).

==Despair==

'''[WHU]''' Back to Krux and Vritra, along with a batch of new loyal allies. You have no recall list, no items in storage (but you do have your gem collection), and several items on the ground. You are going to be encountering some tough enemies, and you want to protect your loyal units, and you probably have a decent gem collection, so now is the time to do some crafting. I like Forestburner melee weapons for my units that do not, and in particular will not after advancing, have ranged attacks. Wretched Defiler gives one more attack, and creates undead that can be used as fodder, a good choice for units with few powerful attacks, such as a paladin. At a minimum, lots of Konrad's Might weapons and Mastadon armor items.

'''[WHU]''' Move forward (north), slowly and carefully, and remember to check the demons' stats carefully. There are caves to be explored, some good, some bad. It's best to enter a cave with a few movement points remaining, the gryphon rider with speed upgrade is good for that. Try to take out the enemies one at a time with overwhelming force. No early finish bonus, and plenty of turns, it may be a good idea to go after some XP here, if possible.

==And Another Orcish Assault==

'''[WHU]''' I have absolutely no idea what to do with this one. The demons are so powerful, and the orcs just suicide all of their forces on them, usually one with regrowing, doing little to no damage. The only way to win is not to play.

==Fimbulwinter==
'''[WHU]''' Again, no idea. If there were more turns, I'd capture some villages and keep recruiting fodder so I could take on the superior demons one or two at a time. But there's not enough turns to begin with. I usually get to about turn 4 or 5 before I remember that I hate this chapter and quit. That's probably not the recommended strategy. Maybe I need to spend a lot more time crafting in the first scenario.

==Betrayers of Humankind==
'''[WHU]''' Finally. You have to kill a demon leader, then Delly. You don't get any extra turns, so you want to make sure you're making progress towards her. This is mostly a straight up fight where you can use terrain to your advantage. I like to use walking dead to screen and distract the enemy.

==The Chase==
'''[WHU]''' A castle of recalls is plenty. Move forward and find terrain advantage, fight off the first wave and take out Delly. Assume position in "her" castle, using the mountains for cover if the next wave contains strong mounted units with charge. There's a cave with villages and loot in the northwest, a fast gryphon rider would be great to explore it. There's another cave to the east and just south of the second castle. Defeat the second wave, advance and take out Delly, again. The third time you defeat her the objectives will change, so make sure you do it at the beginning of a turn and when your army is present and not lagging behind. This would be a good time to recruit a few units to gather some XP.

==Truth==
'''[WHU]''' A quick fight. Recall a front line that can get hit hard, and then a second force to push the counterattack forward while the front line heals.

==Borders==
'''[WHU]''' Proceed southwest to your keep, and clean it out. Recall a couple of castles. A couple fast flying units will be helpful. Let your ally do a lot of the fighting, or at least the dying part. Send several units to help your ally deal with the enemies coming up from the south, then probably no more than a couple to help finish off the southern leader and collect the goods.

'''[WHU]''' Most of the fight will be along the river to the west of your keep. Keep it well covered so the enemy can't cross, leaving his forces to die in the icy river. Once the western enemy has used up most of his forces, send a few units to kill the leader, and start your push northwest.

==Empire of Twilight==
'''[WHU]''' Recruit/recall heavily (like 20 units), as you will be fighting on several fronts at once. There is a cave just to the northeast with some nasty demons. If you follow the obvious path mostly southwest, you'll find a castle in the center. At this point, you'll have enemies constantly upon you from the west and south, and soon possibly demons from the northeast. There's a castle directly to the south that is constantly recruiting, so either split your force and take out that leader as quickly as possible, or milk some XP. Watch out for skirmishers and fast moving units with charge who can get behind your lines to attack your injured units.

'''[WHU]''' Once the first two enemies are dispatched, head west through the gap in the mountains and take out the third group (or fourth if you went into the cave). Send someone almost directly south, staying just west of the mountains and you will find the entrance of a cave that leads southeast to an optional scenario. Here you have a choice, there are two more leaders to the west, who will be triggered if you move even a few tiles west of the third castle. They are just mid-level humans, though they have some chargers who can hit you out of the shroud. Fight them for XP, or don't trigger them and sneak away (with one unit) through the southern cave.

==Trolls==

'''[WHU]''' There aren't a lot of turns here to find and kill ALL dwarves (not just the leaders), so make sure your army can move through caves. Several whelps would be useful for scouting, and generally getting in the way of dwarves that might surprise you. There are two dwarf castles, one in the center of the map and one to the southeast of center.

==Corrupted Town==

'''[WHU]''' Supposedly, you're to use the frozen hills to protect you from the first wave, then counterattack. Doesn't work for me, because the "first" wave never ends. If you try it that way, make sure you are using units that move well on frozen hills so you can rotate them out successfully.

'''[WHU]''' The enemy leaders have a pretty healthy incoming, and will just keep recruiting. Every unit you kill is just less they have to spend on support. They can't recruit if you kill them, or at least knock them off their keep, so I say, "ATTACK!". Using overwhelming force, head out quickly. Bring along a handful of fodder to protect your army, I like whelps due to the low price, decent pierce protection, and regeneration. Ideally, your army would be powerful enough to split and take out the two southernmost leaders in the first line, ending their recruitment as quickly as possible. Then the smart move is probably to end the northeast leader, then sweep west. Ignoring the northeast leader is possible, but not simple.

'''[WHU]''' There are a lot of units that are in castle that have no keep. They will remain stationary until you get to close, so concentrate on killing those enemy leaders (that you need to, remember the objective is to reach the temple, not kill all enemy leaders) carefully. Like most of this chapter, I like to make extensive use of walking corpses to shield my troops, particularly from charging units. I also recruit a lot of fodder (whelps and goblin spearmen) to shield my army and delay my pursuers when I am ready to move from one castle to another. Watch carefully for the demons that look like humans, but are very, very much stronger.

==Idols Falling==

'''[WHU]''' Play each step perfectly. Be very, very lucky. Run out of turns before you can reach the enemy leader.

==Miracle==

'''[WHU]''' You are going to be hit, hard, initially, so use some fodder to protect your key units. Again, I like whelps here, lots of them. To the northeast are demons with temptation, so be sure to send a mix of genders, and more than one of each so you can rotate them out as necessary. To the southeast are imps, a couple of good units with a lot of blade resistance should take most of them out on defense. The rest are demons.

==Rush==

==Black Souls==

'''[WHU]''' I managed to complete this within the turn limit, once, but only because Grumbul had a pretty good Eidolon set giving him unholybane, along with Dark Dragon legacy upgrades for arcane penetration.

==End of the World==

'''[WHU]''' This scenario is basically a victory lap. All you have to do is keep Efraim and Lethalia from being attacked, and don't move them. You could simply recall everything you can, surround them, and wait. But you also have your entire recall list, gem selection, and inventory from Part II, you could experiment with all kinds of combinations of gear, build some superheroes, and go on offense. It's a game. Play it your way, and have fun.

[[LotI_Walkthrough|Back]]

LotI Walkthrough-Part1-Chapter01

2021-11-15T00:14:42Z

Dwarftough: /* The Assassination */

'''Part I, Embracing the Darkness, Chapter 1, Ascension'''

'''Generally'''

This section needs info.

'''[WHU]''' Your recruit/recall lists, as well as available gold, are going to vary widely. Some units will rarely be available for recruiting, potentially preventing you access to their high level advancements. You may want to recruit at least a couple of all the basic unit types, particularly when you are flush with gold, so that they will (usually) be available on the recall list.

==An Orcish Assault==
'''[WHU]'''A classic frontal assault is difficult and time consuming. I will send one or two units west to collect villages, and Delenia (Delly) south along the east edge. Send a couple other units, perhaps rogues, west then south going around the Orc forces to eventually meet Delly at the Orc keep for some glorious backstabbing. While keeping Efraim protected, allow the orcs to enter the city, at which point Lord Redain's troops will become active.

'''[WHU]'''Pick up dropped items and store them or give them to your leaders, your troops are too junior at this point and if you give them items and they die the items are lost.

'''[WHU]'''Steal all your ally's villages, he doesn't need them.

'''[WHU]'''If you recruit any loyal units, they should probably hide behind the lines for future service.

==The Assassination==

'''[WHU]'''Recruit or possibly recall (Mario) very lightly, the fight will be quick and in close quarters. Grab all the villages, you have plenty of time. There is usually a nice item to the northeast, but it's covered by a unit that doesn't die easily, and by the time you kill him either the scenario has ended or some very bad dudes have come up behind you. Travel northwest, then south. Make sure all of your units are in place with full movement before you step into the chamber. Usually Mario will be one XP from levelling up, so give him the first hit. On lower difficulties you can make great use of backstab here, but even on hard Redain should go down in a turn or two.

'''[dwarftough]'''You can backstab Redain on any difficulty, you just need to place your unit on the stabbing square when swords are in the same team and don't block your way. The fight is trigger only when you step on a hex adjacent to Redain

==Banished==
'''[WHU]'''Start with a couple recruits/recalls, focusing on speed. Send Delly west (assuming she still has the Twinkling Sword and its +2 move), and the rest of the units generally following the course of the road but a few tiles to either side, finding and taking villages. Do not get too close to the river until Efraim can get across and into the keep in one turn. Recruit lots of bowmen and poachers depending on time of day, and be aggressive about moving them out of the castle so you can recruit more. Any loyal recruits and seriously injured or poisoned units can be sent north across the river for healing and safety. Efraim should find plenty of cheap kills, keep him protected and he can probably level a couple times (I focus on advancements that make him hard to hit). Once the initial wave of enemies are beaten back, charge south for the easy finish.

==Paradise Lost==
'''[WHU]'''The turn limit is tight here. You are probably going to lose some units as the trolls and orcs come across the river, so initially recruiting fodder is helpful, but save some gold for additional recruits and possibly recalls ''after'' you take the central orc keep (you don't want a bunch of units getting bogged down in the river). Pay attention to the terrain at the river bank.

'''[WHU]'''Lethalia generally needs at least a little help, so at a minimum send Delly west and then south, picking up villages along the way. Once you take the central orc keep, you may want to recruit/recall more than you think you would normally need, as the villages are hard to get to if you need to heal, and any units you had healing north of the river probably won't have time to reach the other castles. If you haven't already, send a couple quick units to assist Delly, even if it's just picking up dropped items.

==Shatter the Defilers==
'''[WHU]'''You have a bunch of elves in the forest. There's a river. Not real difficult. Send the elves east of the river south to gather villages, then west. Send a couple elves west and then south gathering villages. Recruit/recall heavily from the second keep, you're going to have a lot of income and a nice early finish bonus. Kill the orcs in the river, then finish off the leaders.

'''[WHU]'''The next scenario is not difficult, but it is useful to have a decent number of troops and you won't be able to recruit, only recall, so you may want to recruit units now that you don't actually need if your recall list is sparse.

==The Ruins of Lost Empires==

'''[WHU]'''The in-game walkthrough says something about killing the SW leader to get the other factions to fight. I've never seen the point. Recall a couple castles worth of troops. Send half north of the river to fight orcs, half across the bridge to fight trolls. The orcs will go down easily, find the gap in the mountains to the west and encounter the elves. No reason to send many troops to help the elves, there are bottlenecks that will limit the fighting. Send most of the northern forces south along the river, then southwest following the road, while the southern force heads southeast to take out the trolls then southwest to take out another orc leader.

'''[WHU]'''When you kill the northwest leader, send those troops south. When you spot the southwest leader, send some troops northwest into the mountains. Yes, you did just finish about 60 turns early, with a nice fat bonus. Also, early finishes like that will eventually add up to unlocking a secret boss fight.

==The Return==
'''[WHU]'''Pay attention to what Delly says at the beginning, in the Items menu there is an option to remove and store all items which you will want to use on here. Recall a few units, high HP and impact resistance and/or ranged units with marksman . Stick together and stay on the path as much as possible. As you move forward you will trigger packs of bandits, so do not run ahead. There are not a lot of turns, but enough to kill one pack of enemies at a time as long as you keep moving slowly forward.

==Where the Sun Does not Shine==
'''[WHU]''' Head south, east, then southeast. You have plague, use the walking corpses to distract the bats and keep moving. You will come to a corridor where you will start to head north. You can leave Argan there in a one tile wide passage to block the bats. Send someone northwest to pick up an item, though your true target is the passage that starts northeast and then quickly turns southeast. When you come to a deep water river, if you can send someone south to pick up an item, while the rest head northwest and then southwest.

'''[WHU]''' This scenario has no early finish bonus, and as long as you keep moving and do not get surrounded by bats before you start heading north you should finish with around 30 turns left. You could spend a couple dozen turns farming XP from bats, but since they are often level 0, I like to finish early to help attract the previously mentioned boss instead.

==Escape from Oblivion==
'''[WHU]''' As long as you don't get unlucky and get bogged down by bats in the beginning, this one is pretty easy. Follow the path until it starts to head northwest, then be careful. When you get to a certain point, the undead will start spawning and you need Efraim to get to the keep in time to start recalling. One thing you definitely do not want to do is have Lethalia fly over the lava, skipping the path entirely and triggering the undead long before Efraim can catch up.

'''[WHU]''' Recall some Elfish Sorceresses and Druids and Heavy Infantry, or other units that do impact and arcane damage, and some good archery units to take out walking dead. If you position your units well around y=21, with powerful units up front and healers and leaders just behind them and rotate out the injured, the wave of undead are pretty easy to deal with. Then just carefully move forward and kill the leader. There are quite a few areas that are lit which will negate the undead's advantage here, though I've never really felt the need to make use of them.

==The Poison==
'''[WHU]''' This one can be tricky due to the time limit if you try to stand and fight. You need to be moving ahead. When you finally get to the dragon, he'll often fly away, so you'll probably need a few turns to chase him around. A fast, flying, Lethalia can help pin him down.

'''[WHU]''' Chocobones are good at charging drakes. They may seem a little expensive, but you should have plenty of gold at this point. I'll use (okay, waste) a couple castles worth of them, often doing almost enough damage to leave the XP for the kill for units I actually care about. I don't worry much about rotating them out to heal, they are simple fodder to pound forward.

==Ascension==
'''[WHU]''' Sit on a village and kill ghosts. Once you have injured one, it will join your team if it dies. Use zone of control to trap your enemies so they can't heal.

'''[dwarftough]''' I always wonder if it's possible to use ghosts in the middle. I usually just sit in the village near the starting spot or around and enslave everyone who attacks me. And those ghosts in the middle just wail at each other and destroy each other usually not affecting the battle of yours.

==Toxic Sun==
'''[WHU]'''Efraim and Lethalia have a new unit type and abilities, make sure to check them out, in particular penetrates. Every time they get a kill they will receive a soul eater point. When they get enough points, a new AMLA will be unlocked.

'''[WHU]''' Welcome Skellie and Ethiel! Protect them and they will become valuable allies. Get moving with your heroes right away, no need to recruit. Leave a few of the level 1 units to collect villages and generally trail behind. Kill the troll leader, then send a couple low level units north and northeast to collect villages. Drive south, relying mostly on your heroes, then about halfway down the exit is to the east. There are some decent items available to the south and southwest, but you probably won't have enough turns to collect them. Watch out for shadows sneaking up behind you and killing your weaker units.

==Twilight==
'''[WHU]''' Recall units that can do fire, arcane, and maybe impact damage AND move well on frozen. Elfish Sorceresses work well. Note that all of the icy enemies have frozen aura, so you're going to be spending a lot of time slowed, anything that is already slow on frozen terrain is probably useless here. Having enough units to rotate in forces which are not slowed helps. In the beginning, be very wary of gryphons with their extreme range. Once the initial gryphons are killed, you won't need to worry about any more or the leader.

'''[WHU]''' Send a unit south to collect villages and the loot dropped from your ally's battle with the icy monsters and yeti. He normally will not require any help, and if he does you probably won't get there in time.

'''[WHU]''' Send the bulk of your force southeast. Try to make sure you are always advancing while you fight. The enemy leader has a high income, so hit him hard with Lethalia, and when he runs to the village to heal plant a defensive unit on his keep (in the snow on the bank of the pond).

==Shadow Empire==
'''[WHU]''' This scenario is deceptively easy, if you don't screw up one little detail. Immediately send several wraiths and shadows with Lethalia southeast then south to come up behind Zorox. The key here is that you want to kill him on the same turn you first hit him. If he lives, he'll move off his keep and you will have to fight your way through his forces. If you kill him (with Lethalia!), all of the generals will become allies and the fight becomes trivial. Obviously, you also want to do this as quickly as possible. Use Lethalia and your ghosts to clean up the units that make their way to this castle and gather up villages. Then send Lethalia around the map picking up dropped goodies.

'''[WHU]''' Meanwhile, Efraim and the rest of the army head south down the road, across the bridge, and kill the two necromancers, grabbing every village along the way. Move quickly, there's a huge early finish bonus.

==Long Way Home==
'''[WHU]''' Argan warns you he's leaving, so strip his gear. Recall a handful of units, ones that can take a punch and a healer. Fight a small pack of orcs, then a few trolls, and then visit the trader and see what he has to sell by moving next to him. I like to buy lots of pearls to craft Mastadon items. You can leave a unit here, especially one that does not travel (well) in mountains, to buy more items later. At this point, Efraim and Lethalia can easily handle the rest of the fighting, and there will be plenty of villages to provide incoming, assuming you recalled lightly. If you decide to forgo the early finish bonus so you can keep buying items, be aware that while the objectives say to move Efraim to the southern border of the map, you really only need to get close, and at least one of the southern villages you might be tempted to take is close enough to end the scenario.

==The Battle for Ogira==

'''[WHU]''' Recall elves with Lethalia, other units with Efraim (though his group will probably want a druid or two). Moving Skellie to a village near your castle is usually enough to keep the purple orcs in check, while Efraim takes out the white leader. Note that he starts with a lot of gold, so killing him quickly will shorten the fight, but you will forgo a lot of XP. Once white is vanquished, head into the city. A couple strong units should be enough to take out purple.

'''[WHU]''' Lethalia's force moves west through the woods to take out the orange and then green leaders. It's worth sending one or two units north to collect villages. Normally, Delly won't need any assistance, but you may want to send a handful of units into the city, if nothing else than to
collect dropped items and pick up some XP.

'''[WHU]''' Argan will arrive soon and pretty much take out one team on his own. Nice to have a great sword and be invincible.

[[LotI_Walkthrough|Back]]

LotI Walkthrough-Part1-Chapter01

2021-11-03T16:50:40Z

Dwarftough: /* Ascension */

'''Part I, Embracing the Darkness, Chapter 1, Ascension'''

'''Generally'''

Add here.

==An Orcish Assault==
'''[WHU]'''A classic frontal assault is difficult and time consuming. I will send one or two units west to collect villages, and Delenia (Delly) south along the east edge. Send a couple other units, perhaps rogues, west then south going around the Orc forces to eventually meet Delly at the Orc keep for some glorious backstabbing. While keeping Efraim protected, allow the orcs to enter the city, at which point Lord Redain's troops will become active.

'''[WHU]'''Pick up dropped items and store them or give them to your leaders, your troops are too junior at this point and if you give them items and they die the items are lost.

'''[WHU]'''Steal all your ally's villages, he doesn't need them.

'''[WHU]'''If you recruit any loyal units, they should probably hide behind the lines for future service.

==The Assassination==

'''[WHU]'''Recruit or possibly recall (Mario) very lightly, the fight will be quick and in close quarters. Grab all the villages, you have plenty of time. There is usually a nice item to the northeast, but it's covered by a unit that doesn't die easily, and by the time you kill him either the scenario has ended or some very bad dudes have come up behind you. Travel northwest, then south. Make sure all of your units are in place with full movement before you step into the chamber. Usually Mario will be one XP from levelling up, so give him the first hit. On lower difficulties you can make great use of backstab here, but even on hard Redain should go down in a turn or two.

==Banished==
'''[WHU]'''Start with a couple recruits/recalls, focusing on speed. Send Delly west (assuming she still has the Twinkling Sword and its +2 move), and the rest of the units generally following the course of the road but a few tiles to either side, finding and taking villages. Do not get too close to the river until Efraim can get across and into the keep in one turn. Recruit lots of bowmen and poachers depending on time of day, and be aggressive about moving them out of the castle so you can recruit more. Any loyal recruits and seriously injured or poisoned units can be sent north across the river for healing and safety. Efraim should find plenty of cheap kills, keep him protected and he can probably level a couple times (I focus on advancements that make him hard to hit). Once the initial wave of enemies are beaten back, charge south for the easy finish.

==Paradise Lost==
'''[WHU]'''The turn limit is tight here. You are probably going to lose some units as the trolls and orcs come across the river, so initially recruiting fodder is helpful, but save some gold for additional recruits and possibly recalls ''after'' you take the central orc keep (you don't want a bunch of units getting bogged down in the river). Pay attention to the terrain at the river bank.

'''[WHU]'''Lethalia generally needs at least a little help, so at a minimum send Delly west and then south, picking up villages along the way. Once you take the central orc keep, you may want to recruit/recall more than you think you would normally need, as the villages are hard to get to if you need to heal, and any units you had healing north of the river probably won't have time to reach the other castles. If you haven't already, send a couple quick units to assist Delly, even if it's just picking up dropped items.

==Shatter the Defilers==
'''[WHU]'''You have a bunch of elves in the forest. There's a river. Not real difficult. Send the elves east of the river south to gather villages, then west. Send a couple elves west and then south gathering villages. Recruit/recall heavily from the second keep, you're going to have a lot of income and a nice early finish bonus. Kill the orcs in the river, then finish off the leaders.

'''[WHU]'''The next scenario is not difficult, but it is useful to have a decent number of troops and you won't be able to recruit, only recall, so you may want to recruit units now that you don't actually need if your recall list is sparse.

==The Ruins of Lost Empires==

'''[WHU]'''The in-game walkthrough says something about killing the SW leader to get the other factions to fight. I've never seen the point. Recall a couple castles worth of troops. Send half north of the river to fight orcs, half across the bridge to fight trolls. The orcs will go down easily, find the gap in the mountains to the west and encounter the elves. No reason to send many troops to help the elves, there are bottlenecks that will limit the fighting. Send most of the northern forces south along the river, then southwest following the road, while the southern force heads southeast to take out the trolls then southwest to take out another orc leader.

'''[WHU]'''When you kill the northwest leader, send those troops south. When you spot the southwest leader, send some troops northwest into the mountains. Yes, you did just finish about 60 turns early, with a nice fat bonus. Also, early finishes like that will eventually add up to unlocking a secret boss fight.

==The Return==
'''[WHU]'''Pay attention to what Delly says at the beginning. Recall a few units, high HP and impact resistance and/or ranged units with marksman . Stick together and stay on the path as much as possible. As you move forward you will trigger packs of bandits, so do not run ahead. There are not a lot of turns, but enough to kill one pack of enemies at a time as long as you keep moving slowly forward.

==Where the Sun Does not Shine==
'''[WHU]''' Head south, east, then southeast. You have plague, use the walking corpses to distract the bats and keep moving. You will come to a corridor where you will start to head north. You can leave Argan there in a one tile wide passage to block the bats. Send someone northwest to pick up an item, though your true target is the passage that starts northeast and then quickly turns southeast. When you come to a deep water river, if you can send someone south to pick up an item, while the rest head northwest and then southwest.

'''[WHU]''' This scenario has no early finish bonus, and as long as you keep moving and do not get surrounded by bats before you start heading north you should finish with around 30 turns left. You could spend a couple dozen turns farming XP from bats, but since they are often level 0, I like to finish early to help attract the previously mentioned boss instead.

==Escape from Oblivion==
'''[WHU]''' As long as you don't get unlucky and get bogged down by bats in the beginning, this one is pretty easy. Follow the path until it starts to head northwest, then be careful. When you get to a certain point, the undead will start spawning and you need Efraim to get to the keep in time to start recalling. One thing you definitely do not want to do is have Lethalia fly over the lava, skipping the path entirely and triggering the undead long before Efraim can catch up.

'''[WHU]''' Recall some Elfish Sorceresses and Druids and Heavy Infantry, or other units that do impact and arcane damage, and some good archery units to take out walking dead. If you position your units well around y=21, with powerful units up front and healers and leaders just behind them and rotate out the injured, the wave of undead are pretty easy to deal with. Then just carefully move forward and kill the leader. There are quite a few areas that are lit which will negate the undead's advantage here, though I've never really felt the need to make use of them.

==The Poison==
'''[WHU]''' This one can be tricky due to the time limit if you try to stand and fight. You need to be moving ahead. When you finally get to the dragon, he'll often fly away, so you'll probably need a few turns to chase him around. A fast, flying, Lethalia can help pin him down.

'''[WHU]''' Chocobones are good at charging drakes. They may seem a little expensive, but you should have plenty of gold at this point. I'll use (okay, waste) a couple castles worth of them, often doing almost enough damage to leave the XP for the kill for units I actually care about. I don't worry much about rotating them out to heal, they are simple fodder to pound forward.

==Ascension==
'''[WHU]''' Sit on a village and kill ghosts. Once you have injured one, it will join your team if it dies. Use zone of control to trap your enemies so they can't heal.

'''[dwarftough]''' I always wonder if it's possible to use ghosts in the middle. I usually just sit in the village near the starting spot or around and enslave everyone who attacks me. And those ghosts in the middle just wail at each other and destroy each other usually not affecting the battle of yours.

==Toxic Sun==
'''[WHU]'''Efraim and Lethalia have a new unit type and abilities, make sure to check them out, in particular penetrates. Every time they get a kill they will receive a soul eater point. When they get enough points, a new AMLA will be unlocked.

'''[WHU]''' Welcome Skellie and Ethiel! Protect them and they will become valuable allies. Get moving with your heroes right away, no need to recruit. Leave a few of the level 1 units to collect villages and generally trail behind. Kill the troll leader, then send a couple low level units north and northeast to collect villages. Drive south, relying mostly on your heroes, then about halfway down the exit is to the east. There are some decent items available to the south and southwest, but you probably won't have enough turns to collect them. Watch out for shadows sneaking up behind you and killing your weaker units.

==Twilight==

==Shadow Empire==

==Long Way Home==

==The Battle for Ogira==

[[LotI_Walkthrough|Back]]

LotI Walkthrough-Part1-Chapter01

2021-11-03T16:50:33Z

Dwarftough: /* Ascension */

'''Part I, Embracing the Darkness, Chapter 1, Ascension'''

'''Generally'''

Add here.

==An Orcish Assault==
'''[WHU]'''A classic frontal assault is difficult and time consuming. I will send one or two units west to collect villages, and Delenia (Delly) south along the east edge. Send a couple other units, perhaps rogues, west then south going around the Orc forces to eventually meet Delly at the Orc keep for some glorious backstabbing. While keeping Efraim protected, allow the orcs to enter the city, at which point Lord Redain's troops will become active.

'''[WHU]'''Pick up dropped items and store them or give them to your leaders, your troops are too junior at this point and if you give them items and they die the items are lost.

'''[WHU]'''Steal all your ally's villages, he doesn't need them.

'''[WHU]'''If you recruit any loyal units, they should probably hide behind the lines for future service.

==The Assassination==

'''[WHU]'''Recruit or possibly recall (Mario) very lightly, the fight will be quick and in close quarters. Grab all the villages, you have plenty of time. There is usually a nice item to the northeast, but it's covered by a unit that doesn't die easily, and by the time you kill him either the scenario has ended or some very bad dudes have come up behind you. Travel northwest, then south. Make sure all of your units are in place with full movement before you step into the chamber. Usually Mario will be one XP from levelling up, so give him the first hit. On lower difficulties you can make great use of backstab here, but even on hard Redain should go down in a turn or two.

==Banished==
'''[WHU]'''Start with a couple recruits/recalls, focusing on speed. Send Delly west (assuming she still has the Twinkling Sword and its +2 move), and the rest of the units generally following the course of the road but a few tiles to either side, finding and taking villages. Do not get too close to the river until Efraim can get across and into the keep in one turn. Recruit lots of bowmen and poachers depending on time of day, and be aggressive about moving them out of the castle so you can recruit more. Any loyal recruits and seriously injured or poisoned units can be sent north across the river for healing and safety. Efraim should find plenty of cheap kills, keep him protected and he can probably level a couple times (I focus on advancements that make him hard to hit). Once the initial wave of enemies are beaten back, charge south for the easy finish.

==Paradise Lost==
'''[WHU]'''The turn limit is tight here. You are probably going to lose some units as the trolls and orcs come across the river, so initially recruiting fodder is helpful, but save some gold for additional recruits and possibly recalls ''after'' you take the central orc keep (you don't want a bunch of units getting bogged down in the river). Pay attention to the terrain at the river bank.

'''[WHU]'''Lethalia generally needs at least a little help, so at a minimum send Delly west and then south, picking up villages along the way. Once you take the central orc keep, you may want to recruit/recall more than you think you would normally need, as the villages are hard to get to if you need to heal, and any units you had healing north of the river probably won't have time to reach the other castles. If you haven't already, send a couple quick units to assist Delly, even if it's just picking up dropped items.

==Shatter the Defilers==
'''[WHU]'''You have a bunch of elves in the forest. There's a river. Not real difficult. Send the elves east of the river south to gather villages, then west. Send a couple elves west and then south gathering villages. Recruit/recall heavily from the second keep, you're going to have a lot of income and a nice early finish bonus. Kill the orcs in the river, then finish off the leaders.

'''[WHU]'''The next scenario is not difficult, but it is useful to have a decent number of troops and you won't be able to recruit, only recall, so you may want to recruit units now that you don't actually need if your recall list is sparse.

==The Ruins of Lost Empires==

'''[WHU]'''The in-game walkthrough says something about killing the SW leader to get the other factions to fight. I've never seen the point. Recall a couple castles worth of troops. Send half north of the river to fight orcs, half across the bridge to fight trolls. The orcs will go down easily, find the gap in the mountains to the west and encounter the elves. No reason to send many troops to help the elves, there are bottlenecks that will limit the fighting. Send most of the northern forces south along the river, then southwest following the road, while the southern force heads southeast to take out the trolls then southwest to take out another orc leader.

'''[WHU]'''When you kill the northwest leader, send those troops south. When you spot the southwest leader, send some troops northwest into the mountains. Yes, you did just finish about 60 turns early, with a nice fat bonus. Also, early finishes like that will eventually add up to unlocking a secret boss fight.

==The Return==
'''[WHU]'''Pay attention to what Delly says at the beginning. Recall a few units, high HP and impact resistance and/or ranged units with marksman . Stick together and stay on the path as much as possible. As you move forward you will trigger packs of bandits, so do not run ahead. There are not a lot of turns, but enough to kill one pack of enemies at a time as long as you keep moving slowly forward.

==Where the Sun Does not Shine==
'''[WHU]''' Head south, east, then southeast. You have plague, use the walking corpses to distract the bats and keep moving. You will come to a corridor where you will start to head north. You can leave Argan there in a one tile wide passage to block the bats. Send someone northwest to pick up an item, though your true target is the passage that starts northeast and then quickly turns southeast. When you come to a deep water river, if you can send someone south to pick up an item, while the rest head northwest and then southwest.

'''[WHU]''' This scenario has no early finish bonus, and as long as you keep moving and do not get surrounded by bats before you start heading north you should finish with around 30 turns left. You could spend a couple dozen turns farming XP from bats, but since they are often level 0, I like to finish early to help attract the previously mentioned boss instead.

==Escape from Oblivion==
'''[WHU]''' As long as you don't get unlucky and get bogged down by bats in the beginning, this one is pretty easy. Follow the path until it starts to head northwest, then be careful. When you get to a certain point, the undead will start spawning and you need Efraim to get to the keep in time to start recalling. One thing you definitely do not want to do is have Lethalia fly over the lava, skipping the path entirely and triggering the undead long before Efraim can catch up.

'''[WHU]''' Recall some Elfish Sorceresses and Druids and Heavy Infantry, or other units that do impact and arcane damage, and some good archery units to take out walking dead. If you position your units well around y=21, with powerful units up front and healers and leaders just behind them and rotate out the injured, the wave of undead are pretty easy to deal with. Then just carefully move forward and kill the leader. There are quite a few areas that are lit which will negate the undead's advantage here, though I've never really felt the need to make use of them.

==The Poison==
'''[WHU]''' This one can be tricky due to the time limit if you try to stand and fight. You need to be moving ahead. When you finally get to the dragon, he'll often fly away, so you'll probably need a few turns to chase him around. A fast, flying, Lethalia can help pin him down.

'''[WHU]''' Chocobones are good at charging drakes. They may seem a little expensive, but you should have plenty of gold at this point. I'll use (okay, waste) a couple castles worth of them, often doing almost enough damage to leave the XP for the kill for units I actually care about. I don't worry much about rotating them out to heal, they are simple fodder to pound forward.

==Ascension==
'''[WHU]''' Sit on a village and kill ghosts. Once you have injured one, it will join your team if it dies. Use zone of control to trap your enemies so they can't heal.
'''[dwarftough]''' I always wonder if it's possible to use ghosts in the middle. I usually just sit in the village near the starting spot or around and enslave everyone who attacks me. And those ghosts in the middle just wail at each other and destroy each other usually not affecting the battle of yours.

==Toxic Sun==
'''[WHU]'''Efraim and Lethalia have a new unit type and abilities, make sure to check them out, in particular penetrates. Every time they get a kill they will receive a soul eater point. When they get enough points, a new AMLA will be unlocked.

'''[WHU]''' Welcome Skellie and Ethiel! Protect them and they will become valuable allies. Get moving with your heroes right away, no need to recruit. Leave a few of the level 1 units to collect villages and generally trail behind. Kill the troll leader, then send a couple low level units north and northeast to collect villages. Drive south, relying mostly on your heroes, then about halfway down the exit is to the east. There are some decent items available to the south and southwest, but you probably won't have enough turns to collect them. Watch out for shadows sneaking up behind you and killing your weaker units.

==Twilight==

==Shadow Empire==

==Long Way Home==

==The Battle for Ogira==

[[LotI_Walkthrough|Back]]

MultiplayerServerWML

2021-11-02T20:06:57Z

Dwarftough: /* See also */

This page describes the [[WML]] used to communicate with the multiplayer server for Wesnoth, [[wesnothd]].

== The handshake ==

The client sends four bytes, then the server replies with four bytes. To get a new connection number, the client will send these four bytes: 0x00 0x00 0x00 0x00. The server then sends back the connection number (wesnothd calls this number the "socket number"). Since 1.13+ the server no longer is using socket numbers to keep track of clients and always sends the same number to them all. Since 1.15+ client can also send 0x00 0x00 0x00 0x01 instead to request entire connection to be [https://github.com/wesnoth/wesnoth/blob/2f8136951cd77526188cf8d0fb2cf21eaa2ebe63/src/server/common/server_base.hpp#L60-L76 encapsulated in TLS] immediately after. If the handshake is successful, the server will be the first to send a data package. All packages are in [http://en.wikipedia.org/wiki/Gzip gzip] format and are preceded by four bytes that specify the size of the package to come in big-endian. Below you'll find information about what data the (unzipped) packages contain. Unpacked WML uses utf-8 charset.

== The login procedure ==

* server request (optional)
** '''[version]'''

* client response
** '''[version]'''
*** '''version''': The client's version string.
*** '''client_source''': The client's distribution info. (Steam, SourceForge, App Store, etc.)

* server response (if the server does not accept this version)
** '''[redirect]'''
*** '''host''': The host you should connect to.
*** '''port''': The port you should connect to.
*** '''version''': A comma-separated list of globs that this server should accept (e.g. "1.0*,1.2*,1.4*,1.7*,1.8*")
** or '''[reject]''' (if the version is unknown)
*** '''accepted_versions''': A comma-separated list of globs that this server does accept

* server request
** '''[mustlogin]'''

* client response
** '''[login]'''
*** '''username''': The username the client would like to have.
*** '''password''': The hashed password, created from the password and salt received from the server. More information about how this password is being generated, including a real world example, can be found in the file [http://forum.wesnoth.org/download/file.php?id=41145 HashedPasswords.pdf] (885 KiB). Since version 1.15+ if TLS was successfully established before then password will be passed as is, without hashing, relying on TLS for secrecy. Passing password hashes is no longer supported to free the client from responsibility to support all hash schemes the forum can potentially use. Client will emit error instead of trying to send password if TLS wasn't established.

* server response
** '''[join_lobby]'''
*** '''is_moderator''': "yes" if the user is a moderator, "no" otherwise.
*** '''profile_url_prefix''': The external URL prefix for player profiles (empty if the server doesn't have an attached database)
** or '''[error]'''
*** '''message''': The error message.
*** '''password_request''': If not empty the server asks the client to provide a password for its desired username.
*** '''phpbb_encryption''': If "yes" the client will encrypt the password using phpbb's algorithm.
*** '''random_salt''': Random salt sent to the client for mixing with the password hash.
*** '''hash_seed''': Salt generated from the original hash that is required to recreate it.
*** '''salt''': Salt generated from the original hash that is required to recreate it.
*** '''force_confirmation''': Display an ok/cancel dialog with the content of the 'message' key.

* server response
** '''[gamelist]'''
*** '''[game]''' (repeated)
**** '''id''': A unique id of the game.
**** '''name''': The title of the game.
**** '''mp_scenario''': The id of the scenario.
**** '''mp_era''': The id of the used era.
**** '''mp_use_map_settings''': Does the game use the map settings specified in the scenario.
**** '''mp_fog''': Does the game use fog.
**** '''mp_shroud''': Does the game use shroud.
**** '''mp_village_gold''': The number of gold per village.
**** '''experience_modifier''': The experience setting.
**** '''mp_countdown''': Does the game use a timer.
**** '''mp_countdown_reservoir_time''': Upper limit of the possibly available time.
**** '''mp_countdown_init_time''': Initial time.
**** '''mp_countdown_action_bonus''': Time bonus per action.
**** '''mp_countdown_turn_bonus''': Time bonus per turn.
**** '''map_data''': The map data. ''Notice: not sent to lobby if the game uses shroud''
**** '''hash''': The hash value of the map_data.
**** '''observer''': Are observers allowed or not.
**** '''human_sides''': The number of sides played by humans.
**** '''slots''': The number of vacant/max slots.
**** '''turn''': The current turn/max turn.
** '''[user]''' (repeated)
*** '''name''': The username of the player.
*** '''game_id''': The ID of the game the player is in.
*** '''location''': The name of the game the player is in.
*** '''available''': "yes" if the player is in the lobby; "no" if in a game.
Many of the keys under [game] are described more indepth on the [[ScenarioWML]] page.

== Error messages ==

* '''[error]'''
** '''message''': The error message.

== Chat (lobby and in-game) ==

* '''[message]'''
** '''sender''': (optional - filled by the server) The sender of the message.
** '''message''': The message itself.
** '''room''': The room the message is from/to
* '''[whisper]'''
** '''receiver''': The receiver of the whisper
** '''sender''': (optional - filled by the server) The sender of the whisper.
** '''message''': The message itself.

== Room commands ==
Note: the room commands are in general and are subject to change. Room commands are not implemented on 1.13+ servers.
* '''[room_join]'''
** '''room''': The room name to join
** '''player''': (filled by server in response message sent to all room members) the player that joins the room
** '''[members]''': member list sent to the player that joined
*** '''[member]''': (repeated) members
**** '''name''': This member's name
* '''[room_part]'''
** '''room''': The room name to part (leave). Leaving the lobby is not allowed.
** '''player''': (filled by server in response message sent to all room members) the player that leaves the room
* '''[room_query]''': specific room-related queries.
** '''[rooms]''': List rooms created on the server, or
** '''[names]''': List members of a given room
*** '''room''': The room name (if applicable)
** '''[persist]''': Check or set room persistance
*** '''value''': (optional) set room persistance to this value (yes/no)
* '''[room_query_response]''': contains specific response to a room_query.
** '''message''': optional text message response
** '''room''': room name (if applicable)
** '''[rooms]''': room list
*** '''[room]''': (repeated) rooms
**** '''name''': This room's name
** '''[members]''': member list
*** '''[member]''': (repeated) members
**** '''name''': This member's name

== Nickname registration related commands (lobby and in-game) ==

* '''[nickserv]'''
** '''[info]''': Request info about another username.
*** '''name''': The username.

== Updating the lobby state ==

* '''[gamelist_diff]''': server message - basically a [[DiffWML|diff]] from two gamelists, which also includes the user list.

* '''[observer]''' or '''[observer_quit]''': server message - players joining([observer_quit] - quitting the lobby "game")/quitting([observer] - joining the lobby "game") a game
** '''name''': Username of the player/observer.
* '''[refresh_lobby]''': Request the full gamelist.

== Game setup (the phase from creation to start) ==
To create a game the client sends:
* '''[create_game]'''
** '''name''': The title of the game.

followed by a message with the scenario options as under [game] (see above) plus the scenario data ([time], [era], [side], etc. see [[ScenarioWML]])

* '''[join]'''
** '''id''': The id of the game.
** '''observe''': Join the game as an observer.

* '''[scenario_diff]''': [[DiffWML|diff]] of the [[ScenarioWML]] (side changes, etc.)

* '''[start_game]''': sent by the host to start a game
* '''[leave_game]''': sent by the client when it leaves a game; sent by the server to make a client leave a game

== In-game communication ==

* '''[store_next_scenario]''': sent by the host - the scenario data (see [[ScenarioWML]]) to advance to the next scenario
* '''[notify_next_scenario]''': sent by the server to tell players that the data for the next scenario is available
* '''[load_next_scenario]''': sent by the client to request the data for the next scenario
* '''[next_scenario]''': data for the next scenario (see [[ScenarioWML]]), sent by the server on request

* '''[info]''': sent by the host on game end - info about the game state
** '''type''': "termination"
** '''condition''': the termination reason

* '''[change_controller]''': a player (un)droids one of his sides or assigns control to someone else (The host can assign control for any side.)
** '''side''': the side to change controller
** '''player''': the nickname of the player to take control
** '''controller''': the new controller: "human" or "human_ai"
** '''own_side''': "yes"

If a player leaves this is sent to the host for all sides he owned.
* '''side_drop''': The number of a side that dropped because a player left.
* '''controller''': The controller of that side. ("ai", "network")

* '''[muteall]''': the host mutes/unmutes all observers - toggles
* '''[mute]''': the host mutes an observer - toggles
** '''username''': the username of the observer - if not specified the servers returns a list of muted usernames
* '''[kick]''' or '''[ban]''': the host kicks/bans a player/observer
** '''username''': the username of the player/observer

* '''[turn]'''
** '''[command]''': (repeated) can contain all the tags you can find in a replay: [recruit], [move], [end_turn], etc.
*** '''[speak]'''
**** '''message''': text of the message
**** '''id''': the sender
**** '''team_name''': the name of the team the message is for - empty if it's a public message

== Administrative commands ==
* '''[query]'''
** '''type''': The type of query. See [[ServerAdministration]] for details.

== See also ==
[https://github.com/renom/fastbot fastbot] - the bot for tournaments which implements the protocol, can log in into the lobby and host games (without TLS, only MD5 forum hashing). Written in Go.
[[Category:WML Reference]]
[[Category:Server Documentation]]

User:Dwarftough

2021-10-31T10:19:33Z

Dwarftough: Created page with "Wesnoth bots, Invincibles Conquest II"

Wesnoth bots, Invincibles Conquest II