The Battle for Wesnoth Wiki - User contributions [en]

SummerOfCodeIdeas

2008-02-27T23:20:06Z

Rhuvaen: added MapGenerator to other ideas

== Ideas for Google Summer of Code projects ==

This is a compilation of ideas from ML. Needs to be refined (more detailed description, deliverables, workload estimation?):

== List of Ideas for the Project ==

=== Writing an AI based on the formula AI ===

Wesnoth has always had a simple C++ based AI. David (our lead developer) has been working on a simple language to write AI in Wesnoth ''link to formula AI page here''

The Wesnoth AI is used as an opponent in most campaigns, and as such is an important piece of code for the Wesnoth project. Unfortunately it is also one of the most neglected piece of code and a place where a lot of research and work could be done

==== General description ====

The aim of this project is to develop a new AI that would replace the original C++ AI. The main criterias we would want for this new AI are

* ''Plugability :'' It should be trivial for any content maker to change the behavior of the AI in specific case. The exact cases are still to be defined but should typically include
** hardwiring the first few turns of the AI
** changing the recruitment pattern
** completely controlling a given unit (scenario unit)
** taking control then giving back control of a given unit
* ''tunability :'' It should be easy for a scenario author to specify the general behaviour of the enemy on a given scenario (aggressiveness, intrepidity...)
* ''specific behaviours :'' there are some typical behaviours that are not smart to win the scenario but are needed, such as guarding a given unit, a given position, wandering aimlessly, attacking randomly, always fleeing. The AI should implement such behaviours, and allow easy addition of new behaviours

==== Required knowledge and talent ====

* ''A minimal knowledge of C++ is required, a good knowledge of C++ is desired :'' The formula AI framework is a work in progress and chances are high that some changes in the wesnoth code base will be needed. The wesnoth developer community is used to handle people that are familiar with coding but not C++, however the Formula AI framework uses advanced C++ features and a good knowledge of the language would avoid a major hurdle when plugging in new entries or functionalities for the AI
* ''Good social interaction with a large player community :'' A preliminary phase to coding any AI is to know the strategies and game pattern used by human players. This requires huge interaction with the player community. Our Gameplay Developers are open and can give some good starting points, but a big game experience and good interaction with the player community will greatly help in the study of the design

==== Milestones and deliverables ====

It is hard to give milestones at this point, but here are some ideas of what could be done

* ''AI design description, and basic function library :'' This first deliverable aims to conclude the '''study and analysis''' part of the project : becoming familiar with the formula language, study of multiplayer strategies and of the need of scenario writers with regard to AI. We would like to have a description of the code structure of the AI, some basis of the play strategies it would use and how external scenario writers could configure it for the particular behaviour they need
* ''Main AI delivery :'' This milestone's aim is to deliver a working AI implementing the strategies described in the first phase. It would not have to systematically beat the standard C++ AI at this point, but should be able to play the game correctly (recruit, early deployment on villages, grouping units to attack, holding its ground, protecting weak/important units). Moreover most plug-in entries should be available and a test-case for these entries should be provided.
* ''Fine tunning and behaviour library :'' The third phase would validate the actual strategy of the AI. The AI should consistently beat the default C++ AI, and do fairly well against an average human player. At that stage a library of scenario behaviours should also be delivered. The AI does not need to be as efficient with all scenario tweaking, but should act correctly with regard to the particular behaviour desired.

=== Extending the Multiplayer server ===

When the development team met at FOSDEM, we had our multiplayer community, though it is strong and healthy, had its growth restrained by the interface of the multiplayer lobby.

==== General Description ====
The general idea of this project would be
* To study the current lobby,
* To present some ideas of evolutions both in interface and functionalities of our multiplayer interface to allow it to scale to a much larger community
* To present some well constructed thought on our MP community and how that interface would develop it
* Of course to implement those changes :)

Some ideas that we had (but that are in no way mandatory)
* Having a simple way to register and authenticate nicknames, similar to what IRC offers. The point is not to have cryptographically safe logins, but to have something simple that gets the job done
* Having a simple room system? again inspired on IRC
* Having some way to find the type of games you are interested in.
** game type
** number of free slots/players
** any other criteria you might find interesting

Other ideas we are not convinced are good, but that are certainly worth studying (especially how the communities based around these concepts are different from ours)
* ranking players
* guilds
* official tournaments
* titles for players
* metaservers

The scalability of the project, both in term of number of players, and in term of the possibility for players and developers to extend the concept will be a valued criteria

Administration/moderation problems and techniques should also be studied

interaction with the Add-On server/forum might be an interesting field to expand to

==== Required knowledge and talent ====

* A fair amount of experience on C++ is required. Wesnoth uses some advanced C++ features and is heavily based on BOOST and STL. We can train you in some of the libraries used, but learning all of them would be a big hurdle
* Various experience with multiplayer games, in order to have a good idea of what multiplayer lobbies of other game look like, and (more importantly) a good idea of the social behaviours of multiple MP communities, how teams are formed in games and things like that

==== Milestones and deliverables ====

* A first milestone would be a presentation summarizing the different studies, and the proposed interface. preliminary informal stages would probably be desirable, to make sure the proposed idea is already a consensus within devs
** Study of other MP game-matching interfaces and functionalities
** Study of other MP communities
** Study of other MP moderation practices
** Study of the Wesnoth MP community, including needs, various opinons from different developers and players
* A second milestone would be the main code delivery. Code should be functional for it will be delivered in the next Wesnoth development release

=== Other ideas to be fleshed out ===
* Working on the GUI engine (needs to be defined more precisely)
* Rewrite of the campaign (add-on) server
* The editor can use quite a revamp
* A good scenario editor. We have campgen but it hasn't been updated for a while.
* A MapGenerator rewrite - better scalable for outdoor maps, plus the possibility to define areas (similar to the caverns in the ave generator) etc.

== Other info to provide for GSoC ==
==== Describe your organization. ====

==== Why is your organization applying to participate in GSoC 2008? What do you hope to gain by participating?====

Most of our developers have interesting areas in which they work. Though they are efficient in their areas, there are areas that are interesting but have a high barrier of entry.

By having a student dedicated to any of these areas, we could quickly get someone up to date with that particular area, efficient, and responsible of this area.

Basically, by getting new people in and making them actively responsible for an area of code we hope to kickstart some areas of the project that have lagged behind

==== Did your organization participate in past GSoCs? If so, please summarize your involvement and the successes and challenges of your participation.====
This is the first time the Wesnoth projects applies to Google SoC

==== If your organization has not previously participated in GSoC, have you applied in the past? If so, for what year(s)?====

This is the first time the Wesnoth projects applies to Google SoC

==== Who will your organization administrator be? Please include Google Account information.====
Nils Kneuper aka Ivanovic

crazy.ivanovic |ATTT| googlemail.com

==== What license(s) does your project use?====
Our project is entirely GPL.

All code is GPL.

All art is GPL, 99% was made for the project, everything was taken from content that was checked to be GPL.

==== What is the URL for your ideas page?====
Our main summer of code pages is located at http://www.wesnoth.org/wiki/SummerOfCodeIdeas

This page contains various coding ideas and the thought the development team has already given them.

It also contains a list of the developers that are the most active on IRC and their domain of interest.

==== What is the main development mailing list or forum for your organization?====
Most development work takes place on "wesnoth-dev |ATTT| gna.org". Beside this some work happens at http://www.wesnoth.org/forum/.

==== What is the main IRC channel for your organization?====

All our IRC channels are on the ''freenode'' network

* ''#wesnoth-dev'' is the main development channel, where most discussion takes place
* ''#wesnoth'' is a generic channel for the community
* ''#wesnoth-mp'' is a separate channel for multiplayer games and balancing

==== Does your organization have an application template you would like to see students use? If so, please provide it now.====
We plan mainly to meet potential students through our IRC channel, but the following questions are wesnoth-specific and are worth pondering for any student, even if we don't need a formal answer

* What type of gamer are you? What type of games? What type of opponent? Are you more interested in story or gameplay ?
* Are you good at interacting with other players ? Our developer community is quite nice, but the player community can be a bit rough.
* Do you give constructive advices? Do you receive advice well? Are you good at sorting useful criticism from useless ones?

''''to be completed''''

==== Who will be your backup organization administrator? Please include Google Account information.====

Jeremy Rosen alias Boucman

boucman2|ATTT|gmail.com

==== Who will your mentors be? Please include Google Account information.====

==== What criteria did you use to select these individuals as mentors? Please be as specific as possible.====

==== What is your plan for dealing with disappearing students?====

==== What is your plan for dealing with disappearing mentors?====

==== What steps will you take to encourage students to interact with your project's community before, during and after the program?====

Wesnoth has a particularly healthy community, both for developers and for players.

Our general policy regarding new coders has always been "two patch... you're in" In other word, anybody that is able to get two non-trivial patches applied is offered commit right.

We have a developer responsible for applying patches and guiding new developers into our community. This is a well known and effective process we plan to apply to students, directing them to our [[EasyCoding]] pages (these project are usually a couple of hours long and has been chosen to provide easy access to code)

Usually, patches go back and forth a couple of time, to make sure that all secondary things are in place (indenting, coding style, modified makefiles etc.) The idea is that coder education should take place before the coder gets commit rights, but that getting new coder in is one of the most important things to maintain our project alive.

If the student is a little proactive and ready to join IRC, all the developers are usually very welcoming, and good at directing newcomers to quickly give useful results.

'''to be completed'''

==== What will you do to ensure that your accepted students stick with the project after GSoC concludes?====

=== People to bug on IRC, possible mentors ===
Everybody feel free to edit/correct his entry!

==== Dave alias Sirp ====

Sirp started Wesnoth and is our lead developper. He is currently our C++ expert and is also the one that is working on the new Formula AI. Any questions regarding the formula AI should be directed to him.

==== Mordante ====
Many of the possible projects do at least partly go into the area of code where he knows most of. Plus many of the possible projects currently listed on the ideas page do require GUI parts to work, too. So if Mordante wants to tackle a rewrite of large parts of this, he will be our expert there as well as he already is our expert for the terrain engine (cf. editor / scenario editor works).

==== Elias Pscherning (elias) ====
He has written the original version of campgen and as such will know a lot about what is needed to to make such an editor work correctly. The work on a scenario editor might be based upon campgen and as such make his knowledge really helpful.

==== Karol Nowak (grzywacz) ====
Last year he was participating at GSoC as a student, so he knows at least this side of the medal. Beside this he is our top expert regarding embedded devices support since he is actively working on the gp2x support.

==== boucman ====
As our "patch monkey" he has valuable knowledge in comments and critics for patches of every kind. Beside this he knows many areas of the game due to working on applying patches. He is particularly used to answer question from new coders, and doesn't mind explaining trivial stuff.

If you want to have a feeling of the developer spirit, it is recommended to go to our [[EasyCoding]] page.

==== Soliton ====
He does know our mp server setup best. Beside this he already has done a lot of work on the mp server himself, too. So he probably has most knowledge about it and due to being one of our mp-developers might provide important help from the perspective of mp-community and what is needed there.

==== zookeeper or Mythological or Rhuvaen ====
As our leading WML expert it would be good to have him in the list when it comes to WML specific problems. That is for work on the scenario editor he probably knows best what should be implemented in it and what is a usable way for things.

==== YogiHH or Piotr Cychowski (cycholka) ====
Since they are the two developers who know most about building under Windows, they will probably be really helpful. Either if the student comes from the Windows side, or to help test resulting work to make sure that it does work on Windows and, for the case that it does not, to show them where problems are.

SummerOfCodeIdeas

2008-02-27T23:11:51Z

Rhuvaen: nick spelled wrong :o

== Ideas for Google Summer of Code projects ==

This is a compilation of ideas from ML. Needs to be refined (more detailed description, deliverables, workload estimation?):

== List of Ideas for the Project ==

=== Writing an AI based on the formula AI ===

Wesnoth has always had a simple C++ based AI. David (our lead developer) has been working on a simple language to write AI in Wesnoth ''link to formula AI page here''

The Wesnoth AI is used as an opponent in most campaigns, and as such is an important piece of code for the Wesnoth project. Unfortunately it is also one of the most neglected piece of code and a place where a lot of research and work could be done

==== General description ====

The aim of this project is to develop a new AI that would replace the original C++ AI. The main criterias we would want for this new AI are

* ''Plugability :'' It should be trivial for any content maker to change the behavior of the AI in specific case. The exact cases are still to be defined but should typically include
** hardwiring the first few turns of the AI
** changing the recruitment pattern
** completely controlling a given unit (scenario unit)
** taking control then giving back control of a given unit
* ''tunability :'' It should be easy for a scenario author to specify the general behaviour of the enemy on a given scenario (aggressiveness, intrepidity...)
* ''specific behaviours :'' there are some typical behaviours that are not smart to win the scenario but are needed, such as guarding a given unit, a given position, wandering aimlessly, attacking randomly, always fleeing. The AI should implement such behaviours, and allow easy addition of new behaviours

==== Required knowledge and talent ====

* ''A minimal knowledge of C++ is required, a good knowledge of C++ is desired :'' The formula AI framework is a work in progress and chances are high that some changes in the wesnoth code base will be needed. The wesnoth developer community is used to handle people that are familiar with coding but not C++, however the Formula AI framework uses advanced C++ features and a good knowledge of the language would avoid a major hurdle when plugging in new entries or functionalities for the AI
* ''Good social interaction with a large player community :'' A preliminary phase to coding any AI is to know the strategies and game pattern used by human players. This requires huge interaction with the player community. Our Gameplay Developers are open and can give some good starting points, but a big game experience and good interaction with the player community will greatly help in the study of the design

==== Milestones and deliverables ====

It is hard to give milestones at this point, but here are some ideas of what could be done

* ''AI design description, and basic function library :'' This first deliverable aims to conclude the '''study and analysis''' part of the project : becoming familiar with the formula language, study of multiplayer strategies and of the need of scenario writers with regard to AI. We would like to have a description of the code structure of the AI, some basis of the play strategies it would use and how external scenario writers could configure it for the particular behaviour they need
* ''Main AI delivery :'' This milestone's aim is to deliver a working AI implementing the strategies described in the first phase. It would not have to systematically beat the standard C++ AI at this point, but should be able to play the game correctly (recruit, early deployment on villages, grouping units to attack, holding its ground, protecting weak/important units). Moreover most plug-in entries should be available and a test-case for these entries should be provided.
* ''Fine tunning and behaviour library :'' The third phase would validate the actual strategy of the AI. The AI should consistently beat the default C++ AI, and do fairly well against an average human player. At that stage a library of scenario behaviours should also be delivered. The AI does not need to be as efficient with all scenario tweaking, but should act correctly with regard to the particular behaviour desired.

=== Extending the Multiplayer server ===

When the development team met at FOSDEM, we had our multiplayer community, though it is strong and healthy, had its growth restrained by the interface of the multiplayer lobby.

==== General Description ====
The general idea of this project would be
* To study the current lobby,
* To present some ideas of evolutions both in interface and functionalities of our multiplayer interface to allow it to scale to a much larger community
* To present some well constructed thought on our MP community and how that interface would develop it
* Of course to implement those changes :)

Some ideas that we had (but that are in no way mandatory)
* Having a simple way to register and authenticate nicknames, similar to what IRC offers. The point is not to have cryptographically safe logins, but to have something simple that gets the job done
* Having a simple room system? again inspired on IRC
* Having some way to find the type of games you are interested in.
** game type
** number of free slots/players
** any other criteria you might find interesting

Other ideas we are not convinced are good, but that are certainly worth studying (especially how the communities based around these concepts are different from ours)
* ranking players
* guilds
* official tournaments
* titles for players
* metaservers

The scalability of the project, both in term of number of players, and in term of the possibility for players and developers to extend the concept will be a valued criteria

Administration/moderation problems and techniques should also be studied

interaction with the Add-On server/forum might be an interesting field to expand to

==== Required knowledge and talent ====

* A fair amount of experience on C++ is required. Wesnoth uses some advanced C++ features and is heavily based on BOOST and STL. We can train you in some of the libraries used, but learning all of them would be a big hurdle
* Various experience with multiplayer games, in order to have a good idea of what multiplayer lobbies of other game look like, and (more importantly) a good idea of the social behaviours of multiple MP communities, how teams are formed in games and things like that

==== Milestones and deliverables ====

* A first milestone would be a presentation summarizing the different studies, and the proposed interface. preliminary informal stages would probably be desirable, to make sure the proposed idea is already a consensus within devs
** Study of other MP game-matching interfaces and functionalities
** Study of other MP communities
** Study of other MP moderation practices
** Study of the Wesnoth MP community, including needs, various opinons from different developers and players
* A second milestone would be the main code delivery. Code should be functional for it will be delivered in the next Wesnoth development release

=== Other ideas to be fleshed out ===
* Working on the GUI engine (needs to be defined more precisely)
* Rewrite of the campaign (add-on) server
* The editor can use quite a revamp
* A good scenario editor. We have campgen but it hasn't been updated for a while.

== Other info to provide for GSoC ==
==== Describe your organization. ====

==== Why is your organization applying to participate in GSoC 2008? What do you hope to gain by participating?====

Most of our developers have interesting areas in which they work. Though they are efficient in their areas, there are areas that are interesting but have a high barrier of entry.

By having a student dedicated to any of these areas, we could quickly get someone up to date with that particular area, efficient, and responsible of this area.

Basically, by getting new people in and making them actively responsible for an area of code we hope to kickstart some areas of the project that have lagged behind

==== Did your organization participate in past GSoCs? If so, please summarize your involvement and the successes and challenges of your participation.====
This is the first time the Wesnoth projects applies to Google SoC

==== If your organization has not previously participated in GSoC, have you applied in the past? If so, for what year(s)?====

This is the first time the Wesnoth projects applies to Google SoC

==== Who will your organization administrator be? Please include Google Account information.====
Nils Kneuper aka Ivanovic

crazy.ivanovic |ATTT| googlemail.com

==== What license(s) does your project use?====
Our project is entirely GPL.

All code is GPL.

All art is GPL, 99% was made for the project, everything was taken from content that was checked to be GPL.

==== What is the URL for your ideas page?====
Our main summer of code pages is located at http://www.wesnoth.org/wiki/SummerOfCodeIdeas

This page contains various coding ideas and the thought the development team has already given them.

It also contains a list of the developers that are the most active on IRC and their domain of interest.

==== What is the main development mailing list or forum for your organization?====
Most development work takes place on "wesnoth-dev |ATTT| gna.org". Beside this some work happens at http://www.wesnoth.org/forum/.

==== What is the main IRC channel for your organization?====

All our IRC channels are on the ''freenode'' network

* ''#wesnoth-dev'' is the main development channel, where most discussion takes place
* ''#wesnoth'' is a generic channel for the community
* ''#wesnoth-mp'' is a separate channel for multiplayer games and balancing

==== Does your organization have an application template you would like to see students use? If so, please provide it now.====
We plan mainly to meet potential students through our IRC channel, but the following questions are wesnoth-specific and are worth pondering for any student, even if we don't need a formal answer

* What type of gamer are you? What type of games? What type of opponent? Are you more interested in story or gameplay ?
* Are you good at interacting with other players ? Our developer community is quite nice, but the player community can be a bit rough.
* Do you give constructive advices? Do you receive advice well? Are you good at sorting useful criticism from useless ones?

''''to be completed''''

==== Who will be your backup organization administrator? Please include Google Account information.====

Jeremy Rosen alias Boucman

boucman2|ATTT|gmail.com

==== Who will your mentors be? Please include Google Account information.====

==== What criteria did you use to select these individuals as mentors? Please be as specific as possible.====

==== What is your plan for dealing with disappearing students?====

==== What is your plan for dealing with disappearing mentors?====

==== What steps will you take to encourage students to interact with your project's community before, during and after the program?====

Wesnoth has a particularly healthy community, both for developers and for players.

Our general policy regarding new coders has always been "two patch... you're in" In other word, anybody that is able to get two non-trivial patches applied is offered commit right.

We have a developer responsible for applying patches and guiding new developers into our community. This is a well known and effective process we plan to apply to students, directing them to our [[EasyCoding]] pages (these project are usually a couple of hours long and has been chosen to provide easy access to code)

Usually, patches go back and forth a couple of time, to make sure that all secondary things are in place (indenting, coding style, modified makefiles etc.) The idea is that coder education should take place before the coder gets commit rights, but that getting new coder in is one of the most important things to maintain our project alive.

If the student is a little proactive and ready to join IRC, all the developers are usually very welcoming, and good at directing newcomers to quickly give useful results.

'''to be completed'''

==== What will you do to ensure that your accepted students stick with the project after GSoC concludes?====

=== People to bug on IRC, possible mentors ===
Everybody feel free to edit/correct his entry!

==== Dave alias Sirp ====

Sirp started Wesnoth and is our lead developper. He is currently our C++ expert and is also the one that is working on the new Formula AI. Any questions regarding the formula AI should be directed to him.

==== Mordante ====
Many of the possible projects do at least partly go into the area of code where he knows most of. Plus many of the possible projects currently listed on the ideas page do require GUI parts to work, too. So if Mordante wants to tackle a rewrite of large parts of this, he will be our expert there as well as he already is our expert for the terrain engine (cf. editor / scenario editor works).

==== Elias Pscherning (elias) ====
He has written the original version of campgen and as such will know a lot about what is needed to to make such an editor work correctly. The work on a scenario editor might be based upon campgen and as such make his knowledge really helpful.

==== Karol Nowak (grzywacz) ====
Last year he was participating at GSoC as a student, so he knows at least this side of the medal. Beside this he is our top expert regarding embedded devices support since he is actively working on the gp2x support.

==== boucman ====
As our "patch monkey" he has valuable knowledge in comments and critics for patches of every kind. Beside this he knows many areas of the game due to working on applying patches. He is particularly used to answer question from new coders, and doesn't mind explaining trivial stuff.

If you want to have a feeling of the developer spirit, it is recommended to go to our [[EasyCoding]] page.

==== Soliton ====
He does know our mp server setup best. Beside this he already has done a lot of work on the mp server himself, too. So he probably has most knowledge about it and due to being one of our mp-developers might provide important help from the perspective of mp-community and what is needed there.

==== zookeeper or Mythological or Rhuvaen ====
As our leading WML expert it would be good to have him in the list when it comes to WML specific problems. That is for work on the scenario editor he probably knows best what should be implemented in it and what is a usable way for things.

==== YogiHH or Piotr Cychowski (cycholka) ====
Since they are the two developers who know most about building under Windows, they will probably be really helpful. Either if the student comes from the Windows side, or to help test resulting work to make sure that it does work on Windows and, for the case that it does not, to show them where problems are.

TerrainCodesWML

2008-02-15T13:54:38Z

Rhuvaen: /* Terrain Table */

{{WML Tags}}

Note: the old (1.2) terrain system is no longer documented here. If you have 1.2 maps you will need to convert them using [[Maintenance_tools|wmllint]].

== Terrain strings ==

The following rules hold for terrain strings. Note most of these rules are not validated since it would slow down Wesnoth; not following these rules might break Wesnoth.

* terrain strings are between 2 and 4 characters
* terrain strings start with a capital letter and the following letters are lower case
* terrain strings can only contain letters, the symbols /|\ which are meant for directional items like bridges and the symbol ^
* the underscore is used for internal terrains
* the star '*' can be used for wildcards in some parts
* the symbol ^ usually points out that a terrain is created with layers, for example Gs^Fp means Forest(Fp) overlayer on Savanna(Gs).

Starting positions are defined by a number followed by 1 space and then the terrain string; this means that a starting position is no longer automatically a keep.

The letters Y,y,Z,z are reserved for UMC so any string containing any of these letters is a custom terrain. Other undefined terrain strings are reserved for future expansion within Wesnoth.

=== Terrain Table ===
This is a list of the terrains, the strings used for them in the new map format, the letters used for them in the old map format, their id and the terrains they take their stats from.

<table border="1"><tr>
<th>String</th>
<th>Name</th>
<th>Stats from</th>
</tr>
<tr>
<td>_off^_usr</td>
<td>None (used in map borders)</td>
<td></td>
</tr>
<tr>
<td>_s</td>
<td>Shroud (use in mask only)</td>
<td></td>
</tr>
<tr>
<td>_f</td>
<td>Fog (use in mask only)</td>
<td></td>
</tr>
<tr>
<td>Ai</td>
<td>Ice</td>
<td>Snow</td>
</tr>
<tr>
<td>Aa</td>
<td>Snow</td>
<td></td>
</tr>
<tr>
<td>Ww^Bw|</td>
<td>Bridge</td>
<td>Grassland,Shallow Water</td>
</tr>
<tr>
<td>Ww^Bw/</td>
<td>Bridge</td>
<td>Grassland,Shallow Water</td>
</tr>
<tr>
<td>Ww^Bw\</td>
<td>Bridge</td>
<td>Grassland,Shallow Water</td>
</tr>
<tr>
<td>Wo^Bw|</td>
<td>Bridge</td>
<td>Grassland,Deep Water</td>
</tr>
<tr>
<td>Wo^Bw/</td>
<td>Bridge</td>
<td>Grassland,Deep Water</td>
</tr>
<tr>
<td>Wo^Bw\</td>
<td>Bridge</td>
<td>Grassland,Deep Water</td>
</tr>
<tr>
<td>Ss^Bw|</td>
<td>Bridge</td>
<td>Grassland,Swamp</td>
</tr>
<tr>
<td>Ss^Bw/</td>
<td>Bridge</td>
<td>Grassland,Swamp</td>
</tr>
<tr>
<td>Ss^Bw\</td>
<td>Bridge</td>
<td>Grassland,Swamp</td>
</tr>
<tr>
<td>Ce</td>
<td>Encampment</td>
<td>Castle</td>
</tr>
<tr>
<td>Ch</td>
<td>Castle</td>
<td></td>
</tr>
<tr>
<td>Cv</td>
<td>Elven Castle</td>
<td>Castle</td>
</tr>
<tr>
<td>Cud</td>
<td>Dwarven Castle</td>
<td>Castle</td>
</tr>
<tr>
<td>Chr</td>
<td>Ruin</td>
<td>Castle</td>
</tr>
<tr>
<td>Chw</td>
<td>Sunken Ruin</td>
<td>Castle,Shallow Water</td>
</tr>
<tr>
<td>Chs</td>
<td>Swamp Ruin</td>
<td>Castle,Swamp</td>
</tr>
<tr>
<td>Ke</td>
<td>Encampment keep</td>
<td>Castle</td>
</tr>
<tr>
<td>Kh</td>
<td>Keep</td>
<td>Castle</td>
</tr>
<tr>
<td>Kv</td>
<td>Elven Keep</td>
<td>Castle</td>
</tr>
<tr>
<td>Kud</td>
<td>Dwarven keep</td>
<td>Castle</td>
</tr>
<tr>
<td>Khr</td>
<td>Ruined keep</td>
<td>Castle</td>
</tr>
<tr>
<td>Khw</td>
<td>Sunken keep</td>
<td>Castle,Shallow Water</td>
</tr>
<tr>
<td>Khs</td>
<td>Swamp keep</td>
<td>Castle,Swamp</td>
</tr>
<tr>
<td>Dd^Dc</td>
<td>Crater</td>
<td>Sand</td>
</tr>
<tr>
<td>Dd</td>
<td>Desert</td>
<td>Sand</td>
</tr>
<tr>
<td>Dd^Dr</td>
<td>Rubble</td>
<td>Hills</td>
</tr>
<tr>
<td>Ds</td>
<td>Sand</td>
<td></td>
</tr>
<tr>
<td>Dd^Do</td>
<td>Oasis</td>
<td>Sand</td>
</tr>
<tr>
<td>Aa^Fpa</td>
<td>Snow Forest</td>
<td>Snow,Forest</td>
</tr>
<tr>
<td>Gg^Fet</td>
<td>Great Tree</td>
<td>Forest</td>
</tr>
<tr>
<td>Gs^Fp</td>
<td>Forest</td>
<td></td>
</tr>
<tr>
<td>Gs^Ft</td>
<td>Tropical Forest</td>
<td>Forest</td>
</tr>
<tr>
<td>Gg</td>
<td>Grassland</td>
<td></td>
</tr>
<tr>
<td>Ggf</td>
<td>Grassland</td>
<td>Grassland</td>
</tr>
<tr>
<td>Gs</td>
<td>Savanna</td>
<td>Grassland</td>
</tr>
<tr>
<td>Ha</td>
<td>Snow Hills</td>
<td>Snow,Hills</td>
</tr>
<tr>
<td>Hd</td>
<td>Dunes</td>
<td>Sand,Hills</td>
</tr>
<tr>
<td>Hh</td>
<td>Hills</td>
<td></td>
</tr>
<tr>
<td>Md</td>
<td>Mountains</td>
<td>Mountains</td>
</tr>
<tr>
<td>Mm</td>
<td>Mountains</td>
<td></td>
</tr>
<tr>
<td>Qxu</td>
<td>Chasm</td>
<td></td>
</tr>
<tr>
<td>Ql</td>
<td>Lava Chasm</td>
<td>Chasm</td>
</tr>
<tr>
<td>Qlf</td>
<td>Lava (flat)</td>
<td>Chasm</td>
</tr>
<tr>
<td>Rd</td>
<td>Desert road</td>
<td>Grassland</td>
</tr>
<tr>
<td>Re</td>
<td>Dirt</td>
<td>Grassland</td>
</tr>
<tr>
<td>Rr</td>
<td>Road</td>
<td>Grassland</td>
</tr>
<tr>
<td>Rp</td>
<td>Road (Elven Path)</td>
<td>Grassland</td>
</tr>
<tr>
<td>Re^Gvs</td>
<td>Farmland</td>
<td>Grassland</td>
</tr>
<tr>
<td>Gg^Wm</td>
<td>Windmill</td>
<td>Grassland</td>
</tr>
<tr>
<td>Ss</td>
<td>Swamp</td>
<td></td>
</tr>
<tr>
<td>Uu</td>
<td>Cave</td>
<td></td>
</tr>
<tr>
<td>Uu^Ii</td>
<td>Cave Lit</td>
<td>Cave</td>
</tr>
<tr>
<td>Uu^Uf</td>
<td>Mushroom Grove</td>
<td></td>
</tr>
<tr>
<td>Re^Uf</td>
<td>Mushroom Grove</td>
<td>Mushroom Grove</td>
</tr>
<tr>
<td>Uh</td>
<td>Rockbound Cave</td>
<td>Cave,Hills</td>
</tr>
<tr>
<td>Uh^Ii</td>
<td>Rockbound Cave Lit</td>
<td>Cave,Hills</td>
</tr>
<tr>
<td>Dd^Vda</td>
<td>Village</td>
<td>Village,Sand</td>
</tr>
<tr>
<td>Dd^Vdt</td>
<td>Village</td>
<td>Village,Sand</td>
</tr>
<tr>
<td>Aa^Vea</td>
<td>Village</td>
<td>Village</td>
</tr>
<tr>
<td>Gg^Ve</td>
<td>Village</td>
<td>Village</td>
</tr>
<tr>
<td>Aa^Vha</td>
<td>Village</td>
<td>Village</td>
</tr>
<tr>
<td>Gg^Vh</td>
<td>Village</td>
<td></td>
</tr>
<tr>
<td>Hh^Vhh</td>
<td>Village</td>
<td>Village,Hills</td>
</tr>
<tr>
<td>Ha^Vhha</td>
<td>Village</td>
<td>Village,Hills</td>
</tr>
<tr>
<td>Mm^Vhh</td>
<td>Village</td>
<td>Village,Mountains</td>
</tr>
<tr>
<td>Gs^Vht</td>
<td>Village</td>
<td>Village</td>
</tr>
<tr>
<td>Uu^Vu</td>
<td>Village</td>
<td>Village,Cave</td>
</tr>
<tr>
<td>Uu^Vud</td>
<td>Village</td>
<td>Village,Cave</td>
</tr>
<tr>
<td>Ww^Vm</td>
<td>Village</td>
<td>Shallow Water</td>
</tr>
<tr>
<td>Ss^Vhs</td>
<td>Village</td>
<td>Village,Swamp</td>
</tr>
<tr>
<td>Ss^Vm</td>
<td>Village</td>
<td>Swamp</td>
</tr>
<tr>
<td>Wo</td>
<td>Deep Water</td>
<td></td>
</tr>
<tr>
<td>Ww</td>
<td>Shallow Water</td>
<td></td>
</tr>
<tr>
<td>Wwf</td>
<td>River Ford</td>
<td>Grassland,Shallow Water</td>
</tr>
<tr>
<td>Mm^Xm</td>
<td>Impassable Mountains</td>
<td>Cave Wall</td>
</tr>
<tr>
<td>Md^Xm</td>
<td>Impassable Desert Mountains</td>
<td>Cave Wall</td>
</tr>
<tr>
<td>Xu</td>
<td>Cave Wall</td>
<td></td>
</tr>
<tr>
<td>Xv</td>
<td>Void</td>
<td>Cave Wall</td>
</tr>
</table>

== Adding terrains ==
When adding terrains make sure the following files are also checked:

data/faction/* contains favorite positions for the different factions, this is only used for the random map generator at the moment so it is not very important.

data/abilities.cfg contains the definition of ''submerge'' and ''ambush'' so depending on the change these need to be updated.

data/utils/utils.cfg contains the macro STARTING_VILLAGES which contains a list of village strings. This list doesn't support wildcards (yet).

== See Also ==
* [[TerrainWML]]
* [[ReferenceWML]]

[[Category: WML Reference]]

TerrainCodesWML

2008-02-15T13:48:00Z

Rhuvaen: added terrain Rp

{{WML Tags}}

Note: the old (1.2) terrain system is no longer documented here. If you have 1.2 maps you will need to convert them using [[Maintenance_tools|wmllint]].

== Terrain strings ==

The following rules hold for terrain strings. Note most of these rules are not validated since it would slow down Wesnoth; not following these rules might break Wesnoth.

* terrain strings are between 2 and 4 characters
* terrain strings start with a capital letter and the following letters are lower case
* terrain strings can only contain letters, the symbols /|\ which are meant for directional items like bridges and the symbol ^
* the underscore is used for internal terrains
* the star '*' can be used for wildcards in some parts
* the symbol ^ usually points out that a terrain is created with layers, for example Gs^Fp means Forest(Fp) overlayer on Savanna(Gs).

Starting positions are defined by a number followed by 1 space and then the terrain string; this means that a starting position is no longer automatically a keep.

The letters Y,y,Z,z are reserved for UMC so any string containing any of these letters is a custom terrain. Other undefined terrain strings are reserved for future expansion within Wesnoth.

=== Terrain Table ===
This is a list of the terrains, the strings used for them in the new map format, the letters used for them in the old map format, their id and the terrains they take their stats from.

<table border="1"><tr>
<th>String</th>
<th>Name</th>
<th>Stats from</th>
</tr>
<tr>
<td>_off^_usr</td>
<td>None</td>
<td></td>
</tr>
<tr>
<td>_s</td>
<td>Shroud (use in mask only)</td>
<td></td>
</tr>
<tr>
<td>_f</td>
<td>Fog (use in mask only)</td>
<td></td>
</tr>
<tr>
<td>Ai</td>
<td>Ice</td>
<td>Snow</td>
</tr>
<tr>
<td>Aa</td>
<td>Snow</td>
<td></td>
</tr>
<tr>
<td>Ww^Bw|</td>
<td>Bridge</td>
<td>Grassland,Shallow Water</td>
</tr>
<tr>
<td>Ww^Bw/</td>
<td>Bridge</td>
<td>Grassland,Shallow Water</td>
</tr>
<tr>
<td>Ww^Bw\</td>
<td>Bridge</td>
<td>Grassland,Shallow Water</td>
</tr>
<tr>
<td>Wo^Bw|</td>
<td>Bridge</td>
<td>Grassland,Deep Water</td>
</tr>
<tr>
<td>Wo^Bw/</td>
<td>Bridge</td>
<td>Grassland,Deep Water</td>
</tr>
<tr>
<td>Wo^Bw\</td>
<td>Bridge</td>
<td>Grassland,Deep Water</td>
</tr>
<tr>
<td>Ss^Bw|</td>
<td>Bridge</td>
<td>Grassland,Swamp</td>
</tr>
<tr>
<td>Ss^Bw/</td>
<td>Bridge</td>
<td>Grassland,Swamp</td>
</tr>
<tr>
<td>Ss^Bw\</td>
<td>Bridge</td>
<td>Grassland,Swamp</td>
</tr>
<tr>
<td>Ce</td>
<td>Encampment</td>
<td>Castle</td>
</tr>
<tr>
<td>Ch</td>
<td>Castle</td>
<td></td>
</tr>
<tr>
<td>Cv</td>
<td>Elven Castle</td>
<td>Castle</td>
</tr>
<tr>
<td>Cud</td>
<td>Dwarven Castle</td>
<td>Castle</td>
</tr>
<tr>
<td>Chr</td>
<td>Ruin</td>
<td>Castle</td>
</tr>
<tr>
<td>Chw</td>
<td>Sunken Ruin</td>
<td>Castle,Shallow Water</td>
</tr>
<tr>
<td>Chs</td>
<td>Swamp Ruin</td>
<td>Castle,Swamp</td>
</tr>
<tr>
<td>Ke</td>
<td>Encampment keep</td>
<td>Castle</td>
</tr>
<tr>
<td>Kh</td>
<td>Keep</td>
<td>Castle</td>
</tr>
<tr>
<td>Kv</td>
<td>Elven Keep</td>
<td>Castle</td>
</tr>
<tr>
<td>Kud</td>
<td>Dwarven keep</td>
<td>Castle</td>
</tr>
<tr>
<td>Khr</td>
<td>Ruined keep</td>
<td>Castle</td>
</tr>
<tr>
<td>Khw</td>
<td>Sunken keep</td>
<td>Castle,Shallow Water</td>
</tr>
<tr>
<td>Khs</td>
<td>Swamp keep</td>
<td>Castle,Swamp</td>
</tr>
<tr>
<td>Dd^Dc</td>
<td>Crater</td>
<td>Sand</td>
</tr>
<tr>
<td>Dd</td>
<td>Desert</td>
<td>Sand</td>
</tr>
<tr>
<td>Dd^Dr</td>
<td>Rubble</td>
<td>Hills</td>
</tr>
<tr>
<td>Ds</td>
<td>Sand</td>
<td></td>
</tr>
<tr>
<td>Dd^Do</td>
<td>Oasis</td>
<td>Sand</td>
</tr>
<tr>
<td>Aa^Fpa</td>
<td>Snow Forest</td>
<td>Snow,Forest</td>
</tr>
<tr>
<td>Gg^Fet</td>
<td>Great Tree</td>
<td>Forest</td>
</tr>
<tr>
<td>Gs^Fp</td>
<td>Forest</td>
<td></td>
</tr>
<tr>
<td>Gs^Ft</td>
<td>Tropical Forest</td>
<td>Forest</td>
</tr>
<tr>
<td>Gg</td>
<td>Grassland</td>
<td></td>
</tr>
<tr>
<td>Ggf</td>
<td>Grassland</td>
<td>Grassland</td>
</tr>
<tr>
<td>Gs</td>
<td>Savanna</td>
<td>Grassland</td>
</tr>
<tr>
<td>Ha</td>
<td>Snow Hills</td>
<td>Snow,Hills</td>
</tr>
<tr>
<td>Hd</td>
<td>Dunes</td>
<td>Sand,Hills</td>
</tr>
<tr>
<td>Hh</td>
<td>Hills</td>
<td></td>
</tr>
<tr>
<td>Md</td>
<td>Mountains</td>
<td>Mountains</td>
</tr>
<tr>
<td>Mm</td>
<td>Mountains</td>
<td></td>
</tr>
<tr>
<td>Qxu</td>
<td>Chasm</td>
<td></td>
</tr>
<tr>
<td>Ql</td>
<td>Lava Chasm</td>
<td>Chasm</td>
</tr>
<tr>
<td>Qlf</td>
<td>Lava (flat)</td>
<td>Chasm</td>
</tr>
<tr>
<td>Rd</td>
<td>Desert road</td>
<td>Grassland</td>
</tr>
<tr>
<td>Re</td>
<td>Dirt</td>
<td>Grassland</td>
</tr>
<tr>
<td>Rr</td>
<td>Road</td>
<td>Grassland</td>
</tr>
<tr>
<td>Rp</td>
<td>Road (Elven Path)</td>
<td>Grassland</td>
</tr>
<tr>
<td>Re^Gvs</td>
<td>Farmland</td>
<td>Grassland</td>
</tr>
<tr>
<td>Gg^Wm</td>
<td>Windmill</td>
<td>Grassland</td>
</tr>
<tr>
<td>Ss</td>
<td>Swamp</td>
<td></td>
</tr>
<tr>
<td>Uu</td>
<td>Cave</td>
<td></td>
</tr>
<tr>
<td>Uu^Ii</td>
<td>Cave Lit</td>
<td>Cave</td>
</tr>
<tr>
<td>Uu^Uf</td>
<td>Mushroom Grove</td>
<td></td>
</tr>
<tr>
<td>Re^Uf</td>
<td>Mushroom Grove</td>
<td>Mushroom Grove</td>
</tr>
<tr>
<td>Uh</td>
<td>Rockbound Cave</td>
<td>Cave,Hills</td>
</tr>
<tr>
<td>Uh^Ii</td>
<td>Rockbound Cave Lit</td>
<td>Cave,Hills</td>
</tr>
<tr>
<td>Dd^Vda</td>
<td>Village</td>
<td>Village,Sand</td>
</tr>
<tr>
<td>Dd^Vdt</td>
<td>Village</td>
<td>Village,Sand</td>
</tr>
<tr>
<td>Aa^Vea</td>
<td>Village</td>
<td>Village</td>
</tr>
<tr>
<td>Gg^Ve</td>
<td>Village</td>
<td>Village</td>
</tr>
<tr>
<td>Aa^Vha</td>
<td>Village</td>
<td>Village</td>
</tr>
<tr>
<td>Gg^Vh</td>
<td>Village</td>
<td></td>
</tr>
<tr>
<td>Hh^Vhh</td>
<td>Village</td>
<td>Village,Hills</td>
</tr>
<tr>
<td>Ha^Vhha</td>
<td>Village</td>
<td>Village,Hills</td>
</tr>
<tr>
<td>Mm^Vhh</td>
<td>Village</td>
<td>Village,Mountains</td>
</tr>
<tr>
<td>Gs^Vht</td>
<td>Village</td>
<td>Village</td>
</tr>
<tr>
<td>Uu^Vu</td>
<td>Village</td>
<td>Village,Cave</td>
</tr>
<tr>
<td>Uu^Vud</td>
<td>Village</td>
<td>Village,Cave</td>
</tr>
<tr>
<td>Ww^Vm</td>
<td>Village</td>
<td>Shallow Water</td>
</tr>
<tr>
<td>Ss^Vhs</td>
<td>Village</td>
<td>Village,Swamp</td>
</tr>
<tr>
<td>Ss^Vm</td>
<td>Village</td>
<td>Swamp</td>
</tr>
<tr>
<td>Wo</td>
<td>Deep Water</td>
<td></td>
</tr>
<tr>
<td>Ww</td>
<td>Shallow Water</td>
<td></td>
</tr>
<tr>
<td>Wwf</td>
<td>River Ford</td>
<td>Grassland,Shallow Water</td>
</tr>
<tr>
<td>Mm^Xm</td>
<td>Impassable Mountains</td>
<td>Cave Wall</td>
</tr>
<tr>
<td>Md^Xm</td>
<td>Impassable Desert Mountains</td>
<td>Cave Wall</td>
</tr>
<tr>
<td>Xu</td>
<td>Cave Wall</td>
<td></td>
</tr>
<tr>
<td>Xv</td>
<td>Void</td>
<td>Cave Wall</td>
</tr>
</table>

== Adding terrains ==
When adding terrains make sure the following files are also checked:

data/faction/* contains favorite positions for the different factions, this is only used for the random map generator at the moment so it is not very important.

data/abilities.cfg contains the definition of ''submerge'' and ''ambush'' so depending on the change these need to be updated.

data/utils/utils.cfg contains the macro STARTING_VILLAGES which contains a list of village strings. This list doesn't support wildcards (yet).

== See Also ==
* [[TerrainWML]]
* [[ReferenceWML]]

[[Category: WML Reference]]

TerrainCodesWML

2008-01-31T10:05:06Z

Rhuvaen: updated lava terrain info

{{WML Tags}}

Note: the old (1.2) terrain system is no longer documented here. If you have 1.2 maps you will need to convert them using [[Maintenance_tools|wmllint]].

== Terrain strings ==

The following rules hold for terrain strings. Note most of these rules are not validated since it would slow down Wesnoth; not following these rules might break Wesnoth.

* terrain strings are between 2 and 4 characters
* terrain strings start with a capital letter and the following letters are lower case
* terrain strings can only contain letters, the symbols /|\ which are meant for directional items like bridges and the symbol ^
* the underscore is used for internal terrains
* the star '*' can be used for wildcards in some parts
* the symbol ^ usually points out that a terrain is created with layers, for example Gs^Fp means Forest(Fp) overlayer on Savanna(Gs).

Starting positions are defined by a number followed by 1 space and then the terrain string; this means that a starting position is no longer automatically a keep.

The letters Y,y,Z,z are reserved for UMC so any string containing any of these letters is a custom terrain. Other undefined terrain strings are reserved for future expansion within Wesnoth.

=== Terrain Table ===
This is a list of the terrains, the strings used for them in the new map format, the letters used for them in the old map format, their id and the terrains they take their stats from.

<table border="1"><tr>
<th>String</th>
<th>Name</th>
<th>Stats from</th>
</tr>
<tr>
<td>_off^_usr</td>
<td>None</td>
<td></td>
</tr>
<tr>
<td>_s</td>
<td>Shroud (use in mask only)</td>
<td></td>
</tr>
<tr>
<td>_f</td>
<td>Fog (use in mask only)</td>
<td></td>
</tr>
<tr>
<td>Ai</td>
<td>Ice</td>
<td>Snow</td>
</tr>
<tr>
<td>Aa</td>
<td>Snow</td>
<td></td>
</tr>
<tr>
<td>Ww^Bw|</td>
<td>Bridge</td>
<td>Grassland,Shallow Water</td>
</tr>
<tr>
<td>Ww^Bw/</td>
<td>Bridge</td>
<td>Grassland,Shallow Water</td>
</tr>
<tr>
<td>Ww^Bw\</td>
<td>Bridge</td>
<td>Grassland,Shallow Water</td>
</tr>
<tr>
<td>Wo^Bw|</td>
<td>Bridge</td>
<td>Grassland,Deep Water</td>
</tr>
<tr>
<td>Wo^Bw/</td>
<td>Bridge</td>
<td>Grassland,Deep Water</td>
</tr>
<tr>
<td>Wo^Bw\</td>
<td>Bridge</td>
<td>Grassland,Deep Water</td>
</tr>
<tr>
<td>Ss^Bw|</td>
<td>Bridge</td>
<td>Grassland,Swamp</td>
</tr>
<tr>
<td>Ss^Bw/</td>
<td>Bridge</td>
<td>Grassland,Swamp</td>
</tr>
<tr>
<td>Ss^Bw\</td>
<td>Bridge</td>
<td>Grassland,Swamp</td>
</tr>
<tr>
<td>Ce</td>
<td>Encampment</td>
<td>Castle</td>
</tr>
<tr>
<td>Ch</td>
<td>Castle</td>
<td></td>
</tr>
<tr>
<td>Cv</td>
<td>Elven Castle</td>
<td>Castle</td>
</tr>
<tr>
<td>Cud</td>
<td>Dwarven Castle</td>
<td>Castle</td>
</tr>
<tr>
<td>Chr</td>
<td>Ruin</td>
<td>Castle</td>
</tr>
<tr>
<td>Chw</td>
<td>Sunken Ruin</td>
<td>Castle,Shallow Water</td>
</tr>
<tr>
<td>Chs</td>
<td>Swamp Ruin</td>
<td>Castle,Swamp</td>
</tr>
<tr>
<td>Ke</td>
<td>Encampment keep</td>
<td>Castle</td>
</tr>
<tr>
<td>Kh</td>
<td>Keep</td>
<td>Castle</td>
</tr>
<tr>
<td>Kv</td>
<td>Elven Keep</td>
<td>Castle</td>
</tr>
<tr>
<td>Kud</td>
<td>Dwarven keep</td>
<td>Castle</td>
</tr>
<tr>
<td>Khr</td>
<td>Ruined keep</td>
<td>Castle</td>
</tr>
<tr>
<td>Khw</td>
<td>Sunken keep</td>
<td>Castle,Shallow Water</td>
</tr>
<tr>
<td>Khs</td>
<td>Swamp keep</td>
<td>Castle,Swamp</td>
</tr>
<tr>
<td>Dd^Dc</td>
<td>Crater</td>
<td>Sand</td>
</tr>
<tr>
<td>Dd</td>
<td>Desert</td>
<td>Sand</td>
</tr>
<tr>
<td>Dd^Dr</td>
<td>Rubble</td>
<td>Hills</td>
</tr>
<tr>
<td>Ds</td>
<td>Sand</td>
<td></td>
</tr>
<tr>
<td>Dd^Do</td>
<td>Oasis</td>
<td>Sand</td>
</tr>
<tr>
<td>Aa^Fpa</td>
<td>Snow Forest</td>
<td>Snow,Forest</td>
</tr>
<tr>
<td>Gg^Fet</td>
<td>Great Tree</td>
<td>Forest</td>
</tr>
<tr>
<td>Gs^Fp</td>
<td>Forest</td>
<td></td>
</tr>
<tr>
<td>Gs^Ft</td>
<td>Tropical Forest</td>
<td>Forest</td>
</tr>
<tr>
<td>Gg</td>
<td>Grassland</td>
<td></td>
</tr>
<tr>
<td>Ggf</td>
<td>Grassland</td>
<td>Grassland</td>
</tr>
<tr>
<td>Gs</td>
<td>Savanna</td>
<td>Grassland</td>
</tr>
<tr>
<td>Ha</td>
<td>Snow Hills</td>
<td>Snow,Hills</td>
</tr>
<tr>
<td>Hd</td>
<td>Dunes</td>
<td>Sand,Hills</td>
</tr>
<tr>
<td>Hh</td>
<td>Hills</td>
<td></td>
</tr>
<tr>
<td>Md</td>
<td>Mountains</td>
<td>Mountains</td>
</tr>
<tr>
<td>Mm</td>
<td>Mountains</td>
<td></td>
</tr>
<tr>
<td>Qxu</td>
<td>Chasm</td>
<td></td>
</tr>
<tr>
<td>Ql</td>
<td>Lava Chasm</td>
<td>Chasm</td>
</tr>
<tr>
<td>Qlf</td>
<td>Lava (flat)</td>
<td>Chasm</td>
</tr>
<tr>
<td>Rd</td>
<td>Desert road</td>
<td>Grassland</td>
</tr>
<tr>
<td>Re</td>
<td>Dirt</td>
<td>Grassland</td>
</tr>
<tr>
<td>Rr</td>
<td>Road</td>
<td>Grassland</td>
</tr>
<tr>
<td>Re^Gvs</td>
<td>Farmland</td>
<td>Grassland</td>
</tr>
<tr>
<td>Gg^Wm</td>
<td>Windmill</td>
<td>Grassland</td>
</tr>
<tr>
<td>Ss</td>
<td>Swamp</td>
<td></td>
</tr>
<tr>
<td>Uu</td>
<td>Cave</td>
<td></td>
</tr>
<tr>
<td>Uu^Ii</td>
<td>Cave Lit</td>
<td>Cave</td>
</tr>
<tr>
<td>Uu^Uf</td>
<td>Mushroom Grove</td>
<td></td>
</tr>
<tr>
<td>Re^Uf</td>
<td>Mushroom Grove</td>
<td>Mushroom Grove</td>
</tr>
<tr>
<td>Uh</td>
<td>Rockbound Cave</td>
<td>Cave,Hills</td>
</tr>
<tr>
<td>Uh^Ii</td>
<td>Rockbound Cave Lit</td>
<td>Cave,Hills</td>
</tr>
<tr>
<td>Dd^Vda</td>
<td>Village</td>
<td>Village,Sand</td>
</tr>
<tr>
<td>Dd^Vdt</td>
<td>Village</td>
<td>Village,Sand</td>
</tr>
<tr>
<td>Aa^Vea</td>
<td>Village</td>
<td>Village</td>
</tr>
<tr>
<td>Gg^Ve</td>
<td>Village</td>
<td>Village</td>
</tr>
<tr>
<td>Aa^Vha</td>
<td>Village</td>
<td>Village</td>
</tr>
<tr>
<td>Gg^Vh</td>
<td>Village</td>
<td></td>
</tr>
<tr>
<td>Hh^Vhh</td>
<td>Village</td>
<td>Village,Hills</td>
</tr>
<tr>
<td>Ha^Vhha</td>
<td>Village</td>
<td>Village,Hills</td>
</tr>
<tr>
<td>Mm^Vhh</td>
<td>Village</td>
<td>Village,Mountains</td>
</tr>
<tr>
<td>Gs^Vht</td>
<td>Village</td>
<td>Village</td>
</tr>
<tr>
<td>Uu^Vu</td>
<td>Village</td>
<td>Village,Cave</td>
</tr>
<tr>
<td>Uu^Vud</td>
<td>Village</td>
<td>Village,Cave</td>
</tr>
<tr>
<td>Ww^Vm</td>
<td>Village</td>
<td>Shallow Water</td>
</tr>
<tr>
<td>Ss^Vhs</td>
<td>Village</td>
<td>Village,Swamp</td>
</tr>
<tr>
<td>Ss^Vm</td>
<td>Village</td>
<td>Swamp</td>
</tr>
<tr>
<td>Wo</td>
<td>Deep Water</td>
<td></td>
</tr>
<tr>
<td>Ww</td>
<td>Shallow Water</td>
<td></td>
</tr>
<tr>
<td>Wwf</td>
<td>River Ford</td>
<td>Grassland,Shallow Water</td>
</tr>
<tr>
<td>Mm^Xm</td>
<td>Impassable Mountains</td>
<td>Cave Wall</td>
</tr>
<tr>
<td>Md^Xm</td>
<td>Impassable Desert Mountains</td>
<td>Cave Wall</td>
</tr>
<tr>
<td>Xu</td>
<td>Cave Wall</td>
<td></td>
</tr>
<tr>
<td>Xv</td>
<td>Void</td>
<td>Cave Wall</td>
</tr>
</table>

== Adding terrains ==
When adding terrains make sure the following files are also checked:

data/faction/* contains favorite positions for the different factions, this is only used for the random map generator at the moment so it is not very important.

data/abilities.cfg contains the definition of ''submerge'' and ''ambush'' so depending on the change these need to be updated.

data/utils/utils.cfg contains the macro STARTING_VILLAGES which contains a list of village strings. This list doesn't support wildcards (yet).

== See Also ==
* [[TerrainWML]]
* [[ReferenceWML]]

[[Category: WML Reference]]

TerrainCodesWML

2008-01-30T15:07:32Z

Rhuvaen: add windmill terrain to terrain table

{{WML Tags}}

Note: the old (1.2) terrain system is no longer documented here. If you have 1.2 maps you will need to convert them using [[Maintenance_tools|wmllint]].

== Terrain strings ==

The following rules hold for terrain strings. Note most of these rules are not validated since it would slow down Wesnoth; not following these rules might break Wesnoth.

* terrain strings are between 2 and 4 characters
* terrain strings start with a capital letter and the following letters are lower case
* terrain strings can only contain letters, the symbols /|\ which are meant for directional items like bridges and the symbol ^
* the underscore is used for internal terrains
* the star '*' can be used for wildcards in some parts
* the symbol ^ usually points out that a terrain is created with layers, for example Gs^Fp means Forest(Fp) overlayer on Savanna(Gs).

Starting positions are defined by a number followed by 1 space and then the terrain string; this means that a starting position is no longer automatically a keep.

The letters Y,y,Z,z are reserved for UMC so any string containing any of these letters is a custom terrain. Other undefined terrain strings are reserved for future expansion within Wesnoth.

=== Terrain Table ===
This is a list of the terrains, the strings used for them in the new map format, the letters used for them in the old map format, their id and the terrains they take their stats from.

<table border="1"><tr>
<th>String</th>
<th>Name</th>
<th>Stats from</th>
</tr>
<tr>
<td>_off^_usr</td>
<td>None</td>
<td></td>
</tr>
<tr>
<td>_s</td>
<td>Shroud (use in mask only)</td>
<td></td>
</tr>
<tr>
<td>_f</td>
<td>Fog (use in mask only)</td>
<td></td>
</tr>
<tr>
<td>Ai</td>
<td>Ice</td>
<td>Snow</td>
</tr>
<tr>
<td>Aa</td>
<td>Snow</td>
<td></td>
</tr>
<tr>
<td>Ww^Bw|</td>
<td>Bridge</td>
<td>Grassland,Shallow Water</td>
</tr>
<tr>
<td>Ww^Bw/</td>
<td>Bridge</td>
<td>Grassland,Shallow Water</td>
</tr>
<tr>
<td>Ww^Bw\</td>
<td>Bridge</td>
<td>Grassland,Shallow Water</td>
</tr>
<tr>
<td>Wo^Bw|</td>
<td>Bridge</td>
<td>Grassland,Deep Water</td>
</tr>
<tr>
<td>Wo^Bw/</td>
<td>Bridge</td>
<td>Grassland,Deep Water</td>
</tr>
<tr>
<td>Wo^Bw\</td>
<td>Bridge</td>
<td>Grassland,Deep Water</td>
</tr>
<tr>
<td>Ss^Bw|</td>
<td>Bridge</td>
<td>Grassland,Swamp</td>
</tr>
<tr>
<td>Ss^Bw/</td>
<td>Bridge</td>
<td>Grassland,Swamp</td>
</tr>
<tr>
<td>Ss^Bw\</td>
<td>Bridge</td>
<td>Grassland,Swamp</td>
</tr>
<tr>
<td>Ce</td>
<td>Encampment</td>
<td>Castle</td>
</tr>
<tr>
<td>Ch</td>
<td>Castle</td>
<td></td>
</tr>
<tr>
<td>Cv</td>
<td>Elven Castle</td>
<td>Castle</td>
</tr>
<tr>
<td>Cud</td>
<td>Dwarven Castle</td>
<td>Castle</td>
</tr>
<tr>
<td>Chr</td>
<td>Ruin</td>
<td>Castle</td>
</tr>
<tr>
<td>Chw</td>
<td>Sunken Ruin</td>
<td>Castle,Shallow Water</td>
</tr>
<tr>
<td>Chs</td>
<td>Swamp Ruin</td>
<td>Castle,Swamp</td>
</tr>
<tr>
<td>Ke</td>
<td>Encampment keep</td>
<td>Castle</td>
</tr>
<tr>
<td>Kh</td>
<td>Keep</td>
<td>Castle</td>
</tr>
<tr>
<td>Kv</td>
<td>Elven Keep</td>
<td>Castle</td>
</tr>
<tr>
<td>Kud</td>
<td>Dwarven keep</td>
<td>Castle</td>
</tr>
<tr>
<td>Khr</td>
<td>Ruined keep</td>
<td>Castle</td>
</tr>
<tr>
<td>Khw</td>
<td>Sunken keep</td>
<td>Castle,Shallow Water</td>
</tr>
<tr>
<td>Khs</td>
<td>Swamp keep</td>
<td>Castle,Swamp</td>
</tr>
<tr>
<td>Dd^Dc</td>
<td>Crater</td>
<td>Sand</td>
</tr>
<tr>
<td>Dd</td>
<td>Desert</td>
<td>Sand</td>
</tr>
<tr>
<td>Dd^Dr</td>
<td>Rubble</td>
<td>Hills</td>
</tr>
<tr>
<td>Ds</td>
<td>Sand</td>
<td></td>
</tr>
<tr>
<td>Dd^Do</td>
<td>Oasis</td>
<td>Sand</td>
</tr>
<tr>
<td>Aa^Fpa</td>
<td>Snow Forest</td>
<td>Snow,Forest</td>
</tr>
<tr>
<td>Gg^Fet</td>
<td>Great Tree</td>
<td>Forest</td>
</tr>
<tr>
<td>Gs^Fp</td>
<td>Forest</td>
<td></td>
</tr>
<tr>
<td>Gs^Ft</td>
<td>Tropical Forest</td>
<td>Forest</td>
</tr>
<tr>
<td>Gg</td>
<td>Grassland</td>
<td></td>
</tr>
<tr>
<td>Ggf</td>
<td>Grassland</td>
<td>Grassland</td>
</tr>
<tr>
<td>Gs</td>
<td>Savanna</td>
<td>Grassland</td>
</tr>
<tr>
<td>Ha</td>
<td>Snow Hills</td>
<td>Snow,Hills</td>
</tr>
<tr>
<td>Hd</td>
<td>Dunes</td>
<td>Sand,Hills</td>
</tr>
<tr>
<td>Hh</td>
<td>Hills</td>
<td></td>
</tr>
<tr>
<td>Md</td>
<td>Mountains</td>
<td>Mountains</td>
</tr>
<tr>
<td>Mm</td>
<td>Mountains</td>
<td></td>
</tr>
<tr>
<td>Qxu</td>
<td>Chasm</td>
<td></td>
</tr>
<tr>
<td>Ql</td>
<td>Lava</td>
<td>Chasm</td>
</tr>
<tr>
<td>Rd</td>
<td>Desert road</td>
<td>Grassland</td>
</tr>
<tr>
<td>Re</td>
<td>Dirt</td>
<td>Grassland</td>
</tr>
<tr>
<td>Rr</td>
<td>Road</td>
<td>Grassland</td>
</tr>
<tr>
<td>Re^Gvs</td>
<td>Farmland</td>
<td>Grassland</td>
</tr>
<tr>
<td>Gg^Wm</td>
<td>Windmill</td>
<td>Grassland</td>
</tr>
<tr>
<td>Ss</td>
<td>Swamp</td>
<td></td>
</tr>
<tr>
<td>Uu</td>
<td>Cave</td>
<td></td>
</tr>
<tr>
<td>Uu^Ii</td>
<td>Cave Lit</td>
<td>Cave</td>
</tr>
<tr>
<td>Uu^Uf</td>
<td>Mushroom Grove</td>
<td></td>
</tr>
<tr>
<td>Re^Uf</td>
<td>Mushroom Grove</td>
<td>Mushroom Grove</td>
</tr>
<tr>
<td>Uh</td>
<td>Rockbound Cave</td>
<td>Cave,Hills</td>
</tr>
<tr>
<td>Uh^Ii</td>
<td>Rockbound Cave Lit</td>
<td>Cave,Hills</td>
</tr>
<tr>
<td>Dd^Vda</td>
<td>Village</td>
<td>Village,Sand</td>
</tr>
<tr>
<td>Dd^Vdt</td>
<td>Village</td>
<td>Village,Sand</td>
</tr>
<tr>
<td>Aa^Vea</td>
<td>Village</td>
<td>Village</td>
</tr>
<tr>
<td>Gg^Ve</td>
<td>Village</td>
<td>Village</td>
</tr>
<tr>
<td>Aa^Vha</td>
<td>Village</td>
<td>Village</td>
</tr>
<tr>
<td>Gg^Vh</td>
<td>Village</td>
<td></td>
</tr>
<tr>
<td>Hh^Vhh</td>
<td>Village</td>
<td>Village,Hills</td>
</tr>
<tr>
<td>Ha^Vhha</td>
<td>Village</td>
<td>Village,Hills</td>
</tr>
<tr>
<td>Mm^Vhh</td>
<td>Village</td>
<td>Village,Mountains</td>
</tr>
<tr>
<td>Gs^Vht</td>
<td>Village</td>
<td>Village</td>
</tr>
<tr>
<td>Uu^Vu</td>
<td>Village</td>
<td>Village,Cave</td>
</tr>
<tr>
<td>Uu^Vud</td>
<td>Village</td>
<td>Village,Cave</td>
</tr>
<tr>
<td>Ww^Vm</td>
<td>Village</td>
<td>Shallow Water</td>
</tr>
<tr>
<td>Ss^Vhs</td>
<td>Village</td>
<td>Village,Swamp</td>
</tr>
<tr>
<td>Ss^Vm</td>
<td>Village</td>
<td>Swamp</td>
</tr>
<tr>
<td>Wo</td>
<td>Deep Water</td>
<td></td>
</tr>
<tr>
<td>Ww</td>
<td>Shallow Water</td>
<td></td>
</tr>
<tr>
<td>Wwf</td>
<td>River Ford</td>
<td>Grassland,Shallow Water</td>
</tr>
<tr>
<td>Mm^Xm</td>
<td>Impassable Mountains</td>
<td>Cave Wall</td>
</tr>
<tr>
<td>Md^Xm</td>
<td>Impassable Desert Mountains</td>
<td>Cave Wall</td>
</tr>
<tr>
<td>Xu</td>
<td>Cave Wall</td>
<td></td>
</tr>
<tr>
<td>Xv</td>
<td>Void</td>
<td>Cave Wall</td>
</tr>
</table>

== Adding terrains ==
When adding terrains make sure the following files are also checked:

data/faction/* contains favorite positions for the different factions, this is only used for the random map generator at the moment so it is not very important.

data/abilities.cfg contains the definition of ''submerge'' and ''ambush'' so depending on the change these need to be updated.

data/utils/utils.cfg contains the macro STARTING_VILLAGES which contains a list of village strings. This list doesn't support wildcards (yet).

== See Also ==
* [[TerrainWML]]
* [[ReferenceWML]]

[[Category: WML Reference]]

UnitTypeWML

2007-10-30T17:52:43Z

Rhuvaen: added [advancement] image

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

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

Unit animation syntax is described in [[AnimationWML]].

The following key/tags are recognized:
{| class="gallery" style="text-align:left;"
|-
! advancefrom
| the previous level unit 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 ''advanceto'' and ''experience'' keys of a base unit to make it advance into this unit. It takes these keys:<br> ** ''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.<br>** [[experience]] is optional. If present and lower than the experience already required for the base unit to advance, then the experience to advance is lowered. Note: this will also lower the experience required to advance to other units which the base unit can advance into.
|-
! advanceto
| When this unit has experience greater than or equal to [[experience]], it is replaced by a unit of the type that the value of [[advanceto]] refers to. All modifications that have been done to the unit are applied to the unit it is replaced by.
|-
! alignment
| how the unit's damage should be affected by its lawful bonus (See [[TimeWML]]).
|-
! 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.
|-
! 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 ''advanceto'' refers to. All modifications that have been done to the unit are applied to the unit it is replaced by.
|-
! 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
| {{DevFeature}} 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. 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 id and must be avoided because they might lead to corrupted saved games
|-
! 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 recieves each turn.
|-
! movetype
| See '''[[movetype]]''', [[UnitsWML]]. Note that the tags '''[[movement_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]]).
|-
! race
| See '''[race]''', [[UnitsWML]]. Also used in standard unit filter (see [[FilterWML]]).
|-
! unit_description
| (translatable) the text displayed in the unit descriptor box for this unit. Default 'No description available...'.
|-
! undead_variation
| Which image to use when a unit of this type is killed by a unit with the plague ability.
|-
! usage
| the way that the AI should recruit this unit, as determined by the scenario designer. (See ''recruitment_pattern'', [[AiWML]]). The following are conventions on usage:<br> ** 'scout' Fast,<br> ** 'fighter' Melee fighter,<br> ** 'archer' Ranged fighter,<br> ** 'mixed fighter' Melee and ranged fighter, and<br> ** 'healer' Specialty 'heals' or 'cures'.
|-
! 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).
|}
==== 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 ''advanceto''; however, if the player chooses this advancement, the unit will have one or more effects applied to it instead of advancing.
** ''id'' normal internationalization id.
** ''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.
** ''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: ''require_amla=tough,tough,incr_damage'' 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]]

==== Other tags ====
* '''[base_unit]''' Contains one attribute, '''id''', which must be the ID of a unit type. If specified, the UnitWML for that unit is copied into this one. Subsequent attributes modify the copy. (1.3.7 and later versions only.)
* '''[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; see [[FilterWML]]
** ''type'' the damage type of the attack. Used in determining resistance to this attack (see '''[resistances]''', [[UnitsWML]]). Possible values are 'blade', 'pierce', 'impact', 'fire', 'cold', and 'holy'.
** ''special'' the special ability of the attack. Currently having more than 1 ability is not supported. See [[AbilitiesWML]] for a list of possible values.
** ''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
For those two following settings, the engine usually chooses the attack with the best average total damages * weight (default weight = 1.0).
** ''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
** ''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.

** '''[animation]'''
:: This describes an animation for this attack. If multiple animations are present, one will be randomly chosen each time the unit attacks. See [[AnimationWML]] for possible keys.

* '''[defend]''' See [[AnimationWML]]
* '''[death]''' See [[AnimationWML]]
* '''[teleport_anim]''' See [[AnimationWML]]
* '''[extra_anim]''' See [[AnimationWML]]
* '''[event]''' Any [event] written inside the [unit] 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. They are currently used for graphical variations (giving character sprites new weapons) but theoretically you could do anything with it.
** ''variation_name'' The name of the variation.
** ''inherit'' if ''yes'', inherits all the properties of the base unit.
: All other keys in '''[variation]''' are the same as for '''[unit]''' itself.

* '''[male]''', '''[female]''' They can contain all '''[unit]''' tags, to specify a variation of different gender for a unit.

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

== See Also ==

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

[[Category: WML Reference]]

TerrainCodesWML

2007-10-30T16:55:12Z

Rhuvaen: /* Terrain Table */

{{WML Tags}}
== Values of terrain letters ==

What each letter represents in Wesnoth maps,
and the possible values of the ''letter'' key.

See [[TerrainWML]] for information on how to define a terrain.

* '''A''' human (snow) hill village
* '''a''' human hill village
* '''B''' desert village (adobe)
* '''b''' human mountain village
* '''C''' castle
* '''c''' shallow water, "coast"
* '''D''' underground village (cave, village), "dungeon village"
* '''d''' sand, (old desert)
* '''E''' desert road
* '''e''' elven (snow) village
* '''F''' forest (snow)
* '''f''' forest
* '''G''' savanna (grass)
* '''g''' grass
* '''H''' hills (snow)
* '''h''' hills
* '''I''' desert
* '''i''' ice (tundra)
* '''J''' desert hills
* '''j''' -nothing- (will be snowy mountains)
* '''K''' keep (castle)
* '''k''' river ford (grass, shallow water)
* '''L''' tropical forest village (savanna, village)
* '''l''' lava (canyon)
* '''M''' desert mountains
* '''m''' mountain
* '''N''' ruined castle
* '''n''' encampment (castle)
* '''O''' -nothing- (will probably be an Orc Castle one day)
* '''o''' dwarven castle (castle)
* '''P''' desert oasis
* '''p''' dwarven village
* '''Q''' sunken ruin
* '''q''' ruin (swamp)
* '''R''' road (grass)
* '''r''' dirt (grass)
* '''S''' tundra
* '''s''' deep water
* '''T''' forest (tropical)
* '''t''' village
* '''U''' desert village (tent)
* '''u''' cave
* '''V''' snow village (tundra, village)
* '''v''' human village (village)
* '''W''' cavewall
* '''w''' swamp
* '''X''' canyon (replaced by chasm in trunk)
* '''x''' reserved for UMCs
* '''Y''' swamp village (swamp, village)
* '''y''' reserved for UMCs
* '''Z''' mermen village (shallow water)
* '''z''' reserved for UMCs
* '''/''','''|''','''\''' bridge (grass, shallow water)
* '''~''' fog
* ' ' void/shroud (it uses the "space" character)
* '''*''' reserved for UMCs
* '''^''' reserved for UMCs
* '''%''' reserved for UMCs
* '''@''' reserved for UMCs
* '''[''' rockbound cave
* ''']''' mushroom grove
* ''' ' ''' illuminated cave
* ''' ? ''' great Elven tree
* ''' & ''' impassable mountains
* ''' " ''' ???
* ''' $ ''' ???
* ''' . ''' ???
* ''' ; ''' ???
* ''' : ''' ???
* ''' < ''' ???
* ''' > ''' ???
* ''' _ ''' ???
* ''' ` ''' ???

==Reserved letters and non-letter Characters==
Reserved letters are for custom terrains in user-made campaigns. In addition to these it is currently also possible to use other characters not on the above list to represent custom terrain, such as ½ § @ % etc., but new "official" terrain may be assigned for these characters in the future. So when creating custom terrain, the letters marked as reserved on the above list should be used first.
Use campaign definitions (see [[CampaignWML]]) to prevent your custom terrains from interfering with other campaigns.

== Terrain strings '''''[[User:SkeletonCrew#Branch_terrain|(SVN terrain only)]]''''' ==
The terrains will be changed from a single letter to a multi letter system. There will be a compability layer for a short while. This layer doesn't work for campaigns with custom terrains, these campaigns have to be changed to use the new system.

The following rules are stated for the new terrain letters, note most of these rules are not validated since it would slow down Wesnoth; not following these rules might break Wesnoth.
* terrain strings are between 2 and 4 characters
* terrain strings start with a capital letter and the following letters are lower case
* terrain strings can only contain letters, the symbols /|\ which are meant for directional items like bridges and the symbol ^
* the underscore is used for internal terrains
* the star '*' can be used for wildcards in some parts
* the symbol ^ usually points out that a terrain is created with layers, for example Gs^Fp means Forest(Fp) overlayer on Savanna(Gs).

Starting positions are defined by a number followed by 1 space and then the terrain string; this means that a starting position is no longer automatically a keep.

The letters Y,y,Z,z are reserved for UMC so any string containing any of these letters is a custom terrain. Other undefined terrain strings are reserved for future expansion within Wesnoth.

=== Conversion form old to new ===
Map conversion logic is included in the [[Maintenance_tools|upconvert]] tool (in newer versions, [[Maintenance_tools|wmllint]]). This script will, among other things, convert a map with the old letters to the new strings. Here is a lookup table with the letters.

char= a b c d e f g h i j k l m
str= Vhh Vhm Ww Ds Vea Ff Gg Hh Ai Wwf Ql Mm

char= n o p q r s t u v w x y z
str= Ce Cud Vud Chs Re Wo Veg Uu Vhg Ss

char= A B C D E F G H I J K L M
str= Vhha Vda Ch Vu Rd Fa Gs Ha Dd Hd Kh Vht Md

char= N O P Q R S T U V W X Y Z
str= Chr Do Chw Rr Aa Ft Vdt Vha Xu Qxu Vs Vwm

char= / | \ & _ ~ ? ] [ '
str= Ww^Bw/ Ww^Bw| Ww^Bw\ Xm _s _f Fet Uf Uh Uui

=== Terrain Table ===
This is a list of the terrains, the strings used for them in the new map format, the letters used for them in the old map format, their id and the terrains they take their stats from. Generated from terrain.cfg using terrain2wiki.

<table border="1"><tr>
<th>String</th>
<th>Old letter</th>
<th>Name</th>
<th>Stats from</th>
</tr>
<tr>
<td>_off^_usr</td>
<td></td>
<td>None</td>
<td></td>
</tr>
<tr>
<td>_s</td>
<td></td>
<td>Shroud (use in mask only)</td>
<td></td>
</tr>
<tr>
<td>_f</td>
<td>~</td>
<td>Fog (use in mask only)</td>
<td></td>
</tr>
<tr>
<td>Ai</td>
<td>i</td>
<td>Ice</td>
<td>Snow</td>
</tr>
<tr>
<td>Aa</td>
<td>S</td>
<td>Snow</td>
<td></td>
</tr>
<tr>
<td>Ww^Bw|</td>
<td>|</td>
<td>Bridge</td>
<td>Grassland,Shallow Water</td>
</tr>
<tr>
<td>Ww^Bw/</td>
<td>/</td>
<td>Bridge</td>
<td>Grassland,Shallow Water</td>
</tr>
<tr>
<td>Ww^Bw\</td>
<td>\</td>
<td>Bridge</td>
<td>Grassland,Shallow Water</td>
</tr>
<tr>
<td>Wo^Bw|</td>
<td></td>
<td>Bridge</td>
<td>Grassland,Deep Water</td>
</tr>
<tr>
<td>Wo^Bw/</td>
<td></td>
<td>Bridge</td>
<td>Grassland,Deep Water</td>
</tr>
<tr>
<td>Wo^Bw\</td>
<td></td>
<td>Bridge</td>
<td>Grassland,Deep Water</td>
</tr>
<tr>
<td>Ss^Bw|</td>
<td></td>
<td>Bridge</td>
<td>Grassland,Swamp</td>
</tr>
<tr>
<td>Ss^Bw/</td>
<td></td>
<td>Bridge</td>
<td>Grassland,Swamp</td>
</tr>
<tr>
<td>Ss^Bw\</td>
<td></td>
<td>Bridge</td>
<td>Grassland,Swamp</td>
</tr>
<tr>
<td>Ce</td>
<td>n</td>
<td>Encampment</td>
<td>Castle</td>
</tr>
<tr>
<td>Ch</td>
<td>y</td>
<td>Castle</td>
<td></td>
</tr>
<tr>
<td>Cv</td>
<td>y</td>
<td>Elven Castle</td>
<td>Castle</td>
</tr>
<tr>
<td>Cud</td>
<td>o</td>
<td>Dwarven Castle</td>
<td>Castle</td>
</tr>
<tr>
<td>Chr</td>
<td>N</td>
<td>Ruin</td>
<td>Castle</td>
</tr>
<tr>
<td>Chw</td>
<td>Q</td>
<td>Sunken Ruin</td>
<td>Castle,Shallow Water</td>
</tr>
<tr>
<td>Chs</td>
<td>q</td>
<td>Swamp Ruin</td>
<td>Castle,Swamp</td>
</tr>
<tr>
<td>Ke</td>
<td></td>
<td>Encampment keep</td>
<td>Castle</td>
</tr>
<tr>
<td>Kh</td>
<td></td>
<td>Keep</td>
<td>Castle</td>
</tr>
<tr>
<td>Kv</td>
<td></td>
<td>Elven Keep</td>
<td>Castle</td>
</tr>
<tr>
<td>Kud</td>
<td></td>
<td>Dwarven keep</td>
<td>Castle</td>
</tr>
<tr>
<td>Khr</td>
<td></td>
<td>Ruined keep</td>
<td>Castle</td>
</tr>
<tr>
<td>Khw</td>
<td></td>
<td>Sunken keep</td>
<td>Castle,Shallow Water</td>
</tr>
<tr>
<td>Khs</td>
<td></td>
<td>Swamp keep</td>
<td>Castle,Swamp</td>
</tr>
<tr>
<td>Dd^Dc</td>
<td></td>
<td>Crater</td>
<td>Sand</td>
</tr>
<tr>
<td>Dd</td>
<td>I</td>
<td>Desert</td>
<td>Sand</td>
</tr>
<tr>
<td>Dd^Dr</td>
<td></td>
<td>Rubble</td>
<td>Hills</td>
</tr>
<tr>
<td>Ds</td>
<td>d</td>
<td>Sand</td>
<td></td>
</tr>
<tr>
<td>Dd^Do</td>
<td>P</td>
<td>Oasis</td>
<td>Sand</td>
</tr>
<tr>
<td>Aa^Fpa</td>
<td>F</td>
<td>Snow Forest</td>
<td>Snow,Forest</td>
</tr>
<tr>
<td>Gg^Fet</td>
<td>?</td>
<td>Great Tree</td>
<td>Forest</td>
</tr>
<tr>
<td>Gs^Fp</td>
<td>f</td>
<td>Forest</td>
<td></td>
</tr>
<tr>
<td>Gs^Ft</td>
<td>T</td>
<td>Tropical Forest</td>
<td>Forest</td>
</tr>
<tr>
<td>Gg</td>
<td>g</td>
<td>Grassland</td>
<td></td>
</tr>
<tr>
<td>Ggf</td>
<td></td>
<td>Grassland</td>
<td>Grassland</td>
</tr>
<tr>
<td>Gs</td>
<td>G</td>
<td>Savanna</td>
<td>Grassland</td>
</tr>
<tr>
<td>Ha</td>
<td>H</td>
<td>Snow Hills</td>
<td>Snow,Hills</td>
</tr>
<tr>
<td>Hd</td>
<td>J</td>
<td>Dunes</td>
<td>Sand,Hills</td>
</tr>
<tr>
<td>Hh</td>
<td>h</td>
<td>Hills</td>
<td></td>
</tr>
<tr>
<td>Md</td>
<td>M</td>
<td>Mountains</td>
<td>Mountains</td>
</tr>
<tr>
<td>Mm</td>
<td>m</td>
<td>Mountains</td>
<td></td>
</tr>
<tr>
<td>Qxu</td>
<td>X</td>
<td>Chasm</td>
<td></td>
</tr>
<tr>
<td>Ql</td>
<td>l</td>
<td>Lava</td>
<td>Chasm</td>
</tr>
<tr>
<td>Rd</td>
<td>E</td>
<td>Desert road</td>
<td>Grassland</td>
</tr>
<tr>
<td>Re</td>
<td>r</td>
<td>Dirt</td>
<td>Grassland</td>
</tr>
<tr>
<td>Rr</td>
<td>E</td>
<td>Road</td>
<td>Grassland</td>
</tr>
<tr>
<td>Re^Gvs</td>
<td></td>
<td>Farmland</td>
<td>Grassland</td>
</tr>
<tr>
<td>Ss</td>
<td>w</td>
<td>Swamp</td>
<td></td>
</tr>
<tr>
<td>Uu</td>
<td>u</td>
<td>Cave</td>
<td></td>
</tr>
<tr>
<td>Uu^Ii</td>
<td>'</td>
<td>Cave Lit</td>
<td>Cave</td>
</tr>
<tr>
<td>Uu^Uf</td>
<td>]</td>
<td>Mushroom Grove</td>
<td></td>
</tr>
<tr>
<td>Re^Uf</td>
<td></td>
<td>Mushroom Grove</td>
<td>Mushroom Grove</td>
</tr>
<tr>
<td>Uh</td>
<td>[</td>
<td>Rockbound Cave</td>
<td>Cave,Hills</td>
</tr>
<tr>
<td>Uh^Ii</td>
<td></td>
<td>Rockbound Cave Lit</td>
<td>Cave,Hills</td>
</tr>
<tr>
<td>Dd^Vda</td>
<td>U</td>
<td>Village</td>
<td>Village,Sand</td>
</tr>
<tr>
<td>Dd^Vdt</td>
<td>U</td>
<td>Village</td>
<td>Village,Sand</td>
</tr>
<tr>
<td>Aa^Vea</td>
<td>e</td>
<td>Village</td>
<td>Village</td>
</tr>
<tr>
<td>Gg^Ve</td>
<td>t</td>
<td>Village</td>
<td>Village</td>
</tr>
<tr>
<td>Aa^Vha</td>
<td>V</td>
<td>Village</td>
<td>Village</td>
</tr>
<tr>
<td>Gg^Vh</td>
<td>t</td>
<td>Village</td>
<td></td>
</tr>
<tr>
<td>Hh^Vhh</td>
<td>a</td>
<td>Village</td>
<td>Village,Hills</td>
</tr>
<tr>
<td>Ha^Vhha</td>
<td>A</td>
<td>Village</td>
<td>Village,Hills</td>
</tr>
<tr>
<td>Mm^Vhh</td>
<td>b</td>
<td>Village</td>
<td>Village,Mountains</td>
</tr>
<tr>
<td>Gs^Vht</td>
<td>L</td>
<td>Village</td>
<td>Village</td>
</tr>
<tr>
<td>Uu^Vu</td>
<td>D</td>
<td>Village</td>
<td>Village,Cave</td>
</tr>
<tr>
<td>Uu^Vud</td>
<td>p</td>
<td>Village</td>
<td>Village,Cave</td>
</tr>
<tr>
<td>Ww^Vm</td>
<td>Z</td>
<td>Village</td>
<td>Shallow Water</td>
</tr>
<tr>
<td>Ss^Vhs</td>
<td>Y</td>
<td>Village</td>
<td>Village,Swamp</td>
</tr>
<tr>
<td>Ss^Vm</td>
<td></td>
<td>Village</td>
<td>Swamp</td>
</tr>
<tr>
<td>Wo</td>
<td>s</td>
<td>Deep Water</td>
<td></td>
</tr>
<tr>
<td>Ww</td>
<td>c</td>
<td>Shallow Water</td>
<td></td>
</tr>
<tr>
<td>Wwf</td>
<td>k</td>
<td>River Ford</td>
<td>Grassland,Shallow Water</td>
</tr>
<tr>
<td>Mm^Xm</td>
<td>&</td>
<td>Impassable Mountains</td>
<td>Cave Wall</td>
</tr>
<tr>
<td>Md^Xm</td>
<td></td>
<td>Impassable Desert Mountains</td>
<td>Cave Wall</td>
</tr>
<tr>
<td>Xu</td>
<td>W</td>
<td>Cave Wall</td>
<td></td>
</tr>
<tr>
<td>Xv</td>
<td></td>
<td>Void</td>
<td>Cave Wall</td>
</tr>
</table>

== Adding terrains ==
When adding terrains make sure the following files are also checked:

data/faction/* contains favorite positions for the different factions, this is only used for the random map generator at the moment so it is not very important.

data/abilities.cfg contains the definition of ''submerge'' and ''ambush'' so depending on the change these need to be updated.

data/utils/utils.cfg contains the macro STARTING_VILLAGES which contains a list of village strings. This list doesn't support wildcards (yet).

== See Also ==
* [[TerrainWML]]
* [[ReferenceWML]]

[[Category: WML Reference]]

TerrainCodesWML

2007-10-30T16:54:02Z

Rhuvaen: added Void terrain 'Xv'

{{WML Tags}}
== Values of terrain letters ==

What each letter represents in Wesnoth maps,
and the possible values of the ''letter'' key.

See [[TerrainWML]] for information on how to define a terrain.

* '''A''' human (snow) hill village
* '''a''' human hill village
* '''B''' desert village (adobe)
* '''b''' human mountain village
* '''C''' castle
* '''c''' shallow water, "coast"
* '''D''' underground village (cave, village), "dungeon village"
* '''d''' sand, (old desert)
* '''E''' desert road
* '''e''' elven (snow) village
* '''F''' forest (snow)
* '''f''' forest
* '''G''' savanna (grass)
* '''g''' grass
* '''H''' hills (snow)
* '''h''' hills
* '''I''' desert
* '''i''' ice (tundra)
* '''J''' desert hills
* '''j''' -nothing- (will be snowy mountains)
* '''K''' keep (castle)
* '''k''' river ford (grass, shallow water)
* '''L''' tropical forest village (savanna, village)
* '''l''' lava (canyon)
* '''M''' desert mountains
* '''m''' mountain
* '''N''' ruined castle
* '''n''' encampment (castle)
* '''O''' -nothing- (will probably be an Orc Castle one day)
* '''o''' dwarven castle (castle)
* '''P''' desert oasis
* '''p''' dwarven village
* '''Q''' sunken ruin
* '''q''' ruin (swamp)
* '''R''' road (grass)
* '''r''' dirt (grass)
* '''S''' tundra
* '''s''' deep water
* '''T''' forest (tropical)
* '''t''' village
* '''U''' desert village (tent)
* '''u''' cave
* '''V''' snow village (tundra, village)
* '''v''' human village (village)
* '''W''' cavewall
* '''w''' swamp
* '''X''' canyon (replaced by chasm in trunk)
* '''x''' reserved for UMCs
* '''Y''' swamp village (swamp, village)
* '''y''' reserved for UMCs
* '''Z''' mermen village (shallow water)
* '''z''' reserved for UMCs
* '''/''','''|''','''\''' bridge (grass, shallow water)
* '''~''' fog
* ' ' void/shroud (it uses the "space" character)
* '''*''' reserved for UMCs
* '''^''' reserved for UMCs
* '''%''' reserved for UMCs
* '''@''' reserved for UMCs
* '''[''' rockbound cave
* ''']''' mushroom grove
* ''' ' ''' illuminated cave
* ''' ? ''' great Elven tree
* ''' & ''' impassable mountains
* ''' " ''' ???
* ''' $ ''' ???
* ''' . ''' ???
* ''' ; ''' ???
* ''' : ''' ???
* ''' < ''' ???
* ''' > ''' ???
* ''' _ ''' ???
* ''' ` ''' ???

==Reserved letters and non-letter Characters==
Reserved letters are for custom terrains in user-made campaigns. In addition to these it is currently also possible to use other characters not on the above list to represent custom terrain, such as ½ § @ % etc., but new "official" terrain may be assigned for these characters in the future. So when creating custom terrain, the letters marked as reserved on the above list should be used first.
Use campaign definitions (see [[CampaignWML]]) to prevent your custom terrains from interfering with other campaigns.

== Terrain strings '''''[[User:SkeletonCrew#Branch_terrain|(SVN terrain only)]]''''' ==
The terrains will be changed from a single letter to a multi letter system. There will be a compability layer for a short while. This layer doesn't work for campaigns with custom terrains, these campaigns have to be changed to use the new system.

The following rules are stated for the new terrain letters, note most of these rules are not validated since it would slow down Wesnoth; not following these rules might break Wesnoth.
* terrain strings are between 2 and 4 characters
* terrain strings start with a capital letter and the following letters are lower case
* terrain strings can only contain letters, the symbols /|\ which are meant for directional items like bridges and the symbol ^
* the underscore is used for internal terrains
* the star '*' can be used for wildcards in some parts
* the symbol ^ usually points out that a terrain is created with layers, for example Gs^Fp means Forest(Fp) overlayer on Savanna(Gs).

Starting positions are defined by a number followed by 1 space and then the terrain string; this means that a starting position is no longer automatically a keep.

The letters Y,y,Z,z are reserved for UMC so any string containing any of these letters is a custom terrain. Other undefined terrain strings are reserved for future expansion within Wesnoth.

=== Conversion form old to new ===
Map conversion logic is included in the [[Maintenance_tools|upconvert]] tool (in newer versions, [[Maintenance_tools|wmllint]]). This script will, among other things, convert a map with the old letters to the new strings. Here is a lookup table with the letters.

char= a b c d e f g h i j k l m
str= Vhh Vhm Ww Ds Vea Ff Gg Hh Ai Wwf Ql Mm

char= n o p q r s t u v w x y z
str= Ce Cud Vud Chs Re Wo Veg Uu Vhg Ss

char= A B C D E F G H I J K L M
str= Vhha Vda Ch Vu Rd Fa Gs Ha Dd Hd Kh Vht Md

char= N O P Q R S T U V W X Y Z
str= Chr Do Chw Rr Aa Ft Vdt Vha Xu Qxu Vs Vwm

char= / | \ & _ ~ ? ] [ '
str= Ww^Bw/ Ww^Bw| Ww^Bw\ Xm _s _f Fet Uf Uh Uui

=== Terrain Table ===
This is a list of the terrains, the strings used for them in the new map format, the letters used for them in the old map format, their id and the terrains they take their stats from. Generated from terrain.cfg using terrain2wiki.

<table border="1"><tr>
<th>String</th>
<th>Old letter</th>
<th>Name</th>
<th>Stats from</th>
</tr>
<tr>
<td>_off^_usr</td>
<td></td>
<td>None</td>
<td></td>
</tr>
<tr>
<td>_s</td>
<td></td>
<td>Shroud (mask only)</td>
<td></td>
</tr>
<tr>
<td>_f</td>
<td>~</td>
<td>Fog (mask only)</td>
<td></td>
</tr>
<tr>
<td>Ai</td>
<td>i</td>
<td>Ice</td>
<td>Snow</td>
</tr>
<tr>
<td>Aa</td>
<td>S</td>
<td>Snow</td>
<td></td>
</tr>
<tr>
<td>Ww^Bw|</td>
<td>|</td>
<td>Bridge</td>
<td>Grassland,Shallow Water</td>
</tr>
<tr>
<td>Ww^Bw/</td>
<td>/</td>
<td>Bridge</td>
<td>Grassland,Shallow Water</td>
</tr>
<tr>
<td>Ww^Bw\</td>
<td>\</td>
<td>Bridge</td>
<td>Grassland,Shallow Water</td>
</tr>
<tr>
<td>Wo^Bw|</td>
<td></td>
<td>Bridge</td>
<td>Grassland,Deep Water</td>
</tr>
<tr>
<td>Wo^Bw/</td>
<td></td>
<td>Bridge</td>
<td>Grassland,Deep Water</td>
</tr>
<tr>
<td>Wo^Bw\</td>
<td></td>
<td>Bridge</td>
<td>Grassland,Deep Water</td>
</tr>
<tr>
<td>Ss^Bw|</td>
<td></td>
<td>Bridge</td>
<td>Grassland,Swamp</td>
</tr>
<tr>
<td>Ss^Bw/</td>
<td></td>
<td>Bridge</td>
<td>Grassland,Swamp</td>
</tr>
<tr>
<td>Ss^Bw\</td>
<td></td>
<td>Bridge</td>
<td>Grassland,Swamp</td>
</tr>
<tr>
<td>Ce</td>
<td>n</td>
<td>Encampment</td>
<td>Castle</td>
</tr>
<tr>
<td>Ch</td>
<td>y</td>
<td>Castle</td>
<td></td>
</tr>
<tr>
<td>Cv</td>
<td>y</td>
<td>Elven Castle</td>
<td>Castle</td>
</tr>
<tr>
<td>Cud</td>
<td>o</td>
<td>Dwarven Castle</td>
<td>Castle</td>
</tr>
<tr>
<td>Chr</td>
<td>N</td>
<td>Ruin</td>
<td>Castle</td>
</tr>
<tr>
<td>Chw</td>
<td>Q</td>
<td>Sunken Ruin</td>
<td>Castle,Shallow Water</td>
</tr>
<tr>
<td>Chs</td>
<td>q</td>
<td>Swamp Ruin</td>
<td>Castle,Swamp</td>
</tr>
<tr>
<td>Ke</td>
<td></td>
<td>Encampment keep</td>
<td>Castle</td>
</tr>
<tr>
<td>Kh</td>
<td></td>
<td>Keep</td>
<td>Castle</td>
</tr>
<tr>
<td>Kv</td>
<td></td>
<td>Elven Keep</td>
<td>Castle</td>
</tr>
<tr>
<td>Kud</td>
<td></td>
<td>Dwarven keep</td>
<td>Castle</td>
</tr>
<tr>
<td>Khr</td>
<td></td>
<td>Ruined keep</td>
<td>Castle</td>
</tr>
<tr>
<td>Khw</td>
<td></td>
<td>Sunken keep</td>
<td>Castle,Shallow Water</td>
</tr>
<tr>
<td>Khs</td>
<td></td>
<td>Swamp keep</td>
<td>Castle,Swamp</td>
</tr>
<tr>
<td>Dd^Dc</td>
<td></td>
<td>Crater</td>
<td>Sand</td>
</tr>
<tr>
<td>Dd</td>
<td>I</td>
<td>Desert</td>
<td>Sand</td>
</tr>
<tr>
<td>Dd^Dr</td>
<td></td>
<td>Rubble</td>
<td>Hills</td>
</tr>
<tr>
<td>Ds</td>
<td>d</td>
<td>Sand</td>
<td></td>
</tr>
<tr>
<td>Dd^Do</td>
<td>P</td>
<td>Oasis</td>
<td>Sand</td>
</tr>
<tr>
<td>Aa^Fpa</td>
<td>F</td>
<td>Snow Forest</td>
<td>Snow,Forest</td>
</tr>
<tr>
<td>Gg^Fet</td>
<td>?</td>
<td>Great Tree</td>
<td>Forest</td>
</tr>
<tr>
<td>Gs^Fp</td>
<td>f</td>
<td>Forest</td>
<td></td>
</tr>
<tr>
<td>Gs^Ft</td>
<td>T</td>
<td>Tropical Forest</td>
<td>Forest</td>
</tr>
<tr>
<td>Gg</td>
<td>g</td>
<td>Grassland</td>
<td></td>
</tr>
<tr>
<td>Ggf</td>
<td></td>
<td>Grassland</td>
<td>Grassland</td>
</tr>
<tr>
<td>Gs</td>
<td>G</td>
<td>Savanna</td>
<td>Grassland</td>
</tr>
<tr>
<td>Ha</td>
<td>H</td>
<td>Snow Hills</td>
<td>Snow,Hills</td>
</tr>
<tr>
<td>Hd</td>
<td>J</td>
<td>Dunes</td>
<td>Sand,Hills</td>
</tr>
<tr>
<td>Hh</td>
<td>h</td>
<td>Hills</td>
<td></td>
</tr>
<tr>
<td>Md</td>
<td>M</td>
<td>Mountains</td>
<td>Mountains</td>
</tr>
<tr>
<td>Mm</td>
<td>m</td>
<td>Mountains</td>
<td></td>
</tr>
<tr>
<td>Qxu</td>
<td>X</td>
<td>Chasm</td>
<td></td>
</tr>
<tr>
<td>Ql</td>
<td>l</td>
<td>Lava</td>
<td>Chasm</td>
</tr>
<tr>
<td>Rd</td>
<td>E</td>
<td>Desert road</td>
<td>Grassland</td>
</tr>
<tr>
<td>Re</td>
<td>r</td>
<td>Dirt</td>
<td>Grassland</td>
</tr>
<tr>
<td>Rr</td>
<td>E</td>
<td>Road</td>
<td>Grassland</td>
</tr>
<tr>
<td>Re^Gvs</td>
<td></td>
<td>Farmland</td>
<td>Grassland</td>
</tr>
<tr>
<td>Ss</td>
<td>w</td>
<td>Swamp</td>
<td></td>
</tr>
<tr>
<td>Uu</td>
<td>u</td>
<td>Cave</td>
<td></td>
</tr>
<tr>
<td>Uu^Ii</td>
<td>'</td>
<td>Cave Lit</td>
<td>Cave</td>
</tr>
<tr>
<td>Uu^Uf</td>
<td>]</td>
<td>Mushroom Grove</td>
<td></td>
</tr>
<tr>
<td>Re^Uf</td>
<td></td>
<td>Mushroom Grove</td>
<td>Mushroom Grove</td>
</tr>
<tr>
<td>Uh</td>
<td>[</td>
<td>Rockbound Cave</td>
<td>Cave,Hills</td>
</tr>
<tr>
<td>Uh^Ii</td>
<td></td>
<td>Rockbound Cave Lit</td>
<td>Cave,Hills</td>
</tr>
<tr>
<td>Dd^Vda</td>
<td>U</td>
<td>Village</td>
<td>Village,Sand</td>
</tr>
<tr>
<td>Dd^Vdt</td>
<td>U</td>
<td>Village</td>
<td>Village,Sand</td>
</tr>
<tr>
<td>Aa^Vea</td>
<td>e</td>
<td>Village</td>
<td>Village</td>
</tr>
<tr>
<td>Gg^Ve</td>
<td>t</td>
<td>Village</td>
<td>Village</td>
</tr>
<tr>
<td>Aa^Vha</td>
<td>V</td>
<td>Village</td>
<td>Village</td>
</tr>
<tr>
<td>Gg^Vh</td>
<td>t</td>
<td>Village</td>
<td></td>
</tr>
<tr>
<td>Hh^Vhh</td>
<td>a</td>
<td>Village</td>
<td>Village,Hills</td>
</tr>
<tr>
<td>Ha^Vhha</td>
<td>A</td>
<td>Village</td>
<td>Village,Hills</td>
</tr>
<tr>
<td>Mm^Vhh</td>
<td>b</td>
<td>Village</td>
<td>Village,Mountains</td>
</tr>
<tr>
<td>Gs^Vht</td>
<td>L</td>
<td>Village</td>
<td>Village</td>
</tr>
<tr>
<td>Uu^Vu</td>
<td>D</td>
<td>Village</td>
<td>Village,Cave</td>
</tr>
<tr>
<td>Uu^Vud</td>
<td>p</td>
<td>Village</td>
<td>Village,Cave</td>
</tr>
<tr>
<td>Ww^Vm</td>
<td>Z</td>
<td>Village</td>
<td>Shallow Water</td>
</tr>
<tr>
<td>Ss^Vhs</td>
<td>Y</td>
<td>Village</td>
<td>Village,Swamp</td>
</tr>
<tr>
<td>Ss^Vm</td>
<td></td>
<td>Village</td>
<td>Swamp</td>
</tr>
<tr>
<td>Wo</td>
<td>s</td>
<td>Deep Water</td>
<td></td>
</tr>
<tr>
<td>Ww</td>
<td>c</td>
<td>Shallow Water</td>
<td></td>
</tr>
<tr>
<td>Wwf</td>
<td>k</td>
<td>River Ford</td>
<td>Grassland,Shallow Water</td>
</tr>
<tr>
<td>Mm^Xm</td>
<td>&</td>
<td>Impassable Mountains</td>
<td>Cave Wall</td>
</tr>
<tr>
<td>Md^Xm</td>
<td></td>
<td>Impassable Desert Mountains</td>
<td>Cave Wall</td>
</tr>
<tr>
<td>Xu</td>
<td>W</td>
<td>Cave Wall</td>
<td></td>
</tr>
<tr>
<td>Xv</td>
<td></td>
<td>Void</td>
<td>Cave Wall</td>
</tr>
</table>

== Adding terrains ==
When adding terrains make sure the following files are also checked:

data/faction/* contains favorite positions for the different factions, this is only used for the random map generator at the moment so it is not very important.

data/abilities.cfg contains the definition of ''submerge'' and ''ambush'' so depending on the change these need to be updated.

data/utils/utils.cfg contains the macro STARTING_VILLAGES which contains a list of village strings. This list doesn't support wildcards (yet).

== See Also ==
* [[TerrainWML]]
* [[ReferenceWML]]

[[Category: WML Reference]]

BuildingMaps

2007-10-30T16:52:23Z

Rhuvaen: added link to TerrainLettersWML

This is all you need to know about maps:

# A map is just a bunch of letters arranged in a rectangle (the rectangle is known as the "map data")
# There are two ways to save this rectangle in a file

Seriously now, here are the details.

== Wesnoth map data format ==

Map data is used to represent maps in Wesnoth. The encoding for maps has a specific format:

* A map data file consists of any number of lines, each with the same number of characters.
* Each character must be either a letter specified in a ''letter'' key specifying a terrain (see [[TerrainLettersWML]]), or a digit.
* When the file is interpreted, each letter will be replaced by the terrain it refers to.
* Each nonzero digit ''n'' where ''n'' = 1, 2, 3, ... will be replaced by keep, with the leader of side ''n'' placed on the keep.

Since text file tiles are squares while game tiles are hexes, some tiles must be shifted.
Tiles in even-numbered columns are shifted down 1/2 of a tile.
For example, to have a road of connected dirt ('r') tiles, the map data would look like this:

rrgggggg
ggrrgggg
ggggrrgg
ggggggrr

{{DevFeature}}

The map format for the new Wesnoth version has been changed so this description is for the newer version.

Map data is used to represent maps in Wesnoth. The encoding for maps has a specific format:

* A map starts with a header with the following keys
** usage, this is map for a 'map' and 'mask' for an overlay mask
** border_size, the size of the border, should be 1 for map and 0 for mask. When the border_size is 1 the map border is part of the map data, this means the user can define the border instead of the game taking a guess.
* Between the header and the data should be 1 empty line
* A map data file consists of any number of lines, each with the same number of strings.
* Each string must be a string specified in a ''string'' key specifying a terrain (see [[TerrainLettersWML]]).
* Each string may be padded with spaces or tabs and must be separated with a comma, except for the last string on a line this one may not have a comma.
* When the file is interpreted, each string will be replaced by the terrain it refers to.
* Empty lines are allowed before, after and between lines of characters, between lines is not advised.
* Terrains may be prefixed with a number followed by one space, these indicate the starting position for side ''n''. ''n'' = 1, 2, 3, ... 9 (more might work but is untested and unsupported). This is a change from the previous system where a starting position was automatically a keep.

It's advised to use spaces for padding and pad each column to be the same width; the game does this when writing a map file.

Since text file tiles are squares while game tiles are hexes, some tiles must be shifted.
Tiles in even-numbered columns are shifted down 1/2 of a tile.
For example, to have a road of connected dirt ('Re') tiles, the map data would look like this:

usage=map
border_size=1

Re, Re, Gg, Gg, Gg, Gg, Gg, Gg
Gg, Gg, Re, Re, Gg, Gg, Gg, Gg
Gg, Gg, Gg, Gg, Re, Re, Gg, Gg
Gg, Gg, Gg, Gg, Gg, Gg, Re, Re

== Creating a map ==

This is not the Matrix. You do not need to look at encoded maps. The source code and most binary distributions come with the official graphical map editor. When compiling from source, remember to use the ''--enable-editor'' option when configuring, otherwise the map editor won't be compiled. Using the map editor tends to be straightforward, judging from the feedback received from novice mapmakers. However, if you do encounter problems locating or using the editor, please ask for help on the [http://www.wesnoth.org/forum forum].

After the map is created, you may find it easier to make small tweaks by editing the textual map data directly.

Making good, balanced, interesting maps is another task altogether, and if someone wants to take a stab at sharing insight about this art, please do so.

== Using map data ==

Map data is used in two ways.
# It is used as an input to the key ''map_data'' (see [[ScenarioWML]]).
# Files consisting entirely of map data can be read and edited easily by the [[WesnothMapEditor]].
#* Files in the folder '''''userdata''/editor/maps/''' which consist entirely of map data can be played in multiplayer as user maps.

==== The map_data key ====

The first way is to use the map_data key. A campaign scenario starts with the '''[scenario]''' tag. A multiplayer map scenario starts with the '''[multiplayer]''' tag. Each tag takes the key ''map_data''. The value of the ''map_data'' key is the map data enclosed in quotes. Here is an example:
map_data="111111111111111111"

==== Standalone map file ====

The second way to store a map is in a text file that consists '''only''' of the map data. The advantage of this method is that it's simple. If you drop one of the map files in '''''userdata''/editor/maps/''', the game will find it automatically in multiplayer. On the other hand, this method also works with more complex scenarios. If there is a scenario file somewhere (campaign or multiplayer) that has a line similar to the following:
map_data="{@editor/''map_filename''}"
then all of the map data in the file is inserted between the quote marks.

== Discussion: Scenario File vs Standalone ==

Campaign writers can't write campaigns without scenarios, so campaigns will always use the ''map_data'' key, either with the raw data in quotes or a preprocessor symbol {} pointing to the standalone file.

Multiplayer mapmakers, however, '''have a choice'''. If you want to place an object or unit on the map, you must create a scenario file starting with the '''[multiplayer]''' tag and containing the ''map_data'' key therein. You lose the simplicity of the standalone map file, but you gain tremendous power. Not only can you add units and objects, you can set allies, experience modifiers, add a map description, and add custom events (among other things). The question, "How do I place an object on the map with the map editor" is such a common question that I am sorry this information is buried so deeply here. But, now that you know you can seek out an example of a multiplayer map scenario file to use as an example. The game comes with many maps of each type. Check out [[BuildingMultiplayer]] for more information.

== See Also ==

* [[Create]]
* [[ScenarioWML]]
* [[ReferenceWML]]
* [[BuildingScenariosShroudData]]
* [[TerrainLettersWML]]

{{Create}}

MultiplayerContent

2007-09-27T22:55:57Z

Rhuvaen: added version relevance and removed bug tracker link

'''Multiplayer campaigns are working again in versions 1.3.5+''', they are broken in both stable and development versions of Wesnoth prior to 1.x.5. Check the [http://www.wesnoth.org/forum/viewtopic.php?t=11349 forums] for more information.

== Building multiplayer campaigns ==

Both the stable and development versions of wesnoth have basic support for campaigns that can be played in multiplayer mode, with your friends, or even with an AI. Since version 1.1.8, more features and support have been added so we recommend a versions 1.1.8+. There will still be some things that don't work as expected as multiplayer campaigns are an area for exploration. While you can and should test your work in hotseat mode, there are a number of things that might behave differently under real network conditions (mostly affecting scenario and side parameters). Keep this in mind and make sure to test your campaign over the net, too.
This page only documents the differences between writing multiplayer campaigns and single player campaigns, so you might want to read up on [[BuildingCampaigns]] and [[BuildingMultiplayer]] first.

=== The campaign file ===

Multiplayer campaigns do not use the [campaign] tag. As a result of this, multiplayer campaigns only support one difficulty level, though you could support more with enough WML, if you're feeling ambitious. The "campaign file" should look something like this:

#ifdef MULTIPLAYER
{@campaigns/My_Campaign/scenarios}
#endif

Anything that you would normally put in the campaign tag now goes into the first scenario, if it's supported there. The order of scenarios is determined by next_scenario tags, just like in single player.

=== Scenarios ===

A scenario in a multiplayer campaign is almost identical to a scenario in a single player campaign. You only need to change the following:

* The [scenario] tag should be replaced with a [multiplayer] tag.
* The '''next_scenario''' key points to the id of the next scenario.
* Every scenario after the first should have '''allow_new_game=no''' inside the [multiplayer] tag. This will prevent it from showing up in the map selection menu. ''This does not work in v1.1'', but it causes no harm, and it will work in the future. ''(This still doesn't work in 1.2.2, and even prevents your campaign from working. I suggest you leave this commented out until the bug gets fixed.)''
* In v1.1, every scenario in the campaign will appear on the map selection menu, so be sure to include your campaign's name in the [multiplayer] tag's name key. Alternatively, include a warning like "DO NOT PLAY".
* Each human-controlled side needs to have a '''controller=human''' key defined in their [side] tag to work in network mode.
* Each human-controlled side also needs to have a '''save_id''' defined inside their [side] tag. Each side's save_id should be unique, and it should be the same in every scenario. Without this, your recall lists and leaders will not carry over from one scenario to the next.
* Each human-controlled side has to have a leader '''type=''' definition in every scenario except the first one . It doesn't matter which type you choose cause the type set here gets replaced by the actual leader in the recall list.
* Each AI-controlled side should have '''allow_player=no''' in their [side] tag.
* The [story] tag will only display for the first player (or maybe it's the host player). You'll have to use [message] tags in the start event if you want everyone to read the story.
* If you have a file containing macros, it must be referenced by every scenario, since there is no proper campaign file to include it from.

=== The first scenario ===

The first scenario might need some extra work, because the settings from the multiplayer dialog will override the settings in the scenario. However, most of the multiplayer settings can be overridden in the prestart event.

Use a macro like this to force a side to have a particular type of leader.
#define MP_SIDE SIDENO TYPE DESC
[store_unit]
variable=oldunit
kill=yes
[filter]
side={SIDENO}
[/filter]
[/store_unit]

[unit]
type={TYPE}
description={DESC}
unrenameable=yes
side={SIDENO}
x,y=$oldunit.x,$oldunit.y
canrecruit=1
[/unit]

[clear_variable]
name=oldunit
[/clear_variable]
#enddef

Other useful tags include [set_recruit], [modify_side], [modify_turns] and [remove_shroud]. There is currently no way to remove fog. You might also want to use ''experience_modifier=100'' in the [multiplayer] tag.

=== Custom units ===

Since there is no [campaign] tag, there is no natural way to include custom units in a multiplayer campaign. However, there are two workarounds. One way is to use [[EffectWML]] or [store_unit] to modify a mainline unit. The other way is to make your custom units available via an [[EraWML|era]], or by dropping them into ~wesnoth/data/units. If you go this route, using an era is better, because you can keep the units in your campaign directory.

== Current Bugs ==
This information is current for version 1.3.8.

=== linger mode introduces a bug ===
You can completely circumvent this problem as a host if you tell your players to leave linger mode (by clicking "end turn") before you do so. Only if the host leaves linger mode last will the game progress with all players. The download of the next scenario will not start before the host ends linger mode (but it will be at 0% downloaded), so an impatient player may be inclined to abort the game beforehand. Inform your players.

=== OOS on recalls ===
All observers will get OOS on the second and following scenarios. Giving an observer control of a player side will not allow that player to recall. You need to [i]save and reload[/i] if you need to hand control to an observer.

=== [story] is unavailable over the net ===
All your carefully crafted [story] information is not available to players who haven't downloaded your content. It's thus not a reliable way to share the story with all players.

=== allow_new_game=no ===
Still doesn't work properly. I recommend not using this right now.

== See Also ==

* [http://www.wesnoth.org/forum/viewtopic.php?t=11349 Multiplayer Campaigns HOWTO forum post]
* [[BuildingScenarios]]
* [[BuildingMultiplayer]]

MultiplayerContent

2007-09-27T22:54:19Z

Rhuvaen:

'''Multiplayer campaigns are working again in versions 1.3.5+''', they are broken in both stable and development versions of Wesnoth prior to 1.x.5. Check the [http://www.wesnoth.org/forum/viewtopic.php?t=11349 forums] or [https://gna.org/bugs/index.php?9242 bug tracker] for more information.

== Building multiplayer campaigns ==

Both the stable and development versions of wesnoth have basic support for campaigns that can be played in multiplayer mode, with your friends, or even with an AI. Since version 1.1.8, more features and support have been added so we recommend a versions 1.1.8+. There will still be some things that don't work as expected as multiplayer campaigns are an area for exploration. While you can and should test your work in hotseat mode, there are a number of things that might behave differently under real network conditions (mostly affecting scenario and side parameters). Keep this in mind and make sure to test your campaign over the net, too.
This page only documents the differences between writing multiplayer campaigns and single player campaigns, so you might want to read up on [[BuildingCampaigns]] and [[BuildingMultiplayer]] first.

=== The campaign file ===

Multiplayer campaigns do not use the [campaign] tag. As a result of this, multiplayer campaigns only support one difficulty level, though you could support more with enough WML, if you're feeling ambitious. The "campaign file" should look something like this:

#ifdef MULTIPLAYER
{@campaigns/My_Campaign/scenarios}
#endif

Anything that you would normally put in the campaign tag now goes into the first scenario, if it's supported there. The order of scenarios is determined by next_scenario tags, just like in single player.

=== Scenarios ===

A scenario in a multiplayer campaign is almost identical to a scenario in a single player campaign. You only need to change the following:

* The [scenario] tag should be replaced with a [multiplayer] tag.
* The '''next_scenario''' key points to the id of the next scenario.
* Every scenario after the first should have '''allow_new_game=no''' inside the [multiplayer] tag. This will prevent it from showing up in the map selection menu. ''This does not work in v1.1'', but it causes no harm, and it will work in the future. ''(This still doesn't work in 1.2.2, and even prevents your campaign from working. I suggest you leave this commented out until the bug gets fixed.)''
* In v1.1, every scenario in the campaign will appear on the map selection menu, so be sure to include your campaign's name in the [multiplayer] tag's name key. Alternatively, include a warning like "DO NOT PLAY".
* Each human-controlled side needs to have a '''controller=human''' key defined in their [side] tag to work in network mode.
* Each human-controlled side also needs to have a '''save_id''' defined inside their [side] tag. Each side's save_id should be unique, and it should be the same in every scenario. Without this, your recall lists and leaders will not carry over from one scenario to the next.
* Each human-controlled side has to have a leader '''type=''' definition in every scenario except the first one . It doesn't matter which type you choose cause the type set here gets replaced by the actual leader in the recall list.
* Each AI-controlled side should have '''allow_player=no''' in their [side] tag.
* The [story] tag will only display for the first player (or maybe it's the host player). You'll have to use [message] tags in the start event if you want everyone to read the story.
* If you have a file containing macros, it must be referenced by every scenario, since there is no proper campaign file to include it from.

=== The first scenario ===

The first scenario might need some extra work, because the settings from the multiplayer dialog will override the settings in the scenario. However, most of the multiplayer settings can be overridden in the prestart event.

Use a macro like this to force a side to have a particular type of leader.
#define MP_SIDE SIDENO TYPE DESC
[store_unit]
variable=oldunit
kill=yes
[filter]
side={SIDENO}
[/filter]
[/store_unit]

[unit]
type={TYPE}
description={DESC}
unrenameable=yes
side={SIDENO}
x,y=$oldunit.x,$oldunit.y
canrecruit=1
[/unit]

[clear_variable]
name=oldunit
[/clear_variable]
#enddef

Other useful tags include [set_recruit], [modify_side], [modify_turns] and [remove_shroud]. There is currently no way to remove fog. You might also want to use ''experience_modifier=100'' in the [multiplayer] tag.

=== Custom units ===

Since there is no [campaign] tag, there is no natural way to include custom units in a multiplayer campaign. However, there are two workarounds. One way is to use [[EffectWML]] or [store_unit] to modify a mainline unit. The other way is to make your custom units available via an [[EraWML|era]], or by dropping them into ~wesnoth/data/units. If you go this route, using an era is better, because you can keep the units in your campaign directory.

== Current Bugs ==
=== linger mode introduces a bug ===
You can completely circumvent this problem as a host if you tell your players to leave linger mode (by clicking "end turn") before you do so. Only if the host leaves linger mode last will the game progress with all players. The download of the next scenario will not start before the host ends linger mode (but it will be at 0% downloaded), so an impatient player may be inclined to abort the game beforehand. Inform your players.

=== OOS on recalls ===
All observers will get OOS on the second and following scenarios. Giving an observer control of a player side will not allow that player to recall. You need to [i]save and reload[/i] if you need to hand control to an observer.

=== [story] is unavailable over the net ===
All your carefully crafted [story] information is not available to players who haven't downloaded your content. It's thus not a reliable way to share the story with all players.

=== allow_new_game=no ===
Still doesn't work properly. I recommend not using this right now.

Also check out the [http://www.wesnoth.org/forum/viewtopic.php?t=11349 Multiplayer Campaigns HOWTO forum post] (I'm trying to keep this page and the forum post in sync, but won't guarantee it is at all times).

== See Also ==

* [http://www.wesnoth.org/forum/viewtopic.php?t=11349 Multiplayer Campaigns HOWTO forum post]
* [[BuildingScenarios]]
* [[BuildingMultiplayer]]

MultiplayerContent

2007-09-27T22:52:39Z

Rhuvaen: /* Current Bugs */

'''Multiplayer campaigns are working again in versions 1.3.5+''', they are broken in both stable and development versions of Wesnoth prior to 1.x.5. Check the [http://www.wesnoth.org/forum/viewtopic.php?t=11349 forums] or [https://gna.org/bugs/index.php?9242 bug tracker] for more information.

== Building multiplayer campaigns ==

Both the stable and development versions of wesnoth have basic support for campaigns that can be played in multiplayer mode, with your friends, or even with an AI. Since version 1.1.8, more features and support have been added so we recommend a versions 1.1.8+. There will still be some things that don't work as expected as multiplayer campaigns are an area for exploration. While you can and should test your work in hotseat mode, there are a number of things that might behave differently under real network conditions (mostly affecting scenario and side parameters). Keep this in mind and make sure to test your campaign over the net, too.
This page only documents the differences between writing multiplayer campaigns and single player campaigns, so you might want to read up on [[BuildingCampaigns]] and [[BuildingMultiplayer]] first.

=== The campaign file ===

Multiplayer campaigns do not use the [campaign] tag. As a result of this, multiplayer campaigns only support one difficulty level, though you could support more with enough WML, if you're feeling ambitious. The "campaign file" should look something like this:

#ifdef MULTIPLAYER
{@campaigns/My_Campaign/scenarios}
#endif

Anything that you would normally put in the campaign tag now goes into the first scenario, if it's supported there. The order of scenarios is determined by next_scenario tags, just like in single player.

=== Scenarios ===

A scenario in a multiplayer campaign is almost identical to a scenario in a single player campaign. You only need to change the following:

* The [scenario] tag should be replaced with a [multiplayer] tag.
* The '''next_scenario''' key points to the id of the next scenario.
* Every scenario after the first should have '''allow_new_game=no''' inside the [multiplayer] tag. This will prevent it from showing up in the map selection menu. ''This does not work in v1.1'', but it causes no harm, and it will work in the future. ''(This still doesn't work in 1.2.2, and even prevents your campaign from working. I suggest you leave this commented out until the bug gets fixed.)''
* In v1.1, every scenario in the campaign will appear on the map selection menu, so be sure to include your campaign's name in the [multiplayer] tag's name key. Alternatively, include a warning like "DO NOT PLAY".
* Each human-controlled side needs to have a '''controller=human''' key defined in their [side] tag to work in network mode.
* Each human-controlled side also needs to have a '''save_id''' defined inside their [side] tag. Each side's save_id should be unique, and it should be the same in every scenario. Without this, your recall lists and leaders will not carry over from one scenario to the next.
* Each human-controlled side has to have a leader '''type=''' definition in every scenario except the first one . It doesn't matter which type you choose cause the type set here gets replaced by the actual leader in the recall list.
* Each AI-controlled side should have '''allow_player=no''' in their [side] tag.
* The [story] tag will only display for the first player (or maybe it's the host player). You'll have to use [message] tags in the start event if you want everyone to read the story.
* If you have a file containing macros, it must be referenced by every scenario, since there is no proper campaign file to include it from.

=== The first scenario ===

The first scenario might need some extra work, because the settings from the multiplayer dialog will override the settings in the scenario. However, most of the multiplayer settings can be overridden in the prestart event.

Use a macro like this to force a side to have a particular type of leader.
#define MP_SIDE SIDENO TYPE DESC
[store_unit]
variable=oldunit
kill=yes
[filter]
side={SIDENO}
[/filter]
[/store_unit]

[unit]
type={TYPE}
description={DESC}
unrenameable=yes
side={SIDENO}
x,y=$oldunit.x,$oldunit.y
canrecruit=1
[/unit]

[clear_variable]
name=oldunit
[/clear_variable]
#enddef

Other useful tags include [set_recruit], [modify_side], [modify_turns] and [remove_shroud]. There is currently no way to remove fog. You might also want to use ''experience_modifier=100'' in the [multiplayer] tag.

=== Custom units ===

Since there is no [campaign] tag, there is no natural way to include custom units in a multiplayer campaign. However, there are two workarounds. One way is to use [[EffectWML]] or [store_unit] to modify a mainline unit. The other way is to make your custom units available via an [[EraWML|era]], or by dropping them into ~wesnoth/data/units. If you go this route, using an era is better, because you can keep the units in your campaign directory.

== Current Bugs ==
=== linger mode introduces a bug ===
You can completely circumvent this problem as a host if you tell your players to leave linger mode (by clicking "end turn") before you do so. Only if the host leaves linger mode last will the game progress with all players. The download of the next scenario will not start before the host ends linger mode (but it will be at 0% downloaded), so an impatient player may be inclined to abort the game beforehand. Inform your players.

=== OOS on recalls ===
All observers will get OOS on the second and following scenarios. Giving an observer control of a player side will not allow that player to recall. You need to [i]save and reload[/i] if you need to hand control to an observer.

=== [story] is unavailable over the net ===
All your carefully crafted [story] information is not available to players who haven't downloaded your content. It's thus not a reliable way to share the story with all players.

=== allow_new_game=no ===
Still doesn't work properly. I recommend not using this right now.

== See Also ==

* [http://www.wesnoth.org/forum/viewtopic.php?t=11349 Multiplayer Campaigns HOWTO forum post]
* [[BuildingScenarios]]
* [[BuildingMultiplayer]]

MultiplayerContent

2007-09-27T22:34:13Z

Rhuvaen: /* Current Bugs */ corrected thread number

'''Multiplayer campaigns are working again in versions 1.3.5+''', they are broken in both stable and development versions of Wesnoth prior to 1.x.5. Check the [http://www.wesnoth.org/forum/viewtopic.php?t=11349 forums] or [https://gna.org/bugs/index.php?9242 bug tracker] for more information.

== Building multiplayer campaigns ==

Both the stable and development versions of wesnoth have basic support for campaigns that can be played in multiplayer mode, with your friends, or even with an AI. Since version 1.1.8, more features and support have been added so we recommend a versions 1.1.8+. There will still be some things that don't work as expected as multiplayer campaigns are an area for exploration. While you can and should test your work in hotseat mode, there are a number of things that might behave differently under real network conditions (mostly affecting scenario and side parameters). Keep this in mind and make sure to test your campaign over the net, too.
This page only documents the differences between writing multiplayer campaigns and single player campaigns, so you might want to read up on [[BuildingCampaigns]] and [[BuildingMultiplayer]] first.

=== The campaign file ===

Multiplayer campaigns do not use the [campaign] tag. As a result of this, multiplayer campaigns only support one difficulty level, though you could support more with enough WML, if you're feeling ambitious. The "campaign file" should look something like this:

#ifdef MULTIPLAYER
{@campaigns/My_Campaign/scenarios}
#endif

Anything that you would normally put in the campaign tag now goes into the first scenario, if it's supported there. The order of scenarios is determined by next_scenario tags, just like in single player.

=== Scenarios ===

A scenario in a multiplayer campaign is almost identical to a scenario in a single player campaign. You only need to change the following:

* The [scenario] tag should be replaced with a [multiplayer] tag.
* The '''next_scenario''' key points to the id of the next scenario.
* Every scenario after the first should have '''allow_new_game=no''' inside the [multiplayer] tag. This will prevent it from showing up in the map selection menu. ''This does not work in v1.1'', but it causes no harm, and it will work in the future. ''(This still doesn't work in 1.2.2, and even prevents your campaign from working. I suggest you leave this commented out until the bug gets fixed.)''
* In v1.1, every scenario in the campaign will appear on the map selection menu, so be sure to include your campaign's name in the [multiplayer] tag's name key. Alternatively, include a warning like "DO NOT PLAY".
* Each human-controlled side needs to have a '''controller=human''' key defined in their [side] tag to work in network mode.
* Each human-controlled side also needs to have a '''save_id''' defined inside their [side] tag. Each side's save_id should be unique, and it should be the same in every scenario. Without this, your recall lists and leaders will not carry over from one scenario to the next.
* Each human-controlled side has to have a leader '''type=''' definition in every scenario except the first one . It doesn't matter which type you choose cause the type set here gets replaced by the actual leader in the recall list.
* Each AI-controlled side should have '''allow_player=no''' in their [side] tag.
* The [story] tag will only display for the first player (or maybe it's the host player). You'll have to use [message] tags in the start event if you want everyone to read the story.
* If you have a file containing macros, it must be referenced by every scenario, since there is no proper campaign file to include it from.

=== The first scenario ===

The first scenario might need some extra work, because the settings from the multiplayer dialog will override the settings in the scenario. However, most of the multiplayer settings can be overridden in the prestart event.

Use a macro like this to force a side to have a particular type of leader.
#define MP_SIDE SIDENO TYPE DESC
[store_unit]
variable=oldunit
kill=yes
[filter]
side={SIDENO}
[/filter]
[/store_unit]

[unit]
type={TYPE}
description={DESC}
unrenameable=yes
side={SIDENO}
x,y=$oldunit.x,$oldunit.y
canrecruit=1
[/unit]

[clear_variable]
name=oldunit
[/clear_variable]
#enddef

Other useful tags include [set_recruit], [modify_side], [modify_turns] and [remove_shroud]. There is currently no way to remove fog. You might also want to use ''experience_modifier=100'' in the [multiplayer] tag.

=== Custom units ===

Since there is no [campaign] tag, there is no natural way to include custom units in a multiplayer campaign. However, there are two workarounds. One way is to use [[EffectWML]] or [store_unit] to modify a mainline unit. The other way is to make your custom units available via an [[EraWML|era]], or by dropping them into ~wesnoth/data/units. If you go this route, using an era is better, because you can keep the units in your campaign directory.

== Current Bugs ==
Check out the [http://www.wesnoth.org/forum/viewtopic.php?t=16572 announcement on current MP campaign bugs].

== See Also ==

* [http://www.wesnoth.org/forum/viewtopic.php?t=11349 Multiplayer Campaigns HOWTO forum post]
* [[BuildingScenarios]]
* [[BuildingMultiplayer]]

MultiplayerContent

2007-09-27T22:33:44Z

Rhuvaen: added a link to the current bug forum thread

'''Multiplayer campaigns are working again in versions 1.3.5+''', they are broken in both stable and development versions of Wesnoth prior to 1.x.5. Check the [http://www.wesnoth.org/forum/viewtopic.php?t=11349 forums] or [https://gna.org/bugs/index.php?9242 bug tracker] for more information.

== Building multiplayer campaigns ==

Both the stable and development versions of wesnoth have basic support for campaigns that can be played in multiplayer mode, with your friends, or even with an AI. Since version 1.1.8, more features and support have been added so we recommend a versions 1.1.8+. There will still be some things that don't work as expected as multiplayer campaigns are an area for exploration. While you can and should test your work in hotseat mode, there are a number of things that might behave differently under real network conditions (mostly affecting scenario and side parameters). Keep this in mind and make sure to test your campaign over the net, too.
This page only documents the differences between writing multiplayer campaigns and single player campaigns, so you might want to read up on [[BuildingCampaigns]] and [[BuildingMultiplayer]] first.

=== The campaign file ===

Multiplayer campaigns do not use the [campaign] tag. As a result of this, multiplayer campaigns only support one difficulty level, though you could support more with enough WML, if you're feeling ambitious. The "campaign file" should look something like this:

#ifdef MULTIPLAYER
{@campaigns/My_Campaign/scenarios}
#endif

Anything that you would normally put in the campaign tag now goes into the first scenario, if it's supported there. The order of scenarios is determined by next_scenario tags, just like in single player.

=== Scenarios ===

A scenario in a multiplayer campaign is almost identical to a scenario in a single player campaign. You only need to change the following:

* The [scenario] tag should be replaced with a [multiplayer] tag.
* The '''next_scenario''' key points to the id of the next scenario.
* Every scenario after the first should have '''allow_new_game=no''' inside the [multiplayer] tag. This will prevent it from showing up in the map selection menu. ''This does not work in v1.1'', but it causes no harm, and it will work in the future. ''(This still doesn't work in 1.2.2, and even prevents your campaign from working. I suggest you leave this commented out until the bug gets fixed.)''
* In v1.1, every scenario in the campaign will appear on the map selection menu, so be sure to include your campaign's name in the [multiplayer] tag's name key. Alternatively, include a warning like "DO NOT PLAY".
* Each human-controlled side needs to have a '''controller=human''' key defined in their [side] tag to work in network mode.
* Each human-controlled side also needs to have a '''save_id''' defined inside their [side] tag. Each side's save_id should be unique, and it should be the same in every scenario. Without this, your recall lists and leaders will not carry over from one scenario to the next.
* Each human-controlled side has to have a leader '''type=''' definition in every scenario except the first one . It doesn't matter which type you choose cause the type set here gets replaced by the actual leader in the recall list.
* Each AI-controlled side should have '''allow_player=no''' in their [side] tag.
* The [story] tag will only display for the first player (or maybe it's the host player). You'll have to use [message] tags in the start event if you want everyone to read the story.
* If you have a file containing macros, it must be referenced by every scenario, since there is no proper campaign file to include it from.

=== The first scenario ===

The first scenario might need some extra work, because the settings from the multiplayer dialog will override the settings in the scenario. However, most of the multiplayer settings can be overridden in the prestart event.

Use a macro like this to force a side to have a particular type of leader.
#define MP_SIDE SIDENO TYPE DESC
[store_unit]
variable=oldunit
kill=yes
[filter]
side={SIDENO}
[/filter]
[/store_unit]

[unit]
type={TYPE}
description={DESC}
unrenameable=yes
side={SIDENO}
x,y=$oldunit.x,$oldunit.y
canrecruit=1
[/unit]

[clear_variable]
name=oldunit
[/clear_variable]
#enddef

Other useful tags include [set_recruit], [modify_side], [modify_turns] and [remove_shroud]. There is currently no way to remove fog. You might also want to use ''experience_modifier=100'' in the [multiplayer] tag.

=== Custom units ===

Since there is no [campaign] tag, there is no natural way to include custom units in a multiplayer campaign. However, there are two workarounds. One way is to use [[EffectWML]] or [store_unit] to modify a mainline unit. The other way is to make your custom units available via an [[EraWML|era]], or by dropping them into ~wesnoth/data/units. If you go this route, using an era is better, because you can keep the units in your campaign directory.

== Current Bugs ==
Check out the [http://www.wesnoth.org/forum/viewtopic.php?t=11349 announcement on current MP campaign bugs].

== See Also ==

* [http://www.wesnoth.org/forum/viewtopic.php?t=11349 Multiplayer Campaigns HOWTO forum post]
* [[BuildingScenarios]]
* [[BuildingMultiplayer]]

EventWML

2007-09-15T19:23:45Z

Rhuvaen: /* 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 its 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 refresh'' [[DevFeature|(1.3.8 or SVN trunk only)]] this event triggers just before a side is taking control after healing, calculating income, and restoring unit movement and status. Does not trigger on the first 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 side. This is called after ''side turn'', and thus the WML variable '''side_number''' still holds the number of this side.
<br>

Filters can be applied to the following event triggers (see [[FilterWML]]; see also below). The actions specified in the event tag will be executed only if the filter returns true.
These event triggers are all actions by units (''moveto'', ''attack'') or things that happen to units (''recruit'', ''advance''). When one of these events is triggered, the position of the active unit (referred to as ''primary_unit'') is stored in the variables 'x1' and 'y1' and the position of any unit that ''primary_unit'' does something to is stored in the variables 'x2' and 'y2' (this unit is referred to as ''secondary_unit'' below). '' {{DevFeature}} These units are stored in the variables 'unit' and 'second_unit' as if they had been stored using the '''[store_unit]''' tag. see [[SingleUnitWML]]<br><br>

* ''moveto'' triggers after ''primary_unit'' moves. Typically this is used when ''primary_unit'' gets to a particular location and a filter for the location of ''primary_unit'' is included; 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'' {{DevFeature}} 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. ''Note: in networked multiplayer, these events are only executed by the client on which the event is triggered, leading to out of sync errors if you modify the game state in the event.''
* ''menu item X'' triggers when a WML menu item with id=X is selected. ''Note: if the menu item has a [command], this event may be executed before or after the command; there is no guarantee.''
<br>
An '''[allow_undo]''' tag anywhere within a moveto event will cancel any lack of undo functionality the event would have caused. Note that undo functionality will only move the unit back to its former location; it will not other changes to the game caused by the event. Thus it is up to the scenario designer to use this tag correctly. Note that '''[allow_undo]''' does not work within '''[if]''' tags, and that it causes out-of-sync errors in multiplayer games; check [[DirectActionsWML]] for the details.
</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]]

EventWML

2007-09-15T19:22:37Z

Rhuvaen: /* 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 its 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 refresh'' [[DevFeature|(1.3.8 or SVN only)]] this event triggers just before a side is taking control after healing, calculating income, and restoring unit movement and status. Does not trigger on the first 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 side. This is called after ''side turn'', and thus the WML variable '''side_number''' still holds the number of this side.
<br>

Filters can be applied to the following event triggers (see [[FilterWML]]; see also below). The actions specified in the event tag will be executed only if the filter returns true.
These event triggers are all actions by units (''moveto'', ''attack'') or things that happen to units (''recruit'', ''advance''). When one of these events is triggered, the position of the active unit (referred to as ''primary_unit'') is stored in the variables 'x1' and 'y1' and the position of any unit that ''primary_unit'' does something to is stored in the variables 'x2' and 'y2' (this unit is referred to as ''secondary_unit'' below). '' {{DevFeature}} These units are stored in the variables 'unit' and 'second_unit' as if they had been stored using the '''[store_unit]''' tag. see [[SingleUnitWML]]<br><br>

* ''moveto'' triggers after ''primary_unit'' moves. Typically this is used when ''primary_unit'' gets to a particular location and a filter for the location of ''primary_unit'' is included; 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'' {{DevFeature}} 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. ''Note: in networked multiplayer, these events are only executed by the client on which the event is triggered, leading to out of sync errors if you modify the game state in the event.''
* ''menu item X'' triggers when a WML menu item with id=X is selected. ''Note: if the menu item has a [command], this event may be executed before or after the command; there is no guarantee.''
<br>
An '''[allow_undo]''' tag anywhere within a moveto event will cancel any lack of undo functionality the event would have caused. Note that undo functionality will only move the unit back to its former location; it will not other changes to the game caused by the event. Thus it is up to the scenario designer to use this tag correctly. Note that '''[allow_undo]''' does not work within '''[if]''' tags, and that it causes out-of-sync errors in multiplayer games; check [[DirectActionsWML]] for the details.
</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]]

EventWML

2007-09-15T19:21:56Z

Rhuvaen:

{{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 its 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 refresh'' [[(1.3.8 or SVN only)|DevFeature]] this event triggers just before a side is taking control after healing, calculating income, and restoring unit movement and status. Does not trigger on the first 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 side. This is called after ''side turn'', and thus the WML variable '''side_number''' still holds the number of this side.
<br>

Filters can be applied to the following event triggers (see [[FilterWML]]; see also below). The actions specified in the event tag will be executed only if the filter returns true.
These event triggers are all actions by units (''moveto'', ''attack'') or things that happen to units (''recruit'', ''advance''). When one of these events is triggered, the position of the active unit (referred to as ''primary_unit'') is stored in the variables 'x1' and 'y1' and the position of any unit that ''primary_unit'' does something to is stored in the variables 'x2' and 'y2' (this unit is referred to as ''secondary_unit'' below). '' {{DevFeature}} These units are stored in the variables 'unit' and 'second_unit' as if they had been stored using the '''[store_unit]''' tag. see [[SingleUnitWML]]<br><br>

* ''moveto'' triggers after ''primary_unit'' moves. Typically this is used when ''primary_unit'' gets to a particular location and a filter for the location of ''primary_unit'' is included; 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'' {{DevFeature}} 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. ''Note: in networked multiplayer, these events are only executed by the client on which the event is triggered, leading to out of sync errors if you modify the game state in the event.''
* ''menu item X'' triggers when a WML menu item with id=X is selected. ''Note: if the menu item has a [command], this event may be executed before or after the command; there is no guarantee.''
<br>
An '''[allow_undo]''' tag anywhere within a moveto event will cancel any lack of undo functionality the event would have caused. Note that undo functionality will only move the unit back to its former location; it will not other changes to the game caused by the event. Thus it is up to the scenario designer to use this tag correctly. Note that '''[allow_undo]''' does not work within '''[if]''' tags, and that it causes out-of-sync errors in multiplayer games; check [[DirectActionsWML]] for the details.
</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]]

EventWML

2007-09-15T19:18:26Z

Rhuvaen: added info to turn refresh

{{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 its 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 refresh'' {{DevFeature}} this event triggers just before a side is taking control after healing, calculating income, and restoring unit movement and status. Does not trigger on the first 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 side. This is called after ''side turn'', and thus the WML variable '''side_number''' still holds the number of this side.
<br>

Filters can be applied to the following event triggers (see [[FilterWML]]; see also below). The actions specified in the event tag will be executed only if the filter returns true.
These event triggers are all actions by units (''moveto'', ''attack'') or things that happen to units (''recruit'', ''advance''). When one of these events is triggered, the position of the active unit (referred to as ''primary_unit'') is stored in the variables 'x1' and 'y1' and the position of any unit that ''primary_unit'' does something to is stored in the variables 'x2' and 'y2' (this unit is referred to as ''secondary_unit'' below). '' {{DevFeature}} These units are stored in the variables 'unit' and 'second_unit' as if they had been stored using the '''[store_unit]''' tag. see [[SingleUnitWML]]<br><br>

* ''moveto'' triggers after ''primary_unit'' moves. Typically this is used when ''primary_unit'' gets to a particular location and a filter for the location of ''primary_unit'' is included; 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'' {{DevFeature}} 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. ''Note: in networked multiplayer, these events are only executed by the client on which the event is triggered, leading to out of sync errors if you modify the game state in the event.''
* ''menu item X'' triggers when a WML menu item with id=X is selected. ''Note: if the menu item has a [command], this event may be executed before or after the command; there is no guarantee.''
<br>
An '''[allow_undo]''' tag anywhere within a moveto event will cancel any lack of undo functionality the event would have caused. Note that undo functionality will only move the unit back to its former location; it will not other changes to the game caused by the event. Thus it is up to the scenario designer to use this tag correctly. Note that '''[allow_undo]''' does not work within '''[if]''' tags, and that it causes out-of-sync errors in multiplayer games; check [[DirectActionsWML]] for the details.
</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]]

EventWML

2007-09-15T18:33:22Z

Rhuvaen: added 'turn refresh' event

{{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 its 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 refresh'' {{DevFeature}} this event triggers just before a side is taking control after healing, calculating income, and restoring unit movement and status.
* ''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 side. This is called after ''side turn'', and thus the WML variable '''side_number''' still holds the number of this side.
<br>

Filters can be applied to the following event triggers (see [[FilterWML]]; see also below). The actions specified in the event tag will be executed only if the filter returns true.
These event triggers are all actions by units (''moveto'', ''attack'') or things that happen to units (''recruit'', ''advance''). When one of these events is triggered, the position of the active unit (referred to as ''primary_unit'') is stored in the variables 'x1' and 'y1' and the position of any unit that ''primary_unit'' does something to is stored in the variables 'x2' and 'y2' (this unit is referred to as ''secondary_unit'' below). '' {{DevFeature}} These units are stored in the variables 'unit' and 'second_unit' as if they had been stored using the '''[store_unit]''' tag. see [[SingleUnitWML]]<br><br>

* ''moveto'' triggers after ''primary_unit'' moves. Typically this is used when ''primary_unit'' gets to a particular location and a filter for the location of ''primary_unit'' is included; 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'' {{DevFeature}} 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. ''Note: in networked multiplayer, these events are only executed by the client on which the event is triggered, leading to out of sync errors if you modify the game state in the event.''
* ''menu item X'' triggers when a WML menu item with id=X is selected. ''Note: if the menu item has a [command], this event may be executed before or after the command; there is no guarantee.''
<br>
An '''[allow_undo]''' tag anywhere within a moveto event will cancel any lack of undo functionality the event would have caused. Note that undo functionality will only move the unit back to its former location; it will not other changes to the game caused by the event. Thus it is up to the scenario designer to use this tag correctly. Note that '''[allow_undo]''' does not work within '''[if]''' tags, and that it causes out-of-sync errors in multiplayer games; check [[DirectActionsWML]] for the details.
</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:Rhuvaen

2007-08-20T10:27:12Z

Rhuvaen: /* Dark Forecast (Multiplayer Random Survival)(version 1.3.3+) */

I like trying new ideas with WML for '''multiplayer Wesnoth''', and here's a collection of links to things I've made. Some of those could be made into something better with a lot more polish, but it takes a lot of time writing and testing the WML.

If you find any of these aren't working with today's version of Wesnoth and you would like to play them, then contact me about it.

== MP Generator Pack (version 0.8 - today) ==
The random generator is a clumsy tool. I was dissatisfied with the unbalanced maps of clumped terrain that I got with the packaged generator scenarios, so I made these - WML files that break and mix the terrains a bit more. Made in the 0.8 days but still working today.

As a second idea, I used tournament-style maps often found in 2v2 and 1v1 play, made a "template" from those maps specifying which terrains should get randomised and applied that template over the generator. The result is tournament maps which have their terrain randomised somewhat.

It's all in the [http://www.wesnoth.org/forum/viewtopic.php?t=4559 MP Generator Pack]

== Random Tiled Maps (version 0.9 - today) ==
These are maps using the PSEUDORANDOM WML function to apply pre-designed "Tiles" (i.e. map pieces) to a map, replacing many hexes at once. The result is still random, while the "tiles" are actually designed by hand. Sometime in version 0.9, the code was changed to use the [terrain_mask] functionality, which was a great aid here.

I only made one scenario to date as a proof-of-concept, but this is definitely an idea I need to come back to! I have already worked on a generalised tile-based map generator, and plan to use it to make a random dungeon scenario one day.
[http://www.wesnoth.org/forum/viewtopic.php?t=6139 Random Tiles Maps]

== Temples and Villages and Dominions ==
This was an attempt at altered victory conditions, specifically conquering a certain number of locations (villages and/or temples). A different gameplay from simply killing all enemy leaders. There were a number of other gimmicks, such as tunnels and temple experience awards (the latter were broken in later version of Wesnoth), but the integration of these game elements into the whole wasn't perfect.

Here you'll find [http://www.wesnoth.org/forum/viewtopic.php?t=5105 Temples and Villages] and [http://www.wesnoth.org/forum/viewtopic.php?t=6310 Dominions]. They are pretty similar to some of [http://www.wesnoth.org/forum/viewtopic.php?t=5204 Hieronymus' Scenarios], which were developed around the same time.

== Borderland Wars (version 1.0.2 - 1.2+) ==
Temples and Villages and Dominions were decent ideas. But why not base that gameplay on the more professional maps that come with the game (and not just rely on my own map-making skills)? Borderland Wars does just that - it takes standard MP maps and adds altered victory conditions and gameplay.
A number of villages are converted into "towns" that need to be captured for victory. Leaders get reassigned after death (no kill-all-leaders victory condition).

You'll find this at [http://www.wesnoth.org/forum/viewtopic.php?t=13631 Borderland Wars Revisited].

== Multi-Player Campaigns (version 1.1.14ish - today) ==

'''Multiplayer Campaigns are currently broken''' (both in stable and dev versions). Check the forum for more information.

A much asked-for feature, yet something few people tried to do. The beginnings were hacky workarounds trying to recreate the single-player scenario-to-scenario features in multiplayer. Some experimentation around version 1.1.14ish revealed that the basics were actually there, it was possible to set up MP scenarios so that you start with a recall list from the last scenario. It was just still incredibly fiddly!

So I wrote a [http://www.wesnoth.org/forum/viewtopic.php?t=11349 Multi-Player Campaigns HOWTO], which is probably better summarised in the wiki page on [http://www.wesnoth.org/wiki/MultiplayerCampaigns Multiplayer Campaigns]. There are a lot of things that still need to be tested outside of simple proof-of-concepts, and yet so few people are working on MP Campaigns (who else is?).

The question is... ''what is a multiplayer campaign?'' There's so many more possibilities that in single player. Is it cooperative, or is it set-up player-vs-player? If it is cooperative, how can it be designed that the players don't just compete indirectly for villages, xp and so on? So that actually, those people work together and are presented with scenarios that challenge their skills at cooperation?

I'm still continuing work on...

== Unnatural Winter (Multiplayer Campaign)(version 1.1.18 - 1.2+) ==
This started out to become a showcase multiplayer campaign - similar to the single-player campaigns in terms of story, where all the player cooperatively solve the missions. The scenarios are designed in a way that the players are tested in their skills to work together strategically - presenting them with a number of simultaneous objectives between which they need to split up their resources and attention.

The only problem was that development took so long. For over a year, only the first scenario was available, which didn't help testing or proving the MP campaigns concept! There were complicated parts in the WML that dealt with difficulty levels, for instance. Finally, in March 2007 Truper and jb ventured to join the team and with their help, a first development version of the second scenario was developed.

You'll find the campaign here: [http://www.wesnoth.org/forum/viewtopic.php?t=12252 An Unnatural Winter]

== Dark Forecast (Multiplayer Random Survival)(version 1.3.3+) ==
A cooperative project with '''jb'''

This combines the popular idea of cooperative Survival games with replayability and unpredictability. I really liked the basic idea of Survival-type scenarios, but hated the deja-vu effect and the benefit a player had who remembered exactly which spawns appeared where and when.

In Dark Forecast, the waves are randomly determined groups that appear at regular intervals in random locations. Also, the weather changes at times which changes the map. The players need to be on their guard since they never fully know what to expect.

You'll find Dark Forecast here [http://www.wesnoth.org/forum/viewtopic.php?t=17406 Dark Forecast - 2-p Co-Op survival] (or on the campaign server)

----

== Trove of Unfinished Ideas... ==
- '''Map Generators''': with the WML nowadays it would be possible to include a standard mp inside a [terrain_mask] on top of a randomly generated map, and with some smart rules create a Map Generator that always stays up-to-date with the latest changes of the standard mp maps (just like Borderland Wars does).

- '''Random Tiles Map Engine''': I really want to make a generalised version of the tile laying WML. This could be so good when used in dungeon/rpg scenarios - or to create random but structured maps for things like MP Survival.

- '''Borderland Wars Generator''': merge the Borderland Wars and Map Generator concepts into one (randomised map _and_ Borderland Wars gameplay). But I yet have to see that there's any interest in the Borderland Wars concept...

- '''Diplomatic/Epic game''': this is an idea that I see some similarity to [http://www.wesnoth.org/forum/viewtopic.php?t=14072 Becephalus' Westeros Map idea], just with more gameplay changes to favour the diplomatic / grand-strategic game. There would be four AI sides representing grand powers. The players could ally with these (and so, indirectly, with or against each other), and then be the active pawns of the struggle. There would be locations granting units to your recruit lists, and possibilities for changing alliances based on actions ('kill my enemy and you can become my friend').

- '''Dungeon Crawl RPG''': something akin to Dwarvish Treasure, but players start out cooperatively, and can then become "traitors" that serve the forces of darkness...

User:Rhuvaen

2007-08-20T10:26:10Z

Rhuvaen: /* Dark Forecast (Multiplayer Random Survival)(version 1.3.3+) */

I like trying new ideas with WML for '''multiplayer Wesnoth''', and here's a collection of links to things I've made. Some of those could be made into something better with a lot more polish, but it takes a lot of time writing and testing the WML.

If you find any of these aren't working with today's version of Wesnoth and you would like to play them, then contact me about it.

== MP Generator Pack (version 0.8 - today) ==
The random generator is a clumsy tool. I was dissatisfied with the unbalanced maps of clumped terrain that I got with the packaged generator scenarios, so I made these - WML files that break and mix the terrains a bit more. Made in the 0.8 days but still working today.

As a second idea, I used tournament-style maps often found in 2v2 and 1v1 play, made a "template" from those maps specifying which terrains should get randomised and applied that template over the generator. The result is tournament maps which have their terrain randomised somewhat.

It's all in the [http://www.wesnoth.org/forum/viewtopic.php?t=4559 MP Generator Pack]

== Random Tiled Maps (version 0.9 - today) ==
These are maps using the PSEUDORANDOM WML function to apply pre-designed "Tiles" (i.e. map pieces) to a map, replacing many hexes at once. The result is still random, while the "tiles" are actually designed by hand. Sometime in version 0.9, the code was changed to use the [terrain_mask] functionality, which was a great aid here.

I only made one scenario to date as a proof-of-concept, but this is definitely an idea I need to come back to! I have already worked on a generalised tile-based map generator, and plan to use it to make a random dungeon scenario one day.
[http://www.wesnoth.org/forum/viewtopic.php?t=6139 Random Tiles Maps]

== Temples and Villages and Dominions ==
This was an attempt at altered victory conditions, specifically conquering a certain number of locations (villages and/or temples). A different gameplay from simply killing all enemy leaders. There were a number of other gimmicks, such as tunnels and temple experience awards (the latter were broken in later version of Wesnoth), but the integration of these game elements into the whole wasn't perfect.

Here you'll find [http://www.wesnoth.org/forum/viewtopic.php?t=5105 Temples and Villages] and [http://www.wesnoth.org/forum/viewtopic.php?t=6310 Dominions]. They are pretty similar to some of [http://www.wesnoth.org/forum/viewtopic.php?t=5204 Hieronymus' Scenarios], which were developed around the same time.

== Borderland Wars (version 1.0.2 - 1.2+) ==
Temples and Villages and Dominions were decent ideas. But why not base that gameplay on the more professional maps that come with the game (and not just rely on my own map-making skills)? Borderland Wars does just that - it takes standard MP maps and adds altered victory conditions and gameplay.
A number of villages are converted into "towns" that need to be captured for victory. Leaders get reassigned after death (no kill-all-leaders victory condition).

You'll find this at [http://www.wesnoth.org/forum/viewtopic.php?t=13631 Borderland Wars Revisited].

== Multi-Player Campaigns (version 1.1.14ish - today) ==

'''Multiplayer Campaigns are currently broken''' (both in stable and dev versions). Check the forum for more information.

A much asked-for feature, yet something few people tried to do. The beginnings were hacky workarounds trying to recreate the single-player scenario-to-scenario features in multiplayer. Some experimentation around version 1.1.14ish revealed that the basics were actually there, it was possible to set up MP scenarios so that you start with a recall list from the last scenario. It was just still incredibly fiddly!

So I wrote a [http://www.wesnoth.org/forum/viewtopic.php?t=11349 Multi-Player Campaigns HOWTO], which is probably better summarised in the wiki page on [http://www.wesnoth.org/wiki/MultiplayerCampaigns Multiplayer Campaigns]. There are a lot of things that still need to be tested outside of simple proof-of-concepts, and yet so few people are working on MP Campaigns (who else is?).

The question is... ''what is a multiplayer campaign?'' There's so many more possibilities that in single player. Is it cooperative, or is it set-up player-vs-player? If it is cooperative, how can it be designed that the players don't just compete indirectly for villages, xp and so on? So that actually, those people work together and are presented with scenarios that challenge their skills at cooperation?

I'm still continuing work on...

== Unnatural Winter (Multiplayer Campaign)(version 1.1.18 - 1.2+) ==
This started out to become a showcase multiplayer campaign - similar to the single-player campaigns in terms of story, where all the player cooperatively solve the missions. The scenarios are designed in a way that the players are tested in their skills to work together strategically - presenting them with a number of simultaneous objectives between which they need to split up their resources and attention.

The only problem was that development took so long. For over a year, only the first scenario was available, which didn't help testing or proving the MP campaigns concept! There were complicated parts in the WML that dealt with difficulty levels, for instance. Finally, in March 2007 Truper and jb ventured to join the team and with their help, a first development version of the second scenario was developed.

You'll find the campaign here: [http://www.wesnoth.org/forum/viewtopic.php?t=12252 An Unnatural Winter]

== Dark Forecast (Multiplayer Random Survival)(version 1.3.3+) ==
A cooperative project with __jb__

This combines the popular idea of cooperative Survival games with replayability and unpredictability. I really liked the basic idea of Survival-type scenarios, but hated the deja-vu effect and the benefit a player had who remembered exactly which spawns appeared where and when.

In Dark Forecast, the waves are randomly determined groups that appear at regular intervals in random locations. Also, the weather changes at times which changes the map. The players need to be on their guard since they never fully know what to expect.

You'll find Dark Forecast here [http://www.wesnoth.org/forum/viewtopic.php?t=17406 Dark Forecast - 2-p Co-Op survival] (or on the campaign server)

----

== Trove of Unfinished Ideas... ==
- '''Map Generators''': with the WML nowadays it would be possible to include a standard mp inside a [terrain_mask] on top of a randomly generated map, and with some smart rules create a Map Generator that always stays up-to-date with the latest changes of the standard mp maps (just like Borderland Wars does).

- '''Random Tiles Map Engine''': I really want to make a generalised version of the tile laying WML. This could be so good when used in dungeon/rpg scenarios - or to create random but structured maps for things like MP Survival.

- '''Borderland Wars Generator''': merge the Borderland Wars and Map Generator concepts into one (randomised map _and_ Borderland Wars gameplay). But I yet have to see that there's any interest in the Borderland Wars concept...

- '''Diplomatic/Epic game''': this is an idea that I see some similarity to [http://www.wesnoth.org/forum/viewtopic.php?t=14072 Becephalus' Westeros Map idea], just with more gameplay changes to favour the diplomatic / grand-strategic game. There would be four AI sides representing grand powers. The players could ally with these (and so, indirectly, with or against each other), and then be the active pawns of the struggle. There would be locations granting units to your recruit lists, and possibilities for changing alliances based on actions ('kill my enemy and you can become my friend').

- '''Dungeon Crawl RPG''': something akin to Dwarvish Treasure, but players start out cooperatively, and can then become "traitors" that serve the forces of darkness...

User:Rhuvaen

2007-08-20T10:25:17Z

Rhuvaen:

I like trying new ideas with WML for '''multiplayer Wesnoth''', and here's a collection of links to things I've made. Some of those could be made into something better with a lot more polish, but it takes a lot of time writing and testing the WML.

If you find any of these aren't working with today's version of Wesnoth and you would like to play them, then contact me about it.

== MP Generator Pack (version 0.8 - today) ==
The random generator is a clumsy tool. I was dissatisfied with the unbalanced maps of clumped terrain that I got with the packaged generator scenarios, so I made these - WML files that break and mix the terrains a bit more. Made in the 0.8 days but still working today.

As a second idea, I used tournament-style maps often found in 2v2 and 1v1 play, made a "template" from those maps specifying which terrains should get randomised and applied that template over the generator. The result is tournament maps which have their terrain randomised somewhat.

It's all in the [http://www.wesnoth.org/forum/viewtopic.php?t=4559 MP Generator Pack]

== Random Tiled Maps (version 0.9 - today) ==
These are maps using the PSEUDORANDOM WML function to apply pre-designed "Tiles" (i.e. map pieces) to a map, replacing many hexes at once. The result is still random, while the "tiles" are actually designed by hand. Sometime in version 0.9, the code was changed to use the [terrain_mask] functionality, which was a great aid here.

I only made one scenario to date as a proof-of-concept, but this is definitely an idea I need to come back to! I have already worked on a generalised tile-based map generator, and plan to use it to make a random dungeon scenario one day.
[http://www.wesnoth.org/forum/viewtopic.php?t=6139 Random Tiles Maps]

== Temples and Villages and Dominions ==
This was an attempt at altered victory conditions, specifically conquering a certain number of locations (villages and/or temples). A different gameplay from simply killing all enemy leaders. There were a number of other gimmicks, such as tunnels and temple experience awards (the latter were broken in later version of Wesnoth), but the integration of these game elements into the whole wasn't perfect.

Here you'll find [http://www.wesnoth.org/forum/viewtopic.php?t=5105 Temples and Villages] and [http://www.wesnoth.org/forum/viewtopic.php?t=6310 Dominions]. They are pretty similar to some of [http://www.wesnoth.org/forum/viewtopic.php?t=5204 Hieronymus' Scenarios], which were developed around the same time.

== Borderland Wars (version 1.0.2 - 1.2+) ==
Temples and Villages and Dominions were decent ideas. But why not base that gameplay on the more professional maps that come with the game (and not just rely on my own map-making skills)? Borderland Wars does just that - it takes standard MP maps and adds altered victory conditions and gameplay.
A number of villages are converted into "towns" that need to be captured for victory. Leaders get reassigned after death (no kill-all-leaders victory condition).

You'll find this at [http://www.wesnoth.org/forum/viewtopic.php?t=13631 Borderland Wars Revisited].

== Multi-Player Campaigns (version 1.1.14ish - today) ==

'''Multiplayer Campaigns are currently broken''' (both in stable and dev versions). Check the forum for more information.

A much asked-for feature, yet something few people tried to do. The beginnings were hacky workarounds trying to recreate the single-player scenario-to-scenario features in multiplayer. Some experimentation around version 1.1.14ish revealed that the basics were actually there, it was possible to set up MP scenarios so that you start with a recall list from the last scenario. It was just still incredibly fiddly!

So I wrote a [http://www.wesnoth.org/forum/viewtopic.php?t=11349 Multi-Player Campaigns HOWTO], which is probably better summarised in the wiki page on [http://www.wesnoth.org/wiki/MultiplayerCampaigns Multiplayer Campaigns]. There are a lot of things that still need to be tested outside of simple proof-of-concepts, and yet so few people are working on MP Campaigns (who else is?).

The question is... ''what is a multiplayer campaign?'' There's so many more possibilities that in single player. Is it cooperative, or is it set-up player-vs-player? If it is cooperative, how can it be designed that the players don't just compete indirectly for villages, xp and so on? So that actually, those people work together and are presented with scenarios that challenge their skills at cooperation?

I'm still continuing work on...

== Unnatural Winter (Multiplayer Campaign)(version 1.1.18 - 1.2+) ==
This started out to become a showcase multiplayer campaign - similar to the single-player campaigns in terms of story, where all the player cooperatively solve the missions. The scenarios are designed in a way that the players are tested in their skills to work together strategically - presenting them with a number of simultaneous objectives between which they need to split up their resources and attention.

The only problem was that development took so long. For over a year, only the first scenario was available, which didn't help testing or proving the MP campaigns concept! There were complicated parts in the WML that dealt with difficulty levels, for instance. Finally, in March 2007 Truper and jb ventured to join the team and with their help, a first development version of the second scenario was developed.

You'll find the campaign here: [http://www.wesnoth.org/forum/viewtopic.php?t=12252 An Unnatural Winter]

== Dark Forecast (Multiplayer Random Survival)(version 1.3.3+) ==
A cooperative project with ==jb==

This combines the popular idea of cooperative Survival games with replayability and unpredictability. I really liked the basic idea of Survival-type scenarios, but hated the deja-vu effect and the benefit a player had who remembered exactly which spawns appeared where and when.

In Dark Forecast, the waves are randomly determined groups that appear at regular intervals in random locations. Also, the weather changes at times which changes the map. The players need to be on their guard since they never fully know what to expect.

You'll find Dark Forecast here [http://www.wesnoth.org/forum/viewtopic.php?t=17406 Dark Forecast - 2-p Co-Op survival] (or on the campaign server)

----
== Trove of Unfinished Ideas... ==
- '''Map Generators''': with the WML nowadays it would be possible to include a standard mp inside a [terrain_mask] on top of a randomly generated map, and with some smart rules create a Map Generator that always stays up-to-date with the latest changes of the standard mp maps (just like Borderland Wars does).

- '''Random Tiles Map Engine''': I really want to make a generalised version of the tile laying WML. This could be so good when used in dungeon/rpg scenarios - or to create random but structured maps for things like MP Survival.

- '''Borderland Wars Generator''': merge the Borderland Wars and Map Generator concepts into one (randomised map _and_ Borderland Wars gameplay). But I yet have to see that there's any interest in the Borderland Wars concept...

- '''Diplomatic/Epic game''': this is an idea that I see some similarity to [http://www.wesnoth.org/forum/viewtopic.php?t=14072 Becephalus' Westeros Map idea], just with more gameplay changes to favour the diplomatic / grand-strategic game. There would be four AI sides representing grand powers. The players could ally with these (and so, indirectly, with or against each other), and then be the active pawns of the struggle. There would be locations granting units to your recruit lists, and possibilities for changing alliances based on actions ('kill my enemy and you can become my friend').

- '''Dungeon Crawl RPG''': something akin to Dwarvish Treasure, but players start out cooperatively, and can then become "traitors" that serve the forces of darkness...

User:Rhuvaen

2007-08-20T10:24:34Z

Rhuvaen: added Dark Forecast

I like trying new ideas with WML for '''multiplayer Wesnoth''', and here's a collection of links to things I've made. Some of those could be made into something better with a lot more polish, but it takes a lot of time writing and testing the WML.

If you find any of these aren't working with today's version of Wesnoth and you would like to play them, then contact me about it.

== MP Generator Pack (version 0.8 - today) ==
The random generator is a clumsy tool. I was dissatisfied with the unbalanced maps of clumped terrain that I got with the packaged generator scenarios, so I made these - WML files that break and mix the terrains a bit more. Made in the 0.8 days but still working today.

As a second idea, I used tournament-style maps often found in 2v2 and 1v1 play, made a "template" from those maps specifying which terrains should get randomised and applied that template over the generator. The result is tournament maps which have their terrain randomised somewhat.

It's all in the [http://www.wesnoth.org/forum/viewtopic.php?t=4559 MP Generator Pack]

== Random Tiled Maps (version 0.9 - today) ==
These are maps using the PSEUDORANDOM WML function to apply pre-designed "Tiles" (i.e. map pieces) to a map, replacing many hexes at once. The result is still random, while the "tiles" are actually designed by hand. Sometime in version 0.9, the code was changed to use the [terrain_mask] functionality, which was a great aid here.

I only made one scenario to date as a proof-of-concept, but this is definitely an idea I need to come back to! I have already worked on a generalised tile-based map generator, and plan to use it to make a random dungeon scenario one day.
[http://www.wesnoth.org/forum/viewtopic.php?t=6139 Random Tiles Maps]

== Temples and Villages and Dominions ==
This was an attempt at altered victory conditions, specifically conquering a certain number of locations (villages and/or temples). A different gameplay from simply killing all enemy leaders. There were a number of other gimmicks, such as tunnels and temple experience awards (the latter were broken in later version of Wesnoth), but the integration of these game elements into the whole wasn't perfect.

Here you'll find [http://www.wesnoth.org/forum/viewtopic.php?t=5105 Temples and Villages] and [http://www.wesnoth.org/forum/viewtopic.php?t=6310 Dominions]. They are pretty similar to some of [http://www.wesnoth.org/forum/viewtopic.php?t=5204 Hieronymus' Scenarios], which were developed around the same time.

== Borderland Wars (version 1.0.2 - 1.2+) ==
Temples and Villages and Dominions were decent ideas. But why not base that gameplay on the more professional maps that come with the game (and not just rely on my own map-making skills)? Borderland Wars does just that - it takes standard MP maps and adds altered victory conditions and gameplay.
A number of villages are converted into "towns" that need to be captured for victory. Leaders get reassigned after death (no kill-all-leaders victory condition).

You'll find this at [http://www.wesnoth.org/forum/viewtopic.php?t=13631 Borderland Wars Revisited].

== Multi-Player Campaigns (version 1.1.14ish - today) ==

'''Multiplayer Campaigns are currently broken''' (both in stable and dev versions). Check the forum for more information.

A much asked-for feature, yet something few people tried to do. The beginnings were hacky workarounds trying to recreate the single-player scenario-to-scenario features in multiplayer. Some experimentation around version 1.1.14ish revealed that the basics were actually there, it was possible to set up MP scenarios so that you start with a recall list from the last scenario. It was just still incredibly fiddly!

So I wrote a [http://www.wesnoth.org/forum/viewtopic.php?t=11349 Multi-Player Campaigns HOWTO], which is probably better summarised in the wiki page on [http://www.wesnoth.org/wiki/MultiplayerCampaigns Multiplayer Campaigns]. There are a lot of things that still need to be tested outside of simple proof-of-concepts, and yet so few people are working on MP Campaigns (who else is?).

The question is... ''what is a multiplayer campaign?'' There's so many more possibilities that in single player. Is it cooperative, or is it set-up player-vs-player? If it is cooperative, how can it be designed that the players don't just compete indirectly for villages, xp and so on? So that actually, those people work together and are presented with scenarios that challenge their skills at cooperation?

I'm still continuing work on...

== Unnatural Winter (Multiplayer Campaign)(version 1.1.18 - 1.2+) ==
This started out to become a showcase multiplayer campaign - similar to the single-player campaigns in terms of story, where all the player cooperatively solve the missions. The scenarios are designed in a way that the players are tested in their skills to work together strategically - presenting them with a number of simultaneous objectives between which they need to split up their resources and attention.

The only problem was that development took so long. For over a year, only the first scenario was available, which didn't help testing or proving the MP campaigns concept! There were complicated parts in the WML that dealt with difficulty levels, for instance. Finally, in March 2007 Truper and jb ventured to join the team and with their help, a first development version of the second scenario was developed.

You'll find the campaign here: [http://www.wesnoth.org/forum/viewtopic.php?t=12252 An Unnatural Winter]

== Dark Forecast (Multiplayer Random Survival)(version 1.3.3+) ==
A cooperative project with ==jb==

This combines the popular idea of cooperative Survival games with replayability and unpredictability. I really liked the basic idea of Survival-type scenarios, but hated the deja-vu effect and the benefit a player had who remembered exactly which spawns appeared where and when.

In Dark Forecast, the waves are randomly determined groups that appear at regular intervals in random locations. Also, the weather changes at times which changes the map. The players need to be on their guard since they never fully know what to expect.

You'll find Dark Forecast here [http://www.wesnoth.org/forum/viewtopic.php?t=17406 Dark Forecast - 2-p Co-Op survival] (or on the campaign server)

----
== Trove of Unfinished Ideas... ==
- '''Map Generators''': with the WML nowadays it would be possible to include a standard mp inside a [terrain_mask] on top of a randomly generated map, and with some smart rules create a Map Generator that always stays up-to-date with the latest changes of the standard mp maps (just like Borderland Wars does).

- '''Random Tiles Map Engine''': I really want to make a generalised version of the tile laying WML. This could be so good when used in dungeon/rpg scenarios - or to create random but structured maps for things like MP Survival.

- '''Borderland Wars Generator''': merge the Borderland Wars and Map Generator concepts into one (randomised map _and_ Borderland Wars gameplay). But I yet have to see that there's any interest in the Borderland Wars concept...

- '''Diplomatic/Epic game''': this is an idea that I see some similarity to [http://www.wesnoth.org/forum/viewtopic.php?t=14072 Becephalus' Westeros Map idea], just with more gameplay changes to favour the diplomatic / grand-strategic game. There would be four AI sides representing grand powers. The players could ally with these (and so, indirectly, with or against each other), and then be the active pawns of the struggle. There would be locations granting units to your recruit lists, and possibilities for changing alliances based on actions ('kill my enemy and you can become my friend').

- '''Dungeon Crawl RPG''': something akin to Dwarvish Treasure, but players start out cooperatively, and can then become "traitors" that serve the forces of darkness...

MultiplayerContent

2007-08-09T09:32:02Z

Rhuvaen: changed status of MP campaigns from broken to working

'''Multiplayer campaigns are working again in versions 1.3.5+''', they are broken in both stable and development versions of Wesnoth prior to 1.x.5. Check the [http://www.wesnoth.org/forum/viewtopic.php?t=11349 forums] or [https://gna.org/bugs/index.php?9242 bug tracker] for more information.

== Building multiplayer campaigns ==

Both the stable and development versions of wesnoth have basic support for campaigns that can be played in multiplayer mode, with your friends, or even with an AI. Since version 1.1.8, more features and support have been added so we recommend a versions 1.1.8+. There will still be some things that don't work as expected as multiplayer campaigns are an area for exploration. While you can and should test your work in hotseat mode, there are a number of things that might behave differently under real network conditions (mostly affecting scenario and side parameters). Keep this in mind and make sure to test your campaign over the net, too.
This page only documents the differences between writing multiplayer campaigns and single player campaigns, so you might want to read up on [[BuildingCampaigns]] and [[BuildingMultiplayer]] first.

=== The campaign file ===

Multiplayer campaigns do not use the [campaign] tag. As a result of this, multiplayer campaigns only support one difficulty level, though you could support more with enough WML, if you're feeling ambitious. The "campaign file" should look something like this:

#ifdef MULTIPLAYER
{@campaigns/My_Campaign/scenarios}
#endif

Anything that you would normally put in the campaign tag now goes into the first scenario, if it's supported there. The order of scenarios is determined by next_scenario tags, just like in single player.

=== Scenarios ===

A scenario in a multiplayer campaign is almost identical to a scenario in a single player campaign. You only need to change the following:

* The [scenario] tag should be replaced with a [multiplayer] tag.
* The '''next_scenario''' key points to the id of the next scenario.
* Every scenario after the first should have '''allow_new_game=no''' inside the [multiplayer] tag. This will prevent it from showing up in the map selection menu. ''This does not work in v1.1'', but it causes no harm, and it will work in the future. ''(This still doesn't work in 1.2.2, and even prevents your campaign from working. I suggest you leave this commented out until the bug gets fixed.)''
* In v1.1, every scenario in the campaign will appear on the map selection menu, so be sure to include your campaign's name in the [multiplayer] tag's name key. Alternatively, include a warning like "DO NOT PLAY".
* Each human-controlled side needs to have a '''controller=human''' key defined in their [side] tag to work in network mode.
* Each human-controlled side also needs to have a '''save_id''' defined inside their [side] tag. Each side's save_id should be unique, and it should be the same in every scenario. Without this, your recall lists and leaders will not carry over from one scenario to the next.
* Each human-controlled side has to have a leader '''type=''' definition in every scenario except the first one . It doesn't matter which type you choose cause the type set here gets replaced by the actual leader in the recall list.
* Each AI-controlled side should have '''allow_player=no''' in their [side] tag.
* The [story] tag will only display for the first player (or maybe it's the host player). You'll have to use [message] tags in the start event if you want everyone to read the story.
* If you have a file containing macros, it must be referenced by every scenario, since there is no proper campaign file to include it from.

=== The first scenario ===

The first scenario might need some extra work, because the settings from the multiplayer dialog will override the settings in the scenario. However, most of the multiplayer settings can be overridden in the prestart event.

Use a macro like this to force a side to have a particular type of leader.
#define MP_SIDE SIDENO TYPE DESC
[store_unit]
variable=oldunit
kill=yes
[filter]
side={SIDENO}
[/filter]
[/store_unit]

[unit]
type={TYPE}
description={DESC}
unrenameable=yes
side={SIDENO}
x,y=$oldunit.x,$oldunit.y
canrecruit=1
[/unit]

[clear_variable]
name=oldunit
[/clear_variable]
#enddef

Other useful tags include [set_recruit], [modify_side], [modify_turns] and [remove_shroud]. There is currently no way to remove fog. You might also want to use ''experience_modifier=100'' in the [multiplayer] tag.

=== Custom units ===

Since there is no [campaign] tag, there is no natural way to include custom units in a multiplayer campaign. However, there are two workarounds. One way is to use [[EffectWML]] or [store_unit] to modify a mainline unit. The other way is to make your custom units available via an [[EraWML|era]], or by dropping them into ~wesnoth/data/units. If you go this route, using an era is better, because you can keep the units in your campaign directory.

== See Also ==

* [http://www.wesnoth.org/forum/viewtopic.php?t=11349 Multiplayer Campaigns HOWTO forum post]
* [[BuildingScenarios]]
* [[BuildingMultiplayer]]

DirectActionsWML

2007-07-03T10:52:20Z

Rhuvaen: /* Direct actions */ - added not working info to unstore_unit/advance

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

Direct actions are actions that have a direct effect on gameplay.

The following tags are actions:
* '''[endlevel]''' ends the scenario.
** ''result'' before the scenario is over, all events with ''name=result'' are triggered. The message ''result_message'' with the heading ''result_heading'' (see [[LanguageWML]]) are displayed. If ''result=victory'', the player progresses to the next level; if ''result=defeat'', the game returns to the main menu. These last two are rarely used: ''result=continue'' behaves identically to ''result=victory'' except the player's gold is not reduced to 80%, and it does not bring up a "Victory" message or the gold changing message (since it doesn't change); ''result=continue_no_save'' works similarly, except the player is not asked whether to save the game, and is taken directly to the next scenario without any messages. Unless ''result=defeat'', the following keys can also be used:
** ''bonus'' whether the player should get bonus gold (maximum possible gold that could have been earned by waiting the level out). The default is bonus=yes.
** ''next_scenario'' (default specified in '''[scenario]''' tag) the ID of the next scenario that should be played. All units that side 1 controls at this point become available for recall in ''next_scenario''.
* '''[unit]''' places a unit on the map. For syntax see [[SingleUnitWML]].
* '''[recall]''' recalls a unit. The unit is recalled free of charge, and is placed near the leader.
** ''standard unit filter'' the first matching unit will be recalled. If no units match this tag is ignored.
** ''x,y'' the unit is placed here instead of next to the leader.
** ''show'' if not "no", display the unit being recalled.
* '''[teleport]''' teleports a unit on map.
** '''[filter]''' (standard unit filter) all units matching the filter will be teleported.
** ''x,y'' the position to teleport to.
* '''[terrain_mask]''' changes the terrain on the map. See [[TerrainMaskWML]].
* '''[terrain]''' changes the terrain on the map.
** ''letter'' the character of the terrain to use. See [[TerrainLettersWML]] to see what letter a type of terrain uses.
** standard location filter- the area to change the terrain of.
* '''[gold]''' give one side gold.
** ''amount'' the amount of gold to give.
** ''side'' (default=1) the number of the side to give the gold to.
* '''[unstore_unit]''' creates a unit from a game variable, and activates it on the playing field. This must be a specific variable describing a unit, and may not be an array -- to unstore an entire array, iterate over it. The variable is not cleared. See also [store_unit], [while] and [clear_variable] in [[InternalActionsWML]]. Note units with a negative amount of hitpoints will be unstored with 1 hitpoint.
** ''variable'' the name of the variable.
** ''find_vacant'' whether the unit should be placed on the nearest vacant tile to its specified location. If this is set to 'no'(default), then any unit on the same tile as the unit being unstored will be destroyed.
** ''text'' (translatable) floating text to display above the unit, such as a damage amount
** ''red'', ''green'', ''blue'' (default=0,0,0) the color to display the text in. Values vary from 0-255. You may find it convenient to use the {COLOR_HARM} or {COLOR_HEAL} macro instead. (Use {COLOR_HARM} or {COLOR_HEAL} instead of the whole red,green,blue= line.)
** ''advance'' if the XP has been modified then there will be tried to advance the unit, default true (currently not working). {{DevFeature}}
* '''[allow_recruit]''' allows a side to recruit units it couldn't previously recruit.
** ''type'' the types of units that the side can now recruit.
** ''side'' (default=1) the number of the side that is being allowed to recruit the units.
* '''[disallow_recruit]''' prevents a side from recruiting units it could previously recruit.
** ''type'' the types of units that the side can no longer recruit.
** ''side'' (default=1) the number of the side that may no longer recruit the units.
* '''[set_recruit]''' sets the units a side can recruit.
** ''recruit'' the types of units that the side can now recruit.
** ''side'' (default=1) the number of the side that is having its recruitment set.
* '''[modify_side]''' modifies some details of a given side in the middle of a scenario. '''The following listed properties are the only properties that [modify_side] can affect!'''
** ''side'' (default=1) the number of the side that is to be changed.
** ''income'' the income given at the begining of each turn.
** ''team_name'' the team in which the side plays the scenario.
** ''gold'' the amount of gold the side owns.
* '''[modify_turns]''' modifies the turn limit in the middle of a scenario.
** ''value'' the new turn limit.
** ''add'' if used instead of ''value'', specifies the number of turns to add to the current limit (can be negative).
* '''[capture_village]''' changes the ownership of a village.
** ''side'' the side that takes control of the village. If not given, the village will become neutral.
** ''x, y'' the location of the village.
* '''[kill]''' Removes all units (including units in a recall list) that match the filter from the game.
** standard unit filter
** ''animate'' if 'yes', displays the unit dying (fading away).
** ''fire_event'' if 'yes', triggers any appropriate 'die' events (See [[EventWML]]). Note that any 'die' events triggered by this are executed immediately, interrupting the current event and thus causing the x1, y1, x2, and y2 variables to be reset for that 'die' event, which in turn causes those variables to be invalid for the remainder of this event.
* '''[unstone]''' Unstones all units that match the filter.
** '''[filter]''' (standard unit filter) all units matching the filter will be unstoned. If no unit matches the filter, then nothing happens (probably). If absent, all units on the map are unstoned.
* '''[object]''' gives some unit an object and removes all items on the tile the unit is on.
** ''id'' when the object is picked up, a flag is set for ''id''. The object cannot be picked up if a flag for ''id'' has been set. This means that any object with an id can only be used once, even if first_time_only=no is set for the event. This restriction is per level. In a campaign objects with the same id can be assigned once per level.
** '''[effect]''' one or more effect elements may be listed. See [[EffectWML]] for a description of [effect].
** ''duration'' if 'level', effects only last until the end of the level (note : 'level' is the scenario, so this doesn't mean it last until the unit levels-up).
** '''[filter]''' (standard unit filter) the first unit found that matches the filter will be given the object. If no unit matches the filter, then a message is displayed and the object is not removed.
** '''[then]''' a subtag that lets you execute actions if the filter conditions are met. The most common action that should be inside here is a '''[removeitem]''' tag, but you could probably put any tags that otherwise work in a [then] tag.
** ''silent'' whether or not messages should be suppressed. Default is "no".
** ''image'' the displayed image of the object.
** ''name'' (translatable) displayed as a caption of the image.
** ''description'' (translatable) displayed as a message of the image.
** ''cannot_use_message'' (translatable) displayed instead of '''description''' if no unit passes the filter test.
** If you do not supply a filter, the object action will be applied to a unit at the location of the moveto event. Currently this isn't recommended as it is not clear that this will continue working this way. Instead it is better to explicitly include a location filter.
** The object action does not act on units in the recall list. There is a feature request in to allow this, but it is not clear whether or not it will be accepted.
* '''[remove_shroud]''' removes some shroud from the map for a certain side (only relevant for sides that have shroud=yes).
** ''side'' (default=1) the side for which to remove shroud.
** standard location filter- the range of tiles for which shroud should be removed.
* '''[place_shroud]''' places some shroud on the map for a certain side (only relevant for sides that have shroud=yes).
** ''side'' (default=1) the side for which to place shroud.
** standard location filter- the range of tiles on which shroud should be placed.
* '''[allow_undo]''' allows the player to undo the event that this tag is inside. Has an effect only inside moveto events. If the move is undone, only the position of the unit will be restored; any altered variables or changes to the game will remain changed after the move is undone. It is up to the scenario designer to avoid abusing this command. You do not use '''[allow_undo]''' before or after usage of other direct actions ([[DirectActionsWML]]). If you modify a variable ([[InternalActionsWML]]), then you set it back before using '''[allow_undo]'''.
** The '''[allow_undo]''' command has no effect within a '''[then]''' or '''[else]''' or '''[do]''' command. Thus, it is impossible to check a conditional using '''[if]''' or '''[while]''', then only '''[allow_undo]''' sometimes. You have a choice: the moveto event may either allow undo whenever the event fires, or it may never allow undo; you may use filters to control whether the event fires. ({{DevFeature}}This bug should be fixed in 1.3.4)
** Technically, if '''[allow_undo]''' is inside an '''[event]''' with ''first_time_only=yes'' (the default setting), and the user undoes the event, then the state of the game has changed in this way: the event will not fire a second time, even though the user undid the move the first time.
** Do not use '''[allow_undo]''' in multiplayer scenarios, because it causes out-of-sync errors. Someone should report this to the bug-tracker with example code so that it can be fixed.

== See Also ==

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

[[Category: WML Reference]]

MultiplayerContent

2007-05-30T10:50:34Z

Rhuvaen: information on current bugs

'''Multiplayer campaigns are currently broken''' in both stable and development versions of Wesnoth. Check the [http://www.wesnoth.org/forum/viewtopic.php?t=11349 forums] or [https://gna.org/bugs/index.php?9242 bug tracker] for more information.

== Building multiplayer campaigns ==

Both the stable and development versions of wesnoth have basic support for campaigns that can be played in multiplayer mode, with your friends, or even with an AI. Since version 1.1.8, more features and support have been added so we recommend a versions 1.1.8+. There will still be some things that don't work as expected as multiplayer campaigns are an area for exploration. While you can and should test your work in hotseat mode, there are a number of things that might behave differently under real network conditions (mostly affecting scenario and side parameters). Keep this in mind and make sure to test your campaign over the net, too.
This page only documents the differences between writing multiplayer campaigns and single player campaigns, so you might want to read up on [[BuildingCampaigns]] and [[BuildingMultiplayer]] first.

=== The campaign file ===

Multiplayer campaigns do not use the [campaign] tag. As a result of this, multiplayer campaigns only support one difficulty level, though you could support more with enough WML, if you're feeling ambitious. The "campaign file" should look something like this:

#ifdef MULTIPLAYER
{@campaigns/My_Campaign/scenarios}
#endif

Anything that you would normally put in the campaign tag now goes into the first scenario, if it's supported there. The order of scenarios is determined by next_scenario tags, just like in single player.

=== Scenarios ===

A scenario in a multiplayer campaign is almost identical to a scenario in a single player campaign. You only need to change the following:

* The [scenario] tag should be replaced with a [multiplayer] tag.
* The '''next_scenario''' key points to the id of the next scenario.
* Every scenario after the first should have '''allow_new_game=no''' inside the [multiplayer] tag. This will prevent it from showing up in the map selection menu. ''This does not work in v1.1'', but it causes no harm, and it will work in the future. ''(This still doesn't work in 1.2.2, and even prevents your campaign from working. I suggest you leave this commented out until the bug gets fixed.)''
* In v1.1, every scenario in the campaign will appear on the map selection menu, so be sure to include your campaign's name in the [multiplayer] tag's name key. Alternatively, include a warning like "DO NOT PLAY".
* Each human-controlled side needs to have a '''controller=human''' key defined in their [side] tag to work in network mode.
* Each human-controlled side also needs to have a '''save_id''' defined inside their [side] tag. Each side's save_id should be unique, and it should be the same in every scenario. Without this, your recall lists and leaders will not carry over from one scenario to the next.
* Each human-controlled side has to have a leader '''type=''' definition in every scenario except the first one . It doesn't matter which type you choose cause the type set here gets replaced by the actual leader in the recall list.
* Each AI-controlled side should have '''allow_player=no''' in their [side] tag.
* The [story] tag will only display for the first player (or maybe it's the host player). You'll have to use [message] tags in the start event if you want everyone to read the story.
* If you have a file containing macros, it must be referenced by every scenario, since there is no proper campaign file to include it from.

=== The first scenario ===

The first scenario might need some extra work, because the settings from the multiplayer dialog will override the settings in the scenario. However, most of the multiplayer settings can be overridden in the prestart event.

Use a macro like this to force a side to have a particular type of leader.
#define MP_SIDE SIDENO TYPE DESC
[store_unit]
variable=oldunit
kill=yes
[filter]
side={SIDENO}
[/filter]
[/store_unit]

[unit]
type={TYPE}
description={DESC}
unrenameable=yes
side={SIDENO}
x,y=$oldunit.x,$oldunit.y
canrecruit=1
[/unit]

[clear_variable]
name=oldunit
[/clear_variable]
#enddef

Other useful tags include [set_recruit], [modify_side], [modify_turns] and [remove_shroud]. There is currently no way to remove fog. You might also want to use ''experience_modifier=100'' in the [multiplayer] tag.

=== Custom units ===

Since there is no [campaign] tag, there is no natural way to include custom units in a multiplayer campaign. However, there are two workarounds. One way is to use [[EffectWML]] or [store_unit] to modify a mainline unit. The other way is to make your custom units available via an [[EraWML|era]], or by dropping them into ~wesnoth/data/units. If you go this route, using an era is better, because you can keep the units in your campaign directory.

== See Also ==

* [http://www.wesnoth.org/forum/viewtopic.php?t=11349 Multiplayer Campaigns HOWTO forum post]
* [[BuildingScenarios]]
* [[BuildingMultiplayer]]

User:Rhuvaen

2007-05-30T10:46:42Z

Rhuvaen: /* Multi-Player Campaigns (version 1.1.14ish - today) */

I like trying new ideas with WML for '''multiplayer Wesnoth''', and here's a collection of links to things I've made. Some of those could be made into something better with a lot more polish, but it takes a lot of time writing and testing the WML.

If you find any of these aren't working with today's version of Wesnoth and you would like to play them, then contact me about it.

== MP Generator Pack (version 0.8 - today) ==
The random generator is a clumsy tool. I was dissatisfied with the unbalanced maps of clumped terrain that I got with the packaged generator scenarios, so I made these - WML files that break and mix the terrains a bit more. Made in the 0.8 days but still working today.

As a second idea, I used tournament-style maps often found in 2v2 and 1v1 play, made a "template" from those maps specifying which terrains should get randomised and applied that template over the generator. The result is tournament maps which have their terrain randomised somewhat.

It's all in the [http://www.wesnoth.org/forum/viewtopic.php?t=4559 MP Generator Pack]

== Random Tiled Maps (version 0.9 - today) ==
These are maps using the PSEUDORANDOM WML function to apply pre-designed "Tiles" (i.e. map pieces) to a map, replacing many hexes at once. The result is still random, while the "tiles" are actually designed by hand. Sometime in version 0.9, the code was changed to use the [terrain_mask] functionality, which was a great aid here.

I only made one scenario to date as a proof-of-concept, but this is definitely an idea I need to come back to! I have already worked on a generalised tile-based map generator, and plan to use it to make a random dungeon scenario one day.
[http://www.wesnoth.org/forum/viewtopic.php?t=6139 Random Tiles Maps]

== Temples and Villages and Dominions ==
This was an attempt at altered victory conditions, specifically conquering a certain number of locations (villages and/or temples). A different gameplay from simply killing all enemy leaders. There were a number of other gimmicks, such as tunnels and temple experience awards (the latter were broken in later version of Wesnoth), but the integration of these game elements into the whole wasn't perfect.

Here you'll find [http://www.wesnoth.org/forum/viewtopic.php?t=5105 Temples and Villages] and [http://www.wesnoth.org/forum/viewtopic.php?t=6310 Dominions]. They are pretty similar to some of [http://www.wesnoth.org/forum/viewtopic.php?t=5204 Hieronymus' Scenarios], which were developed around the same time.

== Borderland Wars (version 1.0.2 - 1.2+) ==
Temples and Villages and Dominions were decent ideas. But why not base that gameplay on the more professional maps that come with the game (and not just rely on my own map-making skills)? Borderland Wars does just that - it takes standard MP maps and adds altered victory conditions and gameplay.
A number of villages are converted into "towns" that need to be captured for victory. Leaders get reassigned after death (no kill-all-leaders victory condition).

You'll find this at [http://www.wesnoth.org/forum/viewtopic.php?t=13631 Borderland Wars Revisited].

== Multi-Player Campaigns (version 1.1.14ish - today) ==

'''Multiplayer Campaigns are currently broken''' (both in stable and dev versions). Check the forum for more information.

A much asked-for feature, yet something few people tried to do. The beginnings were hacky workarounds trying to recreate the single-player scenario-to-scenario features in multiplayer. Some experimentation around version 1.1.14ish revealed that the basics were actually there, it was possible to set up MP scenarios so that you start with a recall list from the last scenario. It was just still incredibly fiddly!

So I wrote a [http://www.wesnoth.org/forum/viewtopic.php?t=11349 Multi-Player Campaigns HOWTO], which is probably better summarised in the wiki page on [http://www.wesnoth.org/wiki/MultiplayerCampaigns Multiplayer Campaigns]. There are a lot of things that still need to be tested outside of simple proof-of-concepts, and yet so few people are working on MP Campaigns (who else is?).

The question is... ''what is a multiplayer campaign?'' There's so many more possibilities that in single player. Is it cooperative, or is it set-up player-vs-player? If it is cooperative, how can it be designed that the players don't just compete indirectly for villages, xp and so on? So that actually, those people work together and are presented with scenarios that challenge their skills at cooperation?

I'm still continuing work on...

== Unnatural Winter (Multiplayer Campaign)(version 1.1.18 - 1.2+) ==
This started out to become a showcase multiplayer campaign - similar to the single-player campaigns in terms of story, where all the player cooperatively solve the missions. The scenarios are designed in a way that the players are tested in their skills to work together strategically - presenting them with a number of simultaneous objectives between which they need to split up their resources and attention.

The only problem was that development took so long. For over a year, only the first scenario was available, which didn't help testing or proving the MP campaigns concept! There were complicated parts in the WML that dealt with difficulty levels, for instance. Finally, in March 2007 Truper and jb ventured to join the team and with their help, a first development version of the second scenario was developed.

You'll find the campaign here: [http://www.wesnoth.org/forum/viewtopic.php?t=12252 An Unnatural Winter]

----
== Trove of Unfinished Ideas... ==
- '''Map Generators''': with the WML nowadays it would be possible to include a standard mp inside a [terrain_mask] on top of a randomly generated map, and with some smart rules create a Map Generator that always stays up-to-date with the latest changes of the standard mp maps (just like Borderland Wars does).

- '''Random Tiles Map Engine''': I really want to make a generalised version of the tile laying WML. This could be so good when used in dungeon/rpg scenarios - or to create random but structured maps for things like MP Survival.

- '''Borderland Wars Generator''': merge the Borderland Wars and Map Generator concepts into one (randomised map _and_ Borderland Wars gameplay). But I yet have to see that there's any interest in the Borderland Wars concept...

- '''Diplomatic/Epic game''': this is an idea that I see some similarity to [http://www.wesnoth.org/forum/viewtopic.php?t=14072 Becephalus' Westeros Map idea], just with more gameplay changes to favour the diplomatic / grand-strategic game. There would be four AI sides representing grand powers. The players could ally with these (and so, indirectly, with or against each other), and then be the active pawns of the struggle. There would be locations granting units to your recruit lists, and possibilities for changing alliances based on actions ('kill my enemy and you can become my friend').

- '''Dungeon Crawl RPG''': something akin to Dwarvish Treasure, but players start out cooperatively, and can then become "traitors" that serve the forces of darkness...

User:Rhuvaen

2007-03-17T13:15:34Z

Rhuvaen:

I like trying new ideas with WML for '''multiplayer Wesnoth''', and here's a collection of links to things I've made. Some of those could be made into something better with a lot more polish, but it takes a lot of time writing and testing the WML.

If you find any of these aren't working with today's version of Wesnoth and you would like to play them, then contact me about it.

== MP Generator Pack (version 0.8 - today) ==
The random generator is a clumsy tool. I was dissatisfied with the unbalanced maps of clumped terrain that I got with the packaged generator scenarios, so I made these - WML files that break and mix the terrains a bit more. Made in the 0.8 days but still working today.

As a second idea, I used tournament-style maps often found in 2v2 and 1v1 play, made a "template" from those maps specifying which terrains should get randomised and applied that template over the generator. The result is tournament maps which have their terrain randomised somewhat.

It's all in the [http://www.wesnoth.org/forum/viewtopic.php?t=4559 MP Generator Pack]

== Random Tiled Maps (version 0.9 - today) ==
These are maps using the PSEUDORANDOM WML function to apply pre-designed "Tiles" (i.e. map pieces) to a map, replacing many hexes at once. The result is still random, while the "tiles" are actually designed by hand. Sometime in version 0.9, the code was changed to use the [terrain_mask] functionality, which was a great aid here.

I only made one scenario to date as a proof-of-concept, but this is definitely an idea I need to come back to! I have already worked on a generalised tile-based map generator, and plan to use it to make a random dungeon scenario one day.
[http://www.wesnoth.org/forum/viewtopic.php?t=6139 Random Tiles Maps]

== Temples and Villages and Dominions ==
This was an attempt at altered victory conditions, specifically conquering a certain number of locations (villages and/or temples). A different gameplay from simply killing all enemy leaders. There were a number of other gimmicks, such as tunnels and temple experience awards (the latter were broken in later version of Wesnoth), but the integration of these game elements into the whole wasn't perfect.

Here you'll find [http://www.wesnoth.org/forum/viewtopic.php?t=5105 Temples and Villages] and [http://www.wesnoth.org/forum/viewtopic.php?t=6310 Dominions]. They are pretty similar to some of [http://www.wesnoth.org/forum/viewtopic.php?t=5204 Hieronymus' Scenarios], which were developed around the same time.

== Borderland Wars (version 1.0.2 - 1.2+) ==
Temples and Villages and Dominions were decent ideas. But why not base that gameplay on the more professional maps that come with the game (and not just rely on my own map-making skills)? Borderland Wars does just that - it takes standard MP maps and adds altered victory conditions and gameplay.
A number of villages are converted into "towns" that need to be captured for victory. Leaders get reassigned after death (no kill-all-leaders victory condition).

You'll find this at [http://www.wesnoth.org/forum/viewtopic.php?t=13631 Borderland Wars Revisited].

== Multi-Player Campaigns (version 1.1.14ish - today) ==
A much asked-for feature, yet something few people tried to do. The beginnings were hacky workarounds trying to recreate the single-player scenario-to-scenario features in multiplayer. Some experimentation around version 1.1.14ish revealed that the basics were actually there, it was possible to set up MP scenarios so that you start with a recall list from the last scenario. It was just still incredibly fiddly!

So I wrote a [http://www.wesnoth.org/forum/viewtopic.php?t=11349 Multi-Player Campaigns HOWTO], which is probably better summarised in the wiki page on [http://www.wesnoth.org/wiki/MultiplayerCampaigns Multiplayer Campaigns]. There are a lot of things that still need to be tested outside of simple proof-of-concepts, and yet so few people are working on MP Campaigns (who else is?).

The question is... ''what is a multiplayer campaign?'' There's so many more possibilities that in single player. Is it cooperative, or is it set-up player-vs-player? If it is cooperative, how can it be designed that the players don't just compete indirectly for villages, xp and so on? So that actually, those people work together and are presented with scenarios that challenge their skills at cooperation?

I'm still continuing work on...

== Unnatural Winter (Multiplayer Campaign)(version 1.1.18 - 1.2+) ==
This started out to become a showcase multiplayer campaign - similar to the single-player campaigns in terms of story, where all the player cooperatively solve the missions. The scenarios are designed in a way that the players are tested in their skills to work together strategically - presenting them with a number of simultaneous objectives between which they need to split up their resources and attention.

The only problem was that development took so long. For over a year, only the first scenario was available, which didn't help testing or proving the MP campaigns concept! There were complicated parts in the WML that dealt with difficulty levels, for instance. Finally, in March 2007 Truper and jb ventured to join the team and with their help, a first development version of the second scenario was developed.

You'll find the campaign here: [http://www.wesnoth.org/forum/viewtopic.php?t=12252 An Unnatural Winter]

----
== Trove of Unfinished Ideas... ==
- '''Map Generators''': with the WML nowadays it would be possible to include a standard mp inside a [terrain_mask] on top of a randomly generated map, and with some smart rules create a Map Generator that always stays up-to-date with the latest changes of the standard mp maps (just like Borderland Wars does).

- '''Random Tiles Map Engine''': I really want to make a generalised version of the tile laying WML. This could be so good when used in dungeon/rpg scenarios - or to create random but structured maps for things like MP Survival.

- '''Borderland Wars Generator''': merge the Borderland Wars and Map Generator concepts into one (randomised map _and_ Borderland Wars gameplay). But I yet have to see that there's any interest in the Borderland Wars concept...

- '''Diplomatic/Epic game''': this is an idea that I see some similarity to [http://www.wesnoth.org/forum/viewtopic.php?t=14072 Becephalus' Westeros Map idea], just with more gameplay changes to favour the diplomatic / grand-strategic game. There would be four AI sides representing grand powers. The players could ally with these (and so, indirectly, with or against each other), and then be the active pawns of the struggle. There would be locations granting units to your recruit lists, and possibilities for changing alliances based on actions ('kill my enemy and you can become my friend').

- '''Dungeon Crawl RPG''': something akin to Dwarvish Treasure, but players start out cooperatively, and can then become "traitors" that serve the forces of darkness...

User:Rhuvaen

2007-03-17T12:56:27Z

Rhuvaen: formatting

I like trying new ideas with WML for '''multiplayer Wesnoth''', and here's a collection of links to things I've made. Many are fairly raw and could be made into something better with a lot more polish, but it takes a lot of time writing and testing the WML.

If you find any of these aren't working with today's version of Wesnoth and you would like to play them, then contact me about it.

== MP Generator Pack (version 0.8 - today) ==
The random generator is a clumsy tool. I was dissatisfied with the unbalanced maps of clumped terrain that I got with the packaged generator scenarios, so I made these - WML files that break and mix the terrains a bit more. Made in the 0.8 days but still working today.

As a second idea, I used tournament-style maps often found in 2v2 and 1v1 play, made a "template" from those maps specifying which terrains should get randomised and applied that template over the generator. The result is tournament maps which have their terrain randomised somewhat.

It's all in the [http://www.wesnoth.org/forum/viewtopic.php?t=4559 MP Generator Pack]

== Random Tiled Maps (version 0.9 - today) ==
These are maps using the PSEUDORANDOM WML function to apply pre-designed "Tiles" (i.e. map pieces) to a map, replacing many hexes at once. The result is still random, while the "tiles" are actually designed by hand. Sometime in version 0.9, the code was changed to use the [terrain_mask] functionality, which was a great aid here.

I only made one scenario to date as a proof-of-concept, but this is definitely an idea I need to come back to! I have already worked on a generalised tile-based map generator, and plan to use it to make a random dungeon scenario one day.
[http://www.wesnoth.org/forum/viewtopic.php?t=6139 Random Tiles Maps]

== Temples and Villages and Dominions ==
This was an attempt at altered victory conditions, specifically conquering a certain number of locations (villages and/or temples). A different gameplay from simply killing all enemy leaders. There were a number of other gimmicks, such as tunnels and temple experience awards (the latter were broken in later version of Wesnoth), but the integration of these game elements into the whole wasn't perfect.

Here you'll find [http://www.wesnoth.org/forum/viewtopic.php?t=5105 Temples and Villages] and [http://www.wesnoth.org/forum/viewtopic.php?t=6310 Dominions]. They are pretty similar to some of [http://www.wesnoth.org/forum/viewtopic.php?t=5204 Hieronymus' Scenarios], which were developed around the same time.

== Borderland Wars (version 1.0.2 - 1.2+) ==
Temples and Villages and Dominions were decent ideas. But why not base that gameplay on the more professional maps that come with the game (and not just rely on my own map-making skills)? Borderland Wars does just that - it takes standard MP maps and adds altered victory conditions and gameplay.
A number of villages are converted into "towns" that need to be captured for victory. Leaders get reassigned after death (no kill-all-leaders victory condition).

You'll find this at [http://www.wesnoth.org/forum/viewtopic.php?t=13631 Borderland Wars Revisited].

== Multi-Player Campaigns (version 1.1.14ish - today) ==
A much asked-for feature, yet something few people tried to do. The beginnings were hacky workarounds trying to recreate the single-player scenario-to-scenario features in multiplayer. Some experimentation around version 1.1.14ish revealed that the basics were actually there, it was possible to set up MP scenarios so that you start with a recall list from the last scenario. It was just still incredibly fiddly!

So I wrote a [http://www.wesnoth.org/forum/viewtopic.php?t=11349 Multi-Player Campaigns HOWTO], which is probably better summarised in the wiki page on [http://www.wesnoth.org/wiki/MultiplayerCampaigns Multiplayer Campaigns]. There are a lot of things that still need to be tested outside of simple proof-of-concepts, and yet so few people are working on MP Campaigns (who else is?).

The question is... ''what is a multiplayer campaign?'' There's so many more possibilities that in single player. Is it cooperative, or is it set-up player-vs-player? If it is cooperative, how can it be designed that the players don't just compete indirectly for villages, xp and so on? So that actually, those people work together and are presented with scenarios that challenge their skills at cooperation?

I'm still continuing work on...

== Unnatural Winter (Multiplayer Campaign)(version 1.1.18 - 1.2+) ==
This started out to become a showcase multiplayer campaign - similar to the single-player campaigns in terms of story, where all the player cooperatively solve the missions. The scenarios are designed in a way that the players are tested in their skills to work together strategically - presenting them with a number of simultaneous objectives between which they need to split up their resources and attention.

The only problem was that development took so long. For over a year, only the first scenario was available, which didn't help testing or proving the MP campaigns concept! There were complicated parts in the WML that dealt with difficulty levels, for instance. Finally, in March 2007 Truper and jb ventured to join the team and with their help, a first development version of the second scenario was developed.

You'll find the campaign here: [http://www.wesnoth.org/forum/viewtopic.php?t=12252 An Unnatural Winter]

----
== Trove of Unfinished Ideas... ==
- '''Map Generators''': with the WML nowadays it would be possible to include a standard mp inside a [terrain_mask] on top of a randomly generated map, and with some smart rules create a Map Generator that always stays up-to-date with the latest changes of the standard mp maps (just like Borderland Wars does).

- '''Random Tiles Map Engine''': I really want to make a generalised version of the tile laying WML. This could be so good when used in dungeon/rpg scenarios - or to create random but structured maps for things like MP Survival.

- '''Borderland Wars Generator''': merge the Borderland Wars and Map Generator concepts into one (randomised map _and_ Borderland Wars gameplay). But I yet have to see that there's any interest in the Borderland Wars concept...

- '''Diplomatic/Epic game''': this is an idea that I see some similarity to [http://www.wesnoth.org/forum/viewtopic.php?t=14072 Becephalus' Westeros Map idea], just with more gameplay changes to favour the diplomatic / grand-strategic game. There would be four AI sides representing grand powers. The players could ally with these (and so, indirectly, with or against each other), and then be the active pawns of the struggle. There would be locations granting units to your recruit lists, and possibilities for changing alliances based on actions ('kill my enemy and you can become my friend').

- '''Dungeon Crawl RPG''': something akin to Dwarvish Treasure, but players start out cooperatively, and can then become "traitors" that serve the forces of darkness...

User:Rhuvaen

2007-03-17T12:54:46Z

Rhuvaen: added ideas section

I like trying new ideas with WML for '''multiplayer Wesnoth''', and here's a collection of links to things I've made. Many are fairly raw and could be made into something better with a lot more polish, but it takes a lot of time writing and testing the WML.

If you find any of these aren't working with today's version of Wesnoth and you would like to play them, then contact me about it.

== MP Generator Pack (version 0.8 - today) ==
The random generator is a clumsy tool. I was dissatisfied with the unbalanced maps of clumped terrain that I got with the packaged generator scenarios, so I made these - WML files that break and mix the terrains a bit more. Made in the 0.8 days but still working today.

As a second idea, I used tournament-style maps often found in 2v2 and 1v1 play, made a "template" from those maps specifying which terrains should get randomised and applied that template over the generator. The result is tournament maps which have their terrain randomised somewhat.

It's all in the [http://www.wesnoth.org/forum/viewtopic.php?t=4559 MP Generator Pack]

== Random Tiled Maps (version 0.9 - today) ==
These are maps using the PSEUDORANDOM WML function to apply pre-designed "Tiles" (i.e. map pieces) to a map, replacing many hexes at once. The result is still random, while the "tiles" are actually designed by hand. Sometime in version 0.9, the code was changed to use the [terrain_mask] functionality, which was a great aid here.

I only made one scenario to date as a proof-of-concept, but this is definitely an idea I need to come back to! I have already worked on a generalised tile-based map generator, and plan to use it to make a random dungeon scenario one day.
[http://www.wesnoth.org/forum/viewtopic.php?t=6139 Random Tiles Maps]

== Temples and Villages and Dominions ==
This was an attempt at altered victory conditions, specifically conquering a certain number of locations (villages and/or temples). A different gameplay from simply killing all enemy leaders. There were a number of other gimmicks, such as tunnels and temple experience awards (the latter were broken in later version of Wesnoth), but the integration of these game elements into the whole wasn't perfect.

Here you'll find [http://www.wesnoth.org/forum/viewtopic.php?t=5105 Temples and Villages] and [http://www.wesnoth.org/forum/viewtopic.php?t=6310 Dominions]. They are pretty similar to some of [http://www.wesnoth.org/forum/viewtopic.php?t=5204 Hieronymus' Scenarios], which were developed around the same time.

== Borderland Wars (version 1.0.2 - 1.2+) ==
Temples and Villages and Dominions were decent ideas. But why not base that gameplay on the more professional maps that come with the game (and not just rely on my own map-making skills)? Borderland Wars does just that - it takes standard MP maps and adds altered victory conditions and gameplay.
A number of villages are converted into "towns" that need to be captured for victory. Leaders get reassigned after death (no kill-all-leaders victory condition).

You'll find this at [http://www.wesnoth.org/forum/viewtopic.php?t=13631 Borderland Wars Revisited].

== Multi-Player Campaigns (version 1.1.14ish - today) ==
A much asked-for feature, yet something few people tried to do. The beginnings were hacky workarounds trying to recreate the single-player scenario-to-scenario features in multiplayer. Some experimentation around version 1.1.14ish revealed that the basics were actually there, it was possible to set up MP scenarios so that you start with a recall list from the last scenario. It was just still incredibly fiddly!

So I wrote a [http://www.wesnoth.org/forum/viewtopic.php?t=11349 Multi-Player Campaigns HOWTO], which is probably better summarised in the wiki page on [http://www.wesnoth.org/wiki/MultiplayerCampaigns Multiplayer Campaigns]. There are a lot of things that still need to be tested outside of simple proof-of-concepts, and yet so few people are working on MP Campaigns (who else is?).

The question is... ''what is a multiplayer campaign?'' There's so many more possibilities that in single player. Is it cooperative, or is it set-up player-vs-player? If it is cooperative, how can it be designed that the players don't just compete indirectly for villages, xp and so on? So that actually, those people work together and are presented with scenarios that challenge their skills at cooperation?

I'm still continuing work on...

== Unnatural Winter (Multiplayer Campaign)(version 1.1.18 - 1.2+) ==
This started out to become a showcase multiplayer campaign - similar to the single-player campaigns in terms of story, where all the player cooperatively solve the missions. The scenarios are designed in a way that the players are tested in their skills to work together strategically - presenting them with a number of simultaneous objectives between which they need to split up their resources and attention.

The only problem was that development took so long. For over a year, only the first scenario was available, which didn't help testing or proving the MP campaigns concept! There were complicated parts in the WML that dealt with difficulty levels, for instance. Finally, in March 2007 Truper and jb ventured to join the team and with their help, a first development version of the second scenario was developed.

You'll find the campaign here: [http://www.wesnoth.org/forum/viewtopic.php?t=12252 An Unnatural Winter]

----
== Trove of Unfinished Ideas... ==
- Map Generators: with the WML nowadays it would be possible to include a standard mp inside a [terrain_mask] on top of a randomly generated map, and with some smart rules create a Map Generator that always stays up-to-date with the latest changes of the standard mp maps (just like Borderland Wars does).

- Random Tiles Map Engine: I really want to make a generalised version of the tile laying WML. This could be so good when used in dungeon/rpg scenarios - or to create random but structured maps for things like MP Survival.

- Borderland Wars Generator: merge the Borderland Wars and Map Generator concepts into one (randomised map _and_ Borderland Wars gameplay)

- Diplomatic/Epic game: this is an idea that I see some similarity to [http://www.wesnoth.org/forum/viewtopic.php?t=14072 Becephalus' Westeros Map idea], just with more gameplay changes to favour the diplomatic / grand-strategic game. There would be four AI sides representing grand powers. The players could ally with these (and so, indirectly, with or against each other), and then be the active pawns of the struggle. There would be locations granting units to your recruit lists, and possibilities for changing alliances based on actions ('kill my enemy and you can become my friend').

- Dungeon Crawl RPG: something akin to Dwarvish Treasure, but players start out cooperatively, and can then become "traitors" that serve the forces of darkness...

User:Rhuvaen

2007-03-17T12:39:30Z

Rhuvaen:

I like trying new ideas with WML for multiplayer Wesnoth, and here's a collection of links to things I've made. Many are fairly raw and could be made into something better with a lot more polish, but it takes a lot of time writing and testing the WML.

== MP Generator Pack (version 0.8 - today) ==
The random generator is a clumsy tool. I was dissatisfied with the unbalanced maps of clumped terrain that I got with the packaged generator scenarios, so I made these - WML files that break and mix the terrains a bit more. Made in the 0.8 days but still working today.

As a second idea, I used tournament-style maps often found in 2v2 and 1v1 play, made a "template" from those maps specifying which terrains should get randomised and applied that template over the generator. The result is tournament maps which have their terrain randomised somewhat.

It's all in the [http://www.wesnoth.org/forum/viewtopic.php?t=4559 MP Generator Pack]

== Random Tiled Maps (version 0.9 - today) ==
These are maps using the PSEUDORANDOM WML function to apply pre-designed "Tiles" (i.e. map pieces) to a map, replacing many hexes at once. The result is still random, while the "tiles" are actually designed by hand. Sometime in version 0.9, the code was changed to use the [terrain_mask] functionality, which was a great aid here.

I only made one scenario to date as a proof-of-concept, but this is definitely an idea I need to come back to! I have already worked on a generalised tile-based map generator, and plan to use it to make a random dungeon scenario one day.
[http://www.wesnoth.org/forum/viewtopic.php?t=6139 Random Tiles Maps]

== Temples and Villages and Dominions ==
This was an attempt at altered victory conditions, specifically conquering a certain number of locations (villages and/or temples). A different gameplay from simply killing all enemy leaders. There were a number of other gimmicks, such as tunnels and temple experience awards (the latter were broken in later version of Wesnoth), but the integration of these game elements into the whole wasn't perfect.

Here you'll find [http://www.wesnoth.org/forum/viewtopic.php?t=5105 Temples and Villages] and [http://www.wesnoth.org/forum/viewtopic.php?t=6310 Dominions]. They are pretty similar to some of [http://www.wesnoth.org/forum/viewtopic.php?t=5204 Hieronymus' Scenarios], which were developed around the same time.

== Borderland Wars (version 1.0.2 - 1.2+) ==
Temples and Villages and Dominions were decent ideas. But why not base that gameplay on the more professional maps that come with the game (and not just rely on my own map-making skills)? Borderland Wars does just that - it takes standard MP maps and adds altered victory conditions and gameplay.
A number of villages are converted into "towns" that need to be captured for victory. Leaders get reassigned after death (no kill-all-leaders victory condition).

You'll find this at [http://www.wesnoth.org/forum/viewtopic.php?t=13631 Borderland Wars Revisited].

== Multi-Player Campaigns (version 1.1.14ish - today) ==
A much asked-for feature, yet something few people tried to do. The beginnings were hacky workarounds trying to recreate the single-player scenario-to-scenario features in multiplayer. Some experimentation around version 1.1.14ish revealed that the basics were actually there, it was possible to set up MP scenarios so that you start with a recall list from the last scenario. It was just still incredibly fiddly!

So I wrote a [http://www.wesnoth.org/forum/viewtopic.php?t=11349 Multi-Player Campaigns HOWTO], which is probably better summarised in the wiki page on [http://www.wesnoth.org/wiki/MultiplayerCampaigns Multiplayer Campaigns]. There are a lot of things that still need to be tested outside of simple proof-of-concepts, and yet so few people are working on MP Campaigns (who else is?).

The question is... ''what is a multiplayer campaign?'' There's so many more possibilities that in single player. Is it cooperative, or is it set-up player-vs-player? If it is cooperative, how can it be designed that the players don't just compete indirectly for villages, xp and so on? So that actually, those people work together and are presented with scenarios that challenge their skills at cooperation?

I'm still continuing work on...

== Unnatural Winter (Multiplayer Campaign)(version 1.1.18 - 1.2+) ==
This started out to become a showcase multiplayer campaign - similar to the single-player campaigns in terms of story, where all the player cooperatively solve the missions. The scenarios are designed in a way that the players are tested in their skills to work together strategically - presenting them with a number of simultaneous objectives between which they need to split up their resources and attention.

The only problem was that development took so long. For over a year, only the first scenario was available, which didn't help testing or proving the MP campaigns concept! There were complicated parts in the WML that dealt with difficulty levels, for instance. Finally, in March 2007 Truper and jb ventured to join the team and with their help, a first development version of the second scenario was developed.

You'll find the campaign here: [http://www.wesnoth.org/forum/viewtopic.php?t=12252 An Unnatural Winter]

User:Rhuvaen

2007-03-17T12:38:48Z

Rhuvaen: added mp campaigns

I like trying new ideas with WML for multiplayer Wesnoth, and here's a collection of links to things I've made. Many are fairly raw and could be made into something better with a lot more polish, but it takes a lot of time writing and testing the WML.

== 1. MP Generator Pack (version 0.8 - today) ==
The random generator is a clumsy tool. I was dissatisfied with the unbalanced maps of clumped terrain that I got with the packaged generator scenarios, so I made these - WML files that break and mix the terrains a bit more. Made in the 0.8 days but still working today.

As a second idea, I used tournament-style maps often found in 2v2 and 1v1 play, made a "template" from those maps specifying which terrains should get randomised and applied that template over the generator. The result is tournament maps which have their terrain randomised somewhat.

It's all in the [http://www.wesnoth.org/forum/viewtopic.php?t=4559 MP Generator Pack]

== 2. Random Tiled Maps (version 0.9 - today) ==
These are maps using the PSEUDORANDOM WML function to apply pre-designed "Tiles" (i.e. map pieces) to a map, replacing many hexes at once. The result is still random, while the "tiles" are actually designed by hand. Sometime in version 0.9, the code was changed to use the [terrain_mask] functionality, which was a great aid here.

I only made one scenario to date as a proof-of-concept, but this is definitely an idea I need to come back to! I have already worked on a generalised tile-based map generator, and plan to use it to make a random dungeon scenario one day.
[http://www.wesnoth.org/forum/viewtopic.php?t=6139 Random Tiles Maps]

== 3. Temples and Villages and Dominions ==
This was an attempt at altered victory conditions, specifically conquering a certain number of locations (villages and/or temples). A different gameplay from simply killing all enemy leaders. There were a number of other gimmicks, such as tunnels and temple experience awards (the latter were broken in later version of Wesnoth), but the integration of these game elements into the whole wasn't perfect.

Here you'll find [http://www.wesnoth.org/forum/viewtopic.php?t=5105 Temples and Villages] and [http://www.wesnoth.org/forum/viewtopic.php?t=6310 Dominions]. They are pretty similar to some of [http://www.wesnoth.org/forum/viewtopic.php?t=5204 Hieronymus' Scenarios], which were developed around the same time.

== 4. Borderland Wars (version 1.0.2 - 1.2+) ==
Temples and Villages and Dominions were decent ideas. But why not base that gameplay on the more professional maps that come with the game (and not just rely on my own map-making skills)? Borderland Wars does just that - it takes standard MP maps and adds altered victory conditions and gameplay.
A number of villages are converted into "towns" that need to be captured for victory. Leaders get reassigned after death (no kill-all-leaders victory condition).

You'll find this at [http://www.wesnoth.org/forum/viewtopic.php?t=13631 Borderland Wars Revisited].

== 5. Multi-Player Campaigns (version 1.1.14ish - today) ==
A much asked-for feature, yet something few people tried to do. The beginnings were hacky workarounds trying to recreate the single-player scenario-to-scenario features in multiplayer. Some experimentation around version 1.1.14ish revealed that the basics were actually there, it was possible to set up MP scenarios so that you start with a recall list from the last scenario. It was just still incredibly fiddly!

So I wrote a [http://www.wesnoth.org/forum/viewtopic.php?t=11349 Multi-Player Campaigns HOWTO], which is probably better summarised in the wiki page on [http://www.wesnoth.org/wiki/MultiplayerCampaigns Multiplayer Campaigns]. There are a lot of things that still need to be tested outside of simple proof-of-concepts, and yet so few people are working on MP Campaigns (who else is?).

The question is... ''what is a multiplayer campaign?'' There's so many more possibilities that in single player. Is it cooperative, or is it set-up player-vs-player? If it is cooperative, how can it be designed that the players don't just compete indirectly for villages, xp and so on? So that actually, those people work together and are presented with scenarios that challenge their skills at cooperation?

I'm still continuing work on...

== 6. Unnatural Winter (Multiplayer Campaign)(version 1.1.18 - 1.2+) ==
This started out to become a showcase multiplayer campaign - similar to the single-player campaigns in terms of story, where all the player cooperatively solve the missions. The scenarios are designed in a way that the players are tested in their skills to work together strategically - presenting them with a number of simultaneous objectives between which they need to split up their resources and attention.

The only problem was that development took so long. For over a year, only the first scenario was available, which didn't help testing or proving the MP campaigns concept! There were complicated parts in the WML that dealt with difficulty levels, for instance. Finally, in March 2007 Truper and jb ventured to join the team and with their help, a first development version of the second scenario was developed.

You'll find the campaign here: [http://www.wesnoth.org/forum/viewtopic.php?t=12252 An Unnatural Winter]

User:Rhuvaen

2007-03-17T12:20:08Z

Rhuvaen: added borderland wars

User:Rhuvaen

2007-03-17T12:10:49Z

Rhuvaen: added temples and villages

User:Rhuvaen

2007-03-17T12:03:14Z

Rhuvaen: added random tiles maps

User:Rhuvaen

2007-03-17T11:58:17Z

Rhuvaen: Created Page

MultiplayerContent

2007-03-17T11:40:31Z

Rhuvaen: /* Scenarios */

== Building multiplayer campaigns ==

Both the stable and development versions of wesnoth have basic support for campaigns that can be played in multiplayer mode, with your friends, or even with an AI. Since version 1.1.8, more features and support have been added so we recommend a versions 1.1.8+. There will still be some things that don't work as expected as multiplayer campaigns are an area for exploration. While you can and should test your work in hotseat mode, there are a number of things that might behave differently under real network conditions (mostly affecting scenario and side parameters). Keep this in mind and make sure to test your campaign over the net, too.
This page only documents the differences between writing multiplayer campaigns and single player campaigns, so you might want to read up on [[BuildingCampaigns]] and [[BuildingMultiplayer]] first.

=== The campaign file ===

Multiplayer campaigns do not use the [campaign] tag. As a result of this, multiplayer campaigns only support one difficulty level, though you could support more with enough WML, if you're feeling ambitious. The "campaign file" should look something like this:

#ifdef MULTIPLAYER
{@campaigns/My_Campaign/scenarios}
#endif

Anything that you would normally put in the campaign tag now goes into the first scenario, if it's supported there. The order of scenarios is determined by next_scenario tags, just like in single player.

=== Scenarios ===

A scenario in a multiplayer campaign is almost identical to a scenario in a single player campaign. You only need to change the following:

* The [scenario] tag should be replaced with a [multiplayer] tag.
* The '''next_scenario''' key points to the id of the next scenario.
* Every scenario after the first should have '''allow_new_game=no''' inside the [multiplayer] tag. This will prevent it from showing up in the map selection menu. ''This does not work in v1.1'', but it causes no harm, and it will work in the future. ''(This still doesn't work in 1.2.2, and even prevents your campaign from working. I suggest you leave this commented out until the bug gets fixed.)''
* In v1.1, every scenario in the campaign will appear on the map selection menu, so be sure to include your campaign's name in the [multiplayer] tag's name key. Alternatively, include a warning like "DO NOT PLAY".
* Each human-controlled side needs to have a '''controller=human''' key defined in their [side] tag to work in network mode.
* Each human-controlled side also needs to have a '''save_id''' defined inside their [side] tag. Each side's save_id should be unique, and it should be the same in every scenario. Without this, your recall lists and leaders will not carry over from one scenario to the next.
* Each AI-controlled side should have '''allow_player=no''' in their [side] tag.
* The [story] tag will only display for the first player (or maybe it's the host player). You'll have to use [message] tags in the start event if you want everyone to read the story.
* If you have a file containing macros, it must be referenced by every scenario, since there is no proper campaign file to include it from.

=== The first scenario ===

The first scenario might need some extra work, because the settings from the multiplayer dialog will override the settings in the scenario. However, most of the multiplayer settings can be overridden in the prestart event.

Use a macro like this to force a side to have a particular type of leader.
#define MP_SIDE SIDENO TYPE DESC
[store_unit]
variable=oldunit
kill=yes
[filter]
side={SIDENO}
[/filter]
[/store_unit]

[unit]
type={TYPE}
description={DESC}
unrenameable=yes
side={SIDENO}
x,y=$oldunit.x,$oldunit.y
canrecruit=1
[/unit]

[clear_variable]
name=oldunit
[/clear_variable]
#enddef

Other useful tags include [set_recruit], [modify_side], [modify_turns] and [remove_shroud]. There is currently no way to remove fog. You might also want to use ''experience_modifier=100'' in the [multiplayer] tag.

=== Custom units ===

Since there is no [campaign] tag, there is no natural way to include custom units in a multiplayer campaign. However, there are two workarounds. One way is to use [[EffectWML]] or [store_unit] to modify a mainline unit. The other way is to make your custom units available via an [[EraWML|era]], or by dropping them into ~wesnoth/data/units. If you go this route, using an era is better, because you can keep the units in your campaign directory.

== See Also ==

* [http://www.wesnoth.org/forum/viewtopic.php?t=11349 Multiplayer Campaigns HOWTO forum post]
* [[BuildingScenarios]]
* [[BuildingMultiplayer]]

GermanTranslationMPCampaign

2006-11-30T14:34:18Z

Rhuvaen: /* Sonstiges */

<h1 style="text-align:center;">Die Chroniken von Elvenmar ~ Das zweite Zeitalter</h1>

<p><em>„Nun hatte die Allianz von Elvenmar den Feind allen Lebens bezwungen. Der verruchte Totenbeschwörer, der
mit seinen Schergen in unser Land kam, um uns zu unterjochen, ist besiegt. Frieden wird wiederkehren in unser Land und die Lande unser Verbündeten. Doch bevor wir den Totenbeschwörer überwanden, sprach er einen Fluch aus, dass er zurückkehren würde, um Rache zu nehmen.“</em></p>

<p style="text-align:right; margin-bottom:0px;"><em>Liorundel Morgentau, Chronist von Elvenmar</em></p>

== Helden ==

<div style="float:left;">http://wesnoth.slack.it/wesnoth-images/units/elves-wood/marksman.png</div>
'''Eldarion Mistelzweig'''

Eldarion ist ein Kind der Sippe Mistelzweig, die sich zusammen mit vielen anderen Sippen in den westlichen Wäldern von Wesnoth niedergelassen haben. In seiner Kindheit stellte sich heraus, dass er eine besondere Begabung dafür hatte, mit dem Bogen selbst die kleinsten Ziele zu treffen. Kurze Zeit später wurde er nach Elvenmar geschickt, um dort in die Reihen der elfischen Bogenschützen aufgenommen zu werden, auf das seine Fähigkeiten vollendet werden sollten. Während all der Jahre die er in der elfischen Haupstadt verbrachte, lernte er die junge Waldfee Fjoergyn kennen, mit der ihn seither ein mächtiges Band der Freundschaft verbindet. Seit die Untoten wieder zurückgekehrt sind, führt Eldarion kleinere Truppenverbände gegen den Feind der Elfen in die Schlacht.

<div class="visualClear"></div>

<div style="float:left;">http://wesnoth.slack.it/wesnoth-images/units/elves-wood/shyde.png</div>
'''Fjoergyn, Hüterin von Elvenmar'''

Fjoergyn ist in den weitläufigen Elfenwäldern in Wesnoth aufgewachsen und hat schon als kleines Elfenmädchen viel
über die Heilkunst ihrer Sippe gelernt. Als junge Waldfee wurde Fjoergyn von ihren Eltern nach Elvenmar geschickt um dort von den besten Heilerinnen Wesnoths unterrichtet zu werden. In Elvenmar traf sie Eldarion Mistelzweig mit dem sie seither oft Seite an Seite gekämpft hat. Fjoergyn ist mutig und tapfer auf dem Schlachtfeld und schnell zur Stelle wenn eine Schwester oder ein Bruder Hilfe braucht. Manchmal ist sie allerdings etwas ungeduldig.

<div class="visualClear"></div>

<div style="float:left;">http://wesnoth.slack.it/wesnoth-images/units/human-magi/white-mage.png</div>
'''Zoran von Oxid'''

Zoran wurde als erster Sohn des Fürsten von Oxid, welcher damals einen großen Landstrich in Wesnoth regierte, geboren. Als er sein siebentes Lebensjahr vollendet hatte, bemerkte man, dass Zoran die Veranlagung besaß, Magie zu wirken. So wurde er zum Orden des weissen Pentagramms geschickt, um ihn in den Künsten der Heilmagie und der Bannzauberei ausbilden zu lassen. Kurz nach Vollendung seines 17. Lebensjahres kehrte er in ein Fürstentum zurück, von dessen ehemaligem Glanz nur noch wenig zu sehen war. Sein Bruder Byrial hatte inzwischen die Regierungsgewalt erlangt und herrschte mit Schrecken und Unterdrückung. Schlussendlich schaffte es Zoran, seinen rechtmäßigen Platz als Thronfolger einzunehmen. Da er sich jedoch als Magier um die Belange des Ordens kümmern musste, überließ er den Thron einem guten Freund seines Vaters.

<div class="visualClear"></div>

<div style="float:left;">http://wesnoth.slack.it/wesnoth-images/units/saurians/ambusher.png</div>
'''Skaz'''

Als Jüngster von drei Geschwistern, wuchs der saurianische Krieger in einem der Sümpfe im Südwesten von Wesnoth auf. Genau wie der Rest der Familie, sollte Skaz den Weg des einfachen Soldaten einschlagen. Doch schon kurz nachdem er in die Armee eingetreten war, stellte sich heraus, - durch sein Geschick im Nahkampf und seiner Fähigkeit andere für eine Sache zu begeistern - dass er zu Höherem berufen war. Seine Schwäche im Fernkampf fiel dagegen wegen seines taktischen Vorgehens auf dem Schlachtfeld und seines Wissens über diverse Kriegsstrategien kaum ins Gewicht. Nachdem er im Kampf gegen den finsteren Magier Laurentius einige seiner besten Freunde verlor, wurde ihm von saurianischen Tribunal das Kommando über die saurianischen Truppen übertragen.

<div class="visualClear"></div>

<div style="float:left;"></div>
'''Die Rote Zora'''

Zora floh als Kind aus einer Stadt im Norden von Wesnoth, die durch einen furchtbaren Krieg zwischen Trollen und Menschen zerstört wurde. Sie war eine der wenigen, die die Kämpfe überlebten - auch ihre Eltern fielen den Trollen zum Opfer. Bald fand sie Anschluss an eine Gruppe von Gauklern und fahrendem Volk, welche sich mit ziemlich dunklen Geschäften über Wasser hielt. Als sie etwa 20 Jahre alt war, kam es nach einen Raubzug beim Streit um die Beute zu einer Ausseinandersetzung, bei dem sie den alten Anführer (welcher von Gier getrieben die Beute ungleich teilen wollte) tödlich mit ihrem Kampfstab verletzte. Daraufhin zerfiel die Gruppe und Zora zog sich mit wenigen Vertrauten in die nahegelegenen Wälder zurück, um fortan ihre eigene Diebesbande zu führen. Ihr Name rührt wohl zum einen von ihrer Haarfarbe und zum anderem von ihrem sehr ausgeprägten Gerechtigkeitsinn her.

<div class="visualClear"></div>

== Schurken ==

<div style="float:left;">http://wesnoth.slack.it/wesnoth-images/units/undead/shadow.png</div>
''' Asgarath, Herr der Plagen, die verzehrende Finsternis, eine dämonische Wesenheit '''

<div class="visualClear"></div>

<div style="float:left;">http://wesnoth.slack.it/wesnoth-images/units/undead-necromancers/dark_sorcerer.png</div>
''' Laurentius '''

<div class="visualClear"></div>

<div style="float:left;"></div>
''' Wladuch, Laurentius Schüler '''

Wladuch ist Laurentius Schüler, der seinem Meister in nichts nachsteht. Er hat sich, wie viele Dunkle Adepten, vollständig dem Studium der Schwarzen Künste verschrieben. Nachdem Laurentius früherer Schüler bei einer Beschwörung ums Leben kam, war dieser auf der Suche nach einem neuen Schüler. In Wladuch fand er jenen, der seinen Ansprüchen genügte. Laurentius verlieh ihm als Zeichen den Todesdolch, ein mächtiges Artefakt, das beseelt ist. Die Waffe produziert ein tödliches Gift aus sich selbst heraus und führt die Hand des Trägers zum Ziel.

<div class="visualClear"></div>

<div style="float:left;">http://wesnoth.slack.it/wesnoth-images/units/trolls/great-troll.png</div>
''' Guhrath '''

<div class="visualClear"></div>

== Ort und Zeit ==

== Szenarios ==

<div style="float:left;">http://wesnoth.kpm-sport.de/CvE_Szenario1.jpeg</div>
''' Szenario 1 - Die Kugel der Eifersucht '''

Nicht weit entfernt der elfischen Hauptstadt tobt eine Schlacht zwischen den Saurianern und den Draken. Die Saurianer entsenden einen Boten nach Elvenmar, um die Elfen um Hilfe zu bitten. Erstaunt darüber, dass die Saurianer von Drachen angegriffen werden, wird Eldarion entsandt, um dieses merkwürdige Vorkommnis zu untersuchen. Die Elfen glauben nicht an einen Angriff der von Drachen verursacht wurde. Dafür entdecken Eldarions Späher einen Hexenmeister der Untoten, der sich in dem nahegelegen Sumpfgebiet niedergelassen hat. Als sich herausstellt, dass es tatsächlich drachenähnliche Wesen sind, mit denen die Saurianer im Krieg liegen, ist es den untoten Horden bereits gelungen, die Festung der Elfen einzunehmen. Eldarion schickt zwei seiner Bogenschützen, Delorien und Eärewen mit den saurianischen Kriegern nach Westen, um den Hort der Drachen ausfindig zu machen. Kurze Zeit später legen die Saurianer und die Draken ihren Konflikt bei, der nur aus einem Missverständniss entstanden war. Die Saurianer hatten geglaubt, dass ihre Ahnen sie versklaven wollten. Dafür verantwortlich war ein mächtiges Artefakt, '''Eine Kugel der Eifersucht''', die Delorien in dem verlassenen Drachenhort fand. Eine Vorhut der untoten Streitkräfte hatte bereits den Drachenhort erreicht, um die Spuren zu verwischen, doch glücklicherweise kamen ihr einige Saurianer zur Hilfe, allen vorran Skaz. Die beiden können sich zurück zur Burg der Saurianer retten und dem Bündniss aus Draken, Saurianern und Elfen gelingt es schließlich, den Untoten zurückzuschlagen. Danach tratt Eldarion mit seinen Mitstreitern, zu denen jetzt auch Skaz gehörte, der nicht mehr von Deloriens Seite wich, den Rückweg nach Elvenmar an, um dort die Kugel zerstören zu lassen.

<div class="visualClear"></div>

<div style="float:left;">http://wesnoth.kpm-sport.de/CvE_Szenario2.jpeg</div>
''' Szenario 2 - Der Weg nach Elvenmar '''

<div class="visualClear"></div>

<div style="float:left;">http://wesnoth.kpm-sport.de/CvE_Szenario3.jpeg</div>
''' Szenario 3 - Schwarz und Weiß '''

<div class="visualClear"></div>

<div style="float:left;">http://wesnoth.kpm-sport.de/CvE_Szenario3.jpeg</div>
''' Szenario 4 - Die Schlacht um Elvenmar '''

<div class="visualClear"></div>

<div style="float:left;">http://wesnoth.kpm-sport.de/CvE_Szenario5.jpeg</div>
''' Szenario 5 - Der Turm von Shalyn'fey'''

<div class="visualClear"></div>

<div style="float:left;">http://wesnoth.kpm-sport.de/CvE_Szenario6.jpeg</div>
''' Szenario 6 - Die Sphäre des Schattens '''

<div class="visualClear"></div>

<div style="float:left;">http://wesnoth.kpm-sport.de/CvE_Szenario7.jpeg</div>
''' Szenario 7 - Gerettet? '''

<div class="visualClear"></div>

<div style="float:left;">http://wesnoth.kpm-sport.de/CvE_Szenario7.jpeg</div>
''' Szenario 8 - Asgaraths Helfer '''

<div class="visualClear"></div>

== Sonstiges ==
[http://wesnoth.kpm-sport.de/CvE.tar.bz2 Herunterladen der Kampagne]

[http://www.wesnoth.org/forum/viewtopic.php?t=14032 Überarbeitung der Kampagne für BfW 1.1.12+]

[[GermanTranslation|Deutsche Übersetzung]]

GermanTranslationMPCampaign

2006-11-29T18:31:59Z

Rhuvaen: /* Helden */

GermanTranslationMPCampaign

2006-11-28T14:30:58Z

Rhuvaen: /* Helden */

<h1 style="text-align:center;">Die Chroniken von Elvenmar ~ Das zweite Zeitalter</h1>

<p><em>„Nun hatte die Allianz von Elvenmar den Feind allen Lebens bezwungen. Der verruchte Totenbeschwörer, der
mit seinen Schergen in unser Land kam, um uns zu unterjochen, ist besiegt. Frieden wird wiederkehren in unser Land und die Lande unser Verbündeten. Doch bevor wir den Totenbeschwörer überwanden, sprach er einen Fluch aus, dass er zurückkehren würde, um Rache zu nehmen.“</em></p>

<p style="text-align:right; margin-bottom:0px;"><em>Liorundel Morgentau, Chronist von Elvenmar</em></p>

----
<p style="text-align:center; color=blue;">Hallo, Entwickler dieser Kampagne! <em>Rhuvaen</em> würde gerne Euer Werk ins Englische übersetzen und als Multiplayer Kampagne, die man über das Netzwerk spielen kann, umsetzen. Bitte meldet Euch doch mal im Forum http://www.wesnoth.org/forum/viewtopic.php?t=13877, danke!</p>
----

== Helden ==

<div style="float:left;">http://wesnoth.slack.it/wesnoth-images/units/elves-wood/marksman.png</div>
'''Eldarion Mistelzweig'''

Eldarion ist ein Kind der Sippe Mistelzweig, die sich zusammen mit vielen anderen Sippen in den westlichen Wäldern von Wesnoth niedergelassen haben. In seiner Kindheit stellte sich heraus, dass er eine besondere Begabung dafür hatte, mit dem Bogen selbst die kleinsten Ziele zu treffen. Kurze Zeit später wurde er nach Elvenmar geschickt, um dort in die Reihen der elfischen Bogenschützen aufgenommen zu werden, auf das seine Fähigkeiten vollendet werden sollten. Während all der Jahre die er in der elfischen Haupstadt verbrachte, lernte er die junge Waldfee Fjoergyn kennen, mit der ihn seither ein mächtiges Band der Freundschaft verbindet. Seit die Untoten wieder zurückgekehrt sind, führt Eldarion kleinere Truppenverbände gegen den Feind der Elfen in die Schlacht.

<div class="visualClear"></div>

<div style="float:left;">http://wesnoth.slack.it/wesnoth-images/units/elves-wood/shyde.png</div>
'''Fjoergyn, Hüterin von Elvenmar'''

Fjoergyn ist in den weitläufigen Elfenwäldern in Wesnoth aufgewachsen und hat schon als kleines Elfenmädchen viel
über die Heilkunst ihrer Sippe gelernt. Als junge Waldfee wurde Fjoergyn von ihren Eltern nach Elvenmar geschickt um dort von den besten Heilerinnen Wesnoths unterrichtet zu werden. In Elvenmar traf sie Eldarion Mistelzweig mit dem sie seither oft Seite an Seite gekämpft hat. Fjoergyn ist mutig und tapfer auf dem Schlachtfeld und schnell zur Stelle wenn eine Schwester oder ein Bruder Hilfe braucht. Manchmal ist sie allerdings etwas ungeduldig.

<div class="visualClear"></div>

<div style="float:left;">http://wesnoth.slack.it/wesnoth-images/units/human-magi/white-mage.png</div>
'''Zoran von Oxid'''

Zoran wurde als erster Sohn des Fürsten von Oxid, welcher damals einen großen Landstrich in Wesnoth regierte, geboren. Als er sein siebentes Lebensjahr vollendet hatte, bemerkte man, dass Zoran die Veranlagung besaß, Magie zu wirken. So wurde er zum Orden des weissen Pentagramms geschickt, um ihn in den Künsten der Heilmagie und der Bannzauberei ausbilden zu lassen. Kurz nach Vollendung seines 17. Lebensjahres kehrte er in ein Fürstentum zurück, von dessen ehemaligem Glanz nur noch wenig zu sehen war. Sein Bruder Byrial hatte inzwischen die Regierungsgewalt erlangt und herrschte mit Schrecken und Unterdrückung. Schlussendlich schaffte es Zoran, seinen rechtmäßigen Platz als Thronfolger einzunehmen. Da er sich jedoch als Magier um die Belange des Ordens kümmern musste, überließ er den Thron einem guten Freund seines Vaters.

<div class="visualClear"></div>

<div style="float:left;">http://wesnoth.slack.it/wesnoth-images/units/saurians/ambusher.png</div>
'''Skaz'''

Als Jüngster von drei Geschwistern, wuchs der saurianische Krieger in einem der Sümpfe im Südwesten von Wesnoth auf. Genau wie der Rest der Familie, sollte Skaz den Weg des einfachen Soldaten einschlagen. Doch schon kurz nachdem er in die Armee eingetreten war, stellte sich heraus, - durch sein Geschick im Nahkampf und seiner Fähigkeit andere für eine Sache zu begeistern - dass er zu Höherem berufen war. Seine Schwäche im Fernkampf fiel dagegen wegen seines taktischen Vorgehens auf dem Schlachtfeld und seines Wissens über diverse Kriegsstrategien kaum ins Gewicht. Nachdem er im Kampf gegen den finsteren Magier Laurentius einige seiner besten Freunde verlor, wurde ihm von saurianischen Tribunal das Kommando über die saurianischen Truppen übertragen.

<div class="visualClear"></div>

<div style="float:left;"></div>
'''Die Rote Zora'''

Zora floh als Kind aus einer Stadt im Norden von Wesnoth, die durch einen furchtbaren Krieg zwischen Trollen und Menschen zerstört wurde. Sie war eine der wenigen, die die Kämpfe überlebten - auch ihre Eltern fielen den Trollen zum Opfer. Bald fand sie Anschluss an eine Gruppe von Gauklern und fahrendem Volk, welche sich mit ziemlich dunklen Geschäften über Wasser hielt. Als sie etwa 20 Jahre alt war, kam es nach einen Raubzug beim Streit um die Beute zu einer Ausseinandersetzung, bei dem sie den alten Anführer (welcher von Gier getrieben die Beute ungleich teilen wollte) tödlich mit ihrem Kampfstab verletzte. Daraufhin zerfiel die Gruppe und Zora zog sich mit wenigen Vertrauten in die nahegelegenen Wälder zurück, um fortan ihre eigene Diebesbande zu führen. Ihr Name rührt wohl zum einen von ihrer Haarfarbe und zum anderem von ihrem sehr ausgeprägten Gerechtigkeitsinn her.

<div class="visualClear"></div>

== Schurken ==

<div style="float:left;">http://wesnoth.slack.it/wesnoth-images/units/undead/shadow.png</div>
''' Asgarath, Herr der Plagen, die verzehrende Finsternis, eine dämonische Wesenheit '''

<div class="visualClear"></div>

<div style="float:left;">http://wesnoth.slack.it/wesnoth-images/units/undead-necromancers/dark_sorcerer.png</div>
''' Laurentius '''

<div class="visualClear"></div>

<div style="float:left;"></div>
''' Wladuch, Laurentius Schüler '''

Wladuch ist Laurentius Schüler, der seinem Meister in nichts nachsteht. Er hat sich, wie viele Dunkle Adepten, vollständig dem Studium der Schwarzen Künste verschrieben. Nachdem Laurentius früherer Schüler bei einer Beschwörung ums Leben kam, war dieser auf der Suche nach einem neuen Schüler. In Wladuch fand er jenen, der seinen Ansprüchen genügte. Laurentius verlieh ihm als Zeichen den Todesdolch, ein mächtiges Artefakt, das beseelt ist. Die Waffe produziert ein tödliches Gift aus sich selbst heraus und führt die Hand des Trägers zum Ziel.

<div class="visualClear"></div>

<div style="float:left;">http://wesnoth.slack.it/wesnoth-images/units/trolls/great-troll.png</div>
''' Guhrath '''

<div class="visualClear"></div>

== Ort und Zeit ==

== Szenarios ==

<div style="float:left;">http://wesnoth.kpm-sport.de/CvE_Szenario1.jpeg</div>
''' Szenario 1 - Die Kugel der Eifersucht '''

Nicht weit entfernt der elfischen Hauptstadt tobt eine Schlacht zwischen den Saurianern und den Draken. Die Saurianer entsenden einen Boten nach Elvenmar, um die Elfen um Hilfe zu bitten. Erstaunt darüber, dass die Saurianer von Drachen angegriffen werden, wird Eldarion entsandt, um dieses merkwürdige Vorkommnis zu untersuchen. Die Elfen glauben nicht an einen Angriff der von Drachen verursacht wurde. Dafür entdecken Eldarions Späher einen Hexenmeister der Untoten, der sich in dem nahegelegen Sumpfgebiet niedergelassen hat. Als sich herausstellt, dass es tatsächlich drachenähnliche Wesen sind, mit denen die Saurianer im Krieg liegen, ist es den untoten Horden bereits gelungen, die Festung der Elfen einzunehmen. Eldarion schickt zwei seiner Bogenschützen, Delorien und Eärewen mit den saurianischen Kriegern nach Westen, um den Hort der Drachen ausfindig zu machen. Kurze Zeit später legen die Saurianer und die Draken ihren Konflikt bei, der nur aus einem Missverständniss entstanden war. Die Saurianer hatten geglaubt, dass ihre Ahnen sie versklaven wollten. Dafür verantwortlich war ein mächtiges Artefakt, '''Eine Kugel der Eifersucht''', die Delorien in dem verlassenen Drachenhort fand. Eine Vorhut der untoten Streitkräfte hatte bereits den Drachenhort erreicht, um die Spuren zu verwischen, doch glücklicherweise kamen ihr einige Saurianer zur Hilfe, allen vorran Skaz. Die beiden können sich zurück zur Burg der Saurianer retten und dem Bündniss aus Draken, Saurianern und Elfen gelingt es schließlich, den Untoten zurückzuschlagen. Danach tratt Eldarion mit seinen Mitstreitern, zu denen jetzt auch Skaz gehörte, der nicht mehr von Deloriens Seite wich, den Rückweg nach Elvenmar an, um dort die Kugel zerstören zu lassen.

<div class="visualClear"></div>

<div style="float:left;">http://wesnoth.kpm-sport.de/CvE_Szenario2.jpeg</div>
''' Szenario 2 - Der Weg nach Elvenmar '''

<div class="visualClear"></div>

<div style="float:left;">http://wesnoth.kpm-sport.de/CvE_Szenario3.jpeg</div>
''' Szenario 3 - Schwarz und Weiß '''

<div class="visualClear"></div>

<div style="float:left;">http://wesnoth.kpm-sport.de/CvE_Szenario3.jpeg</div>
''' Szenario 4 - Die Schlacht um Elvenmar '''

<div class="visualClear"></div>

<div style="float:left;">http://wesnoth.kpm-sport.de/CvE_Szenario5.jpeg</div>
''' Szenario 5 - Der Turm von Shalyn'fey'''

<div class="visualClear"></div>

<div style="float:left;">http://wesnoth.kpm-sport.de/CvE_Szenario6.jpeg</div>
''' Szenario 6 - Die Sphäre des Schattens '''

<div class="visualClear"></div>

<div style="float:left;">http://wesnoth.kpm-sport.de/CvE_Szenario7.jpeg</div>
''' Szenario 7 - Gerettet? '''

<div class="visualClear"></div>

<div style="float:left;">http://wesnoth.kpm-sport.de/CvE_Szenario7.jpeg</div>
''' Szenario 8 - Asgaraths Helfer '''

<div class="visualClear"></div>

== Sonstiges ==
[http://wesnoth.kpm-sport.de/CvE.tar.bz2 Herunterladen der Kampagne]

[[GermanTranslation|Deutsche Übersetzung]]

GermanTranslationMPCampaign

2006-11-28T14:29:15Z

Rhuvaen: /* Helden */

<h1 style="text-align:center;">Die Chroniken von Elvenmar ~ Das zweite Zeitalter</h1>

<p><em>„Nun hatte die Allianz von Elvenmar den Feind allen Lebens bezwungen. Der verruchte Totenbeschwörer, der
mit seinen Schergen in unser Land kam, um uns zu unterjochen, ist besiegt. Frieden wird wiederkehren in unser Land und die Lande unser Verbündeten. Doch bevor wir den Totenbeschwörer überwanden, sprach er einen Fluch aus, dass er zurückkehren würde, um Rache zu nehmen.“</em></p>

<p style="text-align:right; margin-bottom:0px;"><em>Liorundel Morgentau, Chronist von Elvenmar</em></p>

<p style="text-align:center; color=blue;">Hallo, Entwickler dieser Kampagne! <em>Rhuvaen</em> würde gerne Euer Werk ins Englische übersetzen und als Multiplayer Kampagne, die man über das Netzwerk spielen kann, umsetzen. Bitte meldet Euch doch mal im Forum http://www.wesnoth.org/forum/viewtopic.php?t=13877, danke!</p>

== Helden ==

<div style="float:left;">http://wesnoth.slack.it/wesnoth-images/units/elves-wood/marksman.png</div>
'''Eldarion Mistelzweig'''

Eldarion ist ein Kind der Sippe Mistelzweig, die sich zusammen mit vielen anderen Sippen in den westlichen Wäldern von Wesnoth niedergelassen haben. In seiner Kindheit stellte sich heraus, dass er eine besondere Begabung dafür hatte, mit dem Bogen selbst die kleinsten Ziele zu treffen. Kurze Zeit später wurde er nach Elvenmar geschickt, um dort in die Reihen der elfischen Bogenschützen aufgenommen zu werden, auf das seine Fähigkeiten vollendet werden sollten. Während all der Jahre die er in der elfischen Haupstadt verbrachte, lernte er die junge Waldfee Fjoergyn kennen, mit der ihn seither ein mächtiges Band der Freundschaft verbindet. Seit die Untoten wieder zurückgekehrt sind, führt Eldarion kleinere Truppenverbände gegen den Feind der Elfen in die Schlacht.

<div class="visualClear"></div>

<div style="float:left;">http://wesnoth.slack.it/wesnoth-images/units/elves-wood/shyde.png</div>
'''Fjoergyn, Hüterin von Elvenmar'''

Fjoergyn ist in den weitläufigen Elfenwäldern in Wesnoth aufgewachsen und hat schon als kleines Elfenmädchen viel
über die Heilkunst ihrer Sippe gelernt. Als junge Waldfee wurde Fjoergyn von ihren Eltern nach Elvenmar geschickt um dort von den besten Heilerinnen Wesnoths unterrichtet zu werden. In Elvenmar traf sie Eldarion Mistelzweig mit dem sie seither oft Seite an Seite gekämpft hat. Fjoergyn ist mutig und tapfer auf dem Schlachtfeld und schnell zur Stelle wenn eine Schwester oder ein Bruder Hilfe braucht. Manchmal ist sie allerdings etwas ungeduldig.

<div class="visualClear"></div>

<div style="float:left;">http://wesnoth.slack.it/wesnoth-images/units/human-magi/white-mage.png</div>
'''Zoran von Oxid'''

Zoran wurde als erster Sohn des Fürsten von Oxid, welcher damals einen großen Landstrich in Wesnoth regierte, geboren. Als er sein siebentes Lebensjahr vollendet hatte, bemerkte man, dass Zoran die Veranlagung besaß, Magie zu wirken. So wurde er zum Orden des weissen Pentagramms geschickt, um ihn in den Künsten der Heilmagie und der Bannzauberei ausbilden zu lassen. Kurz nach Vollendung seines 17. Lebensjahres kehrte er in ein Fürstentum zurück, von dessen ehemaligem Glanz nur noch wenig zu sehen war. Sein Bruder Byrial hatte inzwischen die Regierungsgewalt erlangt und herrschte mit Schrecken und Unterdrückung. Schlussendlich schaffte es Zoran, seinen rechtmäßigen Platz als Thronfolger einzunehmen. Da er sich jedoch als Magier um die Belange des Ordens kümmern musste, überließ er den Thron einem guten Freund seines Vaters.

<div class="visualClear"></div>

<div style="float:left;">http://wesnoth.slack.it/wesnoth-images/units/saurians/ambusher.png</div>
'''Skaz'''

Als Jüngster von drei Geschwistern, wuchs der saurianische Krieger in einem der Sümpfe im Südwesten von Wesnoth auf. Genau wie der Rest der Familie, sollte Skaz den Weg des einfachen Soldaten einschlagen. Doch schon kurz nachdem er in die Armee eingetreten war, stellte sich heraus, - durch sein Geschick im Nahkampf und seiner Fähigkeit andere für eine Sache zu begeistern - dass er zu Höherem berufen war. Seine Schwäche im Fernkampf fiel dagegen wegen seines taktischen Vorgehens auf dem Schlachtfeld und seines Wissens über diverse Kriegsstrategien kaum ins Gewicht. Nachdem er im Kampf gegen den finsteren Magier Laurentius einige seiner besten Freunde verlor, wurde ihm von saurianischen Tribunal das Kommando über die saurianischen Truppen übertragen.

<div class="visualClear"></div>

<div style="float:left;"></div>
'''Die Rote Zora'''

Zora floh als Kind aus einer Stadt im Norden von Wesnoth, die durch einen furchtbaren Krieg zwischen Trollen und Menschen zerstört wurde. Sie war eine der wenigen, die die Kämpfe überlebten - auch ihre Eltern fielen den Trollen zum Opfer. Bald fand sie Anschluss an eine Gruppe von Gauklern und fahrendem Volk, welche sich mit ziemlich dunklen Geschäften über Wasser hielt. Als sie etwa 20 Jahre alt war, kam es nach einen Raubzug beim Streit um die Beute zu einer Ausseinandersetzung, bei dem sie den alten Anführer (welcher von Gier getrieben die Beute ungleich teilen wollte) tödlich mit ihrem Kampfstab verletzte. Daraufhin zerfiel die Gruppe und Zora zog sich mit wenigen Vertrauten in die nahegelegenen Wälder zurück, um fortan ihre eigene Diebesbande zu führen. Ihr Name rührt wohl zum einen von ihrer Haarfarbe und zum anderem von ihrem sehr ausgeprägten Gerechtigkeitsinn her.

<div class="visualClear"></div>

== Schurken ==

<div style="float:left;">http://wesnoth.slack.it/wesnoth-images/units/undead/shadow.png</div>
''' Asgarath, Herr der Plagen, die verzehrende Finsternis, eine dämonische Wesenheit '''

<div class="visualClear"></div>

<div style="float:left;">http://wesnoth.slack.it/wesnoth-images/units/undead-necromancers/dark_sorcerer.png</div>
''' Laurentius '''

<div class="visualClear"></div>

<div style="float:left;"></div>
''' Wladuch, Laurentius Schüler '''

Wladuch ist Laurentius Schüler, der seinem Meister in nichts nachsteht. Er hat sich, wie viele Dunkle Adepten, vollständig dem Studium der Schwarzen Künste verschrieben. Nachdem Laurentius früherer Schüler bei einer Beschwörung ums Leben kam, war dieser auf der Suche nach einem neuen Schüler. In Wladuch fand er jenen, der seinen Ansprüchen genügte. Laurentius verlieh ihm als Zeichen den Todesdolch, ein mächtiges Artefakt, das beseelt ist. Die Waffe produziert ein tödliches Gift aus sich selbst heraus und führt die Hand des Trägers zum Ziel.

<div class="visualClear"></div>

<div style="float:left;">http://wesnoth.slack.it/wesnoth-images/units/trolls/great-troll.png</div>
''' Guhrath '''

<div class="visualClear"></div>

== Ort und Zeit ==

== Szenarios ==

<div style="float:left;">http://wesnoth.kpm-sport.de/CvE_Szenario1.jpeg</div>
''' Szenario 1 - Die Kugel der Eifersucht '''

Nicht weit entfernt der elfischen Hauptstadt tobt eine Schlacht zwischen den Saurianern und den Draken. Die Saurianer entsenden einen Boten nach Elvenmar, um die Elfen um Hilfe zu bitten. Erstaunt darüber, dass die Saurianer von Drachen angegriffen werden, wird Eldarion entsandt, um dieses merkwürdige Vorkommnis zu untersuchen. Die Elfen glauben nicht an einen Angriff der von Drachen verursacht wurde. Dafür entdecken Eldarions Späher einen Hexenmeister der Untoten, der sich in dem nahegelegen Sumpfgebiet niedergelassen hat. Als sich herausstellt, dass es tatsächlich drachenähnliche Wesen sind, mit denen die Saurianer im Krieg liegen, ist es den untoten Horden bereits gelungen, die Festung der Elfen einzunehmen. Eldarion schickt zwei seiner Bogenschützen, Delorien und Eärewen mit den saurianischen Kriegern nach Westen, um den Hort der Drachen ausfindig zu machen. Kurze Zeit später legen die Saurianer und die Draken ihren Konflikt bei, der nur aus einem Missverständniss entstanden war. Die Saurianer hatten geglaubt, dass ihre Ahnen sie versklaven wollten. Dafür verantwortlich war ein mächtiges Artefakt, '''Eine Kugel der Eifersucht''', die Delorien in dem verlassenen Drachenhort fand. Eine Vorhut der untoten Streitkräfte hatte bereits den Drachenhort erreicht, um die Spuren zu verwischen, doch glücklicherweise kamen ihr einige Saurianer zur Hilfe, allen vorran Skaz. Die beiden können sich zurück zur Burg der Saurianer retten und dem Bündniss aus Draken, Saurianern und Elfen gelingt es schließlich, den Untoten zurückzuschlagen. Danach tratt Eldarion mit seinen Mitstreitern, zu denen jetzt auch Skaz gehörte, der nicht mehr von Deloriens Seite wich, den Rückweg nach Elvenmar an, um dort die Kugel zerstören zu lassen.

<div class="visualClear"></div>

<div style="float:left;">http://wesnoth.kpm-sport.de/CvE_Szenario2.jpeg</div>
''' Szenario 2 - Der Weg nach Elvenmar '''

<div class="visualClear"></div>

<div style="float:left;">http://wesnoth.kpm-sport.de/CvE_Szenario3.jpeg</div>
''' Szenario 3 - Schwarz und Weiß '''

<div class="visualClear"></div>

<div style="float:left;">http://wesnoth.kpm-sport.de/CvE_Szenario3.jpeg</div>
''' Szenario 4 - Die Schlacht um Elvenmar '''

<div class="visualClear"></div>

<div style="float:left;">http://wesnoth.kpm-sport.de/CvE_Szenario5.jpeg</div>
''' Szenario 5 - Der Turm von Shalyn'fey'''

<div class="visualClear"></div>

<div style="float:left;">http://wesnoth.kpm-sport.de/CvE_Szenario6.jpeg</div>
''' Szenario 6 - Die Sphäre des Schattens '''

<div class="visualClear"></div>

<div style="float:left;">http://wesnoth.kpm-sport.de/CvE_Szenario7.jpeg</div>
''' Szenario 7 - Gerettet? '''

<div class="visualClear"></div>

<div style="float:left;">http://wesnoth.kpm-sport.de/CvE_Szenario7.jpeg</div>
''' Szenario 8 - Asgaraths Helfer '''

<div class="visualClear"></div>

== Sonstiges ==
[http://wesnoth.kpm-sport.de/CvE.tar.bz2 Herunterladen der Kampagne]

[[GermanTranslation|Deutsche Übersetzung]]

GermanTranslationMPCampaign

2006-11-28T14:28:03Z

Rhuvaen: /* Helden */

<h1 style="text-align:center;">Die Chroniken von Elvenmar ~ Das zweite Zeitalter</h1>

<p><em>„Nun hatte die Allianz von Elvenmar den Feind allen Lebens bezwungen. Der verruchte Totenbeschwörer, der
mit seinen Schergen in unser Land kam, um uns zu unterjochen, ist besiegt. Frieden wird wiederkehren in unser Land und die Lande unser Verbündeten. Doch bevor wir den Totenbeschwörer überwanden, sprach er einen Fluch aus, dass er zurückkehren würde, um Rache zu nehmen.“</em></p>

<p style="text-align:right; margin-bottom:0px;"><em>Liorundel Morgentau, Chronist von Elvenmar</em></p>

<p style="text-align:center;">Hallo, Entwickler dieser Kampagne! <em>Rhuvaen</em> würde gerne Euer Werk ins Englische übersetzen und als Multiplayer Kampagne, die man über das Netzwerk spielen kann, umsetzen. Bitte meldet Euch doch mal im Forum http://www.wesnoth.org/forum/viewtopic.php?t=13877, danke!</p>

== Helden ==

<div style="float:left;">http://wesnoth.slack.it/wesnoth-images/units/elves-wood/marksman.png</div>
'''Eldarion Mistelzweig'''

Eldarion ist ein Kind der Sippe Mistelzweig, die sich zusammen mit vielen anderen Sippen in den westlichen Wäldern von Wesnoth niedergelassen haben. In seiner Kindheit stellte sich heraus, dass er eine besondere Begabung dafür hatte, mit dem Bogen selbst die kleinsten Ziele zu treffen. Kurze Zeit später wurde er nach Elvenmar geschickt, um dort in die Reihen der elfischen Bogenschützen aufgenommen zu werden, auf das seine Fähigkeiten vollendet werden sollten. Während all der Jahre die er in der elfischen Haupstadt verbrachte, lernte er die junge Waldfee Fjoergyn kennen, mit der ihn seither ein mächtiges Band der Freundschaft verbindet. Seit die Untoten wieder zurückgekehrt sind, führt Eldarion kleinere Truppenverbände gegen den Feind der Elfen in die Schlacht.

<div class="visualClear"></div>

<div style="float:left;">http://wesnoth.slack.it/wesnoth-images/units/elves-wood/shyde.png</div>
'''Fjoergyn, Hüterin von Elvenmar'''

Fjoergyn ist in den weitläufigen Elfenwäldern in Wesnoth aufgewachsen und hat schon als kleines Elfenmädchen viel
über die Heilkunst ihrer Sippe gelernt. Als junge Waldfee wurde Fjoergyn von ihren Eltern nach Elvenmar geschickt um dort von den besten Heilerinnen Wesnoths unterrichtet zu werden. In Elvenmar traf sie Eldarion Mistelzweig mit dem sie seither oft Seite an Seite gekämpft hat. Fjoergyn ist mutig und tapfer auf dem Schlachtfeld und schnell zur Stelle wenn eine Schwester oder ein Bruder Hilfe braucht. Manchmal ist sie allerdings etwas ungeduldig.

<div class="visualClear"></div>

<div style="float:left;">http://wesnoth.slack.it/wesnoth-images/units/human-magi/white-mage.png</div>
'''Zoran von Oxid'''

Zoran wurde als erster Sohn des Fürsten von Oxid, welcher damals einen großen Landstrich in Wesnoth regierte, geboren. Als er sein siebentes Lebensjahr vollendet hatte, bemerkte man, dass Zoran die Veranlagung besaß, Magie zu wirken. So wurde er zum Orden des weissen Pentagramms geschickt, um ihn in den Künsten der Heilmagie und der Bannzauberei ausbilden zu lassen. Kurz nach Vollendung seines 17. Lebensjahres kehrte er in ein Fürstentum zurück, von dessen ehemaligem Glanz nur noch wenig zu sehen war. Sein Bruder Byrial hatte inzwischen die Regierungsgewalt erlangt und herrschte mit Schrecken und Unterdrückung. Schlussendlich schaffte es Zoran, seinen rechtmäßigen Platz als Thronfolger einzunehmen. Da er sich jedoch als Magier um die Belange des Ordens kümmern musste, überließ er den Thron einem guten Freund seines Vaters.

<div class="visualClear"></div>

<div style="float:left;">http://wesnoth.slack.it/wesnoth-images/units/saurians/ambusher.png</div>
'''Skaz'''

Als Jüngster von drei Geschwistern, wuchs der saurianische Krieger in einem der Sümpfe im Südwesten von Wesnoth auf. Genau wie der Rest der Familie, sollte Skaz den Weg des einfachen Soldaten einschlagen. Doch schon kurz nachdem er in die Armee eingetreten war, stellte sich heraus, - durch sein Geschick im Nahkampf und seiner Fähigkeit andere für eine Sache zu begeistern - dass er zu Höherem berufen war. Seine Schwäche im Fernkampf fiel dagegen wegen seines taktischen Vorgehens auf dem Schlachtfeld und seines Wissens über diverse Kriegsstrategien kaum ins Gewicht. Nachdem er im Kampf gegen den finsteren Magier Laurentius einige seiner besten Freunde verlor, wurde ihm von saurianischen Tribunal das Kommando über die saurianischen Truppen übertragen.

<div class="visualClear"></div>

<div style="float:left;"></div>
'''Die Rote Zora'''

Zora floh als Kind aus einer Stadt im Norden von Wesnoth, die durch einen furchtbaren Krieg zwischen Trollen und Menschen zerstört wurde. Sie war eine der wenigen, die die Kämpfe überlebten - auch ihre Eltern fielen den Trollen zum Opfer. Bald fand sie Anschluss an eine Gruppe von Gauklern und fahrendem Volk, welche sich mit ziemlich dunklen Geschäften über Wasser hielt. Als sie etwa 20 Jahre alt war, kam es nach einen Raubzug beim Streit um die Beute zu einer Ausseinandersetzung, bei dem sie den alten Anführer (welcher von Gier getrieben die Beute ungleich teilen wollte) tödlich mit ihrem Kampfstab verletzte. Daraufhin zerfiel die Gruppe und Zora zog sich mit wenigen Vertrauten in die nahegelegenen Wälder zurück, um fortan ihre eigene Diebesbande zu führen. Ihr Name rührt wohl zum einen von ihrer Haarfarbe und zum anderem von ihrem sehr ausgeprägten Gerechtigkeitsinn her.

<div class="visualClear"></div>

== Schurken ==

<div style="float:left;">http://wesnoth.slack.it/wesnoth-images/units/undead/shadow.png</div>
''' Asgarath, Herr der Plagen, die verzehrende Finsternis, eine dämonische Wesenheit '''

<div class="visualClear"></div>

<div style="float:left;">http://wesnoth.slack.it/wesnoth-images/units/undead-necromancers/dark_sorcerer.png</div>
''' Laurentius '''

<div class="visualClear"></div>

<div style="float:left;"></div>
''' Wladuch, Laurentius Schüler '''

Wladuch ist Laurentius Schüler, der seinem Meister in nichts nachsteht. Er hat sich, wie viele Dunkle Adepten, vollständig dem Studium der Schwarzen Künste verschrieben. Nachdem Laurentius früherer Schüler bei einer Beschwörung ums Leben kam, war dieser auf der Suche nach einem neuen Schüler. In Wladuch fand er jenen, der seinen Ansprüchen genügte. Laurentius verlieh ihm als Zeichen den Todesdolch, ein mächtiges Artefakt, das beseelt ist. Die Waffe produziert ein tödliches Gift aus sich selbst heraus und führt die Hand des Trägers zum Ziel.

<div class="visualClear"></div>

<div style="float:left;">http://wesnoth.slack.it/wesnoth-images/units/trolls/great-troll.png</div>
''' Guhrath '''

<div class="visualClear"></div>

== Ort und Zeit ==

== Szenarios ==

<div style="float:left;">http://wesnoth.kpm-sport.de/CvE_Szenario1.jpeg</div>
''' Szenario 1 - Die Kugel der Eifersucht '''

Nicht weit entfernt der elfischen Hauptstadt tobt eine Schlacht zwischen den Saurianern und den Draken. Die Saurianer entsenden einen Boten nach Elvenmar, um die Elfen um Hilfe zu bitten. Erstaunt darüber, dass die Saurianer von Drachen angegriffen werden, wird Eldarion entsandt, um dieses merkwürdige Vorkommnis zu untersuchen. Die Elfen glauben nicht an einen Angriff der von Drachen verursacht wurde. Dafür entdecken Eldarions Späher einen Hexenmeister der Untoten, der sich in dem nahegelegen Sumpfgebiet niedergelassen hat. Als sich herausstellt, dass es tatsächlich drachenähnliche Wesen sind, mit denen die Saurianer im Krieg liegen, ist es den untoten Horden bereits gelungen, die Festung der Elfen einzunehmen. Eldarion schickt zwei seiner Bogenschützen, Delorien und Eärewen mit den saurianischen Kriegern nach Westen, um den Hort der Drachen ausfindig zu machen. Kurze Zeit später legen die Saurianer und die Draken ihren Konflikt bei, der nur aus einem Missverständniss entstanden war. Die Saurianer hatten geglaubt, dass ihre Ahnen sie versklaven wollten. Dafür verantwortlich war ein mächtiges Artefakt, '''Eine Kugel der Eifersucht''', die Delorien in dem verlassenen Drachenhort fand. Eine Vorhut der untoten Streitkräfte hatte bereits den Drachenhort erreicht, um die Spuren zu verwischen, doch glücklicherweise kamen ihr einige Saurianer zur Hilfe, allen vorran Skaz. Die beiden können sich zurück zur Burg der Saurianer retten und dem Bündniss aus Draken, Saurianern und Elfen gelingt es schließlich, den Untoten zurückzuschlagen. Danach tratt Eldarion mit seinen Mitstreitern, zu denen jetzt auch Skaz gehörte, der nicht mehr von Deloriens Seite wich, den Rückweg nach Elvenmar an, um dort die Kugel zerstören zu lassen.

<div class="visualClear"></div>

<div style="float:left;">http://wesnoth.kpm-sport.de/CvE_Szenario2.jpeg</div>
''' Szenario 2 - Der Weg nach Elvenmar '''

<div class="visualClear"></div>

<div style="float:left;">http://wesnoth.kpm-sport.de/CvE_Szenario3.jpeg</div>
''' Szenario 3 - Schwarz und Weiß '''

<div class="visualClear"></div>

<div style="float:left;">http://wesnoth.kpm-sport.de/CvE_Szenario3.jpeg</div>
''' Szenario 4 - Die Schlacht um Elvenmar '''

<div class="visualClear"></div>

<div style="float:left;">http://wesnoth.kpm-sport.de/CvE_Szenario5.jpeg</div>
''' Szenario 5 - Der Turm von Shalyn'fey'''

<div class="visualClear"></div>

<div style="float:left;">http://wesnoth.kpm-sport.de/CvE_Szenario6.jpeg</div>
''' Szenario 6 - Die Sphäre des Schattens '''

<div class="visualClear"></div>

<div style="float:left;">http://wesnoth.kpm-sport.de/CvE_Szenario7.jpeg</div>
''' Szenario 7 - Gerettet? '''

<div class="visualClear"></div>

<div style="float:left;">http://wesnoth.kpm-sport.de/CvE_Szenario7.jpeg</div>
''' Szenario 8 - Asgaraths Helfer '''

<div class="visualClear"></div>

== Sonstiges ==
[http://wesnoth.kpm-sport.de/CvE.tar.bz2 Herunterladen der Kampagne]

[[GermanTranslation|Deutsche Übersetzung]]

MultiplayerContent

2006-08-03T13:52:08Z

Rhuvaen: /* Scenarios */

== Building multiplayer campaigns ==

Both the stable and development versions of wesnoth have basic support for campaigns that can be played in multiplayer mode, with your friends, or even with an AI. Since version 1.1.8, more features and support have been added so we recommend a versions 1.1.8+. There will still be some things that don't work as expected as multiplayer campaigns are an area for exploration. While you can and should test your work in hotseat mode, there are a number of things that might behave differently under real network conditions (mostly affecting scenario and side parameters). Keep this in mind and make sure to test your campaign over the net, too.
This page only documents the differences between writing multiplayer campaigns and single player campaigns, so you might want to read up on [[BuildingCampaigns]] and [[BuildingMultiplayer]] first.

=== The campaign file ===

Multiplayer campaigns do not use the [campaign] tag. As a result of this, multiplayer campaigns only support one difficulty level, though you could support more with enough WML, if you're feeling ambitious. The "campaign file" should look something like this:

#ifdef MULTIPLAYER
{@campaigns/My_Campaign/scenarios}
#endif

Anything that you would normally put in the campaign tag now goes into the first scenario, if it's supported there. The order of scenarios is determined by next_scenario tags, just like in single player.

=== Scenarios ===

A scenario in a multiplayer campaign is almost identical to a scenario in a single player campaign. You only need to change the following:

* The [scenario] tag should be replaced with a [multiplayer] tag.
* The '''next_scenario''' key points to the id of the next scenario.
* Every scenario after the first should have '''allow_new_game=no''' inside the [multiplayer] tag. This will prevent it from showing up in the map selection menu. ''This does not work in v1.1'', but it causes no harm, and it will work in the future.
* In v1.1, Every scenario in the campaign will appear on the map selection menu, so be sure to include your campaign's name in the [multiplayer] tag's name key. Alternatively, include a warning like "DO NOT PLAY".
* Each human-controlled side needs to have a '''controller=human''' key defined in their [side] tag to work in network mode.
* Each human-controlled side also needs to have a '''save_id''' defined inside their [side] tag. Each side's save_id should be unique, and it should be the same in every scenario. Without this, your recall lists and leaders will not carry over from one scenario to the next.
* Each AI-controlled side should have '''allow_player=no''' in their [side] tag.

=== The first scenario ===

The first scenario might need some extra work, because the settings from the multiplayer dialog will override the settings in the scenario. However, most of the multiplayer settings can be overridden in the prestart event.

Use a macro like this to force a side to have a particular type of leader.
#define MP_SIDE SIDENO TYPE DESC
[store_unit]
variable=oldunit
kill=yes
[filter]
side={SIDENO}
[/filter]
[/store_unit]

[unit]
type={TYPE}
description={DESC}
unrenameable=yes
side={SIDENO}
x,y=$oldunit.x,$oldunit.y
canrecruit=1
[/unit]

[clear_variable]
name=oldunit
[/clear_variable]
#enddef

Other useful tags include [set_recruit], [modify_side], [modify_turns] and [remove_shroud]. There is currently no way to remove fog. You might also want to use ''experience_modifier=100'' in the [multiplayer] tag.

=== Custom units ===

Since there is no [campaign] tag, there is no natural way to include custom units in a multiplayer campaign. However, there are two workarounds. One way is to use [[EffectWML]] or [store_unit] to modify a mainline unit. The other way is to make your custom units available via an [[EraWML|era]], or by dropping them into ~wesnoth/data/units. If you go this route, using an era is better, because you can keep the units in your campaign directory.

== See Also ==

* [http://www.wesnoth.org/forum/viewtopic.php?t=11349 Multiplayer Campaigns HOWTO forum post]
* [[BuildingScenarios]]
* [[BuildingMultiplayer]]

MultiplayerContent

2006-08-03T13:51:45Z

Rhuvaen: /* Scenarios */

== Building multiplayer campaigns ==

Both the stable and development versions of wesnoth have basic support for campaigns that can be played in multiplayer mode, with your friends, or even with an AI. Since version 1.1.8, more features and support have been added so we recommend a versions 1.1.8+. There will still be some things that don't work as expected as multiplayer campaigns are an area for exploration. While you can and should test your work in hotseat mode, there are a number of things that might behave differently under real network conditions (mostly affecting scenario and side parameters). Keep this in mind and make sure to test your campaign over the net, too.
This page only documents the differences between writing multiplayer campaigns and single player campaigns, so you might want to read up on [[BuildingCampaigns]] and [[BuildingMultiplayer]] first.

=== The campaign file ===

Multiplayer campaigns do not use the [campaign] tag. As a result of this, multiplayer campaigns only support one difficulty level, though you could support more with enough WML, if you're feeling ambitious. The "campaign file" should look something like this:

#ifdef MULTIPLAYER
{@campaigns/My_Campaign/scenarios}
#endif

Anything that you would normally put in the campaign tag now goes into the first scenario, if it's supported there. The order of scenarios is determined by next_scenario tags, just like in single player.

=== Scenarios ===

A scenario in a multiplayer campaign is almost identical to a scenario in a single player campaign. You only need to change the following:

* The [scenario] tag should be replaced with a [multiplayer] tag.
* The '''next_scenario''' key points to the id of the next scenario.
* Every scenario after the first should have '''allow_new_game=no''' inside the [multiplayer] tag. This will prevent it from showing up in the map selection menu. ''This does not work in v1.1'', but it causes no harm, and it will work in the future.
* In v1.1, Every scenario in the campaign will appear on the map selection menu, so be sure to include your campaign's name in the [multiplayer] tag's name key. Alternatively, include a warning like "DO NOT PLAY".
* Each human-controlled side needs to have a '''controller=human''' key defined in their [side] tag to work in network mode.
* Each human-controlled side needs to have a '''save_id''' defined inside their [side] tag. Each side's save_id should be unique, and it should be the same in every scenario. Without this, your recall lists and leaders will not carry over from one scenario to the next.
* Each AI-controlled side should have '''allow_player=no''' in their [side] tag.

=== The first scenario ===

The first scenario might need some extra work, because the settings from the multiplayer dialog will override the settings in the scenario. However, most of the multiplayer settings can be overridden in the prestart event.

Use a macro like this to force a side to have a particular type of leader.
#define MP_SIDE SIDENO TYPE DESC
[store_unit]
variable=oldunit
kill=yes
[filter]
side={SIDENO}
[/filter]
[/store_unit]

[unit]
type={TYPE}
description={DESC}
unrenameable=yes
side={SIDENO}
x,y=$oldunit.x,$oldunit.y
canrecruit=1
[/unit]

[clear_variable]
name=oldunit
[/clear_variable]
#enddef

Other useful tags include [set_recruit], [modify_side], [modify_turns] and [remove_shroud]. There is currently no way to remove fog. You might also want to use ''experience_modifier=100'' in the [multiplayer] tag.

=== Custom units ===

Since there is no [campaign] tag, there is no natural way to include custom units in a multiplayer campaign. However, there are two workarounds. One way is to use [[EffectWML]] or [store_unit] to modify a mainline unit. The other way is to make your custom units available via an [[EraWML|era]], or by dropping them into ~wesnoth/data/units. If you go this route, using an era is better, because you can keep the units in your campaign directory.

== See Also ==

* [http://www.wesnoth.org/forum/viewtopic.php?t=11349 Multiplayer Campaigns HOWTO forum post]
* [[BuildingScenarios]]
* [[BuildingMultiplayer]]

MultiplayerContent

2006-08-03T13:48:40Z

Rhuvaen: /* Building multiplayer campaigns */

== Building multiplayer campaigns ==

Both the stable and development versions of wesnoth have basic support for campaigns that can be played in multiplayer mode, with your friends, or even with an AI. Since version 1.1.8, more features and support have been added so we recommend a versions 1.1.8+. There will still be some things that don't work as expected as multiplayer campaigns are an area for exploration. While you can and should test your work in hotseat mode, there are a number of things that might behave differently under real network conditions (mostly affecting scenario and side parameters). Keep this in mind and make sure to test your campaign over the net, too.
This page only documents the differences between writing multiplayer campaigns and single player campaigns, so you might want to read up on [[BuildingCampaigns]] and [[BuildingMultiplayer]] first.

=== The campaign file ===

Multiplayer campaigns do not use the [campaign] tag. As a result of this, multiplayer campaigns only support one difficulty level, though you could support more with enough WML, if you're feeling ambitious. The "campaign file" should look something like this:

#ifdef MULTIPLAYER
{@campaigns/My_Campaign/scenarios}
#endif

Anything that you would normally put in the campaign tag now goes into the first scenario, if it's supported there. The order of scenarios is determined by next_scenario tags, just like in single player.

=== Scenarios ===

A scenario in a multiplayer campaign is almost identical to a scenario in a single player campaign. You only need to change the following:

* The [scenario] tag should be replaced with a [multiplayer] tag.
* Every scenario after the first should have '''allow_new_game=no''' inside the [multiplayer] tag. This will prevent it from showing up in the map selection menu. ''This does not work in v1.1'', but it causes no harm, and it will work in the future.
* In v1.1, Every scenario in the campaign will appear on the map selection menu, so be sure to include your campaign's name in the [multiplayer] tag's name key. Alternatively, include a warning like "DO NOT PLAY".
* Each human-controlled side needs to have a '''controller=human''' key defined in their [side] tag to work in network mode.
* Each human-controlled side needs to have a '''save_id''' defined inside their [side] tag. Each side's save_id should be unique, and it should be the same in every scenario. Without this, your recall lists and leaders will not carry over from one scenario to the next.
* Each AI-controlled side should have '''allow_player=no''' in their [side] tag.

=== The first scenario ===

The first scenario might need some extra work, because the settings from the multiplayer dialog will override the settings in the scenario. However, most of the multiplayer settings can be overridden in the prestart event.

Use a macro like this to force a side to have a particular type of leader.
#define MP_SIDE SIDENO TYPE DESC
[store_unit]
variable=oldunit
kill=yes
[filter]
side={SIDENO}
[/filter]
[/store_unit]

[unit]
type={TYPE}
description={DESC}
unrenameable=yes
side={SIDENO}
x,y=$oldunit.x,$oldunit.y
canrecruit=1
[/unit]

[clear_variable]
name=oldunit
[/clear_variable]
#enddef

Other useful tags include [set_recruit], [modify_side], [modify_turns] and [remove_shroud]. There is currently no way to remove fog. You might also want to use ''experience_modifier=100'' in the [multiplayer] tag.

=== Custom units ===

Since there is no [campaign] tag, there is no natural way to include custom units in a multiplayer campaign. However, there are two workarounds. One way is to use [[EffectWML]] or [store_unit] to modify a mainline unit. The other way is to make your custom units available via an [[EraWML|era]], or by dropping them into ~wesnoth/data/units. If you go this route, using an era is better, because you can keep the units in your campaign directory.

== See Also ==

* [http://www.wesnoth.org/forum/viewtopic.php?t=11349 Multiplayer Campaigns HOWTO forum post]
* [[BuildingScenarios]]
* [[BuildingMultiplayer]]