The Battle for Wesnoth Wiki - User contributions [en]

IGNFileFormat

2015-12-03T13:35:47Z

Aquileia: Use <code> for code snippets (except '?' which looks awkward)

__NOTOC__
When you upload an add-on, some files and directories are ignored and not uploaded.

If you would prefer to have more control over which files and directories should be ignored, you should provide a _server.ign file containing a list of filter patterns. Each file or directory matching any entry of the _server.ign file will not be included when uploaded to the add-ons server.

== Where do I put the file, and what goes in it? ==

The file should be placed within the root level of your add-on (data/add-ons/addon_name/_server.ign).

A specific format is required:

* {{DevFeature1.13|0}}: Blank lines and lines beginning with '<code># </code>' (space required) are ignored.
* Each line should contain exactly one pattern.
* <code>*</code> and ? wildcards are supported (? stands for any single character, <code>*</code> stands for any number of any characters).
* Patterns with a trailing forward slash '<code>/</code>' will match directories; the rest only match files.

==== Default values ====

If there is no custom _server.ign file present, a default filter will be used instead, which as of Wesnoth 1.12 is as follows:

.*
.*/
__MACOSX/
#*#
*~
*-bak
*.swp
*.pbl
*.ign
_info.cfg
*.exe
*.bat
*.cmd
*.com
*.scr
*.sh
*.js
*.vbs
*.o
Thumbs.db
*.wesnoth
*.project

If there is a custom _server.ign file, the contents of the file are used as the filter '''instead''' of the defaults, so you should include any of the applicable default exclusions patterns in your own file as well.

== See Also ==

* [[PblWML]]

[[Category:Create]]

GermanTranslationUnitNames

2015-11-25T01:36:03Z

Aquileia: Unify column width in translation tables

= Hinweise zur Übersetzung =

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

== Generelles ==

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

== Zeichensetzung und Ähnliches ==

Es werden die typografisch richtigen Satzzeichen verwendet:

* Anführungszeichen: »Text«, nicht "Text" oder 'Text'
* Gedankenstriche: Richtig ist "Text – Einschub", nicht "Text - Einschub" oder "Text -- Einschub" (Halbgeviertstrich anstatt Viertelgeviertstrich)
* Apostrophe: Geht’s, nicht Geht's
* Anrede: Groß- und kleingeschriebenes "Ihr/ihr", "Euer / euer":
** Solange sich im Spiel Charaktere untereinander unterhalten: Kleinschreibung (Richtig:"Meine Treu, '''i'''hr seit ein Lump!"; Falsch:"Meine Treu, '''I'''hr seit ein Lump").
** Jedoch: Wenn der Spieler hinter der Tastatur angesprochen wird: Großschreibung! (Richtig: "Bewegt Konrad und '''E'''ure Truppen über die Brücke.", Falsch: "Bewegt Konrad und '''e'''ure Truppen über die Brücke.").
* die vollständige (englische) Typografie-Anleitung gibt es [http://wiki.wesnoth.org/Typography_Style_Guide hier]; Bash-Scripts zum automatisierten Anpassen der Sonderzeichen gibt es [http://wiki.wesnoth.org/TranslatorShellscript hier]
* das Dach "^" ist eine Übersetzerhilfe: alles vor diesem Zeichen wird in der Übersetzung ignoriert. Beispiel: "rod of justice^Take it!" - Der zu übersetzende String heisst eigentlich nur "Take it", aber der Bezug von "it" bliebe dann unklar. Der Kampagnenprogrammierer spezifiziert also, dass sich "it" auf "rod of justice" bezieht. Die Übersetzung könnte also sein: "Schnapp dir das Ding!".

= Mainline (offizieller Inhalt des Spiels) =

== Einheiten ==

Details zum letzten Namensüberarbeitungsprojekt finden sich [http://wiki.wesnoth.org/GermanTranslationNameRework hier].
Die Übersetzungen wurden in die Entwicklerversion eingearbeitet.

Damit niemand 'Goblin' mit 'Goblin' übersetzt oder 'Wose' mit 'Baummensch', orientiert euch bitte an folgenden Übersichten (Haltet die Maus über dem "i", um die englische ID anzuzeigen):

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

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

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

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

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

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

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

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

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

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

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

[http://units.wesnoth.org/trunk/mainline/de_DE/Descent_into_Darkness.html Steigt hinab in die Dunkelheit]

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

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

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

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

{| class="wikitable"
| style="width: 200px;" | Drakes
| style="width: 250px;" | Draken
|-
| Dwarves
| Zwerge
|-
| Elves
| Elfen
|-
| Goblins
| Kobolde
|-
| Humans
| Menschen (Wesnoth)
|-
| Khalifate
| Menschen (Kalifat)
|-
| Mechanical
| Kriegsgerät
|-
| Mermen
| Meervolk
|-
| Monsters
| Monster
|-
| Nagas
| Nagas
|-
| Ogres
| Oger
|-
| Orcs
| Orks
|-
| Saurians / Lizards
| Saurianer / Echsen
|-
| Trolls
| Trolle
|-
| Undead
| Untote
|-
| Woses
| Waldschrate
|}

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

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

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

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

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

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

=== Städte / Dörfer / Festen ===
{| class="wikitable"
| style="width: 200px;" | Elensefar
| style="width: 250px;" | Elensefar
|-
|Blackwater Port
|Schwarzwasser Hafen
|-
|Weldyn
|Weldyn
|-
|Soradoc
|Soradoc
|-
|Spellkeep
|Bannheim
|-
|Dwarves Doors
|Zwergenpforte
|-
|Southbay
|Südbucht
|-
|
|
|}

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

== Waffen und Gegenstände ==

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

=== Waffenfähigkeiten ===
<table>
<tr><td>backstab</td><td>hinterlistiger Angriff</td></tr>
<tr><td>berserk</td><td>Kampfrausch</td></tr>
<tr><td>charge</td><td>Ansturm</td></tr>
<tr><td>drains</td><td>Lebensentzug</td></tr>
<tr><td>firststrike</td><td>Erstschlag</td></tr>
<tr><td>magical</td><td>magisch</td></tr>
<tr><td>marksman</td><td>Schießkunst</td></tr>
<tr><td>plague</td><td>untote Plage</td></tr>
<tr><td>poison</td><td>vergiften</td></tr>
<tr><td>slows</td><td>verlangsamen</td></tr>
<tr><td>stones</td><td>versteinern</td></tr>
</table>

=== Schadenstypen ===
<table>
<tr><td>arcane</td><td>Arkan</td></tr>
<tr><td>blade</td><td>Klinge</td></tr>
<tr><td>cold</td><td>Kälte</td></tr>
<tr><td>fire</td><td>Feuer</td></tr>
<tr><td>impact</td><td>Wucht</td></tr>
<tr><td>pierce</td><td>Stich</td></tr>
</table>

=== Gegenstände===
<table>
<tr><td>Holy Water</td><td>Weihwasser</td></tr>
<tr><td>Poison</td><td>Gift</td></tr>
<tr><td>Potion of Decay</td><td>Trank des Verfalls</td></tr>
<tr><td>Potion of Healing</td><td>Trank der Heilung</td></tr>
<tr><td>Potion of Strength</td><td>Trank der Stärke</td></tr>
<tr><td>Ring of Regeneration</td><td>Ring der Regeneration</td></tr>
<tr><td>Ring of Power</td><td>Ring der Kraft</td></tr>
<tr><td>Ring of Slowness</td><td>Ring der Langsamkeit</td></tr>
<tr><td>Staff of Swiftness</td><td>Stab der Geschwindigkeit</td></tr>
<tr><td>Storm Trident</td><td>Dreizack des Sturms</td></tr>
<tr><td>Staff of righteous Flame</td><td>Stab der aufflammenden Gerechtigkeit</td></tr>
<tr><td>Rod of Justice</td><td>Stab der Gerechtigkeit </td></tr>
</table>

== Charakteristiken, Fertigkeiten ==

=== Charakteristiken ===
<table>
<tr><td>aged</td><td>betagt</td></tr>
<tr><td>dextrous</td><td>treffsicher</td></tr>
<tr><td>elemental</td><td>elementar</td></tr>
<tr><td>fearless</td><td>furchtlos</td></tr>
<tr><td>feral</td><td>wild</td></tr>
<tr><td>healthy</td><td>vital</td></tr>
<tr><td>intelligent</td><td>intelligent</td></tr>
<tr><td>loyal</td><td>loyal</td></tr>
<tr><td>mechanical</td><td>Kriegsgerät</td></tr>
<tr><td>quick</td><td>schnell</td></tr>
<tr><td>resilient</td><td>robust</td></tr>
<tr><td>strong</td><td>kräftig</td></tr>
<tr><td>undead</td><td>untot</td></tr>
</table>

=== Fertigkeiten ===
<table>
<tr><td>ambush</td><td>Waldkenntnis</td></tr>
<tr><td>cures</td><td>Kurieren</td></tr>
<tr><td>concealment</td><td>Gassenwissen</td></tr>
<tr><td>heals +X</td><td>Heilen +X</td></tr>
<tr><td>illuminates</td><td>Lichtaura</td></tr>
<tr><td>leadership</td><td>Führungsqualitäten</td></tr>
<tr><td>nightstalk</td><td>Schemen</td></tr>
<tr><td>regenerates</td><td>Regeneration</td></tr>
<tr><td>skirmisher</td><td>Plänkler</td></tr>
<tr><td>steadfast</td><td>Unerschütterlich</td></tr>
<tr><td>submerge</td><td>Abtauchen</td></tr>
<tr><td>teleport</td><td>Teleportation</td></tr>
<tr><td>feeding</td><td>Kanibalismus</td></tr>
</table>

== Gebräuchliche Formulierungen ==

=== Missionsziele ===
{|
|Death of X
|X fällt in der Schlacht
|-
|Turns run out
|Rundenlimit überschritten
|-
|Defeat all enemy leaders
|Besiegt alle gegnerischen Anführer
|-
|Move X to the signpost in the Y
|Führt X zum Wegweiser im Y
|-
|Early finish bonus
|Bonus für frühzeitiges Ende
|-
|Alternative objective
|Alternatives Missionsziel
|-
|Bonus objective
|Bonusziel
|}

=== Schwierigkeitsgrade ===
<table>
<tr><td>(Novice level, XX scenarios.)</td><td>(Einstufung: Einfach, XX Szenarien)</td></tr>
<tr><td>(Intermediate level, XX scenarios.)</td><td>(Einstufung: Mittel, XX Szenarien)</td></tr>
<tr><td>(Expert level, XX scenarios.)</td><td>(Einstufung: Schwierig, XX Szenarien)</td></tr>
<tr><td>(Beginner)</td><td>(Sehr einfach)</td></tr>
<tr><td>(Easy)</td><td>(Einfach)</td></tr>
<tr><td>(Normal)</td><td>(Normal)</td></tr>
<tr><td>(Challenging)</td><td>(Herausfordernd)</td></tr>
<tr><td>(Difficult)</td><td>(Schwierig)</td></tr>
<tr><td>(Nightmare)</td><td>(Alptraum)</td></tr>
</table>

=== Credits (Herausgeber, Mitarbeiter, Danksagung) ===
<table>
<tr><td>And special thanks to everyone else who I forgot to mention.</td><td>Und besonderen Dank an alle, die ich vergessen habe, zu erwähnen.</td></tr>
<tr><td>Artwork and Graphics Design</td><td>Grafik</td></tr>
<tr><td>Campaign Design</td><td>Kampagnengestaltung</td></tr>
<tr><td>Campaign Epilog and Continuity</td><td>Kampagnenepilog und -fortsetzung</td></tr>
<tr><td>Campaign Maintenance</td><td>Betreuung</td></tr>
<tr><td>Code and Translation Assistance</td><td>Programmierungs- und Übersetzungshilfe</td></tr>
<tr><td>Completion and Maintenance</td><td>Fertigstellung und Betreuung</td></tr>
<tr><td>Conception and Original Design</td><td>Konzeption</td></tr>
<tr><td>Current Maintainer</td><td>Betreuung</td></tr>
<tr><td>Miscellaneous</td><td>Verschiedenes</td></tr>
<tr><td>Music Development</td><td>Musikkomposition</td></tr>
<tr><td>Prose, Grammatical and WML Assistance</td><td>Sprach- und WML-Hilfe</td></tr>
<tr><td>Translators</td><td>Übersetzung</td></tr>
<tr><td>WML Assistance</td><td>WML-Entwicklung</td></tr>
<tr><td>WML Contributors</td><td>WML-Entwicklung</td></tr>
</table>

=== Verschiedenes ===
<table>
<tr><td>(whispered), (whispers)</td><td>(geflüstert), (flüstert)</td></tr>
<tr><td>Minister</td><td>Vater, Bruder (im priesterlichen Sinne)</td></tr>
<tr><td>Whiteboard</td><td>Reißbrett</td></tr>
<tr><td>Multiplayerlobby</td><td>Mehrspielerlobby</td></tr>
<tr><td></td><td></td></tr>
<tr><td></td><td></td></tr>
<tr><td></td><td></td></tr>
</table>

== Siehe auch ==

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

[[Category:Translations]]

GermanTranslationUnitNames

2015-11-24T16:22:39Z

Aquileia: /* Einheiten */ Separate historical info (name revision project) from general info

= Hinweise zur Übersetzung =

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

== Generelles ==

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

== Zeichensetzung und Ähnliches ==

Es werden die typografisch richtigen Satzzeichen verwendet:

* Anführungszeichen: »Text«, nicht "Text" oder 'Text'
* Gedankenstriche: Richtig ist "Text – Einschub", nicht "Text - Einschub" oder "Text -- Einschub" (Halbgeviertstrich anstatt Viertelgeviertstrich)
* Apostrophe: Geht’s, nicht Geht's
* Anrede: Groß- und kleingeschriebenes "Ihr/ihr", "Euer / euer":
** Solange sich im Spiel Charaktere untereinander unterhalten: Kleinschreibung (Richtig:"Meine Treu, '''i'''hr seit ein Lump!"; Falsch:"Meine Treu, '''I'''hr seit ein Lump").
** Jedoch: Wenn der Spieler hinter der Tastatur angesprochen wird: Großschreibung! (Richtig: "Bewegt Konrad und '''E'''ure Truppen über die Brücke.", Falsch: "Bewegt Konrad und '''e'''ure Truppen über die Brücke.").
* die vollständige (englische) Typografie-Anleitung gibt es [http://wiki.wesnoth.org/Typography_Style_Guide hier]; Bash-Scripts zum automatisierten Anpassen der Sonderzeichen gibt es [http://wiki.wesnoth.org/TranslatorShellscript hier]
* das Dach "^" ist eine Übersetzerhilfe: alles vor diesem Zeichen wird in der Übersetzung ignoriert. Beispiel: "rod of justice^Take it!" - Der zu übersetzende String heisst eigentlich nur "Take it", aber der Bezug von "it" bliebe dann unklar. Der Kampagnenprogrammierer spezifiziert also, dass sich "it" auf "rod of justice" bezieht. Die Übersetzung könnte also sein: "Schnapp dir das Ding!".

= Mainline (offizieller Inhalt des Spiels) =

== Einheiten ==

Details zum letzten Namensüberarbeitungsprojekt finden sich [http://wiki.wesnoth.org/GermanTranslationNameRework hier].
Die Übersetzungen wurden in die Entwicklerversion eingearbeitet.

Damit niemand 'Goblin' mit 'Goblin' übersetzt oder 'Wose' mit 'Baummensch', orientiert euch bitte an folgenden Übersichten (Haltet die Maus über dem "i", um die englische ID anzuzeigen):

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

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

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

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

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

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

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

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

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

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

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

[http://units.wesnoth.org/trunk/mainline/de_DE/Descent_into_Darkness.html Steigt hinab in die Dunkelheit]

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

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

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

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

{| class="wikitable"
| Drakes
| Draken
|-
| Dwarves
| Zwerge
|-
| Elves
| Elfen
|-
| Goblins
| Kobolde
|-
| Humans
| Menschen (Wesnoth)
|-
| Khalifate
| Menschen (Kalifat)
|-
| Mechanical
| Kriegsgerät
|-
| Mermen
| Meervolk
|-
| Monsters
| Monster
|-
| Nagas
| Nagas
|-
| Ogres
| Oger
|-
| Orcs
| Orks
|-
| Saurians / Lizards
| Saurianer / Echsen
|-
| Trolls
| Trolle
|-
| Undead
| Untote
|-
| Woses
| Waldschrate
|}

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

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

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

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

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

=== Wüsten / Ebenen ===
{| class="wikitable"
| Barren Plains
| Karge Steppe
|-
| Desert of Death
| Todeswüste
|-
| Frosty Wastes
| Frostwüste
|-
| Horse Plains
| Ebene der Pferde
|}

=== Städte / Dörfer / Festen ===
{|
|Elensefar
|Elensefar
|-
|Blackwater Port
|Schwarzwasser Hafen
|-
|Weldyn
|Weldyn
|-
|Soradoc
|Soradoc
|-
|Spellkeep
|Bannheim
|-
|Dwarves Doors
|Zwergenpforte
|-
|Southbay
|Südbucht
|-
|
|
|}

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

== Waffen und Gegenstände ==

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

=== Waffenfähigkeiten ===
<table>
<tr><td>backstab</td><td>hinterlistiger Angriff</td></tr>
<tr><td>berserk</td><td>Kampfrausch</td></tr>
<tr><td>charge</td><td>Ansturm</td></tr>
<tr><td>drains</td><td>Lebensentzug</td></tr>
<tr><td>firststrike</td><td>Erstschlag</td></tr>
<tr><td>magical</td><td>magisch</td></tr>
<tr><td>marksman</td><td>Schießkunst</td></tr>
<tr><td>plague</td><td>untote Plage</td></tr>
<tr><td>poison</td><td>vergiften</td></tr>
<tr><td>slows</td><td>verlangsamen</td></tr>
<tr><td>stones</td><td>versteinern</td></tr>
</table>

=== Schadenstypen ===
<table>
<tr><td>arcane</td><td>Arkan</td></tr>
<tr><td>blade</td><td>Klinge</td></tr>
<tr><td>cold</td><td>Kälte</td></tr>
<tr><td>fire</td><td>Feuer</td></tr>
<tr><td>impact</td><td>Wucht</td></tr>
<tr><td>pierce</td><td>Stich</td></tr>
</table>

=== Gegenstände===
<table>
<tr><td>Holy Water</td><td>Weihwasser</td></tr>
<tr><td>Poison</td><td>Gift</td></tr>
<tr><td>Potion of Decay</td><td>Trank des Verfalls</td></tr>
<tr><td>Potion of Healing</td><td>Trank der Heilung</td></tr>
<tr><td>Potion of Strength</td><td>Trank der Stärke</td></tr>
<tr><td>Ring of Regeneration</td><td>Ring der Regeneration</td></tr>
<tr><td>Ring of Power</td><td>Ring der Kraft</td></tr>
<tr><td>Ring of Slowness</td><td>Ring der Langsamkeit</td></tr>
<tr><td>Staff of Swiftness</td><td>Stab der Geschwindigkeit</td></tr>
<tr><td>Storm Trident</td><td>Dreizack des Sturms</td></tr>
<tr><td>Staff of righteous Flame</td><td>Stab der aufflammenden Gerechtigkeit</td></tr>
<tr><td>Rod of Justice</td><td>Stab der Gerechtigkeit </td></tr>
</table>

== Charakteristiken, Fertigkeiten ==

=== Charakteristiken ===
<table>
<tr><td>aged</td><td>betagt</td></tr>
<tr><td>dextrous</td><td>treffsicher</td></tr>
<tr><td>elemental</td><td>elementar</td></tr>
<tr><td>fearless</td><td>furchtlos</td></tr>
<tr><td>feral</td><td>wild</td></tr>
<tr><td>healthy</td><td>vital</td></tr>
<tr><td>intelligent</td><td>intelligent</td></tr>
<tr><td>loyal</td><td>loyal</td></tr>
<tr><td>mechanical</td><td>Kriegsgerät</td></tr>
<tr><td>quick</td><td>schnell</td></tr>
<tr><td>resilient</td><td>robust</td></tr>
<tr><td>strong</td><td>kräftig</td></tr>
<tr><td>undead</td><td>untot</td></tr>
</table>

=== Fertigkeiten ===
<table>
<tr><td>ambush</td><td>Waldkenntnis</td></tr>
<tr><td>cures</td><td>Kurieren</td></tr>
<tr><td>concealment</td><td>Gassenwissen</td></tr>
<tr><td>heals +X</td><td>Heilen +X</td></tr>
<tr><td>illuminates</td><td>Lichtaura</td></tr>
<tr><td>leadership</td><td>Führungsqualitäten</td></tr>
<tr><td>nightstalk</td><td>Schemen</td></tr>
<tr><td>regenerates</td><td>Regeneration</td></tr>
<tr><td>skirmisher</td><td>Plänkler</td></tr>
<tr><td>steadfast</td><td>Unerschütterlich</td></tr>
<tr><td>submerge</td><td>Abtauchen</td></tr>
<tr><td>teleport</td><td>Teleportation</td></tr>
<tr><td>feeding</td><td>Kanibalismus</td></tr>
</table>

== Gebräuchliche Formulierungen ==

=== Missionsziele ===
{|
|Death of X
|X fällt in der Schlacht
|-
|Turns run out
|Rundenlimit überschritten
|-
|Defeat all enemy leaders
|Besiegt alle gegnerischen Anführer
|-
|Move X to the signpost in the Y
|Führt X zum Wegweiser im Y
|-
|Early finish bonus
|Bonus für frühzeitiges Ende
|-
|Alternative objective
|Alternatives Missionsziel
|-
|Bonus objective
|Bonusziel
|}

=== Schwierigkeitsgrade ===
<table>
<tr><td>(Novice level, XX scenarios.)</td><td>(Einstufung: Einfach, XX Szenarien)</td></tr>
<tr><td>(Intermediate level, XX scenarios.)</td><td>(Einstufung: Mittel, XX Szenarien)</td></tr>
<tr><td>(Expert level, XX scenarios.)</td><td>(Einstufung: Schwierig, XX Szenarien)</td></tr>
<tr><td>(Beginner)</td><td>(Sehr einfach)</td></tr>
<tr><td>(Easy)</td><td>(Einfach)</td></tr>
<tr><td>(Normal)</td><td>(Normal)</td></tr>
<tr><td>(Challenging)</td><td>(Herausfordernd)</td></tr>
<tr><td>(Difficult)</td><td>(Schwierig)</td></tr>
<tr><td>(Nightmare)</td><td>(Alptraum)</td></tr>
</table>

=== Credits (Herausgeber, Mitarbeiter, Danksagung) ===
<table>
<tr><td>And special thanks to everyone else who I forgot to mention.</td><td>Und besonderen Dank an alle, die ich vergessen habe, zu erwähnen.</td></tr>
<tr><td>Artwork and Graphics Design</td><td>Grafik</td></tr>
<tr><td>Campaign Design</td><td>Kampagnengestaltung</td></tr>
<tr><td>Campaign Epilog and Continuity</td><td>Kampagnenepilog und -fortsetzung</td></tr>
<tr><td>Campaign Maintenance</td><td>Betreuung</td></tr>
<tr><td>Code and Translation Assistance</td><td>Programmierungs- und Übersetzungshilfe</td></tr>
<tr><td>Completion and Maintenance</td><td>Fertigstellung und Betreuung</td></tr>
<tr><td>Conception and Original Design</td><td>Konzeption</td></tr>
<tr><td>Current Maintainer</td><td>Betreuung</td></tr>
<tr><td>Miscellaneous</td><td>Verschiedenes</td></tr>
<tr><td>Music Development</td><td>Musikkomposition</td></tr>
<tr><td>Prose, Grammatical and WML Assistance</td><td>Sprach- und WML-Hilfe</td></tr>
<tr><td>Translators</td><td>Übersetzung</td></tr>
<tr><td>WML Assistance</td><td>WML-Entwicklung</td></tr>
<tr><td>WML Contributors</td><td>WML-Entwicklung</td></tr>
</table>

=== Verschiedenes ===
<table>
<tr><td>(whispered), (whispers)</td><td>(geflüstert), (flüstert)</td></tr>
<tr><td>Minister</td><td>Vater, Bruder (im priesterlichen Sinne)</td></tr>
<tr><td>Whiteboard</td><td>Reißbrett</td></tr>
<tr><td>Multiplayerlobby</td><td>Mehrspielerlobby</td></tr>
<tr><td></td><td></td></tr>
<tr><td></td><td></td></tr>
<tr><td></td><td></td></tr>
</table>

== Siehe auch ==

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

[[Category:Translations]]

GermanTranslationUnitNames

2015-11-17T21:02:17Z

Aquileia: Ersetze Einheiten-Tabelle durch Verweise auf units.wesnoth.org

CampaignWML

2015-08-09T12:17:30Z

Aquileia: Add ENABLE_KHALID to extra_defines

{{WML Tags}}



This page describes how the campaign is displayed in the "Campaign" menu, and how it starts.

==The [campaign] Tag==

The following keys and tags are recognized in '''[campaign]''' tags:
* '''id''': the internal campaign identifier used to classify saved games
* '''icon''': the image displayed in the campaign selection menu
* '''name''': (translatable) name displayed in the campaign selection menu
* '''abbrev''': (translatable) abbreviation used as a prefix for savefile names made from this campaign
* '''image''': the image shown in the information pane when this campaign is selected in the campaign selection menu (typically a transparent, 350×350 pixels portrait)
* '''description''': (translatable) text shown in the information pane when this campaign is selected in the campaign selection menu
* '''type''': campaign's type to specify if it should be visible in singleplayer, multiplayer or both. Possible values are "sp", "mp" and "hybrid". Defaults to "sp".
* '''define'''='''''CAMPAIGN_SYMBOL''''' when this campaign is started, the preprocessor symbol '''''CAMPAIGN_SYMBOL''''' will be defined. See '''#ifdef''' in [[PreprocessorRef]] for how this can be used to isolate parts of the campaign file from other campaigns. Only the tags '''[campaign]''' and '''[binary_path]''' (see [[BinaryPathWML]]) should go outside of '''#ifdef ''CAMPAIGN_SYMBOL'''''. This symbol will be defined ''before'' any .cfg is preprocessed. Important note: starting with 1.7.13, [binary_path] does no longer need to be outside of the '''#ifdef ''CAMPAIGN_SYMBOL''''' block to make custom binary data available, which could easily cause overwrites. E.g. icon=data/add-ons/whatever/something.png is supposed to work. This seems to have been a bug since at least BfW 1.0 which means that practically all available examples of user made add-ons are wrong in this aspect.
* '''extra_defines''': a comma(''',''') separated list of preprocessor symbols. Those symbols will be defined ''before'' any .cfg is preprocessed. Currently supported extra_defines are:
<ul>
;ENABLE_ARMAGEDDON_DRAKE
:allows the advancement ''Inferno Drake'' -> ''Armageddon Drake''
;ENABLE_DWARVISH_ARCANISTER
:allows the advancement ''Dwarvish Runemaster'' -> ''Dwarvish Arcanister''
;ENABLE_DWARVISH_RUNESMITH
:allows the advancement ''Dwarvish Fighter'' -> ''Dwarvish Runesmith''
;DISABLE_GRAND_MARSHAL
:disallows the advancement ''General'' -> ''Grand Marshal''
;ENABLE_ANCIENT_LICH
:allows the advancement ''Lich'' -> ''Ancient Lich''
;ENABLE_DEATH_KNIGHT
:allows the advancement ''Revenant'' -> ''Death Knight'
;ENABLE_TROLL_SHAMAN
:allows the advancement ''Troll Whelp'' -> ''Troll Shaman''
;ENABLE_WOLF_ADVANCEMENT
:allows the advancements ''Wolf'' -> ''Great Wolf'' -> ''Direwolf''
;ENABLE_NIGHTBLADE {{DevFeature1.13|0}}
:allows the advancement ''Orcish Slayer'' -> ''Orcish Nightblade''
;ENABLE_KHALID {{DevFeature1.13|0}}
:allows the advancement ''Shuja'' -> ''Khalid''
</ul>
* '''difficulties''': a comma(''',''') separated list of preprocessor symbols, exactly one of which will be stored depending on the difficulty setting chosen when the campaign is started. The symbols '''EASY''', '''NORMAL''', and '''HARD''' are usually used, and there are several macros in utils.cfg (see [http://www.wesnoth.org/macro-reference.xhtml#file:utils.cfg| Macro Reference]) which check for these values to set WML keys to different values depending on difficulty. If you use different difficulty symbols, you may need to define your own versions of these macros.
* '''difficulty_descriptions''': the menu of difficulties; this is a list of descriptions (see [[DescriptionWML]]) that correspond to different difficulty levels. Since each description is a menu option for a difficulty level, this must provide the same number of descriptions as there are levels in the ''difficulties'' list.
* '''allow_difficulty_change''': Allows difficulty switching during an ongoing campaign. Default:yes
* '''first_scenario''': the ID of the first scenario in the campaign; see ''id'' in [[ScenarioWML]]
* '''rank''': a number that determines the order of campaigns in the campaign selection menu. Lower ''rank'' campaigns appear earlier, with unranked campaigns at the end. Currently the mainline campaigns use multiples of 10 from 0 to 399, with 0-99 for Novice campaigns, 100-199 for Intermediate campaigns, and 200-399 for Expert campaigns; if you specify this, it should not be less than 400. (Note: This replaces an older convention that topped out at 50.)
* '''[about]''': inserts your own credits into the game's list of credits. See below for syntax.
* '''end_credits''': Whether to display the credits screen at the end of the campaign. Defaults to ''yes''.
* '''end_text''': (translatable) Text that is shown centered in a black screen at the end of a campaign. Defaults to "The End".
* '''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.

The following keys are additionally recognized in multiplayer:
* '''min_players''': Minimum number of players campaign supports. Defaults to 2.
* '''max_players''': Maximum number of players campaign supports. Defaults to '''min_players'''.
* '''allow_era_choice''': Whether to hide era selection and use a default one when creating a game. Defaults to ''yes''.
* '''require_campaign''': Whether clients are required to have this campaign installed beforehand to be allowed join a game using this campaign. Possible values 'yes' (the default) and 'no'.

== Campaign credits ==

The campaign's name automatically is inserted at the top of the rolling credits followed by title/text key pairs. There can be any number of '''[about]''' tags inside a '''[campaign]''' tag, but none of them will display credits if there is no "id" key present inside [campaign] (see above). The '''[about]''' tag has the following keys:
* '''title''': (translatable) large text used to start a new subsection (writers, artists, units, balancing) in the rolling credits
* '''text''': (translatable, but you probably won't want to make it such) smaller text which is displayed before the contributor names
* '''[entry]''': Contains information about a single contributor. Only the ''name'' key will be used in-game, the other three keys are for display on the [[Credits]] page ('''note:''' the values of these keys will only display on the Credits page for mainline campaigns; they will not display for UMC campaigns)
** '''name''': The name of the contributor
** '''comment''': Optional short note about what that person did
** '''email''': Optional email address
** '''wikiuser''': Optional, the user name on the wiki

== See Also ==

* [[PreprocessorRef]]
* [[ScenarioWML]]
* [[ReferenceWML]]
* [[PblWML]]

[[Category: WML Reference]]

NotSoEasyCoding

2015-08-03T11:26:53Z

Aquileia: /* SDL 2 + OpenGL port */ assigned to Aginor to avoid that other contributors work on it without coordinating with him

This page lists projects which are considered a good idea by the developers but which have nobody working on them so far. If you think you've got the required skill for a task go on, implement it and you've got a high chance that it'll be accepted. The remaining barrier will only be that it's done well. :-)

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

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

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

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

__TOC__

== Game engine ==

=== [[SDL 2 + OpenGL port]] ===

Wesnoth currently depends on the unmaintained SDL 1.2.x code base and the 1.2.x-based versions of its companion libraries (SDL_image, SDL_mixer, SDL_net, SDL_ttf). This means Wesnoth can't benefit from features added in newer versions of SDL such as built-in support for Android and iOS, improved cross-platform Unicode support, built-in clipboard support, and any bug fixes made since SDL 1.2.15.

The problem with porting Wesnoth to SDL 2.0 as explained by lipkab (who attempted the task as part of GSoC 2014) is that SDL 2.0's software rendering API lacks some things Wesnoth needs such as a specific alpha blending mode (TODO: link to conversations here).

Furthermore, while software rendering is all good and nice, Wesnoth's approach does not scale well as display resolutions increase and the need for supporting high DPI configurations is factored in. One can easily see that our zoom functionality is clunky and inefficient. Having support for OpenGL and shaders would also enable us to implement fancier graphical gimmicks such as particle effects and atmospheric lighting. The downside of adding OpenGL to the mix is that we'd need people with a specific skillset to help us maintain the graphics engine in the long term, as hardware and driver-specific quirks are inevitable. Some users are also concerned about changing Wesnoth's hardware requirements so that they would be unable to play using old or unsupported hardware/OS configurations.

For hardware rendering to be effective, in particular, Wesnoth would necessitate a complete rewrite of the graphics rendering code (the display and game_display classes), the image cache manager (used to abstract the process of loading images from disk and applying image path functions), and potentially GUI2's canvas code. All three would have to limit the amount of textures they allocate to the absolute minimum, using larger textures instead. For example, the image cache could be reimplemented to load images from an internal spritesheet generated during the game loading process. (WML/Lua support for spritesheets would be nice would defining an API for it would only distract from the actual task at hand.)

The greatest difficulty in handling this task probably lies in writing a new optimized rendering engine and updating all code that relies on the old display/game_display API and semantics accordingly. The GUI2 framework code is presently unmaintained and it would take some time for somebody to study and change the current implementation. Finally, as we don't have a graphics engine maintainer at this time, this task involves an implicit long-term commitment to the project that extends beyond Wesnoth 1.14.x (or whichever series will see this project completed).

-- currently worked on by Aginor - 3 August 2015

=== Make a "replay actions since my last turn" button ===

It would be very convenient if there an ability to replay everything your opponents just did at the start of your turn, since sometimes things go out of vision or are confusing.

The feature would be like a "replay since my last turn" menu option or button -- most likely, the best approach to implement it is to store a copy of the game_state object in playcontroller.cpp or even in resources, and to refactor the backlog object so that we can hold a "bookmark", i.e. a pointer, to the last position in the replay that we might look to jump back to. The replay process would work by swapping out for the old gamestate, then replaying through the actions since the bookmark until we get back up to speed. The difficult part would be making sure that scenarios with scripted WML events don't break when we do this. For debugging purposes, it might be good to check that at this point we have the same gamestate we did before we clicked the button. The bookmark should only be advanced when we end our turn, and there might be perhaps need to be multiple bookmarks, one for each side, to handle what happens when a side disconnects or is reassigned.

It would be especially helpful for MP play to have this, where special tactics with ambush units are quite common. Part of the design criteria of wesnoth is that it should be a high-level, thoughtful turn based strategy game, but you should be able to play asynchronously and not necessarily give attention to the game until your turn bell rings if you don't want to. Having ambush units and no ability to replay their movements during the opponents turn harms that goal.

For MP play, it will require special attention to make sure that events like "synchronize_choice" are handled correctly so as not to cause out of sync errors, and also that the timer is handled correctly.

Feature request: https://gna.org/bugs/?15334

=== Improve WML error reporting ===

There are many programming bugs that give very unclear or cryptic error messages when using WML. Here are some examples:

* <strike>When calling a macro with the wrong number of arguments, Wesnoth tells the number it expected, and the number it got, and at which line number it was instantiated. However, it would be helpful if it would also tell the line number of the definition of the macro. This might be helpful if someone is redefining macros.</strike>

* For places where a standard unit filter is expected, if one is not found, the game should point out a problem. For places where such a filter is expected but [filter] child should not appear, if one does it should report an error and a line number. Many users have a hard time with this kind of thing.

* When doing scenario transitions in a campaign, if the side definitions don't matchup exactly the game tends to give unintelligible error messages. For instance, if one is transitioning and there is an AI side which does not have a leader (but it has a starting location in the map) it must have "no_leader = yes" in its [side] tag, or else when the team_builder objects enter stage two, the game will try to create a unit with an empty type, and the constructor of class unit will fail giving the error message "game::game_error tried to create unit with empty type". This really needs to be much better. For instance, giving a line number of a problem, or suggesting that no_leader should be used. (Note that, it is often possible to debug problems like this by turning on --log-debug=team_construction at commandline but I doubt that there are any users that know about this, you would only learn from reading the C++... without such debug info, fixing things like this can literally take hours.) For that matter it's some question why the team_builder doesn't just stop trying to build a unit when it sees it doesn't have enough info...

* Recursive macros break the game, and not by stack overflow but by exhausting the heap (which usually takes forever on modern OSes and results in memory thrashing before resource starvation). It would be nice if we could catch this and report an error.

Many WML users are students or beginners to programming, so any improvements to WML error reporting are a big help for their learning process -- many veterans would appreciate the extra help as well. In part we need fixits here and there, but more broadly we need a smarter system that can figure out what's really wrong when things go wrong, and give helpful suggestions.

=== Map label "groups" which can be selectively turned on and off by the user ===

It would be nice if the user could have more control over how map labels are displayed, for instance to be able to check on / off labels made by certain players, and for custom scenarios, to be able to make custom classes which the use can turn on or off. This might be helpful for custom scenarios esp. which might have some technical info they want to show, but which it might be messy to display all of the time. The hard part of this is that there should ideally be a gui to work with the map labels, although maybe this need could be worked around or simplified somehow.

=== Add a new damage stats calculation mode to support scenarios with extremely high stats ===

Most players use the damage calculation window constantly when they play so that they can see what to expect from various attacks. The way the game is currently set up, when a unit is selected, as soon as another unit is moused over the stats for an attack will be calculated, whether or not the user actually brings up the window.

The probabilities for the various outcomes are calculated by explicitly calculating the distribution of attacker and defender hp / slowed status after each swing by either party, one swing at a time. Thus at the end we get exact probabilities of the possible outcomes.

However, this comes at a cost -- the running time of the calculation can in the worst case be something like O( attacker_hp * defender_hp * total_number_of_strikes). In default era wesnoth (and in much of UMC) this is fine because units don't get extremely high hp values. However in some UMC units do get extremely high hp, and many will also have specials like drain and berzerk, and may have many different weapons as well. At some point these scenarios become unplayable even on a machine of moderate specs because mousing over any unit causes > 10 seconds of lag during which the game becomes unresponsive, trying to calculate attack outcomes.

In these cases, it would be better to give an "inexact" damage prediction, based on just simulating a few thousand attacks and plotting the results. Since it's a monte carlo algorithm rather than an exact algorithm, there will be some error, but if it makes the game playable then it's clearly an improvement, and anyways for "extreme stats" battles with high strikes and damage, the outcome is in a sense less random anyways because the outcomes with inordinate amounts of hits and misses are more and more rare (law of large numbers), so the error shouldn't actually be terribly significant.

If there were an advanced preference that caused the predictions to use such an algorithm instead of the current one, so that the user could turn it on if they start to get problems, it would eliminate a significant headache for some UMC.

== Multiplayer/replay features ==

=== Gold graph ===

Make a graph feature, presumably in a dialog, that helps depict the history of a Wesnoth match for the benefit of spectators of a live game or replay. For example it could display army value, army + bank value, number of villages tagged, luck swings... This would also be particularly helpful for AI tweaking development, by helping coders identify the AI's weaknesses and strengths in the context of a particular scenario.

A possible nice feature for this purpose would be to allow the user to click on the graph at key points which would trigger the "back to turn" mechanism to jump back in the replay, or automatically play the replay forwards from the beginning to that point... etc.

Related email on dev-talk: https://mail.gna.org/public/wesnoth-dev/2014-02/msg00089.html

=== Automatically link up to wesnothd server on a local network ===

The feature request was to use ZeroConf technology, if available, to publish info of a running wesnothd instance to other machines on a local network. Then when they are searching to connect to an unofficial server, they won't have to learn the IP address.

The extra code should be guarded with preprocessor flags so that ZeroConf does not become a mandatory build dependency of Wesnoth.

https://gna.org/bugs/?13703

=== Stock MP chat messages for language-independent communication ===

Wesnoth has seen a large acceptance by international communities, and many players don't speak English. It would be nice we could have a set of messages that could be chatted, but which will be translated by our translators and displayed always in the current locale on each client, to make it easier to communicate in mp games / on the mp server.

The easy part is adding the messages. They would ideally be stored in a WML file in the core data dir so they can be easily modified and translated like all other mainline WML. The hard part is devising the interaction mechanism so that a player can easily make use of these stock messages in the MP lobby or in game.

== GUI2 framework ==

As of 1.13.1+dev, GUI2's core and framework (including widgets and their APIs) are completely unmaintained. A prospective maintainer would have to be able to understand pretty advanced C++ making abundant use of template-based abstractions (most notably, the event handling code is almost completely implemented this way), multiple inheritance, and polymorphism. There is also some missing functionality (such as combo boxes and modeless dialogs) that the author did not get to implement, as well as work-in-progress functionality (new listbox and tooltip implementations, not enabled by default).

=== Multi-line textbox, single-line textbox improvements ===

GUI2 has a single-line textbox widget which works well for most purposes but falls short in a few niche cases. In particular, it's not possible to make it read-only without entirely disabling the user's ability to interact with the contents, which is inconvenient in places like the Game Paths dialog (or the About dialog in version 1.13.2 and later).

The widget also does not support multi-line contents. For this reason, GUI2 dialogs that present multi-line (read-only) text to the user make use of the scroll_label+clipboard button convention introduced by shadowm in 1.12.x (see the Chat Log, Gamestate Inspector, and WML load error dialogs for examples). This has the obvious limitations of not allowing the user to select specific portions of the contents, and not supporting editing.

=== Generic tab_container widget ===

After 1.13.1 was released, shadowm discovered a trick to implement tabbed dialogs in GUI2, involving a general widget bug fix to make children consider their parents' visibility when processing events, and an addition to the stacked_widget API enabling users to hide all but a single active layer.

The About dialog introduced in version 1.13.2 will use a horizontal listbox in combination with a stacked_widget, but ideally we should be able to reuse this pattern in more places without having to clutter up dialog implementations with the requisite code to synchronize the listbox and the stacked_widget's states. This hypothetical tab_container widget would combine the listbox and the stacked_widget to implement tabs in a cleaner fashion without having to expose the implementation details to individual dialog instances.

By all means, this should be an EasyCoding task, but GUI2's unusual code layout and API design conventions (compared to the rest of Wesnoth) ''may'' make it harder than it's supposed to be.

If you want to work on this, you should poke shadowm to make sure you don't duplicate efforts as he is working on a GUI2 port of the Preferences dialog and may take up this task after a while if no-one has done so first.

=== GUI2 combo box and menu ===

GUI2 most notably lacks a combo box widget (e.g., used in the GUI1 MP side setup screen) and menu display (either for the game's menu bar or context menus). It is not known at this time how much work would have to be done in GUI2's core and framework to allow implementing these widgets -- in particular considering how GUI2 widgets are never used without a parent dialog, which menus might not necessarily have, at least with the current gameplay UI implementation.

GUI2 menu FR: https://gna.org/bugs/?22820

GUI2 combo box FR: https://gna.org/bugs/?23652

=== GUI2 themable in-game UI ===

The "themable" in-game UI refers to the gameplay UI including the sidebar, menu/status bar, and map view. Most of it is not implemented using proper GUI1 widgets at all, except for the various interactive buttons, menus (which are floating GUI1 listboxes), and the command and chat input boxes (floating GUI1 textboxes).

Moving the theme UI to GUI2 would probably require finishing up theme support in GUI2 (which is largely incomplete), and may benefit from a rendering engine redesign as is also required for porting the game to SDL 2; in particular so that the GUI aspects are more clearly separated from the game board rendering aspect.

'''Note:''' This task is here solely for the sake of completeness, and only somebody very well versed in the intricacies of Wesnoth's game rendering code and GUI2 should '''ever''' try to take it up. (And even then, I would not want to be anywhere near that person when they inevitably break down and fling one or more tables around upon realizing the sheer complexity of the task. -- shadowm)

== Add-ons server and client ==

=== Passphrase hashing ===

The add-ons server (campaignd) uses a very dumb authentication scheme for uploading add-ons where an author sets a passphrase (or gets a random passphrase assigned by the game) the first time they upload to the server, and subsequent uploads of the same add-on are only allowed if the passphrase matches. The passphrase is stored in clear text form both client and server-side, which has [http://forums.wesnoth.org/viewtopic.php?f=62&t=42663 various implications].

Ideally, the server would store all passphrases in a hashed form.

=== Port redirection ===

Wesnoth's MP server (wesnothd) uses a single port (15000) for servicing most requests and redirects clients to different ports according to the game client's version number. This allows the server administrators to reassign ports freely without having to modify the game client.

The add-ons server (campaignd) and client instead have a hardcoded default port number for a Wesnoth version series. For example, 1.12.x is hardcoded to default to 15006. This becomes a maintainability issue as add-on servers get decommissioned and their port numbers can't be reused for fear of misdirecting obsolete client versions to the wrong instance with incompatible add-ons.

=== Incremental upgrades and uploads ===

Right now, whenever a new add-on version is published, players must download (or conversely, upload) the whole contents, even if the differences between both versions amount to a single line change. This is not a problem with small add-ons, but there is a substantial number of large (> 10 MiB) add-ons on the server. Large downloads and uploads are inconvenient for players on slow or metered connections, and also increase the server's traffic requirements.

Ideally, for each add-on it attempts to upgrade or upload, the add-ons client should be able to send the server its local list of files with hashes, so that the server can identify which files need to be transmitted to/by the client, all archived on the fly like normal add-on downloads/uploads. The obvious downside is that the server would need to calculate an add-on's file hashes on demand, increasing CPU usage when servicing upgrades or uploads; this could be avoided by generating its file hashes when servicing uploads instead.

See also: https://gna.org/bugs/?19972 (for uploads only; there should be one for downloads too but I couldn't find it -- shadowm)

=== Porting the server to Asio ===

Although the client uses Boost.Asio for communications, the server continues to use SDL_net instead. This means, amongst other things, that we are limited to IPv4 and an unmaintained codebase full of hacks waiting to break apart in the future (Wesnoth's SDL_net code does, amongst other things, tamper with what are supposed to be opaque data structures maintained by SDL_net).

There was an attempt to build a new add-ons server (umcd) using Asio as part of GSoC, but it ultimately failed and the developers are no longer involved with the project. The umcd codebase status as of this writing is unknown.

== Multiplayer server and client ==

=== Porting the server and client to Asio ===

As with campaignd above, it would be nice to move the multiplayer server and client to Asio so that we could drop the SDL_net dependency and obtain IPv6 support. There's a [https://github.com/wesnoth/wesnoth/tree/asio_wesnothd branch] to port the server to Asio. Be sure to coordinate any porting to Asio with loonycyborg as he's main contributor to the branch and did Asio porting of addon client.

=== Improve server WML processing ===

The server uses its own custom WML implementation separate from the main engine's to store and process WML objects for games -- see [[WesnothdDesign#simple_wml]]. This is intended to improve performance and reduce wesnothd's memory footprint with large numbers of games and complex scenarios. However, the simple_wml code sometimes messes up WML attribute translatability, resulting in MP scenarios/campaigns being untranslated for non-hosts in networked MP (http://gna.org/bugs/?22989). Fixing this is not easy due to the aforementioned performance requirements.

== Data structures ==

=== Make the Lua state persistent ===

Wesnoth is designed to make all data files as simple and human-readable as possible, including savefiles. WML is designed so that it is always very easy to write the entire WML state as plaintext and reload it correctly. There are many benefits of this, but especially

* It makes it easy for beginners / students to read the files and see what's going on
* It makes it easy for us to debug problems without needing special tools to read the savefiles
* It makes it easy to edit save files to work around any possible bugs. Users have even reported opening savefiles from version 1.10 in microsoft word (!) to correct minor bugs in mp and resaving them, as a policy for tournament games.

This was unfortunately somewhat lost when we added lua. If you use lua in your scenarios, things become more complicated because we can't save the lua state at all. If you rely on lua variables to save information, then when your scenario is saved and reloaded those variables will get wiped. The wesnoth engine provides places for lua to hook into "onsave" and "onload" so that the scenario developer can write their own serialization routines, but this is just punting the problem to scenario developers.

We also provide the "preload" event type specifically to work around the issue -- unlike all other events, preload is called exactly once for every time the scenario is loaded. The purpose is to give another way that lua users can initialize a table of lua functions used by their addon and guarantee that this happens before the functions are called. But to non-lua users this event is basically unsafe for normal use otherwise -- if there is a preload event which e.g. increments a WML variable, then the WML state now depends on how many times the scenario is saved or reloaded. In a normal scenario, save / reload events should be invisible, and normally if this isn't the case it indicates a bug similar to an OOS.

A nice solution to this would be if we properly serialized the lua state alongside the WML in a savefile. The most suitable solution is probably this library: https://github.com/fnuecke/eris
It would require significant additional work as well to find a good way to serialize the C functions that we expose to lua, and the userdata like units held by lua.

More info here: http://lua-users.org/wiki/PlutoLibrary

[[Category:Development]]
[[Category:Future]]

Git for Wesnoth Crash Course

2015-07-27T17:15:33Z

Aquileia: Delete two entries of the addendum

== Foreword ==

'''''(An essay by, mainly, iceiceice.)'''''

This page is intended for new <cite>Battle for Wesnoth</cite> developers and contributors who have never used '''[//wiki.wesnoth.org/WesnothRepository <cite>Git</cite>]''' before. I'm hoping that it will be written mainly by newbies like myself who have just figured out enough about <cite>Git</cite> to use it successfully, and therefore not include a bunch of information superfluous for that purpose. At the time that I am writing this, I have managed to write about eight GitHub pull requests and get them merged into <cite>Wesnoth</cite>, and I hope you will be able to do the same after reading this.

== What is <cite>Git</cite>? ==

The most effective '''"absolute beginner" introduction to <cite>Git</cite>''' that I found when I started is here: '''[http://gitref.org <cite>gitref.org</cite>]'''.

I suggest that you read this through, beginning to end, navigating through the pages by using the red arrows at the bottom of each page. You can skip the part about ''"stashing"'', but you should carefully read and understand the parts about:

* '''''cloning''''' a ''repository'';
* '''''checking out''''' a ''branch'', creating a '''new branch''', and '''merging branches''';
* '''''adding''''' and '''''committing changes''''';
* viewing '''''diffs''''' to make sure you understand exactly what you are committing;
* '''''resetting''''' your repository state in case you make a mistake and need to undo some steps, and using "'''<kbd>git log</kbd>'''" and "'''<kbd>git reflog</kbd>'''" to assist with this; and
* moving content between local and remote repositories, with "'''<kbd>push</kbd>'''" and "'''<kbd>pull</kbd>'''".

== Setting up our workflow for <cite>Wesnoth</cite> in <cite>Git</cite> ==

It is common when reading about <cite>Git</cite> to see the terms '''''"upstream"''''' and '''''"downstream"'''''. This is often confusing at the beginning -- after all, information is usually flowing in both directions; sometimes, you are getting code from the <cite>Wesnoth</cite> repository, and sometimes you are sending code to it. Which way is up and which is down?

Analogously to a river, ''downstream'' is the direction toward which most information flows. Any user that simply wants to build <cite>Wesnoth</cite> from source, and not make any changes to it, will generally do so by cloning or pulling from <https://github.com/wesnoth/wesnoth>. So [https://github.com/wesnoth/wesnoth <code>wesnoth/wesnoth</code>] (the main <cite>Wesnoth</cite> repository) is the <dfn>upstream</dfn> repository, and the users are <dfn>downstream</dfn>.

If you are a developer, you will '''''fork''''' the upstream repository and edit the source code, and -- hopefully, with work, eventually -- get your edits pulled into the upstream repository. That is the '''<dfn>development cycle</dfn>''', and contributing changes back to upstream is what makes you a developer.

In this guide, we are going to assume that you will use GitHub in addition to the official <cite>Git</cite> command-line program, because GitHub has many useful tools to offer and makes some things nicely easy, especially when comparing a topic branch to the master branch and seeing diffs in a somewhat more advanced interface, and when making ''pull requests''. Technically, this means that you will have '''two repositories''' -- your <dfn>local repository</dfn> on your computer, and a ''fork'' of the <code>wesnoth/wesnoth</code> repository, on GitHub.

The first step of becoming a <cite>Wesnoth</cite> developer is to set up these two repositories. Follow the instructions in [https://help.github.com/articles/fork-a-repo/ GitHub's "<cite>Fork A Repo</cite>" help article], which may be summarized as follows:

<ol>
<li>'''''Fork''''' the <code>wesnoth/wesnoth</code> repository, using the GitHub website.</li>
<li>'''''Clone''''' the fork onto your computer, with the command "<kbd>git clone</kbd>".</li>
<li>Configure '''<dfn>remotes</dfn>''' (''remote'' repositories that are essentially bookmarked).
GitHub's <cite>Fork A Repo</cite> article describes how to set the <code>wesnoth/wesnoth</code> repository as a remote with the name "<code>upstream</code>". Because you cloned from your fork, the fork is automatically set as a remote with the name "<code>origin</code>". You can see your remotes with the command "<kbd>git remote -v</kbd>".
You might find this naming scheme confusing, given that the name "<code>origin</code>" might also aptly describe the <code>wesnoth/wesnoth</code> repository. So it might be good to rename that remote to "<code>fork</code>" (with the command "<kbd>git remote rename origin fork</kbd>"). But if you do that, note that much of the GitHub help pages will assume the name "<code>origin</code>".</li>
</ol>

Additionally, we ask that you configure <cite>Git</cite> to use your full real name, per the instructions in [https://help.github.com/articles/setting-your-username-in-git/ GitHub's "<cite>Setting your username in Git</cite>" help article], so that we can associate a concrete person with every commit merged into <cite>Wesnoth</cite>. Your GitHub profile should also display your real name.

== The basic workflow ==

Here's the picture we now have, with 3 repositories:

upstream

origin (fork)

local

There are four basic steps in the development cycle, which are as follows:

# ensuring that your local repository is '''up-to-date''' with the upstream repository;
# creating a '''topic branch''' for your changes;
# '''committing''' your changes to the topic branch and '''pushing''' them to your fork; and
# filing a GitHub '''pull request''', having that request granted, then finally cleaning up.

=== Keeping your local repository up-to-date ===

In this step, you will make sure your local <code>master</code> branch is up-to-date with the most recent development changes before beginning work.

First make sure you are on your <code>master</code> branch:

git checkout master
git status

Now, pull the upstream <code>master</code> branch to your local repository:

upstream
|
|
| origin (fork)
|
v
local

git pull upstream master

At this point your local master is up to date. While you are at it, you might as well update your fork as well:

upstream

.--> origin (fork)
/
/
local --'

git push origin master

At this point, the <code>master</code> branch should be the same in all three repositories.

=== Creating a topic branch ===

In this guide, we will never make any changes directly on the <code>master</code> branch, and will only make code changes on a topic branch, so regardless of which repository you look at, the <code>master</code> branch should be the same, and <cite>Git</cite> will be comparing your work against the upstream <code>master</code> branch.

Now you are ready to create a new '''[https://git-scm.com/book/en/Git-Branching-Branching-Workflows#Topic-Branches <dfn>topic branch</dfn>]''', which will hold your work for this patch. We are on the <code>master</code> branch, as running "<kbd>git status</kbd>" will confirm. Create your new topic branch -- named, in this example, "<code>new-feature</code>" -- by running the following command:

git checkout -b new-feature

As shown in the <cite>gitref.org</cite> guide, you could also have done this with the following commands:

git branch new-feature
git checkout new-feature

Given that you were on the <code>master</code> branch when you created the <code>new-feature</code> topic branch, the <code>new-feature</code> branch will branch off from the ''tip'' of your current <code>master</code> branch, which is best, to avoid conflicts when the <code>new-feature</code> branch is eventually merged upstream.

=== Committing your changes and pushing to your fork ===

Now, you will make your changes to <cite>Wesnoth</cite>, test them, and commit them to your local repository, with the commands "<kbd>git add</kbd>" and "<kbd>git commit</kbd>", as shown in the <cite>gitref.org</cite> guide.

==== Committing guidelines ====

<ol>
<li>
<h5 style="font-size: larger">Write good commit messages</h5>

A commit message should fully explain what changes were made in the commit, and why those changes were made. A good commit message is structured like an email message.

The first line, which summarizes the commit, has special importance -- to quote the <cite>[[DeveloperGuide]]</cite> page, <q cite="http://wiki.wesnoth.org/DeveloperGuide#Commit_messages">This is the first (and often the only) line someone using browsing tools will see</q>. It should ideally be at most 80 characters (TODO: inconsistent with current policy), and is like the subject line of an email message. Commit message summary lines should be written in the imperative present tense, e.g., "Add field to <var>some_class</var>, with accessor methods", "Fix <var>other_class</var>'s constructor", "Delete unnecessary #include", etc.

After the summary line, there must be a blank line, after which comes the '''commit message body''', which is analogous to the body of an email message.

'''Optimally''', a commit's message would be so clearly and comprehensively explanatory that it would answer any questions that anyone might have about the commit, now, the next day, or years into the future -- which is especially important because the author of the commit likely won't always be around to answer those questions.

See also [//wiki.wesnoth.org/DeveloperGuide#Commit_messages the <cite>DeveloperGuide</cite> page's "Commit messages" section] and [https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#Commit-Guidelines the official Git book's "Commit Guidelines" section].
</li>
<li>
<h5 style="font-size: larger">Make appropriately sized commits</h5>

Each commit should correspond to a single logical step in your programming task. The commits constitute the project's development history; people will look at your commits to try to figure out how we got to where we are today, and may at some point need to undo the changes made in some of your commits to fix a future issue.

If you find it difficult to write a succinct commit message that fully explain what changes were made in the commit, and why those changes were made, then the commit is insufficiently fine-grained -- too large and too complicated. Another guideline is, you should at least think about committing almost every time you compile (depending on your habits).

On the other hand, you shouldn't make a commit for every line of code typed. If it would never make sense to revert the repository's code to its current state from a future state, you probably shouldn't commit. For example, if you define a field of an object, but it has no accessors and no way to be used in code, it would never make sense to revert to that time in the repository's history, so those changes should be saved together in a single commit. If you have a commit that merely adjusts whitespace in a file, that should be squashed in with another commit, according to current (2015-07-25) policy.

It is better to commit more often than less often, because, before you submit your changes to upstream, you will have the opportunity to edit your commit history, and it is much easier to ''squash'' commits together than to split up an overly-large commit.

See also [//wiki.wesnoth.org/DeveloperGuide#Commits the <cite>DeveloperGuide</cite> page's "Commits" section].
</li>
<li>
<h5 style="font-size: larger">Keep the change-logs, release notes, and credits up-to-date</h5>

After committing your changes, add an entry in the '''<code>changelog</code>''' document, and commit it with the message "Update changelog".

We also have a '''<code>players_changelog</code>''' document, which should contain only changes that most players are likely to notice, and be less technical than the main, technical <code>changelog</code>.

There is also a '''<code>RELEASE_NOTES</code>''' document, which basically is copied into the next <cite>Wesnoth</cite> release's release announcement post in the forums, so if there is a new feature or bug fix that should be advertised, add that to <code>RELEASE_NOTES</code>.

If this is your first commit, the development team will ask you to add an appropriate note about yourself in the '''credits document''', '''<code>data/about.cfg</code>'''.

See also [//wiki.wesnoth.org/DeveloperGuide#Changelogs_and_release_notes the <cite>DeveloperGuide</cite> page's "Changelogs and release notes" section].
</li>
</ol>

Finally, when your branch is ready, push it to your fork.

upstream

.--> origin (fork)
/
/
local --'

git push origin new-feature

Now, if you navigate to your fork's page on GitHub, you should see a message such as "recently pushed branch new-feature (3 minutes ago)". Click "Compare" to compare it against the <code>master</code> branch. You should now see a list of the commits you made on the <code>new-feature</code> branch, and color-highlighted diffs of the files you changed. You can click through the commits in order to see each of the changes you made and understand how your project progressed -- this is exactly what the development team will do when they review your pull request.

In the GitHub interface, you can always see a list of branches by clicking on "branches" in the line near the middle of the page that looks like the following:

10,000+ commits 27 branches 248 releases 85 contributors

You can also look at a specific branch using the "Branch" menu below that line, and you can compare branches using the green "Compare" button to the left of the "Branch" menu.

=== Cleaning up your branch ===

Before filing your pull request, if, looking at the diffs and the history (the list of commits) for your topic branch, you saw anything confusing or not quite right, now is your opportunity to change it.

From the <cite>gitref.org</cite> guide, you should know how to add more commits, and you should know that you can use "<kbd>reset</kbd>" to go back in time and redo things.

"'''<kbd>reset</kbd>'''" is especially good if your last commit was too big and you want to break it up into a series of smaller commits -- the command "<kbd>git reset "@~"</kbd>" will leave your working directory the same, but jump back in time one commit and unstage all of those changes, so you can add a smaller subset of the files, commit those, then add the others, etc.

More generally, you can use "'''<kbd>git reflog</kbd>'''" to see how to reset back over any number of commits or other <cite>Git</cite> operations.

You can also use "'''<kbd>git commit --amend</kbd>'''" to edit the commit message of the most recent commit.

There are several more advanced cleanup features available with <cite>Git</cite>, but we'll defer any further discussion of them.

Every time you make changes, you should to push them to your fork to keep it up-to-date. If you rewrote your commit history, then the push would be rejected, because the commit histories won't match. Therefore, to push a rewritten history, you must '''''force push''''', which will -- this is a potentially dangerous operation! -- discard the old commit history and replace it with the new history:

upstream

.--> origin (fork)
/
/
local --'

git push --force origin new-feature

You can and should do this throughout your development if you want to look at the diffs of your changes as you work -- after all, the <cite>Wesnoth</cite> code-base is vast and it is easy to forget exactly where you are in your project. You can and should keep cleaning up in this way until you are satisfied with the result. Doing this, your GitHub fork ends up being rather like a personal Web-based IDE plug-in or extension to help you with development.

=== Filing a pull request ===

When you finish working on your feature or bug fix, select your topic branch on your fork (with the "Branch" menu), and click the green button to file a pull request. By default, the target of the pull request -- the repository and branch into which it is requesting that your changes be pulled -- will be "<samp>wesnoth:master</samp>", the <code>master</code> branch of the main <cite>Wesnoth</cite> repository.

The message that you enter for the pull request should become the commit message of the merge operation performed in the upstream repository if the pull request is granted. (Note: if you are granting someone's PR through the GitHub Web interface, please ensure that this happens.)

If you fixed a bug, you should say, e.g., "Fixed bug #5678" in the pull-request message, which should automatically link to [https://gna.org/bugs/index.php?group=wesnoth&set=custom&report_id=101&status_id=1&chunksz=150&boxoptionwanted=1 our Gna! bug tracker].

If you want more information, you could read [https://help.github.com/articles/creating-a-pull-request/ GitHub's "<cite>Creating a pull request</cite>" help article].

upstream <-.
\
\
'- origin (fork)

local

You should then see your pull request in [https://github.com/wesnoth/wesnoth/pulls the main <cite>Wesnoth</cite> repository's "pull requests" page].

At the time of writing this, we also have configured [https://travis-ci.org Travis CI], a [https://en.wikipedia.org/wiki/Continuous_integration continuous integration] system, to automatically try to compile <cite>Wesnoth</cite> with your changes, to make sure that it still works before your pull request is granted. However, it is not mandatory for the Travis build to complete successfully for the pull request to be granted. Additionally, you may still make changes to your pull request by pushing more changes to your topic branch in your fork, after which Travis should try to compile the updated topic branch. You can even still force push to erase the content of the topic branch (on which the pull request is based) and replace it with new content -- however, you shouldn't file a pull request for a topic branch until you are ready for it to be merged.

Now, wait for a member of the development team to review your pull request. You can often find someone on the development [//wiki.wesnoth.org/Support#IRC IRC] channel, <code>#wesnoth-dev</code>. Additionally, developers may comment directly on your pull request with questions, so you should check it periodically.

=== Cleaning up at the end ===

Congratulations, a developer granted your pull request! Now it's time to clean up and update your local repository.

On the GitHub page for your pull request, you should now see a button with the option "delete this branch". Since the content of new-feature is now merged into master, this branch no longer needs to exist as you won't work on it anymore, and future work will go onto a different branch. So you should delete it, which will delete the branch on *origin*, your github-associated repo.

Since master has now changed and we want master to be synced up, you should now do step 1 again:

upstream
|
|
| origin (fork)
|
v
local

git checkout master
git pull upstream master

At this point git will understand that new-feature has been merged into master, so when you ask to delete this branch from local as well, it will do it:

git branch -d new-feature

If you do these steps out of order, i.e. try to delete the branch before before syncing master, it will make a warning "Are you sure? You have unmerged changes on this branch..." etc.

Finally, sync master on the origin as well:

upstream

origin (fork)
/-->
--/
local

git push origin master

That's the end of the development cycle, and now you can begin on your next patch. Note that throughout the cycle, information only flowed counter-clockwise:

upstream
| <--\
| \--
| origin (fork)
| /-->
v --/
local

If for some reason you find yourself doing something where information is flowing the other way, that is a good sign that something is going wrong, at least as far as this guide is concerned! (The exception is the steps in which we set up our repos -- don't overthink this.)

== Advanced / Alternative workflows ==

You can use pull requests as described above whether you have commit access or not -- if you have commit access, then you can click to accept your own pull requests.

However, if you have commit access, you may prefer not to use github / pull requests at all, and instead to push directly to wesnoth:master. You can still use topic branches to hold your work, and merge them to your local master using git merge, then use 'git push upstream master' to push them to the main wesnoth repo.

If you are lazy, you might even skip making a topic branch and just commit to local master, although IMO this can make things more confusing if you get a merge conflict later.

Either way, afaik the vast majority of wesnoth developers prefer to push directly to wesnoth:master.

An extreme option appropriate for small changes is to skip the local repo as well, and simply commit changes directly from the github web interface. This might be appropriate for example if you forgot to commit a changelog entry in an earlier patch, or are simply changing some numbers used as parameters somewhere. Obviously if you change source code this way, you should make certain that everything still compiles immediately after! (Note: Don't actually do that.)

== The ultimate cleanup power tool: git rebase ==

Using things in the gitref guide, you can see how to use reset to undo mistakes you made by backing up and trying again, and for small commits that is probably fine. However, if you have a large and complicated series of changes, the better way to do this is using git rebase. Using git rebase in interactive mode, you can rewrite history by

* reordering your commits
* discarding unwanted commits
* squashing commits together
* editing the content changes represented by an individual commit
* editing the commit message

For our purposes, we assume you are working on a topic branch, and then you will only need to use the form

git rebase -i master

You can see some documentation for using this command here: https://help.github.com/articles/interactive-rebase

Using 'git rebase', you can make your commit history very *clean* -- instead of the history saying "I tried a bunch of things, undid some of them, tried some other things, and found something I liked", your commit history can basically be "I took the simplest and most logical route to the solution that was finally the best". When you review your commits, instead of feeling like a nasty blood-and-elbow-grease engineering project, it should feel like folding a perfect origami crane, to the extent possible ;)

But to reiterate, this has a purpose.
# Other devs need to be able to understand the history.
# It should be possible to jump back in time by checking out one of your commits and find ourselves in a sensible state when we do so.
# If something breaks or some feature become incompatible, it should be possible to roll back only a piece of the implementation of your feature without removing the whole thing.

If you want to use rebase to cleanup your history, it is important to do it *before* it is pulled into wesnoth, as once that happens it is basically no longer possible. If we rewrite history in the main wesnoth repo, then afterwards whenever any dev tries to 'git pull upstream master', their git will give them strange merge errors, stemming from the incompatible history, and then they will become nervous, jump on irc and exclaim some variation of "omg wtf bbq". So except in extreme circumstances, we will never rebase the main wesnoth master, and for the same reason, we will never use "git push --force upstream master". That's why if you want to do these things, it is important to do them on your *fork* before it makes it onto master.

If you feel like it, you might read this, which is a historical email between early users / developers of git, in which Linus Torvalds explains about shared history of repos and when it is appropriate to use git rebase.

http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg39091.html

When you become comfortable with git rebase -i, it will greatly improve your workflow, as you will know that you can easily review and revise commit messages later, and easily reorder and squash commits. Typically I will now commit every single time I compile, and even if it is a commit which e.g. fixes a compile time error, or for some other reason I know it will be squashed in somewhere else, I give it the commit message "fixup", as a note to myself to mark it thusly in the first git rebase pass. (Actually, while writing this I have just learned about the --autosquash feature of git rebase which takes this idea further, good stuff there.)

Note that unlike Linus and github, in this guide we aren't thinking about your github fork repo as public -- we prefer to think of it as your personal private IDE/tool as I described earlier. If other wesnoth devs are cloning it or pulling your topic branches, we assume you will work it out with them. With that caveat the philosophies expressed on github and by Linus should generally apply to the wesnoth project as well.

=== Solving merge conflicts with git rebase ===

Github version: https://github.com/edx/edx-platform/wiki/How-to-Rebase-a-Pull-Request

Suppose that you modify a file in the same place as someone else, and their change gets merged before yours. If git can't figure out how to merge, then someone will have to fix it. This could be done by whoever is merging the new content into master, but if you don't have commit access then that person is not you. One way that *you* could fix it is to resync your master to get the new changes locally, and then rebase your topic branch so that your changes are applied *after* the most recent changes.

git rebase master

To understand what is happening, we should understand a bit more about how git works. Intuitively, git is all about "snapshots" of the project content. Every commit represents a snapshot, and you can look at this snapshot by checking out the commit. However git does not store each snapshot separately -- instead git defines the snapshots in terms of one another, and stores only the diffs. When you rebase your topic branch onto master, this will also update the "point of departure" where your branch was created, so that in the history, it will depart from the current head of master with the most recent changes. (Obviously, if you don't sync master until you are done working, then this subtlety to 'git rebase' is irrelevant.)

If merging your branch with the current master would create a conflict, then when git rebase gets to the commit that creates the conflict, it will get confused when it tries to apply that diff, stop, tell you about the problem, and ask you to resolve it -- you can open up the offending file and go to the point where the conflict is happening, and git will leave a note for you of the content it is having trouble with. The note will look similar to what happens in the gitref guide here, under "merge conflicts".

http://gitref.org/branching/#merge

You just have to remove the note, make the file look like it should to make everything compatible, and type

git add .
git rebase --continue

Then the rebasing process will continue, and at the end your branch should be compatible with master and ready to be merged in.

You can read more about this aspect of git rebase here if you like, although most likely you won't actually need more than we just talked about for wesnoth development.

http://git-scm.com/book/en/Git-Branching-Rebasing

That's all for this guide, have fun hacking on wesnoth!

== Addendum ==
The following section contains commands with the -f / --force options. Those are usually used to rewrite history, which is fine for your own fork but disallowed for upstream. Do not use them on the main repository.

If a command goes awry, you can go to "git reflog", find the point just before you typed it, and reset --hard to that commit, and it should be like the bad thing never happened

revert every file in the repo to look like it did at the HEAD commit (last successful sync)
git reset --hard HEAD

get a clean slate by syncing with upstream
git fetch upstream
git checkout -B master upstream/master
git push --force origin master
if this errors, try again after
git reset --hard HEAD

undo n commits, split/squash and apply again
git reset HEAD~n
git add -p
git commit
git push -f

You can also push from one ‘ref’ to a different one:
$ git push <remote> <from>:<to>

completely overwrite branch b with a (from a to b)
git push -f origin a:b

before any commit:

* if the diff shows an invisible change in the first line - stop! Fix the file encoding back to UTF8 without BOM.

* don't forget the changelog (and, for visible changes, the players_changelog)

* try to keep the summary at 50 characters or less, maximum 72

== See Also ==

* [[Project#Developers]]

[[Category:Development]]

DeveloperGuide

2015-07-02T10:17:16Z

Aquileia: /* Commit messages */

This page describes guidelines developers with push access to the Wesnoth repository should follow. Most items apply to prospective contributors as well, in addition to the [[PatchSubmissionGuidelines|patch submission guidelines]].

__TOC__

== General ==

* [[WesnothRepository#Push_access|Set up developer access to the repository.]]

* Be on the #wesnoth-dev IRC channel on freenode, and coordinate with other developers. Bots report commits and other developers may ask you questions or provide feedback.

== Commits ==

* Any given branch should compile without warnings and run after every commit -- we use [https://travis-ci.org/wesnoth/wesnoth Travis CI], which will report any build failures on master and maintenance branches (1.12, 1.14, etc.) to the #wesnoth-dev IRC channel.
* All unit tests should pass after commit -- Travis will also test this. To run the C++ unit tests on your own machine, compile the "test" executable and run it. To run the WML unit tests, run <code>run_wml_tests -u</code> in the checkout root. If a test times out spuriously on Travis, you can restart the build by
*# Clicking on the link posted to IRC by the Travis bot:
*#: 20141009 20:40:27-!- travis-ci [~travis-ci@ec2-184-73-55-78.compute-1.amazonaws.com] has joined #wesnoth-dev
*#: 20141009 20:40:27< travis-ci> wesnoth/wesnoth#4154 (master - c91604a : Ignacio R. Morelle): The build was broken.
*#: 20141009 20:40:27< travis-ci> Build details : http://travis-ci.org/wesnoth/wesnoth/builds/37536345
*#: 20141009 20:40:27-!- travis-ci [~travis-ci@ec2-184-73-55-78.compute-1.amazonaws.com] has left #wesnoth-dev []
*# Clicking on the [http://i.imgur.com/mxwVKJP.png restart button] on the Travis website.
* Do not disable or ignore unit tests without a very good reason!
* A few small commits are better than a single large commit (which is hard to review), so when possible split it in working parts with info about where you are going
* Always review your changes, both before committing locally and before pushing upstream (see [[WesnothRepository#Reviewing your changes]]).
* Never use the "force" option when pushing to the upstream Wesnoth repositories (see [[WesnothRepository#Force-pushing_policy]]).

=== Changelogs and release notes ===

We provide two separate changelogs at the root of the Wesnoth distribution and Git checkouts. The players_changelog file only contains entries for changes deemed relevant for players (not content creators), while the main changelog contains all changes, except for those that are only relevant to mainline developers and which are not expected to impact players or creators in any way.

It is your responsibility to update both changelogs as you see fit for every commit. For large changes spread over long series of commits, you will probably prefer to commit your changelog additions in a separate last commit to avoid or mitigate conflicts when merging upstream.

Important changes that might be expected to inconvenience or confuse players (including those building from source) or content creators, major bug fixes, and noteworthy feature additions for a future release should be mentioned and explained in RELEASE_NOTES as well, so that the release team can include this information in official announcements. See the contents of the file for instructions.

=== Commit messages ===

A good commit should not only contain good changes, but also include a helpful description of them for other developers, people tracking regressions, project maintainers, and even yourself in the future. There are many style guides on the Web describing best practices for documenting your Git commits.

For Wesnoth in particular, the general consensus is that contributors should adhere to the following rules:

* Every commit message should begin with a self-contained summary/subject line no more than 72 characters long. This is the first (and often the only) line someone using browsing tools will see.
* If your message needs more than a leading summary line, separate it from the rest with a blank line.
* Subsequent lines should also be no more than 72 characters long. Use blank lines to separate paragraphs and list items.
* When working on a mainline campaign/scenario, start the commit message with its acronym. For example <code>HttT: </code> when working on HttT in general and <code>HttT S3: </code> if the commit only applies to the third scenario of HttT (see below).
* Likewise, if you work on the code of a specific component, you may want to use it as a prefix. That is e.g., <code>gui2: </code> or <code>wesnothd: </code>.
* If you are performing branch merges, Git may include a list of conflicted paths in the commit message template. Edit this out; it ceases to be interesting after the conflicts have been resolved.
* If you need to mention commit SHA1 hashes (e.g. in revert messages), make sure to use hashes from the upstream repository that are unlikely to change due to a future local or remote merge or rebase operation.

There are a few additional points to keep in mind for the wording of the contents:

* Include "bug #1234" somewhere in your commit message if it addresses a bug or feature request from the Wesnoth bug tracker.
* Use the project's [[WesnothAcronyms|standard abbreviations]] for campaigns and gameplay concepts, like HttT for <cite>Heir to the Throne</cite>, ZoC for "Zone of Control", etc. If referring to a particular campaign or scenario in your commit subject, you should use this convention: "HttT S1: Made Galdrad less suicidal"

== Dependencies ==
* Any changes to Wesnoth's build and run-time dependencies must be discussed on the developers mailing list first.
* Update the CMake and SCons recipes accordingly.
* Changes must be mentioned in the RELEASE_NOTES file, so they can be included in the forum announcement for the next release, and in the emails to packagers.

== Bugs management ==
* Change Status field of fixed bugs to "Fixed" after pushing upstream
* Change Open/Closed field of fixed bugs to "Closed" after a release including the relevant commits has been published. See [[ReportingBugs#Bug_protocol]] for details.
* Check regularly if there are new bugs relevant to your code and, if any, assign them to you.

== See also ==
* [[Project#Developers]]
* [[WesnothRepository]]

[[Category:Development]]

DeveloperGuide

2015-07-02T10:09:57Z

Aquileia: Prefix rule for scenario acronyms and components

This page describes guidelines developers with push access to the Wesnoth repository should follow. Most items apply to prospective contributors as well, in addition to the [[PatchSubmissionGuidelines|patch submission guidelines]].

__TOC__

== General ==

* [[WesnothRepository#Push_access|Set up developer access to the repository.]]

* Be on the #wesnoth-dev IRC channel on freenode, and coordinate with other developers. Bots report commits and other developers may ask you questions or provide feedback.

== Commits ==

* Any given branch should compile without warnings and run after every commit -- we use [https://travis-ci.org/wesnoth/wesnoth Travis CI], which will report any build failures on master and maintenance branches (1.12, 1.14, etc.) to the #wesnoth-dev IRC channel.
* All unit tests should pass after commit -- Travis will also test this. To run the C++ unit tests on your own machine, compile the "test" executable and run it. To run the WML unit tests, run <code>run_wml_tests -u</code> in the checkout root. If a test times out spuriously on Travis, you can restart the build by
*# Clicking on the link posted to IRC by the Travis bot:
*#: 20141009 20:40:27-!- travis-ci [~travis-ci@ec2-184-73-55-78.compute-1.amazonaws.com] has joined #wesnoth-dev
*#: 20141009 20:40:27< travis-ci> wesnoth/wesnoth#4154 (master - c91604a : Ignacio R. Morelle): The build was broken.
*#: 20141009 20:40:27< travis-ci> Build details : http://travis-ci.org/wesnoth/wesnoth/builds/37536345
*#: 20141009 20:40:27-!- travis-ci [~travis-ci@ec2-184-73-55-78.compute-1.amazonaws.com] has left #wesnoth-dev []
*# Clicking on the [http://i.imgur.com/mxwVKJP.png restart button] on the Travis website.
* Do not disable or ignore unit tests without a very good reason!
* A few small commits are better than a single large commit (which is hard to review), so when possible split it in working parts with info about where you are going
* Always review your changes, both before committing locally and before pushing upstream (see [[WesnothRepository#Reviewing your changes]]).
* Never use the "force" option when pushing to the upstream Wesnoth repositories (see [[WesnothRepository#Force-pushing_policy]]).

=== Changelogs and release notes ===

We provide two separate changelogs at the root of the Wesnoth distribution and Git checkouts. The players_changelog file only contains entries for changes deemed relevant for players (not content creators), while the main changelog contains all changes, except for those that are only relevant to mainline developers and which are not expected to impact players or creators in any way.

It is your responsibility to update both changelogs as you see fit for every commit. For large changes spread over long series of commits, you will probably prefer to commit your changelog additions in a separate last commit to avoid or mitigate conflicts when merging upstream.

Important changes that might be expected to inconvenience or confuse players (including those building from source) or content creators, major bug fixes, and noteworthy feature additions for a future release should be mentioned and explained in RELEASE_NOTES as well, so that the release team can include this information in official announcements. See the contents of the file for instructions.

=== Commit messages ===

A good commit should not only contain good changes, but also include a helpful description of them for other developers, people tracking regressions, project maintainers, and even yourself in the future. There are many style guides on the Web describing best practices for documenting your Git commits.

For Wesnoth in particular, the general consensus is that contributors should adhere to the following rules:

* Every commit message should begin with a self-contained summary/subject line no more than 72 characters long. This is the first (and often the only) line someone using browsing tools will see.
* If your message needs more than a leading summary line, separate it from the rest with a blank line.
* Subsequent lines should also be no more than 72 characters long. Use blank lines to separate paragraphs and list items.
* When working on a mainline campaign/scenario, start the commit message with its acronym. For example <code>HttT: </code> when working on HttT in general and <code>HttT S3: </code> if the commit only applies to the third scenario of HttT.
* Likewise, if you work on the code of a specific component, you may want to use it as a prefix. That is e.g., <code>gui2: </code> or <code>wesnothd: </code>.
* If you are performing branch merges, Git may include a list of conflicted paths in the commit message template. Edit this out; it ceases to be interesting after the conflicts have been resolved.
* If you need to mention commit SHA1 hashes (e.g. in revert messages), make sure to use hashes from the upstream repository that are unlikely to change due to a future local or remote merge or rebase operation.

There are a few additional points to keep in mind for the wording of the contents:

* Include "bug #1234" somewhere in your commit message if it addresses a bug or feature request from the Wesnoth bug tracker.
* Use the project's [[WesnothAcronyms|standard abbreviations]] for campaigns and gameplay concepts, like HttT for <cite>Heir to the Throne</cite>, ZoC for "Zone of Control", etc. If referring to a particular campaign or scenario in your commit subject, you should use this convention: "HttT S1: Made Galdrad less suicidal"

== Dependencies ==
* Any changes to Wesnoth's build and run-time dependencies must be discussed on the developers mailing list first.
* Update the CMake and SCons recipes accordingly.
* Changes must be mentioned in the RELEASE_NOTES file, so they can be included in the forum announcement for the next release, and in the emails to packagers.

== Bugs management ==
* Change Status field of fixed bugs to "Fixed" after pushing upstream
* Change Open/Closed field of fixed bugs to "Closed" after a release including the relevant commits has been published. See [[ReportingBugs#Bug_protocol]] for details.
* Check regularly if there are new bugs relevant to your code and, if any, assign them to you.

== See also ==
* [[Project#Developers]]
* [[WesnothRepository]]

[[Category:Development]]

PatchSubmissionGuidelines

2015-06-24T08:17:32Z

Aquileia: Derate VC to minor build environment (although several devs use it, not even all of them care to add their changes in the project file...)

Submitting a patch for a large and mature project like Wesnoth can be an even more daunting task than writing the code it delivers. This page provides some advice and requirements for prospective code contributors seeking the best chance of acceptance for their patches.

== Technical requirements ==

* '''All patches should be submitted as GitHub pull requests''' You may post them in the [http://forums.wesnoth.org/viewtopic.php?f=10 Coder's Corner] forum for discussion too, but we need to track their status, and GitHub is better suited for this. See [http://wiki.wesnoth.org/WesnothRepository this] page for help on using git and GitHub.

* '''Add entries to the changelogs summarizing your changes if necessary''' The <code>changelog</code> file contains a list of outstanding changes that is published with every release. If you are fixing a bug or adding a feature that is particularly visible or important for players, you should also add an entry to the <code>players_changelog</code> file.

* '''When adding new C++ source code files, make sure to update the most commonly used project files''' The development team primarily uses CMake and SCons. The relevant files are <code>src/CMakeLists.txt</code> and <code>src/SConscript</code>. You may take a look at how existing source code files are handled in each build script to get an idea of the best way to add your own. Please consider updating the other build environments under <code>projectfiles/</code>, e.g. Visual C++, as well.

* '''C++ source code patches must not generate new warnings''' Wesnoth has a large number of compiler warnings enabled, and all of them are useful. If your code causes new warnings during build, you will be required to fix them.

* '''Add yourself to the game credits''' Including your name and/or username(s) makes it easier for the development team and the community at large to recognize your contributions. New contributors (i.e. those without commit access) should add themselves to the ''Miscellaneous Contributors'' section of the credits file (<code>data/core/about.cfg</code>), making sure to follow alphabetical order with respect to the first character that will be displayed.

* '''When changing or adding WML features, provide directions for updating the wiki along with your submission in the tracker''' This allows us to provide content creators with up-to-date information about WML features, even if you cannot be around in time for the commit or the next release.

== After submission ==

* '''Be patient, sometimes we are not very responsive''' The Wesnoth developers live on different locations across the globe and have other matters to attend to, most of the time. It may happen that your patch is assigned to a developer who is currently unable to dedicate much time to reviewing it. If you feel that it takes way too long for us to respond, contact us in #wesnoth-dev on irc.freenode.net.

* '''Don't be surprised if we discuss the patch a lot''' Thus, you should leave us a way to contact you, either a forum nick, an email address, or submit with a registered Gna.org account. We recommend that you join the #wesnoth-dev channel on <code>irc.freenode.net</code> regularly so we can contact you in real time if needed.

* '''Sometimes patches are rejected, don't be surprised if this happens''' If your patch introduces new errors or bugs, the feature you implemented isn't considered an improvement or we couldn't contact you with our questions and recommendations, the pull request will be closed without merging. This can usually be averted if you discuss your idea on #wesnoth-dev as the developers will point out these issues. If it happens, don't let this discourage you; it's just necessary to ensure Wesnoth remains enjoyable.

== Obtaining help ==

If you encounter any issues or need additional guidance when preparing your patch, the easiest way is to ask the developers on the aforementioned IRC channel #wesnoth-dev. You can e.g. log in via 
http://webchat.freenode.net/?channels=wesnoth-dev

If you know who is responsible for the code your patch addresses, please prefix their IRC name in front of your question - else your message could be overlooked.

If your patch has a major impact on Wesnoth, the developer mailing list on https://gna.org/mail/?group=wesnoth might be more appropriate as all developers will be notified.

== See also ==

* [[HackingWesnoth]]
* [[CodingStandards]]
* [[EasyCoding]]
* [[DeveloperResources]]

[[Category:Development]]

Download/de

2015-04-29T02:29:54Z

Aquileia: 1.13 muss nicht mehr versteckt werden

{{Download/Translations}}
Willkommen auf der Battle for Wesnoth-Downloadseite. Das BfW-Team veröffentlicht offiziell nur den Quelltext. Binärpakete werden nur von Freiwilligen aus der Gemeinschaft zur Verfügung gestellt und hier angeboten.

Wenn die neuesten Binärpakete für dein Betriebssystem momentan noch nicht verfügbar sind, überprüfe einfach alle paar Tage ob du sie hier finden kannst. Die jeweilig Verantwortlichen wurden informiert, bitte habe etwas Geduld. In der Zwischenzeit kannst du die [[/FAQ/de#Eine_neue_Version_wurde_ver.C3.B6ffentlicht.2C_aber_wo_kann_man_die_.5BWindows.2C_Mac_OS_X.2C_usw..5D-Version_herunterladen.3F|FAQ-Seite]] lesen.
__NOTOC__
Springen zu: [[Download/de#Hauptversion (1.12-Zweig)|Hauptversion]] | [[Download/de#Entwicklungsversion (1.13-Zweig)|Entwicklungsversion]]

== Hauptversion (1.12-Zweig) ==
Die Hauptversion ist eine stabile und ziemlich ausgewogene Version des Spiels. Alle Versionen des 1.12-Zweigs sind miteinander kompatibel.

==== Quelltext ====
* [[CompilingWesnoth|Kompilierungsanleitung]] - wie man den Quelltext kompiliert
{{StableDownload|Neueste Version|Vorherige Version|md5sum für den aktuellen Quelltext}}

==== GNU/Linux ====
* Es gibt Binärpakete für viele verschiedene GNU/Linux-Distributionen. Nicht alle sind immer auf dem Stand der neuesten Version. Für mehr Informationen über die Binärpakete für deine Distribution lies bitte die [[WesnothBinariesLinux|entsprechende Seite]].

==== Verschiedenes ====
* [http://www.wesnoth.org/wiki/Download_Xdeltas#Stable_Version_1.12.x Xdelta für den Quelltext]
* [http://sourceforge.net/projects/wesnoth/files/ SourceForge-Seite für die aktuellen und alle vorherigen Versionen]

== Entwicklungsversion (1.13-Zweig) ==
Version 1.13.x ist die neueste Entwicklungsversion, die verbesserte Grafik und neue aufregende Inhalte vorstellt. Allerdigs können auch Programmierfehler oder andere Probleme auftreten, da schwerwiegende Änderungen stattfinden.

Um ausgewogen und stabil zu spielen solltest du die neueste Version des 1.12-Zweigs benutzen. Diese Version hingegen ist Programmierern und Kampagnenentwicklern zu empfehlen, ebenso wie denen, die wissen wollen, wie Wesnoth zukünftig aussehen wird.

Wer mit Versionskontrolle und Kompilierung vertraut ist, kann der aktuellen Entwicklung durch das Überprüfen von [[WesnothRepository]] folgen.

==== Quelltext ====
* [[CompilingWesnoth|Kompilierungsanleitung]] - wie man den Quellext kompiliert
{{DevDownload|Neueste Version|Vorherige Version|md5sum für den aktuellen Quelltext}}

==== GNU/Linux ====
* Es gibt Binärpakete für viele verschiedene GNU/Linux-Distributionen. Nicht alle sind immer auf dem Stand der neuesten Version. Für mehr Informationen über die Binärpakete für deine Distribution lies bitte die [[WesnothBinariesLinux|entsprechende Seite]].

==== Verschiedenes ====
* [http://wiki.wesnoth.org/Download_Xdeltas#Development_Version_1.13.x Xdelta für den Quelltext]
* [http://sourceforge.net/projects/wesnoth/files/ SourceForge-Seite für die aktuelle und alle vorherigen Versionen]
* [http://sourceforge.net/projects/wesnoth/files/unofficial/Mac%20Compile%20Stuff/wesnoth_compile_mac_1.9.zip/download MacCompileStuff für 1.9]

== Lizenz ==
''Hauptartikel: [[Wesnoth:Copyrights]]

Dieses Programm ist freie Software; du kannst es weitervertreiben und/oder modifizieren, solange das unter den Bedingungen der [http://www.fsf.org/copyleft/gpl.html GNU General Public License version 2] bleibt, veröffentlicht von der [http://www.fsf.org Free Software Foundation].
Dieses Programm wird mit der Hoffnung vertrieben, dass es nützlich ist, allerdings ohne Garantie; ohne die auch nur angedeutete Garantie auf Marktgängigkeit oder Eignung für eine bestimmte Absicht. Siehe die GNU Allgemeine Öffentliche Lizenz für mehr Informationen.

== Erweiterungseditor ==
Dieser ist für 1.9.x (und höher, einschließlich 1.12.x) verfügbar.
Details und Installationsanweisungen sind auf http://eclipse.wesnoth.org zu finden.

== Siehe auch ==
* [http://changelog.wesnoth.org Versionshistorie]
* [[WesnothRepository]] - bleeding-edge-Version von Quelle

[[Category:Building and Installing]]

DevFeature

2015-04-18T09:50:24Z

Aquileia: /* Previous DevFeature templates */

== Explanation ==

Items marked with the text {{DevFeature1.13|5}} are WML or Lua features only available in a development version of the game.

This WML reference contains the current WML syntax and Lua API for the stable branch. However, the development version of the game is rapidly growing with new and exciting capabilities.

As new features are added, it is very important to track which ones pertain to the stable and development versions. Sometimes a feature is only available in the master branch of the Git repository (i.e. it hasn't been released yet), or sometimes it is a relatively mature addition.

If a specific version is specified (e.g. '''1.13.5'''), that means the feature is known to be specifically available in that and later versions. For features recently implemented in the master branch of the repository, the version number may refer to a release that has not been published yet.

== Using DevFeature in documentation ==

The [[Template:DevFeature1.13]] template may be used as follows:

<nowiki>{{DevFeature1.13|5}}</nowiki>

{{DevFeature1.13|5}}



[[Category:Wesnoth Wiki]]

IGNFileFormat

2015-04-08T00:26:57Z

Aquileia: Update for commit 24d46b7a744

__NOTOC__
When you upload an add-on, some files and directories are ignored and not uploaded.

If you would prefer to have more control over which files and directories should be ignored, you should provide a _server.ign file containing a list of filter patterns. Each file or directory matching any entry of the _server.ign file will not be included when uploaded to the add-ons server.

== Where do I put the file, and what goes in it? ==

The file should be placed within the root level of your add-on (data/add-ons/addon_name/_server.ign).

A specific format is required:

* {{DevFeature1.13|0}}: Blank lines and lines beginning with '# ' (space required) are ignored.
* Each line should contain exactly one pattern.
* * and ? wildcards are supported (? stands for any single character, * stands for any number of any characters).
* Patterns with a trailing forward slash (/) will match directories; the rest only match files.

==== Default values ====

If there is no custom _server.ign file present, a default filter will be used instead, which as of Wesnoth 1.12 is as follows:

.*
.*/
__MACOSX/
#*#
*~
*-bak
*.swp
*.pbl
*.ign
_info.cfg
*.exe
*.bat
*.cmd
*.com
*.scr
*.sh
*.js
*.vbs
*.o
Thumbs.db
*.wesnoth
*.project

If there is a custom _server.ign file, the contents of the file are used as the filter '''instead''' of the defaults, so you should include any of the applicable default exclusions patterns in your own file as well.

== See Also ==

* [[PblWML]]

[[Category:Create]]

IGNFileFormat

2015-03-18T19:29:25Z

Aquileia: __MACOSX is a directory ignore rule

__NOTOC__
When you upload an add-on, some files and directories are ignored and not uploaded.

If you would prefer to have more control over which files and directories should be ignored, you should provide a _server.ign file containing a list of filter patterns. Each file or directory matching any entry of the _server.ign file will not be included when uploaded to the add-ons server.

== Where do I put the file, and what goes in it? ==

The file should be placed within the root level of your add-on (data/add-ons/addon_name/_server.ign).

A specific format is required:

* Each line should contain exactly one pattern and nothing else.
* * and ? wildcards are supported (? stands for any single character, * stands for any number of any characters).
* Patterns with a trailing forward slash (/) will match directories; the rest only match files.

==== Default values ====

If there is no custom _server.ign file present, a default filter will be used instead, which as of Wesnoth 1.12 is as follows:

.*
.*/
__MACOSX/
#*#
*~
*-bak
*.swp
*.pbl
*.ign
_info.cfg
*.exe
*.bat
*.cmd
*.com
*.scr
*.sh
*.js
*.vbs
*.o
Thumbs.db
*.wesnoth
*.project

If there is a custom _server.ign file, the contents of the file are used as the filter '''instead''' of the defaults, so you should include any of the applicable default exclusions patterns in your own file as well.

[[Category:Create]]

WML for Complete Beginners: Chapter 2

2015-03-17T18:16:35Z

Aquileia: Alternative userdata location on Windows

==Chapter 2: The Userdata Directory and the Campaign Folder==

So now that you understand the basic syntax of WML, it's time to learn where The Battle for Wesnoth stores files so that we can begin creating our campaign.

===The Userdata Directory===

There are two main directories that Wesnoth creates on your computer. The '''installation directory''' contains all the files for the core game. The '''userdata directory''' stores all your personal Wesnoth data, which includes your installed add-ons, your settings and preferences, and your saved games. The userdata directory is where we will store your work throughout this tutorial.

The location of your userdata directory differs depending on your operating system, and in the case of Microsoft Windows, the version of your operating system. Refer to the following table to determine where your userdata directory is located:

{| border="1"
!Windows XP
|~/My Documents/My Games/Wesnoth 1.10/
|-
!Windows Vista and above
|~/Documents/My Games/Wesnoth 1.10/
|-
!Mac OS X
|~/Library/Application Support/Wesnoth 1.10/
|-
!Linux
|~/.local/share/wesnoth/1.10/
|}

''Note:'' On Windows, if you chose 'Store userdata in the install location' during setup, the userdata directory is usually in 
~/AppData/Local/VirtualStore/Program Files (x86)/Battle for Wesnoth 1.10.7

Now navigate to your userdata folder. Provided that you have already run the Wesnoth application at least once before, you should see a total of five folders ("cache", "data", "editor", "persist", and "saves") in this directory, along with two files ("preferences" and "save_index.gz"). If you see all seven of these, everything is good. If you do not see all seven, try running the Wesnoth application. If that does not work, try restarting your computer. If neither of these steps work, reinstall Wesnoth.

Of the seven objects contained in the userdata folder, you will only ever need to directly interact with two: the "data" folder and the "editor" folder.

====The data folder====

:The data folder is where all installed add-ons are kept. This is where we will be building our campaign, when we get to that. If you have previously installed any Wesnoth add-ons, they should show up in this folder.

====The editor folder====

:The editor folder is where all maps created with the in-game map editor are stored. If you have ever created and saved a map in-game, you should see the map file in this directory.

===The Campaign Folder===

Like I told you earlier, all add-ons are installed in the data folder inside the userdata directory. That means that your campaign will also be located inside the data folder. If you're not already there, enter the data folder now.

Next, create a new folder inside the data folder. Name this new folder "my_first_campaign" exactly as I wrote it here (but don't include the quotation marks). Make sure you spelled it right, that you didn't accidentally capitalize any letters and that you included the underscores between the words in the folder name, because if you don't your campaign won't work when you try to play it.

Now enter the "my_first_campaign" folder and create seven new folders. Name these folders "images", "macros", "maps", "scenarios", "translations", "units" and "utils" (again, make sure you spelled everything right, that you didn't accidentally capitalize anything, and that you didn't include the quotation marks).

All campaigns share this common folder structure.

Continue to [[WML for Complete Beginners: Chapter 3]]

[[Category:WML_for_Complete_Beginners]]

DevelopersHome

2015-03-13T09:59:20Z

Aquileia: Update link to commit history

= General Information =
* Links
** [http://changelog.wesnoth.org Changelog] - the most recent changes made to the game
** [https://github.com/wesnoth/wesnoth/commits/master Latest commits] - Up-to-date commit messages

* Coding Guidelines
** [[Git_for_Wesnoth_Crash_Course]] - guide for contributors who are new to git
** [[HackingWesnoth]] - guide for programmers
** [[CodingStandards]] - for programmers
** [[DeveloperGuide]] - for those who received repository commit rights
** [[SoftwareTesting]] - for programmers

* Library documentation
** http://www.sgi.com/tech/stl/ - Standard Template Library
** [http://www.boost.org/doc/libs/1_36_0/ Boost 1.36 documentation]

* Debugging Tips
** [[DebuggingWesnoth]]

= Tools and Packaging =
* Supporting Websites
** [[WesnothRepository]] - accessing the source code
** http://gettext.wesnoth.org/ - gettext status
* Compiling and Building
** [[CompilingWesnoth]] - how to compile Battle for Wesnoth (it's not hard)
** [[SCons]]
* Packaging and Releasing
** [[ReleasingWesnoth]] - steps to follow to release a new version
* Documentation
** [[Doxygen]] - Documentation generator
* More stuff
** [[ExternalUtilities]] (Wercator, CampGen, wmllint, etc.)
** [[MaintenanceTools]] WMLLint, WMLIndent and WMLScope
** [[UsingGooglePerformanceTools]] to profile Wesnoth CPU and memory usage.

= I want to start coding, what can I do? =
* [[EasyCoding]] - Bugs and features that are easy to implement for new coders
* [[NotSoEasyCoding]] - Bugs and features which are doable but lacking someone working on them
* [[GettingStarted]]
* [[FrequentlyProposedIdeas]] - summary of past often-repeated forum discussions
* [[Glossary]]

= Game - Create content =
* [[BuildingScenarios]] and related useful forum discussions:
** [http://www.wesnoth.org/forum/viewtopic.php?t=4188 Beginning Campaign Development]
** [http://www.wesnoth.org/forum/viewtopic.php?t=4301 A Balancing Act]
* [[ReferenceWML]]

= Code documentation =
* http://devdocs.wesnoth.org - generated code documentation
* AI
** [[AI_Module]] - guide to AI module (src/ai)
** [[FormulaAI]] - Guide to the experimental formula AI branch
* Themes
** [[ThemeSystem]] - customizing the screen layout for the game and the editor
* Multiplayer
** [[WesnothdDesign]] - Guide to the design of wesnothd, the multiplayer server.
* Gui2 - The new Gui-Framework
** [[GUIToolkit]]
** [[GUILayout]]
** [[GUIVariable]]
** Gui2 WML
*** [[GUICanvasWML]]
*** [[GUIToolkitWML]]
*** [[GUIWidgetDefinitionWML]]
*** [[GUIWidgetInstanceWML]]
*** [[GUIWindowDefinitionWML]]
* Savegames
** [[SavegameClassHierarchy]]

= Communication, Feedback, Events =
* Gna! links
** http://bugs.wesnoth.org/ - Gna! - bugs and feature requests
** http://patches.wesnoth.org/ - Gna! - patches

* Mailing lists
** https://mail.gna.org/listinfo/wesnoth-dev/ - wesnoth-dev
** https://mail.gna.org/listinfo/wesnoth-commits/ - wesnoth-commits

* IRC
** [irc://irc.wesnoth.org/#wesnoth-dev freenode/#wesnoth-dev] - IRC (alias to irc.freenode.net)
** http://irclog.wesnoth.org/ - IRC logs

* Forum - http://forum.wesnoth.org

* This wiki - http://www.wesnoth.org/wiki/Main_Page

* FOSDEM
** [[Fosdem2008]]
** [[Fosdem2009]]
** [[Fosdem2010]]
** [[Fosdem2011]]
** [[Fosdem2012]]

* Google Summer of Code
** [[SummerOfCodeIdeas]] - Ideas for GSoC
** [[SoC_Information_for_Google]] - Our organization profile for Google
** [[SoC_People_to_bug_on_IRC]] - Who GSoC students can ask for help

= Miscellaneous =
* [[DebugMode]] and [[CommandMode]] - in game debugging commands
* [http://www.wesnoth.org/units/trunk/animations.html Missing unit animations] - what's available and what's missing
* http://units.wesnoth.org/ - Unit reference

[[Category:Development]]

DevFeature

2015-03-13T00:37:53Z

Aquileia: Remove deprecated version-less syntax (separate edit)

== Explanation ==

Items marked with the text {{DevFeature1.13|5}} are WML or Lua features only available in a development version of the game.

This WML reference contains the current WML syntax and Lua API for the stable branch. However, the development version of the game is rapidly growing with new and exciting capabilities.

As new features are added, it is very important to track which ones pertain to the stable and development versions. Sometimes a feature is only available in the master branch of the Git repository (i.e. it hasn't been released yet), or sometimes it is a relatively mature addition.

If a specific version is specified (e.g. '''1.13.5'''), that means the feature is known to be specifically available in that and later versions. For features recently implemented in the master branch of the repository, the version number may refer to a release that has not been published yet.

== Using DevFeature in documentation ==

The [[Template:DevFeature1.13]] template may be used as follows:

<nowiki>{{DevFeature1.13|5}}</nowiki>

{{DevFeature1.13|5}}

== Previous DevFeature templates ==

Some items are marked with {{DevFeature1.11}}. These features were created in the 1.11 series and are now in the stable 1.12 branch and all later versions.

This template indicates the history of the features and can be safely removed. Its uses are mainly leftover <code><nowiki>{{DevFeature1.11}}</nowiki></code> tags that haven't been removed yet:

http://wiki.wesnoth.org/index.php?title=Special:WhatLinksHere/Template:DevFeature1.11

[[Category:Wesnoth Wiki]]

DevFeature

2015-03-13T00:34:38Z

Aquileia: 1.7 and 1.9 versions are eliminated, 1.11 is to be pruned, 1.13 is the new development series

== Explanation ==

Items marked with the text {{DevFeature1.13}} are WML or Lua features only available in a development version of the game.

This WML reference contains the current WML syntax and Lua API for the stable branch. However, the development version of the game is rapidly growing with new and exciting capabilities.

As new features are added, it is very important to track which ones pertain to the stable and development versions. Sometimes a feature is only available in the master branch of the Git repository (i.e. it hasn't been released yet), or sometimes it is a relatively mature addition.

If a specific version is specified (e.g. '''1.13.5'''), that means the feature is known to be specifically available in that and later versions. For features recently implemented in the master branch of the repository, the version number may refer to a release that has not been published yet.

== Using DevFeature in documentation ==

The [[Template:DevFeature1.13]] template may be used in either of the following forms:

'''Preferred (version) form:'''
<nowiki>{{DevFeature1.13|5}}</nowiki>

{{DevFeature1.13|5}}

'''Alternative (version-less) form:'''
<nowiki>{{DevFeature1.13}}</nowiki>

{{DevFeature1.13}}

== Previous DevFeature templates ==

Some items are marked with {{DevFeature1.11}}. These features were created in the 1.11 series and are now in the stable 1.12 branch and all later versions.

This template indicates the history of the features and can be safely removed. Its uses are mainly leftover <code><nowiki>{{DevFeature1.11}}</nowiki></code> tags that haven't been removed yet:

http://wiki.wesnoth.org/index.php?title=Special:WhatLinksHere/Template:DevFeature1.11

[[Category:Wesnoth Wiki]]

Download

2015-02-20T16:44:21Z

Aquileia: Fix braces

{{Download/Translations}}
Welcome to the ''Battle for Wesnoth'' downloads page. The BfW project team officially releases the source code and builds for Windows, OS X, OpenPandora, and various Linux distributions. Torrents are unofficial.

If the latest binaries are not currently available for your OS, please check back in a few days to see if they have been placed here. Packagers have been informed of the release, please be patient. In the meantime, read the [[FAQ#A_new_version_is_out.2C_but_where_is_the_download_for_.5BWindows.2C_Mac_OS_X.2C_etc..5D.3F|FAQ]].

Wesnoth is also available for OS X from [http://brew.sh/ Homebrew] and [http://www.macports.org/ Macports]. Macports carries only the stable version. Homebrew carries stable release, development release, and can also build the "bleeding edge" master branch.
__NOTOC__
== Stable (1.12 branch) ==
The stable files are meant to be used as a stable and rather balanced version of the game. Each version of the 1.12 branch is compatible to each other.

==== Source code ====
* [[CompilingWesnoth|Compiling Guide]] - How to compile the source code
{{StableDownload}}

==== GNU/Linux ====
* There are binaries for many different GNU/Linux distributions. Not all are always up to date with the current release. Please have a look at the [[WesnothBinariesLinux|Linux binary page]] for more information about the binaries for your distribution.

==== Miscellaneous ====
* [http://www.wesnoth.org/wiki/Download_Xdeltas#Stable_Version_1.12.x Xdelta for the source code]
* [http://sourceforge.net/projects/wesnoth/files/ SourceForge page for current and all previous versions]


== License ==
''Main article: [[Wesnoth:Copyrights]]''

This program is free software; you can redistribute it and/or modify it under the terms of the [http://www.fsf.org/copyleft/gpl.html GNU General Public License version 2], as published by the [http://www.fsf.org Free Software Foundation].

This program is distributed in the hope that it will be useful, but without any warranty; without even the implied warranty of merchantability or fitness for a particular purpose. See the GNU General Public License for more details.

== UMC Editor ==

This is available with Wesnoth 1.9.x and greater (including Wesnoth 1.12.x). Details and installation steps can be found at: http://eclipse.wesnoth.org

== See also ==
* [http://changelog.wesnoth.org Changelog]
* [[WesnothRepository]] - bleeding edge version from the repository

[[Category:Building and Installing]]

Download

2015-02-20T16:43:20Z

Aquileia: Re-add translation list

{{Download/Translations}
Welcome to the ''Battle for Wesnoth'' downloads page. The BfW project team officially releases the source code and builds for Windows, OS X, OpenPandora, and various Linux distributions. Torrents are unofficial.

If the latest binaries are not currently available for your OS, please check back in a few days to see if they have been placed here. Packagers have been informed of the release, please be patient. In the meantime, read the [[FAQ#A_new_version_is_out.2C_but_where_is_the_download_for_.5BWindows.2C_Mac_OS_X.2C_etc..5D.3F|FAQ]].

Wesnoth is also available for OS X from [http://brew.sh/ Homebrew] and [http://www.macports.org/ Macports]. Macports carries only the stable version. Homebrew carries stable release, development release, and can also build the "bleeding edge" master branch.
__NOTOC__
== Stable (1.12 branch) ==
The stable files are meant to be used as a stable and rather balanced version of the game. Each version of the 1.12 branch is compatible to each other.

==== Source code ====
* [[CompilingWesnoth|Compiling Guide]] - How to compile the source code
{{StableDownload}}

==== GNU/Linux ====
* There are binaries for many different GNU/Linux distributions. Not all are always up to date with the current release. Please have a look at the [[WesnothBinariesLinux|Linux binary page]] for more information about the binaries for your distribution.

==== Miscellaneous ====
* [http://www.wesnoth.org/wiki/Download_Xdeltas#Stable_Version_1.12.x Xdelta for the source code]
* [http://sourceforge.net/projects/wesnoth/files/ SourceForge page for current and all previous versions]


== License ==
''Main article: [[Wesnoth:Copyrights]]''

This program is free software; you can redistribute it and/or modify it under the terms of the [http://www.fsf.org/copyleft/gpl.html GNU General Public License version 2], as published by the [http://www.fsf.org Free Software Foundation].

This program is distributed in the hope that it will be useful, but without any warranty; without even the implied warranty of merchantability or fitness for a particular purpose. See the GNU General Public License for more details.

== UMC Editor ==

This is available with Wesnoth 1.9.x and greater (including Wesnoth 1.12.x). Details and installation steps can be found at: http://eclipse.wesnoth.org

== See also ==
* [http://changelog.wesnoth.org Changelog]
* [[WesnothRepository]] - bleeding edge version from the repository

[[Category:Building and Installing]]

Download

2015-02-19T08:21:30Z

Aquileia: Remove last reference to minor version (in a comment)

Welcome to the ''Battle for Wesnoth'' downloads page. The BfW project team officially releases the source code and builds for Windows, OS X, OpenPandora, and various Linux distributions. Torrents are unofficial.

If the latest binaries are not currently available for your OS, please check back in a few days to see if they have been placed here. Packagers have been informed of the release, please be patient. In the meantime, read the [[FAQ#A_new_version_is_out.2C_but_where_is_the_download_for_.5BWindows.2C_Mac_OS_X.2C_etc..5D.3F|FAQ]].

Wesnoth is also available for OS X from [http://brew.sh/ Homebrew] and [http://www.macports.org/ Macports]. Macports carries only the stable version. Homebrew carries stable release, development release, and can also build the "bleeding edge" master branch.
__NOTOC__
== Stable (1.12 branch) ==
The stable files are meant to be used as a stable and rather balanced version of the game. Each version of the 1.12 branch is compatible to each other.

==== Source code ====
* [[CompilingWesnoth|Compiling Guide]] - How to compile the source code
{{StableDownload}}

==== GNU/Linux ====
* There are binaries for many different GNU/Linux distributions. Not all are always up to date with the current release. Please have a look at the [[WesnothBinariesLinux|Linux binary page]] for more information about the binaries for your distribution.

==== Miscellaneous ====
* [http://www.wesnoth.org/wiki/Download_Xdeltas#Stable_Version_1.12.x Xdelta for the source code]
* [http://sourceforge.net/projects/wesnoth/files/ SourceForge page for current and all previous versions]


== License ==
''Main article: [[Wesnoth:Copyrights]]''

This program is free software; you can redistribute it and/or modify it under the terms of the [http://www.fsf.org/copyleft/gpl.html GNU General Public License version 2], as published by the [http://www.fsf.org Free Software Foundation].

This program is distributed in the hope that it will be useful, but without any warranty; without even the implied warranty of merchantability or fitness for a particular purpose. See the GNU General Public License for more details.

== UMC Editor ==

This is available with Wesnoth 1.9.x and greater (including Wesnoth 1.12.x). Details and installation steps can be found at: http://eclipse.wesnoth.org

== See also ==
* [http://changelog.wesnoth.org Changelog]
* [[WesnothRepository]] - bleeding edge version from the repository

[[Category:Building and Installing]]

Download/zh-Hans

2015-02-19T08:18:15Z

Aquileia: /* 稳定版（1.12 分支） */ Re-add StableDownload template arguments

{{Download/Translations}}
欢迎来到韦诺之战下载页。韦诺之战项目团队官方发布源代码及适用于Windows、OS X、OpenPandora和多种Linux发行版的二进制构建版本。BT种子是非官方的。

如果适用于您的操作系统的最新的二进制可执行文件尚未提供，请过几天再来此处查看是否已提供。打包者们已被告知本次发布的相关情况，请保持耐心。在此期间，请阅读[[FAQ#A_new_version_is_out.2C_but_where_is_the_download_for_.5BWindows.2C_Mac_OS.2C_etc..5D.3F|常见问题]]。

韦诺之战也在[http://brew.sh/ Homebrew]以及[http://www.macports.org/ Macports]上提供。Macports上只有稳定版本。Homebrew 上有稳定发布版，开发发布版，同时也会构建最“前沿”的主开发分支。
__NOTOC__
== 稳定版（1.12 分支） ==
稳定版是希望作为稳定且平衡的游戏版本来使用。1.12分支的每一个版本都相互兼容。

版本1.12.1是最新的稳定版。这个版本推荐给绝大多数玩家，因为1.12在线多人游戏社区很庞大，而且用户自制战役服务器上也有很好的内容可供选择。

==== 源代码 ====
* [[CompilingWesnoth|编译指导]] - 如何编译源代码
{{StableDownload|当前版本|先前版本|当前源代码包的md5sum值|微软视窗操作系统|麦金塔操作系统}}

==== GNU/Linux ====
* 有许多二进制文件对应于不同的Linux发行版。不是所有的文件都已及时更新到最新版。请查阅[[WesnothBinariesLinux|Linux二进制文件页]]寻找对应于你的发行版的二进制包信息。

==== 杂项 ====
* [http://www.wesnoth.org/wiki/Download_Xdeltas#Stable_Version_1.12.x 源代码的Xdelta]
* [http://sourceforge.net/projects/wesnoth/files/ 当前和所有先前版本的SourceForge页]


== 许可 ==
'''主要文章：[[Wesnoth:Copyrights|版权声明]]

本程序为自由软件；您可依据[http://www.fsf.org Free Software Foundation|自由软件基金会]所发表的[http://www.fsf.org/copyleft/gpl.html GNU General Public License version 2|GNU通用公共许可证第2版]条款规定，就本程序再为发布与／或修改。
本程序是基于使用目的而加以发布，然而不负任何担保责任；亦无对适售性或特定目的适用性所为的默示性担保。详情请参照GNU通用公共授权。

== UMC 编辑器 ==
这提供给韦诺之战1.9.x和更高版本（包括韦诺之战1.12.x）。
细节和安装步骤可以在http://eclipse.wesnoth.org找到。

== 参见 ==
* [http://changelog.wesnoth.org 更新日志]
* [[WesnothRepository]] - 版本库中最前沿的版本

[[Category:Building and Installing]]

Download/ru

2015-02-18T11:57:15Z

Aquileia: Comment out 1.11, update version numbers

{{Download/Translations}}
Добро пожаловать на страницу загрузки «Битвы за Веснот». Команда проекта BFW официально поставляет только исходный код, бинарные пакеты же предоставлены добровольцами сообщества и размещаются на этой странице. Торренты тоже официально не поддерживаются.

Если сборки последней версии игры для вашей ОС еще не доступны, то, возможно, они появятся на этой странице спустя какое-то время. Попробуйте проверить через несколько дней. Люди, занимающиеся сборкой, знают о релизе, поэтому, пожалуйста, запаситесь терпением. А тем временем можете прочесть [[FAQ#A_new_version_is_out.2C_but_where_is_the_download_for_.5BWindows.2C_Mac_OS.2C_etc..5D.3F|FAQ]].

__NOTOC__

== Стабильные версии (ветка 1.12) ==
Стабильные файлы предлагается использовать в том случае, если нужна стабильная и одновременно сбалансированная версия игры. Все версии ветки 1.12 совместимы друг с другом.

Версия 1.12.1 на данный момент является последней стабильной версией. Эта версия рекомендуется для большинства игроков, поскольку в многопользовательской игре сообщество 1.12 очень большое и созданный пользователями сервер кампаний предлагает богатый выбор контента.

==== Исходный код ====
* [[CompilingWesnoth|Гайд по компилированию]] - как откомпилировать исходный код
{{StableDownload|Текущая версия|Предыдущая версия|md5sum для исходников текущей версии}}

==== GNU/Linux ====
* Существуют пакеты для множества различных дистрибутивов GNU/Linux. Не все из них обновляются с выходом нового релиза игры. Пожалуйста, ознакомьтесь с [[WesnothBinariesLinux|Страница сборок для Linux]] для того, чтобы узнать больше информации о сборках для вашего дистрибутива.

==== Дополнительно ====
* [http://www.wesnoth.org/wiki/Download_Xdeltas#Stable_Version_1.12.x Xdelta для исходного кода]
* [http://sourceforge.net/projects/wesnoth/files/ Страница на SourceForge для текущей и всех предыдущих версий]

== Лицензия ==
''Main article: [[Wesnoth:Copyrights]]

This program is free software; you can redistribute it and/or modify it under the terms of the [http://www.fsf.org/copyleft/gpl.html GNU General Public License version 2], as published by the [http://www.fsf.org Free Software Foundation].
This program is distributed in the hope that it will be useful, but without any warranty; without even the implied warranty of merchantability or fitness for a particular purpose. See the GNU General Public License for more details.

== UMC Editor ==
Доступно для версий Wesnoth 1.9.x и выше (включая Wesnoth 1.12.x).
Подробности и шаги по установке вы можете найти на:
http://eclipse.wesnoth.org

== Смотрите также ==
* [http://changelog.wesnoth.org Список изменений]
* [[WesnothRepository]] - новейшая версия из репозитория

[[Category:Building and Installing]]

Download/zh-Hans

2015-02-18T11:52:10Z

Aquileia: Comment out 1.11, update version numbers

{{Download/Translations}}
欢迎来到韦诺之战下载页。韦诺之战项目团队只发布官方源代码。二进制包由社区志愿者提供并在此存档。BT种子也是非官方的。

如果对应你操作系统的最新二进制可执行文件没有提供，请过几天再来查看是否发布。打包者已经被通知了这个发布，请保持耐心。在此期间，请阅读[[FAQ#A_new_version_is_out.2C_but_where_is_the_download_for_.5BWindows.2C_Mac_OS.2C_etc..5D.3F|常见问题]]。

__NOTOC__

== 稳定版（1.12 分支） ==
稳定版文件意味着被用来作为一个稳定且平衡的游戏版本。1.12分支的每一个版本相互兼容。

版本1.12.1是最新的稳定版。这个版本推荐给绝大多数玩家，因为1.12在线多人游戏社区很庞大，而且用户自制战役服务器也有很好的内容选择。

==== Source code 源代码 ====
* [[CompilingWesnoth|编译指导]] - 如何编译源代码
{{StableDownload|当前版本|先前版本|当前源代码包的md5sum值|微软视窗操作系统|麦金塔操作系统}}

==== GNU/Linux ====
* 有许多二进制文件对应于不同的Linux发行版。不是所有的都已及时更新到最新版。请查阅[[WesnothBinariesLinux|Linux二进制包页]]寻找对应于你的发行版的二进制包信息。

==== 杂项 ====
* [http://www.wesnoth.org/wiki/Download_Xdeltas#Stable_Version_1.12.x 源代码的Xdelta]
* [http://sourceforge.net/projects/wesnoth/files/ 当前和所有先前版本的SourceForge页]

== 许可 ==
'''主要文章：[[Wesnoth:Copyrights|版权声明]]

本程序为自由软件；您可依据[http://www.fsf.org Free Software Foundation|自由软件基金会]所发表的[http://www.fsf.org/copyleft/gpl.html GNU General Public License version 2|GNU通用公共许可证第2版]条款规定，就本程序再为发布与／或修改。
本程序是基于使用目的而加以发布，然而不负任何担保责任；亦无对适售性或特定目的适用性所为的默示性担保。详情请参照GNU通用公共授权。

== UMC 编辑器 ==
这提供给韦诺之战1.9.x和更高版本（包括韦诺之战1.12.x）。
细节和安装步骤可以在http://eclipse.wesnoth.org 找到。

== 参见 ==
* [http://changelog.wesnoth.org 更新日志]
* [[WesnothRepository]] - SVN中最前沿的版本

[[Category:Building and Installing]]

Download/de

2015-02-18T11:50:07Z

Aquileia: Entferne Verweise auf Abschnitte

{{Download/Translations}}
Willkommen auf der Battle for Wesnoth-Downloadseite. Das BfW-Team veröffentlicht offiziell nur den Quelltext. Binärpakete werden nur von Freiwilligen aus der Gemeinschaft zur Verfügung gestellt und hier angeboten.

Wenn die neuesten Binärpakete für dein Betriebssystem momentan noch nicht verfügbar sind, überprüfe einfach alle paar Tage ob du sie hier finden kannst. Die jeweilig Verantwortlichen wurden informiert, bitte habe etwas Geduld. In der Zwischenzeit kannst du die [[/FAQ/de#Eine_neue_Version_wurde_ver.C3.B6ffentlicht.2C_aber_wo_kann_man_die_.5BWindows.2C_Mac_OS_X.2C_usw..5D-Version_herunterladen.3F|FAQ-Seite]] lesen.
__NOTOC__

== Hauptversion (1.12-Zweig) ==
Die Hauptversion ist eine stabile und ziemlich ausgewogene Version des Spiels. Alle Versionen des 1.12-Zweigs sind miteinander kompatibel.

==== Quelltext ====
* [[CompilingWesnoth|Kompilierungsanleitung]] - wie man den Quelltext kompiliert
{{StableDownload|Neueste Version|Vorherige Version|md5sum für den aktuellen Quelltext}}

==== GNU/Linux ====
* Es gibt Binärpakete für viele verschiedene GNU/Linux-Distributionen. Nicht alle sind immer auf dem Stand der neuesten Version. Für mehr Informationen über die Binärpakete für deine Distribution lies bitte die [[WesnothBinariesLinux|entsprechende Seite]].

==== Verschiedenes ====
* [http://www.wesnoth.org/wiki/Download_Xdeltas#Stable_Version_1.12.x Xdelta für den Quelltext]
* [http://sourceforge.net/projects/wesnoth/files/ SourceForge-Seite für die aktuellen und alle vorherigen Versionen]


== Lizenz ==
''Hauptartikel: [[Wesnoth:Copyrights]]

Dieses Programm ist freie Software; du kannst es weitervertreiben und/oder modifizieren, solange das unter den Bedingungen der [http://www.fsf.org/copyleft/gpl.html GNU General Public License version 2] bleibt, veröffentlicht von der [http://www.fsf.org Free Software Foundation].
Dieses Programm wird mit der Hoffnung vertrieben, dass es nützlich ist, allerdings ohne Garantie; ohne die auch nur angedeutete Garantie auf Marktgängigkeit oder Eignung für eine bestimmte Absicht. Siehe die GNU Allgemeine Öffentliche Lizenz für mehr Informationen.

== Erweiterungseditor ==
Dieser ist für 1.9.x (und höher, einschließlich 1.12.x) verfügbar.
Details und Installationsanweisungen snd auf http://eclipse.wesnoth.org zu finden.

== Siehe auch ==
* [http://changelog.wesnoth.org Versionshistorie]
* [[WesnothRepository]] - bleeding-edge-Version von Quelle

[[Category:Building and Installing]]

Download/de

2015-02-18T11:21:56Z

Aquileia: kommentiere die Entwicklungsversion bis 1.13 aus

{{Download/Translations}}
Willkommen auf der Battle for Wesnoth-Downloadseite. Das BfW-Team veröffentlicht offiziell nur den Quelltext. Binärpakete werden nur von Freiwilligen aus der Gemeinschaft zur Verfügung gestellt und hier angeboten.

Wenn die neuesten Binärpakete für dein Betriebssystem momentan noch nicht verfügbar sind, überprüfe einfach alle paar Tage ob du sie hier finden kannst. Die jeweilig Verantwortlichen wurden informiert, bitte habe etwas Geduld. In der Zwischenzeit kannst du die [[/FAQ/de#Eine_neue_Version_wurde_ver.C3.B6ffentlicht.2C_aber_wo_kann_man_die_.5BWindows.2C_Mac_OS_X.2C_usw..5D-Version_herunterladen.3F|FAQ-Seite]] lesen.
__NOTOC__
Springen zu: [[Download/de#Hauptversion (1.12-Zweig)|Hauptversion]] | [[Download/de#Ältere Hauptversionen|Ältere Hauptversionen]] | [[Download/de#Entwicklungsversion (1.11-Zweig)|Entwicklungsversion]]

== Hauptversion (1.12-Zweig) ==
Die Hauptversion ist eine stabile und ziemlich ausgewogene Version des Spiels. Alle Versionen des 1.12-Zweigs sind miteinander kompatibel.

==== Quelltext ====
* [[CompilingWesnoth|Kompilierungsanleitung]] - wie man den Quelltext kompiliert
{{StableDownload|Neueste Version|Vorherige Version|md5sum für den aktuellen Quelltext}}

==== GNU/Linux ====
* Es gibt Binärpakete für viele verschiedene GNU/Linux-Distributionen. Nicht alle sind immer auf dem Stand der neuesten Version. Für mehr Informationen über die Binärpakete für deine Distribution lies bitte die [[WesnothBinariesLinux|entsprechende Seite]].

==== Verschiedenes ====
* [http://www.wesnoth.org/wiki/Download_Xdeltas#Stable_Version_1.12.x Xdelta für den Quelltext]
* [http://sourceforge.net/projects/wesnoth/files/ SourceForge-Seite für die aktuellen und alle vorherigen Versionen]


== Lizenz ==
''Hauptartikel: [[Wesnoth:Copyrights]]

Dieses Programm ist freie Software; du kannst es weitervertreiben und/oder modifizieren, solange das unter den Bedingungen der [http://www.fsf.org/copyleft/gpl.html GNU General Public License version 2] bleibt, veröffentlicht von der [http://www.fsf.org Free Software Foundation].
Dieses Programm wird mit der Hoffnung vertrieben, dass es nützlich ist, allerdings ohne Garantie; ohne die auch nur angedeutete Garantie auf Marktgängigkeit oder Eignung für eine bestimmte Absicht. Siehe die GNU Allgemeine Öffentliche Lizenz für mehr Informationen.

== Erweiterungseditor ==
Dieser ist für 1.9.x (und höher, einschließlich 1.12.x) verfügbar.
Details und Installationsanweisungen snd auf http://eclipse.wesnoth.org zu finden.

== Siehe auch ==
* [http://changelog.wesnoth.org Versionshistorie]
* [[WesnothRepository]] - bleeding-edge-Version von Quelle

[[Category:Building and Installing]]

Download

2015-02-18T11:12:31Z

Aquileia: prepare 1.11 --> 1.13, still commented out

Welcome to the ''Battle for Wesnoth'' downloads page. The BfW project team officially releases the source code and builds for Windows, OS X, OpenPandora, and various Linux distributions. Torrents are unofficial.

If the latest binaries are not currently available for your OS, please check back in a few days to see if they have been placed here. Packagers have been informed of the release, please be patient. In the meantime, read the [[FAQ#A_new_version_is_out.2C_but_where_is_the_download_for_.5BWindows.2C_Mac_OS_X.2C_etc..5D.3F|FAQ]].

Wesnoth is also available for OS X from [http://brew.sh/ Homebrew] and [http://www.macports.org/ Macports]. Macports carries only the stable version. Homebrew carries stable release, development release, and can also build the "bleeding edge" master branch.
__NOTOC__
== Stable (1.12 branch) ==
The stable files are meant to be used as a stable and rather balanced version of the game. Each version of the 1.12 branch is compatible to each other.

==== Source code ====
* [[CompilingWesnoth|Compiling Guide]] - How to compile the source code
{{StableDownload}}

==== GNU/Linux ====
* There are binaries for many different GNU/Linux distributions. Not all are always up to date with the current release. Please have a look at the [[WesnothBinariesLinux|Linux binary page]] for more information about the binaries for your distribution.

==== Miscellaneous ====
* [http://www.wesnoth.org/wiki/Download_Xdeltas#Stable_Version_1.12.x Xdelta for the source code]
* [http://sourceforge.net/projects/wesnoth/files/ SourceForge page for current and all previous versions]


== License ==
''Main article: [[Wesnoth:Copyrights]]''

This program is free software; you can redistribute it and/or modify it under the terms of the [http://www.fsf.org/copyleft/gpl.html GNU General Public License version 2], as published by the [http://www.fsf.org Free Software Foundation].

This program is distributed in the hope that it will be useful, but without any warranty; without even the implied warranty of merchantability or fitness for a particular purpose. See the GNU General Public License for more details.

== UMC Editor ==

This is available with Wesnoth 1.9.x and greater (including Wesnoth 1.12.x). Details and installation steps can be found at: http://eclipse.wesnoth.org

== See also ==
* [http://changelog.wesnoth.org Changelog]
* [[WesnothRepository]] - bleeding edge version from the repository

[[Category:Building and Installing]]

AbilitiesWML

2015-02-17T20:10:16Z

Aquileia: /* Extra keys and tags used by the [resistance] 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, but by convention only one weapon special should be assigned to any given attack.

== 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
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.

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

* '''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.
* '''affect_self''': if equal to 'yes', the ability will affect the unit that has it.
* '''affect_allies''': if equal to 'yes', the ability will affect allies in the specified adjacent hexes.
* '''affect_enemies''': if equal to 'yes', 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.
* '''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. 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'''.
** '''[filter]''': a [[StandardUnitFilter]].
* '''[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_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''.

=== 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).

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

* '''value''': the percentage bonus to damage.

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

* '''value''': the percentage bonus to lawful units.
* '''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 tunnel tag (see [[DirectActionsWML]]) (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.

=== Macros for common abilities ===

* ABILITY_AMBUSH
* ABILITY_CURES
* ABILITY_HEALS
* ABILITY_ILLUMINATES
* ABILITY_LEADERSHIP_LEVEL_1 to ABILITY_LEADERSHIP_LEVEL_5
* 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 ===

* '''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.
* '''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]''': [[StandardUnitFilter]], which takes an extra key '''adjacent''', which is used to specify which adjacent hexes to filter on. '''adjacent''' is a comma-separated list of any combination of these directions: '''n''','''ne''','''se''','''s''','''sw''','''nw'''. If there is not a matching unit in each of the specified directions, then the special is inactive. Multiple [filter_adjacent] tags can be provided, and each must pass for the special to be active.
* '''[filter_adjacent_location]''': like [filter_adjacent], except that it filters on the locations rather than the units.
* '''[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=.
* '''[filter_opponent]''': the special will only be active if the opponent matches this SUF.
** '''[filter_weapon]''': a standard weapon filter, including special=..
* '''[filter_attacker]''': the special will only be active if the attacker matches this SUF.
** '''[filter_weapon]''': a standard weapon filter, including special=..
* '''[filter_defender]''' the special will only be active if the defender matches this SUF.
** '''[filter_weapon]''': a standard weapon filter, including special=..

=== 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).
* '''[filter_base_value]''': filters on the value before any modifications; uses the keys '''equals''', '''not_equals''', etc.

=== 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

2015-02-17T17:00:31Z

Aquileia: Undo revision 56116 by me

{{WML Tags}}

__TOC__

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. 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.
* '''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.
* '''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.
* '''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.
* '''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.
* '''ellipse''': the ellipse image to display under the unit, which is normally team-colored. Default is the normal ellipse; "misc/ellipse-nozoc" is a dashed ellipse that should be used for units without zone of control. {{DevFeature1.11}} 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.
* '''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.
* '''hide_help''': determines if the unit type will appear in the in-game help. Possible values ''true'' and ''false'', defaults to ''false''.
* '''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. [[ImagePathFunctionWML#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]]).
* '''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.
* '''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. 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: ** ''scout'': Fast, mobile unit meant for exploration and village grabbing. ** ''fighter'': Melee fighter, melee attack substantially more powerful than ranged. ** ''archer'': Ranged fighter, ranged attack substantially more powerful than melee. ** ''mixed fighter'': Melee and ranged fighter, melee and ranged attacks roughly equal. ** ''healer'': Specialty 'heals' or 'cures'. 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.{{DevFeature1.11}}
* '''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''': {{DevFeature1.11}} sets the sound used when the unit is healed in any way (default: heal.wav).

== 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 (see [[DescriptionWML]]) 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.
** '''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.
** '''[effect]''': A modification applied to the unit whenever this advancement is chosen. See [[EffectWML]]

== 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 (if ''name=x'' then ''icon=attacks/x.png'' is assumed unless present). 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}}).
** '''[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.
** '''range''': the range of the attack. Used to determine the enemy's retaliation, which will be of the same type. Also displayed on the status table in parentheses; 'melee'(default) displays "melee", while 'ranged' displays "ranged". Range can be anything. Standard values are now "melee" and "ranged". From now on, ''short'' and ''long'' will be treated as totally different ranges. You can create any number of ranges now (with any name), and units can only retaliate against attacks for which they have a corresponding attack of the same range. This value is translatable.
** '''damage''': the damage of this attack
** '''number''': the number of strikes per attack this weapon has
** '''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; highly weighted attacks are more likely to be used. Setting it to 0 disables the attack on attack
** '''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
For the weight settings, the engine usually chooses the attack with the best average total damages * weight (default weight = 1.0).

== 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. Attributes in this unit overwrite the copy. Tags modify the corresponding tag of the original, so for example the first '''[attack]''' tag in the derived unit would modify the first attack of the base unit rather than defining a new attack.

* '''[portrait]''': Describes a unit portrait for dialogue. However, generally you should use the profile key instead; [portrait] is mostly for internal use.
** '''size''': The size of the portrait, in pixels.
** '''side''': One of left or right.
** '''mirror''': Whether to flip the image horizontally.
** '''image''': The image path.

* '''[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.
** {{DevFeature1.11}} '''variation_id''': The id of this variation. Defaults to ''variation_name''.
** '''variation_name''': The name of the variation. Since {{DevFeature1.11}} is this attribute translatable.
** '''inherit''': if ''yes'', inherits all the properties of the base unit, which are then overwritten by the keys and tags of this variation. Defaults to no.
*** {{DevFeature1.11}} 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]''. A special case is the '''id''' key, for which support is incomplete. If '''id''' is set for a variation, then it applies when filtering existing units (including the breakdown of units in the "damage versus" tooltip), but it cannot be used to create a new unit. For reliable behavior, '''id''' should match the parent type's id. {{DevFeature1.11}} Changing the id for a variation is fully supported starting in 1.11.2.

* '''[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. Defaults to yes.
*** {{DevFeature1.11}} 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]''. A special case is the '''id''' key, for which support is incomplete. If '''id''' is set for a variation, then it applies when filtering existing units (including the breakdown of units in the "damage versus" tooltip), but it cannot be used to create a new unit. For reliable behavior, '''id''' should match the parent type's id. {{DevFeature1.11}} Changing the id for a variation is fully supported starting in 1.11.2.

== See Also ==

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

[[Category: WML Reference]]

UnitTypeWML

2015-02-17T16:25:37Z

Aquileia: /* Other tags */ Clarify [portrait] tag

{{WML Tags}}

__TOC__

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. 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.
* '''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.
* '''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.
* '''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.
* '''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.
* '''ellipse''': the ellipse image to display under the unit, which is normally team-colored. Default is the normal ellipse; "misc/ellipse-nozoc" is a dashed ellipse that should be used for units without zone of control. {{DevFeature1.11}} 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.
* '''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.
* '''hide_help''': determines if the unit type will appear in the in-game help. Possible values ''true'' and ''false'', defaults to ''false''.
* '''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. [[ImagePathFunctionWML#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]]).
* '''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.
* '''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. 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: ** ''scout'': Fast, mobile unit meant for exploration and village grabbing. ** ''fighter'': Melee fighter, melee attack substantially more powerful than ranged. ** ''archer'': Ranged fighter, ranged attack substantially more powerful than melee. ** ''mixed fighter'': Melee and ranged fighter, melee and ranged attacks roughly equal. ** ''healer'': Specialty 'heals' or 'cures'. 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.{{DevFeature1.11}}
* '''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''': {{DevFeature1.11}} sets the sound used when the unit is healed in any way (default: heal.wav).

== 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 (see [[DescriptionWML]]) 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.
** '''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.
** '''[effect]''': A modification applied to the unit whenever this advancement is chosen. See [[EffectWML]]

== 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 (if ''name=x'' then ''icon=attacks/x.png'' is assumed unless present). 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}}).
** '''[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.
** '''range''': the range of the attack. Used to determine the enemy's retaliation, which will be of the same type. Also displayed on the status table in parentheses; 'melee'(default) displays "melee", while 'ranged' displays "ranged". Range can be anything. Standard values are now "melee" and "ranged". From now on, ''short'' and ''long'' will be treated as totally different ranges. You can create any number of ranges now (with any name), and units can only retaliate against attacks for which they have a corresponding attack of the same range. This value is translatable.
** '''damage''': the damage of this attack
** '''number''': the number of strikes per attack this weapon has
** '''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; highly weighted attacks are more likely to be used. Setting it to 0 disables the attack on attack
** '''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
For the weight settings, the engine usually chooses the attack with the best average total damages * weight (default weight = 1.0).

== 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. Attributes in this unit overwrite the copy. Tags modify the corresponding tag of the original, so for example the first '''[attack]''' tag in the derived unit would modify the first attack of the base unit rather than defining a new attack.

* '''[portrait]''': Describes a unit portrait for dialogue. However, generally you should use the profile key instead; [portrait] is mostly used if the profile image has no transparent background.
** '''size''': The size of the portrait, in pixels.
** '''side''': One of left or right.
** '''mirror''': Whether to flip the image horizontally.
** '''image''': The image path.

* '''[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.
** {{DevFeature1.11}} '''variation_id''': The id of this variation. Defaults to ''variation_name''.
** '''variation_name''': The name of the variation. Since {{DevFeature1.11}} is this attribute translatable.
** '''inherit''': if ''yes'', inherits all the properties of the base unit, which are then overwritten by the keys and tags of this variation. Defaults to no.
*** {{DevFeature1.11}} 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]''. A special case is the '''id''' key, for which support is incomplete. If '''id''' is set for a variation, then it applies when filtering existing units (including the breakdown of units in the "damage versus" tooltip), but it cannot be used to create a new unit. For reliable behavior, '''id''' should match the parent type's id. {{DevFeature1.11}} Changing the id for a variation is fully supported starting in 1.11.2.

* '''[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. Defaults to yes.
*** {{DevFeature1.11}} 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]''. A special case is the '''id''' key, for which support is incomplete. If '''id''' is set for a variation, then it applies when filtering existing units (including the breakdown of units in the "damage versus" tooltip), but it cannot be used to create a new unit. For reliable behavior, '''id''' should match the parent type's id. {{DevFeature1.11}} Changing the id for a variation is fully supported starting in 1.11.2.

== See Also ==

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

[[Category: WML Reference]]

Download

2015-02-17T14:14:18Z

Aquileia: /* Stable (1.12 branch) */ Fix version number in comment

Welcome to the ''Battle for Wesnoth'' downloads page. The BfW project team officially releases the source code and builds for Windows, OS X, OpenPandora, and various Linux distributions. Torrents are unofficial.

If the latest binaries are not currently available for your OS, please check back in a few days to see if they have been placed here. Packagers have been informed of the release, please be patient. In the meantime, read the [[FAQ#A_new_version_is_out.2C_but_where_is_the_download_for_.5BWindows.2C_Mac_OS_X.2C_etc..5D.3F|FAQ]].

Wesnoth is also available for OS X from [http://brew.sh/ Homebrew] and [http://www.macports.org/ Macports]. Macports carries only the stable version. Homebrew carries stable release, development release, and can also build the "bleeding edge" master branch.
__NOTOC__
== Stable (1.12 branch) ==
The stable files are meant to be used as a stable and rather balanced version of the game. Each version of the 1.12 branch is compatible to each other.

==== Source code ====
* [[CompilingWesnoth|Compiling Guide]] - How to compile the source code
{{StableDownload}}

==== GNU/Linux ====
* There are binaries for many different GNU/Linux distributions. Not all are always up to date with the current release. Please have a look at the [[WesnothBinariesLinux|Linux binary page]] for more information about the binaries for your distribution.

==== Miscellaneous ====
* [http://www.wesnoth.org/wiki/Download_Xdeltas#Stable_Version_1.12.x Xdelta for the source code]
* [http://sourceforge.net/projects/wesnoth/files/ SourceForge page for current and all previous versions]


== License ==
''Main article: [[Wesnoth:Copyrights]]''

This program is free software; you can redistribute it and/or modify it under the terms of the [http://www.fsf.org/copyleft/gpl.html GNU General Public License version 2], as published by the [http://www.fsf.org Free Software Foundation].

This program is distributed in the hope that it will be useful, but without any warranty; without even the implied warranty of merchantability or fitness for a particular purpose. See the GNU General Public License for more details.

== UMC Editor ==

This is available with Wesnoth 1.9.x and greater (including Wesnoth 1.12.x). Details and installation steps can be found at: http://eclipse.wesnoth.org

== See also ==
* [http://changelog.wesnoth.org Changelog]
* [[WesnothRepository]] - bleeding edge version from the repository

[[Category:Building and Installing]]

MapLocalization

2015-01-25T06:41:07Z

Aquileia: New duplicate maps, now organized as a table

'''This page is a work in progress'''

Like the old maps, the new-style maps can be localized, but the intended method for doing so is quite different.

=== Overview ===

However, the workflow for localizing a map is simple: you create an image which contains the localized labels on a transparent background as simple text, no post-processing effects needed. In GIMP, you then add that image to a corresponding .xcf file as a new layer, and run a script. The script creates an overlay image which covers up the english labels, adds your localized labels and applies a bunch of post-processing effects to them in order to make them look identical to the english labels. All you need to do is to check the output and save.

=== Step-by-step instructions ===

==== Preparations ====

1. If you don't have GIMP, install it.

2. Download the [https://github.com/wesnoth/resources/tree/master/image-localization/maps/wesnoth-map-localization.scm wesnoth-map-localization.scm script] and place it into a script directory recognized by GIMP. You can view and configure the script directories in GIMP's preferences (Preferences -> Folders -> Scripts). If you already have GIMP running, you need to use '''Filters -> Script-Fu -> Refresh Scripts''' to make it recognize the newly added script. In the Filters menu, you should now see a filter category called "Wesnoth", and inside it "Map Localization". However, we don't need it yet.

3. Download the [https://github.com/wesnoth/resources/tree/master/image-localization/maps/ localization.xcf for the map you're localizing].

Now you're all set to begin.

==== Localization ====

# Open the localization.xcf you've downloaded. It contains a bunch of layers needed by the localization script, but at this point all you need is the layer called "label placement guide". It's a version of the map without any perspective or displacement effects added, and it is the one onto which you need to place the localized layers.
# Create a new layer which includes the localized labels, positioning them using the aforementioned layer as a guide. The positions or orientation or curving of the labels does not need to match the english labels in any way. Place them in a way which you think looks good. The requirements for the labels are simple: black text should be pure black, whereas yellow labels on forests should have the RGB value 185,155,85. The script gives you a little bit of leeway so you don't have to stress over very small color deviations, but don't do it intentionally. Background should be transparent. ''Note that you can use whatever graphics application you want in creating your labels, as long as you can import the result into GIMP so that it meets the above requirements.'' 
# Add the layer containing your localized text into the same localization.xcf file and name it "labels". Don't mess with the other layers.
# If ''labels'' and ''label placement guide'' are layer groups, merge them down to single layers. Notice as well that the expected layer names are case-sensitive, so for example ''Labels'' will not work.
# Run the script by choosing Filters -> Wesnoth -> Map Localization. The script will create a new image, and produce the output there. This will take a moment, perhaps as much as a minute or more on a slow computer, and for a few seconds it might seem like nothing is happening.
# You should now have a new image with a single layer called "localized overlay". Inspect that everything's ok by adding the original english map as a new layer underneath the overlay; the english labels should be covered up, the localized labels in place and there should be no glitches anywhere. Export the image to PNG (just remember to hide/delete the english map layer first!) and you're done. In the PNG export dialog, uncheck the option "Save color values from transparent pixels" to get the file of expected size (~100-300 KiB; if the option is not unchecked, it is over 2 MiB).

===== Final notes =====

If there are labels which you don't need to localize, then first of all, don't bother including them among your localized labels. Then, once you've generated the final overlay, simply erase the parts which cover up the original english label.

===== Text sizing =====

These are the text sizing rules that have been used on the english maps. Depending on your language, you may want to break some of them.

Major geographical features or other large areas which extend beyond the map edges (including forests): 28px small caps, tracking ~200.
''Note that these are font sizes for Photoshop. GIMP has slightly different text tools and does not have small caps effect. Small caps effect can be reproduced by using caps with 30px for the first letter and 20px bold for the remaining letters. You might also need to make all text bold in Gimp so it will be legible. The corresponding font tracking in GIMP is 5.0.''

Large geographical features: 22px normal or small caps.

Minor geographical features: 18px normal.

Major rivers: 20px, tracking ~200.

Small rivers: 18px, tracking ~200. For names like "R. Weldyn", note that periods are very small in Monotype Corsiva and get very close to the preceding R; I suggest giving the . a size of 24-30px and removing the following space. Other solutions can work too.

Capital cities: 24px normal.

Other major cities: 20px normal.

Small cities: 16px normal. You might need to increase this to 18px for legibility.

Large forests: 24px normal.

Small forests: 18px normal.

===== Text orientation and curving =====

In the english maps, names of large geographical areas and rivers are often curved. River names usually follow the shape of the river, and names of large features such as "Heart Mountains" are curved to roughly match the shape of said feature.

All of the above is optional. You do not need to match the english labels in shape and location. If for some reason you need to, you can even omit some labels or add completely new ones.

==== Duplicate maps ====

The title screen map is identical with the ''Heir to the Throne'' campaign map. Localize the map for ''Heir to the Throne'', create a copy of the overlay and rename it to 'titlescreen--overlay.png', then place it in ''\data\core\images\maps\l10n\<language iso code>'' and you're done.

The same applies to several other maps:

{|
! Copy !! Source
|-
| ''titlescreen'' || ''Heir to the Throne''
|-
| ''A Tale of Two Brothers'' || ''Liberty''
|-
| ''Northern Rebirth'' || ''An Orcish Incursion''
|-
| ''The Hammer of Thursagan'' || ''The Sceptre of Fire''
|}

[[Category:Translations]]

MapLocalization

2015-01-19T12:48:58Z

Aquileia: Second map which appears twice added

'''This page is a work in progress'''

Like the old maps, the new-style maps can be localized, but the intended method for doing so is quite different.

=== Overview ===

However, the workflow for localizing a map is simple: you create an image which contains the localized labels on a transparent background as simple text, no post-processing effects needed. In GIMP, you then add that image to a corresponding .xcf file as a new layer, and run a script. The script creates an overlay image which covers up the english labels, adds your localized labels and applies a bunch of post-processing effects to them in order to make them look identical to the english labels. All you need to do is to check the output and save.

=== Step-by-step instructions ===

==== Preparations ====

1. If you don't have GIMP, install it.

2. Download the [https://github.com/wesnoth/resources/tree/master/image-localization/maps/wesnoth-map-localization.scm wesnoth-map-localization.scm script] and place it into a script directory recognized by GIMP. You can view and configure the script directories in GIMP's preferences (Preferences -> Folders -> Scripts). If you already have GIMP running, you need to use '''Filters -> Script-Fu -> Refresh Scripts''' to make it recognize the newly added script. In the Filters menu, you should now see a filter category called "Wesnoth", and inside it "Map Localization". However, we don't need it yet.

3. Download the [https://github.com/wesnoth/resources/tree/master/image-localization/maps/ localization.xcf for the map you're localizing].

Now you're all set to begin.

==== Localization ====

# Open the localization.xcf you've downloaded. It contains a bunch of layers needed by the localization script, but at this point all you need is the layer called "label placement guide". It's a version of the map without any perspective or displacement effects added, and it is the one onto which you need to place the localized layers.
# Create a new layer which includes the localized labels, positioning them using the aforementioned layer as a guide. The positions or orientation or curving of the labels does not need to match the english labels in any way. Place them in a way which you think looks good. The requirements for the labels are simple: black text should be pure black, whereas yellow labels on forests should have the RGB value 185,155,85. The script gives you a little bit of leeway so you don't have to stress over very small color deviations, but don't do it intentionally. Background should be transparent. ''Note that you can use whatever graphics application you want in creating your labels, as long as you can import the result into GIMP so that it meets the above requirements.'' 
# Add the layer containing your localized text into the same localization.xcf file and name it "labels". Don't mess with the other layers.
# If ''labels'' and ''label placement guide'' are layer groups, merge them down to single layers. Notice as well that the expected layer names are case-sensitive, so for example ''Labels'' will not work.
# Run the script by choosing Filters -> Wesnoth -> Map Localization. The script will create a new image, and produce the output there. This will take a moment, perhaps as much as a minute or more on a slow computer, and for a few seconds it might seem like nothing is happening.
# You should now have a new image with a single layer called "localized overlay". Inspect that everything's ok by adding the original english map as a new layer underneath the overlay; the english labels should be covered up, the localized labels in place and there should be no glitches anywhere. Export the image to PNG (just remember to hide/delete the english map layer first!) and you're done. In the PNG export dialog, uncheck the option "Save color values from transparent pixels" to get the file of expected size (~100-300 KiB; if the option is not unchecked, it is over 2 MiB).

===== Final notes =====

If there are labels which you don't need to localize, then first of all, don't bother including them among your localized labels. Then, once you've generated the final overlay, simply erase the parts which cover up the original english label.

===== Text sizing =====

These are the text sizing rules that have been used on the english maps. Depending on your language, you may want to break some of them.

Major geographical features or other large areas which extend beyond the map edges (including forests): 28px small caps, tracking ~200.
''Note that these are font sizes for Photoshop. GIMP has slightly different text tools and does not have small caps effect. Small caps effect can be reproduced by using caps with 30px for the first letter and 20px bold for the remaining letters. You might also need to make all text bold in Gimp so it will be legible. The corresponding font tracking in GIMP is 5.0.''

Large geographical features: 22px normal or small caps.

Minor geographical features: 18px normal.

Major rivers: 20px, tracking ~200.

Small rivers: 18px, tracking ~200. For names like "R. Weldyn", note that periods are very small in Monotype Corsiva and get very close to the preceding R; I suggest giving the . a size of 24-30px and removing the following space. Other solutions can work too.

Capital cities: 24px normal.

Other major cities: 20px normal.

Small cities: 16px normal. You might need to increase this to 18px for legibility.

Large forests: 24px normal.

Small forests: 18px normal.

===== Text orientation and curving =====

In the english maps, names of large geographical areas and rivers are often curved. River names usually follow the shape of the river, and names of large features such as "Heart Mountains" are curved to roughly match the shape of said feature.

All of the above is optional. You do not need to match the english labels in shape and location. If for some reason you need to, you can even omit some labels or add completely new ones.

==== Duplicate maps ====

The title screen map is identical with the ''Heir to the Throne'' campaign map. Localize the map for ''Heir to the Throne'', create a copy of the overlay and rename it to 'titlescreen--overlay.png', then place it in ''\data\core\images\maps\l10n\<language iso code>'' and you're done.

The same applies to the ''A Tale of Two Brothers'' map, which is identical to the ''Liberty'' map but for the name.

[[Category:Translations]]

GettextForTranslators

2014-06-29T20:41:27Z

Aquileia: Change repository links to point to github master

== Gettext for translators ==

Wesnoth translation is now divided into several text-domains:
* wesnoth
* wesnoth-editor
* wesnoth-lib (contains strings shared by game and editor)
* plus one text-domain for each campaign. The names of these text-domains are constructed from the word wesnoth and the common abbreviation of the campaign (wesnoth-ei, wesnoth-httt, wesnoth-trow, wesnoth-tb, wesnoth-tsg and wesnoth-utbs).

We will use the Swedish (sv) language and the ''wesnoth'' domain as an example in this page.
There are three important files for each text-domain:
* ''wesnoth/wesnoth.pot'' file, which contains all the strings used in the main game (neither editor, nor campaign strings). You can see how a ''.pot'' file looks like in the repository : [https://github.com/wesnoth/wesnoth/blob/master/po/wesnoth/wesnoth.pot Current repository version].
* ''wesnoth/sv.po'', the file containing the translation, you can see how a ''.po'' file looks like in the repository: [https://github.com/wesnoth/wesnoth/blob/master/po/wesnoth/sv.po Current repository version].
* ''{translations_dir}/sv/LC_MESSAGES/wesnoth.gmo'', which is a binary version of <lang>.po that the game will use for efficiency reasons. This is not found in cvs, but is created during compilation of the game.

The first of these files, we update every once in a while, when there is new or modified text,
for instance when a new campaign scenario hits the repository.

Then, ''msgmerge'' is used to merge this new "state of the game strings" with your current translations, and generate a new, up-to-date, ''sv.po''.

Then, a tool called ''msgfmt'' is called, which generates a new ''wesnoth.gmo'' file from your ''wesnoth.po'' file, which will be used by the game once installed.

"make -C po update-po" does these three steps in one pass.

That was for the "Big Picture".
But you really just need to be concerned with the po file:
translating new strings, checking "fuzzy" entries.
We can handle the administrative tasks of updating etc.
You really don't need to bother with any of these commands, unless you want to compile gmo files to check in-game.

Ivanovic is now responsible for integrating translations into Wesnoth, with the help of Torangan and ott.
You should contact Ivanovic (crazy-ivanovic AT gmx DOT net), and he'll put them in the game.

When sending po files to a maintainer to be included in the repository, please create a zip or tar.gz/bz2 archive that you attach, rather than cutting and pasting the translations into an email. The translated strings are
very sensitive to formatting and the archive will also help distinguish which file is which when sending more than one po file.

== FAQ ==
* '''What's a fuzzy string?'''
** It's a string calling for translator revision. For example, if an English string gets a small change and you run the ''msgmerge'' program, it will mark the translation of that string fuzzy. When we switched to gettext we marked all translations as fuzzy as lots of them were outdated.
* '''What are "Plural-forms"?'''
** Some languages have different word forms for different numbers of things (for example in English we have "1 thing" but "2 thing'''s'''"). The rules are different for different languages. You can find them [http://translate.sourceforge.net/wiki/l10n/pluralforms here].
* '''My language needs a different font to get displayed correctly.'''
** Wesnoth uses several different fonts, and the number is likely to grow with the support for new alphabets/writing systems. Right now we are using DejaVuSans (Roman and Cyrillic), FreeSans (Greek), sazanami-gothic (Japanese) and gkai00mp (Chinese). In the wesnoth/sv.po you will find a string containing the currently used fonts. By changing the order of fonts listed, you choose which font is preferred for your translations. A language using Greek letters would for instance translate that string with:
msgid "DejaVuSans.ttf,FreeSans.ttf,sazanami-gothic.ttf,gkai00mp.ttf"
msgstr "FreeSans.ttf,DejaVuSans.ttf,sazanami-gothic.ttf,gkai00mp.ttf"
Note that if a certain letter/glyph is not found in the first font listed, the second font will be scanned for it and so on.
* '''What should I do to insert a newline in a string?'''
** If you want to insert a newline in a string you need to include the pair of characters "". You can use normal newlines as you wish as they don't affect the translation.
* '''How do I use ' within a single-quote delimited string when translating text= in help screen texts?'''
** Add a backslash before it.
* '''What should I do with strings like "Prefs section^General"?'''
** There are ambiguous strings which should be translated in a different way depending on where they appear. For example, we have "General" in the preferences as "General preferences" and we can also have "a General". These strings can have different translations for a given language, so we use "context" to solve this. The prefix only tries to give a hint about the string, and should be not translated, for example:
msgid "Prefs section^General"
msgstr "General"
* '''Who can I ask for further information?'''
** You can ask Ivanovic, Torangan, ott, Yann or Isaac in IRC (irc.freenode.net, #wesnoth or #wesnoth-dev).
If you don't like IRC, send a mail to crazy-ivanovic AT gmx DOT net, or pm him (ivanovic) at the forum.
* '''How do I quickly test PO file changes?'''
** When you modify a PO file, run "make update-gmo" in the main po directory to create a new MO file, then run "make install" there to install the new MO file.
** Then force cache rebuild. This is tricky -- if you only update MO files, the game may use a cached (i.e., old) version letting you wonder why it still displays the old translation. Either change game.cfg modification time, e.g. with "touch /usr/local/share/wesnoth/game.cfg", or delete the corresponding cache[s] in ~/.wesnoth/cache.
* '''I don't know what ''make'' is and where to get it. Can I still quickly test PO file changes?'''
** Yes you can. Fist, you will need to get an editor for .po files like [http://www.poedit.net/ Poedit] or [http://translate.sourceforge.net/wiki/virtaal/index Virtaal].
** Create a temporary folder to put the .mo files in.
** Poedit automatically creates an .mo file when you save, in Virtaal choose File -> Export.
** Name your .mo files according to the text domain and put them into your temporary folder, e.g. for ''wesnoth-lib/<language_code>.po'' the .mo file will be called ''wesnoth-lib.mo''.
** Go to the folder your Wesnoth installation is in, e. g. ''C:\Users\<username>\AppData\Local\Battle for Wesnoth <version number>'' in Windows 7.
** Go to the ''translations'' folder and check if there is a subfolder for your language code. If there isn't, create one, then in the new subfolder create a folder called ''LC_MESSAGES''.
** Copy your .mo files to ''LC_MESSAGES'' and restart Wesnoth.
* '''The .po file in the repository has changed, how do I move over the translations I've made?'''
** If your file with additional translations is called old.po and the new file from the repository is called repo.po, create a new file called new.po by doing

msgmerge -o new.po old.po repo.po

The new file new.po will keep your translations from old.po as well as the new strings from repo.po, but check the result -- some translations will not be possible to move across if the original strings changed, these are kept as comments at the end of the file.

* '''How to generate man files from wesnoth-man(current 1.3 trunk) .po files?'''
To create "real" manpages out of the po files you have to install a prog
named "po4a" and run make update-po4a inside the maindir before running
make and make install. They are not automatically created out of po
files. With that command the files will be created and afterwards installed.

Note: At least 80% of the .po file must be translated for the creation of a man file

* '''Why is the diff from the previous version so huge? I have only made a small change to the .po file with poedit.'''
** When saving .po file poedit unwraps all strings. Usually, all .po files are wrapped at 80 characters so if you want smaller diffs and less merge conflicts you can execute the following commands each time after editing with poedit:

msgattrib file.po > file.po1
mv file.po1 file.po

== Tools ==

There are several tools to work with .po files:
* [http://userbase.kde.org/Lokalize Lokalize] (Unix KDE, intended to replace KBabel)
* [http://i18n.kde.org/tools/kbabel/ KBabel] (Unix KDE)
* [http://gtranslator.sourceforge.net/ GTranslator] (Unix Gnome)
* [http://translate.sourceforge.net/wiki/virtaal/index Virtaal] (Multiplatform)
* [http://www.poedit.net/ poEdit] (Multiplatform)
* [http://www.gnu.org/software/emacs/emacs.html Emacs with po-mode] (Multiplatform)
* [http://www.vim.org/ Vim] with [http://www.vim.org/scripts/script.php?script_id=695 PO plug-in] (Multiplatform)

Of course, you can edit po files with any UTF-8 capable text editor, but the tools listed above have great advantages over any text editor regarding .po translation, like going to next fuzzy/untranslated string, searching only in specific fields (msgid, msgstr, comment), ...

== See Also ==

* [[WesnothTranslations]]
* [[WesnothTranslationsHowTo]]
* [[GettextForWesnothDevelopers]]
* [[TranslatorShellscript]]
* [http://www.wesnoth.org/gettext/ Translation statistics]

[[Category:Translations]]

Translation Maintenance Commands

2014-06-23T14:28:28Z

Aquileia: Update script location

==Foreword==
This page is meant to document the current commands used for updating translation files that are sent in. Beside this it also is meant to list steps required to add new campaigns (importing from wescamp and changing textdomains) as well as new languages.

This version is based on the stuff required as of 1.6.1. It is based on autotools/configure usage atm but should be easily addaptable to cmake and scons, too.

==Prerequisites==
* svn checkout of Wesnoth with commit privs (eg svn+ssh://USERNAME@svn.gna.org/svn/wesnoth/branches/1.6/ )
* all the autotools foo: as required for building with autotools, too; basically autoconf and automake; when relying on a different build system cmake or scons are required
* gettext: required for the game anyway, but some gettext tools are used like msg*whatever* (don't know exactly which, magically done by the buildsystem...)
* po4a: required for documentation generation like manual and manpages, not for normal updates
* docbook: required to generate the manual, not for normal updates; not sure which parts of docbook at needed, these are the ones I have currently installed on my gentoo box:
** app-text/build-docbook-catalog-1.4
** app-text/docbook-xml-dtd-4.2-r2
** app-text/docbook-xml-dtd-4.4-r1
** app-text/docbook-xml-dtd-4.5
** app-text/docbook-xsl-stylesheets-1.74.0
* a terminal, preferably with bash available, commands posted here work nicely with bash and are easily put into a shellscript to automatize things.

After getting the svn checkout, run ./autogen.sh in the root dir of the checkout to make sure that all the links and make targets are created. So basically to do so a complete and working build environment has to exist.

==Folder structure and files relevant for translations==
Stuff relevant for translations is basically in ''po/''. In there all the translation catalogs as well as the translation files and some "helper files" are placed.

In po/ each subfolder stands for a different '''textdomain''':
* the folder ''wesnoth/'' stands for the textdomain ''wesnoth'' (includes many basic things) * the folder ''wesnoth-utbs/'' stands for the textdomain ''wesnoth-utbs'' and includes all the strings only relevant for the campaign Under the Burning Suns
* ...

In each folder several files are available:
===TEXTDOMAIN.pot===
Catalog with all the original strings. It includes no translated string, a copy of this file is basically what the gettext tools use to start a new translation. This is the file that is basically updated in a so called ''pot-update''. Against this catalog file all po files are merged when they are updated, only English strings in this file determine what has to be in the po-files as "original string". The file is named after the folder it is in.

===*.po===
These are the "real" translation files. They are named after the language they belong to, based on the "langcodes" for those. Eg the file for the german translation is named de.po. With these files translators do work and from these the .mo files are created when "compiling" them. The files basically consist of a header, an area of "active strings" (starting right after the header) and and area used for "old and now unused" strings (commented out using lines starting with ''#~''. All lines starting with a # are commented out, though there are various kinds of comments. These comments are defined by gettext, here a short explaination about them and their syntax, basically the beginning of the lines defines the type:
* ''#. My Text'': ''My Text'' is some automatically extracted comment from the sources (translation hints, status stuff, all this foo).
* ''#, fuzzy'': This string was seen as "reasonably close but not identical" when the file was updated. Translators should check this string and remove this line if the translation is correct. Unless this is done, the string is not shown translated in the program. This is the complete content of the line
* ''#: path/to/file:1'': File reference. This give a hint on where in the files this string was extracted from. Basically a filename:linenumber syntax is used. Only one file per line is listed, but several of those lines can be listed per string.
* ''# My comment'': ''My comment'' is a "Usercreated comment". Basically a comment the translator added. Anything the translator wants can be in here...
* ''#~'': Stuff following after ''#~'' is not active in the corresponding .pot file. Those are mainly old strings that were removed and are left over for the case that it gets back again into the game.
In general translations in the po file consist over (several) of those comments and two other blocks:
* msgid "Original String": the original string used that the translators have to work on.
* msgstr "Translated Version": the string that is used as replacement when the translation this file belongs to is used and a case of "Original String" is meat (where the original has to be marked as translateable!).
In general each of those strings can span over several lines, but to have a newline in the translation (or original) an explicit ''\n'' has to be added. The only constant thing is that strings have to be encapsulated by " and only the stuff inside of the " counts. Additionally to those "normal forms" the strings can also exists as plurals, here an example from the game and a corresponding German translation ([0] means singular, [1] means first plural form, [2] means 2nd plural form and so on):
#: src/actions.cpp:2485
msgid "Friendly unit sighted"
msgid_plural "$friends friendly units sighted"
msgstr[0] "Verbündete Einheit gesichtet"
msgstr[1] "$friends verbündete Einheiten gesichtet"

One more thing users should be aware of:
The translated and original strings have to start *and* end with the same number of \n. A mismatch in those numbers is the most common case for errors.

===LINGUAS===
This file includes a space separated list of all langcodes supported. As of 1.6.1 this is the current content of LINGUAS (changes when new langs are added or old ones are removed):
af ar bg ca ca_ES@valencia cs da de el en_GB es eo et eu fi fr fur_IT gl he hr hu id is it ja ko la lt lv mk mr nl nb_NO pl pt pt_BR racv ro ru sk sl sr sr@latin sv tl tr zh_CN zh_TW
A LINGUAS file exists in every subfolder of po/. The one right in po/ is used by scons and cmake, the one in each textdomain dir is used by autotools (no guarantee that this is really correct, but it should be...). Basically this is used to have a list of files that have to be compiled and such when building the game.

===FINDCFG===
This file in each textdomain dir includes the find term used to find all WML files relevant for this domain. Main task is to reduce time when running a pot-update so that not all files are checked, but only the relevant ones. This is mainly used for campaigns to only check the campaigns folder and stuff like this.
Example:
find data/core/units -name '*.cfg' -print
find data/campaigns/*/units -name '*.cfg' -print

===POTFILES.in===
In this file in each textdomain dir all the c++ files are listed that should belong to this domain. Basically it is just a plain list of the files and nothing more.
src/config_cache.cpp
src/construct_dialog.cpp
src/filechooser.cpp
src/font.cpp
src/game_preferences.cpp
src/game_preferences_display.cpp

===Makevars===
This file in each textdomain dir is for some varibales used by autotools when generating files. Don't ask for what exactly it is, in general it has not to be touched by humans at all. The only thing you should make sure is to add correct entries for textdomains in the ''DOMAIN = '' lines.

===CMakeLists.txt===
Providing information for cmake to generate the required commands. Identical for basically all textdomains.

===remove-potcdate.sin===
Some strange file available in each textdomain dir. Used by the tools, no idea how it is done and if it is really needed.

===Generated files===
Basically all the others files not listed here are generated by the build systems (or specific for documentation/po4a related stuff, described below). That especially includes *.mo or *,gmo files which include the "compiled" translations in a form that gettext can directly use them ingame, too.

===Documentation/po4a specific stuff===
====Makefile====
'''po4a based textdomain only''' (normally autogenerated by autotools)

A hardcoded makefile for po4a stuff. This should eventually be replaced by a generated file from eg cmake. Maybe ettin knows more about this stuff...

====TEXTDOMAIN.cfg====
'''po4a based textdomain only'''

A file with some po4a based config, also duplicating some stuff that normally would be available eg in LINGUAS. This should eventually be changed in some way, too. ATM it is there because, hmm, it is there... Some po4a specific variables are configured here, maybe ettin knows more about this stuff...

====manpages====
To manpages are placed in doc/man/. Currently the originals are '''wesnoth.6''' and '''wesnothd.6'''. Translations are generated from po/wesnoth-manpages/ and placed in doc/man/LANGCODE/ after they are generated using po4a. When new files are generated, they have to be added to svn ( svn add doc/man/*/*.6 ) and also in the autotools based makefile to have them installed (at the top of doc/man/Makefile.am ). Manpages are only created if at least 80% of the strings of the respective manpages are translated.

====html manual====
The base file for the manual is doc/manual/manual.txt. Using the po4a command stuff together with docbook the files doc/manual/manual.LANGCODE.html are generated. After generation of the files, they have to be added to svn, too ( svn add doc/manual/manual.*.html ). Translations can also come with own images, those should be placed in doc/manual/images/LANGOCE/ .

==pot-update==
In a pot-update all the reference files (po/wesnoth*/*.pot) are updated and the respective .po files are updated against those reference files. The commands I use to update all pot and the according .po files is:
cd $CHECKOUT
svn up
cd po/
make update-po
While doing so look out for any error messages from the gettext tools. Afterwards just commit stuff with a plain "svn ci". The "svn up" is only needed to be sure that all files are up to date (the ones with the original strings as well as the translation files).

==regenerating doc files==
To update the po files for documentation and generate the according translated manpages and manuals, use these commands:
cd $CHECKOUT
svn up
make update-po4a
Be aware that this requires po4a as well as docbook and takes considerable time. After running this command you should run ''svn st doc/'' to check if any files were added or removed (? and ! markers). Those files have to be added to svn (all with ?) or removed from svn (those with !, meaning that they were removed because they were not complete enough anymore). Just do so and commit afterwards using ''svn ci doc/ po/'' (the po/pot files as well as the doc files can/should change).

It can happen that files contain errors that are only shown when actually trying to regenerate the doc files. Those have to be fixed in the respective .po files to fix the problems. Doing so requires inspection "by hand" to find the real cause of the problem and fix all occurrences (rather often the case for the man pages with their strange syntax for highlighting).

==updating po files for committing==
When getting po files for committing them you have to ensure some things:
* make sure that the files are in the correct lineending (since svn:eol-style is set to "native" for all po-files)
* run ''pofix.py'' on the files to make sure that the latest "tiny typo fixes" are included in the po file and no unnecessary fuzzy strings are created
* update the files using ''make LANGCODE.po-update'' in the textdomains dir
* check that the files really compile using ''make LANGCODE.gmo'' in the textdomains dir (in general already the step before should end with an error, but with this step stats are shown about the file as well as an error if the file is broken)

In general I am using some rather easy system to handle translation updates. It basically consists of an extra folder which basically has all the po files from po/ in their folder structure and nothing else. Let's call this folder ''$LANGDIR'' (absolute path used!) from now on. In this folder is a folder for each textdomain (''wesnoth/'', ''wesnoth-anl'', ...) with all the *.po files for that domain. This folder is basically meant as intermediate step for renaming and all this stuff. Beside this there is also the checkout dir, lets call it ''$UPDIR'' (absolute path used!). When receiving an update, the archive (whatever format it is, no matter if .zip, .tar.bz2, .7z or *whatever*) is extracted and the TEXTDOMAIN/ folders copied over to the $LANGDIR. In a worst case situation files have to be copied over by hand because translators might use some crude naming scheme. Those following the naming guideline only require a ''cp -r wesnoth* $LANGDIR/''.

Next step is changing into the folder, ensuring the lineendings (unix is native on my box, thus using dos2unix) and copying the files into the "real" dir. This whole stuff is basically dependent on the single langcode you want to update. In a script LANGCODE can be a plain param. When using bash, you can just use this for loop:
cd $LANGDIR
for i in wesnoth* ; do cd $i; dos2unix LANGCODE.po; cp LANGCODE.po $UPDIR/po/$i/LANGCODE.po; cd .. ; done
When not using bash, just copy over the files for each dir by hand.

The next step is to update the files with pofix.py, merge against the latest catalog and build for stats/correctness sake:
cd $UPDIR/po/
for i in wesnoth* ; do cd $i; $UPDIR/utils/pofix.py $2.po; make $2.po-update; make $2.gmo; cd .. ; done
When not using bash, do so by hand or write yourself your own script...

When all of the commands were successfull, just commit the files using ''svn ci'', but make sure that the language is already added in ''changelog'' as well as ''players_changelog''. Using those steps the doc files are *not* regenerated since regenerating doc files takes quite some time. This is only down every now and then for all the doc files (mainly when a pot-update is run, too).

To sum things up, here all the commands used ($2 is the LANGCODE, commiting after this stuff if no error occurred and everything is as it should be):
echo "executing update script"
echo "switching to "$LANGDIR
cd $LANGDIR
echo "copying po-files"
for i in wesnoth* ; do cd $i; dos2unix $2.po; cp $2.po $UPDIR/po/$i/$2.po; cd .. ; done
echo "switching to "$UPDIR"/po"
cd $UPDIR/po/
echo "updateing po-files"
for i in wesnoth* ; do cd $i; $UPDIR/utils/pofix.py $2.po; make $2.po-update; make $2.gmo; cd .. ; done
echo "update complete"

==adding a new Language==
For adding a new language several steps have to be done:
* add the LANGCODE in the list in all LINGUAS files (po/LINGUAS as well as po/wesnoth*/LINGUAGS )
* edit po/wesnoth-man*/wesnoth-man*.cfg to have the LANGCODE added here, too
* generate the po files for the language using this command:
cd po/
for i in wesnoth*; do cd $i; msginit -l LANG_CODE --no-translator; cd ..; done
* make sure the files really compile (basically check if the plural forms and the rest of the header is fine by trying to compile everything normally; a problematic case is eg ''"Project-Id-Version: PACKAGE VERSION\n"'' in the textdomain ''wesnoth'')
* add ''data/languages/langcode_COUNTRYCODE.cfg'' (should look like the other files, too; required to have the file in the lang selection list ingame)
* add language to ''data/core/about.cfg'' (can be a dummy entry for the moment, this is mainly for other langs to have this string among their translateable strings as soon as possible.
* add all the new files to svn and commit (from the checkouts root):
svn add po/wesnoth*/LANG-CODE.po data/languages/langcode_COUNTRYCODE.cfg
svn ci po/wesnoth*/LANG-CODE.po po/*/LINGUAS po/LINGUAS data/languages/langcode_COUNTRYCODE.cfg data/core/about.cfg
* update the language list of g.w.o: This requires getting a checkout of ''branches/resources/gettext.wesnoth.org/public_html/wesnoth-gettext/westats/''. Make sure to add the language to ''langs.php'' in this checkout, commit and ping someone with ssh access to wesnoth.org to run ''svn up'' as the user ''wesnoth'' inside $HOME/SOURCE/gettext.wesnoth.org to have the website updated, too.

==adding translation files for a new campaign==
This is basically the case when importing a new campaign from wescamp. The commands/steps used are:
* Make sure you got an up to date checkout of wescamp (search the wiki for info about this).
* cd into the wesnoth checkout dir
* run this command to import the textdomain from the wescamp repo (the resulting script directly wants to commit, if this is not wanted, comment the respective part out in import_script.sh):
./utils/wescamp_import wescamp-path campaign-name wescamp-textdomain > import_script.sh
./import_script.sh
* Due to changes in the build system and addition of other build systems, a little more has to be done:
** copy over po/wesnoth/CMakeLists.txt to po/TEXTDOMAIN/CMakeLists.txt, and add it to svn
** add the textdomain to po/CMakeLists.txt in the set ''TRANSLATION_DIRS''
** commit the changed files

If the campaign was not in wescamp before, some other commands will have to be used. Basically the "base files" (as described a lot above) have to be created. Most will be done via copy&paste. Of course the po files have to be created, too. For this to work (after adding the po/TEXTDOMAIN folder as well as the required hooks in configure.ac and po/Makefile.am) autogen.sh has to be run and a pot-update (using ''make update-po'') has to be done in the new textdomains folder to generate po/TEXTDOMAIN/TEXTDOMAIN.pot. Once the .pot file exists, the po files can easily be created with this command:
cd po/TEXTDOMAIN/
for i in `cat LINGUAS`; do msginit -l $i --no-translator; done
Afterwards add all the new files to svn and commit.

Most campaigns that are added have the wrong textdomain to work with "mainline". It should basically work, but there are ways to make it "better". To do so, just use the script utils/change-textdomain should be used. Here are the required commands for switching textdomains:
cd $UPDIR
./utils/change-textdomain campaign-name oldtextdomain newtextdomain
Now edit po/CMakeLists.txt by hand (was not existing when the script was written) to change the textdomain declaration from the old value to the new one. In general files in data/campaign-name/ as well as po/ and configure.ac were altered by this script.

After adding all this new stuff to svn the properties for the files (lineendings) as well as ignores for the folders are not set correctly. To change this, run ''svn propedit svn:ignore po/TEXTDOMAIN'' and add this list of files:
CMakeCache.txt
CMakeFiles
cmake_install.cmake
Makefile
Makefile.in
Makefile.in.in
POTFILES
stamp-po
remove-potcdate.sed
*.gmo
Beside this all the files need their svn:eol-style changed. Use these command to change this:
cd po/TEXTDOMAIN
for i in *.po*; do svn propset svn:eol-style "native" $i; done
svn propset svn:eol-style "native" FINDCFG
svn propset svn:eol-style "native" LINGUAS
svn propset svn:eol-style "native" Makevars
svn propset svn:eol-style "native" POTFILES.in
svn propset svn:eol-style "native" remove-potcdate.sin
svn propset svn:eol-style "native" CMakeLists.txt

Now the po files for the new campaign should exist and all the stuff be ready for usage. Only thing left is adding the textdomain to gettext.wesnoth.org. This requires getting a checkout of ''branches/resources/gettext.wesnoth.org/public_html/wesnoth-gettext/westats/''. Make sure to add the textdomain to ''config.php'' in this checkout in the respective ''$packages = '' part, commit and ping someone with ssh access to wesnoth.org to run ''svn up'' as the user ''wesnoth'' inside $HOME/SOURCE/gettext.wesnoth.org to have the website updated, too. With the next run of the update (done every 30mins) the stats for the new domain should appear on the website.

==translation related utils==
===change-textdomain===
This script is meant for several purposes and run from the main checkout dir using ''./utils/change-textdomain PARAMS''. The result depends on PARAMS:
* ''-t'': check all .cfg files in data/ for a textdomain declaration. If there is none, add ''#textdomain wesnoth'' at the top of the files
* ''campaign-name oldtextdomain newtextdomain'': switches the textdomain for a specific campaign (the name is as in the foldername of data/campaigns/FOLDERNAME). This includes adding all textdomain related things in the campaigns folder as well as moving the folder for the old textdomain to the new textdomain in po/. Many of the files are adjusted, atm only po/CMakeLists.txt has to be adjusted by hand.

===po2po===
A program to merge strings between various textdomains. In general using this script is *dangerous* since plural forms are *not* handled well.

===pofix.py===
A program to fix tiny spelling mistages over all textdomains. Ask esr for details (like how to add fixes and such).

===sanity-check===
Checks if the src files listed in po/wesnoth*/POTFILES.in exist and if all files are listed. For this only the textdomains ''wesnoth'', ''wesnoth-editor'' and ''wesnoth-lib'' are considered since the other files should be WML only.

===wescamp_import===
Import the translations of a campaign from wescamp. This requires a wescamp checkout. How this script is used is described further above under ''adding translation files for a new campaign''.

===wmlxgettext===
This script is used to extract translateable files from WML files. The file in utils/ is written in perl and esr is currently working on a replacement written in python. This is available as data/tools/wmlxgettext and requires some more testing. For usage info, ask esr since he probably knows best how to handle wmlxgettext.

[[Category:Translations]]
[[Category:Development]]
[[Category:Tools]]

== Handling Localized Images ==

Translators may localize any in-game image they want. These should mostly be images with some English text on them, like main logo, maps, and in-game help screenshots. Localized images come in two varieties:

* standalone localized images -- localized images which totally replace the original image, when the modified area of the image is great enough (e.g. logo);

* localized overlay images -- images mostly transparent but for some isolated spots, which are are composed with the original at runtime, when the modified area is too small to waste space using a standalone localized image (e.g. maps).

For translators' view of the process, see [[User_talk:Caslav.ilic/ImageLocalization|the separate article]].

=== Receiving New Images ===

When translator sends in a localized image, the maintainer should locate its original counterpart, and place the localized image into the <tt>l10n/LANG</tt> subdirectory of the original image's directory (where <tt>LANG</tt> is the appropriate language code). E.g. if the original image path is:

foo/bar/image.png

then the standalone localized image will have the same name, and be placed as:

foo/bar/l10n/LANG/image.png

and the overlay image will have <tt>--overlay</tt> suffix (note ''two'' hyphens):

foo/bar/l10n/LANG/image--overlay.png

Then, to register the new localized image with tracking system (see [[#Image Synchronization|below]]), the maintainer executes the tracker script in the branch root directory:

$ lbundle-check.py
A foo/bar/l10n/LANG
A (bin) foo/bar/l10n/LANG/image.png
M l10n-track
--------------------
New 'ok': 1
./foo/bar/l10n/LANG/image.png (./foo/bar/image.png 30534)
$

The tracker script will add any new images (and their directories) to version control, and add an entry for this image to the global tracking file <tt>l10n-track</tt>:

ok ¦foo/bar/l10n/LANG/image.png¦ 5c3e43227fd07391faf441450d623543 30534

Then the maintainer just commits everything (including <tt>l10n-track</tt>).

=== Receiving Modified Images ===

Everything as when a new image is received, except that ''prior'' to running tracker script, the line of the image in <tt>l10n-track</tt> should be manually removed. This will make the tracker script register the modified image as matching the current original, with <tt>ok</tt> status (it may have been <tt>fuzzy</tt> before).

In fact, to remove the entry line from <tt>l10n-track</tt> is strictly necessary only if the old status is <tt>fuzzy</tt>. But it's good to do it even if status was <tt>ok</tt>, to get expected feedback when the tracker script is run, signaling proper placement of received image.

=== Tracking Synchronization to Original ===

From time to time the original image will have been moved, removed, or modified, and localized images need to follow this change. To detect such conditions, the maintainer periodically (e.g. sufficiently before the impending release) runs the [https://gitorious.org/scripty/scripty/source/master:l10n-support/lbundle-check.py tracker script] in root directory of the branch, without any arguments, e.g.:

$ cd $REPOSITORY/trunk/
$ lbundle-check.py

If all localized and original images are in sync, there will be no output.

If an original image was modified, the tracker script will notify about it in output, and change the status of corresponding localized images in <tt>l10n-track</tt> to <tt>fuzzy</tt>:

fuzzy ¦foo/bar/l10n/LANG/image.png¦ 5c3e43227fd07391faf441450d623543 30534

The third and fourth field here are the checksum and revision ID of the ''old'' original, to which the localized image was synced. In only some images were fuzzied, maintainer can just commit the <tt>l10n-track</tt> file and be done with it. (Old original revision ID is what translators can use later to compare the changes in the original, modify the localized image accordingly, and send in the updated version.) Alternatively, if in good mood, maintainer could also check in repository log if perhaps the original just got compressed, i.e. there were no visible changes, and manually unfuzzy all the localized images (by removing their lines from <tt>l10n-track</tt> and rerunning the tracker).

If an original image got moved or removed, the status of corresponding localized images will be set to <tt>obsolete</tt>. Then the maintainer should examine what happend to the original image: if it got moved, move localized images accordingly, and if it got removed, remove localized images as well. Then, remove obsolete entries from <tt>l10n-track</tt>, rerun the tracker, and commit moves/removals and modified <tt>l10n-track</tt>.

The setup for the tracker script is in <tt>l10n-spec</tt> file in the root directory, next to <tt>l10n-track</tt> file. It has very few and self-explanatory settings in form of <tt>key=value</tt> pairs. Only the first of those setting needs to be periodically updated:

# List of language codes that have at least one localized file.
languages = sv fr ...

as languages send their first localized images in ((alternatively, just mirror contents of <tt>po/LINGUAS</tt> as the value)).

MapLocalization

2014-06-20T00:27:57Z

Aquileia: /* Final notes */

'''This page is a work in progress'''

Like the old maps, the new-style maps can be localized, but the intended method for doing so is quite different.

=== Overview ===

However, the workflow for localizing a map is simple: you create an image which contains the localized labels on a transparent background as simple text, no post-processing effects needed. In GIMP, you then add that image to a corresponding .xcf file as a new layer, and run a script. The script creates an overlay image which covers up the english labels, adds your localized labels and applies a bunch of post-processing effects to them in order to make them look identical to the english labels. All you need to do is to check the output and save.

=== Step-by-step instructions ===

==== Preparations ====

1. If you don't have GIMP, install it.

2. Download the [https://github.com/wesnoth/resources/tree/master/image-localization/maps/wesnoth-map-localization.scm wesnoth-map-localization.scm script] and place it into a script directory recognized by GIMP. You can view and configure the script directories in GIMP's preferences (Preferences -> Folders -> Scripts). If you already have GIMP running, you need to use '''Filters -> Script-Fu -> Refresh Scripts''' to make it recognize the newly added script. In the Filters menu, you should now see a filter category called "Wesnoth", and inside it "Map Localization". However, we don't need it yet.

3. Download the [https://github.com/wesnoth/resources/tree/master/image-localization/maps/ localization.xcf for the map you're localizing].

Now you're all set to begin.

==== Localization ====

# Open the localization.xcf you've downloaded. It contains a bunch of layers needed by the localization script, but at this point all you need is the layer called "label placement guide". It's a version of the map without any perspective or displacement effects added, and it is the one onto which you need to place the localized layers.
# Create a new layer which includes the localized labels, positioning them using the aforementioned layer as a guide. The positions or orientation or curving of the labels does not need to match the english labels in any way. Place them in a way which you think looks good. The requirements for the labels are simple: black text should be pure black, whereas yellow labels on forests should have the RGB value 185,155,85. The script gives you a little bit of leeway so you don't have to stress over very small color deviations, but don't do it intentionally. Background should be transparent. ''Note that you can use whatever graphics application you want in creating your labels, as long as you can import the result into GIMP so that it meets the above requirements.'' 
# Add the layer containing your localized text into the same localization.xcf file and name it "labels". Don't mess with the other layers.
# If ''labels'' and ''label placement guide'' are layer groups, merge them down to single layers. Notice as well that these have to begin with a lowercase l for the script to work.
# Run the script by choosing Filters -> Wesnoth -> Map Localization. The script will create a new image, and produce the output there. This will take a moment, perhaps as much as a minute or more on a slow computer, and for a few seconds it might seem like nothing is happening.
# You should now have a new image with a single layer called "localized overlay". Inspect that everything's ok by adding the original english map as a new layer underneath the overlay; the english labels should be covered up, the localized labels in place and there should be no glitches anywhere. Export the image to PNG (just remember to hide/delete the english map layer first!) and you're done. In the PNG export dialog, uncheck the option "Save color values from transparent pixels" to get the file of expected size (~100-300 KiB; if the option is not unchecked, it is over 2 MiB).

===== Final notes =====

If there are labels which you don't need to localize, then first of all, don't bother including them among your localized labels. Then, once you've generated the final overlay, simply erase the parts which cover up the original english label.

The script works if and only if the labels layer contains both black and golden pixels.

''As the Dead Water map has no forests, there's a yellow label inmidst the ocean. You'll have to remove that from the final product - it's only there to save you a headache on why the script doesn't work.''

===== Text sizing =====

These are the text sizing rules that have been used on the english maps. Depending on your language, you may want to break some of them.

Major geographical features or other large areas which extend beyond the map edges (including forests): 28px small caps, tracking ~200.
''Note that these are font sizes for Photoshop. GIMP has slightly different text tools and does not have small caps effect. Small caps effect can be reproduced by using caps with 30px for the first letter and 20px bold for the remaining letters. You might also need to make all text bold in Gimp so it will be legible. The corresponding font tracking in GIMP is 5.0.''

Large geographical features: 22px normal or small caps.

Minor geographical features: 18px normal.

Major rivers: 20px, tracking ~200.

Small rivers: 18px, tracking ~200. For names like "R. Weldyn", note that periods are very small in Monotype Corsiva and get very close to the preceding R; I suggest giving the . a size of 24-30px and removing the following space. Other solutions can work too.

Capital cities: 24px normal.

Other major cities: 20px normal.

Small cities: 16px normal. You might need to increase this to 18px for legibility.

Large forests: 24px normal.

Small forests: 18px normal.

===== Text orientation and curving =====

In the english maps, names of large geographical areas and rivers are often curved. River names usually follow the shape of the river, and names of large features such as "Heart Mountains" are curved to roughly match the shape of said feature.

All of the above is optional. You do not need to match the english labels in shape and location. If for some reason you need to, you can even omit some labels or add completely new ones.

===== Title screen map =====

The title screen map is identical with the ''Heir to the Throne'' campaign map. Localize the map for ''Heir to the Throne'', create a copy of the overlay and rename it to 'titlescreen--overlay.png', then place it in ''\data\core\images\maps\l10n\<language iso code>'' and you're done.

[[Category:Translations]]

GermanTranslationUnitNames

2014-06-19T22:38:41Z

Aquileia: Ergänze /* Bedeutende Orte */

= Hinweise zur Übersetzung inoffizieller Erweiterungen =

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

== Generelles ==

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

== Zeichensetzung ==

Es werden die typografisch richtigen Satzzeichen verwendet:

* Anführungszeichen: »Text«, nicht "Text" oder 'Text'
* Gedankenstriche: Text – Einschub, nicht Text - Einschub oder Text -- Einschub (Halbgeviertstrich anstatt Viertelgeviertstrich)
* Apostrophe: Geht’s, nicht Geht's
* die vollständige (englische) Typografie-Anleitung gibt es [http://wiki.wesnoth.org/Typography_Style_Guide hier]

== Einheiten ==

Vielleicht hilfreich für Kampagnen-Übersetzer, damit auch niemand Goblin mit Goblin übersetzt oder Wose mit Baummensch! Die Übersetzungen findet sich für die Entwicklerversion [http://units.wesnoth.org/trunk/mainline/de_DE/mainline.html hier]

Drake - mainline

{| border="solid"
|
| '''Drakenschmetterer''' Drake Clasher
| '''Drakenschlichter''' Drake Arbiter
| '''Drakenschlächter''' Drake Warden
|
|
|-
|
|
| '''Drakendrescher''' Drake Thrasher
| '''Drakenvollstrecker''' Drake Enforcer
|
|
|-
|
| '''Drakenkämpfer''' Drake Fighter
| '''Drakenkrieger''' Drake Warrior
| '''Drakenklingenmeister''' Drake Blademaster
|
|
|-
|
| '''Drakengleiter''' Drake Glider
| '''Himmelsdrake''' Sky Drake
| '''Sturmdrake''' Hurricane Drake
|
|
|-
|
| '''Flammendrake''' Drake Burner
| '''Feuerdrake''' Fire Drake
| '''Infernodrake''' Inferno Drake
|
|
|-
|
|
| '''Lodernder Drake''' Drake Flare
| '''Drake Flameheart''' Entflammender Drake
|
|
|-
|
|
|
|
| '''Armageddon Drake''' Armageddondrake
|
|-
|}

Dwarf - mainline

{| border="solid"
|
| '''Greifenreiter''' Gryphon Rider
| '''Zwergen Donnerwächter''' Dwarvish Thunderguard
| '''Zwergen Drachenwächter''' Dwarvish Dragonguard
|
|
|-
|
| '''Zwergen Gardist''' Dwarvish Guardsman
| '''Zwergen Berserker''' Dwarvish Berserker
| '''Zwergen Fürst''' Dwarvish Lord
|
|
|-
|
| '''Zwergen Kämpfer''' Dwarvish Fighter
| '''Greifenmeister''' Gryphon Master
| '''Zwergen Schildwache''' Dwarvish Sentinel
|
|
|-
|
| '''Zwergen Ulfserker''' Dwarvish Ulfserker
| '''Zwergen Wache''' Dwarvish Stalwart
| '''Zwergen Runenmeister''' Dwarvish Runemaster
|
|
|-
|
| '''Zwergen Donnerer''' Dwarvish Thunderer
| '''Zwergen Chalybter''' Dwarvish Steelclad
|
|
|
|-
|}

Elf - mainline

{| border="solid"
|
| '''Elfenbogenschütze''' Elvish Archer '''Elfenbogenschützin''' Elvish Archer
| '''Elfenlangbogenschütze''' Elvish Marksman '''Elfenlangbogenschützin''' Elvish Marksman
| '''Elfen Avantgarde''' Elvish Outrider
| '''Sylphide''' Elvish Sylph
|
|-
|
| '''Elfenschamanin''' Elvish Shaman
| '''Elfendruidin''' Elvish Druid
| '''Elfenschwertmeister''' Elvish Champion
|
|
|-
|
| '''Elfenspäher''' Elvish Scout
| '''Elfenhauptmann''' Elvish Captain
| '''Elfenscharfschütze''' Elvish Sharpshooter '''Elfenscharfschützin''' Elvish Sharpshooter
|
|
|-
|
| '''Elfenkrieger''' Elvish Fighter
| '''Elfenkundschafter''' Elvish Rider
| '''Elfenrächer''' Elvish Avenger '''Elfenrächerin''' Elvish Avenger
|
|
|-
|
|
| '''Elfenheld''' Elvish Hero
| '''Elfenmarschall''' Elvish Marshal
|
|
|-
|
|
| '''Elfenzauberin''' Elvish Sorceress
| '''Elfenmystikerin''' Elvish Enchantress
|
|
|-
|
|
| '''Elfenwaldhüter''' Elvish Ranger '''Elfenwaldhüterin''' Elvish Ranger
| '''Waldfee''' Elvish Shyde
|
|
|-
|}

Goblin - mainline

{| border="solid"
| '''Kobold Speerträger''' Goblin Spearman
| '''Wolfsreiter''' Wolf Rider
| '''Kobold Raubritter''' Goblin Knight
| '''Schreckenswolf Reiter''' Direwolf Rider
|
|
|-
|
| '''Kobold Standartenträger''' Goblin Rouser
| '''Kobold Plünderer''' Goblin Pillager
|
|
|
|-
|
| '''Kobold Pfähler''' Goblin Impaler
|
|
|
|
|-
|}

Human - mainline

{| border="solid"
| '''Bauer''' Peasant
| '''Dunkler Adept''' Dark Adept '''Dunkle Adeptin''' Dark Adept
| '''Bandit''' Bandit
| '''Fechtmeister''' Master at Arms
| '''Feldmarschall''' Grand Marshal
|
|-
| '''Förster''' Woodsman
| '''Reiter''' Horseman
| '''Weißer Magier''' White Mage '''Weiße Magierin''' White Mage
| '''Leibgardist''' Royal Guard
| '''Großmagier''' Great Mage '''Großmagierin''' Great Mage
|
|-
| '''Raufbold''' Ruffian
| '''Dieb''' Thief '''Diebin''' Thief
| '''Schwarzer Magier''' Dark Sorcerer
| '''Erzmagier''' Arch Mage '''Erzmagierin''' Arch Mage
|
|
|-
|
| '''Bogenschütze''' Bowman
| '''Ritter''' Knight
| '''Magier des Lichtes''' Mage of Light '''Magierin des Lichtes''' Mage of Light
|
|
|-
|
| '''Speerträger''' Spearman
| '''Schreckenskrieger''' Shock Trooper
| '''Stahlkoloss''' Iron Mauler
|
|
|-
|
| '''Strolch''' Thug
| '''Speerwerfer''' Javelineer
| '''Templer''' Grand Knight
|
|
|-
|
| '''Feldwebel''' Sergeant
| '''Roter Magier''' Red Mage '''Rote Magierin''' Red Mage
| '''Attentäter''' Assassin '''Attentäterin''' Assassin
|
|
|-
|
| '''Duellant''' Fencer
| '''Schwertkämpfer''' Swordsman
| '''Kürassier''' Cavalier
|
|
|-
|
| '''Kavallerist''' Cavalryman
| '''Langbogenschütze''' Longbowman
| '''General''' General
|
|
|-
|
| '''Schwerer Infanterist''' Heavy Infantryman
| '''Dragoner''' Dragoon
| '''Totenbeschwörer''' Necromancer
|
|
|-
|
| '''Wilddieb''' Poacher
| '''Lanzenreiter''' Lancer
| '''Paladin''' Paladin
|
|
|-
|
| '''Wegelagerer''' Footpad '''Wegelagererin''' Footpad
| '''Pikenträger''' Pikeman
| '''Meisterbogenschütze''' Master Bowman
|
|
|-
|
| '''Magier''' Mage '''Magierin''' Mage
| '''Fechter''' Duelist
| '''Silberner Magier''' Silver Mage '''Silberne Magierin''' Silver Mage
|
|
|-
|
|
| '''Leutnant''' Lieutenant
| '''Hellebardier''' Halberdier
|
|
|-
|
|
| '''Geächteter''' Outlaw '''Geächtete''' Outlaw
|
|
|
|-
|
|
| '''Schurke''' Rogue '''Schurkin''' Rogue
|
|
|
|-
|
|
| '''Fallensteller''' Trapper
|
|
|
|-
|}

Lizard - mainline

{| border="solid"
|
| '''Saurianischer Seher''' Saurian Augur
| '''Saurianischer Herbalist''' Saurian Soothsayer
| '''Saurianischer Flänkler''' Saurian Flanker
|
|
|-
|
| '''Saurianischer Plänkler''' Saurian Skirmisher
| '''Saurianischer Hinterlistling''' Saurian Ambusher
|
|
|
|-
|
|
| '''Saurianischer Frostmeister''' Saurian Oracle
|
|
|
|-
|}

Mechanical - mainline

{| border="solid"
|
| '''Transportgalleone''' Transport Galleon
|
|
|
|
|-
|
| '''Piratengalleone''' Pirate Galleon
|
|
|
|
|-
|
| '''Galleone''' Galleon
|
|
|
|
|-
|}

Merman - mainline

{| border="solid"
|
| '''Wassermann Kämpfer''' Merman Fighter
| '''Meerjungfrau-Priesterin''' Mermaid Priestess
| '''Meerjungfrau-Wahrsagerin''' Mermaid Diviner
|
|
|-
|
| '''Wassermann Jäger''' Merman Hunter
| '''Seeknecht Merman Warrior
| '''Wassermann Netzmeister''' Merman Entangler
|
|
|-
|
| '''Meerjungfrau''' Mermaid Initiate
| '''Meerjungfrau-Mystikerin''' Mermaid Enchantress
| '''Wassermann Speerwerfer''' Merman Javelineer
|
|
|-
|
|
| '''Wassermann Netzwerfer''' Merman Netcaster
| '''Wassermann Herr der Tiefe''' Merman Triton
|
|
|-
|
|
| '''Wassermann Speerträger''' Merman Spearman
| '''Sirene''' Mermaid Siren
|
|
|-
|
|
|
| '''Wassermann Hoplit''' Merman Hoplite
|
|
|-
|}

Monster - mainline

{| border="solid"
| '''Schlammkriecher''' Mudcrawler
| '''Riesenskorpion''' Giant Scorpion
| '''Tintenfisch''' Cuttle Fish
| '''Riesenspinne''' Giant Spider
| '''Yeti''' Yeti
|
|-
|
| '''Tentakel der Tiefe''' Tentacle of the Deep
| '''Greif''' Gryphon
| '''Seeschlange''' Sea Serpent
|
|
|-
|
| '''Riesenschlammkriecher''' Giant Mudcrawler
|
|
|
|
|-
|}

Naga - mainline

{| border="solid"
|
| '''Naga Kämpfer''' Naga Fighter '''Nagini Kämpferin''' Nagini Fighter
| '''Naga Krieger''' Naga Warrior '''Nagini Kriegerin''' Nagini Warrior
| '''Naga Scherge''' Naga Myrmidon '''Nagini Scherge''' Nagini Myrmidon
|
|
|-
|}

Ogre - mainline

{| border="solid"
|
| '''Junger Oger''' Young Ogre
| '''Oger''' Ogre
|
|
|
|-
|}

Orc - mainline

{| border="solid"
|
| '''Orkschütze''' Orcish Archer
| '''Orkschlächter''' Orcish Slayer
| '''Orkkharraschschütze''' Orcish Slurbow
|
|
|-
|
| '''Orkmeuchler''' Orcish Assassin
| '''Orkarmbruster''' Orcish Crossbowman
| '''Orkkriegsherr''' Orcish Warlord
|
|
|-
|
| '''Orkgrunzer''' Orcish Grunt
| '''Orkkrieger''' Orcish Warrior
| '''Orkheerführer''' Orcish Sovereign
|
|
|-
|
| '''Orkhäuptling''' Orcish Leader
| '''Orkkriegshäuptling''' Orcish Ruler
|
|
|
|-
|}

Troll - mainline

{| border="solid"
|
| '''Trollwelpe''' Troll Whelp
| '''Troll-Felsenschleuderer''' Troll Rocklobber
| '''Trollheld''' Great Troll
|
|
|-
|
|
| '''Troll''' Troll
| '''Kriegstroll''' Troll Warrior
|
|
|-
|
|
| '''Mächtiger Troll''' Troll Hero
|
|
|
|-
|}

Undead - mainline

{| border="solid"
| '''Vampirfledermaus''' Vampire Bat
| '''Seelenloser''' Soulless
| '''Rachegeist''' Wraith
| '''Todesritter''' Death Knight
| '''Alter Lich''' Ancient Lich
|
|-
| '''Wandelnde Leiche''' Walking Corpse
| '''Blutfledermaus''' Blood Bat
| '''Unheilsbringer''' Deathblade
| '''Spuk''' Spectre
| '''Skelettdrache''' Skeletal Dragon
|
|-
|
| '''Ghul''' Ghoul
| '''Knochenbogenschütze''' Bone Shooter
| '''Seelenschütze''' Soul Shooter
|
|
|-
|
| '''Geist''' Ghost
| '''Wiedergänger''' Revenant
| '''Lich''' Lich
|
|
|-
|
| '''Skelettbogenschütze''' Skeleton Archer
| '''Leichenfresser''' Necrophage
| '''Knochenschlächter''' Draug
|
|
|-
|
| '''Skelett''' Skeleton
| '''Knochenreiter''' Chocobone
| '''Nachtalb''' Nightgaunt
|
|
|-
|
|
| '''Schatten''' Shadow
| '''Scheusal''' Ghast
|
|
|-
|}

Wose - mainline

{| border="solid"
|
| '''Waldschrat''' Wose
| '''Älterer Waldschrat''' Elder Wose
| '''Alter Waldschrat''' Ancient Wose
|
|
|-
|}

Elf - Heir to the Throne

{| border="solid"
|
|
| '''Elfenbaron''' Elvish Lord
| '''Elfenfürst''' Elvish High Lord
|
|
|-
|
|
|
| '''Elfenadlige''' Elvish Lady
|
|
|-
|}

Human - Heir to the Throne

{| border="solid"
| '''Jüngling''' Youth
| '''Krieger''' Fighter
| '''Prinzessin''' Princess
| '''Fürst''' Lord
|
| '''Alter Magier''' Elder Mage
|-
|
|
| '''Feldherr''' Commander
| '''Dunkle Königin''' Dark Queen
|
|
|-
|
|
|
| '''Kriegerprinzessin''' Battle Princess
|
|
|-
|}

Monster - Heir to the Throne

{| border="solid"
|
|
| '''Schlafender Greif''' Sleeping Gryphon
|
|
|
|-
|
|
| '''Gorgonit''' Cockatrice
|
|
|
|-
|}

Orc - Heir to the Throne

{| border="solid"
|
| '''Seeork''' Sea Orc
|
|
|
|
|-
|}

Human - The Rise of Wesnoth

{| border="solid"
| '''Edler Jüngling''' Noble Youth
| '''Edler Kämpfer''' Noble Fighter
| '''Edler Feldherr''' Noble Commander
| '''Edler Fürst''' Noble Lord
|
|
|-
|
|
| '''Geächtete Prinzessin''' Outlaw Princess
| '''Kriegerkönig''' Warrior King
|
|
|-
|
|
|
| '''Geächtete Königin''' Outlaw Queen
|
|
|-
|}

Mechanical - The Rise of Wesnoth

{| border="solid"
| '''Feuerball''' Fireball
|
|
|
|
|
|-
|}

Monster - The Rise of Wesnoth

{| border="solid"
|
|
|
|
|
| '''Feuerdrache''' Fire Dragon
|-
|}

Undead - The Rise of Wesnoth

{| border="solid"
|
|
|
| '''Vampirin''' Vampire Lady
|
|
|-
|}

Wose - The Rise of Wesnoth

{| border="solid"
| '''Junger Waldschrat''' Wose Sapling
|
|
|
|
|
|-
|}

Human - Eastern Invasion

{| border="solid"
|
| '''Berittener Kämpfer''' Mounted Fighter
| '''Berittener Krieger''' Mounted Warrior
| '''Berittener Fürst''' Horse Lord
|
|
|-
|}

Human -The South Guard 

{| border="solid"
|
| '''Berittener Leutnant''' Junior Commander
| '''Infanterieleutnant''' Infantry Lieutenant
| '''Infanteriehauptmann''' Infantry Commander
|
|
|-
|
|
| '''Berittener Hauptmann''' Horseman Commander
| '''Hauptmann''' Dismounted Commander
|
|
|-
|}

Undead -The South Guard 

{| border="solid"
|
|
|
| '''Demi-Lich''' Demilich
|
|
|-
|}

Unknown -The South Guard 

{| border="solid"
| '''Unsichtbarer''' Invisible
|
|
|
|
|
|-
|}

Dwarf - Under the Burning Suns

{| border="solid"
|
| '''Zwergenkundschafter''' Dwarvish Scout
| '''Zwergenpfadfinder''' Dwarvish Pathfinder
| '''Zwergenforscher''' Dwarvish Explorer
|
|
|-
|}

Elf - Under the Burning Suns

{| border="solid"
|
| '''Wüstenschamanin''' Desert Shaman
| '''Wüstenlangbogenschütze''' Desert Marksman '''Wüstenlangbogenschützin''' Desert Marksman
| '''Wüstenschwertmeister''' Desert Champion
| '''Wüstenlichtfee''' Desert Star
|
|-
|
| '''Wüstenjäger''' Desert Hunter '''Wüstenjägerin''' Desert Hunter
| '''Wüstenheld''' Desert Hero
| '''Wüstenfee''' Desert Shyde
|
|
|-
|
| '''Wüstenkämpfer''' Desert Fighter
| '''Wüstenhauptmann''' Desert Captain
| '''Göttliche Inkarnation''' Divine Incarnation
|
|
|-
|
| '''Wüstenspäher''' Desert Scout
| '''Göttlicher Abgesandter''' Divine Avatar
| '''Korrupter Elfe''' Corrupted Elf
|
|
|-
|
| '''Wüstenbogenschütze''' Desert Archer '''Wüstenbogenschützin''' Desert Archer
| '''Wüstenritter''' Desert Horseman
| '''Wüstenscharfschütze''' Desert Sharpshooter '''Wüstenscharfschützin''' Desert Sharpshooter
|
|
|-
|
|
| '''Wüstenwache''' Desert Sentinel '''Wüstenwächterin''' Desert Sentinel
| '''Wüstenmarschall''' Desert Marshal
|
|
|-
|
|
| '''Wüstendruidin''' Desert Druid
| '''Wüstenplänkler''' Desert Prowler
|
|
|-
|
|
| '''Wüstenläufer''' Desert Ranger '''Wüstenläuferin''' Desert Ranger
| '''Wüstenwindreiter''' Desert Outrider
|
|
|-
|
|
| '''Wüstenreiter''' Desert Rider
| '''Wüstenrächer''' Desert Avenger '''Wüstenrächerin''' Desert Avenger
|
|
|-
|}

Human - Under the Burning Suns

{| border="solid"
|
|
|
| '''Kommandant der Menschen''' Human Commander
|
|
|-
|}

Monster - Under the Burning Suns

{| border="solid"
| '''Pulsierende Pyramide''' Pulsing Spire
| '''Hüter des Feuers''' Fire Guardian
| '''Ixthala Dämon''' Ixthala Demon
| '''Zentralkörper''' Central Body
|
|
|-
| '''Kriechender Horror''' Crawling Horror
| '''Riesenameise''' Giant Ant
| '''Fleisch-Golem''' Flesh Golem
| '''Geschwächter Zentralkörper''' Weakened Central Body
|
|
|-
| '''Leerraum''' Blank
| '''Dawarf''' Dawarf
| '''Ungeheuer aus der Tiefe''' Deep One
| '''Höhlenspinne''' Cave Spider
|
|
|-
| '''Kleiner Schlammkriecher''' Small Mudcrawler
| '''Wirre Riesenameise''' Confused Ant
|
|
|
|
|-
|
| '''Krabbenmensch''' Crab Man
|
|
|
|
|-
|}

Naga - Under the Burning Suns

{| border="solid"
|
| '''Naga Jäger''' Naga Hunter
| '''Naga Wächter''' Naga Warden
| '''Naga Schildwache''' Naga Sentinel
|
|
|-
|
| '''Naga Wachposten''' Naga Guardian
|
|
|
|
|-
|}

Orc - Under the Burning Suns

{| border="solid"
|
|
| '''Dunkler Mörder''' Dark Assassin
|
|
|
|-
|}

Troll - Under the Burning Suns

{| border="solid"
|
|
| '''Trollschamane''' Troll Shaman
|
|
|
|-
|}

Undead - Under the Burning Suns

{| border="solid"
|
| '''Skelettreiter''' Skeleton Rider
| '''Horrorfledermaus''' Dread Bat
| '''Ätherischer Nachtalb''' Ethereal Nightgaunt
|
|
|-
|
| '''Heimgesuchter''' Haunt
| '''Ätherischer Schatten''' Ethereal Shadow
| '''Ätherisches Spukgespenst''' Ethereal Spectre
|
|
|-
|
| '''Ätherische Geister''' Ethereal Ghost
| '''Ätherischer Rachegeist''' Ethereal Wraith
|
|
|
|-
|
|
| '''Spinnenlich''' Spider Lich
|
|
|
|-
|}

== Rassen und Gruppierungen==
=== Rassen ===
<table>
<tr><td>Drakes</td><td>Draken</td></tr>
<tr><td>Dwarves</td><td>Zwerge</td></tr>
<tr><td>Elves</td><td>Elfen</td></tr>
<tr><td>Goblins</td><td>Kobolde</td></tr>
<tr><td>Humans</td><td>Menschen</td></tr>
<tr><td>Lizards</td><td>Saurianer</td></tr>
<tr><td>Mechanical</td><td>Kriegsgerät</td></tr>
<tr><td>Merman</td><td>Meervolk</td></tr>
<tr><td>Monsters</td><td>Monster</td></tr>
<tr><td>Nagas</td><td>Nagas</td></tr>
<tr><td>Ogres</td><td>Oger</td></tr>
<tr><td>Orcs</td><td>Orks</td></tr>
<tr><td>Trolls</td><td>Trolle</td></tr>
<tr><td>Undead</td><td>Untote</td></tr>
<tr><td>Woses</td><td>Waldschrate</td></tr>
</table>

=== Gruppierungen ===
<table>
<tr><td>Alliance of Darkness</td><td>Allianz der Finsternis</td></tr>
<tr><td>Alliance of Light</td><td>Allianz des Lichtes</td></tr>
<tr><td>Drakes</td><td>Draken</td></tr>
<tr><td>Knalgan Alliance</td><td>Knalgan Allianz</td></tr>
<tr><td>Loyalists</td><td>Loyalisten</td></tr>
<tr><td>Northerners</td><td>Nordmannen</td></tr>
<tr><td>Rebels</td><td>Rebellen</td></tr>
<tr><td>Undead</td><td>Untote</td></tr>
</table>

== Bedeutende Orte ==
Details zur Geographie von Wesnoth sind auf der [[WesnothGeography]] Seite zu finden.
=== Fluss und Meer ===
{|
|Isle of Alduin
|Insel Alduin
|-
|The Three Sisters
|Die Drei Schwestern
|-
|Bay of Pearls
|Perlenbucht
|-
|Arkan-thoria
|Arkan-thoria
|-
|Great River
|Großer Fluss
|-
|The Ford of Abez
|Die Furt von Abez
|-
|The Lake Vrug
|Der Vrugsee
|-
|Island Vrug
|Insel von Vrug
|-
|River Aethen
|Fluss Aethen
|-
|River Weldyn
|Fluss Weldyn
|-
|River Listra
|Fluss Listra
|-
|The Great Ocean
|Der Große Ozean
|-
|Green Isle
|Grüne Insel
|-
|Shimmering Isle
|Glänzende Insel
|}

=== Wälder ===
{|
|Aethenwood
|Aethenwälder
|-
|Lintanir Forest
|Lintanirforst
|-
|Wesmere Forest
|Wesmerewälder
|-
|Grey Woods
|Grauer Wald
|-
|Glyn's Forest
|Glyns Gehölz
|-
|Greenwood
|Grüner Hain
|}

===Gebirge===
{|
|Heart Mountains
|Erzgebirge
|-
|Dulatus Hills
|Dulatushügel
|-
|Estmark Hills
|Ostmarken
|-
|Mountains of Haag
|Haager Berge
|-
|Gryphon Mt.
|Greifenberg
|-
|Mourned Hills
|Trauerhügel
|-
|Mountains of Peril
|Tückische Gipfel
|}

=== Sümpfe ===
{|
|Swamp of Dread
|Sumpf der Furcht
|-
|Bitter Swamp
|Sumpf der Tränen
|-
|Black Marshes
|Schwarzes Moor
|}

=== Städte ===
{|
|Elensefar
|Elensefar
|-
|Blackwater Port
|Schwarzwasser Hafen
|-
|Weldyn
|Weldyn
|-
|Soradoc
|Soradoc
|-
|Spellkeep
|Bannheim
|-
|Dwarves Doors
|Zwergenpforte
|-
|Southbay
|Südbucht
|-
|
|
|}

=== Andere ===
{|
|Horse Plains
|Ebene der Pferde
|-
|Barren Plains
|Karge Steppe
|-
|land of the Clans
|Lande der Sippen
|-
|Northlands
|Nordlande
|-
|Estmark
|Ostmark
|-
|old eastern mines
|alte östliche Mienen
|-
|Midlands
|Mittellande
|-
|the Great Continent
|der Große Kontinent
|}

== Waffen und Gegenstände ==

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

=== Waffenfähigkeiten ===
<table>
<tr><td>backstab</td><td>hinterlistiger Angriff</td></tr>
<tr><td>berserk</td><td>Kampfrausch</td></tr>
<tr><td>charge</td><td>Ansturm</td></tr>
<tr><td>drains</td><td>Lebensentzug</td></tr>
<tr><td>firststrike</td><td>Erstschlag</td></tr>
<tr><td>magical</td><td>magisch</td></tr>
<tr><td>marksman</td><td>Schießkunst</td></tr>
<tr><td>plague</td><td>untote Plage</td></tr>
<tr><td>poison</td><td>vergiften</td></tr>
<tr><td>slows</td><td>verlangsamen</td></tr>
<tr><td>stones</td><td>versteinern</td></tr>
</table>

=== Schadenstypen ===
<table>
<tr><td>arcane</td><td>Arkan</td></tr>
<tr><td>blade</td><td>Klinge</td></tr>
<tr><td>cold</td><td>Kälte</td></tr>
<tr><td>fire</td><td>Feuer</td></tr>
<tr><td>impact</td><td>Wucht</td></tr>
<tr><td>pierce</td><td>Stich</td></tr>
</table>

=== Gegenstände===
<table>
<tr><td>Holy Water</td><td>Weihwasser</td></tr>
<tr><td>Poison</td><td>Gift</td></tr>
<tr><td>Potion of Decay</td><td>Trank des Verfalls</td></tr>
<tr><td>Potion of Healing</td><td>Trank der Heilung</td></tr>
<tr><td>Potion of Strength</td><td>Trank der Stärke</td></tr>
<tr><td>Ring of Regeneration</td><td>Ring der Regeneration</td></tr>
<tr><td>Ring of Power</td><td>Ring der Kraft</td></tr>
<tr><td>Ring of Slowness</td><td>Ring der Langsamkeit</td></tr>
<tr><td>Staff of Swiftness</td><td>Stab der Geschwindigkeit</td></tr>
<tr><td>Storm Trident</td><td>Dreizack des Sturms</td></tr>
<tr><td>Staff of righteous Flame</td><td>Stab der aufflammenden Gerechtigkeit</td></tr>
<tr><td>Rod of Justice</td><td>Stab der Gerechtigkeit </td></tr>
</table>

== Charakteristiken, Fertigkeiten, Zustände ==

=== Charakteristiken ===
<table>
<tr><td>aged</td><td>betagt</td></tr>
<tr><td>dextrous</td><td>treffsicher</td></tr>
<tr><td>elemental</td><td>elementar</td></tr>
<tr><td>fearless</td><td>furchtlos</td></tr>
<tr><td>feral</td><td>wild</td></tr>
<tr><td>healthy</td><td>vital</td></tr>
<tr><td>intelligent</td><td>intelligent</td></tr>
<tr><td>loyal</td><td>loyal</td></tr>
<tr><td>mechanical</td><td>Kriegsgerät</td></tr>
<tr><td>quick</td><td>schnell</td></tr>
<tr><td>resilient</td><td>robust</td></tr>
<tr><td>strong</td><td>kräftig</td></tr>
<tr><td>undead</td><td>untot</td></tr>
</table>

=== Fertigkeiten ===
<table>
<tr><td>ambush</td><td>Waldkenntnis</td></tr>
<tr><td>cures</td><td>Kurieren</td></tr>
<tr><td>concealment</td><td>Gassenwissen</td></tr>
<tr><td>heals +X</td><td>Heilen +X</td></tr>
<tr><td>illuminates</td><td>Lichtaura</td></tr>
<tr><td>leadership</td><td>Führungsqualitäten</td></tr>
<tr><td>nightstalk</td><td>Schemen</td></tr>
<tr><td>regenerates</td><td>Regeneration</td></tr>
<tr><td>skirmisher</td><td>Plänkler</td></tr>
<tr><td>steadfast</td><td>Unerschütterlich</td></tr>
<tr><td>submerge</td><td>Abtauchen</td></tr>
<tr><td>teleport</td><td>Teleportation</td></tr>
</table>

== weitere gebräuchliche Formulierungen ==

=== Missionsziele ===
{|
|Death of X
|X fällt in der Schlacht
|-
|Turns run out
|Rundenlimit überschritten
|-
|Defeat all enemy leaders
|Besiegt alle gegnerischen Anführer
|-
|Move X to the signpost in the Y
|Führt X zum Wegweiser im Y
|-
|Early finish bonus
|Bonus für frühzeitiges Ende
|-
|Alternative objective
|Alternatives Missionsziel
|-
|Bonus objective
|Bonusziel
|}

=== Schwierigkeitsgrade ===
<table>
<tr><td>(Novice level, XX scenarios.)</td><td>(Einstufung: Einfach, XX Szenarien)</td></tr>
<tr><td>(Intermediate level, XX scenarios.)</td><td>(Einstufung: Mittel, XX Szenarien)</td></tr>
<tr><td>(Expert level, XX scenarios.)</td><td>(Einstufung: Schwierig, XX Szenarien)</td></tr>
<tr><td>(Beginner)</td><td>(Sehr einfach)</td></tr>
<tr><td>(Easy)</td><td>(Einfach)</td></tr>
<tr><td>(Normal)</td><td>(Normal)</td></tr>
<tr><td>(Challenging)</td><td>(Herausfordernd)</td></tr>
<tr><td>(Difficult)</td><td>(Schwierig)</td></tr>
<tr><td>(Nightmare)</td><td>(Alptraum)</td></tr>
</table>

=== Credits ===
<table>
<tr><td>And special thanks to everyone else who I forgot to mention.</td><td>Und besonderen Dank an alle, die ich vergessen habe, zu erwähnen.</td></tr>
<tr><td>Artwork and Graphics Design</td><td>Grafik</td></tr>
<tr><td>Campaign Design</td><td>Kampagnengestaltung</td></tr>
<tr><td>Campaign Epilog and Continuity</td><td>Kampagnenepilog und -fortsetzung</td></tr>
<tr><td>Campaign Maintenance</td><td>Betreuung</td></tr>
<tr><td>Code and Translation Assistance</td><td>Programmierungs- und Übersetzungshilfe</td></tr>
<tr><td>Completion and Maintenance</td><td>Fertigstellung und Betreuung</td></tr>
<tr><td>Conception and Original Design</td><td>Konzeption</td></tr>
<tr><td>Current Maintainer</td><td>Betreuung</td></tr>
<tr><td>Miscellaneous</td><td>Verschiedenes</td></tr>
<tr><td>Music Development</td><td>Musikkomposition</td></tr>
<tr><td>Prose, Grammatical and WML Assistance</td><td>Sprach- und WML-Hilfe</td></tr>
<tr><td>Translators</td><td>Übersetzung</td></tr>
<tr><td>WML Assistance</td><td>WML-Entwicklung</td></tr>
<tr><td>WML Contributors</td><td>WML-Entwicklung</td></tr>
</table>

=== Sonstiges ===
<table>
<tr><td>(whispered)</td><td>(Geflüstert)</td></tr>
<tr><td>Minister</td><td>Vater, Bruder (im priesterlichen Sinne)</td></tr>
<tr><td>Whiteboard</td><td>Reißbrett</td></tr>
<tr><td>Multiplayerlobby</td><td>Mehrspielerlobby</td></tr>
<tr><td></td><td></td></tr>
<tr><td></td><td></td></tr>
<tr><td></td><td></td></tr>
</table>

Objektbezug als Übersetzungshilfe - das Dach"^": Bsp: "rod of justice^Take it!": Der zu übersetzende String heisst eigentlich nur "Take it" - aber der Bezug von "it" bliebe dann unklar. Der Kampagnenprogrammierer spezifiziert also, dass sich "it" auf "rod of justice" bezieht. In der Übersetzung wird alles vor dem "^" ignoriert. Die Übersetzung könnte also sein: "Schnapp dir das Ding!".

== Siehe auch ==

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

[[Category:Translations]]

MapLocalization

2014-06-15T23:09:47Z

Aquileia: Add comment about layer groups

'''This page is a work in progress'''

Like the old maps, the new-style maps can be localized, but the intended method for doing so is quite different.

=== Overview ===

However, the workflow for localizing a map is simple: you create an image which contains the localized labels on a transparent background as simple text, no post-processing effects needed. In GIMP, you then add that image to a corresponding .xcf file as a new layer, and run a script. The script creates an overlay image which covers up the english labels, adds your localized labels and applies a bunch of post-processing effects to them in order to make them look identical to the english labels. All you need to do is to check the output and save.

=== Step-by-step instructions ===

==== Preparations ====

1. If you don't have GIMP, install it.

2. Download the [https://github.com/wesnoth/resources/tree/master/image-localization/maps/wesnoth-map-localization.scm wesnoth-map-localization.scm script] and place it into a script directory recognized by GIMP. You can view and configure the script directories in GIMP's preferences (Preferences -> Folders -> Scripts). If you already have GIMP running, you need to use '''Filters -> Script-Fu -> Refresh Scripts''' to make it recognize the newly added script. In the Filters menu, you should now see a filter category called "Wesnoth", and inside it "Map Localization". However, we don't need it yet.

3. Download the [https://github.com/wesnoth/resources/tree/master/image-localization/maps/ localization.xcf for the map you're localizing].

Now you're all set to begin.

==== Localization ====

# Open the localization.xcf you've downloaded. It contains a bunch of layers needed by the localization script, but at this point all you need is the layer called "label placement guide". It's a version of the map without any perspective or displacement effects added, and it is the one onto which you need to place the localized layers.
# Create a new layer which includes the localized labels, positioning them using the aforementioned layer as a guide. The positions or orientation or curving of the labels does not need to match the english labels in any way. Place them in a way which you think looks good. The requirements for the labels are simple: black text should be pure black, whereas yellow labels on forests should have the RGB value 185,155,85. The script gives you a little bit of leeway so you don't have to stress over very small color deviations, but don't do it intentionally. Background should be transparent. ''Note that you can use whatever graphics application you want in creating your labels, as long as you can import the result into GIMP so that it meets the above requirements.'' 
# Add the layer containing your localized text into the same localization.xcf file and name it "labels". Don't mess with the other layers.
# If ''labels'' and ''label placement guide'' are layer groups, merge them down to single layers. Notice as well that these have to begin with a lowercase l for the script to work.
# Run the script by choosing Filters -> Wesnoth -> Map Localization. The script will create a new image, and produce the output there. This will take a moment, perhaps as much as a minute or more on a slow computer, and for a few seconds it might seem like nothing is happening.
# You should now have a new image with a single layer called "localized overlay". Inspect that everything's ok by adding the original english map as a new layer underneath the overlay; the english labels should be covered up, the localized labels in place and there should be no glitches anywhere. Export the image to PNG (just remember to hide/delete the english map layer first!) and you're done. In the PNG export dialog, uncheck the option "Save color values from transparent pixels" to get the file of expected size (~100-300 KiB; if the option is not unchecked, it is over 2 MiB).

===== Final notes =====

If there are labels which you don't need to localize, then first of all, don't bother including them among your localized labels. Then, once you've generated the final overlay, simply erase the parts which cover up the original english label.

The script works if and only if the labels layer contains both black and golden pixels.

===== Text sizing =====

These are the text sizing rules that have been used on the english maps. Depending on your language, you may want to break some of them.

Major geographical features or other large areas which extend beyond the map edges (including forests): 28px small caps, tracking ~200.
''Note that these are font sizes for Photoshop. GIMP has slightly different text tools and does not have small caps effect. Small caps effect can be reproduced by using caps with 30px for the first letter and 20px bold for the remaining letters. You might also need to make all text bold in Gimp so it will be legible. The corresponding font tracking in GIMP is 5.0.''

Large geographical features: 22px normal or small caps.

Minor geographical features: 18px normal.

Major rivers: 20px, tracking ~200.

Small rivers: 18px, tracking ~200. For names like "R. Weldyn", note that periods are very small in Monotype Corsiva and get very close to the preceding R; I suggest giving the . a size of 24-30px and removing the following space. Other solutions can work too.

Capital cities: 24px normal.

Other major cities: 20px normal.

Small cities: 16px normal. You might need to increase this to 18px for legibility.

Large forests: 24px normal.

Small forests: 18px normal.

===== Text orientation and curving =====

In the english maps, names of large geographical areas and rivers are often curved. River names usually follow the shape of the river, and names of large features such as "Heart Mountains" are curved to roughly match the shape of said feature.

All of the above is optional. You do not need to match the english labels in shape and location. If for some reason you need to, you can even omit some labels or add completely new ones.

===== Title screen map =====

The title screen map is identical with the ''Heir to the Throne'' campaign map. Localize the map for ''Heir to the Throne'', create a copy of the overlay and rename it to 'titlescreen--overlay.png', then place it in ''\data\core\images\maps\l10n\<language iso code>'' and you're done.

[[Category:Translations]]

MapLocalization

2014-06-13T13:08:04Z

Aquileia: resources is now a separate repo

'''This page is a work in progress'''

Like the old maps, the new-style maps can be localized, but the intended method for doing so is quite different.

=== Overview ===

However, the workflow for localizing a map is simple: you create an image which contains the localized labels on a transparent background as simple text, no post-processing effects needed. In GIMP, you then add that image to a corresponding .xcf file as a new layer, and run a script. The script creates an overlay image which covers up the english labels, adds your localized labels and applies a bunch of post-processing effects to them in order to make them look identical to the english labels. All you need to do is to check the output and save.

=== Step-by-step instructions ===

==== Preparations ====

1. If you don't have GIMP, install it.

2. Download the [https://github.com/wesnoth/resources/tree/master/image-localization/maps/wesnoth-map-localization.scm wesnoth-map-localization.scm script] and place it into a script directory recognized by GIMP. You can view and configure the script directories in GIMP's preferences (Preferences -> Folders -> Scripts). If you already have GIMP running, you need to use '''Filters -> Script-Fu -> Refresh Scripts''' to make it recognize the newly added script. In the Filters menu, you should now see a filter category called "Wesnoth", and inside it "Map Localization". However, we don't need it yet.

3. Download the [https://github.com/wesnoth/resources/tree/master/image-localization/maps/ localization.xcf for the map you're localizing].

Now you're all set to begin.

==== Localization ====

1. Open the localization.xcf you've downloaded. It contains a bunch of layers needed by the localization script, but at this point all you need is the layer called "label placement guide". It's a version of the map without any perspective or displacement effects added, and it is the one onto which you need to place the localized layers.

2. Create a new layer which includes the localized labels, positioning them using the aforementioned layer as a guide. The positions or orientation or curving of the labels does not need to match the english labels in any way. Place them in a way which you think looks good.

The requirements for the labels are simple: black text should be pure black, whereas yellow labels on forests should have the RGB value 185,155,85. The script gives you a little bit of leeway so you don't have to stress over very small color deviations, but don't do it intentionally. Background should be transparent.

''Note that you can use whatever graphics application you want in creating your labels, as long as you can import the result into GIMP so that it meets the above requirements.''

3. Add the layer containing your localized text into the same localization.xcf file and name it "labels". Don't mess with the other layers.

4. Run the script by choosing Filters -> Wesnoth -> Map Localization. The script will create a new image, and produce the output there. This will take a moment, perhaps as much as a minute or more on a slow computer, and for a few seconds it might seem like nothing is happening.

5. You should now have a new image with a single layer called "localized overlay". Inspect that everything's ok by adding the original english map as a new layer underneath the overlay; the english labels should be covered up, the localized labels in place and there should be no glitches anywhere. Export the image to PNG (just remember to hide/delete the english map layer first!) and you're done. In the PNG export dialog, uncheck the option "Save color values from transparent pixels" to get the file of expected size (~100-300 KiB; if the option is not unchecked, it is over 2 MiB).

===== Final notes =====

If there are labels which you don't need to localize, then first of all, don't bother including them among your localized labels. Then, once you've generated the final overlay, simply erase the parts which cover up the original english label.

The script works if and only if the labels layer contains both black and golden pixels.

===== Text sizing =====

These are the text sizing rules that have been used on the english maps. Depending on your language, you may want to break some of them.

Major geographical features or other large areas which extend beyond the map edges (including forests): 28px small caps, tracking ~200.
''Note that these are font sizes for Photoshop. GIMP has slightly different text tools and does not have small caps effect. Small caps effect can be reproduced by using caps with 30px for the first letter and 20px bold for the remaining letters. You might also need to make all text bold in Gimp so it will be legible. The corresponding font tracking in GIMP is 5.0.''

Large geographical features: 22px normal or small caps.

Minor geographical features: 18px normal.

Major rivers: 20px, tracking ~200.

Small rivers: 18px, tracking ~200. For names like "R. Weldyn", note that periods are very small in Monotype Corsiva and get very close to the preceding R; I suggest giving the . a size of 24-30px and removing the following space. Other solutions can work too.

Capital cities: 24px normal.

Other major cities: 20px normal.

Small cities: 16px normal. You might need to increase this to 18px for legibility.

Large forests: 24px normal.

Small forests: 18px normal.

===== Text orientation and curving =====

In the english maps, names of large geographical areas and rivers are often curved. River names usually follow the shape of the river, and names of large features such as "Heart Mountains" are curved to roughly match the shape of said feature.

All of the above is optional. You do not need to match the english labels in shape and location. If for some reason you need to, you can even omit some labels or add completely new ones.

===== Title screen map =====

The title screen map is identical with the ''Heir to the Throne'' campaign map. Localize the map for ''Heir to the Throne'', create a copy of the overlay and rename it to 'titlescreen--overlay.png', then place it in ''\data\core\images\maps\l10n\<language iso code>'' and you're done.

[[Category:Translations]]

Micro AIs

2014-05-23T15:54:11Z

Aquileia: Fix typo

Micro AIs allow Wesnoth campaign and scenario authors to add new AI functionality without the need for any AI programming. A Micro AI is activated and configured (or deleted) via the [micro_ai] tag, requiring only a few lines of WML code. Note that this is a new functionality and theat '''[http://forums.wesnoth.org/viewtopic.php?f=10&t=39456 we are very much looking for feedback]''' on bugs, new feature requests for the existing AIs or ideas for new Micro AIs.

Micro AIs are available in mainline Wesnoth '''starting from Version 1.11.2'''.

'''''This page only contains instructions for Wesnoth 1.11.7 and later any more.''''' See [[Micro_AIs#A_Few_General_Words_about_Micro_AIs|below]] for details.

== A Few General Words about Micro AIs ==

* '''''This page only contains instructions for Wesnoth 1.11.7 and later any more'''''
** The Micro AIs have gone through so many changes since their introduction in Wesnoth 1.11.2 that this page was becoming too cluttered with all the version history.
** If you are using an earlier Wesnoth version, check out this wiki page's history. Information about versions 1.11.2 - 1.11.6 was removed on 15 November 2013.
** If you are adapting Micro AI code from a version earlier than 1.11.7, in particular '''code containing the now removed RCA_STAGE macro''', the first step is to remove the entire [ai] tag from the [side] definition, as [[Micro_AIs#Setting_up_a_Micro_AI|only the [micro_ai] tag is required]] now with no need for an engine definition in the [side] tag.

* Micro AIs are meant to bring new specialized behavior to Wesnoth that cannot be achieved, at least not easily, by adjusting default AI parameters (such as those described at [[AiWML]]) or with WML code.

* The '''default AI aspects are, for the most part, not taken into account by the Micro AIs'''. For example, unless noted otherwise, specifying a value for 'aggression' does not change the MAI behavior, and locations specified in an '[avoid]' tag generally can be entered by units controlled by an MAI. This is a feature of the Micro AIs, not a bug. If you feel that a certain default AI aspect should also apply to a Micro AI, please let us know in the [http://forums.wesnoth.org/viewtopic.php?f=10&t=39456 Micro AIs Feedback thread].

* Most Micro AIs in their default setting apply to all units of a side, although many of them provide parameters for filtering the units that should be affected by the new behavior. If the Micro AI is applied only to part of the units of a side, the other units follow the default Wesnoth AI behavior.

=== Micro AI Test and Demo Scenarios ===

All Micro AIs described here can be checked out in a number of test and demo scenarios. Test scenarios can be accessed from the command line by typing
path/wesnoth-executable -t micro_ai_test
This starts up a "switchboard scenario" in which you can select the Micro AI demonstration scenario you want to check out. Here, ''path/wesnoth-executable'' needs to be replaced by whatever the path and filename of the Wesnoth executable is on your system.

== Setting up a Micro AI ==

Setting up a Micro AI requires only one simple step:
==== 1. Activating and configuring (or deleting) a Micro AI ====

Micro AIs are activated, deleted and configured using the [micro_ai] tag. This tag needs to be placed in [[ActionWML]], that is, in an event, a menu option or the like. As an example, the following code activates the healer_support Micro AI in its default configuration for Side 2 from the beginning of the scenario:
[event]
name=prestart

# Configure the healer support micro AI
[micro_ai]
side=2
ai_type=healer_support
action=add
[/micro_ai]
[/event]
'''Keys required for all Micro AIs:'''
All [micro_ai] tags must contain the following three required keys:
* '''side''': The side for which the Micro AI is to be added, changed or deleted. This has to be an individual side number, lists of sides are not supported.
* '''ai_type''': The type of Micro AI to be added, changed or deleted. See the following sections for allowed values.
* '''action''' (string): The action to take concerning the Micro AI. The following values are allowed:
** ''add'': Add a Micro AI to a side.
** ''change'': Change the configuration of an existing Micro AI. Note that this does not only change the specific parameters provided in the tag, but it replaces the entire existing Micro AI by a new version with the new (and only the new) configuration. It is therefore equivalent to using first the ''delete'' and then the ''add'' action.
** ''delete'': Delete an existing Micro AI from a side.

'''Keys required under certain circumstances:'''
* '''ca_id''': (string) If several MAIs of the same type are used for the same side and one or several of these are to be changed or deleted during a scenario, this key needs to be included so that the [micro_ai] tag knows which of them needs to be changed/deleted. Notes:
** The id(s)/name(s) actually assigned to the CA(s) of the MAI by the engine might be different from the parameter passed here. It is, however, sufficient to use this ca_id with the [micro_ai] tag add/delete/change actions to identify the MAI uniquely. (In other words: you don't have to worry about this if you always use the [micro_ai] tag, but might have to figure out the actual name(s) of the CA(s) if you want to delete or change them manually.)
* Other keys may also be required depending on the Micro AI. In additional, a number of optional keys may be available to configure the AI behavior. See the sections on the individual Micro AIs for details.

'''Required keys for deleting a Micro AI:'''

Only a subset of the keys required for setting up a Micro AI are needed when deleting it. '''side''', '''ai_type''' and '''action'''=delete always need to be provided. '''ca_id''' needs to be given if it was provided when setting up the Micro AI.

'''Notes:'''
* The ''add'' and ''change'' actions ignore all keys that do not apply to the respective Micro AI type. The ''delete'' action ignores all keys other than the required keys listed above.

* Some of the Micro AIs use and/or modify default AI components (candidate actions or aspects) when they are added, or reset these components to their default values when they are deleted. Thus, if you have modified the AI yourself using the default CAs or aspects, some of these modifications might be affected, or might be interfering with the Micro AI. The sections below indicate whether a Micro AI modifies any default AI components.

===Combining Different Micro AI Types for the Same Side===

No extra steps need to be taken when combining different Micro AIs on the same side. Simply set up the [micro_ai] tags for all AIs you want to use.

'''Notes:'''
* While it is ''technically'' possible to combine any number of Micro AIs, this does not mean that all Micro AIs work together in practice. Some are not compatible because they control units in contradictory ways.
* Not all combinations that ''should'' work have been tested yet. If you find a combination that you believe should work but doesn't, [http://forums.wesnoth.org/viewtopic.php?f=10&t=39456 please let us know] and we will see if that can be fixed.
* The candidate action score almost certainly has to be set (using the ca_score= key) for one or several of the MAIs if several of them are used on the same side.

== Animals Micro AIs ==
=== General Comments on the Animal Micro AIs ===

The Animals Micro AIs are meant to simulate the behaviors of certain types of animals. They are, however, set up so that they can be used with arbitrary unit types and might be applicable in quite diverse situations. The AIs nevertheless remain named after the animals for which they were written originally, so that they are (to some extent) descriptive of their behavior.

Brief descriptions of the AI behaviors are given in the following subsections. To get a better feeling for their behavior, check out the "Animals", "Swarm", "Wolves" and "Dragon" scenarios from the [[Micro_AIs#Micro_AI_Test_and_Demo_Scenarios|test scenario]]. Note that some of the animal AIs are designed for animal types that do not exist in mainline. In the test scenario, other animal types are therefore substituted for them.

=== Animals AI: Wolves (ai_type=wolves) ===

The Wolves Micro AI organizes all "wolf" units (predators) of the side to hunt in a single pack. They actively chase after the closest prey and try to corner it (not always super successfully), but are easily distracted by other enemy units coming into attack range, to the point where the pack might split up. The wolves can, however, be told to attack only prey units as well as to try to avoid other types of units (such as larger predators). When no prey is left, the wolves wander randomly.

This AI works best for a small number of predators (2 - 5) and sparse prey. Also, the predators should be put on the map in a pack, that is, reasonably close to each other. For a demonstration of the Wolves AI behavior, check out the "Animals" scenario from the [[Micro_AIs#Micro_AI_Test_and_Demo_Scenarios|test scenario]].

Note that another wolves AI exists, called [[Micro_AIs#Animals_AI:_Multi-pack_Wolves_.28ai_type.3Dwolves_multipacks.29|Multipack Wolves]], which distributes the wolves of a side into several packs, rather than all of them into one single pack as it is done here.

Enable the Wolves Micro AI by using
ai_type=wolves
in the [micro_ai] tag together with the following keys:

'''Required keys:'''

* '''[filter]''': A [[StandardUnitFilter|Standard Unit Filter]] selecting the predator units. The filter automatically includes the side= key set to the AI side.
* '''[filter_second]''': A [[StandardUnitFilter|Standard Unit Filter]] selecting the prey units. The filter automatically includes a [[StandardSideFilter|Standard Side Filter]] set to all enemies of the AI side.

'''Optional keys:'''

* '''attack_only_prey'''=no: In the default configuration, the wolves attack all enemy units in attack range. If this key is set to 'yes', they only attack prey units.
* '''avoid_type''': Comma-separated list of unit types (on enemy sides) which the wolves try to avoid. They try to stay out of these units' way as much as possible when moving around (except when they are moving in to attack another enemy unit) and never attack them.
* '''ca_score'''=90000: (non-negative integer) The evaluation score of the candidate actions controlling this Micro AI. By default, it is set to 90,000, which is lower than the default combat CA, but higher than most other default CAs which move units. It can be changed by setting this parameter but in most cases this will not make sense. Note that the Wolves AI consists of 2 CAs with scores ranging from <tt>ca_score-1</tt> to <tt>ca_score</tt>.

'''Note:''' Depending on the parameters chosen, the Wolves Micro AI might modify the [[AiWML#Filtering_Combat_with_the_.27attacks.27_Aspect|attacks aspect]].

Here's an example of a wolves [micro_ai] tag usage from the "Animals" [[Micro_AIs#Micro_AI_Test_and_Demo_Scenarios|test scenario]]:
[micro_ai]
side=6
ai_type=wolves
action=add

[filter]
type=Wolf
[/filter]
[filter_second]
type=Vampire Bat
[/filter_second]
avoid_type=Yeti,Giant Spider,Ghast,Footpad
[/micro_ai]

=== Animals AI: Multi-pack Wolves (ai_type=wolves_multipacks) ===

The Multi-pack Wolves Micro AI is different from the [[Micro_AIs#Animals_AI:_Wolves_.28ai_type.3Dwolves.29|Wolves Micro AI]] in that there can be an arbitrary number of wolf packs, with the pack size being a free parameter. At the beginning of the scenario, close wolves are grouped into packs in a semi-methodical way. If the wolves are put on the map in distinct groups of close wolves of the correct number, they will be joined into packs matching these groups. If, on the other hand, they are spread out all over the map, the method of assigning them to packs is semi-random.

Wolves of the same pack begin by joining each other on the map. After that, they stay together until only one wolf is left, which then tries to join up with an incomplete pack or with other single wolves. Individual wolves entering the map during the scenario behave in that way as well.

A second difference to the other Wolves AI is that wolves do not actively hunt here. For the most part they just wander (often long distance). However, the pack ferociously (and without regard for its own health) attacks any enemy units that come into range, as long as that does not mean separating the pack by more than a few hexes. Staying together, or joining with a new wolf assigned to the pack, is the only thing that takes priority over satisfying the wolves' thirst for blood.

For a demonstration of the Multi-pack Wolves AI behavior, check out the "Wolves" scenario from the [[Micro_AIs#Micro_AI_Test_and_Demo_Scenarios|test scenario]].

Enable the Multi-pack Wolves Micro AI by using
ai_type=wolves_multipacks
in the [micro_ai] tag together with the following keys:

'''Required keys:'''

There are no required keys

'''Optional keys:'''

* '''ca_score'''=300000: (non-negative integer) The evaluation score of the candidate actions controlling this Micro AI. By default, it is set to 300,000, which is higher than any of the [http://wiki.wesnoth.org/AiWML#Evaluating_AI_Moves_--_Candidate_Actions_.28CAs.29 RCA AI candidate actions]. By setting it, for example, to 170,000, we can have it be executed after the default recruitment CA, but before most of the other default CAs. Note that the Multi-pack Wolves AI consists of 2 CAs with scores ranging from <tt>ca_score-1</tt> to <tt>ca_score</tt>.
* '''pack_size'''=3: (integer) The size of the packs.
* '''show_pack_number'''=no: If set to "yes", the wolves' pack numbers will be shown below them. Note that this means that the pack number of a wolf killed in an attack will remain as a label on the map.
* '''type'''=Wolf: Comma-separated list of the unit types which the AI controls. The default value is "Wolf".

Here's an example of a wolves_multipacks [micro_ai] tag usage from the "Wolves" [[Micro_AIs#Micro_AI_Test_and_Demo_Scenarios|test scenario]]:
[micro_ai]
side=2
ai_type=wolves_multipacks
action=add

show_pack_number=yes
pack_size=4
[/micro_ai]

=== Animals AI: Big Animals (ai_type=big_animals) ===

The Big Animals Micro AI is a simulation of large predators that wander and hunt alone, such as Bears, Giant Spiders or Yetis. For the most part, these just wander on the terrain that's been defined for them, but they attack enemy units if those happen to come into range. The AI can be set up so that the Big Animals stay out of the way of other units (such as other large predators), in which case they only attack those if cornered.

For a demonstration of the Big Animals AI behavior, check out the "Animals" scenario from the [[Micro_AIs#Micro_AI_Test_and_Demo_Scenarios|test scenario]].

Enable the Big Animals Micro AI by using
ai_type=big_animals
in the [micro_ai] tag together with the following keys:

'''Required keys:'''

* '''[filter]''': A [[StandardUnitFilter|Standard Unit Filter]] selecting the animals to which this AI is applied. The filter automatically includes the side= key set to the AI side.

'''Optional keys:'''

* '''ca_score'''=300000: (non-negative integer) The evaluation score of the candidate action controlling this Micro AI. By default, it is set to 300,000, which is higher than any of the [http://wiki.wesnoth.org/AiWML#Evaluating_AI_Moves_--_Candidate_Actions_.28CAs.29 RCA AI candidate actions]. By setting it, for example, to 170,000, we can have it be executed after the default recruitment CA, but before most of the other default CAs.
* '''[filter_location]''': The big animals often go for long distance (multi-turn) journeys. This tag is a [[StandardLocationFilter|Standard Location Filter]] describing the terrain from which the next goal is chosen. The default is all terrain on the map.
* '''[filter_location_wander]''': The terrain on which the big animals will end their moves. This is a [[StandardLocationFilter|Standard Location Filter]]. The default is all terrain on the map.
* '''[avoid_unit]''': A [[StandardUnitFilter|Standard Unit Filter]] describing all enemy units that the big animals will avoid. The filter automatically includes a [[StandardSideFilter|Standard Side Filter]] set to all enemies of the AI side.

Here's an example of big_animals [micro_ai] tag usage from the "Animals" [[Micro_AIs#Micro_AI_Test_and_Demo_Scenarios|test scenario]]:
[micro_ai]
side=3
ai_type=big_animals
action=add

[filter]
type=Ghast
[/filter]
[avoid_unit]
type=Yeti,Giant Spider,Ghast,Footpad
[/avoid_unit]
[filter_location]
x,y=1-40,1-18
[/filter_location]
[/micro_ai]

=== Animals AI: Forest Animals (ai_type=forest_animals) ===

The Forest Animals Micro AI simulates a number of different animal behaviors that one might find in a forest, namely animals behaving like deer, rabbits and families of tuskers. In the following, we will refer to those animals by these types, even though the actual unit types can be selected freely. They behave as follows:
* Each deer wanders randomly on (selectable) terrain, except when enemies get in its (the deer's) maximum movement range, in which case it flees to the farthest point it can reach.
* Tuskers exhibit the same behavior as deer, except when an enemy is next to one of the tusklets. This enemy is attacked unconditionally by the tuskers trying to protect their young.
* Tusklets blindly follow the closest adult tusker, except when there is no tusker left, in which case they behave the same as deer.
* Rabbits also wander randomly, but in addition disappear into their holes (if any are within reach) when enemies are close. They reappear out of their holes at the beginning of the turn, if it is safe.

For a demonstration of the Forest Animals AI behavior, check out the "Animals" scenario from the [[Micro_AIs#Micro_AI_Test_and_Demo_Scenarios|test scenario]].

Enable the Forest Animals Micro AI by using
ai_type=forest_animals
in the [micro_ai] tag together with the following keys:

'''Required keys:'''

There are no required keys

'''Optional keys:'''

* '''ca_score'''=300000: (non-negative integer) The evaluation score of the candidate actions controlling this Micro AI. By default, it is set to 300,000, which is higher than any of the [http://wiki.wesnoth.org/AiWML#Evaluating_AI_Moves_--_Candidate_Actions_.28CAs.29 RCA AI candidate actions]. By setting it, for example, to 170,000, we can have it be executed after the default recruitment CA, but before most of the other default CAs. Note that the Forest Animals AI consists of 4 CAs with scores ranging from <tt>ca_score-3</tt> to <tt>ca_score</tt>.
* '''rabbit_type, tusker_type, tusklet_type, deer_type''': Comma-separated lists of the unit types behaving as the respective animals. If any of these parameters are not set, those types of animal behavior are skipped by the AI.
* '''[filter_location]''': A [[StandardLocationFilter|Standard Location Filter]] describing the terrain on which the forest animals wander when they are not threatened by enemies.
* '''rabbit_number'''=6: (integer) The number of rabbits for the AI to have on the map simultaneously. The AI puts the missing number of rabbits onto the map at the beginning of the AI's turn (when the rabbits come out of their holes).
* '''rabbit_enemy_distance'''=3: (number) Rabbits won't spawn in holes that aren't more than this distance away from all enemies.
* '''rabbit_hole_img''': Rabbit holes are marked by items on the map. If this parameter is set, it must be the file name of the item image. If it is not set, all items on the map are treated as rabbit holes.

Here's an example of forest_animals [micro_ai] tag usage from the "Animals" [[Micro_AIs#Micro_AI_Test_and_Demo_Scenarios|test scenario]]:
[micro_ai]
side=2
ai_type=forest_animals
action=add

deer_type=Vampire Bat
rabbit_type=Giant Rat
tusker_type=Ogre
tusklet_type=Young Ogre
[filter_location]
terrain=*^F*
[/filter_location]
[/micro_ai]

=== Animals AI: Herd and Herders (ai_type=herding) ===

The Herding Micro AI sets up an area on the map where a number of herder units (such as sheep dog) control and protect a herd (such as sheep). For convenience, we simply refer to them as sheep dogs and sheep in the following, even though arbitrary unit types can be selected for either.

Sheep dogs try to keep their sheep safe. This involves keeping them inside the herding area, positioning themselves in between the sheep and approaching enemies, and attacking the enemies if those get too close. If no active herding or protecting move is needed, the dogs go to a random location on the perimeter of the herding area.

Sheep wander aimlessly except when a sheep dog is next to them, in which case they run away from the dog. The dogs exploit this by positioning themselves on the outside of the sheep, if possible. Sheep also run away from approaching enemies.

For a demonstration of the Herding AI behavior, check out the "Animals" scenario from the [[Micro_AIs#Micro_AI_Test_and_Demo_Scenarios|test scenario]].

Enable the Herding Micro AI by using
ai_type=herding
in the [micro_ai] tag together with the following keys:

'''Required keys:'''

* '''[filter]''': A [[StandardUnitFilter|Standard Unit Filter]] describing the herder units (e.g. dogs). The filter automatically includes the side= key set to the AI side.
* '''[filter_second]''': A [[StandardUnitFilter|Standard Unit Filter]] describing the herd units (e.g. sheep). The filter automatically includes the side= key set to the AI side.
* '''[filter_location]''': A [[StandardLocationFilter|Standard Location Filter]] describing the terrain forming the perimeter of the herding area. In other words, this is the path the herders (dogs) use to patrol around the outside of the herding area. This must be a set of coordinates ''completely enclosing'' the herding area. Here's an example of setting up a rectangular perimeter:
[filter_location]
x=10-20,10-20,10, ,20
y=11, 21, 11-21,11-21
[/filter_location]
Another possibility is by defining the path by certain terrain on the map (as it is done in the "Animals" [[Micro_AIs#Micro_AI_Test_and_Demo_Scenarios|test scenario]]), in which case the filter can simply look like this:
[filter_location]
terrain=Rb
[/filter_location]
* '''herd_x,herd_y''': The coordinate of one hex (''any'' one hex) inside the herding area. This is needed to define which part of the map is on the ''inside'' of the herding area perimeter defined by [herding_perimeter], and which is the ''outside''.

'''Optional keys:'''
* '''attention_distance'''=8: (integer) If an enemy is within this distance of a herd unit, but not as close as ''attack_distance'', the herders try to position themselves in between the enemy and the herd unit.
* '''attack_distance'''=4: (integer) If an enemy is within this distance of a herd animal, the herders attack this enemy.
* '''ca_score'''=300000: (non-negative integer) The evaluation score of the candidate actions controlling this Micro AI. By default, it is set to 300,000, which is higher than any of the [http://wiki.wesnoth.org/AiWML#Evaluating_AI_Moves_--_Candidate_Actions_.28CAs.29 RCA AI candidate actions]. By setting it, for example, to 170,000, we can have it be executed after the default recruitment CA, but before most of the other default CAs. Note that the Herding AI consists of 6 CAs with scores ranging from <tt>ca_score-5</tt> to <tt>ca_score</tt>.

Here's an example of a Herding [micro_ai] tag usage from the "Animals" [[Micro_AIs#Micro_AI_Test_and_Demo_Scenarios|test scenario]]:
[micro_ai]
side=7
ai_type=herding
action=add

[filter]
type=Footpad
[/filter]
[filter_second]
type=Troll Whelp
[/filter_second]
herd_x,herd_y=32,28
[filter_location]
terrain=Rb
[/filter_location]
[/micro_ai]

=== Animals AI: Hunter (ai_type=hunter) ===

The Hunter Micro AI leads a unit (or units) through hunt-and-rest cycles. The units wander in a prescribed area of the map, their hunting ground, until an enemy unit comes within range. Note that the units do not actively chase down enemies, but wander randomly through the hunting ground until an enemy is encountered.

If enemies are within range of a hunter unit, the hunter attacks the weakest of them. If a kill is made, it then retreats to its rest location, where it stays for a certain number of turns and until fully healed (whatever happens later).

A few more details:
* If the hunter's way home is entirely blocked on the return (so that there is no possible path), the normal RCA AI takes over its behavior.
* However, if the way is blocked by an enemy unit occupying the rest hex, that enemy will be attacked unconditionally.
* A kill only makes the hunter go home when it is the attacker, not as defender.

For a demonstration of the Hunter AI behavior, check out the "Dragon" scenario from the [[Micro_AIs#Micro_AI_Test_and_Demo_Scenarios|test scenario]].

Enable the Hunter Micro AI by using
ai_type=hunter
in the [micro_ai] tag together with the following keys:

'''Required keys:'''

* '''id''' or '''[filter]''': The ID of a unit or a [[StandardUnitFilter|Standard Unit Filter]] selecting the units controlled by this Micro AI.
** One or the other is required
** If both are given, [filter] takes priority over id=
** The AI contains an implicit filter for units on the AI side. Thus, if all AI units are to be selected, an empty [filter] tag can be used.
** If several units match the filter, the order in which they are controlled is not guaranteed. If the order matters, set up several MAIs using the id= key and different values for ca_score=.
* '''home_x,home_y''': The coordinates of the hex to which the hunter returns and rests at after a kill.

'''Optional keys:'''

* '''ca_score'''=300000: (non-negative integer) The evaluation score of the candidate action controlling this Micro AI. By default, it is set to 300,000, which is higher than any of the [http://wiki.wesnoth.org/AiWML#Evaluating_AI_Moves_--_Candidate_Actions_.28CAs.29 RCA AI candidate actions]. By setting it, for example, to 170,000, we can have it be executed after the default recruitment CA, but before most of the other default CAs.
* '''[filter_location]''': A [[StandardLocationFilter|Standard Location Filter]] describing the unit's hunting ground. If this tag is not provided, the hunter uses all of the map.
* '''rest_turns'''=3: (integer) The number of turns the AI stays at home_x,home_y after a kill. It will not leave its home until this number of turns have passed ''and'' it is fully healed.
* '''show_messages'''=no: (boolean) If set to yes, the hunter announces whenever its behavior changes to the next phase. Note that this is meant as debug output for the scenario author. The messages are not included in replays (and are only visible to the host in an MP game).

Here's an example of a hunter [micro_ai] tag usage from the "Dragon" [[Micro_AIs#Micro_AI_Test_and_Demo_Scenarios|test scenario]]:
[micro_ai]
side=1
ai_type=hunter
action=add

id=Rowck
[filter_location]
x,y=5-30,1-15
[/filter_location]
home_x,home_y=3,15
rest_turns=2

show_messages=yes
[/micro_ai]

=== Animals AI: Swarm (ai_type=swarm) ===

The Swarm Micro AI uses some very simply algorithms to simulate animal swarm behavior. Without adjacent enemies, they simply do a random move, trying to stay together and at a certain distance from enemies. However, if an enemy unit is close to any bat, the swarm scatters. This is particular fun to watch when one places an enemy unit in the middle of the swarm. After being scattered, the swarm members slowly rejoin, but not in a very organized way. Sub-swarms or individual bats might roam around for quite some time before they find their way back. It is also possible that individual bats (or small groups) split off from the larger swarm at times.

For a demonstration of the Swarm AI behavior, check out the "Swarm" scenario from the [[Micro_AIs#Micro_AI_Test_and_Demo_Scenarios|test scenario]].

Enable the Swarm Micro AI by using
ai_type=swarm
in the [micro_ai] tag together with the following keys:

'''Required keys:'''

There are no required keys

'''Optional keys:'''

* '''ca_score'''=300000: (non-negative integer) The evaluation score of the candidate actions controlling this Micro AI. By default, it is set to 300,000, which is higher than any of the [http://wiki.wesnoth.org/AiWML#Evaluating_AI_Moves_--_Candidate_Actions_.28CAs.29 RCA AI candidate actions]. By setting it, for example, to 170,000, we can have it be executed after the default recruitment CA, but before most of the other default CAs. Note that the Swarm AI consists of 2 CAs with scores ranging from <tt>ca_score-1</tt> to <tt>ca_score</tt>.
* '''enemy_distance'''=5: (int) The minimum distance kept between units of the swarm and enemies when the swarm moves as a whole.
* '''scatter_distance'''=3: (int) Enemies within "scatter_distance" hexes of any swarm unit cause the swarm to scatter, by each unit trying to maximize its individual distance from the enemy.
* '''vision_distance'''=12: (int) Only units within this distance follow the overall swarm motion (either away from an enemy or of the swarm as a whole). The smaller this value is set, the less likely the swarm is to stay together or rejoin. This parameter is meant to simulate how far an individual member of the swarm can see, meaning that the swarm is "out of sight" (and the unit will not be able to follow it) if it is more than this distance away.

Here's an example of a Swarm [micro_ai] tag usage from the "Swarm" [[Micro_AIs#Micro_AI_Test_and_Demo_Scenarios|test scenario]]:
[micro_ai]
side=2
ai_type=swarm
action=add
[/micro_ai]

== Bottleneck Defense Micro AI (ai_type=bottleneck_defense) ==

The Bottleneck Defense Micro AI lets you define a location on the map where the AI can take a defensive stance behind a narrow passage (bottleneck). Units on the front line are backed up by healers and/or units with the leadership ability. Injured units are moved to the back and replaced by uninjured (or less injured) units. The units on the front line only attack when it is safe (no retaliation) or when there is a high chance that they will make a kill or level up. Using this Micro AI only makes sense if there is no way for the enemy sides to move around the bottleneck and attack the AI's units from behind.

For a demonstration, check out the "Bottleneck" scenario from the [[Micro_AIs#Micro_AI_Test_and_Demo_Scenarios|test scenario]].

Enable the Bottleneck Defense Micro AI by using
ai_type=bottleneck_defense
in the [micro_ai] tag.

===Bottleneck Defense specific keys for the [micro_ai] tag:===

'''Required keys:'''

The Bottleneck Defense AI requires two sets of coordinates that define where it should be taking up its defensive stance, and from which side the enemy attacks at that location.

* '''x,y''': Comma separated lists of the hexes on the front line, where strong units are placed. All hexes on which the AI makes contact with (can be attacked by) the enemy need to be included here. Units are placed on them in the order in which they are listed here.
* '''enemy_x,enemy_y''': Comma separated list of the hexes from which the enemy can attack the AI front line units. This is needed for the AI to know on which side of the front line support units (healers etc.) need to be placed. In many cases, it is sufficient to provide only one of the enemy front line hexes, but there are geometries for which that does not work. It is therefore safer to list all enemy front line hexes here.

'''Optional keys:'''

By default, the AI places healers and units with the leadership ability both on the front line itself (if they are the strongest units available) and on hexes adjacent to and behind the line. If different placement is desired, these locations can be overridden with the following keys.

* '''active_side_leader'''=no: (boolean) If set to 'yes', the side leader participates in the bottleneck defense action after the side's gold has been spent. If set to 'no' (default), the leader follows default AI behavior (sitting on the keep and recruiting, for the most part).
* '''ca_score'''=300000: (non-negative integer) The evaluation score of the candidate actions controlling this Micro AI. By default, it is set to 300,000, which is higher than any of the [http://wiki.wesnoth.org/AiWML#Evaluating_AI_Moves_--_Candidate_Actions_.28CAs.29 RCA AI candidate actions]. By setting it, for example, to 170,000, we can have it be executed after the default recruitment CA, but before most of the other default CAs. Note that the Bottleneck Defense AI consists of 2 CAs with scores ranging from <tt>ca_score-1</tt> to <tt>ca_score</tt>.
* '''healer_x,healer_y''': Comma separated list of hexes where healers are placed. This can be used to keep healers from the front line (or to take up only certain positions on the front line), and/or to override the default healing positions behind the line. Healers are placed on them in the order in which the hexes are listed, with the exception that hexes on the line always take priority over hexes behind the line.
* '''leadership_x,leadership_y''': Same as ''healer_x,healer_y'', but for units with the leadership ability.

As an example, in the "Bottleneck" [[Micro_AIs#Micro_AI_Test_and_Demo_Scenarios|test scenario]], there are three front line hexes, two of which are on hill terrain, while the third is a road with a lower defense rating. The healer and side leader are supposed to participate in combat because they are strong units, but only from the hill hexes to keep them safer. This is accomplished by using the following keys settings (check out the scenario to see which hex is which):
[micro_ai]
side=1
ai_type=bottleneck_defense
action=add

x=14,14,14
y= 7, 9, 8
enemy_x=13,13
enemy_y= 8, 9

healer_x=14,14,15,15
healer_y= 7, 9, 8, 9
leadership_x=14,14,15,15
leadership_y= 7, 9, 9 ,8
active_side_leader=yes
[/micro_ai]

== Fast Micro AI (ai_type=fast_ai) ==

{{DevFeature1.13|0}}

This AI is meant as a fall-back AI for scenarios where there are so many units that attacks and moves done by the default AI are slow with long delays before each move. It replaces the default combat and move-to-targets candidate actions (CAs). It should be obvious that in order to achieve the faster speed, compromises concerning the quality of the moves have to be made.

'''Combat candidate action:'''
* Attackers are considered individually one at a time. The best attack found for a unit is executed without checking whether a better attack by another unit might be possible.
* The default order in which attackers are considered is by decreasing hitpoints, starting with the strongest unit (in terms of HP). This can be modified with the optional keys below.
* By default, if weaker units block attack hexes for a stronger unit, they do not move out of the way (this is the same as for the default AI). If a hex becomes available after an attack (e.g. due to a weaker unit dying in the attack), all attacks that were possible ''before'' this happened are finished first. Only after that are attacks by the stronger unit reconsidered.
* If include_occupied_attack_hexes=yes is set, weaker units move out of the way for stronger units if possible. This can, however slow down the AI depending on the situation on the map. Use with caution.

'''Move-to-targets, villages and retreat candidate actions:'''
* The move-to-targets, villages and retreat candidate actions of the default AI are removed. Move-to-targets and villages are taken over by the Fast Micro AI, whereas retreat is simply not done.
* This CA moves units toward goals after attacks are done. Goals are unowned (if the AI side has a leader only) and enemy-owned villages and enemy leaders.
* For each goal, units are pre-sorted in order of the fewest moves needed to cover the ''distance'' toward the goal (that is, as if move cost on each hex toward the goal were 1). Units are then considered sequentially and if a unit can get there "efficiently", its move is executed without considering other units.
** A move is considered efficient if the move cost to get to the hex is not more than 'move_cost_factor' larger than the distance to the hex. 'move_cost_factor' is an optional key that defaults to 2. It can be set to values of 1.1 or larger (see below).
** If the move for the current unit is not found to be efficient, the AI considers the next unit instead. If no unit can do an efficient move toward the goal, the best (fastest) of the inefficient moves is selected instead.

* Village goals:
** Village goals are considered before enemy leader goals so that the AI preferentially chooses scouts (or otherwise fast units) for them.
** The number of units sent toward villages depends on the value of the default AI aspect village_value. It is set to village_value/4 times the number of units the AI has left to move. Thus, by default (village_value=1.0) the AI sends a quarter of its units toward villages, and the rest toward enemy leaders. This means that the meaningful range of values for village_value is 0..4.
** Only one unit is moved toward each village. This consideration also overrides the number of units to move toward villages defined by village_value, topping it at the number of unowned/enemy-owned villages on the map.
** Setting village_value=0 disables moving units toward villages altogether. That is, not only are no units chosen, but the village targeting phase of the AI is entirely disabled with no evaluation time used for it. Note that, unlike with the default AI, this also means that no villages within range of an AI unit are grabbed.
** The order in which villages are chosen as goals is some combination of them being close to the AI side's leader and being spread out over the map.

* Enemy leader goals:
** The order of enemy leaders goals is set according to their distance from the AI leader with the closest enemy leader being targeted first (if the AI has a leader, otherwise their order is random). One unit is sent toward each enemy leader in this order, after which the AI starts with the first enemy leader again. This is repeated until all units have moved.

* Guardians (units with ai_special=guardian set) are ignored by the fast move-to-targets CA.

'''Tips for speeding up/modifying the Fast Micro AI in specific scenarios:'''

A number of optional keys and default AI aspects can be used to modify the behavior of the Fast Micro AI. The MAI is set up so that it is a reasonable compromise between speed and quality of the moves in most situations. However, this might not be ideal for all scenarios here are some things that can be done to speed up the AI (or to get better behavior in some situations by doing the opposite):
* Use large values for the default AI aspect aggression. The largest delays before attacks happen (in some circumstances) when the Fast MAI has to consider lots of units with attacks left but decides not to attack with them. See below for a description of how aggression is used by the fast AI.
* Use large values of move_cost_factor (see above for description of what this does). If you want to emphasize units that can move across terrain easily (e.g. bats) to be chosen for village grabbing, you might want to use low values of move_cost_factor, but this might slow down the AI. The default value should work reasonably well in most standard situations, but modifying the value might work better on specific maps.
* Don't use dungeon_mode=yes unless absolutely necessary, even in most dungeon crawls. Test the AI without this setting first and only use it if it is the only way to solve the problem. Often, a minor tweak to the map will have the same effect, without the speed penalty.
* Use include_occupied_attack_hexes=yes with caution. It might (or might not) slow down the attack CA significantly, depending on the scenario.
* Set village_value=0, which makes the AI not consider villages as goals. This has not been found to make a large difference on the maps tested so far, but it might have an effect on maps with a very large number of villages.

'''Required keys:'''

There are no required keys.

'''Optional keys:'''

* '''dungeon_mode'''=no: (boolean) As much as possible, the Fast Micro AI works with distances between hexes rather than path finding. This works pretty well on open maps and even most dungeon crawls (and similar scenarios), but it might result in some units getting temporarily (and in rare cases permanently) stuck on maps with convoluted labyrinths. If that is the case, setting dungeon_mode=yes triggers more path finding that avoids such situations (but as a result is somewhat slower).
* '''include_occupied_attack_hexes'''=no: (boolean) If set to 'yes', the AI moves weaker units out of the way for a stronger attacker. This might lead to better attacks but is slower, so don't use if speed is essential.
* '''move_cost_factor'''=2: (number >= 1.1) The factor by which the move cost to a goal hex may be larger than the distance to the goal hex for a move to be considered "efficient". See description above. 1.1 is used if this is set to values smaller than 1.1. Smaller values might lead to better behavior, while larger values might speed up the AI.
* '''weak_units_first'''=no: (boolean) If set to 'yes', inverts the order in which units are considered by the combat CA. Attacks are then done in order of increasing hitpoints of the attackers.
* '''skip_combat_ca'''=no: (boolean) If set to 'yes', the fast combat CA is not used. The default AI's CA remains in place in this case.
* '''skip_move_ca'''=no: (boolean) If set to 'yes', the fast move-to-targets CA is not used. The default AI's retreat, villages and move-to-targets CAs remains in place in this case.

'''Standard RCA AI aspects respected by this Micro AI:'''
*'''aggression''': The [[AiWML#The_.5Bai.5D_Tag:_Defining_Aspects|default RCA AI aspect]] used to set how aggressive the AI should attack. It works in roughly the same way as the default AI aspect:
** The value of (1 - aggression) determines how much the AI values its own units compared to the enemy's units. Thus, aggression=0 means that attacks are only done if the AI expects to deal (roughly) the same amount of damage as it will receive. aggression=1 means that expected damage to the AI's units is not considered, only the expected damage to enemy units matters.
** Damage is calculated as a combination of hitpoints and chance to die, in "gold equivalent units".
** Unlike the default AI, aggression is set to 1 for values larger than 1. Allowed values are thus anything from -infinity to +infinity, although only -infinity to +1.0 make sense.
*'''village_value=1''': (number ranging from 0 to 4) The [[AiWML#The_.5Bai.5D_Tag:_Defining_Aspects|default RCA AI aspect]] used to define how much villages should be targeted by the move-to-targets CA. In the Fast MAI, this defines which fraction of the AI units are moved toward village goals (see above for details). If set to 0, villages are ignored as goals.

'''Notes:'''
* The CA evaluation scores of this AI are hard-coded to the same values as those of the respective [[AiWML#Evaluating_AI_Moves_--_Candidate_Actions_.28CAs.29|default candidate actions]]. ca_score is therefore not a valid optional key.
* The fast Micro AI modifies (removes) the default combat, move-to-targets, villages and retreat candidate actions.

== Generalized Goto Micro AI (ai_type=goto) ==

The Goto Micro AI provides a highly configurable method of sending a unit (or units) to a location or set of locations. The units to be moved are defined using a [[StandardUnitFilter|Standard Unit Filter]] (SUF) [alternatively, all side units are used if the SUF is not provided), while the goto locations are given in a [[StandardLocationFilter|Standard Location Filter]] (SLF).

By default, each unit matching the SUF will move toward the closest goal (in terms of turns needed to get there) matching the SLF via the fastest route given the current situation on the map (locations of enemy units etc.), but this behavior can be influenced by the optional keys listed below. Note that this means that a unit's goal might change from one turn to the next depending on the situation on the map.

The behavior of the unit(s) once they reach their goal location(s) is configurable as well. By default, they will stay there until the Goto Micro AI is deleted or changed.

For demonstrations of several Goto Micro AI usages, check out the "Goto" scenario from the [[Micro_AIs#Micro_AI_Test_and_Demo_Scenarios|test scenario]].

Enable the Goto Micro AI by using
ai_type=goto
in the [micro_ai] tag.

===Goto specific keys for the [micro_ai] tag:===

'''Required keys:'''

* '''[filter_location]''': A [[StandardLocationFilter|Standard Location Filter]] describing the possible goal locations for the move.

'''Optional keys:'''

* '''avoid_enemies''': (number>0) By default, units controlled by the Goto Micro AI will not take enemy units into account for route finding, other than the enemies' ZoCs. By contrast, if this key is set, they will try to avoid traversing hexes on which they can be attacked by enemies. The larger the value of ''avoid_enemies'', the more the units will try to stay out of the enemies' way. Notes:
** Units are willing to take a path that is 'avoid_enemies' movement points longer for each enemy unit that can be avoided by doing so for each hex along the path. As an example, if avoid_enemies=1 and the shortest path crosses 2 hexes that can be reached by 3 enemies each, the unit is willing to take a path that is up to 6 hexes longer instead. If avoid_enemies=10 in the same situation, the unit will take a path up to 60 hexes longer.
** Hexes adjacent to enemy units are always strongly avoided, independent of the value of avoid_enemies.
** avoid_enemies is ignored if 'use_straight_line=true' is set.
* '''ca_score'''=300000: (non-negative integer) The evaluation score of the candidate action controlling this Micro AI. By default, it is set to 300,000, which is higher than any of the [http://wiki.wesnoth.org/AiWML#Evaluating_AI_Moves_--_Candidate_Actions_.28CAs.29 RCA AI candidate actions]. By setting it, for example, to 170,000, we can have it be executed after the default recruitment CA, but before most of the other default CAs.
* '''[filter]''': A [[StandardUnitFilter|Standard Unit Filter]] selecting the units to be moved. Defaults to all units of the side if not defined. The filter automatically includes the side= key set to the AI side.
* '''ignore_enemy_at_goal'''=no and '''ignore_units'''=no: (boolean) In the default configuration, the Goto MAI does not move units if the path to all goal hexes is blocked by enemies. It is therefore possible to disable the Goto MAI by putting enemy units on all the goal hexes. That can be changed if either of these two keys is set to 'yes'.
** 'ignore_enemy_at_goal=yes' makes the AI choose its goals while disregarding any enemy units at the goal hexes. Even so, a stiff rating penalty is applied to goal hexes occupied by enemies, thus that unoccupied goal hexes are chosen unless all possible goals are occupied by enemies. Note that this setting ''only'' ignores enemy units at the goal hexes themselves. It is still possible to disable the AI by putting enemies all around the goals.
** 'ignore_units=yes' let's the AI ignore ''all'' enemy units when deciding which goal hex(es) to move toward.
** In both cases, enemies are only ignored for deciding which unit to move toward which goal hex. For the actual move itself, all enemies and their ZoCs are considered as usual.
** Both options only take effect if neither avoid_enemies nor use_straight_line is set to 'yes', as neither of these consider enemies as blockers.
* '''release_unit_at_goal'''=no: (boolean) By default, a unit that reaches a goal location will stay there until the Goto Micro AI is deleted or changed (or until the conditions specified in the [goto_goals] SLF change). If this parameter is set, a unit that has reached its goal will not be controlled by this Micro AI any more starting from the next turn.
* '''release_all_units_at_goal'''=no: (boolean) Same as ''release_unit_at_goal'', but this will deactivate the Goto Micro AI for all units once the first unit reaches a goal.
* '''unique_goals'''=no: (boolean) If set to 'yes', each unit will be sent to a different goal location. Note that the best goals are recalculated each turn, so a unit might choose a different goal this turn from what it was heading for during the previous turn if the situation on the map has changed. Also note that if there are more units than goal locations, the left over units will not be handled by the Goto MAI but follow default behavior instead.
* '''use_straight_line'''=no: (boolean) By default, units choose the route by which they will get to their goal locations in the smallest number of turns. If this parameter is set to 'yes', a straight line route (or something pretty close to it at least) will be chosen instead, irrespective of whether this leads into a dead end, whether it is blocked by enemies, etc.

'''Notes:'''
* Depending on the parameters used, the Goto Micro AI might require a lot of path finding to be done. Thus, while it is possible to set up this AI to move many units to many different locations, a usage like that might require quite a long calculation time.

===Goto Micro AI example usages:===

Here are several examples of goto [micro_ai] tag usages from the "Goto" [[Micro_AIs#Micro_AI_Test_and_Demo_Scenarios|test scenario]]:
* Send a unit toward a castle (similar to the RCA AI's Goto Candidate Action, but avoiding dead ends and areas ZoCed by enemies)
[micro_ai]
side=2
ai_type=goto
action=add
ca_id=messenger1

[filter]
id=messenger1
[/filter]
[filter_location]
x,y=6-7,2-4
terrain=C*
[/filter_location]
ca_score=210001
[/micro_ai]
* Send all units of the side toward the southern border of the map
[micro_ai]
side=8
ai_type=goto
action=add

[filter_location]
y=33
[/filter_location]
avoid_enemies=1
[/micro_ai]
* Send units to the four corners of the map (with each unit going to a different corner).
[micro_ai]
side=7
ai_type=goto
action=add

[filter_location]
x=1,1,44,44
y=1,33,1,33
[/filter_location]
unique_goals=yes
[/micro_ai]
* Set up a guardian unit that doesn't move while no enemy unit is within 8 hexes (ironically, the Goto Micro AI can be used to keep units in place, although using one of the Guardian Micro AIs might often be a better idea)
[micro_ai]
side=3
ai_type=goto
action=add

[filter]
id=guard1
[/filter]
[filter_location]
[filter]
id=guard1
[/filter]
[not]
[filter]
side=1
[/filter]
radius=8
[/not]
[/filter_location]
[/micro_ai]

== Guardian Micro AIs ==
=== General Comments on the Guardian Micro AIs ===

The Guardian Micro AIs can be used to set up different kind of guardian behaviors for a unit or a set of units. Four different types of guardians are available and are described below.

For a demonstration of several different guardian behaviors, check out the "Guardians" scenario from the [[Micro_AIs#Micro_AI_Test_and_Demo_Scenarios|test scenario]].

=== Return Guardian (ai_type=return_guardian)===

A 'return guardian' is a variation of the standard Wesnoth guardian. It has an assigned guard position (GP) to which it returns after attacks on approaching enemies:
* If at GP with no enemy in reach, do nothing.
* If at GP with an enemy in reach, attack (note that the attack is done by default AI, which might result in the guardian not attacking if the enemy is deemed too strong).
* If not at GP, return there, no matter whether an enemy is in reach or not.
* If enemies are blocking the way back to GP, do your best to move around them.
* If the guardian ends up next to an enemy on the way back, attack that enemy after the move.

Enable the Return Guardian Micro AI by using
ai_type=return_guardian
in the [micro_ai] tag together with the following keys:

'''Required keys:'''

* '''id''' or '''[filter]''': The ID of a unit or a [[StandardUnitFilter|Standard Unit Filter]] selecting the units controlled by this Micro AI.
** One or the other is required
** If both are given, [filter] takes priority over id=
** The AI contains an implicit filter for units on the AI side. Thus, if all AI units are to be selected, an empty [filter] tag can be used.
** If several units match the filter, the order in which they are controlled is not guaranteed. If the order matters, set up several MAIs using the id= key and different values for ca_score=.
* '''return_x,return_y''': The coordinate of the hex the unit returns to after each attack

'''Optional keys:'''

* '''ca_score'''=10010: (non-negative integer) The evaluation score of the candidate actions controlling this Micro AI. This AI consist of 2 CAs, one with score <tt>ca_score</tt> the other with <tt>ca_score-20</tt>. The default value is set so that the first CA gets executed right before the default combat CA, and the other right after. It usually will not make sense to change this value, but it is possible to do so for custom applications.

Here's an example of a return guardian [micro_ai] tag usage from the "Guardians" [[Micro_AIs#Micro_AI_Test_and_Demo_Scenarios|test scenario]]:
[micro_ai]
side=2
ai_type=return_guardian
action=add

id=return1
return_x,return_y=20,2
[/micro_ai]

===Stationed Guardian (ai_type=stationed_guardian) ===

A 'stationed guardian' is another variation of the standard Wesnoth guardian with a somewhat more complex behavior than that of the 'return guardian'. Two positions are defined for it, a 'station' and a 'guarded location', as well as a distance. The behavior is as follows:
* If no enemy is within 'distance' of the guard's current position, do nothing. This is independent of the guardian being at its station or not.
* Otherwise: If an enemy is within 'distance' of the guard, but not also within the same distance of the guarded location and the station (all of this simultaneously), move the guard in the direction of the station.
* Otherwise:
** Pick the enemy unit that is closest to the guarded location.
** If we can reach it, pick the adjacent hex with the highest defense rating and attack from there.
** If not in reach, move toward this unit.

Enable the Stationed Guardian Micro AI by using
ai_type=stationed_guardian
in the [micro_ai] tag together with the following keys:

'''Required keys:'''

* '''id''' or '''[filter]''': The ID of a unit or a [[StandardUnitFilter|Standard Unit Filter]] selecting the units controlled by this Micro AI.
** One or the other is required
** If both are given, [filter] takes priority over id=
** The AI contains an implicit filter for units on the AI side. Thus, if all AI units are to be selected, an empty [filter] tag can be used.
** If several units match the filter, the order in which they are controlled is not guaranteed. If the order matters, set up several MAIs using the id= key and different values for ca_score=.
* '''distance''': The distance parameter as explained above
* '''station_x,station_y''': The x and y position of the hex that serves as the guardians station.
* '''guard_x, guard_y''': The x and y position of the guarded location.

'''Optional keys:'''

* '''ca_score'''=300000: (non-negative integer) The evaluation score of the candidate action controlling this Micro AI. By default, it is set to 300,000, which is higher than any of the [http://wiki.wesnoth.org/AiWML#Evaluating_AI_Moves_--_Candidate_Actions_.28CAs.29 RCA AI candidate actions]. By setting it, for example, to 170,000, we can have it be executed after the default recruitment CA, but before most of the other default CAs.

Here's an example of a stationed guardian [micro_ai] tag usage from the "Guardians" [[Micro_AIs#Micro_AI_Test_and_Demo_Scenarios|test scenario]]:
[micro_ai]
side=2
ai_type=stationed_guardian
action=add

id=stationed1
distance=4
station_x,station_y=2,14
guard_x,guard_y=3,13
[/micro_ai]

=== Coward (ai_type=coward) ===

Cowards are units that, like guardians, sit around doing nothing until an enemy comes into range. Unlike guardians, however, they run away once enemies approach. Applications might be wild animals, unarmed civilians getting in the way of a battle, etc. The coward macro can be called with two optional locations, 'seek' and 'avoid':
* If neither is given, the coward retreats to the position farthest away from the approaching enemies.
* If 'seek' is given, it preferentially goes toward that location (but getting away from enemies takes priority).
* If 'avoid' is given, it in addition tries to avoid that location (with both maximizing distance from enemies and going toward 'seek' taking priority).
* Both 'seek' and 'avoid' may consist of only one coordinate ('x' or 'y'), in which case not a single hex, but a line of hexes is sought or avoided.

Enable the Coward Micro AI by using
ai_type=coward
in the [micro_ai] tag together with the following keys:

'''Required keys:'''

* '''id''' or '''[filter]''': The ID of a unit or a [[StandardUnitFilter|Standard Unit Filter]] selecting the units controlled by this Micro AI.
** One or the other is required
** If both are given, [filter] takes priority over id=
** The AI contains an implicit filter for units on the AI side. Thus, if all AI units are to be selected, an empty [filter] tag can be used.
** If several units match the filter, the order in which they are controlled is not guaranteed. If the order matters, set up several MAIs using the id= key and different values for ca_score=.
* '''distance''': The distance within which an enemy must be to "scare" the unit

'''Optional keys:'''

* '''avoid_x, avoid_y''': The x and y coordinate of the hex to avoid
* '''ca_score'''=300000: (non-negative integer) The evaluation score of the candidate action controlling this Micro AI. By default, it is set to 300,000, which is higher than any of the [http://wiki.wesnoth.org/AiWML#Evaluating_AI_Moves_--_Candidate_Actions_.28CAs.29 RCA AI candidate actions]. By setting it, for example, to 170,000, we can have it be executed after the default recruitment CA, but before most of the other default CAs.
* '''[filter_second]''': A [[StandardUnitFilter|Standard Unit Filter]] selecting the units from which the cowards flee. If not set, this defaults to all enemy units. Note, however, that no "enemy of AI side" condition is added if [filter_second] is specified, meaning that it can include allied and/or enemy units as desired (and even units on the same side as the coward). {{DevFeature1.11|8}}
* '''seek_x, seek_y''': The x and y coordinate of the hex to seek

Here's an example of a coward [micro_ai] tag usage from the "Guardians" [[Micro_AIs#Micro_AI_Test_and_Demo_Scenarios|test scenario]]:
[micro_ai]
side=2
ai_type=coward
action=add

id=coward3
distance=5
seek_x,seek_y=24,5
avoid_x,avoid_y=24,15
[/micro_ai]

=== Zone guardian (ai_type=zone_guardian) ===

A zone guardian is a unit that, as the name says, guards a zone. It moves randomly inside this zone until an enemy enters it (or a separately defined enemy zone, see below). Applications might be the defense of a castle or a nesting area. The zone macro can be called with an optional SLF, [filter_location_enemy]:
* If not specified, the zone guard attacks any enemy coming inside its guard zone.
* If [filter_location_enemy] is given, it attacks any enemy entering this zone and once there are no more enemies, it goes back to patrol in its basic zone.

Enable the Zone Guardian Micro AI by using
ai_type=zone_guardian
in the [micro_ai] tag together with the following keys:

'''Required keys:'''

* '''id''' or '''[filter]''': The ID of a unit or a [[StandardUnitFilter|Standard Unit Filter]] selecting the units controlled by this Micro AI.
** One or the other is required
** If both are given, [filter] takes priority over id=
** The AI contains an implicit filter for units on the AI side. Thus, if all AI units are to be selected, an empty [filter] tag can be used.
** If several units match the filter, the order in which they are controlled is not guaranteed. If the order matters, set up several MAIs using the id= key and different values for ca_score=.
* '''[filter_location]''': A [[StandardLocationFilter|Standard Location Filter]] designating the zone to guard.

'''Optional keys:'''
* '''ca_score'''=300000: (non-negative integer) The evaluation score of the candidate action controlling this Micro AI. By default, it is set to 300,000, which is higher than any of the [http://wiki.wesnoth.org/AiWML#Evaluating_AI_Moves_--_Candidate_Actions_.28CAs.29 RCA AI candidate actions]. By setting it, for example, to 170,000, we can have it be executed after the default recruitment CA, but before most of the other default CAs.
* '''[filter_location_enemy]''': A [[StandardLocationFilter|Standard Location Filter]] designating the zone where enemies have to be attacked. If not given, it defaults to [filter_location].
* '''station_x,station_y''': By default, the zone guardian moves randomly within the zone if there is no enemy to attack. However, if station_x/y is given, it moves to this position instead during turns when it does not have an enemy to attack. This position does not need to be inside the zone defined above. Note: obviously it does not make sense to define [filter_location], [filter_location_enemy] and station_x/y all at the same time. Only [filter_location] and either one of the latter two (or none of them) should be provided for any zone guardian.

Here's an example of a zone guardian [micro_ai] tag usage from the "Guardians" [[Micro_AIs#Micro_AI_Test_and_Demo_Scenarios|test scenario]]:
[micro_ai]
side=2
ai_type=zone_guardian
action=add

id=zone3
[filter_location]
x,y=22-31,4-11 # This is intentionally chosen to extend past the lake
terrain=W*
[/filter_location]
station_x,station_y=32,8
[/micro_ai]

== Hang Out Micro AI (ai_type=hang_out) ==

The Hang Out Micro AI instructs units of the AI side to "hang out" around a certain location, or locations, until a condition for mobilizing the side is met. If none of the optional keys are given, the AI controls all units of the side to hang around the leader while moving off castle tiles to make room for recruiting.

The AI works by moving each unit to its best hex first using the minimum amount of movement points required for this move. Once all AI units are in position, movement points are set to zero for all of them simultaneously such that they cannot be used by other AI candidate actions. This is done because the mobilizing condition might be met as result of one of the moves of the Hang Out AI, after which we want units to be able to continue with other AI actions.

For a demonstration, check out the "Hang Out and Messenger" scenario from the [[Micro_AIs#Micro_AI_Test_and_Demo_Scenarios|test scenario]].

Enable the Hang Out Micro AI by using
ai_type=hang_out
in the [micro_ai] tag.

===Hang Out specific keys for the [micro_ai] tag:===

'''Required keys:'''

There are no required keys. In its default configuration, the Hang Out MAI controls all units of a side, keeping them as close to the side leader(s) as possible while moving off castle tiles to make room for recruiting. For this purpose, the candidate action score defaults to 170,000, which is just below the score of the default recruiting CA.

'''Optional keys:'''

* '''[avoid]''': A [[StandardLocationFilter|Standard Location Filter]] for the terrain which the AI units should avoid. If it is not given, the existence of the default (RCA) AI's [avoid] tag is checked (and used if it exists). If neither of these two exists, this parameter is set to default to all castle terrain (<tt>terrain=C*,C*^*,*^C*</tt>) so that units move off the castle to make room for recruiting. Note that this does not include keep terrain, otherwise the leader would be moved off the keep as well.
* '''ca_score'''=170000: (non-negative integer) The evaluation score of the candidate action controlling this Micro AI. By default, it is set to 170,000, which means that it is executed after the default recruitment CA, but before most of the other default CAs.
* '''[filter]''': A [[StandardUnitFilter|Standard Unit Filter]] selecting the units of the AI side participating in the Hang Out action (<tt>side=</tt> is always set and does not need to be provided). It defaults to all units of the side. The filter automatically includes the side= key set to the AI side.
* '''[filter_location]''': A [[StandardLocationFilter|Standard Location Filter]] describing the locations ''near'' which the AI units should hang out. This does not mean that the units only move onto terrain specified here, but that they minimize the distance to such terrain. It defaults to the position of the side leader(s).
* '''mobilize_condition''': ([[ConditionalActionsWML#Condition_Tags|WML Condition Tag]]) Once the condition set up here has been met, the Hang Out MAI is disabled and the side goes over to other AI activity. The Hang Out MAI remains disabled after this, even if the condition is not met any more later in the scenario.
* '''mobilize_on_gold_less_than''': (number) Since side gold cannot be checked in a WML condition tag without storing it in a variable first, this key is provided separately. It disables the Hang Out Micro AI once the side gold goes below the value specified here for the first time.

'''Standard RCA AI aspects respected by this Micro AI:'''
*'''[avoid]''': The standard RCA AI aspect used to define locations that should be avoided by the AI. See above (under 'optional keys') for details.

'''Notes:'''

* The Hang Out AI still takes effect if no locations to hang out at are found or if all map locations are to be avoided. In that case, it simply keeps all units at their current locations.

This is an example of a Hang Out Micro AI configuration from the "Hang Out and Messenger" [[Micro_AIs#Micro_AI_Test_and_Demo_Scenarios|test scenario]]:
[micro_ai]
side=1
ai_type=hang_out
action=add

[avoid]
terrain=C*,H*,M*,A*,S*,*^F*
[/avoid]
[mobilize_condition]
[have_unit]
side=1
count=7-99
[/have_unit]
[/mobilize_condition]
[/micro_ai]

== Healer Support Micro AI (ai_type=healer_support) ==

The Healer Support Micro AI configures the healers of a side to stay behind the battle lines and heal injured and/or threatened units rather than participate in combat under all circumstances. You can set different levels of aggressiveness for the healers.

'''Notes'''
* By default, ''all'' healers of the AI side are controlled by this AI. This includes in particular also the side leader, if the leader is a healer. If you do not want the leader to be included (and possibly be moved away from the keep etc.) use the [filter] tag with canrecruit=no (see below).
* It is not always better to use this Micro AI than the default AI, as it takes healers (which can be strong units) away from the pool of units to choose for attacks.

For a demonstration, check out the "Healers" scenario from the [[Micro_AIs#Micro_AI_Test_and_Demo_Scenarios|test scenario]].

Enable the Healer Support Micro AI by using
ai_type=healer_support
in the [micro_ai] tag.

===Healer Support specific keys for the [micro_ai] tag:===

'''Required keys:'''

There are no required keys.

'''Optional keys:'''

* '''[filter]''': A [[StandardUnitFilter|Standard Unit Filter]] selecting the healer units. If set, only units on the AI side passing this filter ''and'' having the healing ability are considered by this Micro AI.
*'''[filter_second]''': A [[StandardUnitFilter|Standard Unit Filter]] selecting units to receive healing. If set, only units on the AI side passing this filter ''and'' the other healee selection criteria will be selected for healing by this Micro AI.
* '''aggression'''=1.0: (float) Sets the aggressiveness of the AI. This parameter is set up as a float to accommodate future functionality, but it currently acts as a boolean: if set to zero, the AI will never let its healers participate in combat, for all other values it allows them to attack after all other units have attacked and if the healers cannot find any more units to support. The former behavior might be appropriate in scenarios with only one or few valuable healers, while the latter might work better in scenarios with many healers.
* '''injured_units_only'''=no: (boolean) If set to 'yes', the AI will only move healers next to units that are already injured and skip units that currently have full hitpoints, but might get injured during the next enemy turn.
* '''max_threats'''=9999: (integer) The maximum allowable number of enemies that can attack a hex in order for it to be considered for a healer. As an example, setting 'max_threats=0' means that the AI only moves healers to locations that are entirely safe from the enemy (assuming that none of the units currently on the map dies). Note that the value of this key is checked against the number of enemies that can make it to the hex, not the number of adjacent hexes from which the healer could be attacked.

'''Standard RCA AI aspects respected by this Micro AI:'''
*'''[avoid]''': The standard RCA AI aspect used to define locations that should be avoided by the AI.

'''Notes:'''
* The Healer Support Micro AI modifies the [[AiWML#Filtering_Combat_with_the_.27attacks.27_Aspect|attacks aspect]].
* The CA evaluation scores of this AI are hard-coded. It does not work otherwise.

This is an example of a Healer Support Micro AI configuration from the "Healers" [[Micro_AIs#Micro_AI_Test_and_Demo_Scenarios|test scenario]]:
[micro_ai]
side=2
ai_type=healer_support
action=add

aggression=0
[/micro_ai]

== Lurkers Micro AI (ai_type=lurkers) ==

The Lurker Micro AI controls some or all units of a side in "lurker mode". A lurker is a unit that is capable of moving across most terrains, but that only stops on and attacks from specific terrain. It might also have the ability to hide on this terrain (which is the reason why it is called a lurker).

Lurkers move individually without strategy and always attack the weakest enemy within their reach. If no enemy is in reach, the lurker does a random move instead - or it just sits and waits (lurks).

For a demonstration of different types of lurker behavior, check out the "Lurkers" scenario from the [[Micro_AIs#Micro_AI_Test_and_Demo_Scenarios|test scenario]].

Enable the Lurkers Micro AI by using
ai_type=lurkers
in the [micro_ai] tag

===Lurkers specific keys for the [micro_ai] tag:===

'''Required keys:'''
* '''[filter]''': Specifies which units of the side are controlled by the Lurker Micro AI. This is a [[StandardUnitFilter|Standard Unit Filter]]. The filter automatically includes the side= key set to the AI side.
* '''[filter_location]''': Specifies the terrain from which the lurkers attack. This is a [[StandardLocationFilter|Standard Location Filter]].

'''Optional keys:'''
* '''ca_score'''=300000: (non-negative integer) The evaluation score of the candidate action controlling this Micro AI. By default, it is set to 300,000, which is higher than any of the [http://wiki.wesnoth.org/AiWML#Evaluating_AI_Moves_--_Candidate_Actions_.28CAs.29 RCA AI candidate actions]. By setting it, for example, to 170,000, we can have it be executed after the default recruitment CA, but before most of the other default CAs.
* '''[filter_location_wander]''': Specifies the terrain on which lurkers end their moves if there is no enemy in reach. This is a [[StandardLocationFilter|Standard Location Filter]]. If [filter_location_wander] is not given, it defaults to [filter_location].
* '''stationary'''=no: (boolean) If set to yes, a lurker never moves if there is no enemy within attack range.

Here's an example of [micro_ai] tag usage from the "Lurkers" [[Micro_AIs#Micro_AI_Test_and_Demo_Scenarios|test scenario]]:
[micro_ai]
side=4
ai_type=lurkers
action=add

[filter]
type=Naga Fighter
[/filter]
[filter_location]
terrain=W*,S*
[/filter_location]
[filter_location_wander]
terrain=W*
[/filter_location_wander]
[/micro_ai]

== Messenger Escort Micro AI (ai_type=messenger_escort) ==

The Messenger Escort Micro AI lets you define a set of waypoints through which it tries to move one or several of its units, the messenger(s). The other units escort the messenger, trying to protect it and attacking enemies that are in its way. Note that a messenger might not strictly hit intermediate waypoints, but that getting close is good enough, especially if a waypoint is occupied by an enemy unit. It does, however, always try to get to the last waypoint.

'''Notes on the use of several messengers:''' {{DevFeature1.13|0}}
* This Micro AI can control several messengers at the same time, which can but do not have to move in a group. They can be put on the map altogether in one location, or be spread out on the map or across different turns.
* The farther a messenger has moved through the chain of waypoints, the higher a priority it is for the AI, meaning that farther advanced (on the map) messengers are moved first, and that the escort units try to clear the way and stay with those messengers more so than with those further back on the map. This order can be inverted using the invert_order= key.
* If several messengers are on the map, escort units might move from one to the other, the AI making a judgement call where they are needed most. Closeness to a messenger is generally the most important criterion, but not the only one.
* If a messenger dies, the escort units previously staying with it now join one of the other messengers if there are any left (otherwise they follow default AI behavior).
* If you want certain escort units to stay always with the same messenger, use several messenger [micro_ai] tags with different [filter]/[filter_second] combinations.

For a demonstration, check out the "Messenger" scenario from the [[Micro_AIs#Micro_AI_Test_and_Demo_Scenarios|test scenario]].

Enable the Messenger Escort Micro AI by using
ai_type=messenger_escort
in the [micro_ai] tag.

===Messenger Escort specific keys for the [micro_ai] tag:===

'''Required keys:'''

* '''id''' or '''[filter]''': {{DevFeature1.13|0}} (Previous to 1.13.0, only id= was allowed.) The id of a unit or a [[StandardUnitFilter|Standard Unit Filter]] selecting the units controlled by this Micro AI.
** One or the other is required
** If both are given, [filter] takes priority over id=
** The AI contains an implicit filter for units on the AI side. Thus, if all AI units are to be selected, an empty [filter] tag can be used.
* '''waypoint_x,waypoint_y''': Comma-separated list of waypoint coordinates through which the messenger will go in the given order to reach its goal, given by the last coordinate. If you want the messenger to go directly to the goal, simply enter a single x,y coordinate here. Note that the messenger does not have to hit each waypoint exactly (except for the final one), getting close to them is good enough.

'''Optional keys:'''

* '''ca_score'''=300000: (non-negative integer) The evaluation score of the candidate actions controlling this Micro AI. By default, it is set to 300,000, which is higher than any of the [http://wiki.wesnoth.org/AiWML#Evaluating_AI_Moves_--_Candidate_Actions_.28CAs.29 RCA AI candidate actions]. By setting it, for example, to 170,000, we can have it be executed after the default recruitment CA, but before most of the other default CAs. Note that the Messenger Escort AI consists of 3 CAs with scores ranging from <tt>ca_score-2</tt> to <tt>ca_score</tt>.
* '''enemy_death_chance'''=0.67 and '''messenger_death_chance'''=0.0: (both floats; ranging from 0 to 1) If the messenger is adjacent to an enemy at the end of the move, it will only attack the enemy if the chance of death of the enemy is >= enemy_death_chance and if the messenger's chance of death is <= messenger_death_chance (or if it is an attack at a range for which the enemy does not have a weapon).
* '''[filter_second]''': {{DevFeature1.13|0}} A [[StandardUnitFilter|Standard Unit Filter]] selecting the escort units. If not set, this defaults to all enemy units. The filter automatically includes the side= key set to the AI side.
* '''invert_order'''=no: {{DevFeature1.13|0}} If set to 'yes', the order of priority with which messenger units are considered is inverted, starting with the messenger unit that is the least advanced on the map (see description above). In most cases, selecting this option results in worse performance of the AI, so use it with caution. (And obviously it has no effect at all if there is only one messenger controlled by the AI.)

Here's an example of [micro_ai] tag usage from the "Messenger Escort" [[Micro_AIs#Micro_AI_Test_and_Demo_Scenarios|test scenario]]:
[micro_ai]
side=2
ai_type=messenger_escort
action=add

id=messenger
waypoint_x=31,24,27,28
waypoint_y=20,14,7,1
[/micro_ai]

== Patrol Micro AI (ai_type=patrol) ==

The defines a number of waypoints for a unit (or units) to follow. Options can be set whether the route should be followed in a loop, as an out-and back, only once, whether units encountered along the way should be attacked, etc.

No matter what options are chosen, getting to the next waypoint always takes priority over attacking for a patroller. The AI thus prefers to move the patrol unit around enemies rather than straight for them. Also, if a waypoint is occupied by a unit the AI is not instructed to attack, it will (eventually) abandon that waypoint once it gets close enough and move on to the next one.

For a demonstration of several different patrol behaviors, check out the "Patrols" scenario from the [[Micro_AIs#Micro_AI_Test_and_Demo_Scenarios|test scenario]].

Enable the Patrol Micro AI it by using
ai_type=patrol
in the [micro_ai] tag.

===Patrol specific keys for the [micro_ai] tag:===

'''Required keys:'''

* '''id''' or '''[filter]''': The ID of a unit or a [[StandardUnitFilter|Standard Unit Filter]] selecting the units controlled by this Micro AI.
** One or the other is required
** If both are given, [filter] takes priority over id=
** The AI contains an implicit filter for units on the AI side. Thus, if all AI units are to be selected, an empty [filter] tag can be used.
** If several units match the filter, the order in which they are controlled is not guaranteed. If the order matters, set up several MAIs using the id= key and different values for ca_score=.
* '''waypoint_x,waypoint_y''': Comma-separated lists of the waypoint coordinates through which the patrol travels (in order).

'''Optional keys:'''

* '''attack''': By default (if this key is not set), the patrol unit attacks any unit it ends up next to after a move. Alternatively, this parameter can be set to a comma-separated list of unit ids. If that is done, the patrol only attacks these units when it ends up next to them and ignores any other unit. This can in turn be used to have the patroller not attack at all, by setting ''attack='' to a non-existing id.
* '''ca_score'''=300000: (non-negative integer) The evaluation score of the candidate action controlling this Micro AI. By default, it is set to 300,000, which is higher than any of the [http://wiki.wesnoth.org/AiWML#Evaluating_AI_Moves_--_Candidate_Actions_.28CAs.29 RCA AI candidate actions]. By setting it, for example, to 170,000, we can have it be executed after the default recruitment CA, but before most of the other default CAs.
* '''one_time_only'''=no: (boolean) If set to 'yes', the unit goes through the patrol route only once and then hangs out at the last waypoint. It also always attacks any enemy unit on the last waypoint, independent of what ''attack='' is set to.
* '''out_and_back'''=no: (boolean) By default, a patrol unit returns to the first waypoint after reaching the last, doing the patrol route as a loop. If this parameter is set to 'yes', the unit instead reverses its course and perpetually does out and backs of the route.

Here's an example of [micro_ai] tag usage from the "Patrols" [[Micro_AIs#Micro_AI_Test_and_Demo_Scenarios|test scenario]]:
[micro_ai]
side=2
ai_type=patrol
action=add

id=Konrad
waypoint_x=9,24,25
waypoint_y=21,23,15
one_time_only=yes
attack=Gertburt
[/micro_ai]

== Protect Unit Micro AI (ai_type=protect_unit) ==

The Protect Unit Micro AI tries to move one or several units to a given location while keeping them safe from enem attacks. It does so by keeping the protected units away from enemy units and close to friendly units. Other units on the AI side are controlled by the default Wesnoth AI.

For a demonstration, check out the "Protect Unit" and "The Elves Besieged" scenarios from the [[Micro_AIs#Micro_AI_Test_and_Demo_Scenarios|test scenario]].

Enable the Protect Unit Micro AI by using
ai_type=protect_unit
in the [micro_ai] tag.

===Protect Unit specific keys for the [micro_ai] tag:===

'''Required keys:'''

* '''[unit]''': A separate [unit] tag is required for each protected unit(s). Each tag has required keys id=, goal_x=, goal_y= for each unit, as shown in the example below.

'''Optional keys:'''

* '''disable_move_leader_to_keep'''=no: (boolean) If set to 'yes', side leaders protected by this AI do not try to return to their keep. This is necessary for this Micro AI to work with units that are side leaders and that are supposed to move to an off-keep location.

'''Notes:'''
*The Protect Unit Micro AI modifies the [[AiWML#Filtering_Combat_with_the_.27attacks.27_Aspect|attacks aspect]]. Depending on the parameters, it might also modify the [[AiWML#Evaluating_AI_Moves_--_Candidate_Actions_.28CAs.29|move leader to keep candidate action]].
* The CA evaluation scores of this AI are hard-coded. It does not work otherwise.

Here's an example of [micro_ai] tag usage from the "HttT: The Elves Besieged" [[Micro_AIs#Micro_AI_Test_and_Demo_Scenarios|test scenario]]:
[micro_ai]
side=1
ai_type=protect_unit
action=add

[unit]
id=Delfador
goal_x,goal_y=1,2
[/unit]
[unit]
id=Konrad
goal_x,goal_y=1,1
[/unit]

disable_move_leader_to_keep=true
[/micro_ai]

== Recruiting Micro AI==
=== General Comments on the Recruiting Micro AIs ===

The Recruiting Micro AI replaces the default recruitment AI by alternative recruiting patterns. Currently there are two recruiting algorithms you can choose from, random recruiting and the rush recruiting used in the new (as of Version 1.11.1) Experimental AI (see below).

For a demonstration of a different recruiting pattern, check out the "Recruiting" scenario from the [[Micro_AIs#Micro_AI_Test_and_Demo_Scenarios|test scenario]]. You can also explore the unit choices by watching the Experimental AI in a multiplayer game.

'''Note:''' Obviously, the Recruitment Micro AI modifies the [[AiWML#Evaluating_AI_Moves_--_Candidate_Actions_.28CAs.29|recruitment candidate action]].

=== Random Recruitment AI (ai_type=recruit_random) ===

This AI randomly selects a unit type from the recruitment list of the side. The probability of choosing each type and the behavior in low-gold situations can be influenced with optional parameters.

Enable the Random Recruiting Micro AI by using
ai_type=recruit_random
in the [micro_ai] tag.

'''Required keys:'''

There are no required keys.

'''Optional keys:'''

* '''ca_score'''=180000: (non-negative integer) The evaluation score of the candidate action controlling this Micro AI. By default, it is set to 180,000. This is identical to the default Recruiting CA which it replaces.
* '''[probability]''': This tag sets the probability of selecting the given unit type. It has two required sub-keys:
** '''type''': comma-separated list of unit types to which this probability is to be applied
** '''probability''': (non-negative float) The probability with which these unit types is to be selected. All unit types for which no [probability] tag is defined receive a default probability of 1.0, thus values should be chosen relative to that. As an example, in the code below swordsmen and peasants are given a probability of 8, while no other units have assigned probabilities. Thus, each of these two unit types is 8 times more likely to be selected than any other individual unit type.
* '''skip_low_gold_recruit'''=no: (boolean) By default, the random recruitment AI chooses a unit to recruit only from those types for which it has sufficient gold. If this parameter is set to 'yes', it will instead choose from all available unit types and end recruiting for the turn if there is not enough gold to recruit it this turn (even if other, affordable unit types exist).

Here's an example of a random recruiting [micro_ai] tag usage from the "Recruiting" [[Micro_AIs#Micro_AI_Test_and_Demo_Scenarios|test scenario]]:
[micro_ai]
side=1
ai_type=recruit_random
action=add

[probability]
type=Swordsman,Peasant
probability=8
[/probability]

skip_low_gold_recruiting=yes
[/micro_ai]

=== Rush Recruitment AI (ai_type=recruit_rushers) ===

This AI replaces the default recruiting with the rush recruiting used in the new (as of Version 1.11.1) Experimental AI.

Enable the Rush Recruiting Micro AI by using
ai_type=recruit_rushers
in the [micro_ai] tag.

'''Required keys:'''

There are no required keys.

'''Optional keys:'''

* '''ca_score'''=180000: (non-negative integer) The evaluation score of the candidate action controlling this Micro AI. By default, it is set to 180,000. This is identical to the default Recruiting CA which it replaces.
* '''randomness'''=0.1: (number) A random number is applied to the rusher recruit engine's score to prevent the recruitment pattern from being too predictable. 0 causes no randomness to be applied, while larger numbers increase the random effect. A value of 1-2 generates results in which the random effect is approximately equal to the scored effect. Extremely high values are essentially entirely random.

Here's an example of a rush recruiting [micro_ai] tag usage from the "Recruiting" [[Micro_AIs#Micro_AI_Test_and_Demo_Scenarios|test scenario]]:
[micro_ai]
side=1
ai_type=recruit_rushers
action=add
[/micro_ai]

== Simple Attack Micro AI (ai_type=simple_attack) ==

The Simple Attack Micro AI is meant as an addition to the default combat candidate action for when one wants to force the AI to do attacks that it would otherwise not do (for example on units that are 1 XP from leveling) or to execute certain attacks before all others (for example, attack with all "expendable" units first). It is not set up to be a replacement for the default attacks. Some notes:

* The algorithm is different from and simpler than that of the default combat CA. For example, no attack combinations are considered, only individual attacks. As a result, the [[AiWML#The_.5Bai.5D_Tag:_Defining_Aspects|default aspects]] (aggression, caution, [avoid], ...) are not taken into account. Also, if lots of units are involved, evaluation of this Micro AI is potentially quite a bit slower than of the default attacks.

* If an attack matching the Standard Unit Filters described below is found, this attack will always be executed, no matter how bad the odds are. Thus, this Micro AI can be used to force the AI to do attacks it would otherwise avoid.

* Other than selecting the attacker/defender units, this AI is currently not configurable. Let us know if you would like to see certain options to be added. (No guarantees that we will add them, but we will definitely consider them.)

For a demonstration, check out the "Simple Attack" scenario from the [[Micro_AIs#Micro_AI_Test_and_Demo_Scenarios|test scenario]].

Enable the Simple Attack Micro AI by using
ai_type=simple_attack
in the [micro_ai] tag.

===Simple Attack specific keys for the [micro_ai] tag:===

'''Required keys:'''

There are no required keys. It is, however, in general not desirable to use this AI without at least one of the optional Standard Unit Filters below, as this AI is not meant as a replacement of the default combat candidate action.

'''Optional keys:'''

* '''ca_score'''=110000: (non-negative integer) The evaluation score of the candidate action controlling this Micro AI. By default, it is set to 110,000, which means that it is executed right before the default combat candidate action.
* '''[filter]''': A [[StandardUnitFilter|Standard Unit Filter]] selecting the units of the AI side participating in the Simple Attack action. It defaults to all units of the side. The filter automatically includes the side= key set to the AI side.
* '''[filter_second]''': A [[StandardUnitFilter|Standard Unit Filter]] selecting the units the AI should attack. It defaults to all enemy units. The filter automatically includes a [[StandardSideFilter|Standard Side Filter]] set to all enemies of the AI side.
* '''weapon'''=-1: (integer) The number of the weapon that should be used for this attack. Weapon numbers start at 1 (not 0). -1 stands for "best weapon" (by whatever criterion the AI chooses to use). '''Available from Wesnoth 1.11.8'''

Below are 2 examples of Simple Attack Micro AI configurations from the "Simple Attack" [[Micro_AIs#Micro_AI_Test_and_Demo_Scenarios|test scenario]]. The first one shows how to force the AI to attack with all Soulless and Walking Corpse units first:
[micro_ai]
side=2
ai_type=simple_attack
action=add

ca_score=110000
[filter]
type=Soulless,Walking Corpse
[/filter]
[/micro_ai]
The second executes attacks by Soulless on all enemy units that are 1 XP from leveling (something the RCA AI would generally not do). Note that the Lua code bit is simply there in order to code the "1 XP from advancing" condition. It is not needed for most other SUFs, as can be seen in the previous example.
[lua]
code=<<
function close_to_advancing(unit)
if (unit.experience >= unit.max_experience-1) then
return true
else
return false
end
end
>>
[/lua]

[micro_ai]
side=2
ai_type=simple_attack
action=add

ca_score=110001
[filter]
type=Soulless # No Walking Corpses; L0 units don't advance enemy
[/filter]
[filter_second]
lua_function = "close_to_advancing"
[/filter_second]
[/micro_ai]
Several Simple Attack Micro AIs can be combined for the same AI side. The two examples above are both used (note the different values for ca_score) in the "Simple Attack" [[Micro_AIs#Micro_AI_Test_and_Demo_Scenarios|test scenario]].

== Using Development (1.13) Version Micro AIs in your Stable (1.12) Version Add-on ==

The Micro AIs will be in a stable release for the first time in Wesnoth 1.12. It is therefore likely that quite a few (good) feature requests will be made as more UMC authors start using them. However, new features cannot be added to the stable 1.12 series and will be implemented in Wesnoth 1.13 instead. Fortunately, since the Micro AIs are entirely written in Lua, a 1.13 Micro AI can be added to a 1.12 add-on with relative ease. This section describes the steps necessary to accomplish that.

==== 1. Download the latest development release and locate the Micro AIs directory in it ====

The Micro AI directory in each Wesnoth distribution is <tt>data/ai/micro_ais</tt>. Check out [http://wiki.wesnoth.org/Editingwesnoth#The_game_data_directory this link] if you do not know where that is on your system.

As an alternative to downloading the entire development release, you can also download only the files in which you are interested from the [https://github.com/wesnoth/wesnoth/ Wesnoth repository site].

==== 2. Copy the relevant files into your add-on ====

* In your add-on's folder, create a directory <tt>ai</tt>
* Copy file <tt>data/ai/micro_ais/micro_ai_wml_tag.lua</tt> from the development release into the new <tt>ai</tt> folder in your add-on
* In <tt>data/ai/micro_ais</tt> is a subfolder called <tt>cas</tt> containing all the AI candidate action (CA) files. Copy the files for the Micro AI you want to use from there into the <tt>ai</tt> folder of your add-on. The number of relevant files depends on the Micro AI. For example, the Patrol Micro AI only uses a single file (<tt>ca_patrol.lua</tt>), while there are four for the Messenger Escort Micro AI (<tt>ca_messenger_attack.lua</tt>, <tt>ca_messenger_escort_move.lua</tt>, <tt>ca_messenger_f_next_waypoint.lua</tt> and <tt>ca_messenger_move.lua</tt>).

==== 3. Set up a local Micro AI tag ====

Open file <tt>micro_ai_wml_tag.lua</tt> (the one in your add-on, not the original) and find these two lines:
function wesnoth.wml_actions.micro_ai(cfg)
local CA_path = ''''ai/micro_ais/cas/''''
Modify them to (the pars to change are shown in bold)
function wesnoth.wml_actions.micro_ai'''_MC'''(cfg)
local CA_path = ''''~add-ons/My_Campaign/''''
<tt>_MC</tt> here stands for 'My Campaign'. You can really use anything you want here, as long as you use it consistently throughout the next steps. Also, you obviously need to adapt the second line to contain the correct path for your add-on.

You also need to add the following to your <tt>_main.cfg</tt> file
[lua]
code = << wesnoth.dofile("~add-ons/My_Campaign/ai/micro_ai_wml_tag.lua") >>
[/lua]
replacing, again, <tt>My_Campaign</tt> with the correct path to your add-on.

These two steps set up a WML tag <tt>[micro_ai_MC]</tt> which you can use in exactly the same way as the mainline <tt>[micro_ai]</tt> tag, just that it contains the functionality of the new files you just copied into the <tt>ai</tt> folder of your add-on. However, it might not quite work correctly yet as the paths in some of the files still might have to be adjusted.

==== 4. Adjust paths in the files ====

All of the candidate action files load other libraries (files) at the beginning. For example, this is the beginning of <tt>ca_messenger_attack.lua</tt>
local H = wesnoth.require "lua/helper.lua"
local AH = wesnoth.require "ai/lua/ai_helper.lua"

local messenger_next_waypoint = wesnoth.require "ai/micro_ais/cas/ca_messenger_f_next_waypoint.lua"

The most difficult part of setting up the Micro AI in your add-on is figuring out which of these files need to be imported and linked in your add-on directory. Anything that belongs to the same Micro AI definitely needs to be changed. Thus, the last line needs to be changed to
local messenger_next_waypoint = wesnoth.require "~add-ons/My_Campaign/ai/ca_messenger_f_next_waypoint.lua"

For all other files included by the CA file (that is <tt>lua/helper.lua</tt> and <tt>ai/lua/ai_helper.lua</tt> in the example above), it depends on whether they have been changed between the version of Wesnoth 1.12 you are using and the development version from which you are copying the Micro AI; and more importantly, whether the part of them which the Micro AI uses has been changed. In principle, you could import and change all files that are linked from the <tt>ca_*.lua</tt> files, but that would result in a lot of unnecessary code duplication and should be avoided. It's better to compare the files (do a 'diff') between the stable and the development version and decide based on that. If in doubt, just [http://forums.wesnoth.org/viewtopic.php?f=10&t=39456 ask] and we will tell you.

As an example, let's assume that file <tt>ai_helper.lua</tt> has been changed. In that case, it needs to be copied from <tt>data/ai/lua/ai_helper.lua</tt> in the development version (note that the paths shown in the example above do not include the leading <tt>data/</tt>) and copied into your add-on's <tt>ai</tt> directory. And finally, as a last step, the line including the file inside <tt>ca_messenger_attack.lua</tt> needs to be changed to point to the newly created local copy:
local AH = wesnoth.require "~add-ons/My_Campaign/ai/ai_helper.lua"
Repeat this step for all the <tt>ca_*.lua</tt> files.

Well, that's all. You can now use the <tt>[micro_ai_MC]</tt> tag for the Micro AI you just imported, and continue to use the default <tt>[micro_ai]</tt> tag for all others. It does take a bit of work, but it (hopefully) is much easier than writing your own AI from scratch. If you have any problems with this, please don't hesitate to [http://forums.wesnoth.org/viewtopic.php?f=10&t=39456 ask us for help].

[[Category:AI]]

Garardine Dynasty

2014-05-18T20:35:49Z

Aquileia: Fix Asheviere spelling... the faulty image isn't changed, though

The Garardine Dynasty began with the ascension of [http://wiki.wesnoth.org/WesnothFigures#Garard_I Garard I] to the throne of Wesnoth in 417. Though there were a number of periods of turmoil, the Garardine Dynasty is (aside from the reign of [http://wiki.wesnoth.org/WesnothFigures#Asheviere Queen Asheviere]) regarded as a strong and prosperous period for the Kingdom of Wesnoth. Most of the monarchs of the Garardine Dynasty are considered to have been good and just rulers [citation needed].

Queen Asheviere was the exception to this trend. Though she maneuvered her son into position to take the crown from [http://wiki.wesnoth.org/WesnothFigures#Garard_II Garard II] after defeating him in battle, [http://wiki.wesnoth.org/WesnothFigures#Eldred Prince Eldred] died shortly afterward and was never actually crowned king. This put Asheviere in a dangerous situation, since the only remaining offspring of Garard II was the three-year old [http://wiki.wesnoth.org/WesnothFigures#Li.27sar Princess Li'sar]. Though Li'sar was legally the next in line for the throne, Asheviere's dishonourable behaviour made it likely that one of her nephews might claim the royal scepter. To prevent this eventuality she had them all killed and assumed the throne herself. However, the reign of Asheviere is not considered part of the Garardine dynasty by some historians because Asheviere was not descended from Garard I and therefore not of royal blood. In this view the dynasty was therefore restored with the ascension of Queen Li'sar to the throne in 518.

When Li'sar became queen, she married [http://wiki.wesnoth.org/WesnothFigures#Konrad Konrad I], and though technically the legal authority lay solely in Li'sar's hands, she and Konrad I ruled jointly as king and queen. Though Konrad was presented to the public as the youngest son of Prince Arand, and therefore of royal blood, he was actually an orphan groomed by the mage [http://wiki.wesnoth.org/WesnothFigures#Delfador Delfador] to take the place of the dead prince.

The Garardine Dynasty met its greatest threat at the hands of the evil necromancer [http://wiki.wesnoth.org/WesnothFigures#Mal_Ravanal Mal-Ravanal]; though Asheviere had alienated Wesnoth's neighbours and allies, Mal-Ravanal's invasion had much greater long-term consequences. Mal-Ravanal's attack in 626-627 devastated a great deal of the kingdom, and though it was ultimately turned back the consequences to the kingdom were severe, with large parts of central Wesnoth having been turned into a wasteland. Though [http://wiki.wesnoth.org/WesnothFigures#Konrad_II Konrad II] attempted to rebuild the kingdom afterward it is clear that the kingdom was entering a steep decline.

The Garardine Dynasty formally ended with the death of King Konrad II in 673 after a 61-year reign, though many claimants to the throne had enough royal blood to continue the dynasty had they managed to assert control over the Kingdom of Wesnoth. Instead the Kingdom descended into civil war and no one ruler ever gained control over the kingdom until the invasion of the Akladians 165 years later. However, descendents of Garard did retain control of the region around Weldyn (they referred to this region as 'The Kingdom of Wesnoth' even though it contained less than one tenth of the land of the original nation). It was a descendent of these rulers that married the Hagarthen king of Vakladia, and whose son in around 900 YW became King Gawen Haldric Hagarthen, the first Garardine to rule all of Wesnoth in more than 250 years.

The monarchs of the Garardine Dynasty are:

* 417-470 [http://wiki.wesnoth.org/WesnothFigures#Garard_I Garard I]
* 473-501 [http://wiki.wesnoth.org/WesnothFigures#Garard_II Garard II]
* 501-518 [http://wiki.wesnoth.org/WesnothFigures#Asheviere Asheviere]
* 518-563 [http://wiki.wesnoth.org/WesnothFigures#Li.27sar Li'sar] & [http://wiki.wesnoth.org/WesnothFigures#Konrad Konrad I]
* 563-585 Ana'sar
* 585-612 Haldric VII
* 612-673 [http://wiki.wesnoth.org/WesnothFigures#Konrad_II Konrad II]

http://exong.net/wesnoth-attach/files/garardine_dynasty_581.png

(The death dates of Garard I and Konrad II, and the accession date of Garard II, are erroneous on this chart, having been revised in light of later historical findings.)

[[Category:World of Wesnoth]]

Download/zh-Hans

2014-04-26T00:26:55Z

Aquileia:

{{Download/Translations}}
欢迎来到韦诺之战下载页。韦诺之战项目团队只发布官方源代码。二进制包由社区志愿者提供并在此存档。BT种子也是非官方的。

如果对应你操作系统的最新二进制可执行文件没有提供，请过几天再来查看是否发布。打包者已经被通知了这个发布，请保持耐心。在此期间，请阅读[[FAQ#A_new_version_is_out.2C_but_where_is_the_download_for_.5BWindows.2C_Mac_OS.2C_etc..5D.3F|常见问题]]。

__NOTOC__
跳至： [[Download/zh-Hans#稳定版（1.10 分支）|稳定版分支]] | [[Download/zh-Hans#稳定版（旧版）|稳定版分支（旧版）]] | [[Download/zh-Hans#开发版（1.11分支）|开发版分支]]

== 稳定版（1.10 分支） ==
稳定版文件意味着被用来作为一个稳定且平衡的游戏版本。1.10分支的每一个版本相互兼容。

版本1.10.7是最新的稳定版。这个版本推荐给绝大多数玩家，因为1.10在线多人游戏社区很庞大，而且用户自制战役服务器也有很好的内容选择。

==== Source code 源代码 ====
* [[CompilingWesnoth|编译指导]] - 如何编译源代码
{{StableDownload|当前版本|先前版本|当前源代码包的md5sum值|微软视窗操作系统|麦金塔操作系统}}

==== GNU/Linux ====
* 有许多二进制文件对应于不同的Linux发行版。不是所有的都已及时更新到最新版。请查阅[[WesnothBinariesLinux|Linux二进制包页]]寻找对应于你的发行版的二进制包信息。

==== 杂项 ====
* [http://www.wesnoth.org/wiki/Download_Xdeltas#Stable_Version_1.10.x 源代码的Xdelta]
* [http://sourceforge.net/projects/wesnoth/files/ 当前和所有先前版本的SourceForge页]

== 开发版（1.11分支） ==
版本1.11.x 是最新的开发版，拥有升级的图像和令人兴奋的新特性。然而，在开发版里可能有偶尔的错误或性能问题，因为总是有着很多大的修改。为了平衡和稳定地游戏，强烈推荐你使用1.10.x分支的最新版。开发版是推荐给程序员和战役开发者，也给那些想要预览韦诺新特性的人。熟悉SVN和编译的人可以从[[WesnothRepository]]中检出最新的开发版。

==== Source code 源代码 ====
* [[CompilingWesnoth|编译指导]] - 如何编译源代码
{{DevDownload|当前版本|先前版本|当前源代码包的md5sum值|微软视窗操作系统|麦金塔操作系统}}

==== GNU/Linux ====
* 有许多二进制文件对应于不同的Linux发行版。不是所有的都已及时更新到最新版。请查阅[[WesnothBinariesLinux|Linux二进制包页]]寻找对应于你的发行版的二进制包信息。

==== 杂项 ====
* [http://wiki.wesnoth.org/Download_Xdeltas#Development_Version_1.11.x 源代码的Xdelta]
* [http://sourceforge.net/projects/wesnoth/files/ 当前和所有先前版本的SourceForge页]
* [http://sourceforge.net/projects/wesnoth/files/unofficial/Mac%20Compile%20Stuff/wesnoth_compile_mac_1.9.zip/download MacCompileStuff for 1.9]

== 许可 ==
'''主要文章：[[Wesnoth:Copyrights|版权声明]]

本程序为自由软件；您可依据[http://www.fsf.org Free Software Foundation|自由软件基金会]所发表的[http://www.fsf.org/copyleft/gpl.html GNU General Public License version 2|GNU通用公共许可证第2版]条款规定，就本程序再为发布与／或修改。
本程序是基于使用目的而加以发布，然而不负任何担保责任；亦无对适售性或特定目的适用性所为的默示性担保。详情请参照GNU通用公共授权。

== UMC 编辑器 ==
这提供给韦诺之战1.9.x和更高版本（包括韦诺之战1.10.x）。
细节和安装步骤可以在http://eclipse.wesnoth.org 找到。

== 参见 ==
* [http://changelog.wesnoth.org 更新日志]
* [[WesnothBinaries|更多二进制文件]]
* [[WesnothRepository]] - SVN中最前沿的版本

[[Category:Building and Installing]]

Download/ru

2014-04-26T00:26:13Z

Aquileia:

{{Download/Translations}}
Добро пожаловать на страницу загрузки «Битвы за Веснот». Команда проекта BFW официально поставляет только исходный код, бинарные пакеты же предоставлены добровольцами сообщества и размещаются на этой странице. Торренты тоже официально не поддерживаются.

Если сборки последней версии игры для вашей ОС еще не доступны, то, возможно, они появятся на этой странице спустя какое-то время. Попробуйте проверить через несколько дней. Люди, занимающиеся сборкой, знают о релизе, поэтому, пожалуйста, запаситесь терпением. А тем временем можете прочесть [[FAQ#A_new_version_is_out.2C_but_where_is_the_download_for_.5BWindows.2C_Mac_OS.2C_etc..5D.3F|FAQ]].

__NOTOC__
Перейти к: [[Download/ru#Стабильные_версии_.28ветка_1.10.29|Стабильная ветка]] | [[Download/ru#Стабильные_.28старые_версии.29|Стабильная ветка (старые версии)]] | [[Download/ru#Разработка_.28ветка_1.11.29|Ветка разработки]]

== Стабильные версии (ветка 1.10) ==
Стабильные файлы предлагается использовать в том случае, если нужна стабильная и одновременно сбалансированная версия игры. Все версии ветки 1.10 совместимы друг с другом.

Версия 1.10.7 на данный момент является последней стабильной версией. Эта версия рекомендуется для большинства игроков, поскольку в многопользовательской игре сообщество 1.10 очень большое и созданный пользователями сервер кампаний предлагает богатый выбор контента.

==== Исходный код ====
* [[CompilingWesnoth|Гайд по компилированию]] - как откомпилировать исходный код
{{StableDownload|Текущая версия|Предыдущая версия|md5sum для исходников текущей версии}}

==== GNU/Linux ====
* Существуют пакеты для множества различных дистрибутивов GNU/Linux. Не все из них обновляются с выходом нового релиза игры. Пожалуйста, ознакомьтесь с [[WesnothBinariesLinux|Страница сборок для Linux]] для того, чтобы узнать больше информации о сборках для вашего дистрибутива.

==== Дополнительно ====
* [http://www.wesnoth.org/wiki/Download_Xdeltas#Stable_Version_1.10.x Xdelta для исходного кода]
* [http://sourceforge.net/projects/wesnoth/files/ Страница на SourceForge для текущей и всех предыдущих версий]

== Разработка (ветка 1.11) ==
1.11.x - это новая, разрабатываемая в настоящий момент версия, которая может похвастаться усовершенствованной графикой и новыми волнующими возможностями. Однако в версиях разработки могут быть баги или проблемы производительности из-за крупных изменений, постоянно вводимых в код. Для сбалансированной и стабильной игры рекомендуется использовать наиболее свежую версию ветки 1.10.x. Эта версия рекомендуется как для кодеров и разработчиков кампаний, так и для тех, кто хочет увидеть, что ждет Веснот в будущем. Люди, знакомые с системой контроля версий и компилированием, могут следить за разработкой здесь: [[WesnothRepository]].

==== Исходный код ====
* [[CompilingWesnoth|Гайд по компилированию]] - как откомпилировать исходный код
{{DevDownload|Текущая версия|Предыдущая версия|md5sum для исходников текущей версии}}

==== GNU/Linux ====
* Существуют пакеты для множества различных дистрибутивов GNU/Linux. Не все из них обновляются с выходом нового релиза игры. Пожалуйста, ознакомьтесь с [[WesnothBinariesLinux|Страница сборок для Linux]] для того, чтобы узнать больше информации о сборках для вашего дистрибутива.

==== Дополнительно ====
* [http://wiki.wesnoth.org/Download_Xdeltas#Development_Version_1.11.x Xdelta для исходного кода]
* [http://sourceforge.net/projects/wesnoth/files/ Страница на SourceForge для текущей и всех предыдущих версий]
* [http://sourceforge.net/projects/wesnoth/files/unofficial/Mac%20Compile%20Stuff/wesnoth_compile_mac_1.9.zip/download MacCompileStuff для 1.9]

== Лицензия ==
''Main article: [[Wesnoth:Copyrights]]

This program is free software; you can redistribute it and/or modify it under the terms of the [http://www.fsf.org/copyleft/gpl.html GNU General Public License version 2], as published by the [http://www.fsf.org Free Software Foundation].
This program is distributed in the hope that it will be useful, but without any warranty; without even the implied warranty of merchantability or fitness for a particular purpose. See the GNU General Public License for more details.

== UMC Editor ==
Доступно для версий Wesnoth 1.9.x и выше (включая Wesnoth 1.10.x).
Подробности и шаги по установке вы можете найти на:
http://eclipse.wesnoth.org

== Смотрите также ==
* [http://changelog.wesnoth.org Список изменений]
* [[WesnothBinaries| Другие сборки]]
* [[WesnothRepository]] - новейшая версия из репозитория

[[Category:Building and Installing]]

Download/de

2014-04-26T00:25:39Z

Aquileia:

{{Download/Translations}}
Willkommen auf der Battle for Wesnoth-Downloadseite. Das BfW-Team veröffentlicht offiziell nur den Quelltext. Binärpakete werden nur von Freiwilligen aus der Gemeinschaft zur Verfügung gestellt und hier angeboten.

Wenn die neuesten Binärpakete für dein Betriebssystem momentan noch nicht verfügbar sind, überprüfe einfach alle paar Tage ob du sie hier finden kannst. Die jeweilig Verantwortlichen wurden informiert, bitte habe etwas Geduld. In der Zwischenzeit kannst du die [[/FAQ/de#Eine_neue_Version_wurde_ver.C3.B6ffentlicht.2C_aber_wo_kann_man_die_.5BWindows.2C_Mac_OS_X.2C_usw..5D-Version_herunterladen.3F|FAQ-Seite]] lesen.

__NOTOC__
Springen zu: [[Download/de#Hauptversion (1.10-Zweig)|Hauptversion]] | [[Download/de#Ältere Hauptversionen|Ältere Hauptversionen]] | [[Download/de#Entwicklungsversion (1.11-Zweig)|Entwicklungsversion]]

== Hauptversion (1.10-Zweig) ==
Die Hauptversion ist eine stabile und ziemlich ausgewogene Version des Spiels. Alle Versionen des 1.10-Zweigs sind miteinander kompatibel.

Version 1.10.7 ist die neueste Hauptversion. Diese Version ist für die meisten Spieler zu empfehlen, da die 1.10-Mehrspielergemeinschaft riesig ist und der Erweiterungsserver eine ordentliche Auswahl anbietet.

==== Quelltext ====
* [[CompilingWesnoth|Kompilierungsanleitung]] - wie man den Quelltext kompiliert
{{StableDownload|Neueste Version|Vorherige Version|md5sum für den aktuellen Quelltext}}

==== GNU/Linux ====
* Es gibt Binärpakete für viele verschiedene GNU/Linux-Distributionen. Nicht alle sind immer auf dem Stand der neuesten Version. Für mehr Informationen über die Binärpakete für deine Distribution lies bitte die [[WesnothBinariesLinux|entsprechende Seite]].

==== Verschiedenes ====
* [http://www.wesnoth.org/wiki/Download_Xdeltas#Stable_Version_1.10.x Xdelta für den Quelltext]
* [http://sourceforge.net/projects/wesnoth/files/ SourceForge-Seite für die aktuellen und alle vorherigen Versionen]

== Entwicklungsversion (1.11-Zweig) ==
Version 1.11.x ist die neueste Entwicklungsversion, die verbesserte Grafik und neue aufregende Inhalte vorstellt. Allerdigs können auch Programmierfehler oder andere Probleme auftreten, da schwerwiegende Änderungen stattfinden.



Derzeit befindet sich Wesnoth 1.11 in der Beta-Phase für die kommende Hauptversion 1.12. Entwickler und Spieler sind zu diesem Anlass ermuntert, die neuen Funktionen auszuprobieren und gegebenenfalls vorhandene Fehler zu berichten, damit diese vor 1.12.0 behoben werden können.

Wer mit Versionskontrolle und Kompilierung vertraut ist, kann der aktuellen Entwicklung durch das Überprüfen von [[WesnothRepository]] folgen.

==== Quelltext ====
* [[CompilingWesnoth|Kompilierungsanleitung]] - wie man den Quellext kompiliert
{{DevDownload|Neueste Version|Vorherige Version|md5sum für den aktuellen Quelltext}}

==== GNU/Linux ====
* Es gibt Binärpakete für viele verschiedene GNU/Linux-Distributionen. Nicht alle sind immer auf dem Stand der neuesten Version. Für mehr Informationen über die Binärpakete für deine Distribution lies bitte die [[WesnothBinariesLinux|entsprechende Seite]].

==== Verschiedenes ====
* [http://wiki.wesnoth.org/Download_Xdeltas#Development_Version_1.11.x Xdelta für den Quelltext]
* [http://sourceforge.net/projects/wesnoth/files/ SourceForge-Seite für die aktuelle und alle vorherigen Versionen]
* [http://sourceforge.net/projects/wesnoth/files/unofficial/Mac%20Compile%20Stuff/wesnoth_compile_mac_1.9.zip/download MacCompileStuff für 1.9]

== Lizenz ==
''Hauptartikel: [[Wesnoth:Copyrights]]

Dieses Programm ist freie Software; du kannst es weitervertreiben und/oder modifizieren, solange das unter den Bedingungen der [http://www.fsf.org/copyleft/gpl.html GNU General Public License version 2] bleibt, veröffentlicht von der [http://www.fsf.org Free Software Foundation].
Dieses Programm wird mit der Hoffnung vertrieben, dass es nützlich ist, allerdings ohne Garantie; ohne die auch nur angedeutete Garantie auf Marktgängigkeit oder Eignung für eine bestimmte Absicht. Siehe die GNU Allgemeine Öffentliche Lizenz für mehr Informationen.

== Erweiterungseditor ==
Dieser ist für 1.9.x (und höher, einschließlich 1.10.x) verfügbar.
Details und Installationsanweisungen snd auf http://eclipse.wesnoth.org zu finden.

== Siehe auch ==
* [http://changelog.wesnoth.org Versionshistorie]
* [[WesnothBinaries| Mehr Binärpakete]]
* [[WesnothRepository]] - bleeding-edge-Version von Quelle

[[Category:Building and Installing]]

Download/es

2014-04-26T00:25:03Z

Aquileia:

{{Download/Translations}}

Bienvenido a la página de descargas de ''La Batalla por Wesnoth''. El equipo de ''La Batalla por Wesnoth'' sólo publica de forma oficial el código fuente. Los paquetes binarios son proporcionados por voluntarios y alojados aquí. Los torrents tampoco son oficiales.

Si la última versión de los binarios no está disponible para tu sistema operativo, por favor vuelve a comprobar en unos días si ya lo está. Se ha informado convenientemente a los empaquetadores, así que debes ser paciente. Durante la espera puedes leer las [[FAQ#A_new_version_is_out.2C_but_where_is_the_download_for_.5BWindows.2C_Mac_OS_X.2C_etc..5D.3F | preguntas frecuentes]] a este respecto.

__NOTOC__
Ir a: [[#Estable_.28rama_1.10.29 | Rama estable]] | [[#Estable_.28versiones_antiguas.29 | Rama estable (versiones antiguas)]] | [[#Desarrollo_.28rama_1.11.29 | Rama de desarrollo]]

== Estable (rama 1.10) ==
Las publicaciones de las ramas estables están destinadas a ser utilizadas como versiones del juego estables y equilibradas. Cada versión de la rama 1.10 es compatible con las otras.

La version 1.10.6 es la última versión estable. Ésta es la versión recomendada para la mayoría de los jugadores ya que la comunidad multijugador en línea de la versión 1.10 es muy extensa y el servidor de campañas de usuario garantiza la selección de contenidos robustos.

==== Código fuente ====
* [[CompilingWesnoth | Guía de compilación]] - cómo compilar el código fuente
{{StableDownload|Versión actual|Versión anterior|Control md5sum para el código fuente actual}}

==== GNU/Linux ====
* Existen binarios para muchas distribuciones diferentes de GNU/Linux. No siempre están todos actualizados a la última publicación. Por favor, echa un vistazo a la [[WesnothBinariesLinux | página de binarios para Linux]] para obtener más información sobre los binarios de tu distribución.

==== Miscelánea ====
* [http://www.wesnoth.org/wiki/Download_Xdeltas#Stable_Version_1.10.x Xdelta para el código fuente]
* [http://sourceforge.net/projects/wesnoth/files/ Página de SourceForge para la versión actual y todas las anteriores]

== Desarrollo (rama 1.11) ==
La versión 1.11.x es la última versión de desarrollo y luce gráficos actualizados y nuevas y emocionantes características. Sin embargo, puede haber errores o problemas de rendimiento en las versiones de desarrollo debido a que se realizan grandes cambios continuamente. Para un juego equilibrado y estable, se recomienda el uso de la última versión estable de la rama 1.10.x. Esta versión está recomendada para programadores y desarrolladores de campañas, y también para aquellos que deseen prever el futuro de Wesnoth. Las personas familiarizadas con los sistemas de control de versiones podrán seguir los últimos desarrollos en el [[WesnothRepository | Repositorio de Wesnoth]].

==== Código fuente ====
* [[CompilingWesnoth | Guía de compilación]] - cómo compilar el código fuente
{{DevDownload|Versión actual|Versión anterior|Control md5sum para el código fuente actual}}

==== GNU/Linux ====
* Existen binarios para muchas distribuciones diferentes de GNU/Linux. No siempre están todos actualizados a la última publicación. Por favor, echa un vistazo a la [[WesnothBinariesLinux | página de binarios para Linux]] para obtener más información sobre los binarios de tu distribución.

==== Miscelánea ====
* [http://wiki.wesnoth.org/Download_Xdeltas#Development_Version_1.11.x Xdelta para el código fuente]
* [http://sourceforge.net/projects/wesnoth/files/ Página de SourceForge para la versión actual y todas las anteriores]
* [http://sourceforge.net/projects/wesnoth/files/unofficial/Mac%20Compile%20Stuff/wesnoth_compile_mac_1.9.zip/download MacCompileStuff para 1.9]

== Licencia ==
''Artículo principal: [[Wesnoth:Copyrights]]

Este programa es software libre; puedes redistribuirlo o modificarlo bajo los términos de la [http://www.gnu.org/licenses/gpl-2.0.html GNU General Public License, versión 2], publicada por la [http://www.fsf.org Free Software Foundation]. Este programa se distribuye con la esperanza de que sea útil, pero sin ninguna grantía; incluso sin la garantía implícita de comerciabilidad o aptitud para un propósito particular. Vea la Licencia Pública General de GNU para más detalles.

== Editor UMC ==
Disponible para Wesnoth 1.9.x y superiores (incluyendo Wesnoth 1.10.x).
Se puede encontrar una descripción detallada y una guía de instalación en: http://eclipse.wesnoth.org.

== Véase también ==
* [http://changelog.wesnoth.org Log de cambios]
* [[WesnothBinaries | Más binarios]]
* [[WesnothRepository | Repositorio de Wesnoth]] - Obtener la última versión desde el repositorio

[[Category:Building and Installing]]

Download/zh-Hans

2014-04-25T22:21:33Z

Aquileia: Move md5sum to template

{{Download/Translations}}
欢迎来到韦诺之战下载页。韦诺之战项目团队只发布官方源代码。二进制包由社区志愿者提供并在此存档。BT种子也是非官方的。

如果对应你操作系统的最新二进制可执行文件没有提供，请过几天再来查看是否发布。打包者已经被通知了这个发布，请保持耐心。在此期间，请阅读[[FAQ#A_new_version_is_out.2C_but_where_is_the_download_for_.5BWindows.2C_Mac_OS.2C_etc..5D.3F|常见问题]]。

__NOTOC__
跳至： [[Download/zh-Hans#稳定版（1.10 分支）|稳定版分支]] | [[Download/zh-Hans#稳定版（旧版）|稳定版分支（旧版）]] | [[Download/zh-Hans#开发版（1.11分支）|开发版分支]]

== 稳定版（1.10 分支） ==
稳定版文件意味着被用来作为一个稳定且平衡的游戏版本。1.10分支的每一个版本相互兼容。

版本1.10.7是最新的稳定版。这个版本推荐给绝大多数玩家，因为1.10在线多人游戏社区很庞大，而且用户自制战役服务器也有很好的内容选择。

==== Source code 源代码 ====
* [[CompilingWesnoth|编译指导]] - 如何编译源代码
{{StableDownload|当前版本|先前版本|当前源代码包的md5sum值|微软视窗操作系统|麦金塔操作系统}}

==== GNU/Linux ====
* 有许多二进制文件对应于不同的Linux发行版。不是所有的都已及时更新到最新版。请查阅[[WesnothBinariesLinux|Linux二进制包页]]寻找对应于你的发行版的二进制包信息。

==== 杂项 ====
* [http://www.wesnoth.org/wiki/Download_Xdeltas#Stable_Version_1.10.x 源代码的Xdelta]
* [http://sourceforge.net/projects/wesnoth/files/ 当前和所有先前版本的SourceForge页]

== 稳定版（旧版） ==
一些操作系统没有提供最新稳定版的二进制文件。这是给不少系统已知的最近二进制文件的表单。那些旧版本往往已经没有官方多人游戏和插件服务器提供了。

==== AmigaOS4 ====
* [http://www.amigasoft.net/pages/games/download/Wesnoth186.lha.lzh 旧版] (1.8.6, 300MB)

==== (Open)Solaris ====
* [http://sourceforge.net/projects/wesnoth/files/wesnoth-1.4/wesnoth-1.4.5/wesnoth-solaris-i386-1.4.5.pkg.bz2/download 旧版] (1.4.5, 145.6 MB)，1.6.x版已经没有编译

==== OS/2 & eComStation ====
* [http://download.smedley.info/wesnoth-1.4.5-os2-20080828.zip 旧版] (1.4.5, 160 MB)，1.6.x版已经没有编译

==== RISC OS ====
*[http://www.riscos.info/packages/arm/Games/wesnoth_1.4.5-1.zip 旧版] (1.4.5-1, 140MB)，1.6.x版已经没有编译

==== Syllable ====
* [http://downloads.syllable.org/Syllable/i586/applications/contributed/Battle-for-Wesnoth/Battle-for-Wesnoth-1.2.6.application 旧版] (1.2.6, 60.8 MB)，1.6.x版已经没有编译

== 开发版（1.11分支） ==
版本1.11.x 是最新的开发版，拥有升级的图像和令人兴奋的新特性。然而，在开发版里可能有偶尔的错误或性能问题，因为总是有着很多大的修改。为了平衡和稳定地游戏，强烈推荐你使用1.10.x分支的最新版。开发版是推荐给程序员和战役开发者，也给那些想要预览韦诺新特性的人。熟悉SVN和编译的人可以从[[WesnothRepository]]中检出最新的开发版。

==== Source code 源代码 ====
* [[CompilingWesnoth|编译指导]] - 如何编译源代码
{{DevDownload|当前版本|先前版本|当前源代码包的md5sum值|微软视窗操作系统|麦金塔操作系统}}

==== GNU/Linux ====
* 有许多二进制文件对应于不同的Linux发行版。不是所有的都已及时更新到最新版。请查阅[[WesnothBinariesLinux|Linux二进制包页]]寻找对应于你的发行版的二进制包信息。

==== 杂项 ====
* [http://wiki.wesnoth.org/Download_Xdeltas#Development_Version_1.11.x 源代码的Xdelta]
* [http://sourceforge.net/projects/wesnoth/files/ 当前和所有先前版本的SourceForge页]
* [http://sourceforge.net/projects/wesnoth/files/unofficial/Mac%20Compile%20Stuff/wesnoth_compile_mac_1.9.zip/download MacCompileStuff for 1.9]

== 许可 ==
'''主要文章：[[Wesnoth:Copyrights|版权声明]]

本程序为自由软件；您可依据[http://www.fsf.org Free Software Foundation|自由软件基金会]所发表的[http://www.fsf.org/copyleft/gpl.html GNU General Public License version 2|GNU通用公共许可证第2版]条款规定，就本程序再为发布与／或修改。
本程序是基于使用目的而加以发布，然而不负任何担保责任；亦无对适售性或特定目的适用性所为的默示性担保。详情请参照GNU通用公共授权。

== UMC 编辑器 ==
这提供给韦诺之战1.9.x和更高版本（包括韦诺之战1.10.x）。
细节和安装步骤可以在http://eclipse.wesnoth.org 找到。

== 参见 ==
* [http://changelog.wesnoth.org 更新日志]
* [[WesnothBinaries|更多二进制文件]]
* [[WesnothRepository]] - SVN中最前沿的版本

[[Category:Building and Installing]]

Download/ru

2014-04-25T22:19:32Z

Aquileia: Move md5sum to template

{{Download/Translations}}
Добро пожаловать на страницу загрузки «Битвы за Веснот». Команда проекта BFW официально поставляет только исходный код, бинарные пакеты же предоставлены добровольцами сообщества и размещаются на этой странице. Торренты тоже официально не поддерживаются.

Если сборки последней версии игры для вашей ОС еще не доступны, то, возможно, они появятся на этой странице спустя какое-то время. Попробуйте проверить через несколько дней. Люди, занимающиеся сборкой, знают о релизе, поэтому, пожалуйста, запаситесь терпением. А тем временем можете прочесть [[FAQ#A_new_version_is_out.2C_but_where_is_the_download_for_.5BWindows.2C_Mac_OS.2C_etc..5D.3F|FAQ]].

__NOTOC__
Перейти к: [[Download/ru#Стабильные_версии_.28ветка_1.10.29|Стабильная ветка]] | [[Download/ru#Стабильные_.28старые_версии.29|Стабильная ветка (старые версии)]] | [[Download/ru#Разработка_.28ветка_1.11.29|Ветка разработки]]

== Стабильные версии (ветка 1.10) ==
Стабильные файлы предлагается использовать в том случае, если нужна стабильная и одновременно сбалансированная версия игры. Все версии ветки 1.10 совместимы друг с другом.

Версия 1.10.7 на данный момент является последней стабильной версией. Эта версия рекомендуется для большинства игроков, поскольку в многопользовательской игре сообщество 1.10 очень большое и созданный пользователями сервер кампаний предлагает богатый выбор контента.

==== Исходный код ====
* [[CompilingWesnoth|Гайд по компилированию]] - как откомпилировать исходный код
{{StableDownload|Текущая версия|Предыдущая версия|md5sum для исходников текущей версии}}

==== GNU/Linux ====
* Существуют пакеты для множества различных дистрибутивов GNU/Linux. Не все из них обновляются с выходом нового релиза игры. Пожалуйста, ознакомьтесь с [[WesnothBinariesLinux|Страница сборок для Linux]] для того, чтобы узнать больше информации о сборках для вашего дистрибутива.

==== Дополнительно ====
* [http://www.wesnoth.org/wiki/Download_Xdeltas#Stable_Version_1.10.x Xdelta для исходного кода]
* [http://sourceforge.net/projects/wesnoth/files/ Страница на SourceForge для текущей и всех предыдущих версий]

== Стабильные (старые версии) ==
Для некоторых операционных систем не предоставлено сборки последнего стабильного релиза. Ниже вы можете найти список последних известных (стабильных) сборок для различных систем. Для этих более старых версий часто не поддерживается (официально) многопользовательская игра или сервер аддонов.

==== AmigaOS4 ====
* [http://www.amigasoft.net/pages/games/download/Wesnoth186.lha.lzh Старая версия] (1.8.6, 300 MB)

==== (Open)Solaris ====
* [http://sourceforge.net/projects/wesnoth/files/wesnoth-1.4/wesnoth-1.4.5/wesnoth-solaris-i386-1.4.5.pkg.bz2/download Старая версия] (1.4.5, 145.6 MB), не совместима с текущими стабильными версиями

==== OS/2 и eComStation ====
* [http://download.smedley.info/wesnoth-1.4.5-os2-20080828.zip Старая версия] (1.4.5, 160 MB), не совместима с текущими стабильными версиями

==== RISC OS ====
*[http://www.riscos.info/packages/arm/Games/wesnoth_1.4.5-1.zip Старая версия] (1.4.5-1, 140 MB), не совместима с текущими стабильными версиями

==== Syllable ====
* [http://downloads.syllable.org/Syllable/i586/applications/contributed/Battle-for-Wesnoth/Battle-for-Wesnoth-1.2.6.application Старая версия] (1.2.6, 60.8 MB), не совместима с текущими стабильными версиями

== Разработка (ветка 1.11) ==
1.11.x - это новая, разрабатываемая в настоящий момент версия, которая может похвастаться усовершенствованной графикой и новыми волнующими возможностями. Однако в версиях разработки могут быть баги или проблемы производительности из-за крупных изменений, постоянно вводимых в код. Для сбалансированной и стабильной игры рекомендуется использовать наиболее свежую версию ветки 1.10.x. Эта версия рекомендуется как для кодеров и разработчиков кампаний, так и для тех, кто хочет увидеть, что ждет Веснот в будущем. Люди, знакомые с системой контроля версий и компилированием, могут следить за разработкой здесь: [[WesnothRepository]].

==== Исходный код ====
* [[CompilingWesnoth|Гайд по компилированию]] - как откомпилировать исходный код
{{DevDownload|Текущая версия|Предыдущая версия|md5sum для исходников текущей версии}}

==== GNU/Linux ====
* Существуют пакеты для множества различных дистрибутивов GNU/Linux. Не все из них обновляются с выходом нового релиза игры. Пожалуйста, ознакомьтесь с [[WesnothBinariesLinux|Страница сборок для Linux]] для того, чтобы узнать больше информации о сборках для вашего дистрибутива.

==== Дополнительно ====
* [http://wiki.wesnoth.org/Download_Xdeltas#Development_Version_1.11.x Xdelta для исходного кода]
* [http://sourceforge.net/projects/wesnoth/files/ Страница на SourceForge для текущей и всех предыдущих версий]
* [http://sourceforge.net/projects/wesnoth/files/unofficial/Mac%20Compile%20Stuff/wesnoth_compile_mac_1.9.zip/download MacCompileStuff для 1.9]

== Лицензия ==
''Main article: [[Wesnoth:Copyrights]]

This program is free software; you can redistribute it and/or modify it under the terms of the [http://www.fsf.org/copyleft/gpl.html GNU General Public License version 2], as published by the [http://www.fsf.org Free Software Foundation].
This program is distributed in the hope that it will be useful, but without any warranty; without even the implied warranty of merchantability or fitness for a particular purpose. See the GNU General Public License for more details.

== UMC Editor ==
Доступно для версий Wesnoth 1.9.x и выше (включая Wesnoth 1.10.x).
Подробности и шаги по установке вы можете найти на:
http://eclipse.wesnoth.org

== Смотрите также ==
* [http://changelog.wesnoth.org Список изменений]
* [[WesnothBinaries| Другие сборки]]
* [[WesnothRepository]] - новейшая версия из репозитория

[[Category:Building and Installing]]

Download/de

2014-04-25T22:18:08Z

Aquileia: Move md5sum to template - verschiebe md5sum in die Templates

{{Download/Translations}}
Willkommen auf der Battle for Wesnoth-Downloadseite. Das BfW-Team veröffentlicht offiziell nur den Quelltext. Binärpakete werden nur von Freiwilligen aus der Gemeinschaft zur Verfügung gestellt und hier angeboten.

Wenn die neuesten Binärpakete für dein Betriebssystem momentan noch nicht verfügbar sind, überprüfe einfach alle paar Tage ob du sie hier finden kannst. Die jeweilig Verantwortlichen wurden informiert, bitte habe etwas Geduld. In der Zwischenzeit kannst du die [[/FAQ/de#Eine_neue_Version_wurde_ver.C3.B6ffentlicht.2C_aber_wo_kann_man_die_.5BWindows.2C_Mac_OS_X.2C_usw..5D-Version_herunterladen.3F|FAQ-Seite]] lesen.

__NOTOC__
Springen zu: [[Download/de#Hauptversion (1.10-Zweig)|Hauptversion]] | [[Download/de#Ältere Hauptversionen|Ältere Hauptversionen]] | [[Download/de#Entwicklungsversion (1.11-Zweig)|Entwicklungsversion]]

== Hauptversion (1.10-Zweig) ==
Die Hauptversion ist eine stabile und ziemlich ausgewogene Version des Spiels. Alle Versionen des 1.10-Zweigs sind miteinander kompatibel.

Version 1.10.7 ist die neueste Hauptversion. Diese Version ist für die meisten Spieler zu empfehlen, da die 1.10-Mehrspielergemeinschaft riesig ist und der Erweiterungsserver eine ordentliche Auswahl anbietet.

==== Quelltext ====
* [[CompilingWesnoth|Kompilierungsanleitung]] - wie man den Quelltext kompiliert
{{StableDownload|Neueste Version|Vorherige Version|md5sum für den aktuellen Quelltext}}

==== GNU/Linux ====
* Es gibt Binärpakete für viele verschiedene GNU/Linux-Distributionen. Nicht alle sind immer auf dem Stand der neuesten Version. Für mehr Informationen über die Binärpakete für deine Distribution lies bitte die [[WesnothBinariesLinux|entsprechende Seite]].

==== Verschiedenes ====
* [http://www.wesnoth.org/wiki/Download_Xdeltas#Stable_Version_1.10.x Xdelta für den Quelltext]
* [http://sourceforge.net/projects/wesnoth/files/ SourceForge-Seite für die aktuellen und alle vorherigen Versionen]

== Ältere Hauptversionen ==
Für einige Betriebssysteme gibt es keine Binärpakete der neuesten Version. Hier findest du eine Liste der letzten bekannten Hauptversionsbinärdateien für verschiedene Betriebssysteme. Für diese Versionen ist häufig kein (offizieller) Erweiterungs- und Mehrspielerserver mehr verfügbar.

==== AmigaOS4 ====
* [http://www.amigasoft.net/pages/games/download/Wesnoth186.lha.lzh Ältere Version] (1.8.6, 300MB)

==== (Open)Solaris ====
* [http://sourceforge.net/projects/wesnoth/files/wesnoth-1.4/wesnoth-1.4.5/wesnoth-solaris-i386-1.4.5.pkg.bz2/download Ältere Version] (1.4.5, 145.6 MB), inkompatibel mit 1.6.x

==== OS/2 & eComStation ====
* [http://download.smedley.info/wesnoth-1.4.5-os2-20080828.zip Ältere Version] (1.4.5, 160 MB), inkompatibel mit 1.6.x

==== RISC OS ====
*[http://www.riscos.info/packages/arm/Games/wesnoth_1.4.5-1.zip Ältere version] (1.4.5-1, 140MB), inkompatibel mit 1.6.x

==== Syllable ====
* [http://downloads.syllable.org/Syllable/i586/applications/contributed/Battle-for-Wesnoth/Battle-for-Wesnoth-1.2.6.application Ältere Version] (1.2.6, 60.8 MB), inkompatibel mit 1.6.x

== Entwicklungsversion (1.11-Zweig) ==
Version 1.11.x ist die neueste Entwicklungsversion, die verbesserte Grafik und neue aufregende Inhalte vorstellt. Allerdigs können auch Programmierfehler oder andere Probleme auftreten, da schwerwiegende Änderungen stattfinden.



Derzeit befindet sich Wesnoth 1.11 in der Beta-Phase für die kommende Hauptversion 1.12. Entwickler und Spieler sind zu diesem Anlass ermuntert, die neuen Funktionen auszuprobieren und gegebenenfalls vorhandene Fehler zu berichten, damit diese vor 1.12.0 behoben werden können.

Wer mit Versionskontrolle und Kompilierung vertraut ist, kann der aktuellen Entwicklung durch das Überprüfen von [[WesnothRepository]] folgen.

==== Quelltext ====
* [[CompilingWesnoth|Kompilierungsanleitung]] - wie man den Quellext kompiliert
{{DevDownload|Neueste Version|Vorherige Version|md5sum für den aktuellen Quelltext}}

==== GNU/Linux ====
* Es gibt Binärpakete für viele verschiedene GNU/Linux-Distributionen. Nicht alle sind immer auf dem Stand der neuesten Version. Für mehr Informationen über die Binärpakete für deine Distribution lies bitte die [[WesnothBinariesLinux|entsprechende Seite]].

==== Verschiedenes ====
* [http://wiki.wesnoth.org/Download_Xdeltas#Development_Version_1.11.x Xdelta für den Quelltext]
* [http://sourceforge.net/projects/wesnoth/files/ SourceForge-Seite für die aktuelle und alle vorherigen Versionen]
* [http://sourceforge.net/projects/wesnoth/files/unofficial/Mac%20Compile%20Stuff/wesnoth_compile_mac_1.9.zip/download MacCompileStuff für 1.9]

== Lizenz ==
''Hauptartikel: [[Wesnoth:Copyrights]]

Dieses Programm ist freie Software; du kannst es weitervertreiben und/oder modifizieren, solange das unter den Bedingungen der [http://www.fsf.org/copyleft/gpl.html GNU General Public License version 2] bleibt, veröffentlicht von der [http://www.fsf.org Free Software Foundation].
Dieses Programm wird mit der Hoffnung vertrieben, dass es nützlich ist, allerdings ohne Garantie; ohne die auch nur angedeutete Garantie auf Marktgängigkeit oder Eignung für eine bestimmte Absicht. Siehe die GNU Allgemeine Öffentliche Lizenz für mehr Informationen.

== Erweiterungseditor ==
Dieser ist für 1.9.x (und höher, einschließlich 1.10.x) verfügbar.
Details und Installationsanweisungen snd auf http://eclipse.wesnoth.org zu finden.

== Siehe auch ==
* [http://changelog.wesnoth.org Versionshistorie]
* [[WesnothBinaries| Mehr Binärpakete]]
* [[WesnothRepository]] - bleeding-edge-Version von Quelle

[[Category:Building and Installing]]

Download/es

2014-04-25T22:14:48Z

Aquileia: Move md5sum to template

{{Download/Translations}}

Bienvenido a la página de descargas de ''La Batalla por Wesnoth''. El equipo de ''La Batalla por Wesnoth'' sólo publica de forma oficial el código fuente. Los paquetes binarios son proporcionados por voluntarios y alojados aquí. Los torrents tampoco son oficiales.

Si la última versión de los binarios no está disponible para tu sistema operativo, por favor vuelve a comprobar en unos días si ya lo está. Se ha informado convenientemente a los empaquetadores, así que debes ser paciente. Durante la espera puedes leer las [[FAQ#A_new_version_is_out.2C_but_where_is_the_download_for_.5BWindows.2C_Mac_OS_X.2C_etc..5D.3F | preguntas frecuentes]] a este respecto.

__NOTOC__
Ir a: [[#Estable_.28rama_1.10.29 | Rama estable]] | [[#Estable_.28versiones_antiguas.29 | Rama estable (versiones antiguas)]] | [[#Desarrollo_.28rama_1.11.29 | Rama de desarrollo]]

== Estable (rama 1.10) ==
Las publicaciones de las ramas estables están destinadas a ser utilizadas como versiones del juego estables y equilibradas. Cada versión de la rama 1.10 es compatible con las otras.

La version 1.10.6 es la última versión estable. Ésta es la versión recomendada para la mayoría de los jugadores ya que la comunidad multijugador en línea de la versión 1.10 es muy extensa y el servidor de campañas de usuario garantiza la selección de contenidos robustos.

==== Código fuente ====
* [[CompilingWesnoth | Guía de compilación]] - cómo compilar el código fuente
{{StableDownload|Versión actual|Versión anterior|Control md5sum para el código fuente actual}}

==== GNU/Linux ====
* Existen binarios para muchas distribuciones diferentes de GNU/Linux. No siempre están todos actualizados a la última publicación. Por favor, echa un vistazo a la [[WesnothBinariesLinux | página de binarios para Linux]] para obtener más información sobre los binarios de tu distribución.

==== Miscelánea ====
* [http://www.wesnoth.org/wiki/Download_Xdeltas#Stable_Version_1.10.x Xdelta para el código fuente]
* [http://sourceforge.net/projects/wesnoth/files/ Página de SourceForge para la versión actual y todas las anteriores]

== Estable (versiones antiguas) ==
Para algunos sistemas operativos no se ofrecen los binarios de la última publicación estable. Aquí se recoge una lista de las últimas versiones estables conocidas de los binarios para varios sistemas. Para estas versiones antiguas a menudo ya no existe un servidor (oficial) de multijugador o de complementos disponible.

==== AmigaOS4 ====
* [http://www.amigasoft.net/pages/games/download/Wesnoth186.lha.lzh Versión antigua] (1.8.6, 300MB)

==== (Open)Solaris ====
* [http://sourceforge.net/projects/wesnoth/files/wesnoth-1.4/wesnoth-1.4.5/wesnoth-solaris-i386-1.4.5.pkg.bz2/download Versión antigua] (1.4.5, 145.6 MB), no compatible con 1.6.x

==== OS/2 & eComStation ====
* [http://download.smedley.info/wesnoth-1.4.5-os2-20080828.zip Versión antigua] (1.4.5, 160 MB), no compatible con 1.6.x

==== RISC OS ====
*[http://www.riscos.info/packages/arm/Games/wesnoth_1.4.5-1.zip Versión antigua] (1.4.5-1, 140MB), no compatible con 1.6.x

==== Syllable ====
* [http://downloads.syllable.org/Syllable/i586/applications/contributed/Battle-for-Wesnoth/Battle-for-Wesnoth-1.2.6.application Versión antigua] (1.2.6, 60.8 MB), no compatible con 1.6.x

== Desarrollo (rama 1.11) ==
La versión 1.11.x es la última versión de desarrollo y luce gráficos actualizados y nuevas y emocionantes características. Sin embargo, puede haber errores o problemas de rendimiento en las versiones de desarrollo debido a que se realizan grandes cambios continuamente. Para un juego equilibrado y estable, se recomienda el uso de la última versión estable de la rama 1.10.x. Esta versión está recomendada para programadores y desarrolladores de campañas, y también para aquellos que deseen prever el futuro de Wesnoth. Las personas familiarizadas con los sistemas de control de versiones podrán seguir los últimos desarrollos en el [[WesnothRepository | Repositorio de Wesnoth]].

==== Código fuente ====
* [[CompilingWesnoth | Guía de compilación]] - cómo compilar el código fuente
{{DevDownload|Versión actual|Versión anterior|Control md5sum para el código fuente actual}}

==== GNU/Linux ====
* Existen binarios para muchas distribuciones diferentes de GNU/Linux. No siempre están todos actualizados a la última publicación. Por favor, echa un vistazo a la [[WesnothBinariesLinux | página de binarios para Linux]] para obtener más información sobre los binarios de tu distribución.

==== Miscelánea ====
* [http://wiki.wesnoth.org/Download_Xdeltas#Development_Version_1.11.x Xdelta para el código fuente]
* [http://sourceforge.net/projects/wesnoth/files/ Página de SourceForge para la versión actual y todas las anteriores]
* [http://sourceforge.net/projects/wesnoth/files/unofficial/Mac%20Compile%20Stuff/wesnoth_compile_mac_1.9.zip/download MacCompileStuff para 1.9]

== Licencia ==
''Artículo principal: [[Wesnoth:Copyrights]]

Este programa es software libre; puedes redistribuirlo o modificarlo bajo los términos de la [http://www.gnu.org/licenses/gpl-2.0.html GNU General Public License, versión 2], publicada por la [http://www.fsf.org Free Software Foundation]. Este programa se distribuye con la esperanza de que sea útil, pero sin ninguna grantía; incluso sin la garantía implícita de comerciabilidad o aptitud para un propósito particular. Vea la Licencia Pública General de GNU para más detalles.

== Editor UMC ==
Disponible para Wesnoth 1.9.x y superiores (incluyendo Wesnoth 1.10.x).
Se puede encontrar una descripción detallada y una guía de instalación en: http://eclipse.wesnoth.org.

== Véase también ==
* [http://changelog.wesnoth.org Log de cambios]
* [[WesnothBinaries | Más binarios]]
* [[WesnothRepository | Repositorio de Wesnoth]] - Obtener la última versión desde el repositorio

[[Category:Building and Installing]]

Template:StableDownload

2014-04-25T22:13:52Z

Aquileia: Fix parameter for md5sum

<noinclude>
== Stable (1.10 branch) ==
==== Source code ====
</noinclude>
* [http://sourceforge.net/projects/wesnoth/files/wesnoth-1.10/wesnoth-1.10.7/wesnoth-1.10.7.tar.bz2/download {{{1|Current Version}}}] (1.10.7, 347.4 MB)
* [http://sourceforge.net/projects/wesnoth/files/wesnoth-1.10/wesnoth-1.10.6/wesnoth-1.10.6.tar.bz2/download {{{2|Previous Version}}}] (1.10.6, 346.1 MB)
* [http://sourceforge.net/projects/wesnoth/files/wesnoth-1.10/wesnoth-1.10.7/wesnoth-1.10.7.tar.bz2.md5/download {{{3|md5sum for current source code}}}]

==== MS Windows {{{4|}}} ====
* [http://sourceforge.net/projects/wesnoth/files/wesnoth-1.10/wesnoth-1.10.7/wesnoth-1.10.7-win32.exe/download {{{1|Current Version}}}] (1.10.7, 319.1 MB)
* [http://sourceforge.net/projects/wesnoth/files/wesnoth-1.10/wesnoth-1.10.6/wesnoth-1.10.6-win32.exe/download {{{2|Previous Version}}}] (1.10.6, 317.4 MB)

==== Mac OS X (10.5+) {{{5|}}} ====
* [http://sourceforge.net/projects/wesnoth/files/wesnoth-1.10/wesnoth-1.10.7/Wesnoth_1.10.7.dmg/download {{{1|Current Version}}}] (1.10.7, 349.6 MB)
* [http://sourceforge.net/projects/wesnoth/files/wesnoth-1.10/wesnoth-1.10.6/Wesnoth_1.10.6.dmg/download {{{2|Previous Version}}}] (1.10.6, 348.1 MB)

==== OpenPandora {{{6|}}} ====
* [http://sourceforge.net/projects/wesnoth/files/wesnoth-1.10/wesnoth-1.10.7/wesnoth-1.10.7-1.pnd/download {{{1|Current Version}}}] (1.10.7-1, 340.8 MB)
* [http://sourceforge.net/projects/wesnoth/files/wesnoth-1.10/wesnoth-1.10.6/wesnoth-1.10.6-1.pnd/download {{{2|Previous Version}}}] (1.10.6-1, 338.9 MB)