The Battle for Wesnoth Wiki - User contributions [en]

Credits

2007-06-18T17:56:10Z

Darth Fool: /* Coders, (minor and major) */

{| style="float:right"
|
__TOC__
|}
In July 2003, '''David White''' released the first version of Wesnoth. Since then, many people have joined the project, contributing in very different ways.

== Developers ==
====Coders, (minor and major)====
* Alfredo Beaumont (ziberpunk) - autotools
* András Salamon ([[User:Ott|ott]]) - QA, bug fixing, subediting, game mechanics
* Benoît Timbert (Noyga) - coder
* Bram Ridder (Morloth) - editor improvements
* [[User:bruno|Bruno Wolff III]] - Campaign web interface, [[MainlineScenarios#The_Dark_Hordes|The Dark Hordes]] maintainer, bug fixing, minor coder
* Cédric Duval - coder, internationalization manager
* David Philippi (Torangan) - internationalization manager, wescamp
* [mailto:davidnwhite_AT_verizon.net David White] (Sirp) - founder, lead developer, scenario designer
* Dominic Bolin (Xan) - programmer
* Guillaume Melquiond (silene) - coding, bug fixes
* Jérémy Rosen (Boucman) - coder
* Jörg Hinrichs (Yogi Bear/YogiHH) - coder
* Jon Daniel (forcemstr) - coder, bug fixes
* J. W. C. McNabb (Darth Fool) - coder, graphics
* [mailto:justin.zaun_AT_gmail.com Justin Zaun] (jzaun) - coder, scenario designer
* [mailto:erl_AT_erl.se Kristoffer Erlandsson] (erl) - help system, editor
* Nicolas Weeger (ryo) - Python API
* [mailto:patrick_x99(AT).hotmail.com Patrick Parker] ([[User:Sapient|Sapient]]) - improvements to user interface, WML engine, various features
* [mailto:philippe.plantier_AT_naema.org Philippe Plantier] ([[User:Ayin|Ayin]]) - several parts of the code, notably terrain graphics code
* [mailto:ydirson_AT_altern.org Yann Dirson] - gettext support, tinygui
* [mailto:esr&x40;thyrsus.com Eric S. Raymond] - macro and tools cleanup

====Miscellaneous====
* Benjamin Drieu (benj) - campaign writer (wrote "Son of the Black Eye")
* [mailto:dragonking_AT_o2.pl Bartek Waresiak] (Dragonking) - multiplayer balancing
* Crossbow/Miyo - administrator, release manager
* Francisco Muñoz (fmunoz) - artwork manager, many images, scenario designer (also listed below)
* Hogne Håskjold (frame) - terrain designer (also listed below)
* [mailto:isaac_AT_sindominio.net Isaac Clerencia] - administrator, release manager, debian packager
* James Spencer (Shade) - campaign writer (wrote "The Rise of Wesnoth")
* [mailto:jorda_AT_ettin.org Jordà Polo] (ettin) - website, i18n
* Joseph Simmons (Turin) - campaign writer, some graphics (wrote "The Eastern Invasion," and others)
* Mark Michelsen (skovbaer) - internationalization manager
* Mike Quiñones (Doc Paterson) - multiplayer balancing, multiplayer maps
* [mailto:Crazy-Ivanovic_AT_gmx.net Nils Kneuper] (Ivanovic) - administrator, campaign maintainer (Two Brothers), internationalization manager, release manager
* Richard Kettering (Jetryl) - artwork manager, many images (also listed below)
* Richard S. (Noy) - multiplayer balancing
* Soliton - multiplayer balancing
* Susanna Björverud (sanna) - internationalization manager
* [mailto:kleinfel_AT_wpi.edu Zack Kleinfeld] - multiplayer maps, unit balancing

====Unclassified====
* Jan Zvánovec (jaz)
* John B. Messerly (jbm)
* J.R. Blain (Cowboy)
* Maksim Orlovich (SadEagle)
* Zas

== Artists ==
==== Major Contributors ====
* Francisco Muñoz (fmunoz) - Founding Artist and former lead artist, worked consistently on all aspects till around v0.7-0.9.
* Richard Kettering [http://www.wesnoth.org/wiki/User:Jetryl (Jetryl)] - Current art director/slave, major focus on sprites, portraits, buildings, and icons
* Hogne Håskjold (frame/freim) - Former director of terrain art, made much of the current terrains (esp. mountains)
* J. W. Bjerk [http://www.wesnoth.org/wiki/User:Eleazar (Eleazar)] - Terrain-art lead. Made chasm, cave, water, etc, sprite animations, various visual tweaks and clean-ups
* Pekka Aikio (pekka) - tiles, esp. castles, and attack icons
* Lari Nieminen (zookeeper) - Current sprite animation director and WML wizard
* James Woo (Pickslide) - portraits (major focus on orcs and campaigns, especially UtBS, TEI, TSoF)
* Jason Lutes - portraits (major focus on humans, some campaign portraits)
* ?? (Neoriceisgood) - sprite creator and animator (major focus on drakes, dwarves, saurians)
* Peter Geinitz (Shadow/Wayfarer) - sprite creator and animator

==== Moderate Contributors ====
* Alex Jarocha-Ernst (Jormungandr) - portraits
* Moritz Göbelbecker (mog) - tiles, esp. swamp, encampment, ice, and work with lava/chasm
* Erkki Lonkainen (Eternal) - created and animated many replacement sprites (esp. ogre, orc assassin & spear units, and cockatrice)
* Maximiliano Buis (Redeth) - Made nearly all of the idle animations, and some death animations (as of 1.3.1)
* Leonhard ? (Leonhard) - made several of the new attack icons
* Michael Gil de Muro (grp21) - portraits (for the campaign "The Rise of Wesnoth")
* Robert Bolin (Zebulon) - tiles, sprite editing and animations
* Christophe Anjard (Christophe33) - made many of the old (c. v0.6) terrains, and some sprites for the dwarves
* Johann de Venecia (Johann) - drew the new campaign story art for HttT
* Mark Goodenough (Ranger M) - Sprite animator

==== Minor Contributors ====

* Eli Dupree (Elvish Pillager) - sprites and animations
* Murray Cook (Zhukov) - Sprite animator
* Gerald Clears (Smok'em Jags) - sprite animator
* Jesse Holland (Kestenvarn) - map illustrator, designed the current map for HttT
* Mikko Kraft (Deserter) - Sprite animator
* Michael Mielewczik (Mille) - Sprite animator
* Stephen Stone (Disto) - Sprite animator
* Andrew James Patterson (Kamahawk) - sprites
* Diego Brea (Cobretti) - sprite creator/animator
* ?? (antwerpz) - sprite creator/animator for old saurian units
* Gareth Miller (Gafgarion) - made some early sprites/tiles
* James Barton (Sangel) - sprites
* John Muccigrosso (Eponymous Archon) - made some early sprites, such as the human bowmen
* ?? (Slainte) - made sprites for c. v0.6 mages, also made many of the old attack icons
* ?? (Svetac) - made many of the old attack icons
* Johanna Manninen (lohari) - edited tiles, ported freeciv tiles used in very early versions of wesnoth
* Tristan Millner (tatmf) - made portrait of dwarven fighter
* EEL (EELuminatus) - Made death animations for the wose line.
* Mattias Westlund (West) - new colored cursors, TB portrait
* Eric Holdos (Rev. V!) - Made a few extra frames for the elvish captain/hero.
* Musketaquid - animated windmill

==== Very Minor Contributors ====
* Gideon Chia (Deonjo) - new "units" icon for general status bar
* John-Robert Funck (XJaPaN) - sprite animator
* Anton Ecker (Kaldred) - burnt villages
* Joe (battlestar) - some scenery graphics including burnt tent.
* Jonatan Alamà (tin) - made red logo used until before v1.0
* Jimmy Olsson (Azlan) - made old icons for windows version
* Randall Walls (slightcrazed) - sprite animator
* Jason Frailey (Valdroni) - made scorpion portrait
* Nicholas Kerpan (Thrawn) - made human theif portrait
* ?? (Highhole) - revised storm trident
* Irwin Ismail (Swordy) - original projectile/attack icon for chakram
* Evan Crook (Flametrooper) - Sprite animator (TC conversion)
* Daniel Borgmann (dborg) - semi-transparent map grid
* Garrett Wessner (Stilgar) - gold coin-pile
* Javier Hoyos (Vendanna) - naga hunter attack frames

== Musicians ==
* Aleksi Aubry-Carlson (Aleksi) - music coordinator/composer
* Joseph Toscano (zhaymusic.com) - music
* Pau Congost - music
* Fredrik Lindroth - music
* Timothy Pinkham (TimothyP) - music coordinator/composer

== Translators ==
* adson - hungarian translation
* İhsan Akın - turkish translation
* Agata Chmiel - polish translation
* Aleksej Korgenkov (Grimpanto) - esperanto translation
* Alessio D'Ascanio (otaku) - italian translation
* Alexander Alexiou (Santi) - greek translation
* Alexander Kjäll (capitol) - swedish translation
* Alexandr Menovchicov - russian translation
* Alexey Remizov - russian translation
* Alexey Zakharchenko - russian translation
* Alfredo Beaumont (ziberpunk) - basque translation
* Ambra Viviani Loos - brazilian portuguese translation
* Americo Iacovizzi (DarkAmex) - italian translation
* Anders K. Madsen (madsen) - danish translation
* András Salamon ([[User:Ott|ott]]) - afrikaans, english and hungarian translation
* Andre Schmidt (schmidta) - german translation
* Anežka Bubeníčková (Bubu) - czech translation
* Ankka - finnish translation
* Anton Tsigularov (Atilla) - bulgarian translation
* Arkadiusz Danilecki (szopen) - polish translation
* Arnaud Garoux (La vie en wose) - french translation
* Arne Deprez - dutch translation
* Artur R. Czechowski - polish translation
* Åse Petersson (tintin) - swedish translation
* Aurélien Brevers (Breversa) - french translation
* Azamat Hackimov ([[User:Winterheart|winterheart]]) - russian translation
* Bartek Waresiak (Dragonking) - polish translation
* Beer (Eddi) - hungarian translation
* Benoit Astruc - french translation
* Benoît Timbert (Noyga) - french translation
* Bjarke Sørensen (basher) - danish translation
* BlueStar - japanese translation
* Boris Stumm (quijote_) - german translation
* BOrsuk - polish translation
* Branko Kokanovic (kokan) - serbian translation
* Bruno Fève (PP) - french translation
* [mailto:caslav_DOT_ilic_AT_gmx_DOT_net Časlav Ilić] - serbian translation
* Cédric Duval - french translation
* Carles Company (brrr) - catalan translation
* Celso Goya - brazilian portuguese translation
* Christoph Berg (chrber) - german translation
* [mailto:cbterra_AT_gmail.com Claudio Terra] - brazilian portuguese translation
* Claus Aranha - brazilian portuguese translation
* crys0000 - italian translation
* Dan Rosàs Garcia (focks) - catalan translation
* Damien Jacquot - french translation
* Daniel López (Azazelo) - catalan translation
* DaringTremayne - french translation
* David Nečas (Yeti) - czech translation
* dentro - hungarian translation
* Denica Mincheva - bulgarian translation
* Enes Akın (yekialem) - turkish translation
* Erik J. Mesoy (Circon) - norwegian translation
* Eugenio Favalli (ElvenProgrammer) - italian translation
* Federico Tomassetti - italian translation
* Flamma - spanish translation
* Florence Guettaa (inflow) - french translation
* Foppe Benedictus - dutch translation
* Francesco Lorenzon (Likso) - esperanto translation
* Franciso Muñoz (fmunoz) - spanish translation
* François Mariage (Paquito) - french translation
* François Orieux - french translation
* Gabriel Rodríguez (Chewie) - spanish translation
* Gaute Jao (Bombadil) - norwegian translation
* Geoffroy Douillié ([[User:Gdou|Gdou]]) - french translation
* Georgi Dimitrov (oblak)- bulgarian translation
* Gérard Bodin - french translation
* Gerfried Fuchs ([[User:Rhonda|Rhonda]]) - german translation
* Gilluin - hungarian translation
* Guillaume Duwelz-Rebert - french translation
* [mailto:massart.guillaume_AT_wanadoo.fr Guillaume Massart (Piou2fois)] - french translation
* Guillaume Melquiond (silene) - french translation
* Hallvard Norheim Bø (Lysander) - norwegian translation
* Harry Kaimenas - greek translation
* Håvard Korsvoll - norwegian translation
* Huang huan (unicon) - chinese translation
* Hugo Gerlach (Entrimo) - swedish translation
* Ilya Kaznacheev - russian translation
* Ilya Kotov - russian translation
* Ivan Kovacs - slovak translation
* isazi - italian translation
* Iván Herrero (navitux) - spanish translation
* Jaka Kranjc (lynx) - slovenian translation
* Jan Greve (Jan) - german translation
* Jan-Heiner Laberenz (jan-heiner) - german translation
* Jean Privat (Tout) - french translation
* Jean-Luc Menut - french translation
* Jean-Luc Richard (Le Gnome) - french translation
* Jehan Hysseo (Jey) - french translation
* Jérémy Rosen (Boucman) - french translation
* Jesper Fuglsang Wolff (ulven) - danish translation
* Joan Queralt - catalan translation
* Joe Hansen - danish translation
* Joeri Melis - dutch translation
* Jonatan Alamà (tin) - catalan translation
* [mailto:jorda_AT_ettin.org Jordà Polo] (ettin) - catalan translation coordinator
* Jose Gordillo (kilder) - spanish and catalan translation
* Jose Manuel Gomez (joseg) - spanish translation
* Joset Anthony Zamora (sophie^) - filipino translation
* Julien Moncel - french translation
* Julien Tailleur - french translation
* Julen Landa (genars) - basque translation
* Jussi Rautio (jgrr) - finnish translation
* Kai Ensenbach (Pingu) - german translation
* Kékkői László (BlackEvil) - hungarian translation
* Karol Nowak (grzywacz) - polish translation
* Katerina Sykioti - greek translation
* Kertész Csaba - hungarian translation
* Khiraly - hungarian translation
* Kim Woong (Kazya) - korean translation
* kko - finnish translation
* Konstantinos Karasavvas - greek translation
* Konstantinos Egarhos - greek translation
* Kosif - turkish translation
* Kovács Dániel - hungarian translation
* krix - hungarian translation
* Lala - dutch translation
* Leo Danielson (Lugo Moll) - swedish translation
* Luciano Montanaro (Luciano) - italian translation
* Lukáš Faltýnek - czech translation
* Ľubo Fajth - esperanto translation
* Maarten Albrecht - dutch and esperanto translation
* Mark Michelsen (skovbaer) - danish translation
* Mark Polo (mpolo) - latin translation
* Mark Recasens - catalan translation
* Mart Tõnso - estonian translation
* Martin Dzbor - slovak translation
* Martin Šín - czech translation
* Matej Repinc - slovenian translation
* Mathias Bundgaard Svensson (freaken) - danish translation
* Matias Parmala - finnish translation
* methinks - polish translation
* Michał Jedynak (Artanis) - polish translation
* Michał Ligowski (misiorysio) - polish translation
* Michel Loos - brazilian portuguese translation
* Michel Poléni (Thanatloc) - french translation
* Mik2303 - greek translation
* Mikel Olasagasti (Hey_neken) - basque translation
* Mikko Kraft (deserter) - finnish translation
* Mintaka - czech translation
* Naoki Iimura (amatubu) いいむらなおき - japanese translation
* Nico Oliver - afrikaans translation
* Nicolas Boudin (Blurgk) - french translation
* Nikolay Vladimirov (Turki) - bulgarian translation
* [mailto:Crazy-Ivanovic_AT_gmx.net Nils Kneuper] (Ivanovic) - german translation
* [mailto:okyada_AT_gmail.com Nobuhito Okada] 岡田信人 - japanese translation
* [mailto:tapik_AT_buchtovi.cz Oto Buchta] ([[User:Tapik|tapik]]) - czech translation
* Pau Rul·lan Ferragut - catalan translation
* Paweł Stradomski - polish translation
* Paweł Tomak - polish translation
* paxed - finnish translation
* Petr Kopač (Ferda) - czech translation
* Petr Kovár (Juans) - czech translation
* [mailto:philippe.plantier_AT_naema.org Philippe Plantier] ([[User:Ayin|Ayin]]) - french translation
* Pieter Vermeylen (Onne) - dutch translation
* Pınar Yanardağ (moonquelle) - turkish translation
* Q - japanese translation
* Rastislav Šarišský (Asto) - esperanto translation
* Renato Cunha - brazilian portuguese translation
* Ricardo Sodré Andrade - brazilian portuguese translation
* Roberto Garcia (Motxales) - catalan translation
* Roberto Romero (sildur) - spanish translation
* Roel Thijs (Roel) - dutch translation
* Roger Koot - dutch translation
* RokStar - italian translation
* Roman Tuchin (Sankt) - russian translation
* Rudolf Orság - czech translation
* Ruben Philipp Wickenhäuser (The Very Uhu) - german translation
* Sébastien Raynaud (Galactic turkey) - french translation
* Sérgio de Miranda Costa - brazilian portuguese translation
* Selim Farsakoğlu - turkish translation
* Sofronius - czech translation
* Spiros, Giorgis - greek translation
* [mailto:sreckotoroman_AT_gmail_DOT_com Srećko Toroman] (FreeCraft) - serbian translation
* Stefan Bergström (tephlon) - swedish translation
* Stephan Grochtmann (Schattenstephan) - german translation
* [mailto:susanna.bjorverud_AT_telia.com Susanna Björverud] (sanna) - swedish translation
* Susanne Mesoy (Rarlgland) - norwegian translation
* Széll Tamás (TomJoad) - hungarian translation
* Takanobu Hirai - japanese translation
* Tiago Souza (Salvador) - brazilian portuguese translation
* Tobe Deprez - dutch translation
* Uz-Valentin Friedrich - german translation
* Vít Komárek - czech translation
* Vít Krčál - czech translation
* [http://www.viliam.bur.sk/ Viliam Búr] - slovak translation
* Vladimír Slávik - czech translation
* Vlad Glagolev (Stelz) - russian translation
* vonHalenbach - german translation
* William Dupré - french translation
* wint3r - swedish translation
* [mailto:ydirson_AT_altern.org Yann Dirson] - french translation
* Yuji Matsumoto - japanese translation
* Zas - french translation

== Other Contributions ==
* Ben Anderman (crimson_penguin) - unit list
* Cyril Bouthors (CyrilB) - debian packager, patron
* Dacyn - scenario designer
* Darryl Dixon - packager
* edge - packager
* Francesco Gigli (Jaramir) - wiki, wesnoth.slack.it
* Frédéric Wagner
* Jay Hopping - packager
* Jeff Breidenbach (Jab) - Bilinear interpolation
* Joshua Northey (Becephalus) - multiplayer maps
* Laurent Wacrenier (lwa) - Mac OS X packager
* Marcin Konicki (ahwayakchih) - BeOS packager
* Marcus Phillips (Sithrandel) - Mac OS X packager (for v1.0 and before)
* Mark Michelsen (skovbaer) - slackware packager
* Miguel Zapico (elricz) - unit list translations
* Peter Groen (pg) - multiplayer maps
* Ruben Philipp Wickenhäuser (The Very Uhu) - multiplayer maps
* Sam Phillips (dark172) - creation of campains and multiplayer maps
* Tom Chance (telex4) - multiplayer maps, scenario balancing
* Vlad Glagolev (Stelz) - OpenBSD packager

{{Home}}

User:Darth Fool

2007-06-15T20:37:56Z

Darth Fool:

This page is intended as a development page for the documentation of the new AI that I am working on. When the AI is officially released, the information will be migrated to the official wml reference pages. Some of this is partially implemented, some of it has not yet been implemented, and some of these are planned changes to something that is already implemented, and all of it is subject to change in the code without notification. So, in short, don't start using this in your scenarios and expect it to work just yet, or even to still be the same by the time of the official release. This is primarily meant as a way to organize my thoughts and reduce the time from when the code is complete to when the new AI is fully documented. You have been warned.

----

'''The Grand Idea'''

Ok, so what is this AI supposed to accomplish anyways. Well, it has many goals, but most of them can be wrapped up in the following statement: The AI should be sufficiently flexible to be able to specify parameters so that it can win Heir To The Throne on easy without cheating. That means, no knowing where things are before they are discovered (scepter of fire), no knowing where hidden or fogged units are, etc... Along the way, we should end up with an AI that makes it quite possible to create much more interesting AI behaviour in campaigns. so, how to accomplish this?

'''Orders'''

The basic scheme begins with a simple concept. The AI WML will be able to specify the order in which various objectives are accomplished, and by what units those orders are filled. Consider that currently, the AI pursues its goals in a very specific order (combat, village capture, healing, retreat, recruit...)

So, the first order of business is to enable the abilty to specify the order in which commands are executed. As a further refinement, we allow the order to restrict what type of units the order applies to. Inside the order are a series of commands that are executed. Units that fill that order remember which order they are following (via the ai_special tag in the unit) until they are reassigned. Units that have no ai_special are part of the "default" orders. Initially, any [fill] commands are executed within the order. After this, units are sorted according to any [sort] commands. Then, for each unit the remaining commands are executed in order by each unit before the next unit begins executing the commands.

[order]#This tag specifies the beginning of an order description.
name = #the name of the order. Acts to id units that are part of this order
id = #uniq ID of this order tag. Used when executing summon commands.
execute = # yes(default) or no. If yes will execute when encountered.
# If no, only executed if explicitly called by an execute command.
memory = #In the various calculations, use the last seen locations of units that
# are now invisible if they were last seen within memory turns.
priority = # determines if order can steal units from other orders during fill.
# can only steal units from orders with strictly lower priority.
# units of equal or greater priority will ignore the request to fill
# the order. default value = 0
[fill]#command to attempt to fill the order with units that match the appropriate unit filter
number = #command of how many units to fill that match the filter
[filter]#standard unit filter.[/filter]
sort = #evaluation of how to choose which unit to accept first. Higher value chosen first.
[/fill]
[sort]
[filter]#standard unit filter.
[/filter]
sort = #evaluation of how to choose which unit to accept first. Higher value chosen first.
[/sort]
[command]#generic tags for all commands
[filter]#standard unit filter. limits which units will execute this command.
[/filter]
type = #type of command to execute. command specific WML tags below
[/command]#move command
type = moveto # move to target.
[command]
type = set_order # change the unit to be a part of a different order
[/command]
[command]
type = break # stop executing this order for this unit.
#Should really have a filter otherwise makes all following commands never be executed.
[/command]
[command]
type = attack # execute an attack. Does not move the unit!
[/command]
[command]
type = recruit # recruit units. Does not move the unit!
[/command]
[command]
type = execute # execute the following order before continuing.
id = #id of order to execute
[/command]
[command]
type = summon # summon units to give current unit a boost before combat.
#possibly will be eliminated in favor of the execute command.
[/command]
[/order]

Note that orders with the same name can be used multiple times and will keep the same units between calls, but they should each have a unique id.

'''Evaluators'''

Within the many options, there will be various parameters that need to be calculated, especially numeric ones. A large number of them will be possible to be specified as an expression that will be evaluated at the time the order is being executed. Most of these will be numeric. To make this more flexible, these values will allow the use of simple arithmetic expressions, wml variables, and some specialized function calls. A typical example might look like:

sort_value = "$villages + (2*$enemies) / @distance(@unit(),@target(fool))"

note that the quotes are necessary to prevent certain preprocessor actions.

In this case the first thing that are evaluated are the WML variables. Then functions that are designated by beginning with an @ followed by the function name and a parenthetical expression that encloses a parameter string. Typically these functions will evaluate the parameter string in a similar manner before returning a value. Note that the string inside the parenthesis of a function will be passed as a whole into the function before being evaluated. Typically the first thing that each function will do is re-evaluate the string, but this is not a requirement.

The next thing that is evaluated are things within paranthesis and finally the arithmetic expression evaluated with the standard precedence.

Items within an individual command will be evaluated before the command is executed.
Items within an individual order will be evaluated at the begining of the order for each unit in the order.
Items within the AI tag but not in either of the above will be evaluated only at the beginning of the turn.

The use of evaluators will make it possible to control many of the AI parameters indirectly via WML variables that are set/changed within events.

'''@ Functions'''
The following functions are planned for use within the evaluators. Parameters are generally a comma seperated list. Required parameters must be in the proper order at the beginning of the list. If optional parameters are allowed, they go at the end of the list and are generally of the form "A=b" where A is the optional parameter and B is the value to assign it.

@distance(x1,y1,x2,y2 [,type=[hex,turns]]) : evaluate distance between two hexes using different metrics

@adjacent(x1,y1 [,direction=[1-6]]) : return adjacent hex [x,y] values in different directions (0=N, 1=NE ...)

@unit([variable=[location,wml_variable...],id=]) : return variable from the current unit (or unit with matching id.

@hex(x1,y1,variable) : return variable associated with particular hex

@eval(string) : evaluate an arithmetic expression

User:Darth Fool

2007-06-15T20:36:42Z

Darth Fool:

User:Darth Fool

2007-05-30T21:25:34Z

Darth Fool:

This page is intended as a development page for the documentation of the new AI that I am working on. When the AI is officially released, the information will be migrated to the official wml reference pages. Some of this is partially implemented, some of it has not yet been implemented, and some of these are planned changes to something that is already implemented, and all of it is subject to change in the code without notification. So, in short, don't start using this in your scenarios and expect it to work just yet, or even to still be the same by the time of the official release. This is primarily meant as a way to organize my thoughts and reduce the time from when the code is complete to when the new AI is fully documented. You have been warned.

----

'''The Grand Idea'''

Ok, so what is this AI supposed to accomplish anyways. Well, it has many goals, but most of them can be wrapped up in the following statement: The AI should be sufficiently flexible to be able to specify parameters so that it can win Heir To The Throne on easy without cheating. That means, no knowing where things are before they are discovered (scepter of fire), no knowing where hidden or fogged units are, etc... Along the way, we should end up with an AI that makes it quite possible to create much more interesting AI behaviour in campaigns. so, how to accomplish this?

'''Orders'''

The basic scheme begins with a simple concept. The AI WML will be able to specify the order in which various objectives are accomplished, and by what units those orders are filled. Consider that currently, the AI pursues its goals in a very specific order (combat, village capture, healing, retreat, recruit...)

So, the first order of business is to enable the abilty to specify the order in which commands are executed. As a further refinement, we allow the order to restrict what type of units the order applies to. Inside the order are a series of commands that are executed. Units that fill that order remember which order they are following (via the ai_special tag in the unit) until they are reassigned. Units that have no ai_special are part of the "default" orders. Initially, any [fill] commands are executed within the order. After this, units are sorted according to any [sort] commands. Then, for each unit the remaining commands are executed in order by each unit before the next unit begins executing the commands.

[order]#This tag specifies the beginning of an order description.
name = #the name of the order. Acts to id units that are part of this order
id = #uniq ID of this order tag. Used when executing summon commands.
execute = # yes(default) or no. If yes will execute when encountered.
# If no, only executed if explicitly called by an execute command.
memory = #In the various calculations, use the last seen locations of units that
# are now invisible if they were last seen within memory turns.
priority = # determines if order can steal units from other orders during fill.
# can only steal units from orders with strictly lower priority.
# units of equal or greater priority will ignore the request to fill
# the order. default value = 0
[fill]#command to attempt to fill the order with units that match the appropriate unit filter
number = #command of how many units to fill that match the filter
[filter]#standard unit filter.[/filter]
sort = #evaluation of how to choose which unit to accept first. Higher value chosen first.
[/fill]
[sort]
[filter]#standard unit filter.
[/filter]
sort = #evaluation of how to choose which unit to accept first. Higher value chosen first.
[/sort]
[command]#generic tags for all commands
[filter]#standard unit filter. limits which units will execute this command.
[/filter]
type = #type of command to execute. command specific WML tags below
[/command]#move command
type = moveto # move to target.
[command]
type = set_order # change the unit to be a part of a different order
[/command]
[command]
type = break # stop executing this order for this unit.
#Should really have a filter otherwise makes all following commands never be executed.
[/command]
[command]
type = attack # execute an attack. Does not move the unit!
[/command]
[command]
type = recruit # recruit units. Does not move the unit!
[/command]
[command]
type = execute # execute the following order before continuing.
id = #id of order to execute
[/command]
[command]
type = summon # summon units to give current unit a boost before combat.
#possibly will be eliminated in favor of the execute command.
[/command]
[/order]

Note that orders with the same name can be used multiple times and will keep the same units between calls, but they should each have a unique id.

'''Evaluators'''

Within the many options, there will be various parameters that need to be calculated, especially numeric ones. A large number of them will be possible to be specified as an expression that will be evaluated at the time the order is being executed. Most of these will be numeric. To make this more flexible, these values will allow the use of simple arithmetic expressions, wml variables, and some specialized function calls. A typical example might look like:

sort_value = "$villages + (2*$enemies) / @distance(@unit(),@target(fool))"

note that the quotes are necessary to prevent certain preprocessor actions.

In this case the first thing that are evaluated are the WML variables. Then functions that are designated by beginning with an @ followed by the function name and a parenthetical expression that encloses a parameter string. Typically these functions will evaluate the parameter string in a similar manner before returning a value. Note that the string inside the parenthesis of a function will be passed as a whole into the function before being evaluated. Typically the first thing that each function will do is re-evaluate the string, but this is not a requirement.

The next thing that is evaluated are things within paranthesis and finally the arithmetic expression evaluated with the standard precedence.

Items within an individual command will be evaluated before the command is executed.
Items within an individual order will be evaluated at the begining of the order for each unit in the order.
Items within the AI tag but not in either of the above will be evaluated only at the beginning of the turn.

The use of evaluators will make it possible to control many of the AI parameters indirectly via WML variables that are set/changed within events.

'''@ Functions'''
The following functions are planned for use within the evaluators. Parameters are generally a comma seperated list. Required parameters must be in the proper order at the beginning of the list. If optional parameters are allowed, they go at the end of the list and are generally of the form "A=b" where A is the optional parameter and B is the value to assign it.

@distance(x1,y1,x2,y2 [,type=[hex,turns]]) : evaluate distance between two hexes using different metrics
@adjacent(x1,y1 [,direction=[1-6]]) : return adjacent hex [x,y] values in different directions (0=N, 1=NE ...)
@unit([variable=[location,wml_variable...],id=]) : return variable from the current unit (or unit with matching id.
@hex(x1,y1,variable) : return variable associated with particular hex
@eval(string) : evaluate an aritmetic expression

User:Darth Fool

2007-05-25T01:59:37Z

Darth Fool:

User:Darth Fool

2007-05-25T01:24:33Z

Darth Fool:

This page is intended as a development page for the documentation of the new AI that I am working on. When the AI is officially released, the information will be migrated to the official wml reference pages. Some of this is partially implemented, some of it has not yet been implemented, and some of these are planned changes to something that is already implemented, and all of it is subject to change in the code without notification. So, in short, don't start using this in your scenarios and expect it to work just yet, or even to still be the same by the time of the official release. This is primarily meant as a way to organize my thoughts and reduce the time from when the code is complete to when the new AI is fully documented. You have been warned.

----

'''The Grand Idea'''

Ok, so what is this AI supposed to accomplish anyways. Well, it has many goals, but most of them can be wrapped up in the following statement: The AI should be sufficiently flexible to be able to specify parameters so that it can win Heir To The Throne on easy without cheating. That means, no knowing where things are before they are discovered (scepter of fire), no knowing where hidden or fogged units are, etc... Along the way, we should end up with an AI that makes it quite possible to create much more interesting AI behaviour in campaigns. so, how to accomplish this?

'''Orders'''

The basic scheme begins with a simple concept. The AI WML will be able to specify the order in which various objectives are accomplished, and by what units those orders are filled. Consider that currently, the AI pursues its goals in a very specific order (combat, village capture, healing, retreat, recruit...)

So, the first order of business is to enable the abilty to specify the order in which commands are executed. As a further refinement, we allow the order to restrict what type of units the order applies to. Inside the order are a series of commands that are executed. Units that fill that order remember which order they are following (via the ai_special tag in the unit) until they are reassigned. Units that have no ai_special are part of the "default" orders. Initially, any [fill] commands are executed within the order. After this, units are sorted according to any [sort] commands. Then, for each unit the remaining commands are executed in order by each unit before the next unit begins executing the commands.

[order]#This tag specifies the beginning of an order description.
name = #the name of the order. Acts to id units that are part of this order
id = #uniq ID of this order tag. Used when executing summon commands.
execute = # yes(default) or no. If yes will execute when encountered.
# If no, only executed if explicitly called by an execute command.
memory = #In the various calculations, use the last seen locations of units that
# are now invisible if they were last seen within memory turns.
priority = # determines if order can steal units from other orders during fill.
# can only steal units from orders with strictly lower priority.
# units of equal or greater priority will ignore the request to fill
# the order. default value = 0
[fill]#command to attempt to fill the order with units that match the appropriate unit filter
number = #command of how many units to fill that match the filter
[filter]#standard unit filter.[/filter]
sort = #evaluation of how to choose which unit to accept first. Higher value chosen first.
[/fill]
[sort]
[filter]#standard unit filter.
[/filter]
sort = #evaluation of how to choose which unit to accept first. Higher value chosen first.
[/sort]
[command]#generic tags for all commands
[filter]#standard unit filter. limits which units will execute this command.
[/filter]
type = #type of command to execute. command specific WML tags below
[/command]#move command
type = moveto # move to target.
[command]
type = set_order # change the unit to be a part of a different order
[/command]
[command]
type = break # stop executing this order for this unit.
#Should really have a filter otherwise makes all following commands never be executed.
[/command]
[command]
type = attack # execute an attack. Does not move the unit!
[/command]
[command]
type = recruit # recruit units. Does not move the unit!
[/command]
[command]
type = execute # execute the following order before continuing.
id = #id of order to execute
[/command]
[command]
type = summon # summon units to give current unit a boost before combat.
#possibly will be eliminated in favor of the execute command.
[/command]
[/order]

Note that orders with the same name can be used multiple times and will keep the same units between calls, but they should each have a unique id.

'''Evaluators'''

Within the many options, there will be various parameters that need to be calculated, especially numeric ones. A large number of them will be possible to be specified as an expression that will be evaluated at the time the order is being executed. Most of these will be numeric. To make this more flexible, these values will allow the use of simple arithmetic expressions, wml variables, and some specialized function calls. A typical example might look like:

sort_value = "$villages + (2*$enemies) / @distance(@unit(),@target(fool))"

note that the quotes are necessary to prevent certain preprocessor actions.

In this case the first thing that is evaluated are the functions that are designated by beginning with an @ followed by the function name and a parenthetical expression that encloses a parameter string. Typically these functions will evaluate the parameter string in a similar manner before returning a value. Note that the string inside the parenthesis of a function will be passed as a whole into the function before being evaluated. Typically the first thing that each function will do is re-evaluate the string, but this is not a requirement.

The next thing that is evaluated are things within paranthesis followed by WML variables designated with a $ at the beginning, and finally the arithmetic expression evaluated with the standard precedence.

Items within an individual command will be evaluated before the command is executed.
Items within an individual order will be evaluated at the begining of the order for each unit in the order.
Items within the AI tag but not in either of the above will be evaluated only at the beginning of the turn.

The use of evaluators will make it possible to control many of the AI parameters indirectly via WML variables that are set/changed within events.

User:Darth Fool

2007-05-22T21:40:53Z

Darth Fool:

This page is intended as a development page for the documentation of the new AI that I am working on. When the AI is officially released, the information will be migrated to the official wml reference pages. Some of this is partially implemented, some of it has not yet been implemented, and some of these are planned changes to something that is already implemented, and all of it is subject to change in the code without notification. So, in short, don't start using this in your scenarios and expect it to work just yet, or even to still be the same by the time of the official release. This is primarily meant as a way to organize my thoughts and reduce the time from when the code is complete to when the new AI is fully documented. You have been warned.

----

'''The Grand Idea'''

Ok, so what is this AI supposed to accomplish anyways. Well, it has many goals, but most of them can be wrapped up in the following statement: The AI should be sufficiently flexible to be able to specify parameters so that it can win Heir To The Throne on easy without cheating. That means, no knowing where things are before they are discovered (scepter of fire), no knowing where hidden or fogged units are, etc... Along the way, we should end up with an AI that makes it quite possible to create much more interesting AI behaviour in campaigns. so, how to accomplish this?

'''Orders'''

The basic scheme begins with a simple concept. The AI WML will be able to specify the order in which various objectives are accomplished, and by what units those orders are filled. Consider that currently, the AI pursues its goals in a very specific order (combat, village capture, healing, retreat, recruit...)

So, the first order of business is to enable the abilty to specify the order in which commands are executed. As a further refinement, we allow the order to restrict what type of units the order applies to. Inside the order are a series of commands that are executed. Units that fill that order remember which order they are following (via the ai_special tag in the unit) until they are reassigned. Units that have no ai_special are part of the "default" orders. Initially, any [fill] commands are executed within the order. After this, units are sorted according to any [sort] commands. Then, for each unit the remaining commands are executed in order by each unit before the next unit begins executing the commands.

[order]#This tag specifies the beginning of an order description.
name = #the name of the order. Acts to id units that are part of this order
id = #uniq ID of this order tag. Used when executing summon commands.
execute = # yes(default) or no. If yes will execute when encountered.
# If no, only executed if explicitly called by an execute command.
memory = #In the various calculations, use the last seen locations of units that
# are now invisible if they were last seen within memory turns.
priority = # determines if order can steal units from other orders during fill.
# can only steal units from orders with strictly lower priority.
# units of equal or greater priority will ignore the request to fill
# the order. default value = 0
[fill]#command to attempt to fill the order with units that match the appropriate unit filter
number = #command of how many units to fill that match the filter
[filter]#standard unit filter.[/filter]
sort = #evaluation of how to choose which unit to accept first. Higher value chosen first.
[/fill]
[sort]
[filter]#standard unit filter.
[/filter]
sort = #evaluation of how to choose which unit to accept first. Higher value chosen first.
[/sort]
[command]#generic tags for all commands
[filter]#standard unit filter. limits which units will execute this command.
[/filter]
type = #type of command to execute. command specific WML tags below
[/command]#move command
type = moveto # move to target.
[command]
type = set_order # change the unit to be a part of a different order
[/command]
[command]
type = break # stop executing this order for this unit.
#Should really have a filter otherwise makes all following commands never be executed.
[/command]
[command]
type = attack # execute an attack. Does not move the unit!
[/command]
[command]
type = recruit # recruit units. Does not move the unit!
[/command]
[command]
type = execute # execute the following order before continuing.
id = #id of order to execute
[/command]
[command]
type = summon # summon units to give current unit a boost before combat.
#possibly will be eliminated in favor of the execute command.
[/command]
[/order]

Note that orders with the same name can be used multiple times and will keep the same units between calls, but they should each have a unique id.

'''Evaluators'''

Within the many options, there will be various parameters that need to be calculated, especially numeric ones. A large number of them will be possible to be specified as an expression that will be evaluated at the time the order is being executed. Most of these will be numeric. To make this more flexible, these values will allow the use of simple arithmetic expressions, wml variables, and some specialized function calls. A typical example might look like:

sort_value = $villages + (2*$enemies) / @distance(@unit(),@target(fool))

In this case the first thing that is evaluated are the functions that are designated by beginning with an @ followed by the function name and a parenthetical expression that encloses a parameter string. Typically these functions will evaluate the parameter string in a similar manner before returning a value. Note that the string inside the parenthesis of a function will be passed as a whole into the function before being evaluated. Typically the first thing that each function will do is re-evaluate the string, but this is not a requirement.

The next thing that is evaluated are things within paranthesis followed by WML variables designated with a $ at the beginning, and finally the arithmetic expression evaluated with the standard precedence.

Items within an individual command will be evaluated before the command is executed.
Items within an individual order will be evaluated at the begining of the order for each unit in the order.
Items within the AI tag but not in either of the above will be evaluated only at the beginning of the turn.

The use of evaluators will make it possible to control many of the AI parameters indirectly via WML variables that are set/changed within events.

User:Darth Fool

2007-05-18T04:39:03Z

Darth Fool:

This page is intended as a development page for the documentation of the new AI that I am working on. When the AI is officially released, the information will be migrated to the official wml reference pages. Some of this is partially implemented, some of it has not yet been implemented, and some of these are planned changes to something that is already implemented, and all of it is subject to change in the code without notification. So, in short, don't start using this in your scenarios and expect it to work just yet, or even to still be the same by the time of the official release. This is primarily meant as a way to organize my thoughts and reduce the time from when the code is complete to when the new AI is fully documented. You have been warned.

----

'''The Grand Idea'''

Ok, so what is this AI supposed to accomplish anyways. Well, it has many goals, but most of them can be wrapped up in the following statement: The AI should be sufficiently flexible to be able to specify parameters so that it can win Heir To The Throne on easy without cheating. That means, no knowing where things are before they are discovered (scepter of fire), no knowing where hidden or fogged units are, etc... Along the way, we should end up with an AI that makes it quite possible to create much more interesting AI behaviour in campaigns. so, how to accomplish this?

'''Orders'''

The basic scheme begins with a simple concept. The AI WML will be able to specify the order in which various objectives are accomplished, and by what units those orders are filled. Consider that currently, the AI pursues its goals in a very specific order (combat, village capture, healing, retreat, recruit...)

So, the first order of business is to enable the abilty to specify the order in which commands are executed. As a further refinement, we allow the order to restrict what type of units the order applies to. Inside the order are a series of commands that are executed. Units that fill that order remember which order they are following (via the ai_special tag in the unit) until they are reassigned. Units that have no ai_special are part of the "default" orders. Initially, any [fill] commands are executed within the order. After this, units are sorted according to any [sort] commands
Then, for each unit in order the remaining commands are executed by that unit before the next unit executes the commands.

[order]#This tag specifies the beginning of an order description.
name = #the name of the order. Acts to id units that are part of this order
id = #uniq ID of this order tag. Used when executing summon commands.
execute = # yes(default) or no. If yes will execute when encountered.
# If no, only executed if explicitly called by an execute command.
memory = #In the various calculations, use the last seen locations of units that
# are now invisible if they were last seen within memory turns.
priority = # determines if order can steal units from other orders during fill.
# can only steal units from orders with strictly lower priority.
# units of equal or greater priority will ignore the request to fill
# the order. default value = 0
[fill]#command to attempt to fill the order with units that match the appropriate unit filter
number = #command of how many units to fill that match the filter
[filter]#standard unit filter.[/filter]
sort = #evaluation of how to choose which unit to accept first. Higher value chosen first.
[/fill]
[sort]
[filter]#standard unit filter.
[/filter]
sort = #evaluation of how to choose which unit to accept first. Higher value chosen first.
[/sort]
[command]#generic tags for all commands
[filter]#standard unit filter. limits which units will execute this command.
[/filter]
type = #type of command to execute. command specific WML tags below
[/command]#move command
type = moveto # move to target.
[command]
type = set_order # change the unit to be a part of a different order
[/command]
[command]
type = break # stop executing this order for this unit.
#Should really have a filter otherwise makes all following commands never be executed.
[/command]
[command]
type = attack # execute an attack. Does not move the unit!
[/command]
[command]
type = recruit # recruit units. Does not move the unit!
[/command]
[command]
type = execute # execute the following order before continuing.
id = #id of order to execute
[/command]
[command]
type = summon # summon units to give current unit a boost before combat.
#possibly will be eliminated in favor of the execute command.
[/command]
[/order]

Note that orders with the same name can be used multiple times and will keep the same units between calls, but they should each have a unique id.

'''Evaluators'''

Within the many options, there will be various parameters that need to be calculated, especially numeric ones. A large number of them will be possible to be specified as an expression that will be evaluated at the time the order is being executed. Most of these will be numeric. To make this more flexible, these values will allow the use of simple arithmetic expressions, wml variables, and some specialized function calls. A typical example might look like:

sort_value = $villages + (2*$enemies) / @distance(@unit(),@target(fool))

In this case the first thing that is evaluated are the functions that are designated by beginning with an @ followed by the function name and a parenthetical expression that encloses a parameter string. Typically these functions will evaluate the parameter string in a similar manner before returning a value. The next thing that is evaluated are things within paranthesis followed by WML variables designated with a $ at the beginning, and finally the arithmetic expression evaluated with the standard precedence.

Items within an individual command will be evaluated before the command is executed.
Items within an individual order will be evaluated at the begining of the order.
Items within the AI tag will be evaluated only at the beginning of the turn.

The use of evaluators will make it possible to control many of the AI parameters indirectly via WML variables that are set/changed within events.

User:Darth Fool

2007-05-18T04:07:21Z

Darth Fool:

This page is intended as a development page for the documentation of the new AI that I am working on. When the AI is officially released, the information will be migrated to the official wml reference pages. Some of this is partially implemented, some of it has not yet been implemented, and some of these are planned changes to something that is already implemented, and all of it is subject to change in the code without notification. So, in short, don't start using this in your scenarios and expect it to work just yet, or even to still be the same by the time of the official release. This is primarily meant as a way to organize my thoughts and reduce the time from when the code is complete to when the new AI is fully documented. You have been warned.

----

'''The Grand Idea'''

Ok, so what is this AI supposed to accomplish anyways. Well, it has many goals, but most of them can be wrapped up in the following statement: The AI should be sufficiently flexible to be able to specify parameters so that it can win Heir To The Throne on easy without cheating. That means, no knowing where things are before they are discovered (scepter of fire), no knowing where hidden or fogged units are, etc... Along the way, we should end up with an AI that makes it quite possible to create much more interesting AI behaviour in campaigns. so, how to accomplish this?

'''Orders'''

The basic scheme begins with a simple concept. The AI WML will be able to specify the order in which various objectives are accomplished, and by what units those orders are filled. Consider that currently, the AI pursues its goals in a very specific order (combat, village capture, healing, retreat, recruit...)

So, the first order of business is to enable the abilty to specify the order in which commands are executed. As a further refinement, we allow the order to restrict what type of units the order applies to. Inside the order are a series of commands that are executed. Units that fill that order remember which order they are following (via the ai_special tag in the unit) until they are reassigned. Units that have no ai_special are part of the "default" orders. Initially, any [fill] commands are executed within the order. After this, units are sorted according to any [sort] commands
Then, for each unit in order the remaining commands are executed by that unit before the next unit executes the commands.

[order]#This tag specifies the beginning of an order description.
name = #the name of the order. Acts to id units that are part of this order
id = #uniq ID of this order tag. Used when executing summon commands.
execute = # yes(default) or no. If yes will execute when encountered.
# If no, only executed if explicitly called by an execute command.
memory = #In the various calculations, use the last seen locations of units that
# are now invisible if they were last seen within memory turns.
[fill]#command to attempt to fill the order with units that match the appropriate unit filter
number = #command of how many units to fill that match the filter
[filter]#standard unit filter.[/filter]
sort = #evaluation of how to choose which unit to accept first. Higher value chosen first.
[/fill]
[sort]
[filter]#standard unit filter.
[/filter]
sort = #evaluation of how to choose which unit to accept first. Higher value chosen first.
[/sort]
[command]#generic tags for all commands
[filter]#standard unit filter. limits which units will execute this command.
[/filter]
type = #type of command to execute. command specific WML tags below
[/command]#move command
type = moveto # move to target.
[command]
type = set_order # change the unit to be a part of a different order
[/command]
[command]
type = break # stop executing this order for this unit.
#Should really have a filter otherwise makes all following commands never be executed.
[/command]
[command]
type = attack # execute an attack. Does not move the unit!
[/command]
[command]
type = recruit # recruit units. Does not move the unit!
[/command]
[command]
type = execute # execute the following order before continuing.
id = #id of order to execute
[/command]
[command]
type = summon # summon units to give current unit a boost before combat.
#possibly will be eliminated in favor of the execute command.
[/command]
[/order]

Note that orders with the same name can be used multiple times and will keep the same units between calls, but they should each have a unique id.

'''Evaluators'''

Within the many options, there will be various parameters that need to be calculated, especially numeric ones. A large number of them will be possible to be specified as an expression that will be evaluated at the time the order is being executed. Most of these will be numeric. To make this more flexible, these values will allow the use of simple arithmetic expressions, wml variables, and some specialized function calls. A typical example might look like:

sort_value = $villages + (2*$enemies) / @distance(@unit(),@target(fool))

In this case the first thing that is evaluated are the functions that are designated by beginning with an @ followed by the function name and a parenthetical expression that encloses a parameter string. Typically these functions will evaluate the parameter string in a similar manner before returning a value. The next thing that is evaluated are things within paranthesis followed by WML variables designated with a $ at the beginning, and finally the arithmetic expression evaluated with the standard precedence.

Items within an individual command will be evaluated before the command is executed.
Items within an individual order will be evaluated at the begining of the order.
Items within the AI tag will be evaluated only at the beginning of the turn.

The use of evaluators will make it possible to control many of the AI parameters indirectly via WML variables that are set/changed within events.

User:Darth Fool

2007-05-18T04:02:58Z

Darth Fool:

This page is intended as a development page for the documentation of the new AI that I am working on. When the AI is officially released, the information will be migrated to the official wml reference pages. Some of this is partially implemented, some of it has not yet been implemented, and some of these are planned changes to something that is already implemented, and all of it is subject to change in the code without notification. So, in short, don't start using this in your scenarios and expect it to work just yet, or even to still be the same by the time of the official release. This is primarily meant as a way to organize my thoughts and reduce the time from when the code is complete to when the new AI is fully documented. You have been warned.

----

'''The Grand Idea'''

Ok, so what is this AI supposed to accomplish anyways. Well, it has many goals, but most of them can be wrapped up in the following statement: The AI should be sufficiently flexible to be able to specify parameters so that it can win Heir To The Throne on easy without cheating. That means, no knowing where things are before they are discovered (scepter of fire), no knowing where hidden or fogged units are, etc... Along the way, we should end up with an AI that makes it quite possible to create much more interesting AI behaviour in campaigns. so, how to accomplish this?

'''Orders'''

The basic scheme begins with a simple concept. The AI WML will be able to specify the order in which various objectives are accomplished, and by what units those orders are filled. Consider that currently, the AI pursues its goals in a very specific order (combat, village capture, healing, retreat, recruit...)

So, the first order of business is to enable the abilty to specify the order in which commands are executed. As a further refinement, we allow the order to restrict what type of units the order applies to. Inside the order are a series of commands that are executed. Units that fill that order remember which order they are following (via the ai_special tag in the unit) until they are reassigned. Units that have no ai_special are part of the "default" orders. Initially, any [fill] commands are executed within the order. After this, units are sorted according to any [sort] commands
Then, for each unit in order the remaining commands are executed by that unit before the next unit executes the commands.

[order]#This tag specifies the beginning of an order description.
name = #the name of the order. Acts to id units that are part of this order
id = #uniq ID of this order tag. Used when executing summon commands.
execute = # yes(default) or no. If yes will execute when encountered.
# If no, only executed if explicitly called by an execute command.
memory = #In the various calculations, use the last seen locations of units that
# are now invisible if they were last seen within memory turns.
[fill]#command to attempt to fill the order with units that match the appropriate unit filter
number = #command of how many units to fill that match the filter
[filter]#standard unit filter.[/filter]
sort = #evaluation of how to choose which unit to accept first. Higher value chosen first.
[/fill]
[sort]
[filter]#standard unit filter.
[/filter]
sort = #evaluation of how to choose which unit to accept first. Higher value chosen first.
[/sort]
[command]#generic tags for all commands
[filter]#standard unit filter. limits which units will execute this command.
[/filter]
type = #type of command to execute. command specific WML tags below
[/command]#move command
type = moveto # move to target.
[command]
type = set_order # change the unit to be a part of a different order
[/command]
[command]
type = break # stop executing this order for this unit.
#Should really have a filter otherwise makes all following commands never be executed.
[/command]
[command]
type = attack # execute an attack. Does not move the unit!
[/command]
[command]
type = recruit # recruit units. Does not move the unit!
[/command]
[command]
type = execute # execute the following order before continuing.
id = #id of order to execute
[/command]
[command]
type = summon # summon units to give current unit a boost before combat.
#possibly will be eliminated in favor of the execute command.
[/command]
[/order]

Note that orders with the same name can be used multiple times and will keep the same units between calls, but they should each have a unique id.

'''Evaluators'''

Within the many options, there will be various parameters that need to be calculated, especially numeric ones. A large number of them will be possible to be specified as an expression that will be evaluated at the time the order is being executed. Most of these will be numeric. To make this more flexible, these values will allow the use of simple arithmetic expressions, wml variables, and some specialized function calls. A typical example might look like:

sort_value = $villages + (2*$enemies) / @distance(@unit(),@target(fool))

In this case the first thing that is evaluated are the functions that are designated by beginning with an @ followed by the function name and a parenthetical expression that encloses a parameter string. Typically these functions will evaluate the parameter string in a similar manner before returning a value. The next thing that is evaluated are things within paranthesis followed by WML variables designated with a $ at the beginning, and finally the arithmetic expression evaluated with the standard precedence.

Items within an individual command will be evaluated before the command is executed.
Items within an individual order will be evaluated at the begining of the order.
Items within the AI tag will be evaluated only at the beginning of the turn.

User:Darth Fool

2007-05-18T03:39:50Z

Darth Fool:

User:Darth Fool

2007-05-18T03:28:49Z

Darth Fool:

User:Darth Fool

2007-05-18T03:27:50Z

Darth Fool:

User:Darth Fool

2007-05-18T03:26:41Z

Darth Fool:

User:Darth Fool

2007-05-18T03:25:58Z

Darth Fool:

User:Darth Fool

2007-05-18T03:25:33Z

Darth Fool:

EventWML

2006-11-18T23:23:53Z

Darth Fool: /* the [event] tag */

{{WML Tags}}
== the [event] tag ==

This tag is a subtag of [scenario] (or [unit] - see '''event''', [[UnitWML]]) which is used to describe a set of actions
which trigger at a certain point in the scenario.

keys and tags that describe when the event should trigger:
<ul><li> ''name'' this is not like a normal 'name' key. It is a basic description of when the event will trigger.
* ''prestart'' the event is triggered before a scenario 'starts' -- before anything is shown on the screen at all. You can use this event to set up things like village ownership. For things displayed on-screen such as character dialog, use 'start'.
* ''start'' this event triggers after the map is shown but before the scenario begins
* ''new turn'' this event triggers whenever the last player ends their turn. See also '''first_time_only=no'''. When the last player ends their turn, before any events of this type trigger, the value of the WML variable '''turn_number''' is set to the number of the turn that is beginning.
* ''side turn'' this event triggers when a side starts it's turn. Before events of this type trigger, the value of the WML variable '''side_number''' is set to the number of the side of the player about to take their turn.
* ''turn ''X'''' this event triggers at the start of turn ''X''. ''X'' cannot be 1.
* ''time over'' this event triggers on turn ''turns''. (''turns'' is specified in [scenario])
* ''enemies defeated'' this event triggers when all units with '''canrecruit=1''' (i.e. all leaders) not allied with side 1 are killed.
* ''victory'' in this scenario, any tag of the form '''[endlevel] result=victory [/endlevel]''' will be automatically preceded by all actions in this tag. It helps debugging if the victory event allows you to safely advance to any of the possible next maps after using the ":n" command. Scenarios where key units are picked up before the victory, or where some action chosen earlier determines which map to advance to, make it hard to quickly test scenarios in a campaign. (See also [endlevel], [[DirectActionsWML]])
* ''defeat'' in this scenario, any tag of the form '''[endlevel] result=defeat [/endlevel]''' will be automatically preceded by all actions in this tag. (See also [endlevel], [[DirectActionsWML]])
* ''ai turn'' is triggered just before the AI is invoked for a player. This is called after ''side turn'', so if you move a unit here, its movement will not be reset .

Events with the following trigger types can be filtered on (see [[FilterWML]]).
Whenever one of these events is triggered,
the position of ''primary_unit'' is stored in the variables 'x1' and 'y1',
and the position of ''secondary_unit'' is stored in 'x2' and 'y2'.

* ''moveto'' triggers after ''primary_unit'' moves. Usually the location of ''primary_unit'' is also filtered on; remember that this is the location that ''primary_unit'' lands on, not the location it started on or any location it travels on.
* ''sighted'' this event triggers when ''primary_unit'' moves to a location where ''secondary_unit'' is in ''primary_unit'''s sight range. Works only in shroud or fog.
* ''attack'' this event triggers when ''primary_unit'' attacks ''secondary_unit''.
* ''attacker_hits'' this event triggers when the attacker (''primary_unit'') hits the defender (''secondary_unit'').
* ''attacker_misses''} same as ''attacker_hits'', but is triggered when the attacker misses.
* ''defender_hits'' this event triggers when the attacker (''primary_unit'') is hit in retaliation by the defender (''secondary_unit'').
* ''defender_misses'' same as ''defender_hits'', but is triggered when the defender misses.
* ''attack_end'' is similar to ''attack'', but is instead triggered after the fight, not before. Note that if either unit is killed during the fight, this event triggers before any ''die'' events.
* ''stone'' this event triggers when ''primary_unit'' is hit by an attack with the 'stones' ability (See ''stones'', [[AbilitiesWML]]) by ''secondary_unit'' (''secondary_unit'' is the unit with the 'stones' ability.)
* ''die'' this event triggers when ''primary_unit'' is killed by ''secondary_unit''.
* ''capture'' this event triggers when ''primary_unit'' captures a village. The village may have been previously neutral, or previously owned by another side; merely moving into your own villages does not constitute a capture.
* ''recruit'' this event triggers when ''primary_unit'' is recruited or recalled. (That is, when a unit is recruited or recalled, it will trigger this event and this event's filter will filter that unit.)
* ''prerecruit'' this event triggers when ''primary_unit'' is recruited, but before it is displayed.
* ''advance'' this event triggers just before ''primary_unit'' is going to advance to another unit.
* ''post_advance'' this event triggers just after ''primary_unit'' has advanced to another unit.
* ''select'' triggers when a unit is selected. Mainly useful for the tutorial.

An '''[allow_undo]''' tag anywhere within a moveto event will cancel any lack of undo functionality the event would have
caused. It is up to the scenario designer to avoid abusing this command by allowing undo on events that shouldn't be
undoable. The results of doing this may be strange. This actually does have functionality beyond aesthetics like
signs: suppose you have an event that performs some action depending on the condition of an 'if' statement. This event
might be executed on every single move, but the body of the 'if' statement entered only in a few cases. Previously
this would completely disable undo for the entire scenario, while now it can be made to only disable undo in the cases
where the event mutates the scenario.
</li></ul>

''Primary_unit'' can be referred to as '''unit''' and ''Secondary_unit'' can be referred to as '''second_unit''' in [message] tags. For example:
[event]
name=die
[message]
speaker=second_unit
message="Hahaha, I finally killed you!"
[/message]

[message]
speaker=unit
message="It's not over yet! I'll come back to haunt you!"
[/message]
[/event]

These keys and tags are more complex ways to filter when an event should trigger:
* ''first_time_only'' whether the event should be removed from the scenario after it is triggered. Default is 'yes'.
* '''[filter]''' the event will only trigger if ''primary_unit'' matches this filter.
** standard unit filter - attributes for [filter] are described in [[FilterWML]]
* '''[filter_second]''' is like [filter], but for ''secondary_unit''.
** standard unit filter
* '''[special_filter]''' and '''[special_filter_second]''' can be used to set some additional filtering criteria for ''primary_unit'' and ''secondary_unit'' that are not generally available in a standard unit filter. Can be used in events ''attack'', ''attacker_hits'', ''attacker_misses'', ''defender_hits'', ''defender_misses'' and ''attack_end''.
** ''weapon'' the name of the weapon used.
** ''terrain'' the letter of the terrain the unit is on.

=== Actions triggered by [event] ===

After the trigger conditions have been met, all action tags within the [event] tag are executed in the order they are written in.

There are 3 main types of actions:
* direct actions ([[DirectActionsWML]]) which have a direct effect on gameplay
* display actions ([[InterfaceActionsWML]]) which show something to the user
* internal actions ([[InternalActionsWML]]) which are used by WML internally

Several actions use standard filters to find out which units
to execute the command on. These are denoted by the phrases
"standard unit filter" and "standard location filter".

=== Nested events ===

There is 1 special type of action: event creation. By placing an '''[event]''' tag inside another '''[event]''' tag, the nested event is created when the outer event executes. For example, you could create a portal that opens on turn 10. The outer event executes on turn 10, creating the nested moveto event, which executes when a player steps on a certain spot. An equivalent way of doing this would be to a single moveto event with an if statement to check for turn number, but using nested '''[event]''' tags is a simple and elegant way to accomplish more complex tasks without resorting to excessive if statements.

== See Also ==

* [[DirectActionsWML]]
* [[InternalActionsWML]]
* [[InterfaceActionsWML]]
* [[FilterWML]]
* [[ReferenceWML]]

[[Category: WML Reference]]

User:Ayin/New terrain graphics system proposal

2005-10-15T19:05:19Z

Darth Fool: /* Hard to understand */

This page is a working document for a proposal for a complete rewrite of the terrain graphics system. It may be considered as a counter-proposal to the [[User:Ayin/Extended terrains proposal|extended terrains proposal]].

__TOC__

==Motivations for the proposal==

The current terrain-graphics system is a powerful, albeit complex, system whose purpose is to transform maps (which are, basically, 2-dimensional arrays containing 1-character terrains) into a list of graphics for each location in the map.

The base for the system, and the root of a <tt>terrain_graphics</tt> rule, is: "'''pattern of terrains''' => '''associated images'''". In my ([[User:Ayin|Ayin]] <sup>[[User_talk:Ayin|(talk)]]</sup>) opinion, pattern-based rules are the way to go: those are simple to understand, and allow nearly anything.

However, the current system (see documentation here [[TerrainGraphicsWML]], or, better, [http://www.anathas.org/ayin/wesnoth/doc/terrain_graphics_wml here]) has several drawbacks, which I will try to detail below:

=== Very WML-intensive ===

The basic, pattern => images system, is quite hard to type effectively in WML.

One simple, standard rule takes about 20 to 50 lines of WML. Considering that completely defining a "castle" with a keep takes about 7 rules (using rotation symetries), and a basic transition takes 4 rules (again, using rotation symetries), this means about 200 lines of WML to completely define a transition.

To solve this problem, the WML macro system is used quite intensively. Considering that the <tt>terrain-graphics.cfg</tt> file only contains macros and comments, and is about 800 lines long, and considering each macro rule generates, more or less, 40 lines of WML, this amounts to many lines of WML for the engine. Some testing shown this amounts to about 13000 lines in Wesnoth 1.1-svn. This is about 1/4 of the WML cache.

The problem with this use of macros is that directly coding <tt>terrain_graphics</tt> rules is pretty much deprecated: it is recommended to use macros which re-use already-created rulesets instead of directly using new ones. We are more or less falling in the situation of Sendmail, where what was originally a "config file" became "program logic", and where the "config file" uses some macro system to transform higher-level macros into the actual low-level file which is then parsed by the compiled program.

This is a bad thing.

=== Relatively slow ===

Although there have been many optimizations in this way, rebuilding the list of terrain graphics (when, for example, a terrain has changed) still is pretty slow on older computers.

=== Quite a complex system ===

The pattern => images system is something very simple, conceptually. However, to be able to properly generate terrain graphics, the following subtelties must be taken into account:

;Rule overlapping
:The main problem with this approach is to specify precedence, and mutual-exclusiveness, of rules. For example, rules can be mutually-exclusive:
:*on an hex (only one rule of this "kind" can apply on a given hex)
:*on a hex border (only one rule of this "kind" can apply on a given hex border)
:*or on a hex corner (only one rule of this "kind" can apply on a given hex corner)
:Furthermore, some rules have to be independant one from the other (for example, rules defining the base terrains and transitions, and rules defining the overlay graphics, are totally independant), and some rules are mutually exclusive (for example, all rules defining base terrain transitions are mutually exclusives on hex borders, all rules defining base terrains are mutually exclusive on hexes, all rules defining some kind of castle-like fence are mutually exclusive on hex corners).
:To solve this problem, a rule may apply "flags" on some hexes, and check for the presence, or absence, of flags before being applyied.
;Image ordering and adjustment
:Images will necessarily have to overlap. The overlapping order of images is the source of many potential graphical glitches. A simple, layer-based mode to specify the overlapping order of images is not enough, nor is the "drawing in the order the rules are defined" solution.
:The current system uses an ordering model based on 2 different shapes for images:
:*Images representing terrains layered over the floor. Those use a simple layer-based model
:*Images representing terrains standing vertically on the floor. Those have x,y coordinates, and are layered in the logical order. Specifying those coordinates seems quite hard to many terrain developers.
;Using symetry properties
:Most rules (hopefully) have 6-way rotational symetry properties. If they had not, the already huge amount of WML used would actually have to be multiplicated by 6. However, defining template-like rules which spawn 6 actual, rotated rules is not trivial:
:*The rule itself can be rotated, but not the images themselves. Said images must have different filenames. The rule rotation must then have a way to specify the name of those files.
:*Same for flags and rule overlapping
:*Same (worse?) for layering of "vertical" images.

===Hard to understand===

Overall, the system has many possibilities, which have successfully been used to expand the graphics possiblities on Wesnoth. However, it looks like that few (no?) people understand it enough to use it effectively, and that the only solution, for graphics designers, to implement new ideas or to fix glitches is to ask me, on IRC, how to do it. As said above, the system is split in two parts:

* A WML part which can be considered program logic, which is quite complex. For a long time I ([[User:Ayin|Ayin]] <sup>[[User_talk:Ayin|(talk)]]</sup>) was the only one to actually commit changes in this part. There has only been one other commit, made by Darth Fool for use with the ruins graphics. He has promptly forget everything he knew about terrain WML and continues to point people at Ayin when questions are asked of him.
* A WML-macro parts which is more-or-less accessible to artists, but which still retains a large part of black magic. (For example: "<tt>{TERRAIN_ADJACENT_CORNER_PROB K q !NQqCK 56,76 sunken-ruinkeep3-wall-1 25}</tt>": who know what those "56,76" numbers mean? And what would happen if those were changed?)

I've been starting to thing the problem is that the system is too powerful, and that going all-WML may not necessarily be a good idea. Being generic is good, being too generic may prove harmful.

==Proposals==

===Part 1: Make terrain_graphics WML driven by terrain WML===

Part 1 of the proposal is to make <tt>terrain</tt> WML define which rules are to be associated to a given terrain. For example:

[terrain]
id=grassland
name= _ "Grassland"
char=g
'''graphics=grassland'''
[/terrain]

[terrain]
symbol_image=village-elven-tile
id=village
name= _ "Village"
char=t
heals=true
gives_income=true
'''graphics=grassland,elven-village'''
[/terrain]

[terrain]
symbol_image=forest-tile
id=forest
name= _ "Forest"
char=f
'''graphics=grassland,forest'''
[/terrain]

The <tt>terrain_graphics</tt> rules would not apply on terrain characters anymore, but would, instead, apply on symbols like "grassland", "forest", "village", etc.

===Part 2: Use modular terrain graphics code===
====Basics====

If only coders can modify the rulesets which build terrains, that's OK, but then, there's no point anymore to define rulesets using WML then.

The proposal is to have a common C++ API which would be used to define terrain graphics modules. Terrain graphics WML would then be used to instantiate such modules with parameters.

The following WML elements would be present:

;module
:The name of the module, as defined in the game code.
;terrain_type_X
:A "terrain type" parameter. Modules may require 1, 2, or more terrain types. Those are module-specific. Those actually correspond to the <tt>graphics</tt> WML element of the <tt>terrain</tt> WML (see part 1 of the proposition)
;image_basename
:A parameter from which the module will derive the actual name of the images used (for example, if this is "grassland", the module "base-terrain" will determine that the names of the actual files to use are "grassland.png", "grassland-nw.png", etc.

====Other====

* Specify several image probabilities
* Specify animations
* Other types of per-module parameters?

====Examples====
[terrain_graphics]
module="base-terrain"
terrain_type_1="grassland"
terrain_type_2="! grassland"
image_basename="grassland:80,grassland-v2:10,grassland-v3:10"
[/terrain_graphics]

[terrain_graphics]
module="overlay-image"
terrain-type_1="village"
image_basename="human-village"
[/terrain_graphics]

The castles would still have a bit of complexity in them, as there are many kinds of 3-way transitions possibles.

[terrain_graphics]
module=wall
terrain_type_1="castle"
terrain_type_2="!castle,!keep,!encampment"
terrain_type_3="!castle,!keep,!encampment"
image_basename="castle-convex"
[/terrain_graphics]

[terrain_graphics]
module=wall
terrain_type_1="!castle,!keep,!encampment"
terrain_type_2="castle"
terrain_type_3="castle"
image_basename="castle-concave"
[/terrain_graphics]

====Modules to create====

According to what is currently done in the code, the following modules would need to be developed:

* base-terrain. Basic terrain with standard transitions. to remplace TERRAIN_BASE, TERRAIN_BASE_PROB, and TERRAIN_ADJACENT.
* wall. To replace terrain-adjacent-corner.
* overlay-image. To replace SHEX and BUILDING.
* canyon.
* bridge.

====Module API====

This is a proposal for a terrain_graphics module API. Modules should, ideally, be very short, independant fragments of C++ code.

''// Represents an image set as defined in the [terrain_graphics] WML, and handling probs''
''// and animations transparently''.
''// operator+(const std::string&) is defined, to add a suffix to animated or probabilized images.''
class imageset;

class terrain_pattern;

class module
{
public:
module(gamemap& map, imageset& set);

virtual void fill_terrains_for(const gamemap::location&)
protected:
const gamemap& map() const;
void insert_image_flat(int layer, imageset&) const;
void insert_image_vertical(pos, imageset&) const;

bool tile_matches(const gamemap::location& loc, const terrain_pattern& pattern);
const gamemap::location adjacent_tile(const gamemap::location& loc, int position);

imageset& image_basename() const; ''// Corresponds to image_basename in the WML''
std::vector<terrain_pattern> terrain_types; ''// Corresponds to terrain_types in the WML''

std::string corner_name(int corner);
std::string edge_name(int edge);
}

''// Sample code for the "wall" module''
module_wall : public module
{
public:
virtual void fill_terrains_for(const gamemap::location& loc)
{
for (int i = 0; i < 6; ++i) {
if (tile_matches(loc, tile_terrain_types[0]) &&
tile_matches(ajacent_tile(loc, i), terrain_types[1]) &&
tile_matches(adjacent_tile(loc, i+1), terrain_types[2])) {

insert_image_vertical(i, image_basename() + corner_name(i));
}
}
}

===Part 3: Sanitize the vertical layering code===

The vertical layering system, using x,y coordinates for the "base point" of a vertical item, is more complicated than necessary. The following points must be taked into account:

* Only y-layering is important. x-layering was only used when rotating rules, which, according to part 2, will be directly managed by modules.
* The "pixel size" of a tile, and x-layering of images, are totally unrelated concepts. There is no need for 72 layers per hexes. 3, 5, or 7 layers should be enough.
* Calculating the rectangular coordinates of a point in a hex-system is a pain. Coordinates should be expressed relatively to hexes, not in cartesian coordinates.
* The "backside" layer of an hex should '''always''' be '''in front''' of the "frontside" layer of hexes behind it. This rule should save us many headaches about graphic glitches.

CommandMode

2005-08-14T04:46:58Z

Darth Fool: /* Command Mode */

== Command Mode ==

You can access command mode by typing ':' in a single or multi player scenario.
More accurately, you need to type shift - semicolon( ''';''' ).
However this isn't possible on all keyboards;
if your keyboard doesn't have ':' above ';' you can change
the hotkey in the Preferences, or you could edit '''game.cfg''' by hand.'

Several vi-like commands are available in command mode.
They are defined in ''playturn.cpp'' in the ''turn_info::do_command()'' function:
* ''':q|| or ||:q!''' quit the scenario (without prompting)
* ''':w''' save the game (without prompting)
* ''':wq''' save the game and quit the scenario (without prompting)
* ''':refresh''' redraw the screen
* ''':droid side''' toggle player on side between human and AI players
* ''':kick''' kick a user in multiplayer. They will be able to rejoin the game.
Generally a friendly way to remove someone who is having connection or other difficulties.
* ''':ban''' kick and ban a user in multiplayer, and the IP address used by that username
* ''':control ''side'' ''player//''' change the controller for ''side'' to ''player''
* ''':clear''' clear chat messages
* ''':debug''' switch debug mode on
* ''':debug off''' switch debug mode off
* ''':theme''' bring up theme selection menu

[[DebugMode]] enables additional commands in command mode:
* ''':n''' skip to next scenario by triggering a win event
* ''':gold ''amount//''' add ''amount'' gold to the current player's side
* ''':create ''unit_type''''' create a unit of type specified at last selected hex
* ''':unit ''attribute//=//value''''' when a unit is selected, this will set
the unit's ''attribute'' to ''value''.
See [[SingleUnitWML]] for possible values.

== See Also ==

* [[DebugMode]]
* [[DeveloperResources]]

CommandMode

2005-08-14T04:46:24Z

Darth Fool: /* Command Mode */

== Command Mode ==

You can access command mode by typing ':' in a single or multi player scenario.
More accurately, you need to type shift - semicolon( ''';''' ).
However this isn't possible on all keyboards;
if your keyboard doesn't have ':' above ';' you can change
the hotkey in the Preferences, or you could edit '''game.cfg''' by hand.'

Several vi-like commands are available in command mode.
They are defined in ''playturn.cpp'' in the ''turn_info::do_command()'' function:
* ''':q|| or ||:q!''' quit the scenario (without prompting)
* ''':w''' save the game (without prompting)
* ''':wq''' save the game and quit the scenario (without prompting)
* ''':refresh''' redraw the screen
* ''':droid X''' toggle player X between human and AI players
* ''':kick''' kick a user in multiplayer. They will be able to rejoin the game.
Generally a friendly way to remove someone who is having connection or other difficulties.
* ''':ban''' kick and ban a user in multiplayer, and the IP address used by that username
* ''':control ''side'' ''player//''' change the controller for ''side'' to ''player''
* ''':clear''' clear chat messages
* ''':debug''' switch debug mode on
* ''':debug off''' switch debug mode off
* ''':theme''' bring up theme selection menu

[[DebugMode]] enables additional commands in command mode:
* ''':n''' skip to next scenario by triggering a win event
* ''':gold ''amount//''' add ''amount'' gold to the current player's side
* ''':create ''unit_type''''' create a unit of type specified at last selected hex
* ''':unit ''attribute//=//value''''' when a unit is selected, this will set
the unit's ''attribute'' to ''value''.
See [[SingleUnitWML]] for possible values.

== See Also ==

* [[DebugMode]]
* [[DeveloperResources]]