https://wiki.wesnoth.org/api.php?action=feedcontributions&user=Fabi&feedformat=atomThe Battle for Wesnoth Wiki - User contributions [en]2024-03-19T04:12:37ZUser contributionsMediaWiki 1.31.16https://wiki.wesnoth.org/index.php?title=PblWML&diff=55011PblWML2014-05-09T22:22:24Z<p>Fabi: /* core */</p>
<hr />
<div>{{WML Tags}}<br />
<br />
To upload an add-on you have made, you need a '''_server.pbl''' file in your add-on's directory, at the same leven as the '''_main.cfg''' file. When you upload the add-on, the entire directory and subdirectories containing the _server.pbl file will be published. Your add-on must be based entirely on these paths.<br />
<br />
See [[AddonStructure]] for more on setting up the add-on folder if you have not done so, and [[Distributing_Content]] for more on uploading an add-on to the server with this file.<br />
<br />
<b>Note:</b> Be aware that translations in the .pbl-files are '''not''' used, so don't mark these strings as translatable.<br />
<br />
== What goes into a .pbl file? ==<br />
<br />
'''Note:''' ''You should '''not''' use special formatting or coloring in any of these keys when uploading to the official server.'''''<br />
<br />
The following keys are recognized for .pbl files:<br />
<br />
=== icon ===<br />
: An image, displayed leftmost in the add-ons download dialog. It must be a standard Wesnoth file and '''not a custom one'''. A custom file will only work for users who already have the relevant add-on installed. This is not related to the icon used for entries in the campaigns menu -- see [[CampaignWML]] for more information.<br />
<br />
: If the icon is a unit with magenta team-color bits, please use [[ImagePathFunctionWML]] to recolor it.<br />
<br />
=== title ===<br />
: Displayed to the right of the icon, it is just text. It should usually be the same as the name of your add-on when it is played.<br />
<br />
=== version ===<br />
: Displayed to the right of the title, it is just text. However, starting with Wesnoth 1.6, the ''required'' format is x.y.z where x, y and z are numbers and a value for x greater than 0 implies the add-on is complete feature-wise. Trailing non-numeric elements are allowed, but nothing should appear ''before'' the numbers. This is necessary for the ''Update add-ons'' button to work correctly. ([[#Version Key Examples|See Examples]])<br />
<br />
=== author ===<br />
: Displayed to the right of the version, it is just text. Put your name or nickname here. If several people have contributed significantly to the add-on you may want to list all of their names.<br />
<br />
=== passphrase ===<br />
: Not displayed, it prevents others from modifying the version of your add-on on the server. You do not need to input a passphrase when initially publishing a add-on; if you do not, one will be randomly generated for you and replaced in your local copy of the .pbl file.<br />
: '''SECURITY NOTE:''' If you do specify a passphrase of your own, note that it is stored in '''clear text''' form in the server; '''do NOT use a password you would normally use for any other services or web sites!'''<br />
<br />
=== description ===<br />
: This can be used to provide a brief description of your add-on, and for pre-1.0 versions, let people know how playable it is. The description can be viewed by users by clicking on the Description button in the built-in client, or by moving their mouse over the add-on's icon in the web interface.<br />
<br />
=== dependencies ===<br />
: An optional list of dependencies (a comma separated list of ''addon-name'' – the directory names of the needed add-ons), which should be provided if your add-on relies on other user-made content to work properly. ([[#Dependency Key Example|See Example]])<br />
<br />
=== core ===<br />
: An optional string defining the id of the core which the addon is designed for. Defaults to "default". Don't specify for an addon which is of type "core" itself. {{DevFeature1.13|0}}<br />
<br />
=== translate ===<br />
: If set to '''true''', the add-on will be sent to and updated with [[WesCamp|WesCamp-i18n]]. (NOTE: this is a new and experimental function, which will automatically update the translations in your add-on. Make sure you make backups of your add-on in case of problems.)<br />
<br />
: You should make sure your add-on complies with some very specific [[WesCamp#Preparing_your_add-on_for_WesCamp|conventions]] required to ease the process for translators as well as technical requirements.<br />
<br />
=== type ===<br />
: Indicates the type of the add-on, used for the downloads manager dialog. Possible values are:<br />
<br />
:* ''core'': replaces the whole wml tree. {{DevFeature1.13|0}}<br />
:* ''campaign'': single player campaign.<br />
:* ''scenario'': single player scenario.<br />
:* ''campaign_sp_mp'': hybrid campaign.<br />
:* ''era'': multiplayer era.<br />
:* ''faction'': multiplayer stand-alone faction, or add-on for other available era.<br />
:* ''map_pack'': multiplayer map-pack.<br />
:* ''campaign_mp'': multiplayer campaign.<br />
:* ''scenario_mp'': multiplayer scenario. (See the note below.)<br />
:* ''mod_mp'': multiplayer modification.<br />
:* ''media'': miscellaneous resources for UMC authors/users, for example, music packs, packages of general-purpose WML, etc.<br />
:* ''other'': The type to use when no other type fits.<br />
<br />
'''Note:''' If your add-on contains two or more separate multiplayer scenarios, use ''map_pack''.<br />
<br />
=== email ===<br />
: Hidden e-mail address used by the server administrators to contact content authors in case of major issues. Again, this will only be seen by the server administrators and it is required that you provide one in case you need to be contacted about your add-on.<br />
<br />
=== [feedback] ===<br />
: {{DevFeature1.11|8}} The [feedback] tag includes information used by the server to provide the client with a website URL for players to post feedback on an add-on and communicate with the maintainers. At this time, the official add-ons server is configured to take a single parameter described below.<br />
<br />
==== topic_id ====<br />
: {{DevFeature1.11|8}} Topic id from the [http://forums.wesnoth.org/ Wesnoth.org forums] for the add-on's feedback or development topic maintained by the add-on uploader or author. For existing topics, the '''topic_id''' corresponds to the series of digits in the '''t=YYYYY''' portion of an URL like <code><nowiki>http://forums.wesnoth.org/viewtopic.php?f=XX&t=YYYYY</nowiki></code>. You must take special care to ensure this information is valid before uploading if you want players to be able to reach you!<br />
<br />
<br />
The add-on server keeps track of some other information about uploaded content, including when they were uploaded, what languages they have been at least partly translated into, how large they are on the server and the number of times they have been downloaded. For more information about this you can read [[CampaignServerWML]].<br />
<br />
== Examples ==<br />
<br />
=== Dependency Key Example ===<br />
<br />
The following dependency key could be used when the add-on needs the ''Imperial_Era'' and ''Era_of_Myths'' to be installed before it will work properly:<br />
<br />
dependencies=Imperial_Era,Era_of_Myths<br />
<br />
=== Version Key Examples ===<br />
<br />
The following are examples of '''good''' version values:<br />
<br />
version="1.5"<br />
<br />
version="0.11.4"<br />
<br />
version="0.1.4beta"<br />
<br />
version="1.5c"<br />
<br />
<br />
The following are examples of '''bad''' version values:<br />
<br />
version="Beta1.5"<br />
<br />
version="Incomplete (0.3.4)"<br />
<br />
In both of the above examples the version number as read by the server will be '''0.0.0Beta1.5''' and '''0.0.0Incomplete (0.3.4)'''. You can clearly see why this will not be a good thing with the ''Update add-ons'' feature.<br />
<br />
<br />
Finally, here are some example version numbers and how they will be interpreted by the ''Update add-ons'' button. The number on the left will be considered an earlier number than the number on the right in each example.<br />
<br />
0.5 < 1.0<br />
<br />
1.5 < 1.5c<br />
<br />
1.0 < 1.0.1<br />
<br />
1.0c < 1.0.1a<br />
<br />
1.0.1a < 1.0.1c<br />
<br />
1.0 Final < 1.0.1 Beta<br />
<br />
=== Example .pbl File ===<br />
<br />
title="My Campaign"<br />
type="campaign"<br />
icon="misc/ball.png"<br />
version="0.1.2"<br />
author="Me, artwork by myself"<br />
passphrase="This is like a password; see the security note in the documentation above before choosing a value of your own"<br />
description="You get to kill a lot of bad guys. But only the first map is done."<br />
email="name@example.com"<br />
# The following tag is only used by Wesnoth 1.11.8 and later!<br />
[feedback]<br />
topic_id=12345<br />
[/feedback]<br />
<br />
== See Also ==<br />
<br />
* [[ReferenceWML]]<br />
* [[CampaignServerWML]]<br />
* [[FancyAddonIcons]]<br />
<br />
[[Category: WML Reference]]</div>Fabihttps://wiki.wesnoth.org/index.php?title=PblWML&diff=55010PblWML2014-05-09T22:21:51Z<p>Fabi: /* core */</p>
<hr />
<div>{{WML Tags}}<br />
<br />
To upload an add-on you have made, you need a '''_server.pbl''' file in your add-on's directory, at the same leven as the '''_main.cfg''' file. When you upload the add-on, the entire directory and subdirectories containing the _server.pbl file will be published. Your add-on must be based entirely on these paths.<br />
<br />
See [[AddonStructure]] for more on setting up the add-on folder if you have not done so, and [[Distributing_Content]] for more on uploading an add-on to the server with this file.<br />
<br />
<b>Note:</b> Be aware that translations in the .pbl-files are '''not''' used, so don't mark these strings as translatable.<br />
<br />
== What goes into a .pbl file? ==<br />
<br />
'''Note:''' ''You should '''not''' use special formatting or coloring in any of these keys when uploading to the official server.'''''<br />
<br />
The following keys are recognized for .pbl files:<br />
<br />
=== icon ===<br />
: An image, displayed leftmost in the add-ons download dialog. It must be a standard Wesnoth file and '''not a custom one'''. A custom file will only work for users who already have the relevant add-on installed. This is not related to the icon used for entries in the campaigns menu -- see [[CampaignWML]] for more information.<br />
<br />
: If the icon is a unit with magenta team-color bits, please use [[ImagePathFunctionWML]] to recolor it.<br />
<br />
=== title ===<br />
: Displayed to the right of the icon, it is just text. It should usually be the same as the name of your add-on when it is played.<br />
<br />
=== version ===<br />
: Displayed to the right of the title, it is just text. However, starting with Wesnoth 1.6, the ''required'' format is x.y.z where x, y and z are numbers and a value for x greater than 0 implies the add-on is complete feature-wise. Trailing non-numeric elements are allowed, but nothing should appear ''before'' the numbers. This is necessary for the ''Update add-ons'' button to work correctly. ([[#Version Key Examples|See Examples]])<br />
<br />
=== author ===<br />
: Displayed to the right of the version, it is just text. Put your name or nickname here. If several people have contributed significantly to the add-on you may want to list all of their names.<br />
<br />
=== passphrase ===<br />
: Not displayed, it prevents others from modifying the version of your add-on on the server. You do not need to input a passphrase when initially publishing a add-on; if you do not, one will be randomly generated for you and replaced in your local copy of the .pbl file.<br />
: '''SECURITY NOTE:''' If you do specify a passphrase of your own, note that it is stored in '''clear text''' form in the server; '''do NOT use a password you would normally use for any other services or web sites!'''<br />
<br />
=== description ===<br />
: This can be used to provide a brief description of your add-on, and for pre-1.0 versions, let people know how playable it is. The description can be viewed by users by clicking on the Description button in the built-in client, or by moving their mouse over the add-on's icon in the web interface.<br />
<br />
=== dependencies ===<br />
: An optional list of dependencies (a comma separated list of ''addon-name'' – the directory names of the needed add-ons), which should be provided if your add-on relies on other user-made content to work properly. ([[#Dependency Key Example|See Example]])<br />
<br />
=== core ===<br />
: An optional string defining the id of the core which the addon is designed for. Defaults to "default". Don't specify for an addon which is a core itself. {{DevFeature1.13|0}}<br />
<br />
=== translate ===<br />
: If set to '''true''', the add-on will be sent to and updated with [[WesCamp|WesCamp-i18n]]. (NOTE: this is a new and experimental function, which will automatically update the translations in your add-on. Make sure you make backups of your add-on in case of problems.)<br />
<br />
: You should make sure your add-on complies with some very specific [[WesCamp#Preparing_your_add-on_for_WesCamp|conventions]] required to ease the process for translators as well as technical requirements.<br />
<br />
=== type ===<br />
: Indicates the type of the add-on, used for the downloads manager dialog. Possible values are:<br />
<br />
:* ''core'': replaces the whole wml tree. {{DevFeature1.13|0}}<br />
:* ''campaign'': single player campaign.<br />
:* ''scenario'': single player scenario.<br />
:* ''campaign_sp_mp'': hybrid campaign.<br />
:* ''era'': multiplayer era.<br />
:* ''faction'': multiplayer stand-alone faction, or add-on for other available era.<br />
:* ''map_pack'': multiplayer map-pack.<br />
:* ''campaign_mp'': multiplayer campaign.<br />
:* ''scenario_mp'': multiplayer scenario. (See the note below.)<br />
:* ''mod_mp'': multiplayer modification.<br />
:* ''media'': miscellaneous resources for UMC authors/users, for example, music packs, packages of general-purpose WML, etc.<br />
:* ''other'': The type to use when no other type fits.<br />
<br />
'''Note:''' If your add-on contains two or more separate multiplayer scenarios, use ''map_pack''.<br />
<br />
=== email ===<br />
: Hidden e-mail address used by the server administrators to contact content authors in case of major issues. Again, this will only be seen by the server administrators and it is required that you provide one in case you need to be contacted about your add-on.<br />
<br />
=== [feedback] ===<br />
: {{DevFeature1.11|8}} The [feedback] tag includes information used by the server to provide the client with a website URL for players to post feedback on an add-on and communicate with the maintainers. At this time, the official add-ons server is configured to take a single parameter described below.<br />
<br />
==== topic_id ====<br />
: {{DevFeature1.11|8}} Topic id from the [http://forums.wesnoth.org/ Wesnoth.org forums] for the add-on's feedback or development topic maintained by the add-on uploader or author. For existing topics, the '''topic_id''' corresponds to the series of digits in the '''t=YYYYY''' portion of an URL like <code><nowiki>http://forums.wesnoth.org/viewtopic.php?f=XX&t=YYYYY</nowiki></code>. You must take special care to ensure this information is valid before uploading if you want players to be able to reach you!<br />
<br />
<br />
The add-on server keeps track of some other information about uploaded content, including when they were uploaded, what languages they have been at least partly translated into, how large they are on the server and the number of times they have been downloaded. For more information about this you can read [[CampaignServerWML]].<br />
<br />
== Examples ==<br />
<br />
=== Dependency Key Example ===<br />
<br />
The following dependency key could be used when the add-on needs the ''Imperial_Era'' and ''Era_of_Myths'' to be installed before it will work properly:<br />
<br />
dependencies=Imperial_Era,Era_of_Myths<br />
<br />
=== Version Key Examples ===<br />
<br />
The following are examples of '''good''' version values:<br />
<br />
version="1.5"<br />
<br />
version="0.11.4"<br />
<br />
version="0.1.4beta"<br />
<br />
version="1.5c"<br />
<br />
<br />
The following are examples of '''bad''' version values:<br />
<br />
version="Beta1.5"<br />
<br />
version="Incomplete (0.3.4)"<br />
<br />
In both of the above examples the version number as read by the server will be '''0.0.0Beta1.5''' and '''0.0.0Incomplete (0.3.4)'''. You can clearly see why this will not be a good thing with the ''Update add-ons'' feature.<br />
<br />
<br />
Finally, here are some example version numbers and how they will be interpreted by the ''Update add-ons'' button. The number on the left will be considered an earlier number than the number on the right in each example.<br />
<br />
0.5 < 1.0<br />
<br />
1.5 < 1.5c<br />
<br />
1.0 < 1.0.1<br />
<br />
1.0c < 1.0.1a<br />
<br />
1.0.1a < 1.0.1c<br />
<br />
1.0 Final < 1.0.1 Beta<br />
<br />
=== Example .pbl File ===<br />
<br />
title="My Campaign"<br />
type="campaign"<br />
icon="misc/ball.png"<br />
version="0.1.2"<br />
author="Me, artwork by myself"<br />
passphrase="This is like a password; see the security note in the documentation above before choosing a value of your own"<br />
description="You get to kill a lot of bad guys. But only the first map is done."<br />
email="name@example.com"<br />
# The following tag is only used by Wesnoth 1.11.8 and later!<br />
[feedback]<br />
topic_id=12345<br />
[/feedback]<br />
<br />
== See Also ==<br />
<br />
* [[ReferenceWML]]<br />
* [[CampaignServerWML]]<br />
* [[FancyAddonIcons]]<br />
<br />
[[Category: WML Reference]]</div>Fabihttps://wiki.wesnoth.org/index.php?title=PblWML&diff=55009PblWML2014-05-09T22:20:56Z<p>Fabi: /* dependencies */</p>
<hr />
<div>{{WML Tags}}<br />
<br />
To upload an add-on you have made, you need a '''_server.pbl''' file in your add-on's directory, at the same leven as the '''_main.cfg''' file. When you upload the add-on, the entire directory and subdirectories containing the _server.pbl file will be published. Your add-on must be based entirely on these paths.<br />
<br />
See [[AddonStructure]] for more on setting up the add-on folder if you have not done so, and [[Distributing_Content]] for more on uploading an add-on to the server with this file.<br />
<br />
<b>Note:</b> Be aware that translations in the .pbl-files are '''not''' used, so don't mark these strings as translatable.<br />
<br />
== What goes into a .pbl file? ==<br />
<br />
'''Note:''' ''You should '''not''' use special formatting or coloring in any of these keys when uploading to the official server.'''''<br />
<br />
The following keys are recognized for .pbl files:<br />
<br />
=== icon ===<br />
: An image, displayed leftmost in the add-ons download dialog. It must be a standard Wesnoth file and '''not a custom one'''. A custom file will only work for users who already have the relevant add-on installed. This is not related to the icon used for entries in the campaigns menu -- see [[CampaignWML]] for more information.<br />
<br />
: If the icon is a unit with magenta team-color bits, please use [[ImagePathFunctionWML]] to recolor it.<br />
<br />
=== title ===<br />
: Displayed to the right of the icon, it is just text. It should usually be the same as the name of your add-on when it is played.<br />
<br />
=== version ===<br />
: Displayed to the right of the title, it is just text. However, starting with Wesnoth 1.6, the ''required'' format is x.y.z where x, y and z are numbers and a value for x greater than 0 implies the add-on is complete feature-wise. Trailing non-numeric elements are allowed, but nothing should appear ''before'' the numbers. This is necessary for the ''Update add-ons'' button to work correctly. ([[#Version Key Examples|See Examples]])<br />
<br />
=== author ===<br />
: Displayed to the right of the version, it is just text. Put your name or nickname here. If several people have contributed significantly to the add-on you may want to list all of their names.<br />
<br />
=== passphrase ===<br />
: Not displayed, it prevents others from modifying the version of your add-on on the server. You do not need to input a passphrase when initially publishing a add-on; if you do not, one will be randomly generated for you and replaced in your local copy of the .pbl file.<br />
: '''SECURITY NOTE:''' If you do specify a passphrase of your own, note that it is stored in '''clear text''' form in the server; '''do NOT use a password you would normally use for any other services or web sites!'''<br />
<br />
=== description ===<br />
: This can be used to provide a brief description of your add-on, and for pre-1.0 versions, let people know how playable it is. The description can be viewed by users by clicking on the Description button in the built-in client, or by moving their mouse over the add-on's icon in the web interface.<br />
<br />
=== dependencies ===<br />
: An optional list of dependencies (a comma separated list of ''addon-name'' – the directory names of the needed add-ons), which should be provided if your add-on relies on other user-made content to work properly. ([[#Dependency Key Example|See Example]])<br />
<br />
=== core ===<br />
: An optional string defining the id of the core which the addon is designed for. Defaults to "default". Don't specify for an addon which is a core itself.<br />
<br />
=== translate ===<br />
: If set to '''true''', the add-on will be sent to and updated with [[WesCamp|WesCamp-i18n]]. (NOTE: this is a new and experimental function, which will automatically update the translations in your add-on. Make sure you make backups of your add-on in case of problems.)<br />
<br />
: You should make sure your add-on complies with some very specific [[WesCamp#Preparing_your_add-on_for_WesCamp|conventions]] required to ease the process for translators as well as technical requirements.<br />
<br />
=== type ===<br />
: Indicates the type of the add-on, used for the downloads manager dialog. Possible values are:<br />
<br />
:* ''core'': replaces the whole wml tree. {{DevFeature1.13|0}}<br />
:* ''campaign'': single player campaign.<br />
:* ''scenario'': single player scenario.<br />
:* ''campaign_sp_mp'': hybrid campaign.<br />
:* ''era'': multiplayer era.<br />
:* ''faction'': multiplayer stand-alone faction, or add-on for other available era.<br />
:* ''map_pack'': multiplayer map-pack.<br />
:* ''campaign_mp'': multiplayer campaign.<br />
:* ''scenario_mp'': multiplayer scenario. (See the note below.)<br />
:* ''mod_mp'': multiplayer modification.<br />
:* ''media'': miscellaneous resources for UMC authors/users, for example, music packs, packages of general-purpose WML, etc.<br />
:* ''other'': The type to use when no other type fits.<br />
<br />
'''Note:''' If your add-on contains two or more separate multiplayer scenarios, use ''map_pack''.<br />
<br />
=== email ===<br />
: Hidden e-mail address used by the server administrators to contact content authors in case of major issues. Again, this will only be seen by the server administrators and it is required that you provide one in case you need to be contacted about your add-on.<br />
<br />
=== [feedback] ===<br />
: {{DevFeature1.11|8}} The [feedback] tag includes information used by the server to provide the client with a website URL for players to post feedback on an add-on and communicate with the maintainers. At this time, the official add-ons server is configured to take a single parameter described below.<br />
<br />
==== topic_id ====<br />
: {{DevFeature1.11|8}} Topic id from the [http://forums.wesnoth.org/ Wesnoth.org forums] for the add-on's feedback or development topic maintained by the add-on uploader or author. For existing topics, the '''topic_id''' corresponds to the series of digits in the '''t=YYYYY''' portion of an URL like <code><nowiki>http://forums.wesnoth.org/viewtopic.php?f=XX&t=YYYYY</nowiki></code>. You must take special care to ensure this information is valid before uploading if you want players to be able to reach you!<br />
<br />
<br />
The add-on server keeps track of some other information about uploaded content, including when they were uploaded, what languages they have been at least partly translated into, how large they are on the server and the number of times they have been downloaded. For more information about this you can read [[CampaignServerWML]].<br />
<br />
== Examples ==<br />
<br />
=== Dependency Key Example ===<br />
<br />
The following dependency key could be used when the add-on needs the ''Imperial_Era'' and ''Era_of_Myths'' to be installed before it will work properly:<br />
<br />
dependencies=Imperial_Era,Era_of_Myths<br />
<br />
=== Version Key Examples ===<br />
<br />
The following are examples of '''good''' version values:<br />
<br />
version="1.5"<br />
<br />
version="0.11.4"<br />
<br />
version="0.1.4beta"<br />
<br />
version="1.5c"<br />
<br />
<br />
The following are examples of '''bad''' version values:<br />
<br />
version="Beta1.5"<br />
<br />
version="Incomplete (0.3.4)"<br />
<br />
In both of the above examples the version number as read by the server will be '''0.0.0Beta1.5''' and '''0.0.0Incomplete (0.3.4)'''. You can clearly see why this will not be a good thing with the ''Update add-ons'' feature.<br />
<br />
<br />
Finally, here are some example version numbers and how they will be interpreted by the ''Update add-ons'' button. The number on the left will be considered an earlier number than the number on the right in each example.<br />
<br />
0.5 < 1.0<br />
<br />
1.5 < 1.5c<br />
<br />
1.0 < 1.0.1<br />
<br />
1.0c < 1.0.1a<br />
<br />
1.0.1a < 1.0.1c<br />
<br />
1.0 Final < 1.0.1 Beta<br />
<br />
=== Example .pbl File ===<br />
<br />
title="My Campaign"<br />
type="campaign"<br />
icon="misc/ball.png"<br />
version="0.1.2"<br />
author="Me, artwork by myself"<br />
passphrase="This is like a password; see the security note in the documentation above before choosing a value of your own"<br />
description="You get to kill a lot of bad guys. But only the first map is done."<br />
email="name@example.com"<br />
# The following tag is only used by Wesnoth 1.11.8 and later!<br />
[feedback]<br />
topic_id=12345<br />
[/feedback]<br />
<br />
== See Also ==<br />
<br />
* [[ReferenceWML]]<br />
* [[CampaignServerWML]]<br />
* [[FancyAddonIcons]]<br />
<br />
[[Category: WML Reference]]</div>Fabihttps://wiki.wesnoth.org/index.php?title=PblWML&diff=55008PblWML2014-05-09T22:14:02Z<p>Fabi: /* type */</p>
<hr />
<div>{{WML Tags}}<br />
<br />
To upload an add-on you have made, you need a '''_server.pbl''' file in your add-on's directory, at the same leven as the '''_main.cfg''' file. When you upload the add-on, the entire directory and subdirectories containing the _server.pbl file will be published. Your add-on must be based entirely on these paths.<br />
<br />
See [[AddonStructure]] for more on setting up the add-on folder if you have not done so, and [[Distributing_Content]] for more on uploading an add-on to the server with this file.<br />
<br />
<b>Note:</b> Be aware that translations in the .pbl-files are '''not''' used, so don't mark these strings as translatable.<br />
<br />
== What goes into a .pbl file? ==<br />
<br />
'''Note:''' ''You should '''not''' use special formatting or coloring in any of these keys when uploading to the official server.'''''<br />
<br />
The following keys are recognized for .pbl files:<br />
<br />
=== icon ===<br />
: An image, displayed leftmost in the add-ons download dialog. It must be a standard Wesnoth file and '''not a custom one'''. A custom file will only work for users who already have the relevant add-on installed. This is not related to the icon used for entries in the campaigns menu -- see [[CampaignWML]] for more information.<br />
<br />
: If the icon is a unit with magenta team-color bits, please use [[ImagePathFunctionWML]] to recolor it.<br />
<br />
=== title ===<br />
: Displayed to the right of the icon, it is just text. It should usually be the same as the name of your add-on when it is played.<br />
<br />
=== version ===<br />
: Displayed to the right of the title, it is just text. However, starting with Wesnoth 1.6, the ''required'' format is x.y.z where x, y and z are numbers and a value for x greater than 0 implies the add-on is complete feature-wise. Trailing non-numeric elements are allowed, but nothing should appear ''before'' the numbers. This is necessary for the ''Update add-ons'' button to work correctly. ([[#Version Key Examples|See Examples]])<br />
<br />
=== author ===<br />
: Displayed to the right of the version, it is just text. Put your name or nickname here. If several people have contributed significantly to the add-on you may want to list all of their names.<br />
<br />
=== passphrase ===<br />
: Not displayed, it prevents others from modifying the version of your add-on on the server. You do not need to input a passphrase when initially publishing a add-on; if you do not, one will be randomly generated for you and replaced in your local copy of the .pbl file.<br />
: '''SECURITY NOTE:''' If you do specify a passphrase of your own, note that it is stored in '''clear text''' form in the server; '''do NOT use a password you would normally use for any other services or web sites!'''<br />
<br />
=== description ===<br />
: This can be used to provide a brief description of your add-on, and for pre-1.0 versions, let people know how playable it is. The description can be viewed by users by clicking on the Description button in the built-in client, or by moving their mouse over the add-on's icon in the web interface.<br />
<br />
=== dependencies ===<br />
: An optional list of dependencies (a comma separated list of ''addon-name'' – the directory names of the needed add-ons), which should be provided if your add-on relies on other user-made content to work properly. ([[#Dependency Key Example|See Example]])<br />
<br />
=== translate ===<br />
: If set to '''true''', the add-on will be sent to and updated with [[WesCamp|WesCamp-i18n]]. (NOTE: this is a new and experimental function, which will automatically update the translations in your add-on. Make sure you make backups of your add-on in case of problems.)<br />
<br />
: You should make sure your add-on complies with some very specific [[WesCamp#Preparing_your_add-on_for_WesCamp|conventions]] required to ease the process for translators as well as technical requirements.<br />
<br />
=== type ===<br />
: Indicates the type of the add-on, used for the downloads manager dialog. Possible values are:<br />
<br />
:* ''core'': replaces the whole wml tree. {{DevFeature1.13|0}}<br />
:* ''campaign'': single player campaign.<br />
:* ''scenario'': single player scenario.<br />
:* ''campaign_sp_mp'': hybrid campaign.<br />
:* ''era'': multiplayer era.<br />
:* ''faction'': multiplayer stand-alone faction, or add-on for other available era.<br />
:* ''map_pack'': multiplayer map-pack.<br />
:* ''campaign_mp'': multiplayer campaign.<br />
:* ''scenario_mp'': multiplayer scenario. (See the note below.)<br />
:* ''mod_mp'': multiplayer modification.<br />
:* ''media'': miscellaneous resources for UMC authors/users, for example, music packs, packages of general-purpose WML, etc.<br />
:* ''other'': The type to use when no other type fits.<br />
<br />
'''Note:''' If your add-on contains two or more separate multiplayer scenarios, use ''map_pack''.<br />
<br />
=== email ===<br />
: Hidden e-mail address used by the server administrators to contact content authors in case of major issues. Again, this will only be seen by the server administrators and it is required that you provide one in case you need to be contacted about your add-on.<br />
<br />
=== [feedback] ===<br />
: {{DevFeature1.11|8}} The [feedback] tag includes information used by the server to provide the client with a website URL for players to post feedback on an add-on and communicate with the maintainers. At this time, the official add-ons server is configured to take a single parameter described below.<br />
<br />
==== topic_id ====<br />
: {{DevFeature1.11|8}} Topic id from the [http://forums.wesnoth.org/ Wesnoth.org forums] for the add-on's feedback or development topic maintained by the add-on uploader or author. For existing topics, the '''topic_id''' corresponds to the series of digits in the '''t=YYYYY''' portion of an URL like <code><nowiki>http://forums.wesnoth.org/viewtopic.php?f=XX&t=YYYYY</nowiki></code>. You must take special care to ensure this information is valid before uploading if you want players to be able to reach you!<br />
<br />
<br />
The add-on server keeps track of some other information about uploaded content, including when they were uploaded, what languages they have been at least partly translated into, how large they are on the server and the number of times they have been downloaded. For more information about this you can read [[CampaignServerWML]].<br />
<br />
== Examples ==<br />
<br />
=== Dependency Key Example ===<br />
<br />
The following dependency key could be used when the add-on needs the ''Imperial_Era'' and ''Era_of_Myths'' to be installed before it will work properly:<br />
<br />
dependencies=Imperial_Era,Era_of_Myths<br />
<br />
=== Version Key Examples ===<br />
<br />
The following are examples of '''good''' version values:<br />
<br />
version="1.5"<br />
<br />
version="0.11.4"<br />
<br />
version="0.1.4beta"<br />
<br />
version="1.5c"<br />
<br />
<br />
The following are examples of '''bad''' version values:<br />
<br />
version="Beta1.5"<br />
<br />
version="Incomplete (0.3.4)"<br />
<br />
In both of the above examples the version number as read by the server will be '''0.0.0Beta1.5''' and '''0.0.0Incomplete (0.3.4)'''. You can clearly see why this will not be a good thing with the ''Update add-ons'' feature.<br />
<br />
<br />
Finally, here are some example version numbers and how they will be interpreted by the ''Update add-ons'' button. The number on the left will be considered an earlier number than the number on the right in each example.<br />
<br />
0.5 < 1.0<br />
<br />
1.5 < 1.5c<br />
<br />
1.0 < 1.0.1<br />
<br />
1.0c < 1.0.1a<br />
<br />
1.0.1a < 1.0.1c<br />
<br />
1.0 Final < 1.0.1 Beta<br />
<br />
=== Example .pbl File ===<br />
<br />
title="My Campaign"<br />
type="campaign"<br />
icon="misc/ball.png"<br />
version="0.1.2"<br />
author="Me, artwork by myself"<br />
passphrase="This is like a password; see the security note in the documentation above before choosing a value of your own"<br />
description="You get to kill a lot of bad guys. But only the first map is done."<br />
email="name@example.com"<br />
# The following tag is only used by Wesnoth 1.11.8 and later!<br />
[feedback]<br />
topic_id=12345<br />
[/feedback]<br />
<br />
== See Also ==<br />
<br />
* [[ReferenceWML]]<br />
* [[CampaignServerWML]]<br />
* [[FancyAddonIcons]]<br />
<br />
[[Category: WML Reference]]</div>Fabihttps://wiki.wesnoth.org/index.php?title=PblWML&diff=55007PblWML2014-05-09T22:13:00Z<p>Fabi: /* type */</p>
<hr />
<div>{{WML Tags}}<br />
<br />
To upload an add-on you have made, you need a '''_server.pbl''' file in your add-on's directory, at the same leven as the '''_main.cfg''' file. When you upload the add-on, the entire directory and subdirectories containing the _server.pbl file will be published. Your add-on must be based entirely on these paths.<br />
<br />
See [[AddonStructure]] for more on setting up the add-on folder if you have not done so, and [[Distributing_Content]] for more on uploading an add-on to the server with this file.<br />
<br />
<b>Note:</b> Be aware that translations in the .pbl-files are '''not''' used, so don't mark these strings as translatable.<br />
<br />
== What goes into a .pbl file? ==<br />
<br />
'''Note:''' ''You should '''not''' use special formatting or coloring in any of these keys when uploading to the official server.'''''<br />
<br />
The following keys are recognized for .pbl files:<br />
<br />
=== icon ===<br />
: An image, displayed leftmost in the add-ons download dialog. It must be a standard Wesnoth file and '''not a custom one'''. A custom file will only work for users who already have the relevant add-on installed. This is not related to the icon used for entries in the campaigns menu -- see [[CampaignWML]] for more information.<br />
<br />
: If the icon is a unit with magenta team-color bits, please use [[ImagePathFunctionWML]] to recolor it.<br />
<br />
=== title ===<br />
: Displayed to the right of the icon, it is just text. It should usually be the same as the name of your add-on when it is played.<br />
<br />
=== version ===<br />
: Displayed to the right of the title, it is just text. However, starting with Wesnoth 1.6, the ''required'' format is x.y.z where x, y and z are numbers and a value for x greater than 0 implies the add-on is complete feature-wise. Trailing non-numeric elements are allowed, but nothing should appear ''before'' the numbers. This is necessary for the ''Update add-ons'' button to work correctly. ([[#Version Key Examples|See Examples]])<br />
<br />
=== author ===<br />
: Displayed to the right of the version, it is just text. Put your name or nickname here. If several people have contributed significantly to the add-on you may want to list all of their names.<br />
<br />
=== passphrase ===<br />
: Not displayed, it prevents others from modifying the version of your add-on on the server. You do not need to input a passphrase when initially publishing a add-on; if you do not, one will be randomly generated for you and replaced in your local copy of the .pbl file.<br />
: '''SECURITY NOTE:''' If you do specify a passphrase of your own, note that it is stored in '''clear text''' form in the server; '''do NOT use a password you would normally use for any other services or web sites!'''<br />
<br />
=== description ===<br />
: This can be used to provide a brief description of your add-on, and for pre-1.0 versions, let people know how playable it is. The description can be viewed by users by clicking on the Description button in the built-in client, or by moving their mouse over the add-on's icon in the web interface.<br />
<br />
=== dependencies ===<br />
: An optional list of dependencies (a comma separated list of ''addon-name'' – the directory names of the needed add-ons), which should be provided if your add-on relies on other user-made content to work properly. ([[#Dependency Key Example|See Example]])<br />
<br />
=== translate ===<br />
: If set to '''true''', the add-on will be sent to and updated with [[WesCamp|WesCamp-i18n]]. (NOTE: this is a new and experimental function, which will automatically update the translations in your add-on. Make sure you make backups of your add-on in case of problems.)<br />
<br />
: You should make sure your add-on complies with some very specific [[WesCamp#Preparing_your_add-on_for_WesCamp|conventions]] required to ease the process for translators as well as technical requirements.<br />
<br />
=== type ===<br />
: Indicates the type of the add-on, used for the downloads manager dialog. Possible values are:<br />
<br />
:* ''core'': replaces the whole wml tree.<br />
:* ''campaign'': single player campaign.<br />
:* ''scenario'': single player scenario.<br />
:* ''campaign_sp_mp'': hybrid campaign.<br />
:* ''era'': multiplayer era.<br />
:* ''faction'': multiplayer stand-alone faction, or add-on for other available era.<br />
:* ''map_pack'': multiplayer map-pack.<br />
:* ''campaign_mp'': multiplayer campaign.<br />
:* ''scenario_mp'': multiplayer scenario. (See the note below.)<br />
:* ''mod_mp'': multiplayer modification.<br />
:* ''media'': miscellaneous resources for UMC authors/users, for example, music packs, packages of general-purpose WML, etc.<br />
:* ''other'': The type to use when no other type fits.<br />
<br />
'''Note:''' If your add-on contains two or more separate multiplayer scenarios, use ''map_pack''.<br />
<br />
=== email ===<br />
: Hidden e-mail address used by the server administrators to contact content authors in case of major issues. Again, this will only be seen by the server administrators and it is required that you provide one in case you need to be contacted about your add-on.<br />
<br />
=== [feedback] ===<br />
: {{DevFeature1.11|8}} The [feedback] tag includes information used by the server to provide the client with a website URL for players to post feedback on an add-on and communicate with the maintainers. At this time, the official add-ons server is configured to take a single parameter described below.<br />
<br />
==== topic_id ====<br />
: {{DevFeature1.11|8}} Topic id from the [http://forums.wesnoth.org/ Wesnoth.org forums] for the add-on's feedback or development topic maintained by the add-on uploader or author. For existing topics, the '''topic_id''' corresponds to the series of digits in the '''t=YYYYY''' portion of an URL like <code><nowiki>http://forums.wesnoth.org/viewtopic.php?f=XX&t=YYYYY</nowiki></code>. You must take special care to ensure this information is valid before uploading if you want players to be able to reach you!<br />
<br />
<br />
The add-on server keeps track of some other information about uploaded content, including when they were uploaded, what languages they have been at least partly translated into, how large they are on the server and the number of times they have been downloaded. For more information about this you can read [[CampaignServerWML]].<br />
<br />
== Examples ==<br />
<br />
=== Dependency Key Example ===<br />
<br />
The following dependency key could be used when the add-on needs the ''Imperial_Era'' and ''Era_of_Myths'' to be installed before it will work properly:<br />
<br />
dependencies=Imperial_Era,Era_of_Myths<br />
<br />
=== Version Key Examples ===<br />
<br />
The following are examples of '''good''' version values:<br />
<br />
version="1.5"<br />
<br />
version="0.11.4"<br />
<br />
version="0.1.4beta"<br />
<br />
version="1.5c"<br />
<br />
<br />
The following are examples of '''bad''' version values:<br />
<br />
version="Beta1.5"<br />
<br />
version="Incomplete (0.3.4)"<br />
<br />
In both of the above examples the version number as read by the server will be '''0.0.0Beta1.5''' and '''0.0.0Incomplete (0.3.4)'''. You can clearly see why this will not be a good thing with the ''Update add-ons'' feature.<br />
<br />
<br />
Finally, here are some example version numbers and how they will be interpreted by the ''Update add-ons'' button. The number on the left will be considered an earlier number than the number on the right in each example.<br />
<br />
0.5 < 1.0<br />
<br />
1.5 < 1.5c<br />
<br />
1.0 < 1.0.1<br />
<br />
1.0c < 1.0.1a<br />
<br />
1.0.1a < 1.0.1c<br />
<br />
1.0 Final < 1.0.1 Beta<br />
<br />
=== Example .pbl File ===<br />
<br />
title="My Campaign"<br />
type="campaign"<br />
icon="misc/ball.png"<br />
version="0.1.2"<br />
author="Me, artwork by myself"<br />
passphrase="This is like a password; see the security note in the documentation above before choosing a value of your own"<br />
description="You get to kill a lot of bad guys. But only the first map is done."<br />
email="name@example.com"<br />
# The following tag is only used by Wesnoth 1.11.8 and later!<br />
[feedback]<br />
topic_id=12345<br />
[/feedback]<br />
<br />
== See Also ==<br />
<br />
* [[ReferenceWML]]<br />
* [[CampaignServerWML]]<br />
* [[FancyAddonIcons]]<br />
<br />
[[Category: WML Reference]]</div>Fabihttps://wiki.wesnoth.org/index.php?title=CoreWML&diff=55006CoreWML2014-05-09T22:11:42Z<p>Fabi: /* The [core] Tag */</p>
<hr />
<div>{{WML Tags}}<br />
<br />
This page describes how the core is displayed in the "Load Core" menu, and how it works.<br />
<br />
==The [core] Tag== <br />
{{DevFeature1.13}}<br />
<br />
The following keys and tags are recognized in '''[core]''' tags:<br />
* '''id''': the internal core identifier used to load only core specific add-ons.<br />
* '''icon''': the image displayed in the core selection menu<br />
* '''name''': (translatable) name displayed in the core selection menu<br />
* '''image''': the image shown in the information pane when this core is selected in the core selection menu (typically a transparent, 350×350 pixels portrait)<br />
* '''description''': (translatable) text shown in the information pane when this core is selected in the core selection menu<br />
* '''rank''': a number that determines the order of cores in the core selection menu. Lower ''rank'' campaigns appear earlier, with unranked cores at the end. Currently the mainline cores use multiples of 10 from 0 to 100.<br />
* '''path''': the path to the core's directory or initial config file.<br />
<br />
== See Also ==<br />
<br />
* [[PreprocessorRef]]<br />
* [[ReferenceWML]]<br />
* [[PblWML]]<br />
<br />
<br />
[[Category: WML Reference]]</div>Fabihttps://wiki.wesnoth.org/index.php?title=CoreWML&diff=55005CoreWML2014-05-09T22:11:04Z<p>Fabi: Created page with "{{WML Tags}} This page describes how the core is displayed in the "Load Core" menu, and how it works. ==The [core] Tag== {{DevFeature1.13}} The following keys and tags are..."</p>
<hr />
<div>{{WML Tags}}<br />
<br />
This page describes how the core is displayed in the "Load Core" menu, and how it works.<br />
<br />
==The [core] Tag== <br />
{{DevFeature1.13}}<br />
<br />
The following keys and tags are recognized in '''[core]''' tags:<br />
* '''id''': the internal core identifier used to ... TODO<br />
* '''icon''': the image displayed in the core selection menu<br />
* '''name''': (translatable) name displayed in the core selection menu<br />
* '''image''': the image shown in the information pane when this core is selected in the core selection menu (typically a transparent, 350×350 pixels portrait)<br />
* '''description''': (translatable) text shown in the information pane when this core is selected in the core selection menu<br />
* '''rank''': a number that determines the order of cores in the core selection menu. Lower ''rank'' campaigns appear earlier, with unranked cores at the end. Currently the mainline cores use multiples of 10 from 0 to 100.<br />
* '''path''': the path to the core's directory or initial config file.<br />
<br />
== See Also ==<br />
<br />
* [[PreprocessorRef]]<br />
* [[ReferenceWML]]<br />
* [[PblWML]]<br />
<br />
<br />
[[Category: WML Reference]]</div>Fabihttps://wiki.wesnoth.org/index.php?title=ReferenceWML&diff=55004ReferenceWML2014-05-09T22:00:35Z<p>Fabi: /* WML toplevel tags */</p>
<hr />
<div>{{WML Tags}}<br />
== The Wesnoth Markup Language ==<br />
<br />
The Wesnoth Markup Language (WML) is used to code almost everything in Wesnoth, including scenarios, units, savefiles, and the user interface layout. WML files are simple, human-readable text files, usually with the .cfg extension, with similarities to INI files and XML. A major feature in WML are macros, which are alike those found in the C language and similarily are handled by a preprocessor. Implementation-wise, WML files are handled mainly by the ''config'' class (and ''simple_wml'' in [[wesnothd]]).<br />
<br />
This page is a collection of pointers to different common WML structures. See [[AlphabeticalWML]] for a quick listing of all WML tags. The more comprehensive [[BuildingScenariosIndex]] lists tags and keys.<br />
<br />
See [[BuildingScenarios]], [[BuildingCampaigns]] and [[BuildingUnits]]<br />
for a tutorial style overview.<br />
<br />
<br />
<br />
''Note: this reference may contain slight inaccuracies, might not list all existing keys and tags or might contain some deprecated syntax. If you find that this reference doesn't give you the answer to how to implement some feature in WML, the most reliable way is to look at the WML code of existing units and campaigns that have done so.''<br />
<br />
== How WML works ==<br />
<br />
* [[SyntaxWML]] the syntactical definition of WML, and how to use variables<br />
* [[PreprocessorRef]] the WML preprocessor syntax<br />
<br />
== WML toplevel tags ==<br />
<br />
* [[GameConfigWML]] the top level '''[game_config]''' tag<br />
* [[UnitsWML]] the top level '''[units]''' tag<br />
** [[UnitTypeWML]] how to describe a unit type<br />
** [[AnimationWML]] how to animate units<br />
* [[CampaignWML]] the top level '''[campaign]''' tag<br />
* [[CoreWML]] the top level '''[core]''' tag<br />
* [[ScenarioWML]] the top level tags '''[scenario]''', '''[multiplayer]''', '''[test]''', and '''[tutorial]'''<br />
** [[EventWML]] how to describe an event<br />
** [[SideWML]] how to describe a side<br />
** [[MapGeneratorWML]] the random map generator<br />
** [[TimeWML]] how to describe a day<br />
** [[IntroWML]] how to describe the intro screen<br />
* [[SavefileWML]] a description of the format of savegames<br />
** [[ReplayWML]] a description of the format of player actions such as moving a unit<br />
** [[StatisticalScenarioWML]] used to generate statistics of a savegame<br />
* [[PblWML]] a description of the format of server-uploadable campaigns<br />
* [[EraWML]] the top level '''[era]''' tag<br />
* [[TerrainWML]] the top level '''[terrain_type]''' tag<br />
* [[TerrainGraphicsWML]], the top level '''[terrain_graphics]''' tag<br />
* [[ThemeWML]] the top level '''[theme]''' tag<br />
* [[LanguageWML]] the top level '''[language]''' tag<br />
* [[LocaleWML]] the top level '''[locale]''' tag<br />
* [[HelpWML]] the top level '''[help]''' tag<br />
* [[BinaryPathWML]] the top level '''[binary_path]''' tag<br />
* [[FontsWML]] the top level '''[fonts]''' tag<br />
<br />
== Other WML tags ==<br />
<br />
* [[EventWML]] how to describe an event<br />
** [[FilterWML]] the construct to filter on units, locations, and weapons<br />
** [[ActionWML]] to describe the actions which occur when the event is fired<br />
*** [[ConditionalActionsWML]] actions that encapsulate conditional filters and the actions to execute if the conditions are met<br />
*** [[DirectActionsWML]] actions that directly affect gameplay: for example creating a unit<br />
**** [[SingleUnitWML]] how to describe a unit<br />
*** [[InternalActionsWML]] actions that WML uses internally: for example storing a variable<br />
*** [[InterfaceActionsWML]] actions that do not affect gameplay: for example displaying a message<br />
*** [[LuaWML]] how to code actions with the Lua language<br />
* [[AiWML]] how to describe parameters for AI<br />
* [[EffectWML]] the construct to modify a unit<br />
* [[AbilitiesWML]] a list of the different abilities a unit or weapon can have<br />
* [[DescriptionWML]] the structure of WML coded menus like the difficulty chooser of campaigns<br />
* [[EditorWML]] tags controlling the post-1.4 editor's behavior<br />
<br />
== Predefined macros == <br />
<br />
Wesnoth ships with a library of predefined macros you should find useful in writing your own WML.<br />
* [http://www.wesnoth.org/macro-reference.xhtml WML Macros] - description of all such macros.<br />
<br />
== Other ==<br />
<br />
* [[ReferenceWMLSyntax]] how this wiki and the pages it links to should be formatted<br />
* [[ConventionsWML]] how to make your WML more readable<br />
* [[Wml_optimisation]] how to make your WML code more efficient<br />
* [[UsefulWMLFragments]] Various pieces of WML for various purposes. If you have some WML you're proud of that you think others can use, add it here.<br />
* [[Maintenance tools]] for wmlindent, wmllint, wmlscope<br />
* [[CommandMode]] commands are not strictly speaking part of WML, these could be a little hard to find so there's a link here.<br />
* [[MultiplayerServerWML]] is used when communicating with the multiplayer server.<br />
* [[CampaignServerWML]] is used when managing contributed campaigns on the campaign server.<br />
* [[ImagePathFunctionWML]] is used when applying the team-color function to images.<br />
* [[BinaryWML]] how WML is sent over the network<br />
<br />
== See Also ==<br />
<br />
* [[BuildingMaps]] the text-based format for Wesnoth maps<br />
* [[TerrainCodesWML]] a list of all terrains<br />
* [[MultiHexTutorial]] a description of the multi-hex tiling system<br />
* [[IGNFileFormat]] a description of the ignore file format<br />
<br />
<br />
[[Category: WML Reference]]</div>Fabihttps://wiki.wesnoth.org/index.php?title=BuildingMaps&diff=53155BuildingMaps2014-02-20T11:52:31Z<p>Fabi: Removed the section about a new map format.</p>
<hr />
<div>A map is the most basic of user made content you can create. Complex scenarios can be developed on them, or they can be played on their own as simple battlefields with with no extra work required.<br />
<br />
Wesnoth features a fully featured map editor, accessible from the <b>Map Editor</b> option at the main menu. Inside you will find all the tools you need to create your own arenas to stage your adventures. <br />
<br />
Inside the individual map files themselves are simply terrain codes that the games translates into graphics when you play. Usually you will never have to edit these files manually, but it can come in handy to understand the format. For more on terrain codes and the map data format, see the [[TerrainCodesWML]] page.<br />
<br />
For further instructions on what to do once you have completed your map, see below.<br />
<br />
== Creating a map ==<br />
<br />
When you first open the map editor, you are presented with a large blank canvas covered in Grass. Below is a general guide to turning this empty meadow into an interesting and challenging battlefield.<br />
<br />
#<b>Choose your map size</b> <br> You can resize your map with the resize function. Choose one proportional to the gameplay you would like to see on it. A close-knit battle arena? Smaller is better. A large epic, battle with many sizes? Go larger. Remember, though, to not make it to big, or you will bore your players. <br><br />
#<b>Decide on a theme</b> <br> Wesnoth includes many different terrains for many different situations. Caves, dungeons, meadows, icy wastes, beautiful fall scenery, etc. Decide on a general theme for your map and be sure to work with the terrains that best fit your chosen theme. <br><br />
# <b>Place large geographic features first</b> <br> If you were designing an outdoors map, now would be the time to draw large features such as mountain ranges, rivers, etc. On an indoors map, place the walls, design the passages, and room, etc. It doesn't have to be perfect, just a general outline to work with. <br><br />
# <b>Add castles, villages, and roads</b> <br> Every map needs castles and keeps to recruit on, and roads or flat terrain for units to move on (most units most best on Flat terrain such as roads, grass, or dirt). Add these now, making sure not to make your castles too big or close to one another. The placement of these determines the general flow of your scenario, so choose carefully. Also add villages. These will provide your team income and healing, so don't place them too close to each other (a general rule is about 6 hex radius (at minimum) around each village). Too many close together will result in imbalance from too much gold and health regeneration.<br />
# <b>Finer details</b> <br> Begin filling in the more open spaces of your map. Add forests, trees, hills, dirt, floors, the lot. Your map is beginning to take shape. Be sure to draw terrain features in a way that work with your plans for the scenario. For example, be sure to place brides where you want your units to be able to cross a river. <br><br />
# <b>Embellishments</b> <br> Your map is almost complete, but in order to look polished, throw in a few embellishments. Make the grass different colors. Put rocks and mud in the rivers. Strew trash around your buildings. Scatter flowers in the meadows. It's up to you, just don't overdo it.<br />
<br />
It can take a lot of practice. Making good, balanced, interesting maps is an art unto itself. ESR has more handy tips in his [http://catb.org/~esr/wesnoth/campaign-design-howto.html#_map_composition Campaign Design How-To] article. You can also ask for assistance on the [http://www.wesnoth.org/forum/viewforum.php?f=15 Multiplayer Development forum].<br />
<br />
== Now what? ==<br />
<br />
You've created an awesome map with the map editor and you're ready to test it out. But how can you do this? It's actually quite simple.<br />
<br />
=== Play your map ===<br />
<br />
If you just want to play the map, maybe against the computer or with a friend, all you have to do is save it into the map editor's folder (the default location). Then, when you launch the game and host a multiplayer game, the map should appear <b>at the top</b> of the map choices screen.<br />
<br />
When creating a game on the multiplayer server, your map will be described to other players as a "User Map" and any replays stored on the server will refer to the game as "User Map."<br />
<br />
For the curious: Saving a map file like this creates a stand-alone file that holds the map data. That file is by default saved in <b><i>userdata</i>/editor/maps/</b>, and maps in that location are added to the top of the multiplayer map selection list.<br />
<br />
=== Share your map ===<br />
<br />
When you're ready to share your map with the world, post it to the [http://www.wesnoth.org/forum/viewforum.php?f=15 Multiplayer Development forum] or package it to be distributed on the in-game add-ons server. For instructions on how to distribute maps, see [[BuildingMapsDistribution]]<br />
<br />
=== Turn your map into a scenario ===<br />
<br />
If you're interested in more complex gameplay, you can turn your map into a scenario. More information on how to proceed is on the [[BuildingScenarios]] page.<br />
<br />
== See Also ==<br />
<br />
* [[TerrainCodesWML]]<br />
* [[ScenarioWML]]<br />
* [[ReferenceWML]]<br />
<br />
{{Create}}</div>Fabihttps://wiki.wesnoth.org/index.php?title=TerrainWML&diff=52894TerrainWML2014-01-19T05:06:14Z<p>Fabi: /* the toplevel [terrain_type] tag */</p>
<hr />
<div>{{WML Tags}}<br />
== the toplevel [terrain_type] tag ==<br />
<br />
The [terrain_type] tag describes a terrain in WML.<br />
Terrains are usually described in the terrain.cfg file<br />
<br />
the [terrain_type] tag has the following keys and subtags<br />
* '''symbol_image''': an image used for this terrain in the minimap<br />
* '''editor_image''': an image used for this terrain in the map editor; if not defined uses symbol_image<br />
* '''id''': a non-translatable string identifying this terrain. It is used as the key for attributes in some parts of WML, such as {{tag|UnitsWML|movetype}} (but see also the aliasof= attribute below; not all ids need to be listed under movetypes).<br />
* '''name''': the name of the terrain, a translatable string used for the display of terrain type in the game and the map editor<br />
* '''description''': the detailed description of the terrain, a translatable string used for the display of terrain type in the game and the map editor. If this is not present, the game and editor will fall back to the '''name''' attribute. The difference is that the name tends to describe the game effect of the terrain type (e.g., "Forest") but the description attribute also carries information about visual subtype (e.g. "Summer Deciduous Forest").<br />
* '''editor_name''': a detailed name for the terrain used only in the map editor. Terrains are presented in the editor as "''<editor_name>''/''<name>'' (''<aliases>'')" when this attribute is used.<br />
* '''string''': this is the string that represents the terrain in maps and scenarios<br />
* '''unit_height_adjust''': how much the unit graphic should be moved up or down when on that terrain<br />
* '''submerge''': float, between 0 and 1: specifies how much of the unit graphic should be submerged by the terrain<br />
* '''light''': signed value: this will modify the local light level on that hex by that amount for gameplay.<br />
* '''max_light''': {{DevFeature1.11}} signed value: this is the maximum local light level that may be indicated by light=. Defaults to the value of light= and is effectively overridden by the time-of-day lighting, if that is higher.<br />
* '''min_light''': {{DevFeature1.11}} signed value: this is the minimum local light level that may be indicated by light=. Defaults to the value of light= and is effectively overridden by the time-of-day lighting, if that is lower.<br />
* '''heals''': signed value: this value is the amount of HP a unit on this terrain will be healed at the start of every turn. (If set to true a unit on that terrain will be healed 8 HP at the start of every turn.) This notation is <b>deprecated</b> and support might be removed at some point.<br />
* '''gives_income''': if set to true, this terrain will give income every turn when flagged, as if it were a village<br />
* '''recruit_onto''': if set to true, it is possible to recruit or recall on that terrain<br />
* '''recruit_from''': if set to true it is possible to recruit when a unit that can recruit is on that terrain<br />
* '''aliasof''': comma separated string of terrains of which this terrain will be an alias. This is a list of terrains, with + and - signs having special meanings. The string is read left to right taking the best value until a minus sign is encountered, after which it takes the worst value instead. The plus sign reverts to best value. (Note: after a + or - a comma is also required. In order to include a + sign the entire line must be placed between double quotes.)<br />
* '''def_alias''': like ''aliasof'' but overides it for defense calculation only<br />
* '''mvt_alias''': like ''aliasof'' but overides it for movement calculation only<br />
* '''income_description''': for terrains with ''gives_income'' and owned by nobody this text is shown in the terrain description in the top bar before the brackets. This tag is optional, if not supplied Wesnoth will assume the terrain is a village and sets an appropriate message.<br />
* '''income_description_ally''': like ''income_description'' but if owned by an ally<br />
* '''income_description_enemy''': like ''income_description'' but if owned by an enemy<br />
* '''income_description_own''': like ''income_description'' but if owned by yourself<br />
* '''editor_group''': a comma separated list of editor_group ids to which this terrain belongs.<br />
* '''hidden''': (boolean) if set to 'yes', makes this terrain not appear in the map editor palettes.<br />
* '''hide_help''': {{DevFeature1.11}} (boolean) if set to 'yes', makes this terrain not appear in the terrain help browser.<br />
<br />
== See Also ==<br />
<br />
* [[ReferenceWML]]<br />
* [[TerrainCodesWML]]<br />
* [[EditorGroupWML]]<br />
<br />
<br />
[[Category: WML Reference]]</div>Fabihttps://wiki.wesnoth.org/index.php?title=TerrainWML&diff=52893TerrainWML2014-01-19T05:05:18Z<p>Fabi: /* the toplevel [terrain_type] tag */</p>
<hr />
<div>{{WML Tags}}<br />
== the toplevel [terrain_type] tag ==<br />
<br />
The [terrain_type] tag describes a terrain in WML.<br />
Terrains are usually described in the terrain.cfg file<br />
<br />
the [terrain_type] tag has the following keys and subtags<br />
* '''symbol_image''': an image used for this terrain in the minimap<br />
* '''editor_image''': an image used for this terrain in the map editor; if not defined uses symbol_image<br />
* '''id''': a non-translatable string identifying this terrain. It is used as the key for attributes in some parts of WML, such as {{tag|UnitsWML|movetype}} (but see also the aliasof= attribute below; not all ids need to be listed under movetypes).<br />
* '''name''': the name of the terrain, a translatable string used for the display of terrain type in the game and the map editor<br />
* '''description''': the detailed description of the terrain, a translatable string used for the display of terrain type in the game and the map editor. If this is not present, the game and editor will fall back to the '''name''' attribute. The difference is that the name tends to describe the game effect of the terrain type (e.g., "Forest") but the description attribute also carries information about visual subtype (e.g. "Summer Deciduous Forest").<br />
* '''editor_name''': a detailed name for the terrain used only in the map editor. Terrains are presented in the editor as "''<editor_name>''/''<name>'' (''<aliases>'')" when this attribute is used.<br />
* '''string''': this is the string that represents the terrain in maps and scenarios<br />
* '''unit_height_adjust''': how much the unit graphic should be moved up or down when on that terrain<br />
* '''submerge''': float, between 0 and 1: specifies how much of the unit graphic should be submerged by the terrain<br />
* '''light''': signed value: this will modify the local light level on that hex by that amount for gameplay.<br />
* '''max_light''': {{DevFeature1.11}} signed value: this is the maximum local light level that may be indicated by light=. Defaults to the value of light= and is effectively overridden by the time-of-day lighting, if that is higher.<br />
* '''min_light''': {{DevFeature1.11}} signed value: this is the minimum local light level that may be indicated by light=. Defaults to the value of light= and is effectively overridden by the time-of-day lighting, if that is lower.<br />
* '''heals''': signed value: this value is the amount of HP a unit on this terrain will be healed at the start of every turn. (If set to true a unit on that terrain will be healed 8 HP at the start of every turn.) This notation is <b>deprecated</b> and support might be removed at some point.<br />
* '''gives_income''': if set to true, this terrain will give income every turn when flagged, as if it were a village<br />
* '''recruit_onto''': if set to true, it is possible to recruit or recall on that terrain<br />
* '''recruit_from''': if set to true it is possible to recruit when a unit that can recruit is on that terrain<br />
* '''aliasof''': comma separated string of terrains of which this terrain will be an alias. This is a list of terrains, with + and - signs having special meanings. The string is read left to right taking the best value until a minus sign is encountered, after which it takes the worst value instead. The plus sign reverts to best value. (Note: after a + or - a comma is also required. In order to include a + sign the entire line must be placed between double quotes.)<br />
* '''def_alias''': like ''aliasof'' but overides it for defense calculation only<br />
* '''mvt_alias''': like ''aliasof'' but overides it for movement calculation only<br />
* '''income_description''': for terrains with ''gives_income'' and owned by nobody this text is shown in the terrain description in the top bar before the brackets. This tag is optional, if not supplied Wesnoth will assume the terrain is a village and sets an appropriate message.<br />
* '''income_description_ally''': like ''income_description'' but if owned by an ally<br />
* '''income_description_enemy''': like ''income_description'' but if owned by an enemy<br />
* '''income_description_own''': like ''income_description'' but if owned by yourself<br />
* '''editor_group''': a comma separated list of editor_group ids to which this terrain belongs.<br />
* '''hidden''': (boolean) if set to 'yes', makes this terrain not appear in the map editor palettes.<br />
* '''hide_help''': (boolean) if set to 'yes', makes this terrain not appear in the terrain help browser.<br />
<br />
== See Also ==<br />
<br />
* [[ReferenceWML]]<br />
* [[TerrainCodesWML]]<br />
* [[EditorGroupWML]]<br />
<br />
<br />
[[Category: WML Reference]]</div>Fabihttps://wiki.wesnoth.org/index.php?title=Template:WML_Tags&diff=52693Template:WML Tags2013-12-31T12:31:29Z<p>Fabi: </p>
<hr />
<div>{| class="gallery" style="width:225px;float: right;border: 1px solid #B48648; color:#B48648; font-size: 7pt;margin-left;10px;"<br />
|-<br />
|<br />
<span style="float: right;"><small class="editlink noprint plainlinksneverexpand">[{{SERVER}}{{localurl:Template:WML Tags|action=edit}} edit ]</small></span><br />
'''WML Tags'''<br />
<br />
|-<br />
|''A:'' <br />
[[AbilitiesWML|abilities]],<br />
[[CampaignWML#Campaign credits|about]],<br />
[[Lua_AI_Howto#Behavior_.28Sticky.29_Candidate_Actions|add_ai_behavior]],<br />
[[AbilitiesWML#Common_keys_and_tags_for_every_ability|adjacent_description]],<br />
[[SingleUnitWML|advance]],<br />
[[AdvancedPreferenceWML|advanced_preference]],<br />
[[UnitTypeWML|advancefrom]],<br />
[[UnitTypeWML#After_max_level_advancement_.28AMLA.29|advancement]],<br />
[[StatisticalScenarioWML#The_.5Bteam.5D_tag|advances]],<br />
[[AbilitiesWML#Common_keys_and_tags_for_every_ability|affect_adjacent]],<br />
[[AiWML#The_.5Bai.5D_Tag:_Defining_Aspects|ai]],<br />
[[StandardSideFilter|allied_with]], <br />
[[DirectActionsWML#.5Ballow_end_turn.5D|allow_end_turn]],<br />
[[DirectActionsWML#.5Ballow_extra_recruit.5D|allow_extra_recruit]],<br />
[[DirectActionsWML#.5Ballow_recruit.5D|allow_recruit]],<br />
[[DirectActionsWML#.5Ballow_undo.5D|allow_undo]],<br />
[[ConditionalActionsWML#Meta-Condition_Tags|and]],<br />
[[InterfaceActionsWML#.5Banimate_unit.5D|animate]],<br />
[[InterfaceActionsWML#.5Banimate_unit.5D|animate_unit]],<br />
[[AnimationWML|animation]],<br />
[[VariablesWML#Array|array]],<br />
[[AiWML#A_Bit_More_on_Simple_vs._Composite_Aspects|aspect]],<br />
[[UnitTypeWML#Attacks|attack]],<br />
[[AnimationWML|attack_anim]],<br />
[[StatisticalScenarioWML#The_.5Bteam.5D_tag|attacks]],<br />
[[AiWML#The_.5Bai.5D_Tag:_Defining_Aspects|avoid]];<br />
|-<br />
|''B:'' <br />
[[UnitTypeWML#Other_tags|base_unit]], <br />
[[AbilitiesWML|berserk]], <br />
[[BinaryPathWML|binary_path]], <br />
[[EditorWML#The_.5Bbrush.5D_tag|brush]];<br />
|-<br />
|''C:'' <br />
[[CampaignWML#The_.5Bcampaign.5D_tag|campaign]],<br />
[[Formula_AI_Howto#Setting_up_the_RCA_main_loop_Stage_and_Candidate_Actions|candidate_action]], <br />
[[DirectActionsWML#.5Bcapture_village.5D|capture_village]],<br />
[[ConditionalActionsWML#.5Bswitch.5D|case]],<br />
[[MapGeneratorWML#The_Default_Generator|castle]], <br />
[[MapGeneratorWML#The_Cave_Generator|chamber]], <br />
[[AbilitiesWML#The_.5Bspecials.5D_tag|chance_to_hit]], <br />
[[InterfaceActionsWML#.5Bchat.5D|chat]],<br />
[[ReplayWML|choose]],<br />
[[PersistenceWML|clear_global_variable]],<br />
[[InterfaceActionsWML#.5Bclear_menu_item.5D|clear_menu_item]],<br />
[[InternalActionsWML#.5Bclear_variable.5D|clear_variable]],<br />
[[InterfaceActionsWML#.5Bcolor_adjust.5D|color_adjust]],<br />
command&nbsp;([[ConditionalActionsWML#.5Bcommand.5D|action]], [[ReplayWML|replay]]),<br />
[[MapGeneratorWML#The_Default_Generator|convert]], <br />
[[AiWML#The_.5Bgoal.5D_Tag|criteria]];<br />
|-<br />
|''D:'' <br />
[[AbilitiesWML#The_.5Bspecials.5D_tag|damage]],<br />
[[AnimationWML#death|death]], <br />
[[StatisticalScenarioWML#The_.5Bteam.5D_tag|deaths]],<br />
[[AnimationWML#default|default]], <br />
[[AnimationWML#defend|defend]],<br />
[[StatisticalScenarioWML#The_.5Bteam.5D_tag|defends]],<br />
[[UnitsWML#.5Bmovetype.5D|defense]],<br />
[[InterfaceActionsWML#.5Bdelay.5D|delay]],<br />
[[InterfaceActionsWML#.5Bdeprecated_message.5D|deprecated_message]],<br />
[[ReplayWML|destination]],<br />
[[DirectActionsWML#.5Bdisallow_end_turn.5D|disallow_end_turn]],<br />
[[DirectActionsWML#.5Bdisallow_extra_recruit.5D|disallow_extra_recruit]],<br />
[[DirectActionsWML#.5Bdisallow_recruit.5D|disallow_recruit]],<br />
[[ConditionalActionsWML#.5Bwhile.5D|do]], <br />
[[AbilitiesWML#The_.5Bspecials.5D_tag|drains]], <br />
[[AnimationWML#draw_weapon_anim|draw_weapon_anim]];<br />
|-<br />
|''E:'' <br />
[[EditorWML#The_.5Beditor_group.5D_tag|editor_group]],<br />
[[EditorWML#The_.5Beditor_music.5D_tag|editor_music]], <br />
[[EditorWML#The_.5Beditor_times.5D_tag|editor_times]],<br />
[[EffectWML|effect]],<br />
else&nbsp;([[ConditionalActionsWML#.5Bif.5D|action]], [[AnimationWML#.5Bif.5D_and_.5Belse.5D|animation]]),<br />
[[DirectActionsWML#.5Bendlevel.5D|endlevel]],<br />
end_turn&nbsp;([[DirectActionsWML#.5Bend_turn.5D|action]], [[ReplayWML|replay]]),<br />
[[StandardSideFilter|enemy_of]], <br />
[[Customizing_AI_in_Wesnoth_1.8#AI_engines_.28_via_.5Bengine.5D_tags_.29|engine]], <br />
[[CampaignWML#Campaign_credits|entry]], <br />
[[EraWML|era]],<br />
[[EventWML|event]],<br />
[[ThemeWML#.5Bstatus.5D|expenses]], <br />
[[AnimationWML#Simplified_animation_blocks|extra_anim]];<br />
|-<br />
|''F:''<br />
[[AiWML#A_Bit_More_on_Simple_vs._Composite_Aspects|facet]],<br />
[[InterfaceActionsWML#.5Banimate_unit.5D|facing]], <br />
[[InterfaceActionsWML#.5Bmove_units_fake.5D|fake_unit]], <br />
[[UnitTypeWML#Other_tags|female]], <br />
[[FilterWML|filter]],<br />
[[StandardUnitFilter|filter_adjacent]], <br />
[[StandardLocationFilter|filter_adjacent_location]], <br />
[[FilterWML#Filtering_Weapons|filter_attack]],<br />
[[AbilitiesWML#Common_keys_and_tags_for_every_weapon_special|filter_attacker]], <br />
[[AbilitiesWML#Common_keys_and_tags_for_every_ability|filter_base_value]], <br />
[[EventWML#.5Bfilter_condition.5D|filter_condition]],<br />
[[AbilitiesWML#Common_keys_and_tags_for_every_weapon_special|filter_defender]], <br />
[[AiWML#Filtering_Combat_with_the_.27attacks.27_Aspect|filter_enemy]],<br />
[[StandardLocationFilter|filter_location]],<br />
[[AbilitiesWML#Common_keys_and_tags_for_every_weapon_special|filter_opponent]], <br />
[[AiWML#Filtering_Combat_with_the_.27attacks.27_Aspect|filter_own]],<br />
[[StandardLocationFilter|filter_owner]], <br />
[[StandardLocationFilter|filter_radius]], <br />
[[SingleUnitWML|filter_recall]], <br />
[[StandardUnitFilter|filter_second]],<br />
[[FilterWML#Filtering_Weapons|filter_second_attack]],<br />
[[AbilitiesWML|filter_self]], <br />
[[StandardSideFilter|filter_side]],<br />
[[FilterWML#Filtering_Vision|filter_vision]],<br />
[[AbilitiesWML#Common_keys_and_tags_for_every_weapon_special|filter_weapon]], <br />
[[StandardUnitFilter|filter_wml]],<br />
[[InternalActionsWML#.5Bfind_path.5D|find_path]],<br />
[[InternalActionsWML#.5Bfire_event.5D|fire_event]],<br />
[[AbilitiesWML#The_.5Bspecials.5D_tag|firststrike]], <br />
[[InterfaceActionsWML#.5Bfloating_text.5D|floating_text]],<br />
[[AnimationWML#Frames|frame]];<br />
|-<br />
|''G:'' <br />
[[GameConfigWML|game_config]],<br />
[[MapGeneratorWML|generator]],<br />
[[PersistenceWML|get_global_variable]],<br />
[[AiWML#The_.5Bgoal.5D_Tag|goal]],<br />
gold&nbsp;([[DirectActionsWML#.5Bgold.5D|action]], [[ThemeWML|theme]]),<br />
[[InterfaceActionsWML#.5Bobjectives.5D|gold_carryover]];<br />
|-<br />
|''H:'' <br />
[[DirectActionsWML#.5Bharm_unit.5D|harm_unit]],<br />
[[StandardSideFilter|has_unit]], <br />
[[ConditionalActionsWML#Condition_Tags|have_location]],<br />
[[ConditionalActionsWML#Condition_Tags|have_unit]],<br />
[[AbilitiesWML#The_.5Bspecials.5D_tag|heal_on_hit]], <br />
[[DirectActionsWML#.5Bheal_unit.5D|heal_unit]],<br />
[[AnimationWML#healed|healed_anim]], <br />
[[AnimationWML#healing|healing_anim]], <br />
[[AbilitiesWML|heals]], <br />
[[MapGeneratorWML|height]], <br />
[[UnitsWML#.5Bhide_help.5D|hide_help]],<br />
[[InterfaceActionsWML#.5Bhide_unit.5D|hide_unit]],<br />
[[AbilitiesWML|hides]];<br />
|-<br />
|''I:'' <br />
[[AnimationWML#idling|idle_anim]], <br />
if&nbsp;([[ConditionalActionsWML#.5Bif.5D|action]], [[AnimationWML#.5Bif.5D_and_.5Belse.5D|animation]]),<br />
[[AbilitiesWML|illuminates]], <br />
[[TerrainGraphicsWML|image]],<br />
[[ThemeWML#.5Bstatus.5D|income]],<br />
[[ReplayWML|init_side]],<br />
[[InternalActionsWML#.5Binsert_tag.5D|insert_tag]],<br />
[[InterfaceActionsWML#.5Binspect.5D|inspect]],<br />
[[InterfaceActionsWML#.5Bitem.5D|item]], <br />
[[MapGeneratorWML#The_Cave_Generator|items]];<br />
|-<br />
|''J:''<br />
[[InternalActionsWML#.5Bset_variables.5D|join]];<br />
|-<br />
|''K:'' <br />
[[DirectActionsWML#.5Bkill.5D|kill]],<br />
[[StatisticalScenarioWML|killed]];<br />
|-<br />
|''L:'' <br />
label&nbsp;([[InterfaceActionsWML#.5Blabel.5D|map]], [[ThemeWML|theme]]),<br />
[[LanguageWML|language]],<br />
[[AiWML#The_.5Bai.5D_Tag:_Defining_Aspects|leader_goal]],<br />
[[AbilitiesWML|leadership]], <br />
[[AnimationWML#leading|leading_anim]], <br />
[[AnimationWML#levelin|levelin_anim]],<br />
[[AnimationWML#levelout|levelout_anim]], <br />
[[DirectActionsWML#.5Blift_fog.5D|lift_fog]],<br />
[[AiWML#Limiting_Recruiting_with_the_.27recruitment.27_Aspect|limit]],<br />
[[InternalActionsWML#.5Bset_variables.5D|literal]], <br />
[[LocaleWML|locale]],<br />
[[InterfaceActionsWML#.5Block_view.5D|lock_view]],<br />
[[LuaWML|lua]];<br />
|-<br />
|''M:'' <br />
[[ThemeWML#.5Bmain_map.5D|main_map]],<br />
[[ThemeWML#.5Bmain_map_border.5D|main_map_border]], <br />
[[UnitTypeWML#Other_tags|male]], <br />
[[ThemeWML#.5Bmenu.5D|menu]], <br />
[[SavefileWML|menu_item]], <br />
[[InterfaceActionsWML#.5Bmessage.5D|message]],<br />
[[Micro AIs|micro_ai]],<br />
[[ThemeWML#.5Bmini_map.5D|mini_map]],<br />
[[AnimationWML#The_content_of_a_frame|missile_frame]],<br />
[[ModificationWML|modification]],<br />
[[SingleUnitWML|modifications]],<br />
[[DirectActionsWML#.5Bmodify_ai.5D|modify_ai]],<br />
[[DirectActionsWML#.5Bmodify_side.5D|modify_side]],<br />
[[DirectActionsWML#.5Bmodify_turns.5D|modify_turns]],<br />
[[DirectActionsWML#.5Bmodify_unit.5D|modify_unit]],<br />
[[ReplayWML|move]],<br />
[[DirectActionsWML#.5Bmove_unit.5D|move_unit]],<br />
[[InterfaceActionsWML#.5Bmove_unit_fake.5D|move_unit_fake]],<br />
[[InterfaceActionsWML#.5Bmove_units_fake.5D|move_units_fake]],<br />
[[AnimationWML#movement|movement_anim]], <br />
[[UnitsWML#.5Bmovetype.5D|movement costs]],<br />
[[UnitsWML#.5Bmovetype.5D|movetype]],<br />
[[ScenarioWML|multiplayer]],<br />
[[EraWML|multiplayer_side]],<br />
[[MusicListWML#.5Bmusic.5D|music]];<br />
|-<br />
|''N:'' <br />
[[MapGeneratorWML|naming]], <br />
[[ConditionalActionsWML#Meta-Condition_Tags|not]], <br />
[[InterfaceActionsWML#.5Bobjectives.5D|note]], <br />
[[ThemeWML#.5Bstatus.5D|num_units]];<br />
|-<br />
|''O:'' <br />
[[DirectActionsWML#.5Bobject.5D|object]],<br />
[[InterfaceActionsWML#.5Bobjectives.5D|objective]],<br />
[[InterfaceActionsWML#.5Bobjectives.5D|objectives]],<br />
[[ThemeWML#.5Bstatus.5D|observers]],<br />
[[InterfaceActionsWML#.5Bopen_help.5D|open_help]],<br />
[[InterfaceActionsWML#.5Bmessage.5D|option]],<br />
[[OptionWML|options]],<br />
[[ConditionalActionsWML#Meta-Condition_Tags|or]];<br />
|-<br />
|''P:'' <br />
[[ThemeWML#.5Bpanel.5D|panel]], <br />
[[IntroWML|part]], <br />
[[AbilitiesWML#The_.5Bspecials.5D_tag|petrifies]], <br />
[[DirectActionsWML#.5Bpetrify.5D|petrify]], <br />
[[DirectActionsWML#.5Bplace_shroud.5D|place_shroud]], <br />
[[AbilitiesWML#The_.5Bspecials.5D_tag|plague]], <br />
[[AbilitiesWML#The_.5Bspecials.5D_tag|poison]], <br />
[[UnitTypeWML#Other_tags|portrait]], <br />
[[ThemeWML#.5Bstatus.5D|position]],<br />
[[AnimationWML#post_movement|post_movement_anim]], <br />
[[AnimationWML#pre_movement|pre_movement_anim]], <br />
[[FilterWML#Filtering_Weapons|primary_attack]], <br />
[[StandardUnitFilter|primary_unit]], <br />
[[InterfaceActionsWML#.5Bprint.5D|print]], <br />
[[AiWML#Deprecated_AI_Targeting_Aspects|protect_location]], <br />
[[AiWML#Deprecated_AI_Targeting_Aspects|protect_unit]];<br />
|-<br />
|''R:'' <br />
[[UnitsWML#.5Brace.5D|race]], <br />
[[ReplayWML|random]], <br />
recall&nbsp;([[DirectActionsWML#.5Brecall.5D|action]], [[ReplayWML|replay]]), <br />
[[StatisticalScenarioWML|recalls]],<br />
[[ReplayWML|recruit]], <br />
[[AnimationWML#recruited|recruit_anim]], <br />
[[AnimationWML#recruiting|recruiting_anim]], <br />
[[StatisticalScenarioWML|recruits]], <br />
[[InterfaceActionsWML#.5Bredraw.5D|redraw]],<br />
[[AbilitiesWML|regenerate]], <br />
[[InterfaceActionsWML#.5Bremove_item.5D|remove_item]], <br />
[[DirectActionsWML#.5Bremove_shroud.5D|remove_shroud]], <br />
[[InterfaceActionsWML#.5Bremove_sound_source.5D|remove_sound_source]], <br />
[[InterfaceActionsWML#.5Bremove_unit_overlay.5D|remove_unit_overlay]],<br />
[[DirectActionsWML#.5Breplace_map.5D|replace_map]], <br />
[[DirectActionsWML#.5Breplace_schedule.5D|replace_schedule]], <br />
[[ReplayWML|replay]], <br />
[[SavefileWML|replay_start]],<br />
[[DirectActionsWML#.5Breset_fog.5D|reset_fog]], <br />
resistance&nbsp;([[AbilitiesWML|ability]], [[UnitsWML#.5Bmovetype.5D|unit]]),<br />
[[ThemeWML|resolution]], <br />
[[ReplayWML|results]], <br />
[[MapGeneratorWML|road_cost]], <br />
[[InternalActionsWML#.5Brole.5D|role]], <br />
[[TerrainMaskWML|rule]];<br />
|-<br />
|''S:'' <br />
[[SavefileWML|save]], <br />
[[ScenarioWML|scenario]],<br />
[[InterfaceActionsWML#.5Bscroll.5D|scroll]], <br />
[[InterfaceActionsWML#.5Bscroll_to.5D|scroll_to]],<br />
[[InterfaceActionsWML#.5Bscroll_to_unit.5D|scroll_to_unit]], <br />
[[FilterWML#Filtering_Weapons|secondary_attack]], <br />
[[StandardUnitFilter|secondary_unit]], <br />
[[HelpWML|section]], <br />
[[InterfaceActionsWML#.5Bselect_unit.5D|select_unit]], <br />
[[ReplayWML|sequence]], <br />
[[DirectActionsWML#.5Bset_extra_recruit.5D|set_extra_recruit]],<br />
[[PersistenceWML|set_global_variable]],<br />
[[InterfaceActionsWML#.5Bset_menu_item.5D|set_menu_item]], <br />
[[DirectActionsWML#.5Bset_recruit.5D|set_recruit]],<br />
[[EffectWML|set_specials]], <br />
[[InternalActionsWML#.5Bset_variable.5D|set_variable]], <br />
[[InternalActionsWML#.5Bset_variables.5D|set_variables]], <br />
[[MapGeneratorWML#The_Cave_Generator|settings]], <br />
[[AnimationWML#sheath_weapon|sheath_weapon_anim]], <br />
show_if&nbsp;([[InterfaceActionsWML#.5Bmessage.5D|message]], [[InterfaceActionsWML#.5Bset_menu_item.5D|set_menu_item]]),<br />
[[InterfaceActionsWML#.5Bshow_objectives.5D|show_objectives]],<br />
[[SideWML|side]], <br />
[[ThemeWML|side_playing]], <br />
[[AbilitiesWML|skirmisher]], <br />
[[AbilitiesWML#The_.5Bspecials.5D_tag|slow]], <br />
[[SavefileWML|snapshot]],<br />
[[InterfaceActionsWML#.5Bsound.5D|sound]], <br />
[[InterfaceActionsWML#.5Bsound_source.5D|sound_source]], <br />
source&nbsp;([[ReplayWML|replay]], [[DirectActionsWML#.5Btunnel.5D|teleport]]),<br />
[[AbilitiesWML#The_.5Bspecials.5D_tag|specials]], <br />
[[InternalActionsWML#.5Bset_variables.5D|split]],<br />
[[Customizing_AI_in_Wesnoth_1.8#Working_with_main_loop_of_the_RCA_AI|stage]], <br />
[[AnimationWML#standing|standing_anim]], <br />
[[StatisticalScenarioWML#The_.5Bstatistics.5D_tag|statistics]],<br />
status&nbsp;([[SingleUnitWML|single unit]], [[ThemeWML|theme]]), <br />
[[InternalActionsWML#.5Bstore_gold.5D|store_gold]], <br />
[[InternalActionsWML#.5Bstore_items.5D|store_items]], <br />
[[InternalActionsWML#.5Bstore_locations.5D|store_locations]],<br />
[[InternalActionsWML#.5Bstore_map_dimensions.5D|store_map_dimensions]],<br />
[[InternalActionsWML#.5Bstore_reachable_locations.5D|store_reachable_locations]],<br />
[[InternalActionsWML#.5Bstore_side.5D|store_side]], <br />
[[InternalActionsWML#.5Bstore_starting_location.5D|store_starting_location]], <br />
[[InternalActionsWML#.5Bstore_time_of_day.5D|store_time_of_day]], <br />
[[InternalActionsWML#.5Bstore_turns.5D|store_turns]], <br />
[[InternalActionsWML#.5Bstore_unit.5D|store_unit]], <br />
[[InternalActionsWML#.5Bstore_unit_type.5D|store_unit_type]], <br />
[[InternalActionsWML#.5Bstore_unit_type_ids.5D|store_unit_type_ids]], <br />
[[InternalActionsWML#.5Bstore_villages.5D|store_villages]], <br />
[[IntroWML|story]], <br />
[[AbilitiesWML#The_.5Bspecials.5D_tag|swarm]], <br />
[[ConditionalActionsWML#.5Bswitch.5D|switch]];<br />
|-<br />
|''T:'' <br />
[[DirectActionsWML#.5Btunnel.5D|target]], <br />
[[StatisticalScenarioWML#The_.5Bteam.5D_tag|team]],<br />
teleport&nbsp;([[AbilitiesWML|ability]], [[DirectActionsWML#.5Bteleport.5D|action]]),<br />
[[AnimationWML#pre_teleport|teleport_anim]],<br />
[[DirectActionsWML#.5Bterrain.5D|terrain]], <br />
[[TerrainGraphicsWML|terrain_graphics]], <br />
[[TerrainMaskWML|terrain_mask]], <br />
[[TerrainWML|terrain_type]], <br />
[[ScenarioWML#Test_scenario|test]],<br />
[[InterfaceActionsWML#.5Bmessage.5D|text_input]], <br />
[[WesCamp#The_textdomain_declaration|textdomain]],<br />
[[ThemeWML|theme]], <br />
[[ConditionalActionsWML#.5Bif.5D|then]],<br />
[[TerrainGraphicsWML|tile]], <br />
[[TimeWML|time]], <br />
[[DirectActionsWML#.5Btime_area.5D|time_area]], <br />
[[ThemeWML#.5Bstatus.5D|time_of_day]],<br />
[[HelpWML|topic]], <br />
[[HelpWML|toplevel]], <br />
[[UnitsWML#.5Btrait.5D|trait]], <br />
[[DirectActionsWML#.5Btransform_unit.5D|transform_unit]], <br />
[[InternalActionsWML#.5Bfind_path.5D|traveler]], <br />
[[DirectActionsWML#.5Btunnel.5D|tunnel]], <br />
[[ThemeWML#.5Bstatus.5D|turn]], <br />
[[ScenarioWML|tutorial]];<br />
|-<br />
|''U:'' <br />
[[InterfaceActionsWML#.5Bunhide_unit.5D|unhide_unit]], <br />
[[SingleUnitWML|unit]],<br />
[[ThemeWML#.5Bstatus.5D|unit_abilities]], <br />
[[ThemeWML#.5Bstatus.5D|unit_alignment]], <br />
[[ThemeWML#.5Bstatus.5D|unit_description]], <br />
[[ThemeWML#.5Bstatus.5D|unit_hp]], <br />
[[ThemeWML#.5Bstatus.5D|unit_image]], <br />
[[ThemeWML#.5Bstatus.5D|unit_level]], <br />
[[ThemeWML#.5Bstatus.5D|unit_moves]],<br />
[[InterfaceActionsWML#.5Bunit_overlay.5D|unit_overlay]], <br />
[[ThemeWML#.5Bstatus.5D|unit_profile]], <br />
[[ThemeWML#.5Bstatus.5D|unit_status]],<br />
[[ThemeWML#.5Bstatus.5D|unit_traits]], <br />
[[UnitTypeWML|unit_type]], <br />
[[ThemeWML#.5Bstatus.5D|unit_weapons]],<br />
[[InternalActionsWML|unit_worth]], <br />
[[ThemeWML#.5Bstatus.5D|unit_xp]],<br />
[[UnitsWML|units]],<br />
[[InterfaceActionsWML#.5Bunlock_view.5D|unlock_view]],<br />
[[DirectActionsWML#.5Bunpetrify.5D|unpetrify]], <br />
[[DirectActionsWML#.5Bunstore_unit.5D|unstore_unit]], <br />
[[ThemeWML#.5Bstatus.5D|upkeep]];<br />
|-<br />
| ''V:'' <br />
[[InternalActionsWML#.5Bset_variables.5D|value]], <br />
[[ConditionalActionsWML#Condition_Tags|variable]],<br />
[[VariablesWML#The_.5Bvariables.5D_tag|variables]],<br />
[[UnitTypeWML#Other_tags|variation]], <br />
[[AnimationWML#victory|victory_anim]], <br />
[[SideWML|village]],<br />
[[MapGeneratorWML|village_naming]], <br />
[[ThemeWML#.5Bstatus.5D|villages]],<br />
[[InterfaceActionsWML#.5Bvolume.5D|volume]];<br />
|-<br />
| ''W:'' <br />
[[ConditionalActionsWML#.5Bwhile.5D|while]],<br />
[[InterfaceActionsWML#.5Bwml_message.5D|wml_message]];<br />
|}<br />
<br />
<includeonly>[[Category:WML Reference]]</includeonly><br />
<br />
<noinclude>A box with all the WML tags, each one linking to the page and section they are described in. This box should be included in each of the WML reference pages.</noinclude></div>Fabihttps://wiki.wesnoth.org/index.php?title=EditorWML&diff=52692EditorWML2013-12-31T10:40:32Z<p>Fabi: </p>
<hr />
<div>{{WML Tags}}<br />
E<br />
<br />
Editor2, the new map editor in Wesnoth 1.5, has some adjustable behaviour that can de configured by the following WML. Note that this has very little to do with the "old", 1.4-era editor shipped as a separate executable.<br />
<br />
== The [brush] tag ==<br />
Each brush tag defines one brush. (0,0) is the hotspot, that is, the brush is always moved so the mouse is over the brush's (0,0) coordinate. The following keys and tags are recognized:<br />
* '''name''': name for the brush (will possibly show up in the tooltip for the brush)<br />
* '''image''': icon for the brush to de displayed on the toolbar<br />
* '''radius''': (int) include in the brushall hexes that are this or closer to the center of the brush, excluding the (0,0) point<br />
* '''[relative]''': include in the brush a single hex with coordinates relative from the center of the brush<br />
** '''x''': the relative x coordinate<br />
** '''y''': the relative y coordinate<br />
A brush that has neither a radius nor any [relative] hexes will be empty which is not desired and a warning or error is to be expected.<br />
<br />
==The [editor_times] tag==<br />
The editor_times tag defines a schedule (time-of-day) for the editor. Standard time of day macros can be used.<br />
* '''[[TimeWML|[time]]]''' Time of day definitions<br />
* '''id''': The identifier of the time schedule<br />
* '''name''': The translatable name of the schedule<br />
<br />
==The [editor_music] tag==<br />
This tag defines a music playlist for the editor. Standard music macros can be used here.<br />
* '''[[InterfaceActionsWML|[music]]]''': Playlist item definitions<br />
<br />
==The [editor_group] tag ==<br />
The editor_group tag defines a group of terrains displayed together on the terrain palette. Terrains must use a editor_group attribute from the list of ids specified in the editor_group tags. Custom terrains should be put in their own separate groups.<br />
* '''id''': the unique id of this group. Duplicates are ignored.<br />
* '''name''': a name for the group<br />
* '''icon''': an icon for the group<br />
* '''core''': whether this group is a "core" group. Non-core (UMC) groups are treated slightly differently by the editor -- a warning may be given to map authors, since maps using non-core terrains need special treatment in the scenario file to work properly. UMC groups should not define this attribute.<br />
<br />
[[Category: WML Reference]]</div>Fabihttps://wiki.wesnoth.org/index.php?title=ScenarioWML&diff=52513ScenarioWML2013-11-26T04:20:41Z<p>Fabi: /* The [scenario] tag */</p>
<hr />
<div>{{WML Tags}}<br />
== the toplevel tags [multiplayer], [test], [tutorial], [scenario] ==<br />
<br />
The top level tags '''[multiplayer]''', '''[test]''', '''[tutorial]''' and '''[scenario]''' are all formatted the same way.<br />
The difference between these tags is the way that the scenarios they describe are accessed.<br />
<br />
The keys '''id''' and '''next_scenario''' affect how scenarios can be accessed.<br />
Whenever a scenario is won, the scenario with id=''next_scenario'' of the same tag type will be played.<br />
Units from the first scenario will be available for recall in the second.<br />
<br />
Some scenarios can be played without playing other scenarios first<br />
(in this case there is nothing on the recall list).<br />
These scenarios are called ''initial scenario''s.<br />
<br />
A list of initial scenarios, and how to access them:<br />
<br />
* All '''[multiplayer]''' scenarios (without ''allow_new_game=no'') are initial scenarios listed in the multiplayer scenario selector screen (accessed by the "multiplayer" button).<br />
<br />
* The '''[test]''' scenario with the attribute '''id=test''' is an initial scenario. This test scenario can be accessed by running the game in test mode. (note: this is NOT the same as debug mode. It can be accessed using -t or --test)<br />
<br />
* The '''[tutorial]''' scenario with the attribute '''id=tutorial''' is an initial scenario. The tutorial is accessed by clicking on the "tutorial" button.<br />
<br />
* Any '''[scenario]''' scenario with an id listed in the value of ''first_scenario'' in a campaign tag (see [[CampaignWML]]) is an initial scenario accessed by selecting that campaign after clicking on the "campaign" button.<br />
<br />
== The [scenario] tag ==<br />
<br />
The following keys and tags are recognized in '''[scenario]''' tags:<br />
<br />
* '''id''': A unique identifier for this scenario. All scenarios must have an id. Can't clash with '''id''' used in '''[multiplayer]''' tags.<br />
<br />
* '''next_scenario''': The id of the scenario to load when the current one is won. This can be changed dynamically, to build non-linear campaigns.<br />
<br />
* '''description''': (translatable) only for multiplayer maps. Will show up as a tooltip when mousing over the minimap in the multiplayer setup screen.<br />
<br />
* '''name''': (translatable) is shown in several places in the level, including the intro screen. It is also the default name for saves on the level.<br />
<br />
* '''map_data''': inputs valid Wesnoth map data. See [[BuildingMaps]] for a description of the Wesnoth map syntax.<br />
<br />
* '''turns''': sets an event on turn ''turns'' causing the player to lose. Use ''-1'' to have no turn limit (default). See also [[EventWML]]<br />
<br />
* '''turn_at''': the turn to start on (default=1)<br />
<br />
: Note that none of the regular start-of-turn behavior, including poison damage, healing, income and refreshing unit movement and status, will occur before the start of turn 2. All start-of-turn [[EventWML|WML events]] will still be fired, however.<br />
<br />
* '''random_start_time''': controls random starting time of day. Possible values are yes and no or list of possible start times; starting from 1 to number of times. for example ''random_start_time=2,3,5,6'' (default=no)<br />
<br />
* '''music''': the music file relative to ''./music/'' to play during the scenario<br />
<br />
* '''[music]''': specifies the music tracks to play during this scenario, see [[MusicListWML]].<br />
<br />
* '''defeat_music''': specifies a comma-separated list of music tracks which may be chosen to play on defeat. If not provided, the default in [[GameConfigWML]] is used instead. May be overridden by [[DirectActionsWML|endlevel]] clauses.<br />
<br />
* '''victory_music''': specifies a comma-separated list of music tracks which may be chosen to play on victory. If not provided, the default in [[GameConfigWML]] is used instead. May be overridden by [[DirectActionsWML|endlevel]] clauses.<br />
<br />
* '''theme''': the name of the UI theme that should be used when playing this scenario.<br />
<br />
* '''victory_when_enemies_defeated''': when this is set to '''yes''' (default), the player wins once all non-allied units with '''canrecruit=yes''' (aka leaders) are killed. (Currently this only controls the win condition for when all enemies are defeated; it does not prevent the player from losing if he has no leader.) When this value is true the following keys can be used:<br />
** '''carryover_percentage''': by default 80% of the gold is carried over to the next scenario, with this key the amount can be changed.<br />
** '''carryover_add''': if true the gold will be added to the starting gold the next scenario, if false the next scenario will start with the amount of the current scenario (after taxes) or the minimum in the next scenario. Default is false.<br />
* '''remove_from_carryover_on_leaders_loss''': {{DevFeature1.11}} when this is set to '''yes''' (default), for sides who lost all their leaders, carryover will be removed.<br />
<br />
* '''disallow_recall''': when this is set to 'no'(default), the player is allowed to recall units from previous scenarios.<br />
<br />
* '''experience_modifier''': the percentage that required XP to level up (for all units in the scenario) is multiplied by. Default 100. Note that when used in a campaign, weird things (like units being above the required XP to level up) can happen if this value is different for different scenarios.<br />
<br />
* '''[story]''': describes the intro screen. See [[IntroWML]]<br />
<br />
* '''[label]''': sets a label<br />
** '''x''', '''y''': location to set label<br />
** '''text''': the label<br />
<br />
* '''[time]''': how a day should progress. See [[TimeWML]]<br />
* '''current_tod''': The time of day slot number (starting from zero) active at scenario start.<br />
<br />
* '''[time_area]''': how a day should progress in a given area. Everywhere not specified in a [time_area] tag is affected by the [time] tags in the [scenario] tag<br />
** takes x and y coordinates.<br />
** '''[time]''': how a day should progress in those locations. See [[TimeWML]]<br />
** '''current_time''': The time slot number (starting with zero) active at the creation of the area.{{DevFeature1.11}}<br />
** time areas can be used in events, assigned identifiers, and removed at discretion. They also accept complete Standard Location Filters. See [[DirectActionsWML]].<br />
<br />
* '''[side]''': describes one player. See [[SideWML]]<br />
<br />
* '''[event]''': describes an event that may be triggered at a certain point of the scenario. See [[EventWML]]<br />
<br />
* '''map_generation''': another way to generate a map. The map will be generated randomly<br />
** '''default''': the default random map generator<br />
<br />
* '''[generator]''' if this is present, the map and scenario will be generated randomly. See [[MapGeneratorWML]]<br />
<br />
The following keys and subtags are additionally recognized in '''[multiplayer]''' scenarios:<br />
* '''force_lock_settings''': {{DevFeature1.11}} provides a default value for [[SideWML]] ''lock'' attributes and forces the "Use map settings" to be checked and disabled.<br />
* '''new_game_title''': {{DevFeature1.11}} if provided will be used instead of '''name''' for campaign entry points.<br />
* '''allow_new_game''': (default=yes) allow/prevent the scenario to be listed in the game configuration screen. This is intended for multiplayer campaigns with multiple entry points.<br />
* '''allow_era''': {{DevFeature1.11}} a list of era ids. Only the eras with matching ids will be allowed to be played with this scenario.<br />
* '''disallow_era''': {{DevFeature1.11}} a list of era ids. Only the eras with matching ids will not be allowed to be played with this scenario. Cannot be used in parallel with allow_era.<br />
* '''ignore_incompatible_era''': {{DevFeature1.11}} a list of era ids. The eras with matching ids will be considered compatible with this scenario regardless their dependencies.<br />
* '''allow_modification''': {{DevFeature1.11}} same as allow_era, but for modifications.<br />
* '''disallow_modification''': {{DevFeature1.11}} same as disallow_era, but for modifications. Cannot be used in parallel with allow_modification.<br />
* '''ignore_incompatible_modification''': {{DevFeature1.11}} same as ignore_incompatible_era, but for modifications.<br />
* '''force_modification''': {{DevFeature1.11}} a list of modification ids. The specified modifications must be enabled to play this scenario.<br />
* '''[options]''': {{DevFeature1.11}} custom options. See [[OptionWML]] for details.<br />
<br />
== See Also ==<br />
<br />
* [[EventWML]]<br />
* [[ReferenceWML]]<br />
<br />
<br />
[[Category: WML Reference]]</div>Fabihttps://wiki.wesnoth.org/index.php?title=ScenarioWML&diff=52512ScenarioWML2013-11-26T04:14:55Z<p>Fabi: /* The [scenario] tag */</p>
<hr />
<div>{{WML Tags}}<br />
== the toplevel tags [multiplayer], [test], [tutorial], [scenario] ==<br />
<br />
The top level tags '''[multiplayer]''', '''[test]''', '''[tutorial]''' and '''[scenario]''' are all formatted the same way.<br />
The difference between these tags is the way that the scenarios they describe are accessed.<br />
<br />
The keys '''id''' and '''next_scenario''' affect how scenarios can be accessed.<br />
Whenever a scenario is won, the scenario with id=''next_scenario'' of the same tag type will be played.<br />
Units from the first scenario will be available for recall in the second.<br />
<br />
Some scenarios can be played without playing other scenarios first<br />
(in this case there is nothing on the recall list).<br />
These scenarios are called ''initial scenario''s.<br />
<br />
A list of initial scenarios, and how to access them:<br />
<br />
* All '''[multiplayer]''' scenarios (without ''allow_new_game=no'') are initial scenarios listed in the multiplayer scenario selector screen (accessed by the "multiplayer" button).<br />
<br />
* The '''[test]''' scenario with the attribute '''id=test''' is an initial scenario. This test scenario can be accessed by running the game in test mode. (note: this is NOT the same as debug mode. It can be accessed using -t or --test)<br />
<br />
* The '''[tutorial]''' scenario with the attribute '''id=tutorial''' is an initial scenario. The tutorial is accessed by clicking on the "tutorial" button.<br />
<br />
* Any '''[scenario]''' scenario with an id listed in the value of ''first_scenario'' in a campaign tag (see [[CampaignWML]]) is an initial scenario accessed by selecting that campaign after clicking on the "campaign" button.<br />
<br />
== The [scenario] tag ==<br />
<br />
The following keys and tags are recognized in '''[scenario]''' tags:<br />
<br />
* '''id''': A unique identifier for this scenario. All scenarios must have an id. Can't clash with '''id''' used in '''[multiplayer]''' tags.<br />
<br />
* '''next_scenario''': The id of the scenario to load when the current one is won. This can be changed dynamically, to build non-linear campaigns.<br />
<br />
* '''description''': (translatable) only for multiplayer maps. Will show up as a tooltip when mousing over the minimap in the multiplayer setup screen.<br />
<br />
* '''name''': (translatable) is shown in several places in the level, including the intro screen. It is also the default name for saves on the level.<br />
<br />
* '''map_data''': inputs valid Wesnoth map data. See [[BuildingMaps]] for a description of the Wesnoth map syntax.<br />
<br />
* '''turns''': sets an event on turn ''turns'' causing the player to lose. Use ''-1'' to have no turn limit (default). See also [[EventWML]]<br />
<br />
* '''turn_at''': the turn to start on (default=1)<br />
<br />
: Note that none of the regular start-of-turn behavior, including poison damage, healing, income and refreshing unit movement and status, will occur before the start of turn 2. All start-of-turn [[EventWML|WML events]] will still be fired, however.<br />
<br />
* '''random_start_time''': controls random starting time of day. Possible values are yes and no or list of possible start times; starting from 1 to number of times. for example ''random_start_time=2,3,5,6'' (default=no)<br />
<br />
* '''music''': the music file relative to ''./music/'' to play during the scenario<br />
<br />
* '''[music]''': specifies the music tracks to play during this scenario, see [[MusicListWML]].<br />
<br />
* '''defeat_music''': specifies a comma-separated list of music tracks which may be chosen to play on defeat. If not provided, the default in [[GameConfigWML]] is used instead. May be overridden by [[DirectActionsWML|endlevel]] clauses.<br />
<br />
* '''victory_music''': specifies a comma-separated list of music tracks which may be chosen to play on victory. If not provided, the default in [[GameConfigWML]] is used instead. May be overridden by [[DirectActionsWML|endlevel]] clauses.<br />
<br />
* '''theme''': the name of the UI theme that should be used when playing this scenario.<br />
<br />
* '''victory_when_enemies_defeated''': when this is set to '''yes''' (default), the player wins once all non-allied units with '''canrecruit=yes''' (aka leaders) are killed. (Currently this only controls the win condition for when all enemies are defeated; it does not prevent the player from losing if he has no leader.) When this value is true the following keys can be used:<br />
** '''carryover_percentage''': by default 80% of the gold is carried over to the next scenario, with this key the amount can be changed.<br />
** '''carryover_add''': if true the gold will be added to the starting gold the next scenario, if false the next scenario will start with the amount of the current scenario (after taxes) or the minimum in the next scenario. Default is false.<br />
* '''remove_from_carryover_on_leaders_loss''': {{DevFeature1.11}} when this is set to '''yes''' (default), for sides who lost all their leaders, carryover will be removed.<br />
<br />
* '''disallow_recall''': when this is set to 'no'(default), the player is allowed to recall units from previous scenarios.<br />
<br />
* '''experience_modifier''': the percentage that required XP to level up (for all units in the scenario) is multiplied by. Default 100. Note that when used in a campaign, weird things (like units being above the required XP to level up) can happen if this value is different for different scenarios.<br />
<br />
* '''[story]''': describes the intro screen. See [[IntroWML]]<br />
<br />
* '''[label]''': sets a label<br />
** '''x''', '''y''': location to set label<br />
** '''text''': the label<br />
<br />
* '''[time]''': how a day should progress. See [[TimeWML]]<br />
* '''current_tod''': The time of day slot number (starting from zero) active at scenario start.<br />
<br />
* '''[time_area]''': how a day should progress in a given area. Everywhere not specified in a [time_area] tag is affected by the [time] tags in the [scenario] tag<br />
** takes x and y coordinates.<br />
** '''[time]''': how a day should progress in those locations. See [[TimeWML]]<br />
** time areas can be used in events, assigned identifiers, and removed at discretion. They also accept complete Standard Location Filters. See [[DirectActionsWML]].<br />
<br />
* '''[side]''': describes one player. See [[SideWML]]<br />
<br />
* '''[event]''': describes an event that may be triggered at a certain point of the scenario. See [[EventWML]]<br />
<br />
* '''map_generation''': another way to generate a map. The map will be generated randomly<br />
** '''default''': the default random map generator<br />
<br />
* '''[generator]''' if this is present, the map and scenario will be generated randomly. See [[MapGeneratorWML]]<br />
<br />
The following keys and subtags are additionally recognized in '''[multiplayer]''' scenarios:<br />
* '''force_lock_settings''': {{DevFeature1.11}} provides a default value for [[SideWML]] ''lock'' attributes and forces the "Use map settings" to be checked and disabled.<br />
* '''new_game_title''': {{DevFeature1.11}} if provided will be used instead of '''name''' for campaign entry points.<br />
* '''allow_new_game''': (default=yes) allow/prevent the scenario to be listed in the game configuration screen. This is intended for multiplayer campaigns with multiple entry points.<br />
* '''allow_era''': {{DevFeature1.11}} a list of era ids. Only the eras with matching ids will be allowed to be played with this scenario.<br />
* '''disallow_era''': {{DevFeature1.11}} a list of era ids. Only the eras with matching ids will not be allowed to be played with this scenario. Cannot be used in parallel with allow_era.<br />
* '''ignore_incompatible_era''': {{DevFeature1.11}} a list of era ids. The eras with matching ids will be considered compatible with this scenario regardless their dependencies.<br />
* '''allow_modification''': {{DevFeature1.11}} same as allow_era, but for modifications.<br />
* '''disallow_modification''': {{DevFeature1.11}} same as disallow_era, but for modifications. Cannot be used in parallel with allow_modification.<br />
* '''ignore_incompatible_modification''': {{DevFeature1.11}} same as ignore_incompatible_era, but for modifications.<br />
* '''force_modification''': {{DevFeature1.11}} a list of modification ids. The specified modifications must be enabled to play this scenario.<br />
* '''[options]''': {{DevFeature1.11}} custom options. See [[OptionWML]] for details.<br />
<br />
== See Also ==<br />
<br />
* [[EventWML]]<br />
* [[ReferenceWML]]<br />
<br />
<br />
[[Category: WML Reference]]</div>Fabihttps://wiki.wesnoth.org/index.php?title=DirectActionsWML&diff=52511DirectActionsWML2013-11-26T04:11:07Z<p>Fabi: /* [time_area] */</p>
<hr />
<div>{{WML Tags}}<br />
== Direct actions ==<br />
<br />
Direct actions are actions that have a direct effect on gameplay. They can be used inside of [[EventWML|events]].<br />
<br />
The following tags are actions:<br />
<br />
=== [endlevel] ===<br />
Ends the scenario.<br />
* '''result''': before the scenario is over, all events with ''name=result'' are triggered. If ''result=victory'', the player progresses to the next level (i.e., the next scenario in single player); if ''result=defeat'', the game returns to the main menu. <br />
<br />
When the result is "victory" the following keys can be used:<br />
* '''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.<br />
* '''carryover_report''': whether the player should receive a summary of the scenario outcome, the default is carryover_report=yes.<br />
* '''save''': whether a start-of-scenario save should be created for the next scenario, the default is save=yes. Do not confuse this with saving of replays for the current scenario.<br />
* '''replay_save''': whether a replay save for the current scenario is allowed, the default is replay_save=yes. If yes, the player's settings in preferences will be used to determine if a replay is saved. If no, will override and not save a replay.<br />
* '''linger_mode''': If ...=yes, the screen is greyed out and there's the possibility to save before advancing to the next scenario, the default is linger_mode=yes.<br />
* '''reveal_map''': (Multiplayer only) (Default is 'yes') If 'no', shroud doesn't disappear when game ended.<br />
* '''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''.<br />
* '''carryover_percentage''': by default 80% of the gold is carried over to the next scenario, with this key the amount can be changed.<br />
* '''carryover_add''': if true the gold will be added to the starting gold the next scenario, if false the next scenario will start with the amount of the current scenario (after taxes) or the minimum in the next scenario. Default is false.<br />
* '''music''': (default specified in '''[scenario]''' or '''[game_config]''' tags) a comma-separated list of music tracks from which one will be chosen and played once after any events related to the end of level result are executed; by default, victory_music is used on victory, and defeat_music on defeat.<br />
* '''end_credits''': {{DevFeature1.11}} Whether to display the credits screen at the end of a single-player campaign. Defaults to ''yes''. Note that this has cumulative effects over the campaign - it persists even if the endlevel does not trigger the end of the campaign. See also [[CampaignWML]].<br />
* '''end_text''': (translatable) Text that is shown centered in a black screen at the end of a campaign. Defaults to "The End". Note that this has cumulative effects over the campaign - it persists even if the endlevel does not trigger the end of the campaign. See also [[CampaignWML]].<br />
* '''end_text_duration''': Delay, in milliseconds, before displaying the game credits at the end of a campaign. In other words, for how much time '''end_text''' is displayed on screen. Defaults to 3500. Note that this has cumulative effects over the campaign - it persists even if the endlevel does not trigger the end of the campaign. See also [[CampaignWML]].<br />
<br />
=== [unit] ===<br />
Places a unit on the map. For syntax see [[SingleUnitWML]].<br />
* {{Short Note:Predefined Macro|GENERIC_UNIT}}<br />
* '''to_variable''': spawn directly into a variable instead of on the map.<br />
<br />
=== [recall] ===<br />
Recalls a unit taking into account any [http://wiki.wesnoth.org/SingleUnitWML filter_recall] of the leader. The unit is recalled free of charge, and is placed near its leader, e.g., if multiple leaders are present, near the first found which would be able to normally recall it.<br />
<br />
If neither a valid map location is provided nor a leader on the map would be able to recall it, the tag is ignored.<br />
<br />
* [[StandardUnitFilter]]: the first matching unit will be recalled. If no units match this tag is ignored. Do not use a [filter] tag. If a comma separated list is given, every unit currently considered for recall is checked against all the types (not each single one of the types against all units).<br />
* '''x,y''': the unit is placed here instead of next to the leader.<br />
* '''show''': yes/no, default yes: whether the unit is animated (faded in) or instantly displayed<br />
* '''fire_event''': boolean yes|no (default no); whether any according prerecall or recall events shall be fired.<br />
* '''check_passability''': (boolean yes|no, default yes): If yes, checks for terrain passability when placing the unit (a nearby passable hex is chosen).<br />
<br />
=== [teleport] ===<br />
Teleports a unit on map. {{Short Note:Predefined Macro|TELEPORT_UNIT}}<br />
* '''[filter]''': [[StandardUnitFilter]] the first unit matching this filter will be teleported.<br />
* '''x,y''': the position to teleport to.<br />
* '''clear_shroud''': should shroud be cleared on arrival<br />
* '''animate''': should a teleport animation be played (if the unit doesn't have a teleport animation, it will fade out/fade in)<br />
* '''check_passability''': (boolean yes|no, default yes): normally, units will not be teleported into terrain that is impassable for them. Setting this attribute to "no" permits it.<br />
<br />
(Note: There is also a ability named teleport, see [[AbilitiesWML]].)<br />
<br />
=== [terrain_mask] ===<br />
Changes the terrain on the map. See [[TerrainMaskWML]].<br />
<br />
=== [terrain] ===<br />
Changes the terrain on the map.<br />
* '''terrain''': the character of the terrain to use. See [[TerrainCodesWML]] to see what letter a type of terrain uses.<br />
* [[StandardLocationFilter]]. This [[StandardLocationFilter]]'s terrain= key is used for the new terrain, filtering by terrain can be done with a nested [[StandardLocationFilter]]: [and]terrain=terrain_string_to_be_filtered_for.<br />
* '''layer''': (overlay|base|both, default=both) only change the specified layer.<br />
* '''replace_if_failed''': (default=no) When replacing just one layer failed, try to replace the whole terrain. If '''terrain''' is an overlay only terrain, use the default_base as base layer. If the terrain has no default base, do nothing.<br />
Note: When a hex changes from a village terrain to a non-village terrain, and a team owned that village it loses that village. When a hex changes from a non-village terrain to a village terrain and there is a unit on that hex it does not automatically capture the village. The reason for not capturing villages it that there are too many choices to make; should a unit loose its movement points, should capture events be fired. It is easier to do this as wanted by the author in WML.<br />
<br />
=== [gold] ===<br />
Gives sides gold.<br />
* '''amount''': the amount of gold to give.<br />
* '''side''': (default=1) the number of the side to give the gold to. Can be a comma-separated list of sides. note: Default side=1 for empty side= is deprecated.<br />
* [[StandardSideFilter]] {{DevFeature1.11}} tags and keys; default for empty side= is all sides, as usual in a SSF.<br />
* '''[filter_side]''' with a [[StandardSideFilter]] as argument {{DevFeature1.11}}: [gold][filter_side] is deprecated, use the new inline SSF.<br />
<br />
=== [unstore_unit] ===<br />
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 [[InternalActionsWML#.5Bstore_unit.5D|[store_unit]]], [[ConditionalActionsWML#.5Bwhile.5D|[while]]] and [[InternalActionsWML#.5Bclear_variable.5D|[clear_variable]]].<br />
* '''variable''': the name of the variable.<br />
* '''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. <br />
* '''check_passability''': (boolean yes|no, default yes): If yes, checks for terrain passability when placing the unit. This key has no effect if find_vacant=no (no check performed then). Before 1.9 this key is always "no".<br />
* '''text''': (translatable) floating text to display above the unit, such as a damage amount<br />
* '''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.)<br />
* '''advance''': (default=true) if true the unit is advanced if it has enough XP. When modifying XP make sure to do it from inside a [[EventWML#Multiplayer_safety|synchronized event]] or it may lead to OOS errors especially when several advancement paths exist. Note that advance and post advance events are called, so infinite loops can happen.<br />
* '''fire_event''': (boolean yes|no, default no) Whether any advance/post advance events shall be fired if an advancement takes place, no effect otherwise.<br />
* '''animate''': {{DevFeature1.11}} (boolean yes|no, default yes) Whether "levelout" and "levelin" (or fade to white and back) animations shall be played if an advancement takes place, no effect otherwise.<br />
* '''x''' ,'''y''': override unit location, "x,y=recall,recall" will put the unit on the unit's side's recall list.<br />
Units can be unstored with negative (or zero) hit points. This can be useful if modifying a unit in its last_breath event (as the unit's death is already the next step), but tends to look wrong in other cases. In particular, it is possible to have units with negative hit points in play. Such units are aberrations, subject to unusual behavior as the game compensates for them. (For example, such units are currently automatically hit&ndash;and killed&ndash;in combat.) The details of the unusual behavior are subject to change between stable releases without warning.<br />
<br />
=== [allow_recruit] ===<br />
Allows a side to recruit units it couldn't previously recruit.<br />
* '''type''': the types of units that the side can now recruit.<br />
* '''side''': (default=1) the number of the side that is being allowed to recruit the units. This can be a comma-separated list note: Default side=1 for empty side= is deprecated.<br />
* [[StandardSideFilter]] {{DevFeature1.11}} tags and keys; default for empty side= is all sides, as usual in a SSF.<br />
<br />
=== [allow_extra_recruit] ===<br />
Allows a leader to recruit units it couldn't previously recruit.<br />
These types add to the types the leader can recruit because of [side]recruit=.<br />
* '''extra_recruit''': the types of units that the unit can now recruit.<br />
* '''[[StandardUnitFilter]]''': All units matching this filter are modified. Does not match on recall list units.<br />
<br />
=== [disallow_recruit] ===<br />
Prevents a side from recruiting units it could previously recruit.<br />
* '''type''': the types of units that the side can no longer recruit.<br />
* '''side''': (default=1) the number of the side that may no longer recruit the units. This can be a comma-separated list note: Default side=1 for empty side= is deprecated.<br />
* [[StandardSideFilter]] {{DevFeature1.11}} tags and keys; default for empty side= is all sides, as usual in a SSF.<br />
<br />
=== [disallow_extra_recruit] ===<br />
Prevents a leader from recruiting units it could previously recruit.<br />
* '''extra_recruit''': the types of units that the side can no longer recruit.<br />
* '''[[StandardUnitFilter]]''': All units matching this filter are modified. Does not match on recall list units.<br />
<br />
=== [set_recruit] ===<br />
Sets the units a side can recruit.<br />
* '''recruit''': the types of units that the side can now recruit.<br />
* '''side''': (default=1) the number of the side that is having its recruitment set. This can be a comma-separated list. note: Default side=1 for empty side= is deprecated.<br />
* [[StandardSideFilter]] {{DevFeature1.11}} tags and keys; default for empty side= is all sides, as usual in a SSF.<br />
<br />
=== [set_extra_recruit] === <br />
Sets the units a leader can recruit.<br />
* '''extra_recruit''': the types of units that the leader can now recruit.<br />
* '''[[StandardUnitFilter]]''': All units matching this filter are modified. Does not match on recall list units.<br />
<br />
=== [modify_side] ===<br />
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!'''<br />
* '''side''': (default=1) the number of the side that is to be changed. note: Default side=1 for empty side= is deprecated.<br />
* '''[filter_side]''' with a [[StandardSideFilter]] as argument<br />
* '''income''': the income given at the begining of each turn.<br />
* '''recruit''': a list of unit types, replacing the side's current recruitment list.<br />
* '''team_name''': the team in which the side plays the scenario.<br />
* '''user_team_name''': a translatable string representing the team's description. This has no effect on alliances. Defaults to ''team_name''.<br />
* '''gold''': the amount of gold the side owns.<br />
* '''village_gold''': the income setting per village for the side.<br />
* '''controller''': the identifier string of the side's controller. Uses the same syntax of the ''controller'' key in the [[SideWML|[side]]] tag.<br />
* '''fog''': a boolean string (yes/no) describing the status of Fog for the side.<br />
* '''shroud''': a boolean string describing the status of Shroud for the side.<br />
* '''hidden''': a boolean string specifying whether side is shown in status table.<br />
* '''color''': {{DevFeature1.11}} a team color range specification, name (e.g. "red", "blue"), or number (e.g. "1", "2") for this side. The default color range names, numbers, and definitions can be found in data/core/team_colors.cfg.<br />
* '''[ai]''': replaces a side's AI parameters with the new specified ones. Uses the same syntax described in [[AiWML]]. Note that [modify_side][ai] works for all simple AI parameters and some, but not all of the more complex ones. If in doubt, use [http://wiki.wesnoth.org/AiWML#Adding_and_Deleting_Aspects_with_the_.5Bmodify_ai.5D_Tag [modify_ai]] instead, which always works.<br />
* '''switch_ai''': replaces a side ai with a new AI from specified file(ignoring those AI parameters above). Path to file follows the usual WML convention.<br />
* '''reset_maps''': {{DevFeature1.11}} If set to "yes", then the shroud is spread to all hexes, covering the parts of the map that had already been explored by the side, including hexes currently seen. (Seen hexes will be cleared at the end of most events; they can also be manually cleared with {{tag|InterfaceActionsWML|redraw}}.) This is only effective if shroud is on, but this is evaluated after shroud= (and before shroud_data=).<br />
* '''reset_view''': {{DevFeature1.11}} If set to "yes", then the fog of war is spread to all hexes, covering the parts of the map that had already been seen this turn by the side, including hexes currently seen, excluding hexes affected by multi-turn {{tag|DirectActionsWML|lift_fog}}. (Seen hexes will be cleared at the end of most events; they can also be manually cleared with {{tag|InterfaceActionsWML|redraw}}.) This is only effective if fog is on, but this is evaluated after fog=.<br />
* '''share_maps''': change the share_maps side attribute. Be sure to use shroud=yes for that side and have it as an ally<br />
* '''share_view''': change the share_view side attribute. Be sure to use fog=yes for that side and have it as an ally<br />
* '''shroud_data''': changes to the side's shroud, using the same format as when defining the [side].<br />
* '''suppress_end_turn_confirmation''': {{DevFeature1.11}} Boolean value controlling whether or not a player is asked for confirmation when skipping a turn.<br />
* '''scroll_to_leader''': {{DevFeature1.11}} Boolean value controlling whether or not the game view scrolls to the side leader at the start of their turn when present.<br />
<br />
=== [modify_turns] ===<br />
Modifies the turn limit in the middle of a scenario.<br />
* '''value''': the new turn limit.<br />
* '''add''': if used instead of ''value'', specifies the number of turns to add to the current limit (can be negative).<br />
* '''current''': changes the current turn number after applying turn limit modifications, if any. It is not possible to change the turn number to exceed the turn limit (1 <= current turns <= max turns).<br />
<br />
=== [allow_end_turn] ===<br />
Allows human players to end their turn through the user interface if they were previously affected by the '''[disallow_end_turn]''' action. This action doesn't take any arguments.<br />
<br />
=== [disallow_end_turn] ===<br />
Disallows human players to end their turn through the user interface. This action doesn't take any arguments.<br />
<br />
'''Note:''' on Wesnoth versions prior to 1.10.6, there are two bugs affecting this WML action. First, its effect was lost when reloading from a saved game ([https://gna.org/bugs/?20350 bug #20350]); second, its effect persisted when advancing scenarios in a campaign ([https://gna.org/bugs/?20351 bug #20351]).<br />
<br />
A known workaround for both issues would be to use [[PreprocessorRef#.23ifver_and_.23ifnver|#ifver]]-based preprocessor macros to include additional code for Wesnoth 1.10.5 and earlier taking advantage of unique ''preload'', ''victory'', and ''defeat'' [[EventWML|event handlers]], such as the following:<br />
<br />
#ifver WESNOTH_VERSION > 1.10.5<br />
<br />
#define DISALLOW_END_TURN<br />
[disallow_end_turn][/disallow_end_turn]<br />
#enddef<br />
<br />
#define ALLOW_END_TURN<br />
[allow_end_turn][/allow_end_turn]<br />
#enddef<br />
<br />
#else<br />
<br />
#define DISALLOW_END_TURN<br />
[disallow_end_turn][/disallow_end_turn]<br />
<br />
[event]<br />
id=bug_20350_workaround<br />
name=preload<br />
<br />
[disallow_end_turn][/disallow_end_turn]<br />
[/event]<br />
<br />
[event]<br />
id=bug_20351_workaround<br />
name=victory,defeat<br />
<br />
[allow_end_turn][/allow_end_turn]<br />
[/event]<br />
#enddef<br />
<br />
#define ALLOW_END_TURN<br />
[allow_end_turn][/allow_end_turn]<br />
<br />
[event]<br />
id=bug_20350_workaround<br />
remove=yes<br />
[/event]<br />
<br />
[event]<br />
id=bug_20351_workaround<br />
remove=yes<br />
[/event]<br />
#enddef<br />
<br />
#endif<br />
<br />
=== [capture_village] ===<br />
Changes the ownership of a village.<br />
* [[StandardLocationFilter]]: all village locations matching the filter are affected.<br />
* '''side''': the side that takes control of the village. This side needs to have a leader (canrecruit=yes). If the side key is not given, the village will become neutral (unless [filter_side] is present, in which case that side fiter decides, see below).<br />
* '''[filter_side]''' with [[StandardSideFilter]] tags and keys as arguments; if both this tag and inline side= are present it's an error. Otherwise, the first matching side gets ownership (or the village becomes neutral if none match).<br />
* '''fire_event''' (boolean yes|no, default: no): Whether any capture events shall be fired.<br />
<br />
=== [kill] ===<br />
Removes all units (including units in a recall list) that match the filter from the game.<br />
* [[StandardUnitFilter]]: Selection criterion; do not use a [filter] tag.<br />
* '''animate''': if 'yes', displays the unit dying (fading away).<br />
* '''fire_event''': if 'yes', triggers any appropriate 'die' events (See [[EventWML]]). Note that events are only fired for killed units that have been on the map (as opposed to recall list).<br />
* '''[secondary_unit]''' with a [[StandardUnitFilter]] as argument. Do not use a [filter] tag. Has an effect only if fire_event=yes. The first on-map unit matching the filter becomes second_unit in any fired die and last breath events. If an on-map unit matches and if there are several units killed with a single [kill] tag, second_unit is this same unit for all of them. If no on-map unit matches or [secondary_unit] isn't present, the variable second_unit in each of the die and last breath events is always the same as the variable unit (the dying unit).<br />
<br />
=== [move_unit] ===<br />
works like the MOVE_UNIT macro.<br />
* [[StandardUnitFilter]] as argument; do not use a [filter] tag. All units matching the filter are moved. If the target location is occupied, the nearest free location is chosen.<br />
* '''to_x''' (unsigned integer): The units are moved to this x coordinate. Can be a comma-separated list, in which case the unit follows this given path during the move.<br />
* '''to_y''' (unsigned integer): The units are moved to this y coordinate. Can be a comma-separated list.<br />
* '''fire_event''' (optional, boolean yes|no, default no): Whether any according moveto events shall be fired. The target location ($x1, $y1 in the event) may not be the same location that the unit was tried to be moved to, if the original target location is occupied or impassable.<br />
* '''check_passability''' (boolean yes|no, default yes): Whether the terrain the unit is moved to should be checked for suiting the unit. (If it does not, a nearby suitable hex is chosen.)<br />
* {{DevFeature1.11}} '''force_scrolling''': Whether to scroll the map or not even when [[InterfaceActionsWML#.5Block_view.5D|[lock_view]]] is in effect or ''Follow Unit Actions'' is disabled in ''Advanced Preferences''. Defaults to using [[InterfaceActionsWML#.5Bmove_unit_fake.5D|[move_unit_fake]]]'s default value.<br />
<br />
=== [modify_ai] ===<br />
Changes AI objects (aspects, goals, candidate actions or stages) for a specified side. See [[AiWML#Adding_and_Deleting_Aspects_with_the_.5Bmodify_ai.5D_Tag|AiWML]] for full description.<br />
<br />
* '''action''' (string): Takes values 'add', 'change', 'delete' or 'try_delete' to do just that for the AI object.<br />
* '''path''' (string): Describes which AI object is to be modified. <br />
* '''[facet]''', '''[goal]''', '''[candidate_action]''' or '''[stage]''': Details about the AI object to be modified.<br />
* [[StandardSideFilter]] {{DevFeature1.11}} tags and keys; default for empty side= is all sides, as usual in a SSF.<br />
* '''[filter_side]''' with a [[StandardSideFilter]] as argument {{DevFeature1.11}}: [modify_ai][filter_side] is deprecated, use the new inline SSF.<br />
<br />
=== [modify_unit] ===<br />
works similar to the MODIFY_UNIT macro.<br />
* '''[filter]''' with a [[StandardUnitFilter]] as argument. All units matching this filter are modified. Matches on recall list units too.<br />
* Accepts generally the syntax inside of wml unit variables created by [store_unit] which can be viewed in a savefile or by using the :inspect command. Can add traits with immediate effect. Cannot remove things. Subtags with the same name must be written in the correct order to match them with the tag they are supposed to modify.<br />
example usage (see also the test scenario):<br />
[modify_unit]<br />
[filter]<br />
x,y=38,6<br />
[/filter]<br />
hitpoints=10<br />
{TRAIT_HEALTHY}<br />
[/modify_unit]<br />
<br />
The unit which is currently modified is accessible via $this_unit, e.g. hitpoints = "$($this_unit.hitpoints / 2)" to set the hitpoints of all units to half of their particular maxima. This this_unit variable is independent from the this_unit variable available in the SUF used to determine which units to modify (first all matching units are gathered, and then all those are modified).<br />
<br />
note: The syntax allowed is somehow vague. Just try things and possibly correct/add/modify this documentation. (a [http://forums.wesnoth.org/viewtopic.php?f=21&t=31676& forum thread] discusses some related issues).<br />
<br />
=== [transform_unit] ===<br />
Transforms every unit matching the filter to the given unit type. Keeps intact hit points, experience and status. If the unit is transformed to a non-living type (undead or mechanical), it will be also unpoisoned.<br />
{{DevFeature1.11}} Hit points will be changed if necessary to respect the transformed unit's maximum hit points.<br />
* [[StandardUnitFilter]]: do not use a [filter] tag.<br />
* '''transform_to''': the unit type in which all the units matching the filter will be transformed. If missing, the units will follow their normal advancement.<br />
<br />
=== [petrify] ===<br />
<br />
* [[StandardUnitFilter]] as an argument. Do not use a [filter] tag. All units matching this filter are petrified. Recall list units are included.<br />
<br />
=== [unpetrify] ===<br />
* [[StandardUnitFilter]] as an argument. Do not use a [filter] tag. All units matching this filter are unpetrified. Recall list units are included.<br />
<br />
=== [object] ===<br />
Gives some unit an object which modifies their stats in some way.<br />
* '''id''': (Optional) 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.<br />
* '''delayed_variable_substitution''' (boolean yes|no, default no): If set to "yes", the wml block contained in this [object] is not variable-substituted at execution time of the event where this [object] is within. You need this to work around a bug when adding ABILITY_TELEPORT via an [object] or when using [object][effect][filter]with a $this_unit (see http://gna.org/bugs/index.php?18893).<br />
* '''[effect]''': one or more effect elements may be listed. See [[EffectWML]] for a description of [effect].<br />
* '''duration''':<br />
**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). {{DevFeature1.11}} 'level' has been renamed to 'scenario'.<br />
**if 'forever' or not set, effects never wear off.<br />
** {{DevFeature1.11}} if 'turn', effects only last until the start of the unit's next turn (when the unit refreshes movement and attacks). (Like other start-of-turn behavior, objects with a duration of "turn" won't expire before turn 2.)<br />
* '''[filter]''' with a [[StandardUnitFilter]] as argument. The first unit found that matches the filter will be given the object. Only on-map units are considered. If no unit matches or no [filter] is supplied, it is tried to apply the object to the unit at the $x1,$y1 location of the event where this [object] is in. The case of no unit being at that spot is handled in the same way as no unit matching a given filter ([else] commands executed, cannot_use_message displayed)<br />
* '''[then]''': a subtag that lets you execute actions if the filter conditions are met. The most common action that should be inside here is a '''[remove_item]''' tag, but you could probably put any tags that otherwise work in a [then] tag.<br />
* '''[else]''': a subtag that lets you execute actions if the filter conditions are *not* met.<br />
* '''silent''': whether or not messages should be suppressed. Default is "no".<br />
* '''image''': the displayed image of the object.<br />
* '''name''': (translatable) displayed as a caption of the image.<br />
<br />
* '''description''': (translatable) displayed as a message of the image.<br />
* '''cannot_use_message''': (translatable) displayed instead of '''description''' if no unit passes the filter test.<br />
<br />
=== [remove_shroud] ===<br />
Removes some shroud from the map for a certain side (only relevant for sides that have shroud=yes).<br />
* '''side''': (default=1) the side for which to remove shroud. This can be a comma-separated list of sides. note: Default side=1 for empty side= is deprecated.<br />
* '''[filter_side]''' with a [[StandardSideFilter]] as argument<br />
* [[StandardLocationFilter]]: the range of tiles for which shroud should be removed<br />
<br />
=== [place_shroud] ===<br />
Places some shroud on the map for a certain side (only relevant for sides that have shroud=yes).<br />
* '''side''': (default=1) the side for which to place shroud. This can be a comma-separated list. note: Default side=1 for empty side= is deprecated.<br />
* '''[filter_side]''' with a [[StandardSideFilter]] as argument<br />
* [[StandardLocationFilter]]: the range of tiles on which shroud should be placed<br />
<br />
=== [lift_fog] ===<br />
{{DevFeature1.11}}Lifts the fog of war from parts of the map for a certain side (only relevant for sides that have fog=yes), allowing a player to witness what occurs there even if that player has no units within vision range.<br />
* '''[filter_side]''' with a [[StandardSideFilter]] indicating which sides should be affected.<br />
* [[StandardLocationFilter]]: the tiles from which fog should be lifted.<br />
* '''multiturn''': ''yes/no, default:no''. The default (not multiturn) causes fog to be removed in the same way that normal vision works; the cleared tiles will remain cleared until fog is recalculated (which normally happens when a side ends its turn). When multiturn is set to "yes", the cleared tiles remain clear until {{tag||reset_fog}} cancels the clearing. This allows tiles to remain clear for multiple turns, or to be refogged before the end of the current turn (without also refogging all tiles). Multiturn lifted fog is not shared with allies (even when share_view=yes).<br />
<br />
=== [reset_fog] ===<br />
{{DevFeature1.11}}The primary use of this tag is to remove multiturn lifted fog (created by {{tag||lift_fog}}), which causes the fog to reset to what it would have been had WML not interfered. (That is, hexes that a side's units could not see at any point this turn will be re-fogged, while seen hexes remain defogged.)<br />
* '''[filter_side]''' with a [[StandardSideFilter]] indicating which sides should be affected.<br />
* [[StandardLocationFilter]]: the fog reset will be restricted to these tiles.<br />
* '''reset_view''': ''yes/no, default: no'' If set to "yes", then in addition to removing multiturn fog, the side's current view is canceled (independent of the SLF). This means that all hexes will become fogged for the side unless multiturn fog exists outside the tiles selected by the SLF. Normally, one would want the currently seen hexes to become clear of fog; this is done automatically at the end of many events, and it can be done manually with {{tag|InterfaceActionsWML|redraw}}.<br />
Omitting both the SSF and the SLF would cancel all earlier uses of [lift_fog].<br />
Additionally setting reset_view="yes" would cause the side's entire map to be fogged (unless an ally keeps hexes clear by sharing its view).<br />
<br />
=== [allow_undo] ===<br />
<br />
Normally when an event with a handler fires, the player's undo stack is cleared, preventing all actions performed so far from being undone. Including this tag in the event handler prevents the stack from being cleared for this reason, allowing the player to undo actions. (However, the stack might still be cleared for other reasons, such as fog being cleared or combat occurring.) In the common cases, this means '''[allow_undo]''' allows the current action to be undone even though an event was handled. There is a less common case, though &mdash; specifically when handling a menu item, where there is no current action &mdash; and in this case, '''[allow_undo]''' means merely that earlier actions can still be undone.<br />
* {{DevFeature1.11}} Using this tag in a menu item has an additional side effect in 1.11. Starting with version 1.11.1, executing a WML menu item normally counts as doing something as far as the "you have not started your turn yet" dialog is concerned. However, a menu item whose handler includes '''[allow_undo]''' will not count.<br />
<br />
This tag does nothing during recruit and recall actions, as the game incorrectly ignores whether or not an event fired during those times. {{DevFeature1.11}} This has been fixed in the latest development release.<br />
<br />
The types of actions that can be undone are movement, recruitment, recalling, and dismissing a unit from the recall list. If an action is undone, only the position (or existence) of the involved unit will be restored; any altered variables or changes to the game will remain changed after the action is undone. It is up to the scenario designer to avoid abusing this command.<br />
* Technically, if '''[allow_undo]''' is inside an '''[event]''' with ''first_time_only=yes'' (the default setting), and the user undoes the event, then the state of the game has changed in this way: the event will not fire a second time, even though the user undid the action the first time.<br />
<br />
=== [heal_unit] ===<br />
Heal a unit. The variable '''$heal_amount''' will be set to the exact number of points healed (i.e can be lesser than the parameter '''amount''' if the unit is fully healed). $heal_amount contains only the number of hitpoints the first unit that was found got healed.<br />
* '''[filter]''': [[StandardUnitFilter]] All matching on-map units are healed. If no filter is supplied, it is tried to take the unit at $x1, $y1.<br />
* '''[filter_second]''': [[StandardUnitFilter]] all the units matching the filter ''and'' having the ''heals'' ability will have their animation played (if ''animate'' is set to true) for each of the units healed.<br />
* '''amount''': (integer, default full) the maximum points the unit(s) will be healed. Can't set below 1 or above max_hitpoints. If "full", sets hitpoints to max_hitpoints. Before 1.9 the default is 0.<br />
* '''animate''': a boolean which indicate if the healing animations must be played. (default no)<br />
* '''moves''': (integer, default 0) The maximum current movement points the units will be "healed". Can't set below 0 or above max_moves. If "full", sets moves to max_moves.<br />
* '''restore_attacks''': (boolean, default no) Whether the units' attacks_left should be reset to their max_attacks (usually 1).<br />
* '''restore_statuses''': (boolean, default yes) Whether standard statuses should be reset to "no". This affects poisoned, slowed, petrified and unhealable. Before 1.9 this is always "no".<br />
<br />
=== [harm_unit] ===<br />
Harms every unit matching the filter, for the specific damage amount.<br />
* '''[filter]''': [[StandardUnitFilter]] all matching units will be harmed (required).<br />
* '''[filter_second]''': [[StandardUnitFilter]] if present, the first matching unit will attack all the units matching the filter above.<br />
* '''amount''': the amount of damage that will be done (required).<br />
* '''alignment''': (default neutral) applies an alignment to the damage, this means that if alignment=chaotic, the damage will be increased at night and reduced at day.<br />
* '''damage_type''': if present, amount will be altered by unit resistance to the damage type specified.<br />
* '''kill''': (default yes) if yes, when a harmed unit goes to or below 0 HP, it is killed; if no its HP are set to 1.<br />
* '''fire_event''': (default no) if yes, when a unit is killed by harming, the corresponding events are fired. {{DevFeature1.11}} If yes, also the corresponding advance and post advance events are fired.<br />
* '''animate''': (default no) if yes, scrolls to each unit before harming it and plays its defense (or attack, if it's the harmer) and death animations. Special values supported, other than the usual yes and no, are "attacker", that means only the harmer will be animated, and "defender", that means only the harmed units will be animated. {{DevFeature1.11}} If the supplied value is yes, attacker or defender also advancement animations are played.<br />
* '''[primary_attack], [secondary_attack]''': these set the weapon against which the harmed units will defend, and that the harming unit will use to attack, respectively (notice this is the opposite of '''[filter]''' and '''[filter_second]''' above). This allows for playing specific defense and attack animations. Both tags are expected to contain a [[FilterWML#Filtering_Weapons|Standard Weapon Filter]].<br />
* '''delay''': if animate=yes, sets the delay (in milliseconds, default 500) between each unit harming.<br />
* '''variable''': if present, the damage caused to the unit, altered by resistances, will be stored in a WML array with the given name, under the "harm_amount" key.<br />
* '''poisoned, slowed, petrified, unhealable''': (default no) if yes, every harmed unit that doesn't already have such status will have it set.<br />
* '''experience''': if yes, and there is a harmer, experience will be attributed like in regular combat.<br />
* '''resistance_multiplier''': {{DevFeature1.11}} the harmed unit's resistance is multiplied by the supplied value; this means that a value lower than 1 increases it, and a value greater than 1 decreases it. Default value is 1, that means no modification.<br />
<br />
=== [time_area] ===<br />
How a day should progress in a given area. Everywhere not specified in a [time_area] tag is affected by the [time] tags in the [scenario] tag.<br />
* [[StandardLocationFilter]]: the locations to affect. ''note: only for [event][time_area]s - at scenario toplevel [time_area] does not support [[StandardLocationFilter]], only location ranges''<br />
* [[TimeWML]]: the new schedule.<br />
* '''id''': an unique identifier assigned to a time_area. Optional, unless you want to remove the time_area later. Can be a comma-separated list when removing time_areas, see below.<br />
* '''remove''': (boolean) yes/no value. Indicates whether the specified time_area should be removed. Requires an identifier. If no identifier is used, however, all time_areas are removed.<br />
* '''current_time''': The time slot number (starting with zero) active at the creation of the area.{{DevFeature1.11}}<br />
<br />
''Example:'' (caves in parts of a map)<br />
[time_area]<br />
x=1-2,4-5<br />
y=1-2,1-2<br />
{UNDERGROUND}<br />
[/time_area]<br />
<br />
=== [end_turn] ===<br />
End the current side's turn. The current event is finished before the turn is ended. Also, if the current event (where the tag appears) has been fired by another event, that event (and the complete stack of other possible parent events) is ended before [end_turn] comes into affect. Also, events following the event stack that fired [end_turn] are not omitted (e.g. [end_turn] is used by a side turn event and a turn refresh event does something afterwards).<br />
<br />
=== [replace_map] ===<br />
<br />
Replaces the entire map.<br />
* '''map''': Content of a wesnoth map file. example:<br />
map="{campaigns/Heir_To_The_Throne/maps/01_The_Elves_Besieged.map}"<br />
* '''expand''': if 'yes', allows the map size to increase. The expansion direction is currently always bottom-right.<br />
* '''shrink''': if 'yes', allows the map size to decrease. If the map size is reduced, any units that would no longer be on the map due to its coordinates no longer existing will be put into the recall list.<br />
Note: When a hex changes from a village terrain to a non-village terrain, and a team owned that village it loses that village. When a hex changes from a non-village terrain to a village terrain and there is a unit on that hex it does not automatically capture the village. The reason for not capturing villages it that there are too many choices to make; should a unit loose its movement points, should capture events be fired. It is easier to do this as wanted by the author in WML.<br />
<br />
=== [replace_schedule] ===<br />
Replace the time of day schedule of the entire scenario.<br />
* [[TimeWML]]: the new schedule.<br />
<br />
=== [tunnel] ===<br />
<br />
Create a tunnel between some locations, later usable by units to move from source hex to target hex (using the movement cost of unit on the target terrain). ([http://forums.wesnoth.org/viewtopic.php?f=21&t=14749&p=405667&hilit=tunnel#p405667 source])<br />
<br />
* '''id''' identifier for the tunnel, to allow removing (optional).<br />
* '''remove''': (boolean) yes/no value. If yes, removes all defined tunnels with the same ID (then only id= is necessary). (default: no)<br />
* '''bidirectional''': (boolean) if yes, creates also a tunnel in the other direction. (default: yes)<br />
* '''always_visible''': (boolean) if yes, the possible movement of enemies under fog can be seen. (default: no)<br />
* '''[source]''': [[StandardLocationFilter]] the source hex(es) (required).<br />
* '''[target]''': [[StandardLocationFilter]] the target hex(es) (required).<br />
* '''[filter]''': [[StandardUnitFilter]] the units which can use the tunnel (required). Leave empty for "all units".<br />
<br />
(Note: The tunnel tag can also be used inside the [[AbilitiesWML|[teleport]]] ability, without remove= and id=).<br />
<br />
== Useful Macros ==<br />
There are some predefined macros that you find useful for direct actions. You can find a complete list along with a detailed explanation of how they work [http://www.wesnoth.org/macro-reference.xhtml here].<br />
* '''{MOVE_UNIT}''': Moves a unit to another location in the map and the player sees the movement (unlike [teleport])<br />
* '''{FULL_HEAL}''': Brings a unit to full HP<br />
* '''{LOYAL_UNIT}''': Create a loyal unit<br />
* '''{MODIFY_TERRAIN_MASK}''': Modify an area of terrain<br />
<br />
== See Also ==<br />
<br />
* [[InternalActionsWML]]<br />
* [[InterfaceActionsWML]]<br />
* [[EventWML]]<br />
* [[ReferenceWML]]<br />
<br />
[[Category: WML Reference]]<br />
[[Category: ActionsWML]]</div>Fabihttps://wiki.wesnoth.org/index.php?title=GameConfigWML&diff=52261GameConfigWML2013-10-27T04:28:14Z<p>Fabi: /* The [game_config] tag */</p>
<hr />
<div>{{WML Tags}}<br />
== The [game_config] tag ==<br />
<br />
This tag is a top level WML tag which can only be used once because<br />
it defines basic settings that are used everywhere in the game.<br />
In official versions of Wesnoth it is in ''game_config.cfg''; values used there are labeled 'standard'.<br />
<br />
<br />
The following keys are recognised<br />
* '''base_income''': (standard 2) how much your leader earns without any villages<br />
* '''village_income''': (standard 1) how much your leader earns for each village you control<br />
* '''poison_amount''': (standard 8) the amount of damage poison deals to a unit<br />
* '''rest_heal_amount''': (standard 2) how much HP a unit gains each turn it rests<br />
* '''recall_cost''': (standard 20) how much it costs to recall a unit; this cost is independent of level.<br />
* '''kill_experience''': (standard 8) killing a unit with ''level=X'' will give ''X''*''kill_experience'' experience to the killing unit. However, if a unit has ''level=0'', it will still give half of ''X'' experience.<br />
<br />
* '''icon''': (standard 'wesnoth-icon.png') the game icon file<br />
* '''title''': (standard 'misc/title.png') the title screen image<br />
* '''logo''': (standard 'misc/logo.png') the wesnoth logo which will be put over the title image<br />
* '''default_defeat_music''': (standard 'defeat.ogg,defeat2.ogg') default list of music tracks that are chosen to play on player's defeat; this can be overriden per-scenario<br />
* '''default_victory_music''': (standard 'victory.ogg,victory2.ogg') default list of music tracks that are chosen to play on player's victory; this can be overriden per-scenario<br />
* '''title_music''': (standard 'main_menu.ogg') the music to play at the title screen<br />
* '''logo_x''': (standard 292) the x position of the logo on the title screen<br />
* '''logo_y''': (standard 120) the y position of the logo on the title screen<br />
* '''buttons_x''': (standard 760) the x position of the buttons on the title screen<br />
* '''buttons_y''': (standard 330) the y position of the buttons on the title screen<br />
* '''buttons_padding''': (standard 20) space between buttons, and border in main menu<br />
* '''tip_x''': (standard 100) space between the button panel left edge and the tip-of-the-day panel right edge<br />
* '''tip_y''': (standard 500) not used (the bottom right corner of the tip-of-the-day panel is pegged to align with the bottom of the button panel)<br />
* '''tip_width''': (standard 495) max width in pixels of the tip-of-the-day panel. The width will actually adjust to be the smallest size necessary to fit the text. Once the max width is reached, if text must flow onto multiple lines, then the height will also automatically adjust.<br />
* '''tip_padding''': (standard 20) space between the edge of the tip-of-the-day panel and an imaginary bounding box containing the text inside the panel<br />
<br />
* '''map_image''': (standard 'maps/wesnoth.png') the background image for the "About" screen<br />
* '''sidebar_image''': (standard 'misc/rightside.png') border of window when displaying unit statistics<br />
* '''sidebar_image_bottom''': (standard 'misc/rightside-bottom.png') border of image when displaying unit statistics<br />
* '''energy_image''': (standard 'misc/bar-energy.png') the images used to display hp/xp bars.<br />
* '''moved_ball_image''': (standard 'misc/ball-moved.png') the orb image to add on top of the hp bar for player's moved units; see 'Orbs', [[WesnothManual]]<br />
* '''unmoved_ball_image''': (standard 'misc/ball-unmoved.png') like '''moved_ball_image''', but for player's unmoved units<br />
* '''partmoved_ball_image''': (standard 'misc/ball-partmoved.png') like '''moved_energy_image''', but for player's partially moved units<br />
* '''flag_image''': (standard 'image/flag'terrain/flag-1.png:150,terrain/flag-2.png:150,terrain/flag-3.png:150,terrain/flag-4.png:150') the default flag animation to mark captured villages (if no custom flag is defined in the [side] tag). By example, this animation has 4 frames of 150ms each. An automatic side-coloring is applied. <br />
* '''flag_icon_image''': (standard 'flags/flag-icon.png') the default flag icon to indicate the side playing in the statusbar (if no custom flag_icon is defined in the [side] tag). An automatic side-coloring is applied. <br />
* ''' hp_bar_scalling ''': (standard '0.6') The ratio of hitpoints to height used for displaying the hp bar. {{DevFeature1.11}} Can be overwritten in [unit] and [unit_type].<br />
* ''' xp_bar_scalling ''': (standard '0.5') The ratio of xp to height used for displaying the xp bar. {{DevFeature1.11}} Can be overwritten in [unit] and [unit_type].<br />
* '''cross_image''': (standard 'misc/cross.png') the cross image displayed on the map at start of scenarios; see [[IntroWML]]<br />
* '''dot_image''': (standard 'misc/dot.png') the dot image used to draw a path on the map before scenarios<br />
<br />
* '''footprint_left_nw''', '''footprint_left_n''', '''footprint_right_nw''', '''footprint_right_n''': images used to display the path that a unit would take to the tile the cursor is on.<br />
The first image of each key is used for tiles which would take only 1 movement point for the selected unit to move onto;<br />
the second for ones which would take more.<br />
The 'n' and 'nw' designations distinguish between tiles which are moved from orthogonally and diagonally in the same way as described in '''[missile_frame]''', [[AnimationWML]].<br />
The 'left' and 'right' designations are used alternately throughout the path;<br />
however, the standard values are the same for 'left' and 'right'.<br />
<br />
* '''terrain_mask_image''': (standard 'terrain/alphamask.png') used to give a hex-shape from a rectangular image.<br />
* '''grid_image''': (standard 'terrain/grid.png') the image used by the grid option <br />
* '''unreachable_image''': (standard 'terrain/darken.png') the stripes mask used to show unreachable locations<br />
<br />
* '''missile_n_image''': (standard 'projectiles/missile-n.png') orthogonal missile image to use if none is specified; see ''image'', '''[missile_frame]''', [[AnimationWML]]<br />
* '''missile_ne_image''': (standard 'projectiles/missile-ne.png') diagonal missile image to use if none is specified; see ''image_diagonal'', '''[missile_frame]''', [[AnimationWML]]<br />
* '''observer_image''': (standard 'misc/eye.png') the image to use for observer in multi-player games. (The eye in the upper right hand corner.)<br />
* '''download_campaign_image''': (standard no image) the icon for the "Download more Campaigns" campaign menu option.<br />
<br />
== See Also ==<br />
<br />
* [[ReferenceWML]]<br />
<br />
<br />
[[Category: WML Reference]]</div>Fabihttps://wiki.wesnoth.org/index.php?title=GameConfigWML&diff=52260GameConfigWML2013-10-27T04:20:22Z<p>Fabi: /* The [game_config] tag */</p>
<hr />
<div>{{WML Tags}}<br />
== The [game_config] tag ==<br />
<br />
This tag is a top level WML tag which can only be used once because<br />
it defines basic settings that are used everywhere in the game.<br />
In official versions of Wesnoth it is in ''game_config.cfg''; values used there are labeled 'standard'.<br />
<br />
<br />
The following keys are recognised<br />
* '''base_income''': (standard 2) how much your leader earns without any villages<br />
* '''village_income''': (standard 1) how much your leader earns for each village you control<br />
* '''poison_amount''': (standard 8) the amount of damage poison deals to a unit<br />
* '''rest_heal_amount''': (standard 2) how much HP a unit gains each turn it rests<br />
* '''recall_cost''': (standard 20) how much it costs to recall a unit; this cost is independent of level.<br />
* '''kill_experience''': (standard 8) killing a unit with ''level=X'' will give ''X''*''kill_experience'' experience to the killing unit. However, if a unit has ''level=0'', it will still give half of ''X'' experience.<br />
<br />
* '''icon''': (standard 'wesnoth-icon.png') the game icon file<br />
* '''title''': (standard 'misc/title.png') the title screen image<br />
* '''logo''': (standard 'misc/logo.png') the wesnoth logo which will be put over the title image<br />
* '''default_defeat_music''': (standard 'defeat.ogg,defeat2.ogg') default list of music tracks that are chosen to play on player's defeat; this can be overriden per-scenario<br />
* '''default_victory_music''': (standard 'victory.ogg,victory2.ogg') default list of music tracks that are chosen to play on player's victory; this can be overriden per-scenario<br />
* '''title_music''': (standard 'main_menu.ogg') the music to play at the title screen<br />
* '''logo_x''': (standard 292) the x position of the logo on the title screen<br />
* '''logo_y''': (standard 120) the y position of the logo on the title screen<br />
* '''buttons_x''': (standard 760) the x position of the buttons on the title screen<br />
* '''buttons_y''': (standard 330) the y position of the buttons on the title screen<br />
* '''buttons_padding''': (standard 20) space between buttons, and border in main menu<br />
* '''tip_x''': (standard 100) space between the button panel left edge and the tip-of-the-day panel right edge<br />
* '''tip_y''': (standard 500) not used (the bottom right corner of the tip-of-the-day panel is pegged to align with the bottom of the button panel)<br />
* '''tip_width''': (standard 495) max width in pixels of the tip-of-the-day panel. The width will actually adjust to be the smallest size necessary to fit the text. Once the max width is reached, if text must flow onto multiple lines, then the height will also automatically adjust.<br />
* '''tip_padding''': (standard 20) space between the edge of the tip-of-the-day panel and an imaginary bounding box containing the text inside the panel<br />
<br />
* '''map_image''': (standard 'maps/wesnoth.png') the background image for the "About" screen<br />
* '''sidebar_image''': (standard 'misc/rightside.png') border of window when displaying unit statistics<br />
* '''sidebar_image_bottom''': (standard 'misc/rightside-bottom.png') border of image when displaying unit statistics<br />
* '''energy_image''': (standard 'misc/bar-energy.png') the images used to display hp/xp bars.<br />
* '''moved_ball_image''': (standard 'misc/ball-moved.png') the orb image to add on top of the hp bar for player's moved units; see 'Orbs', [[WesnothManual]]<br />
* '''unmoved_ball_image''': (standard 'misc/ball-unmoved.png') like '''moved_ball_image''', but for player's unmoved units<br />
* '''partmoved_ball_image''': (standard 'misc/ball-partmoved.png') like '''moved_energy_image''', but for player's partially moved units<br />
* '''flag_image''': (standard 'image/flag'terrain/flag-1.png:150,terrain/flag-2.png:150,terrain/flag-3.png:150,terrain/flag-4.png:150') the default flag animation to mark captured villages (if no custom flag is defined in the [side] tag). By example, this animation has 4 frames of 150ms each. An automatic side-coloring is applied. <br />
* '''flag_icon_image''': (standard 'flags/flag-icon.png') the default flag icon to indicate the side playing in the statusbar (if no custom flag_icon is defined in the [side] tag). An automatic side-coloring is applied. <br />
* ''' hp_bar_scalling ''': The ratio of hitpoints to height used for displaying the hp bar. (standard '0.6')<br />
* ''' xp_bar_scalling ''': The ratio of xp to height used for displaying the xp bar. (standard '0.5')<br />
<br />
* '''cross_image''': (standard 'misc/cross.png') the cross image displayed on the map at start of scenarios; see [[IntroWML]]<br />
* '''dot_image''': (standard 'misc/dot.png') the dot image used to draw a path on the map before scenarios<br />
<br />
* '''footprint_left_nw''', '''footprint_left_n''', '''footprint_right_nw''', '''footprint_right_n''': images used to display the path that a unit would take to the tile the cursor is on.<br />
The first image of each key is used for tiles which would take only 1 movement point for the selected unit to move onto;<br />
the second for ones which would take more.<br />
The 'n' and 'nw' designations distinguish between tiles which are moved from orthogonally and diagonally in the same way as described in '''[missile_frame]''', [[AnimationWML]].<br />
The 'left' and 'right' designations are used alternately throughout the path;<br />
however, the standard values are the same for 'left' and 'right'.<br />
<br />
* '''terrain_mask_image''': (standard 'terrain/alphamask.png') used to give a hex-shape from a rectangular image.<br />
* '''grid_image''': (standard 'terrain/grid.png') the image used by the grid option <br />
* '''unreachable_image''': (standard 'terrain/darken.png') the stripes mask used to show unreachable locations<br />
<br />
* '''missile_n_image''': (standard 'projectiles/missile-n.png') orthogonal missile image to use if none is specified; see ''image'', '''[missile_frame]''', [[AnimationWML]]<br />
* '''missile_ne_image''': (standard 'projectiles/missile-ne.png') diagonal missile image to use if none is specified; see ''image_diagonal'', '''[missile_frame]''', [[AnimationWML]]<br />
* '''observer_image''': (standard 'misc/eye.png') the image to use for observer in multi-player games. (The eye in the upper right hand corner.)<br />
* '''download_campaign_image''': (standard no image) the icon for the "Download more Campaigns" campaign menu option.<br />
<br />
== See Also ==<br />
<br />
* [[ReferenceWML]]<br />
<br />
<br />
[[Category: WML Reference]]</div>Fabihttps://wiki.wesnoth.org/index.php?title=SingleUnitWML&diff=52259SingleUnitWML2013-10-27T04:12:45Z<p>Fabi: /* How to describe a single unit */</p>
<hr />
<div>{{WML Tags}}<br />
== How to describe a single unit ==<br />
<br />
This tag, '''[unit]''', describes a single unit on the map, for example Konrad.<br />
It is different from the [unit_type] in [units], which describes a class of units. However it takes many of the same keys and thus can generally override the inherited properties from the associated [unit_type].<br />
<br />
[unit] can be used inside [side] ([[SideWML]]) for units present at start of the scenario, or as [[DirectActionsWML]] for units created during the game. (It is also used in save-files.)<br />
<br />
The following keys are recognized:<br />
* '''type''': the ID of the unit's unit type. See [[UnitTypeWML]].<br />
<br />
* '''parent_type''': {{DevFeature1.11}} overrides '''type''' if this is present. This is likely of little use to WML authors; it is automatically generated when needed by the game (to keep track of some [unit_type][variation]s).<br />
<br />
* '''side''': the side that the unit is on. It has to be an existing side, even if the unit is created in a variable.<br />
<br />
* '''gender''': can be set to male or female to designate the gender of the unit. Default is male, but if the unit has only a female variant it will be female.<br />
<br />
* '''x''', '''y''': the location of the unit. By default ( see '''placement''') if a location isn't provided and the side the unit will belong to has a recall list, the unit will be created on the recall list.<br />
<br />
* '''placement''': How the unit should be placed: can be one value or a comma-separated list of values. Default value is 'map,leader' for a leader given directly in [side], "" otherwise. By default, 'map,recall' is implicitly appended to the end of the list.<br />
** '''map''': If x,y are explicitly given and point to a valid on-map location - try to place the unit at the nearest free location to there, never overwriting existing units. Successful if x,y are given and a valid on-map vacant location near it can be found.<br />
** '''leader''': Try to place unit near the leader, if leader is not present or is in recall list - try to place unit near the start location for this side. Successful if a valid on-map vacant location can be found near leader or near start location.<br />
** '''recall''': Place unit on recall list. Always successful. <br />
** '''map_overwrite''': If x,y are explicitly given and point to a valid on-map location - try to place unit at this location, if there was a unit there - overwriting it, without firing events. note: This value currently (1.9.12) does not work since it apparently wasn't implemented; see also http://gna.org/bugs/?15113<br />
** '''map_passable''': If x,y are explicitly given and point to a valid on-map location - try to place unit at this location; if the hex is of an impassable terrain for the unit being placed, or is already occupied by another unit, the new unit will be placed in the nearest vacant hex.<br />
** '''leader_passable''': Similar to "leader", with the additional restriction that the selected location is not impassable for the unit being placed.<br />
<br />
* '''to_variable''': creates the unit into the given variable instead of placing it on the map.<br />
<br />
* '''id''': a unique identifier for the unit. This is (usually) not displayed to the player, but is to be used only for identifying and filtering units. If not specified or when a unit is normally recruited, a random one will be generated for the unit to ensure that each unit has a unique ''id'' attribute. In older versions, the '''description''' attribute specified a unique ID. (The one instance when an id is displayed to the player is when the leader's id is used as the default for a [[SideWML|side]]'s '''current_player''' attribute.)<br />
<br />
* '''name''': the user-visible name of the unit. Note that the player may use the "rename unit" action to change this.<br />
<br />
* '''generate_name''': (default=yes) will generate a new name if there isn't one specifed for the unit, as if the unit were a freshly-recruited one<br />
<br />
* '''unrenamable''': if 'yes', the user-visible name of the unit cannot be changed by the player (which is only possible when the unit is on the player's side anyway).<br />
<br />
* '''traits_description''': the description of the unit's traits which is displayed. However if it is not specified explicitly, the unit's actual traits' names will be used instead, so it is normally not necessary to set this.<br />
<br />
* '''random_traits''': "no" will prevent random trait generation for units. You should only need to set this for placed nonleaders in multiplayer games or if you want to give a unit less traits than it would normally get for its unit type. When generating traits for a unit, first traits the unit has already been given are excluded. Then "musthave" traits (undead, mechanical) for the unit type are given. Then for leaders ('''canrecruit=yes''') traits that are not available to "any" (currently that's all of them to avoid a multiplayer OOS issue, but later will be restricted based on multiplayer play balance issues) are removed from consideration. Then traits are added randomly until the maximum allowed for the unit type is reached or there are no more available traits. Random traits can now be used in MP games but only when spawned in an event, so not for leaders and other units in the [side] definition.<br />
<br />
* '''random_gender''': "yes" will cause the gender of the unit with male and female variations to be male 50% of the time, female 50% of the time. If the unit has only one gender variant it will always be given the correct one.<br />
<br />
* '''canrecruit''': a special key for leaders.<br />
** '''no''': default. Unit cannot recruit.<br />
** '''yes''': unit can recruit.<br />
: Normally when a team controls no units with '''canrecruit=yes''', that team loses. However, even if your team has lost you continue to play with whatever units you still have until the scenario is over. Usually scenarios end when only one team is left with a leader that can recruit, but special victory conditions can be set up in campaigns. Normally you want to set the leader of a side with '''canrecruit=yes'''. If you don't want the leader to recruit, it is usually better to just not give him any unit types to recruit, than to make a special victory condition. Units with '''canrecruit=yes''' are exempt from upkeep costs. So that leaders do not need to be given the ''loyal'' trait.<br />
: More than one unit with '''canrecruit=yes''' for the same side (see [[SideWML]]) are allowed in single player, if the side is human-controlled.<br />
<br />
* '''extra_recruit''': a list of unit types which this unit can recruit in addition to the ones given by its [side]recruit=, only working for units with '''canrecruit=yes'''.<br />
<br />
* '''variation''': the variation of itself the unit should be created as.<br />
<br />
* '''upkeep''': the amount of upkeep the unit costs.<br />
** '''loyal''': no upkeep cost. Can be changed by the effect 'loyal' (see [[EffectWML]])<br />
** '''free''': synonymous with "loyal".<br />
** '''full''': unit costs ''level'' upkeep (see [[UnitTypeWML]]).<br />
** An integer can be used to set the upkeep cost to that number.<br />
** The default is "full".<br />
** Leaders (units with '''canrecruit=yes''') never pay upkeep no matter what upkeep is set to.<br />
** Normally you don't want to muck with this value. If you want to give a side units without upkeep costs, give those units the 'loyal' trait.<br />
<br />
* '''overlays''': a list of images that are overlayed on the unit.<br />
<br />
* '''goto_x''':, '''goto_y''': UI settings that control courses. Default is 0,0 i.e. the unit is not on a course.<br />
<br />
* '''hitpoints''': the HP of the unit. Default is the max HP for ''type''.<br />
<br />
* {{DevFeature1.11}} '''hp_bar_scalling''': Overwrites the attribute in ([[GameConfigWML]]).<br />
<br />
* '''experience''': the XP of the unit. Default is 0.<br />
<br />
* '''moves''': number of movement points the unit has left. Default is the movement for its unit type.<br />
<br />
* '''attacks_left''': number of attacks the unit has left. Default is equal to the attacks key for its unit type, that usually is 1 (see ''max_attacks'' below).<br />
<br />
* '''resting''': whether the unit has not moved yet this turn. Used to decide whether to give a unit rest healing.<br />
<br />
* '''role''': used in standard unit filter ([[FilterWML]]). Can be set using [role] (see [[InternalActionsWML]]).<br />
<br />
* '''ai_special''': causes the unit to act differently<br />
** "guardian" the unit will not move, except to attack something in the turn it moves (so, it only can move if an enemy unit gets within range of it). {{DevFeature1.11}} Does the same as '''[status] guardian = 'yes''''.<br />
<br />
* '''facing''': which way the unit is facing (this only affects how the unit is displayed).<br />
** Possible values are '''se''', '''s''', '''sw''', '''nw''', '''n''', '''ne'''. Using '''sw''' is preferred for a "reversed" facing (looking to the left) and '''se''' for a normal (looking to the right) facing.<br />
<br />
* '''profile''': sets a portrait image for this unit. If the unit type already has a portrait set, this is used instead for this unit. When the unit advances, if the value of profile is different from the unit-type portrait, that value is preserved. If the profile field is empty or the same as the unit-type portrait, the level-advance changes the unit portrait to the default for the new level and type. See [[UnitTypeWML]] for the rules used for locating files.<br />
** "unit_image" if given instead of a filename, uses the unit's base image as the portrait (in the same manner that unit types without portraits do by default).<br />
<br />
* '''small_profile''': sets a small portrait image for this unit. See the '''profile''' attribute above for advancement and special values. As with [[UnitTypeWML]], the location heuristic of the '''profile''' attribute is disabled when the '''small_profile''' attribute is provided.<br />
<br />
* '''max_attacks''': Default is 1. The number of attacks the unit can have per turn.<br />
<br />
* '''max_experience''': The experience the unit needs to advance. If left out, this information will be taken from the unit's file.<br />
<br />
* '''max_hitpoints''': The maximum hitpoints the unit has. If left out, this information will be taken from the unit's file.<br />
<br />
* '''max_moves''': The maximum moves the unit has. If left out, this information will be taken from the unit's file.<br />
<br />
* '''animate''': if ''yes'', fades the unit in like when it's recruited/recalled.<br />
<br />
* '''[status]''' the status of the unit. This affects different features of the unit, for example whether the unit loses health each turn. Default for all keys is 'no', but this can be changed by the scenario or by special abilities (see [[AbilitiesWML]]). The Status Table displays the status of each unit using the three images '''misc/poisoned.png''', '''misc/slowed.png''' and '''misc/petrified.png'''; other keys do not appear in the Status Table.<br />
** '''poisoned''': if 'yes', the unit loses 8 HP each turn. See also ''heals'', ''cures'', [[AbilitiesWML]].<br />
** '''slowed''': if 'yes', the unit has 50% of its normal movement and does half damage. When the controller of the unit's turn is over, ''slowed'' is set to 'no'. <br />
** '''petrified''': if 'yes', the unit cannot move, attack, or be attacked.<br />
** '''uncovered''': if 'yes', the unit has performed an action (e.g. attacking) that causes it to no longer be hidden until the next turn.<br />
** '''guardian''': if 'yes', the unit will not move, except to attack something in the turn it moves (so, it only can move if an enemy unit gets within range of it). {{DevFeature1.11}} Does the same as '''ai_special = "guardian"'''.<br />
** '''unhealable''': if set to 'yes', the unit cannot be healed.<br />
** One can add other keys to [status], but they must have boolean values. For example, a scenario can set unit.status.''my_custom_key'' to 'yes' or 'no'.<br />
<br />
* '''[variables]''' a set of variables that will be stored when this unit is stored (See [store_unit], [[InternalActionsWML]]). The attribute '''variable'''='''value''' means that when the unit is stored in the array ''unit'', the variable '''unit'''.variables.''variable'' will have the value ''value'' (See [[VariablesWML]]).<br />
<br />
* '''[modifications]''' changes that have been made to the unit.<br />
** '''[trait]''' a trait the unit has. Same format as [trait], [[UnitsWML]].<br />
** '''[object]''' an object the unit has. Same format as [object], [[DirectActionsWML]].<br />
** '''[advance]''' an advancement the unit has. Same format as [advancement], [[UnitTypeWML]]. Might be used if the unit type has some advancements, but this particular one is supposed to have some of them already taken.<br />
<br />
* '''[filter_recall]''' A leader can only recall those units which pass the SUF.<br />
**'''[[StandardUnitFilter]]''' tags and keys<br />
<br />
* '''unit_description''': overrides the unit type description for this unit. You will probably want to set up a ''post_advance'' [[EventWML|event]] to override the default description after promotions. Or better, use an object with a profile [[EffectWML|effect(s)]] to filter on unit type and change the unit description and/or portrait.<br />
<br />
* '''[event]''' The event is copied from this unit's wml description into the scenario. The event is carried along with the unit (it can advance etc) and inserted into every scenario where this unit is first created. A [unit][event] requires a non-empty id= attribute.<br />
<br />
* '''[ai]''' This affects how the computer will control this unit (currently only used by [[FormulaAI]]).<br />
** '''formula''': if set, the unit will execute this code during the "unit_formulas" stage, assuming that the "unit_formulas" stage has been enabled for this side<br />
** '''priority''', '''loop_formula''', '''[vars]''': see the [[FormulaAI]] documentation for details<br />
<br />
== See Also ==<br />
<br />
* [[UnitTypeWML]]<br />
* [[ReferenceWML]]<br />
<br />
[[Category:WML Reference]]</div>Fabihttps://wiki.wesnoth.org/index.php?title=UnitTypeWML&diff=52258UnitTypeWML2013-10-27T03:55:43Z<p>Fabi: /* Other tags */</p>
<hr />
<div>{{WML Tags}}<br />
<br />
__TOC__<br />
<br />
Each '''[unit_type]''' tag defines one unit type. (for the use of [unit] to create a unit, see [[SingleUnitWML]])<br />
<br />
Unit animation syntax is described in [[AnimationWML]]. In addition to the animation tags described there, the following key/tags are recognized:<br />
* '''[advancefrom]''': Defines the previous unit type on the advancement tree. Allows a campaign-specific unit to be spliced into an already existing advancement tree. It should generally be used only inside a campaign ifdef, to prevent changes to other campaigns. This tag makes changes to the ''advances_to'' and ''experience'' keys of a base unit to make it advance into this unit. It takes these keys:<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'': (optional) If present the experience needed to advance is set to this value. If there are more than one [advancefrom] tags referencing the same base unit within the same preprocessor scope (e.g. a campaign #ifdef) with experience= keys, the lowest value of these is chosen. Note: this will also lower the experience required to advance to other units which the base unit can advance into.<br />
: If the previous unit type makes use of '''[male]''' and/or '''[female]''' tags, then the current (new) unit type is expected to also. That is, the subtypes defined by those tags will only receive this advancement if the new type has a corresponding tag.<br />
* '''advances_to''': When this unit has ''experience'' greater than or equal to ''experience'', it is replaced by a unit of the type that the value of ''advances_to'' refers to. All modifications that have been done to the unit are applied to the unit it is replaced by. The special value 'null' says that the unit does not advance but gets an AMLA instead. Can be a comma-separated list of units that can be chosen from upon advancing.<br />
* '''alignment''': one of lawful/neutral/chaotic/liminal (See [[TimeWML]]). Default is "neutral".<br />
* '''attacks''': the number of times that this unit can attack each turn.<br />
* '''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.<br />
* '''description''': (translatable) the text displayed in the unit descriptor box for this unit. Default 'No description available...'. <br />
* '''do_not_list''': Not used by the game, but by tools for browsing and listing the unit tree. If this is 'yes', the unit will be ignored by these tools. <br />
* '''ellipse''': the ellipse image to display under the unit, which is normally team-colored. Default is the normal ellipse; "misc/ellipse-nozoc" is a dashed ellipse that should be used for units without zone of control. {{DevFeature1.11}} Default is "misc/ellipse"; "-nozoc" and "-leader" are automatically appended for units without zone of control and with canrecruit=yes respectively. The [http://www.wesnoth.org/macro-reference.xhtml#IS_HERO IS_HERO]/[http://www.wesnoth.org/macro-reference.xhtml#MAKE_HERO MAKE_HERO]/[http://www.wesnoth.org/macro-reference.xhtml#UNMAKE_HERO UNMAKE_HERO] macros change the ellipse to/back from "misc/ellipse-hero".<br />
* '''experience''': When this unit has experience greater than or equal to ''experience'', it is replaced by a unit with 0 experience of the type that the value of ''advances_to'' refers to. All modifications that have been done to the unit are applied to the unit it is replaced by.<br />
* '''flag_rgb''': usually set by [http://www.wesnoth.org/macro-reference.xhtml#MAGENTA_IS_THE_TEAM_COLOR MAGENTA_IS_THE_TEAM_COLOR]; specifies the colours in the base flag to use for team-colouring the unit, expressed as a colour name (such as magenta) or a comma-separated list of RGB values (in hex format).<br />
* '''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.<br />
* '''hide_help''': determines if the unit type will appear in the in-game help. Possible values ''true'' and ''false'', defaults to ''false''.<br />
* '''hitpoints''': the maximum HP that the unit has, and the HP it has when it is created.<br />
* '''id''': the value of the ''type'' key for units of this type. This is required and must be unique among all [unit_type] tags. An ''id'' should consist only of alphanumerics and spaces (or underscores). ''type'' keys are found in [[SingleUnitWML]] and [[FilterWML]]. For example, id=Drake Flare<br />
::WARNING : characters "$", "&", "*", "-", "(" and ")" are illegal for use in the unit type id and must be avoided because they might lead to corrupted saved games<br />
*'''ignore_race_traits''': 'yes' or 'no' (default). Determines whether racial traits (see [[UnitsWML]]) are applied. <br />
* '''image''': sets the base image of the unit, which is used on the map.<br />
* '''image_icon''': sets the image used to represent the unit in areas such as the attack dialog and the unit image box in the sidebar<br />
* '''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]]).<br />
* '''movement''': the number of move points that this unit receives each turn.<br />
* '''movement_type''': See [[UnitsWML#.5Bmovetype.5D|movetype]]. Note that the tags '''[movement_costs]''', '''[vision_costs]''', '''[defense]''', and '''[resistance]''' can be used to modify this movetype.<br />
* '''name''':(translatable) displayed in the Status Table for units of this type.<br />
* '''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.<br />
* '''profile''': the portrait image to use for this unit type. You can also set a portrait for an individual unit instead of the whole unit type (see [[SingleUnitWML]]). The engine first looks for the image in the transparent subdirectory and if found that image is used. If not found it will use the image as-is. Depending on the size the engine will or will not scale the image, the cutoff currently is at 300x300. For images which should only be shown on the right side in the dialog append ~RIGHT() to the image.<br />
* '''small_profile''': the image to use when a smaller portrait is needed than the one used for messages (e.g., in the help system). When this attribute is missing, the value of the '''profile''' attribute is used instead. When present, the heuristic for finding a transparent portrait is disabled for the '''profile''' attribute, so the correct '''profile''' should be set too. Note that image modifiers are allowed; they might be useful for cropping and rescaling a portrait:<br />
small_profile="portraits/elves/transparent/marksman+female.png~CROP(0,20,380,380)~SCALE(205,205)"<br />
profile="portraits/elves/transparent/marksman+female.png"<br />
* '''race''': See {{tag|UnitsWML|race}}. Also used in standard unit filter (see [[FilterWML]]).<br />
* '''undead_variation''': When a unit of this type is killed by a weapon with the plague special, this variation is applied to the new plague unit that is created, whatever its type. For example, if the plague special creates Walking Corpses and undead_variation is set to "troll", you'll get a troll Walking Corpse. Defaults to the undead_variation set in this unit type's race.<br />
* '''usage''': the way that the AI should recruit this unit, as determined by the scenario designer. (See ''recruitment_pattern'', [[AiWML]]). The following are conventions on usage:<br> ** ''scout'': Fast, mobile unit meant for exploration and village grabbing.<br> ** ''fighter'': Melee fighter, melee attack substantially more powerful than ranged.<br> ** ''archer'': Ranged fighter, ranged attack substantially more powerful than melee.<br> ** ''mixed fighter'': Melee and ranged fighter, melee and ranged attacks roughly equal.<br> ** ''healer'': Specialty 'heals' or 'cures'.<br>Note that this field primarily affects recruitment. It also has a small effect on unit movement (the AI tries to keep scouts away from enemies, to some extent). It does not affect the AI's behavior in combat; that is always computed from attack power and hitpoints. Non-standard usages may be used as well.<br />
* '''vision''': the number of vision points to calculate the unit's sight range. Defaults to ''movement'' if not present.{{DevFeature1.11}}<br />
* '''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).<br />
* '''die_sound''': sets the sound, which is used when the unit dies.<br />
<br />
== After max level advancement (AMLA) ==<br />
* '''[advancement]''': describes what happens to a unit when it reaches the XP required for advancement. It is considered as an advancement in the same way as advancement described by '''advances_to'''; however, if the player chooses this advancement, the unit will have one or more effects applied to it instead of advancing.<br />
** '''id''': unique identifier for this advancement; ''Required'' if there are multiple advancement options, or if ''strict_amla=no''.<br />
** '''always_display''': if set to true displays the AMLA option even if it is the only available one.<br />
** '''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.<br />
** '''image''': an image to display next to the description in the advancement menu.<br />
** '''max_times''': default 1. The maximum times the unit can be awarded this advancement. Pass -1 for "unlimited".<br />
** '''strict_amla''': (yes|no) default=no. Disable the AMLA if the unit can advance to another unit.<br />
** '''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.<br />
*** example: <tt>require_amla=tough,tough,incr_damage</tt> assumes there exist other [advancement] options called ''id=tough'' and ''id=incr_damage''. Once ''tough'' is chosen twice and ''incr_damage'' is chosen once, then the current [advancement] will become available.<br />
*** ''require_amla=tough,incr_damage,tough'' is an equivalent way of expressing this.<br />
** '''[effect]''': A modification applied to the unit whenever this advancement is chosen. See [[EffectWML]]<br />
<br />
== Attacks ==<br />
* '''[attack]''': one of the unit's attacks.<br />
** '''description''': a translatable text for name of the attack, to be displayed to the user.<br />
** '''name''': the name of the attack. Used as a default description, if ''description'' is not present, and to determine the default icon, if ''icon'' is not present (if ''name=x'' then ''icon=attacks/x.png'' is assumed unless present). Non-translatable. Used for the ''has_weapon'' key and animation filters; see [[StandardUnitFilter]] and [[AnimationWML]]<br />
** '''type''': the damage type of the attack. Used in determining resistance to this attack (see {{tag|UnitsWML|movetype|resistance}}).<br />
** '''[specials]''': contains the specials of the attack. See [[AbilitiesWML#The_.5Bspecials.5D_tag|AbilitiesWML]].<br />
** '''icon''': the image to use as an icon for the attack in the attack choice menu, as a path relative to the images directory.<br />
** '''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.<br />
** '''damage''': the damage of this attack<br />
** '''number''': the number of strikes per attack this weapon has<br />
** '''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.<br />
** '''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<br />
** '''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 <br />
For the weight settings, the engine usually chooses the attack with the best average total damages * weight (default weight = 1.0).<br />
<br />
== Other tags ==<br />
* '''[base_unit]''': Contains one attribute, '''id''', which must be the ID of a unit type. If specified, the UnitTypeWML for that unit is copied into this one. Attributes in this unit overwrite the copy. Tags modify the corresponding tag of the original, so for example the first '''[attack]''' tag in the derived unit would modify the first attack of the base unit rather than defining a new attack.<br />
<br />
* '''[portrait]''': Describes a unit portrait for dialogue. However, generally you should use the profile key instead; [portrait] is mostly for internal use.<br />
** '''size''': The size of the portrait, in pixels.<br />
** '''side''': One of left or right.<br />
** '''mirror''': Whether to flip the image horizontally.<br />
** '''image''': The image path.<br />
<br />
* '''[abilities]''': Defines the abilities of a unit. See [[AbilitiesWML]]<br />
<br />
* '''[event]''': Any [event] written inside the [unit_type] tag will get included into any scenario where a unit of this type appears in. Note that such events get included when a unit of this type first appears in the scenario, not automatically when the scenario begins (meaning that ''name=prestart'' events, for example, would usually never trigger). See [[EventWML]] and [[WML_Abilities]]<br />
<br />
* '''[variation]''': Defines a variation of a unit. Variations are invoked with an [effect] tag or the variation= attribute in [[SingleUnitWML]]. They are currently used for graphical variations (giving character sprites new weapons) but theoretically you could do anything with it.<br />
** {{DevFeature1.11}} '''variation_id''': The id of this variation. Defaults to ''variation_name''.<br />
** '''variation_name''': The name of the variation. Since {{DevFeature1.11}} is this attribute translatable.<br />
** '''inherit''': if ''yes'', inherits all the properties of the base unit, which are then overwritten by the keys and tags of this variation. Defaults to no.<br />
*** {{DevFeature1.11}} The '''id''' key is always inherited, regardless of the value of '''inherit'''.<br />
** All keys and tags of '''[unit_type]''', except ''[advancefrom]'', ''[base_unit]'', ''[female]'', ''[male]'', and ''[variation]''. A special case is the '''id''' key, for which support is incomplete. If '''id''' is set for a variation, then it applies when filtering existing units (including the breakdown of units in the "damage versus" tooltip), but it cannot be used to create a new unit. For reliable behavior, '''id''' should match the parent type's id. {{DevFeature1.11}} Changing the id for a variation is fully supported starting in 1.11.2.<br />
<br />
* '''[male]''', '''[female]''': These can specify a variation based on gender for a unit. If these are provided, they will automatically apply based upon the gender of a unit.<br />
** '''inherit''': if ''yes'', inherits all the properties of the base unit. Defaults to yes.<br />
*** {{DevFeature1.11}} The '''id''' key is always inherited, regardless of the value of '''inherit'''.<br />
** All '''[unit_type]''' tags and keys, excluding ''[advancefrom]'', ''[base_unit]'', ''[female]'', and ''[male]''. A special case is the '''id''' key, for which support is incomplete. If '''id''' is set for a variation, then it applies when filtering existing units (including the breakdown of units in the "damage versus" tooltip), but it cannot be used to create a new unit. For reliable behavior, '''id''' should match the parent type's id. {{DevFeature1.11}} Changing the id for a variation is fully supported starting in 1.11.2.<br />
<br />
== See Also ==<br />
<br />
* [[AnimationWML]]<br />
* [[ReferenceWML]]<br />
* [[TerrainWML]]<br />
<br />
[[Category: WML Reference]]</div>Fabihttps://wiki.wesnoth.org/index.php?title=AbilitiesWML&diff=52133AbilitiesWML2013-09-27T03:02:52Z<p>Fabi: Added disable weapon special</p>
<hr />
<div>{{WML Tags}}<br />
== Abilities and their effects ==<br />
<br />
There are two types of abilities: ones that apply to units (called ''abilities'') and ones that only apply when using a particular attack (called ''specials'' or ''weapon specials''). A unit may have multiple abilities and an attack can have multiple specials, but by convention only one weapon special should be assigned to any given attack.<br />
<br />
== The ''[abilities]'' tag ==<br />
<br />
The following tags are used to describe an ability in WML:<br />
<br />
* '''[heals]''': modifies the hitpoints of a unit at the beginning of the healer's turn<br />
* '''[regenerate]''': modifies the hitpoints of a unit at the beginning of the unit's turn<br />
* '''[resistance]''': modifies the resistance of a unit to damage<br />
* '''[leadership]''': modifies the damage of a unit<br />
* '''[skirmisher]''': negates enemy zones of control<br />
* '''[illuminates]''': modifies the time of day adjacent to the affected units<br />
* '''[teleport]''': allows the unit to teleport<br />
* '''[hides]''': renders the unit invisible to enemies<br />
Any other name is valid (for example '''[dummy]'''), but will result in an ability that does nothing but report it's there. These tags still use the same common keys and tags as every other ability. '''Note:''' a dummy ability must have an id for the name and description to display.<br />
<br />
=== Common keys and tags for every ability ===<br />
<br />
* '''name''': the (translatable) name of the ability.<br />
* '''female_name''': the (translatable) name of the ability when possessed by a female unit. Defaults to ''name'' if not specified.<br />
* '''name_inactive''': the (translatable) name of the ability when inactive. {{DevFeature1.11}} Defaults to ''name'' if not specified; if the ability is supposed to be not displayed when inactive, you must explicitly set ''name_inactive'' to an empty string (nothing after the equals sign).<br />
* '''female_name_inactive''': the (translatable) name of the ability when inactive and possessed by a female unit. Defaults to ''name_inactive'' if not specified.<br />
* '''description''': the (translatable) description of the ability.<br />
* '''description_inactive''': the (translatable) description of the ability when inactive. {{DevFeature1.11}} Defaults to ''description'' if not specified.<br />
* '''affect_self''': if equal to 'yes', the ability will affect the unit that has it.<br />
* '''affect_allies''': if equal to 'yes', the ability will affect allies in the specified adjacent hexes.<br />
* '''affect_enemies''': if equal to 'yes', the ability will affect enemies in the specified adjacent hexes.<br />
* '''cumulative''': if set to 'yes', this ability will be cumulative with the base value for this ability.<br />
* '''id''': this ability will not be cumulative with other abilities using this id. Must be present if cumulative is anything other than 'yes'.<br />
* '''[filter]''': [[StandardUnitFilter]] If the unit owning the ability does not match this filter, the ability will be inactive.<br />
* '''[affect_adjacent]''': an adjacent unit that does not match this filter will not receive its effects. There can be multiple [affect_adjacent] tags in a single ability; a unit needs to match any one of these to receive the effects. If there are no [affect_adjacent] tags, then no adjacent units will receive the effects.<br />
** '''adjacent''': a comma separated list of any combination of these directions: '''n''','''ne''','''se''','''s''','''sw''','''nw'''.<br />
** '''[filter]''': a [[StandardUnitFilter]].<br />
* '''[filter_self]''': if the owner of the ability does not match this filter, it will not receive the effects of the ability. [filter_self] takes a [[StandardUnitFilter]] as argument.<br />
* '''[filter_base_value]''': filters on the value before any modifications; uses the keys '''equals''', '''not_equals''', etc. If several keys are used all have to match.<br />
<br />
=== Extra keys used by the ''[heals]'' ability ===<br />
<br />
* '''value''': the amount healed.<br />
* '''poison''': can be one of ''slowed'',''cured''.<br />
<br />
=== Extra keys used by the ''[regenerate]'' ability ===<br />
<br />
* '''value''': the amount healed.<br />
* '''poison''': can be one of ''slowed'',''cured''.<br />
<br />
=== Extra keys and tags used by the ''[resistance]'' ability ===<br />
<br />
* '''value''': set resistance to this value.<br />
* '''max_value''': maximum resistance value. This value '''must''' be set in order for [resistance] to function.<br />
* '''add''': adds to resistance.<br />
* '''sub''': subtracts from resistance.<br />
* '''multiply''': multiplies resistance value. <br />
* '''divide''': divides resistance value.<br />
* '''apply_to''': a list of damage types; if left out, the ability applies to all types.<br />
* '''active_on''': one of 'defense' or 'offense'; if left out, the ability is active on both.<br />
<br />
=== Extra keys used by the ''[leadership]'' ability ===<br />
<br />
* '''value''': the percentage bonus to damage.<br />
<br />
=== Extra keys used by the ''[illuminates]'' ability ===<br />
<br />
* '''value''': the percentage bonus to lawful units.<br />
* '''max_value''': the maximum percentage bonus given.<br />
* '''min_value''': the minimum percentage bonus given.<br />
<br />
=== Extra keys used by the ''[hides]'' ability ===<br />
<br />
* '''alert''': the displayed text when the unit is discovered. Default "Ambushed!".<br />
<br />
=== Extra tags used by the ''[teleport]'' ability ===<br />
<br />
* '''[tunnel]''' - a tunnel tag (see [[DirectActionsWML]]) (without the remove key) defining the tunneling source and target hexes, and maybe other conditions. (It automatically applies only to the unit with the ability.) You may use $teleport_unit inside the tunnel tag for filtering purposes.<br />
<br />
=== Macros for common abilities ===<br />
<br />
* ABILITY_AMBUSH<br />
* ABILITY_CURES<br />
* ABILITY_HEALS<br />
* ABILITY_ILLUMINATES<br />
* ABILITY_LEADERSHIP_LEVEL_1 to ABILITY_LEADERSHIP_LEVEL_5<br />
* ABILITY_NIGHTSTALK<br />
* ABILITY_REGENERATES<br />
* ABILITY_SKIRMISHER<br />
* ABILITY_STEADFAST<br />
* ABILITY_SUBMERGE<br />
* ABILITY_TELEPORT<br />
<br />
== The ''[specials]'' tag ==<br />
<br />
The '''[specials]''' tag goes inside the '''[attack]''' tag. It can contain the following tags:<br />
<br />
* '''[attacks]''': modifies the number of attacks of a weapon<br />
* '''[berserk]''': pushes the attack for more than one combat round<br />
* '''[chance_to_hit]''': modifies the chance to hit of a weapon<br />
* '''[damage]''': modifies the damage of a weapon<br />
* '''[disable]''': disables the weapon {{DevFeature1.11}}<br />
* '''[drains]''': heals the attacker half of the damage dealt<br />
* '''[firststrike]''': forces the weapon to always strike first<br />
* '''[heal_on_hit]''': heals the attacker when an attack connects {{DevFeature1.11}}<br />
* '''[petrifies]''': turns the target to stone<br />
* '''[plague]''': when used to kill an enemy, a friendly unit takes its place<br />
* '''[poison]''': poisons the target<br />
* '''[slow]''': slows the target<br />
* '''[swarm]''': number of strikes decreases as the unit loses hitpoints<br />
Any other name is valid, but will result in an special that does nothing but report it is there.<br />
<br />
=== Common keys and tags for every weapon special ===<br />
<br />
* '''name''': the (translatable) name of the special.<br />
* '''name_inactive''': the (translatable) name of the special when inactive. {{DevFeature1.11}} Defaults to ''name'' if not specified; if the special is supposed to be not displayed when inactive, you must explicitly set ''name_inactive'' to an empty string (nothing after the equals sign).<br />
* '''description''': the (translatable) description of the special.<br />
* '''description_inactive''': the (translatable) description of the special when inactive. {{DevFeature1.11}} Defaults to ''description'' if not specified.<br />
* '''id''': this ability will not be cumulative with other specials using this id.<br />
* '''active_on''': one of '''defense''' or '''offense'''; if left out, the special is active on both.<br />
* '''apply_to''': one of '''self''','''opponent''','''attacker''','''defender''','''both''' (default: ''self''). Determines who the effects of this special are applied to.<br />
* '''[filter_adjacent]''': [[StandardUnitFilter]], which takes an extra key '''adjacent''', which is used to specify which adjacent hexes to filter on. '''adjacent''' is a comma-separated list of any combination of these directions: '''n''','''ne''','''se''','''s''','''sw''','''nw'''. If there is not a matching unit in each of the specified directions, then the special is inactive. Multiple [filter_adjacent] tags can be provided, and each must pass for the special to be active.<br />
* '''[filter_adjacent_location]''': like [filter_adjacent], except that it filters on the locations rather than the units.<br />
* '''[filter_self]''': the special will only be active if the owner matches this [[StandardUnitFilter]] (SUF).<br />
** '''[filter_weapon]''': a [[FilterWML#Filtering_Weapons|standard weapon filter]], excluding special= ({{DevFeature1.11}} including special=).<br />
* '''[filter_opponent]''': the special will only be active if the opponent matches this SUF.<br />
** '''[filter_weapon]''': a standard weapon filter, excluding special= ({{DevFeature1.11}} including special=)..<br />
* '''[filter_attacker]''': the special will only be active if the attacker matches this SUF.<br />
** '''[filter_weapon]''': a standard weapon filter, excluding special= ({{DevFeature1.11}} including special=)..<br />
* '''[filter_defender]''' the special will only be active if the defender matches this SUF.<br />
** '''[filter_weapon]''': a standard weapon filter, excluding special= ({{DevFeature1.11}} including special=)..<br />
<br />
=== Common keys and tags for specials with a value ===<br />
<br />
The '''[damage]''', '''[attacks]''', and '''[chance_to_hit]''' specials take values that specify how those specials modify their respective base values. {{DevFeature1.11}} The '''[drains]''' special takes a value specifying the percentage of damage drained (default 50) and '''[heal_on_hit]''' takes the amount to heal (default 0; negative values will harm the attacker, but not kill).<br />
<br />
* '''value''': the value to be used.<br />
* '''add''': the number to add to the base value.<br />
* '''sub''': the number to subtract from the base value.<br />
* '''multiply''': this multiplies the base value.<br />
* '''divide''': this divides the base value.<br />
* '''cumulative''': if set to 'yes', this special will be cumulative with the base value.<br />
* '''backstab''': if set to 'yes', this special will only apply to the attacker, and only when there is an enemy on the target's opposite side (i.e. when the standard backstab special applies).<br />
* '''[filter_base_value]''': filters on the value before any modifications; uses the keys '''equals''', '''not_equals''', etc.<br />
<br />
=== Extra keys used by the ''[berserk]'' special ===<br />
<br />
* '''value''': the maximum number of combat rounds (default 1).<br />
* '''cumulative''': if set to 'yes', this special will be cumulative with other active berserk specials (on the current combatant, not with an opponent's berserk).<br />
<br />
=== Extra keys used by the ''[plague]'' special ===<br />
<br />
* '''type''': the unit type to be spawned on kill.<br />
<br />
=== Extra keys used by the ''[swarm]'' special ===<br />
<br />
* '''swarm_attacks_max''': the maximum number of attacks for the swarm. Defaults to the base number of attacks. (In {{DevFeature1.11}}, defaults to the base number of attacks modified by any applicable [attacks] specials.) If this is specified, then the base number of attacks is ignored.<br />
* '''swarm_attacks_min''': the minimum number of attacks for the swarm. Defaults to zero. {{DevFeature1.11}} This can be set higher than swarm_attacks_max to cause a unit to gain attacks as health decreases.<br />
The ratio of the unit's current to maximum hit points will be used to scale the number of attacks between these two values.<br />
<br />
Prior to version 1.11, a [swarm] special will cause [attacks] specials to be ignored. In 1.11 and later, [attacks] specials are applied before [swarm].<br />
<br />
=== Macros for common weapon specials ===<br />
<br />
* WEAPON_SPECIAL_BACKSTAB<br />
* WEAPON_SPECIAL_BERSERK<br />
* WEAPON_SPECIAL_CHARGE<br />
* WEAPON_SPECIAL_DRAIN<br />
* WEAPON_SPECIAL_FIRSTSTRIKE<br />
* WEAPON_SPECIAL_MAGICAL<br />
* WEAPON_SPECIAL_MARKSMAN<br />
* WEAPON_SPECIAL_PLAGUE<br />
* WEAPON_SPECIAL_PLAGUE_TYPE TYPE<br />
* WEAPON_SPECIAL_POISON<br />
* WEAPON_SPECIAL_SLOW<br />
* WEAPON_SPECIAL_STONE<br />
* WEAPON_SPECIAL_SWARM<br />
<br />
== See Also ==<br />
<br />
* [[UnitTypeWML]]<br />
* [[SingleUnitWML]]<br />
* [[ReferenceWML]]<br />
<br />
[[Category:WML Reference]]</div>Fabihttps://wiki.wesnoth.org/index.php?title=AnimationWML&diff=51865AnimationWML2013-09-06T08:30:07Z<p>Fabi: Fixed animation timings to 200, see commit 13dfeb7e5232455f70ff2dbd169b7262fab50ab7</p>
<hr />
<div>{{WML Tags}}<br />
<br />
== Introduction ==<br />
<br />
This page covers unit animations. At any point in game, units are playing an animation. Even when the unit is standing, it is actually playing a single frame animation.<br />
<br />
This page will deal with the two problems of animations<br />
* How are animations chosen<br />
* What exactly is drawn<br />
<br />
<br />
<br />
== How animations are drawn ==<br />
=== Animations ===<br />
Any unit has a huge set of animations to choose from. Animations are WML blocks in the unit type, enclosed in either the generic type '''[animation]''' or some more specific tags such as '''[attack_anim]''' '''[idle_anim]''' and the like. An animation is what a unit displays when a given event is triggered, and a certain set of conditions are met such as<br />
* unit is attacking<br />
* unit is idling<br />
* unit is attacking (event) and uses a melee weapon (condition)<br />
* unit is attacking (event) and uses a melee weapon (condition) and opponent can't retaliate (condition)<br />
<br />
events and conditions are described entirely in the [animation] block, and will be discussed in the animation choice section.<br />
<br />
=== Frames ===<br />
<br />
An animation is cut in frames. Frames are WML blocks that are contained either in '''[frame]''' WML blocks or in generic '''[xxx_frame]''' block. (the xxx part can be any string not starting with an underscore) the xxx part in the frame name is called the frame prefix. frames of the type '''[frame]''' are said to have an empty prefix<br />
<br />
A frame typically describes an image, where an how to render it. It can contain such things as<br />
* the image to display<br />
* how transparent should that image be<br />
* where to draw that image.<br />
<br />
At any given time, an animation will display one frame for each frame prefix it can find. I.e if your animation has both '''[frame]''' and '''[missile_frame]''' blocks, both will be displayed at the same time<br />
<br />
<br />
The frame with the empty prefix is special in many way. It is assumed to contain the image representing the unit itself, and as such the engine will heavily temper with it in multiple ways, such as providing a default image if none is available, or forcing the image to be green when the unit is poisoned<br />
<br />
=== Timing, Clock, Multiple animations ===<br />
When an animation is played it has an internal clock that is run. The step of this clock is the milisecond, and each frame is played for a given duration. Each animation also has a starting time which tells the animation engine at what value the animation clock should start<br />
<br />
This starting time is very important when multiple animations from different units are played synchronously Typically a fight involves a unit playing its defense animation while the opponent plays its attack animation (and a third might play its leading animation, too). In that case all animations have a common clock, and are played concurrently.<br />
<br />
The convention is that the "important time" (usually the time of the hit) is at time 0. everything before should be at negative time, everything after at positive time. This is a WML convention that is not enforced by the engine<br />
<br />
In that case, it is very important that these animations (which can have different lengths) be synchronized. Fight animations are synchronized around the point of impact, so they all reach time 0 when the attack lands (or misses). This is accomplished through the use of the '''start_time''' key of the '''[animation]''' tag.<br />
<br />
Just like the '''[frame]''' tag can have a prefix, so can the '''start_time''' key. A '''start_time''' key without prefix will affect a '''[frame]''' tag without prefix, while a '''start_time''' key with a prefix will affect a '''[frame]''' tag with the same prefix.<br />
<br />
==== Example Syntax ====<br />
[attack_anim]<br />
[filter_attack]<br />
name=bow<br />
[/filter_attack]<br />
'''start_time'''=-350<br />
'''missile_start_time'''=-200<br />
[missile_frame]<br />
duration=200<br />
image="projectiles/missile-n.png"<br />
image_diagonal="projectiles/missile-ne.png"<br />
[/missile_frame]<br />
[if]<br />
hits=yes<br />
[frame]<br />
sound=bow.ogg<br />
[/frame]<br />
[/if]<br />
[else]<br />
hits=no<br />
[frame]<br />
sound=bow-miss.ogg<br />
[/frame]<br />
[/else]<br />
[/attack_anim]<br />
<br />
=== The content of a frame ===<br />
==== Syntax summary ====<br />
[frame]<br />
duration=<integer><br />
begin=<deprecated,integer><br />
end=<deprecated,integer><br />
image=<string, dev feature 1.11.2 - progressive string><br />
image_diagonal=<string, dev feature 1.11.2 - progressive string><br />
image_mod=<string><br />
sound=<string><br />
halo=<progressive string><br />
halo_x=<progressive int><br />
halo_y=<progressive int><br />
halo_mod=<string><br />
alpha=<progressive float><br />
offset=<progressive float><br />
blend_color=<red, green, blue><br />
blend_ratio=<progressive float><br />
text=<string><br />
text_color=< red, green, blue ><br />
submerge=<progressive float><br />
x=<progressive int><br />
y=<progressive int><br />
directional_x=<progressive int><br />
directional_y=<progressive int><br />
layer=<progressive int><br />
auto_hflip=<boolean><br />
auto_vflip=<boolean><br />
primary=<boolean><br />
[/frame]<br />
<br />
==== Progressive parameters ====<br />
<br />
Some parameters above are marked as ''progressive'' This means that you can specify that during the time the frame is displayed, the parameter should smoothly slide from one value to an other.<br />
<br />
A typical example would be a unit progressively fading out, becoming transparent<br />
<br />
To do that, you could use:<br />
<br />
alpha=1~0<br />
<br />
To make a frame, which is 900ms long, slide to transparent for 300ms, stay transparent for another 300ms and finally fade back to normal for 300ms, use:<br />
<br />
alpha=1~0:300,0:300,0~1:300<br />
<br />
you could also specify it like that<br />
<br />
alpha=1~0,0,0~1<br />
<br />
when a timing is missing, the engine will do its best to fill in in a fair way. <br />
<br />
a progressive string has an expanded syntax:<br />
<br />
image=image1.png:100,image2.png:100,image3.png:100<br />
halo=halo1.png:100,halo2.png:200,halo3.png:300<br />
<br />
or (from Wesnoth 1.11.2+) equivalently,<br />
image=image[1~3]:100<br />
halo=halo[1~3]:[100,200,300]<br />
<br />
for convenience, the square bracket expansion works like so:<br />
halo=halo[3,5,7].png is equivalent to halo=halo3.png,halo5.png,halo7.png<br />
halo=halo[07~10].png is equivalent to halo=halo07.png,halo08.png,halo09.png,halo10.png<br />
halo=halo[5~3,1].png is equivalent to halo=halo5.png,halo4.png,halo3.png,halo1.png<br />
image=image[1~2]-ex[4~5].png:[100,200] is equivalent to image=image1-ex4.png:100,image2-ex5:200.png<br />
image=image[1~4].png:[10,20*3] is equivalent to image1.png:10,image2.png:20,image3.png:20,image4.png:20<br />
<br />
==== Field Description ====<br />
<br />
** '''begin''': (deprecated) will be replaced by '''duration= <end - begin >'''<br />
** '''end''': (deprecated) see '''begin''' and also [[AnimationWML#Timing.2C_Clock.2C_Multiple_animations|Timing, Clock, Multiple animations]] section for coverage of '''start_time''' which combines with '''duration''' to replace '''begin=''' '''end='''.<br />
** '''duration''': how long the frame should be displayed. Use instead of '''begin=''' and '''end='''. If specified by timing in a progressive string, such as a halo, this can be left out and will be automatically calculated.<br />
** '''image''': the image, or sequence of images, to display during the frame.<br />
** '''image_diagonal''': the image, or sequence of images, to display when the attack occurs diagonally (directions ne,se,sw,nw).<br />
** '''image_mod''': a string modifications (see [[ImagePathFunctionWML]] ) that will be applied to all images<br />
** '''sound''': the sound to play when the frame begins. Can be a comma-separated list of sounds, in which case one of them is chosen randomly every time.<br />
** '''halo''': the halo to display at the time.<br />
** '''halo_x''': the position the halo is displayed in pixel relative to the unit's center.<br />
** '''halo_y''': the position the halo is displayed in pixel relative to the unit's center.<br />
** '''halo_mod''': a string modifications (see [[ImagePathFunctionWML]] ) that will be applied to all haloes<br />
** '''alpha''': transparency level to apply to the frame. This is a floating point progressive parameter ranging from 0.0 to 1.0.<br />
** '''offset''': the position of the image relative to the hex the unit is facing, 0.0 will display the unit in the center of the hex, 1.0 in the center of the faced hex, -1.0 at the center of the hex behind you. This is a progressive parameter.<br />
** '''blend_color''': a comma separated list of numbers representing a color in RGB (0-255); this color will be mixed to the frame to give it a tint.<br />
** '''blend_ratio''': this is a progressive parameter ranging from 0 to 1: 0 means no tint, 1 means target color only.<br />
** '''text''': if specified, floats a label with the given text above the unit (identical to the floating damage and healing numbers).<br />
** '''text_color''': the color of the above floating label.<br />
** '''submerge''': the part of the unit that should drawn with 50% opacity (for units in water)<br />
** '''x''': x offset applied to the frame<br />
** '''y''': y offset applied to the frame<br />
** '''directional_x''': the x offset, in pixels, applied to the frame in the direction the unit is facing<br />
** '''directional_y''': the y offset, in pixels, applied to the frame in the direction the unit is facing<br />
** '''layer''': layer used to draw the frame, see discussion bellow<br />
** '''auto_hflip''': should the image flip horizontally depending on sprite orientation<br />
** '''auto_vflip''': should the image flip vertically depending on sprite orientation<br />
** '''primary''': should the engine consider that frame as a primary frame (affected by visual effects like stone and poison)<br />
<br />
=== Drawing related animation content ===<br />
==== Syntax summary ====<br />
[animation]<br />
<animation choice related content><br />
[frame]<br />
<frame content><br />
[/frame]<br />
[frame]<br />
<frame content><br />
[/frame]<br />
start_time=<integer><br />
offset=<progressive float><br />
image_mod=<string><br />
blend_color=<r,g,b><br />
blend_ratio=<progressive float><br />
halo=<progressive_string><br />
halo_x=<progressive int><br />
halo_y=<progressive int><br />
halo_mod=<string><br />
submerge=<progressive float><br />
x=<progressive int><br />
y=<progressive int><br />
directional_x=<progressive int><br />
directional_y=<progressive int><br />
layer=<progressive int><br />
<br />
[xxx_frame]<br />
<frame content><br />
[/xxx_frame]<br />
xxx_start_time=<integer><br />
xxx_image_mod=<string><br />
xxx_offset=<progressive float><br />
xxx_blend_color=<r,g,b><br />
xxx_blend_ratio=<progressive float><br />
xxx_halo=<progressive_string><br />
xxx_halo_x=<progressive int><br />
xxx_halo_y=<progressive int><br />
xxx_halo_mod=<string><br />
xxx_submerge=<progressive float><br />
xxx_x=<progressive int><br />
xxx_y=<progressive int><br />
xxx_directional_x=<progressive int><br />
xxx_directional_y=<progressive int><br />
xxx_layer=<progressive int><br />
<br />
[/animation]<br />
<br />
==== Parameter handling ====<br />
All drawing related parameters in '''[animation]''' can be matched with a corresponding parameter in a '''[frame]''' block (or a '''[xxx_frame]''' block) The value provided in the animation will be used if no value is provided in the frame. <br />
<br />
The point of these two level of parameters is to easily be able to specify a parameter at the animation level and override it for a special case of frame.<br />
<br />
== How animations are chosen ==<br />
Within a unit description block there are multiple animations. Each animation is meant to be played in a very special set of circumstances. We will discuss here how to tell the animation engine when a given animation should be played. <br />
<br />
Let's take an example. Suppose we have a unit which has the skirmisher ability. We have the following movement animations :<br />
* a normal walking animation<br />
* a swimming animation when the unit is in water<br />
* a tiptoeing animation when moving next to an enemy unit<br />
<br />
Ok. most of the time it's easy to guess what animation should be. However if you are both in water and next to an enemy unit, the animation to play is not obvious.<br />
<br />
To solve that question, each animation has a number of filtering criteria. The engine follow the following rules to select an animation<br />
* Start with all animations<br />
* Drop all animations with a criteria that fails on the current situation<br />
* Take the animations that have the most matching criteria<br />
* If there are more than one animation remaining, take an animation randomly<br />
* If all animations have been dropped, the engine will provide a smart default.<br />
<br />
here is a pseudo-code explanation of this algorithm:<br />
<br />
foreach animation<br />
animation_score = 0<br />
foreach filter-criteria<br />
if <criteria-fails> <br />
animation_score = -1;<br />
break;<br />
elsif <criteria-matches> <br />
animation_score++<br />
endfor<br />
if animation_score > max_score<br />
<empty animation list><br />
max_score = animation_score;<br />
push(animation,animation_list);<br />
elsif animation_score = max_score<br />
push(animation,animation_list);<br />
endfor<br />
<choose an animation randomly from animation_list><br />
<br />
<br />
Note that all animations don't have all the filters...<br />
<br />
so, if we have a unit with<br />
# an animation for water terrain<br />
# an animation for SE on grassland<br />
# an animation with no criteria<br />
# an animation for N,NE,NW,S,SW,SE<br />
# an animation for NW<br />
<br />
* 3. will never be taken, because 4. will always trump it<br />
* on water going NW, it can be 1. 4. 5.<br />
* on water, any direction but NW, it will be 1. or 4.<br />
* on SE grassland it will be 2.<br />
* on other grasslands, it will be 4. (4. or 5. if NW)<br />
<br />
=== Generic animation filters available for all animations ===<br />
* '''apply_to''': a list of comma separated keywords describing what event should trigger the animation (movement, attack...) the complete list is given below<br />
* '''value''': a list of comma separated integer, the meaning depends on the triggering event. the meaning is given with the list of event<br />
* '''value_second''': a list of comma separated integer, the meaning depends on the triggering event. the meaning is given with the list of event<br />
* '''terrain''': a list of comma separated terrain letters, the animation will only be used on these terrains. See [[FilterWML#Filtering Terrains|Filtering Terrains]]. this has been replaced by '''terrain_type'''<br />
* '''terrain_type''': a list of comma separated terrain codes, the animation will only be used on matching terrains. See [[FilterWML#Filtering Terrains|Filtering Terrains]].<br />
* '''[filter]''': this will filter using a [[StandardUnitFilter|standard unit filter]] on the animated unit. Note that matching all criterias in the filter will only earn you one point for animation selection, but that you can have multiple '''[filter]''' blocks in an animation.<br />
* '''[filter_second]''': this will filter using a [[StandardUnitFilter|standard unit filter]] on the unit in the hex faced. Note that matching all criteria in the filter will only earn you one point for animation selection, but that you can have multiple '''[filter_second]''' blocks in an animation. Also note that if the faced hex is empty, the whole filter will fail.<br />
* '''direction''': a list of directions (n,ne,se,s,sw,nw), the animation will only be used when acting or moving in this direction (the attack direction for attack animations, moving direction for movement animations, direction of lead unit for leading animations, and so on).<br />
* '''frequency''': this integer value allows to easily tweak the matching frequency of animations. The filter will fail n-1 times out of n, randomly. Note that unlike every other filter, matching this filter won't give an extra point.<br />
* '''[filter_attack]''': a standard attack filter to match on the attacker's attack. See [[FilterWML#Filtering Weapons|Filtering Weapons]]. <br />
* '''[filter_second_attack]''': a standard attack filter to match on the defender's attack. See [[FilterWML#Filtering Weapons|Filtering Weapons]]. Also note that if the defender doesn't have any weapon to retaliate with, this filter will always fail. <br />
* '''hits''': filters attack animations based on whether the attack hits, misses or kills. Accepts a list of the following:<br />
** '''hit''': the attack hits, defender survives.<br />
** '''no''' or '''miss''': the attack misses.<br />
** '''kill''': the attack hits, defender dies.<br />
** '''yes''': is an alias of '''hit,kill'''.<br />
* '''swing''': a list of numbers representing the swing numbers this animation should match (numbered from 1). this has been replaced by value_second<br />
* '''base_score''': a number that will always be added to the score. Use with caution<br />
<br />
=== Events triggering animations and default animations ===<br />
==== standing ====<br />
This animation is triggered whenever any other animation is finished, and is played in loop until another animation is triggered<br />
<br />
this is the default "standing image" for the unit<br />
<br />
''value='' is not used, and always contains 0<br />
<br />
''value_second='' is not used, and always contains 0<br />
<br />
if no standing animation is set a single frame animation based on the enclosing unit's '''image=''' field is used<br />
==== selected ====<br />
This animation is triggered whenever the unit is selected<br />
<br />
''value='' is not used, and always contains 0<br />
<br />
''value_second='' is not used, and always contains 0<br />
<br />
if no animation is available, the default uses the standing animation(s) with ''blend_ratio="0.0~0.3:100,0.3~0.0:200" blend_color=255,255,255''<br />
==== recruited ====<br />
This animation is triggered whenever the unit is recruited or recalled<br />
<br />
''value='' is not used, and always contains 0<br />
<br />
''value_second='' is not used, and always contains 0<br />
<br />
if no animation is available, the default uses the standing animation(s) with ''alpha=0~1:600''<br />
<br />
==== recruiting ====<br />
<br />
This animation is triggered for the leader when a unit is recruited or recalled<br />
<br />
''value='' is not used, and always contains 0<br />
<br />
''value_second='' is not used, and always contains 0<br />
<br />
no default animation is needed<br />
<br />
note that is not triggered for WML triggered animations<br />
<br />
==== levelout ====<br />
This animation is triggered whenever the unit levels, before the unit is replaced by the new unit.<br />
<br />
''value='' is not used, and always contains 0<br />
<br />
''value_second='' is not used, and always contains 0<br />
<br />
if no animation is available, the default uses the standing animation(s) with ''blend_ratio="0~1:600" blend_color=255,255,255''<br />
<br />
==== levelin ====<br />
This animation is triggered whenever the unit levels, after the unit is replaced by the new unit.<br />
<br />
''value='' is not used, and always contains 0<br />
<br />
''value_second='' is not used, and always contains 0<br />
<br />
if no animation is available, the default uses the standing animation(s) with ''blend_ratio="1~0:600" blend_color=255,255,255''<br />
<br />
==== movement ====<br />
This animation is used whenever a unit moves. There are multiple things to consider when dealing with movement animation<br />
* unit stay ''exactly'' 200ms in each hex. so you typically want to have an offset of ''0~1:200,0~1:200,0~1:200,0~1:200,0~1:200'' or something similar<br />
* when a unit enters a hex, the current anim is tested again.<br />
** if the current animation is still valid (i.e it passes all its filter) it is kept, whatever the final score is<br />
** if it fails, a new movement anim is searched<br />
<br />
''value='' contains the number of steps already taken<br />
<br />
''value_second='' contains the number of steps left<br />
<br />
if no animation is available, the default uses the standing animation(s) with ''offset="0~1:200,0~1:200,0~1:200,0~1:200,0~1:200,0~1:200,0~1:200,0~1:200,0~1:200,0~1:200"''<br />
<br />
==== pre_movement ====<br />
This animation is used before any unit movement<br />
<br />
''value='' is not used, and always contains 0 <br />
<br />
''value_second='' is not used, and always contains 0 <br />
<br />
==== post_movement ====<br />
This animation is used after any unit movement<br />
<br />
''value='' is not used, and always contains 0 <br />
<br />
''value_second='' is not used, and always contains 0<br />
<br />
==== pre_teleport ====<br />
This animation is triggered whenever the unit teleports, but before it has moved to the target hex<br />
<br />
''value='' is not used, and always contains 0<br />
<br />
''value_second='' is not used, and always contains 0<br />
<br />
if no animation is available, the default uses the standing animation(s) with ''blend_ratio="1~0:200" blend_color=255,255,255''<br />
==== post_teleport ====<br />
This animation is triggered whenever the unit teleports, but after it has moved to the target hex<br />
<br />
''value='' is not used, and always contains 0<br />
<br />
''value_second='' is not used, and always contains 0<br />
<br />
if no animation is available, the default uses the standing animation(s) with ''blend_ratio="0~1:200" blend_color=255,255,255''<br />
==== healing ====<br />
This animation is triggered when the unit has healing powers and uses them<br />
<br />
''value='' is the number of points healed<br />
<br />
''value_second='' is not used, and always contains 0<br />
<br />
No default is provided by the engine<br />
==== healed ====<br />
This animation is triggered whenever the unit is healed for any reason<br />
<br />
''value='' is the number of points healed<br />
<br />
''value_second='' is not used, and always contains 0<br />
<br />
if no animation is available, the default uses the standing animation(s) with ''blend_ratio="0:30,0.5:30,0:30,0.5:30,0:30,0.5:30,0:30,0.5:30,0:30" blend_color=255,255,255''<br />
and plays the sound ''heal.wav''<br />
==== poisoned ====<br />
This animation is triggered whenever the unit suffers poison damage<br />
<br />
''value='' is the number of points lost<br />
<br />
''value_second='' is not used, and always contains 0<br />
<br />
if no animation is available, the default uses the standing animation(s) with ''blend_ratio="0:30,0.5:30,0:30,0.5:30,0:30,0.5:30,0:30,0.5:30,0:30" blend_color=0,255,0''<br />
and plays the sound 'poison.ogg''<br />
<br />
==== defend ====<br />
This animation is triggered during a strike, of the unit receiving the blow<br />
<br />
''value='' is the number of point lost, if any<br />
<br />
''value_second='' is the number of the swing, starting from 1<br />
<br />
No default is provided by the engine<br />
==== attack ====<br />
This animation is triggered during a strike, of the unit giving the blow<br />
<br />
''value='' is the number of damage dealt, if any<br />
<br />
''value_second='' is the number of the swing, starting from 1<br />
<br />
if no animation is available, the default uses the standing animation(s) with ''offset="0~0.6:200,0.6~0:200"'' for melee attacks<br />
No default is provided for range attacks<br />
==== leading ====<br />
This animation is triggered for units with the leading special ability, when the unit they are leading is attacking<br />
<br />
''value='' is not used, and always contains 0<br />
<br />
''value_second='' is the number of the swing, starting from 1<br />
<br />
No default is provided by the engine<br />
<br />
<br />
==== resistance ====<br />
This animation is triggered for units with the resistance special ability affecting neighbouring fights, when the unit they are helping is defending<br />
<br />
''value='' is not used, and always contains 0<br />
<br />
''value_second='' is the number of the swing, starting from 1<br />
<br />
No default is provided by the engine<br />
<br />
==== death ====<br />
This animation is triggered when a unit die.<br />
<br />
''value='' is not used, and always contains 0<br />
<br />
''value_second='' is not used, and always contains 0<br />
<br />
if no animation is available, the default uses the standing animation(s) with ''alpha=1~0:600'' and plays the sound in ''die_sound='' of the enclosing unit<br />
==== victory ====<br />
This animation is triggered when a unit finishes a fight by killing the other unit<br />
<br />
''value='' is not used, and always contains 0<br />
<br />
''value_second='' is not used, and always contains 0<br />
<br />
No default is provided by the engine<br />
==== idling ====<br />
This animation is called when the unit has been using its standing animation for a random duration.<br />
<br />
''value='' is not used, and always contains 0<br />
<br />
''value_second='' is not used, and always contains 0<br />
<br />
No default is provided by the engine<br />
<br />
==== draw_weapon ====<br />
This animation is played before a fight<br />
<br />
''hit='' is set to HIT for the attacker and MISS for the defender<br />
<br />
No default is provided by the engine<br />
<br />
==== sheath_weapon ====<br />
This animation is played after a fight simultaneously for all surviving units<br />
<br />
No default is provided by the engine<br />
<br />
==== default ====<br />
<br />
This animation is never triggered, but is used as a base to create new animations<br />
<br />
''value='' is used depending of the type of animation it replaces<br />
<br />
''value_second='' is used depending of the type of animation it replaces<br />
<br />
A single animation made of the base frame is provided by the engine if no default animation is available<br />
<br />
==== extra animations ====<br />
Other values are never called by the engine. However they can be triggered by WML events allowing custom animations.<br />
<br />
Note that WML events can also trigger standard animations.<br />
''value='' is set from the WML event<br />
<br />
''value_second='' is set from the WML event<br />
<br />
== Shortcuts, tricks and quirks ==<br />
<br />
=== ''[if]'' and ''[else]'' ===<br />
<br />
Often, you need to do very slight variations in an animation (like a different sound depending on whether the unit hits or misses its attack), the '''[if]''' and '''[else]''' tags are meant to help you do that. ('''Attention:''' These do not have the same syntax as the action tag [if] and its subtag [else] in [[ConditionalActionsWML]].)<br />
<br />
Using these in an animation is equivalent to having multiple animations, one with the '''[if]''' block and one with each of the ''[else]'' blocks. Any filtering flags in these blocks will replace the toplevel filters. You can have multiple '''[if]''' blocks in an animation, but you can't nest an '''[if]''' inside another. These should be written directly inside the '''[animation]''' block. The following example would make the '''[frame]''' inside the '''[if]''' be played when the attack misses, and the '''[frame]''' inside the '''[else]''' be played when the attack hits (producing a different sound):<br />
<br />
start_time=-100<br />
[if]<br />
hits=no<br />
[frame]<br />
image="units/dwarves/lord-attack.png:200"<br />
sound={SOUND_LIST:MISS}<br />
[/frame]<br />
[/if]<br />
[else]<br />
hits=yes<br />
[frame]<br />
image="units/dwarves/lord-attack.png:200"<br />
sound=axe.ogg<br />
[/frame]<br />
[/else]<br />
<br />
note that this is very close to preprocessing and should be considered as such, especially with regard to scoring and animation selection<br />
<br />
A macro exists under macros/sound-util.cfg called SOUND:HIT_AND_MISS to simplify this type of animation, which is equivalent to:<br />
<br />
start_time=-100<br />
[frame]<br />
image="units/dwarves/lord-attack.png:200"<br />
[/frame]<br />
{SOUND:HIT_AND_MISS axe.ogg {SOUND_LIST:MISS} -100}<br />
<br />
=== Simplified animation blocks ===<br />
To simplify the most common animation cases, you can use different blocks instead of the generic '''[animation]''' block. These are also here for backward compatibility, but are not deprecated and fully supported<br />
<br />
some of these use extra tags which are translated in the normal ''value='' tag<br />
<br />
some of these define '''[xxx_frame]''' blocks where the frame prefix starts with an underscore. This is not allowed in normal WML (prefix starting with underscore is reserved for the engine internal use). It is here for clarity purpose<br />
<br />
* '''[leading_anim]''' is an animation with the following parameters automatically set<br />
apply_to=leading<br />
* '''[recruit_anim]''' is an animation with the following parameters automatically set<br />
apply_to=recruited<br />
* '''[recruiting_anim]''' is an animation with the following parameters automatically set<br />
apply_to=recruiting<br />
* '''[standing_anim]''' is an animation with the following parameters automatically set<br />
apply_to=standing,default<br />
note for 1.4 :''default'' doesn't exist in 1.4, but the semantic is the same.<br />
<br />
i.e: the animation will be used to build default animations<br />
* '''[idle_anim]''' is an animation with the following parameters automatically set<br />
apply_to=idling<br />
* '''[levelout_anim]''' is an animation with the following parameters automatically set<br />
apply_to=levelout<br />
* '''[levelin_anim]''' is an animation with the following parameters automatically set<br />
apply_to=levelin<br />
* '''[healing_anim]''' is an animation with the following parameters automatically set<br />
apply_to=healing<br />
value=<damage= value><br />
* '''[healed_anim]''' is an animation with the following parameters automatically set<br />
apply_to=healed<br />
value=<healing= value><br />
[_healed_sound_frame]<br />
sound=heal.wav<br />
[/_healed_sound_frame]<br />
* '''[poison_anim]''' is an animation with the following parameters automatically set<br />
apply_to=poisoned<br />
value=<damage= value><br />
[_poison_sound_frame]<br />
sound=poison.ogg<br />
[/_poison_sound_frame]<br />
* '''[movement_anim]''' is an animation with the following parameters automatically set<br />
apply_to=movement<br />
offset="0~1:200,0~1:200,0~1:200,0~1:200,0~1:200,0~1:200,0~1:200"<br />
* '''[pre_movement_anim]''' is an animation with the following parameters automatically set<br />
apply_to=pre_movement<br />
* '''[post_movement_anim]''' is an animation with the following parameters automatically set<br />
apply_to=post_movement<br />
* '''[draw_weapon_anim]''' is an animation with the following parameters automatically set<br />
apply_to=draw_weapon<br />
* '''[sheath_weapon_anim]''' is an animation with the following parameters automatically set<br />
apply_to=sheath_weapon_movement<br />
* '''[defend]''' is an animation with the following parameters automatically set<br />
apply_to=defend<br />
value=<damage= value><br />
<WML content><br />
[frame]<br />
blend_color=255,0,0<br />
blend_ratio="0.5:50,0.0:50"<br />
[/frame]<br />
<br />
there are some subtil change compared to what is described above to avoid the red flash when value=0, but it should work as expected as far as WML author are concerned<br />
<br />
* '''[attack_anim]''' is an animation with the following parameters automatically set<br />
if the animation contains a missile frame<br />
<br />
apply_to=attack<br />
missile_offset="0~0.8"<br />
<br />
else<br />
<br />
apply_to=attack<br />
offset="0~0.6,0.6~0"<br />
<br />
* '''[death]''' is an animation with the following parameters automatically set<br />
apply_to=death<br />
[_death_sound_frame]<br />
sound=<die_sound= of the enclosing [unit] tag><br />
[/_death_sound_frame]<br />
* '''[victory_anim]''' is an animation with the following parameters automatically set<br />
apply_to=victory<br />
* '''[extra_anim]''' is an animation with the following parameters automatically set<br />
apply_to=<flag= value of the anim><br />
* '''[teleport_anim]''' will be cut into two at the clock-time 0<br />
everything before zero becomes an animation with the following parameters automatically set<br />
apply_to=pre_teleport<br />
everything after zero becomes an animation with the following parameters automatically set<br />
apply_to=post_teleport<br />
<br />
== Layering ==<br />
The ''layer'' progressive parameter allows the animation writer to choose in what order the animation should be drawn.<br />
<br />
this value must be between 0 and 100<br />
<br />
* the back of haloes is drawn with a value of 10<br />
* when unspecified, a animation is drawn with a value of 40<br />
* terrain elements that are supposed to go in front of units (castles) are drawn with a value of 50<br />
* orbs and status bars are drawn on layer 80<br />
* when unspecified missile frames are drawn on layer 90<br />
<br />
by changing these values, it is easy to have the unit display the way you want<br />
<br />
== Optimization ==<br />
<br />
there is a special flag that goes into the animation block (not the frame) <br />
<br />
* ''offscreen'' a boolean saying if the unit's animation should be played when the unit is offscreen. You want the animation to play offscreen if the animation contains some usefull sound effects.This attribute defaults to true (play offscreen) except for standing and idle animations where it defaults to false<br />
<br />
== Cycling ==<br />
<br />
there is a special boolean parameter that can be put in an animation block (not the frame)<br />
<br />
* ''cycles'' a boolean value. if set to true the animation will cycles forever until it is replaced. That animation will not influence the end time of all related animations (for example a cycling defense animation will play normally but the overall duration of the fight animation will be only decided by the attack animation)<br />
<br />
== See Also ==<br />
<br />
* [[UnitTypeWML]]<br />
* [[ReferenceWML]]<br />
<br />
<br />
[[Category: WML Reference]]</div>Fabihttps://wiki.wesnoth.org/index.php?title=UnitTypeWML&diff=48345UnitTypeWML2013-01-11T22:10:07Z<p>Fabi: </p>
<hr />
<div>{{WML Tags}}<br />
<br />
__TOC__<br />
<br />
Each '''[unit_type]''' tag defines one unit type. (for the use of [unit] to create a unit, see [[SingleUnitWML]])<br />
<br />
Unit animation syntax is described in [[AnimationWML]]. In addition to the animation tags described there, the following key/tags are recognized:<br />
* '''[advancefrom]''': Defines the previous 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 ''advances_to'' 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'': (optional) If present the experience needed to advance is set to this value. If there are more than one [advancefrom] tags referencing the same base unit within the same preprocessor scope (e.g. a campaign #ifdef) with experience= keys, the lowest value of these is chosen. Note: this will also lower the experience required to advance to other units which the base unit can advance into.<br />
* '''advances_to''': When this unit has ''experience'' greater than or equal to ''experience'', it is replaced by a unit of the type that the value of ''advances_to'' refers to. All modifications that have been done to the unit are applied to the unit it is replaced by. The special value 'null' says that the unit does not advance but gets an AMLA instead. Can be a comma-separated list of units that can be chosen from upon advancing.<br />
* '''alignment''': one of lawful/neutral/chaotic/liminal (See [[TimeWML]]). Default is "neutral".<br />
* '''attacks''': the number of times that this unit can attack each turn.<br />
* '''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.<br />
* '''description''': (translatable) the text displayed in the unit descriptor box for this unit. Default 'No description available...'. <br />
* '''do_not_list''': Not used by the game, but by tools for browsing and listing the unit tree. If this is 'yes', the unit will be ignored by these tools. <br />
* '''ellipse''': the ellipse image to display under the unit, which is normally team-colored. Default is the normal ellipse; "misc/ellipse-nozoc" is a dashed ellipse that should be used for units without zone of control.<br />
* '''experience''': When this unit has experience greater than or equal to ''experience'', it is replaced by a unit with 0 experience of the type that the value of ''advances_to'' refers to. All modifications that have been done to the unit are applied to the unit it is replaced by.<br />
* '''flag_rgb''': usually set by [http://www.wesnoth.org/macro-reference.xhtml#MAGENTA_IS_THE_TEAM_COLOR MAGENTA_IS_THE_TEAM_COLOR]; specifies the colours in the base flag to use for team-colouring the unit, expressed as a colour name (such as magenta) or a comma-separated list of RGB values (in hex format).<br />
* '''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.<br />
* '''hide_help''': determines if the unit type will appear in the in-game help. Possible values ''true'' and ''false'', defaults to ''false''.<br />
* '''hitpoints''': the maximum HP that the unit has, and the HP it has when it is created.<br />
* '''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<br />
::WARNING : characters "$", "&", "*", "-", "(" and ")" are illegal for use in the unit type id and must be avoided because they might lead to corrupted saved games<br />
*'''ignore_race_traits''': 'yes' or 'no' (default). Determines whether racial traits (see [[UnitsWML]]) are applied. <br />
* '''image''': sets the base image of the unit, which is used on the map.<br />
* '''image_icon''': sets the image used to represent the unit in areas such as the attack dialog and the unit image box in the sidebar<br />
* '''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]]).<br />
* '''movement''': the number of move points that this unit receives each turn.<br />
* '''movement_type''': See [[UnitsWML#.5Bmovetype.5D|movetype]]. Note that the tags '''[movement_costs]''', '''[vision_costs]''', '''[defense]''', and '''[resistance]''' can be used to modify this movetype.<br />
* '''name''':(translatable) displayed in the Status Table for units of this type.<br />
* '''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.<br />
* '''profile''': the portrait image to use for this unit type. You can also set a portrait for an individual unit instead of the whole unit type (see [[SingleUnitWML]]). The engine first looks for the image in the transparent subdirectory and if found that image is used. If not found it will use the image as-is. Depending on the size the engine will or will not scale the image, the cutoff currently is at 300x300. For images which should only be shown on the right side in the dialog append ~RIGHT() to the image.<br />
* '''small_profile''': the image to use when a smaller portrait is needed than the one used for messages (e.g., in the help system). When this attribute is missing, the value of the '''profile''' attribute is used instead. When present, the heuristic for finding a transparent portrait is disabled for the '''profile''' attribute, so the correct '''profile''' should be set too. Note that image modifiers are allowed; they might be useful for cropping and rescaling a portrait:<br />
small_profile="portraits/elves/transparent/marksman+female.png~CROP(0,20,380,380)~SCALE(205,205)"<br />
profile="portraits/elves/transparent/marksman+female.png"<br />
* '''race''': See {{tag|UnitsWML|race}}. Also used in standard unit filter (see [[FilterWML]]).<br />
* '''undead_variation''': When a unit of this type is killed by a weapon with the plague special, this variation is applied to the new plague unit that is created, whatever its type. For example, if the plague special creates Walking Corpses and undead_variation is set to "troll", you'll get a troll Walking Corpse. Defaults to the undead_variation set in this unit type's race.<br />
* '''usage''': the way that the AI should recruit this unit, as determined by the scenario designer. (See ''recruitment_pattern'', [[AiWML]]). The following are conventions on usage:<br> ** ''scout'': Fast, mobile unit meant for exploration and village grabbing.<br> ** ''fighter'': Melee fighter, melee attack substantially more powerful than ranged.<br> ** ''archer'': Ranged fighter, ranged attack substantially more powerful than melee.<br> ** ''mixed fighter'': Melee and ranged fighter, melee and ranged attacks roughly equal.<br> ** ''healer'': Specialty 'heals' or 'cures'.<br>Note that this field affects only recruitment, not the AI's behavior in combat; that is always computed from attack power and hitpoints. Non-standard usages may be used as well.<br />
* '''vision''': the number of vision points to calculate the unit's sight range. Defaults to ''movement'' if not present.{{DevFeature1.11}}<br />
* '''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).<br />
<br />
== After max level advancement (AMLA) ==<br />
* '''[advancement]''': describes what happens to a unit when it reaches the XP required for advancement. It is considered as an advancement in the same way as advancement described by '''advances_to'''; however, if the player chooses this advancement, the unit will have one or more effects applied to it instead of advancing.<br />
** '''id''': unique identifier for this advancement; ''Required'' if there are multiple advancement options, or if ''strict_amla=no''.<br />
** '''always_display''': if set to true displays the AMLA option even if it is the only available one.<br />
** '''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.<br />
** '''image''': an image to display next to the description in the advancement menu.<br />
** '''max_times''': default 1. The maximum times the unit can be awarded this advancement. Pass -1 for "unlimited".<br />
** '''strict_amla''': (yes|no) default=no. Disable the AMLA if the unit can advance to another unit.<br />
** '''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.<br />
*** example: <tt>require_amla=tough,tough,incr_damage</tt> assumes there exist other [advancement] options called ''id=tough'' and ''id=incr_damage''. Once ''tough'' is chosen twice and ''incr_damage'' is chosen once, then the current [advancement] will become available.<br />
*** ''require_amla=tough,incr_damage,tough'' is an equivalent way of expressing this.<br />
** '''[effect]''': A modification applied to the unit whenever this advancement is chosen. See [[EffectWML]]<br />
<br />
== Attacks ==<br />
* '''[attack]''': one of the unit's attacks.<br />
** '''description''': a translatable text for name of the attack, to be displayed to the user.<br />
** '''name''': the name of the attack. Used as a default description, if ''description'' is not present, and to determine the default icon, if ''icon'' is not present (if ''name=x'' then ''icon=attacks/x.png'' is assumed unless present). Non-translatable. Used for the ''has_weapon'' key and animation filters; see [[StandardUnitFilter]] and [[AnimationWML]]<br />
** '''type''': the damage type of the attack. Used in determining resistance to this attack (see {{tag|UnitsWML|movetype|resistance}}).<br />
** '''[specials]''': contains the specials of the attack. See [[AbilitiesWML#The_.5Bspecials.5D_tag|AbilitiesWML]].<br />
** '''icon''': the image to use as an icon for the attack in the attack choice menu, as a path relative to the images directory.<br />
** '''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.<br />
** '''damage''': the damage of this attack<br />
** '''number''': the number of strikes per attack this weapon has<br />
** '''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.<br />
** '''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<br />
** '''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 <br />
For the weight settings, the engine usually chooses the attack with the best average total damages * weight (default weight = 1.0).<br />
<br />
== Other tags ==<br />
* '''[base_unit]''': Contains one attribute, '''id''', which must be the ID of a unit type. If specified, the UnitTypeWML for that unit is copied into this one. Subsequent attributes modify the copy. Tags modify the corresponding tag of the original, so for example the first '''[attack]''' tag in the derived unit would modify the first attack of the base unit rather than defining a new attack.<br />
<br />
* '''[portrait]''': Describes a unit portrait for dialogue. However, generally you should use the profile key instead; [portrait] is mostly for internal use.<br />
** '''size''': The size of the portrait, in pixels.<br />
** '''side''': One of left or right.<br />
** '''mirror''': Whether to flip the image horizontally.<br />
** '''image''': The image path.<br />
<br />
* '''[abilities]''': Defines the abilities of a unit. See [[AbilitiesWML]]<br />
<br />
* '''[event]''': Any [event] written inside the [unit_type] tag will get included into any scenario where a unit of this type appears in. Note that such events get included when a unit of this type first appears in the scenario, not automatically when the scenario begins (meaning that ''name=prestart'' events, for example, would usually never trigger). See [[EventWML]] and [[WML_Abilities]]<br />
<br />
* '''[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.<br />
** '''variation_name''': The name of the variation.<br />
** '''inherit''': if ''yes'', inherits all the properties of the base unit. Defaults to no.<br />
: All other keys in '''[variation]''' are the same as for '''[unit_type]''' itself.<br />
<br />
* '''[male]''', '''[female]''': They can contain all '''[unit_type]''' tags, to specify a variation of different gender for a unit.<br />
** '''inherit''': if ''yes'', inherits all the properties of the base unit. Defaults to yes.<br />
<br />
== See Also ==<br />
<br />
* [[AnimationWML]]<br />
* [[ReferenceWML]]<br />
* [[TerrainWML]]<br />
<br />
[[Category: WML Reference]]</div>Fabihttps://wiki.wesnoth.org/index.php?title=UnitsWML&diff=47087UnitsWML2012-08-25T15:32:35Z<p>Fabi: /* the [units] tag */</p>
<hr />
<div>{{WML Tags}}<br />
== the [units] tag ==<br />
<br />
This tag is a top level WML tag which is in game.cfg.<br />
It defines the set of all units in Wesnoth.<br />
<br />
The following subtags are recognized:<br />
* '''[unit_type]''': describes one unit type. See [[UnitTypeWML]] for syntax.<br />
* '''[trait]''': describes a global trait.<br />
All races with the attribute '''ignore_global_traits=no''' will have this trait.<br />
See '''[trait]''': below for syntax.<br />
* '''[movetype]''': used to make shortcuts to describe units with similar terrain handicaps. Units from the same advancement tree should generally have the same movetype.<br />
** '''name''': an ID for this movetype. Units with the attribute '''movement_type=''name''''' will be assigned this movetype.<br />
** ''flies'' either 'true' or 'false'(default). A unit with ''flies=true'' does not have its image's height adjusted for different terrains.<br />
** '''[movement_costs]''': describes how fast the unit moves on different terrains. The attribute '''terrain=''speed''''' means that the unit will need to use ''speed'' move points to move onto the terrain with '''name=''terrain''''' (see [[TerrainWML]]).<br />
** '''[vision_costs]''': describes how far the unit clears fog and shroud on different terrains. The attribute '''terrain=''cost''''' means that the unit will need to use ''cost'' vision points to view onto the terrain with '''name=''terrain''''' (see [[TerrainWML]]). {{DevFeature1.11}}<br />
** '''[defense]''': describes how likely the unit is to be hit on different terrains. The attribute '''terrain=''defense''''' means that the unit will be hit ''defense'' percent of the time in the terrain with '''name=''terrain'''''. If the defense value is negative, then the unit will be hit as though the value were positive with one difference: the number is also the best defense that the unit may have if there is more than one terrain type for the terrain the unit is on.<br />
** '''[resistance]''': describes how much damage the unit takes from different types of attacks. The attribute '''type=''resistance''''' makes the unit receive '''resistance''' percent of damage, or resist '''100-resistance''' percent of damage from attacks with '''type=''type'''''. So for example, a resistance of fire=110 means, this unit will receive 110% of damage, or have a resistance of -10% as displayed in-game. A value of fire=0 would mean, the unit receives no damage and therefore has a resistance of 100%.<br />
* '''[race]''': is used to make shortcuts to describe units with similar names. Units from the same advancement tree should generally have the same race. Also, units with the same race should generally be recruitable by the same sides/factions.<br />
** '''id''': ID for this race. Units with the attribute '''race=''id''''' will be assigned this race. In older versions of WML, the value of the name key was used as id if the id field was missing, but this is no longer the case.<br />
** '''plural_name''': user-visible name for its people (e.g. "Merfolk" or "Elves"). Currently only used in the in-game help.<br />
** '''male_name''': user-visible name for the race of the male units (e.g. "Merman"). Currently only used in the in-game unit status.<br />
** '''female_name''': user-visible name for the race of the female units (e.g. "Mermaid"). Currently only used in the in-game unit status.<br />
** '''name''': the default value for the three keys above. The 'name' key is the default for 'male_name' and 'female_name'. 'id' and 'plural_name' '''must''' be supplied.<br />
** '''description''': description of this race, used in the race page of the in-game help. Note: currently not used by all mainline races because their descriptions are not ready. But this is already supported by the engine.<br />
** '''male_names''', '''female_names''': lists of names (i.e. non-translatable strings). They are inputted into the Markov name generator to generate random names. ''male_names'' describes units with '''gender=male'''; ''female_names'' describes units with '''gender=female'''.<br />
** '''markov_chain_size''': (default 2) number of letters per "syllable". "Syllables" are groupings of names that the Markov name generator uses to determine names. It does this by running a probability algorithm to guess from the name list which syllables fit well together, which can start or end a name, etc.<br />
** '''num_traits''': is the number of non-repeating traits each unit of this race can be assigned.<br />
** '''ignore_global_traits''': 'yes' or 'no'(default). Determines whether global traits (see [traits] above) are applied.<br />
** '''undead_variation''': sets the default undead variation for members of this race.<br />
** '''[topic]''': describes extra help topics for this race.<br />
** '''[trait]''': describes a trait for this race. :<br />
*** '''id''': unique identifier<br />
*** '''availability''': describes whether a trait is "musthave" for a race or is available to "any" unit in a race, including leaders, or "none" if it is not normally available, but should be kept when advancing to this unit type. (Traits not available to the advanced unit type at all, are permanently lost upon advancement.) The default is for a trait to only be available to nonleaders. Currently "any" should not be used for traits available in multiplayer. It can be used for campaign specific traits. (Note that currently "musthave" is somewhat misused to have what are really abilities (''undead'' and ''mechanical'') default from a unit type's race. Ideally someone will eventually extend ''race'' to allow for default abilities. It might also be possible to unify traits and abilities with keys to indicate how you get them and what happens to them when you advance, while allowing them to come from race, unit type and unit definitions. There are also display issues related to doing this.)<br />
*** '''male_name''': text displayed in the status of unit with the trait if the unit is male.<br />
*** '''female_name''': text displayed in the status of unit with the trait if the unit is female.<br />
*** '''name''': text displayed in the status of unit with the trait if none of the two above is used.<br />
*** '''description''': text displayed for the description of the trait.<br />
*** '''[effect]''': described in [[EffectWML]].<br />
<br />
* '''[hide_help]''': allow to hide some units from the help. Mainly useful if you can't change these units (e.g. mainline units) and thus can't add a 'hide_help=yes' key to them. The following keys and theirs contents uses an 'OR' logic between them.<br />
** '''type''': list of unit types.<br />
** '''race''': list of races. Equivalent to all unit types of these races.<br />
** '''type_adv_tree''': list of unit types. Equivalent to all these types and their advancement trees.<br />
** '''all''': 'yes' or 'no'(default). 'yes' is equivalent to all unit types (useful before [not])<br />
** '''[not]''': all the previous keys (except 'all') can also be used in [not] sub-tags. And you can use [not] recursively. For example, if you want to only show the Yeti and the human race except the mage tree, use:<br />
[hide_help]<br />
all=yes<br />
[not]<br />
type=Yeti<br />
race=human<br />
[not]<br />
type_adv_tree=Mage<br />
[/not]<br />
[/not]<br />
[/hide_help]<br />
<br />
== See Also ==<br />
<br />
* [[UnitTypeWML]]<br />
* [[ReferenceWML]]<br />
<br />
<br />
[[Category: WML Reference]]</div>Fabihttps://wiki.wesnoth.org/index.php?title=UnitsWML&diff=46540UnitsWML2012-05-02T02:26:43Z<p>Fabi: /* the [units] tag */</p>
<hr />
<div>{{WML Tags}}<br />
== the [units] tag ==<br />
<br />
This tag is a top level WML tag which is in game.cfg.<br />
It defines the set of all units in Wesnoth.<br />
<br />
The following subtags are recognized:<br />
* '''[unit_type]''': describes one unit type. See [[UnitTypeWML]] for syntax.<br />
* '''[trait]''': describes a global trait.<br />
All races with the attribute '''ignore_global_traits=no''' will have this trait.<br />
See '''[trait]''': below for syntax.<br />
* '''[movetype]''': used to make shortcuts to describe units with similar terrain handicaps. Units from the same advancement tree should generally have the same movetype.<br />
** '''name''': an ID for this movetype. Units with the attribute '''movetype=''name''''' will be assigned this movetype.<br />
** ''flies'' either 'true' or 'false'(default). A unit with ''flies=true'' does not have its image's height adjusted for different terrains.<br />
** '''[movement_costs]''': describes how fast the unit moves on different terrains. The attribute '''terrain=''speed''''' means that the unit will need to use ''speed'' move points to move onto the terrain with '''name=''terrain''''' (see [[TerrainWML]]).<br />
** '''[vision_costs]''': describes how far the unit clears fog and shroud on different terrains. The attribute '''terrain=''cost''''' means that the unit will need to use ''cost'' vision points to view onto the terrain with '''name=''terrain''''' (see [[TerrainWML]]). {{DevFeature1.11}}<br />
** '''[defense]''': describes how likely the unit is to be hit on different terrains. The attribute '''terrain=''defense''''' means that the unit will be hit ''defense'' percent of the time in the terrain with '''name=''terrain'''''. If the defense value is negative, then the unit will be hit as though the value were positive with one difference: the number is also the best defense that the unit may have if there is more than one terrain type for the terrain the unit is on.<br />
** '''[resistance]''': describes how much damage the unit takes from different types of attacks. The attribute '''type=''resistance''''' makes the unit receive '''resistance''' percent of damage, or resist '''100-resistance''' percent of damage from attacks with '''type=''type'''''. So for example, a resistance of fire=110 means, this unit will receive 110% of damage, or have a resistance of -10% as displayed in-game. A value of fire=0 would mean, the unit receives no damage and therefore has a resistance of 100%.<br />
* '''[race]''': is used to make shortcuts to describe units with similar names. Units from the same advancement tree should generally have the same race. Also, units with the same race should generally be recruitable by the same sides/factions.<br />
** '''id''': ID for this race. Units with the attribute '''race=''id''''' will be assigned this race. In older versions of WML, the value of the name key was used as id if the id field was missing, but this is no longer the case.<br />
** '''plural_name''': user-visible name for its people (e.g. "Merfolk" or "Elves"). Currently only used in the in-game help.<br />
** '''male_name''': user-visible name for the race of the male units (e.g. "Merman"). Currently only used in the in-game unit status.<br />
** '''female_name''': user-visible name for the race of the female units (e.g. "Mermaid"). Currently only used in the in-game unit status.<br />
** '''name''': the default value for the three keys above. The 'name' key is the default for 'male_name' and 'female_name'. 'id' and 'plural_name' '''must''' be supplied.<br />
** '''description''': description of this race, used in the race page of the in-game help. Note: currently not used by all mainline races because their descriptions are not ready. But this is already supported by the engine.<br />
** '''male_names''', '''female_names''': lists of names (i.e. non-translatable strings). They are inputted into the Markov name generator to generate random names. ''male_names'' describes units with '''gender=male'''; ''female_names'' describes units with '''gender=female'''.<br />
** '''markov_chain_size''': (default 2) number of letters per "syllable". "Syllables" are groupings of names that the Markov name generator uses to determine names. It does this by running a probability algorithm to guess from the name list which syllables fit well together, which can start or end a name, etc.<br />
** '''num_traits''': is the number of non-repeating traits each unit of this race can be assigned.<br />
** '''ignore_global_traits''': 'yes' or 'no'(default). Determines whether global traits (see [traits] above) are applied.<br />
** '''undead_variation''': sets the default undead variation for members of this race.<br />
** '''[topic]''': describes extra help topics for this race.<br />
** '''[trait]''': describes a trait for this race. :<br />
*** '''id''': unique identifier<br />
*** '''availability''': describes whether a trait is "musthave" for a race or is available to "any" unit in a race, including leaders, or "none" if it is not normally available, but should be kept when advancing to this unit type. (Traits not available to the advanced unit type at all, are permanently lost upon advancement.) The default is for a trait to only be available to nonleaders. Currently "any" should not be used for traits available in multiplayer. It can be used for campaign specific traits. (Note that currently "musthave" is somewhat misused to have what are really abilities (''undead'' and ''mechanical'') default from a unit type's race. Ideally someone will eventually extend ''race'' to allow for default abilities. It might also be possible to unify traits and abilities with keys to indicate how you get them and what happens to them when you advance, while allowing them to come from race, unit type and unit definitions. There are also display issues related to doing this.)<br />
*** '''male_name''': text displayed in the status of unit with the trait if the unit is male.<br />
*** '''female_name''': text displayed in the status of unit with the trait if the unit is female.<br />
*** '''name''': text displayed in the status of unit with the trait if none of the two above is used.<br />
*** '''description''': text displayed for the description of the trait.<br />
*** '''[effect]''': described in [[EffectWML]].<br />
<br />
* '''[hide_help]''': allow to hide some units from the help. Mainly useful if you can't change these units (e.g. mainline units) and thus can't add a 'hide_help=yes' key to them. The following keys and theirs contents uses an 'OR' logic between them.<br />
** '''type''': list of unit types.<br />
** '''race''': list of races. Equivalent to all unit types of these races.<br />
** '''type_adv_tree''': list of unit types. Equivalent to all these types and their advancement trees.<br />
** '''all''': 'yes' or 'no'(default). 'yes' is equivalent to all unit types (useful before [not])<br />
** '''[not]''': all the previous keys (except 'all') can also be used in [not] sub-tags. And you can use [not] recursively. For example, if you want to only show the Yeti and the human race except the mage tree, use:<br />
[hide_help]<br />
all=yes<br />
[not]<br />
type=Yeti<br />
race=human<br />
[not]<br />
type_adv_tree=Mage<br />
[/not]<br />
[/not]<br />
[/hide_help]<br />
<br />
== See Also ==<br />
<br />
* [[UnitTypeWML]]<br />
* [[ReferenceWML]]<br />
<br />
<br />
[[Category: WML Reference]]</div>Fabihttps://wiki.wesnoth.org/index.php?title=UnitTypeWML&diff=46539UnitTypeWML2012-05-02T02:16:30Z<p>Fabi: /* The [unit_type] tag */</p>
<hr />
<div>{{WML Tags}}<br />
== The [unit_type] tag ==<br />
<br />
Each '''[unit_type]''' tag defines one unit type. (for the use of [unit] to create a unit, see [[SingleUnitWML]])<br />
<br />
Unit animation syntax is described in [[AnimationWML]].<br />
<br />
The following key/tags are recognized:<br />
{| class="gallery" style="text-align:left;"<br />
|-<br />
! [advancefrom]<br />
| the previous level unit on the advancement tree<br />
- allows a campaign-specific unit to be spliced into an already existing advancement tree. It should generally be used only inside a campaign ifdef, to prevent changes to other campaigns. This tag makes changes to the ''advances_to'' and ''experience'' keys of a base unit to make it advance into this unit. It takes these keys:<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 the experience needed to advance is set to this value. If there are more than one [advancefrom] tags referencing the same base unit within the same preprocessor scope (e.g. a campaign #ifdef) with experience= keys, the lowest value of these is chosen. Note: this will also lower the experience required to advance to other units which the base unit can advance into.<br />
|-<br />
! advances_to<br />
| When this unit has'' experience'' greater than or equal to ''experience'', it is replaced by a unit of the type that the value of ''advances_to'' refers to. All modifications that have been done to the unit are applied to the unit it is replaced by. The special value 'null' says that the unit does not advance but gets an AMLA instead.<br />
|-<br />
! alignment <br />
| one of lawful/neutral/chaotic/liminal (See [[TimeWML]]). Default is "neutral".<br />
|-<br />
! attacks<br />
| the number of times that this unit can attack each turn.<br />
|-<br />
! cost<br />
| 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.<br />
|-<br />
! description<br />
| (translatable) the text displayed in the unit descriptor box for this unit. Default 'No description available...'. <br />
|-<br />
! do_not_list<br />
| Not used by the game, but by tools for browsing and listing the unit tree. If this is 'yes', the unit will be ignored by these tools. <br />
|-<br />
! ellipse<br />
| the ellipse image to display under the unit, which is normally team-colored. Default is the normal ellipse; "misc/ellipse-nozoc" is a dashed ellipse that should be used for units without zone of control.<br />
|-<br />
! experience<br />
| When this unit has experience greater than or equal to ''experience'', it is replaced by a unit with 0 experience of the type that the value of ''advances_to'' refers to. All modifications that have been done to the unit are applied to the unit it is replaced by.<br />
|-<br />
! flag_rgb<br />
| set by [http://www.wesnoth.org/macro-reference.xhtml#MAGENTA_IS_THE_TEAM_COLOR MAGENTA_IS_THE_TEAM_COLOR]<br />
|-<br />
! gender<br />
| 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.<br />
|-<br />
! hide_help<br />
| determines if the unit type will appear in the in-game help. Possible values ''true'' and ''false'', defaults to ''false''.<br />
|-<br />
! hitpoints<br />
| the maximum HP that the unit has, and the HP it has when it is created.<br />
|-<br />
! id<br />
|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<br />
WARNING : characters "$", "&", "*", "-", "(" and ")" are illegal for use in the unit id and must be avoided because they might lead to corrupted saved games<br />
|-<br />
! image<br />
| sets the base image of the unit, which is used on the map.<br />
|-<br />
! image_icon<br />
| sets the image used to represent the unit in areas such as the attack dialog and the unit image box in the sidebar<br />
|-<br />
! level<br />
| the amount of upkeep the unit costs. After this unit fights, its opponent gains ''level'' experience. See also kill_experience ([[GameConfigWML]]), and leadership ([[AbilitiesWML]]).<br />
|-<br />
! movement<br />
| the number of move points that this unit receives each turn.<br />
|-<br />
! vision<br />
| the number of vision points to calculate the unit's sight range. Defaults to ''movement'' if not present.<br />
|-<br />
! movement_type<br />
| See '''movetype''', [[UnitsWML]]. Note that the tags '''movement_costs''', '''vision_costs''', '''defense''', and '''resistance''' can be used to modify this movetype.<br />
|-<br />
! name<br />
|(translatable) displayed in the Status Table for units of this type.<br />
|-<br />
! num_traits<br />
| the number of traits that units of this type should receive when they are recruited, overriding the value set in the [race] tag.<br />
|-<br />
! profile<br />
| the portrait image to use for this unit type. You can also set a portrait for an individual unit instead of the whole unit type (see [[SingleUnitWML]]). The engine first looks for the image in the transparent subdirectory and if found that image is used. If not found it will use the image as-is. Depending on the size the engine will or will not scale the image, the cutoff currently is at 300x300. For images which should only be shown on the right side in the dialog append ~RIGHT() to the image.<br />
|-<br />
! small_profile<br />
| the image to use when a smaller portrait is needed than the one used for messages (e.g., in the help system). When this attribute is missing, the value of the '''profile''' attribute is used instead. When present, the heuristic for finding a transparent portrait is disabled for the '''profile''' attribute, so the correct '''profile''' should be set too. Note that image modifiers are allowed; they might be useful for cropping and rescaling a portrait:<br />
small_profile="portraits/elves/transparent/marksman+female.png~CROP(0,20,380,380)~SCALE(205,205)"<br />
profile="portraits/elves/transparent/marksman+female.png"<br />
|-<br />
! race<br />
| See '''[race]''', [[UnitsWML]]. Also used in standard unit filter (see [[FilterWML]]).<br />
|-<br />
! undead_variation<br />
| Which image to use when a unit of this type is killed by a unit with the plague ability. Defaults to the undead_variation set in this unit type's race.<br />
|-<br />
! usage<br />
| the way that the AI should recruit this unit, as determined by the scenario designer. (See ''recruitment_pattern'', [[AiWML]]). The following are conventions on usage:<br> ** ''scout'': Fast, mobile unit meant for exploration and village grabbing.<br> ** ''fighter'': Melee fighter, melee attack substantially more powerful than ranged.<br> ** ''archer'': Ranged fighter, ranged attack substantially more powerful than melee.<br> ** ''mixed fighter'': Melee and ranged fighter, melee and ranged attacks roughly equal.<br> ** ''healer'': Specialty 'heals' or 'cures'.<br>Note that this field affects only recruitment, not the AI's behavior in combat; that is always computed from attack power and hitpoints. <br />
|-<br />
! zoc<br />
| 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).<br />
|}<br />
==== After max level advancement (AMLA) ====<br />
* '''[advancement]''': describes what happens to a unit when it reaches the XP required for advancement. It is considered as an advancement in the same way as advancement described by '''advances_to'''; however, if the player chooses this advancement, the unit will have one or more effects applied to it instead of advancing.<br />
** '''id''': unique identifier for this advancement; ''Required'' if there are multiple advancement options, or if ''strict_amla=no''.<br />
** '''always_display''': if set to true displays the AMLA option even if it is the only available one.<br />
** '''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.<br />
** '''image''': an image to display next to the description in the advancement menu.<br />
** '''max_times''': default 1. The maximum times the unit can be awarded this advancement. Pass -1 for "unlimited".<br />
** '''strict_amla''': (yes|no) default=no. Disable the AMLA if the unit can advance to another unit.<br />
** '''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.<br />
*** example: <tt>require_amla=tough,tough,incr_damage</tt> assumes there exist other [advancement] options called ''id=tough'' and ''id=incr_damage''. Once ''tough'' is chosen twice and ''incr_damage'' is chosen once, then the current [advancement] will become available.<br />
*** ''require_amla=tough,incr_damage,tough'' is an equivalent way of expressing this.<br />
** '''[effect]''': A modification applied to the unit whenever this advancement is chosen. See [[EffectWML]]<br />
<br />
==== Attacks ====<br />
* '''[attack]''': one of the unit's attacks.<br />
** '''description''': a translatable text for name of the attack, to be displayed to the user.<br />
** '''name''': the name of the attack. Used as a default description, if ''description'' is not present, and to determine the default icon, if ''icon'' is not present (if ''name=x'' then ''icon=attacks/x.png'' is assumed unless present). Non-translatable. Used for the ''has_weapon'' key and animation filters; see [[StandardUnitFilter]] and [[AnimationWML]]<br />
** '''type''': the damage type of the attack. Used in determining resistance to this attack (see '''[resistances]''', [[UnitsWML]]).<br />
** '''[specials]''': contains the specials of the attack. See [[AbilitiesWML]].<br />
** '''icon''': the image to use as an icon for the attack in the attack choice menu, as a path relative to the images directory.<br />
** '''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.<br />
** '''damage''': the damage of this attack<br />
** '''number''': the number of strikes per attack this weapon has<br />
** '''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.<br />
For those two following settings, the engine usually chooses the attack with the best average total damages * weight (default weight = 1.0).<br />
** '''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<br />
** '''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 <br />
<br />
==== Animations ====<br />
See [[AnimationWML]] for details on how to specify animations for the unit.<br />
<br />
==== Other tags ====<br />
* '''[base_unit]''': Contains one attribute, '''id''', which must be the ID of a unit type. If specified, the UnitTypeWML for that unit is copied into this one. Subsequent attributes modify the copy.<br />
<br />
* '''[abilities]''': Defines the abilities of a unit. See [[AbilitiesWML]]<br />
<br />
* '''[event]''': Any [event] written inside the [unit_type] tag will get included into any scenario where a unit of this type appears in. Note that such events get included when a unit of this type first appears in the scenario, not automatically when the scenario begins (meaning that ''name=prestart'' events, for example, would usually never trigger). See [[EventWML]] and [[WML_Abilities]]<br />
<br />
* '''[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.<br />
** '''variation_name''': The name of the variation.<br />
** '''inherit''': if ''yes'', inherits all the properties of the base unit. Defaults to no.<br />
: All other keys in '''[variation]''' are the same as for '''[unit_type]''' itself.<br />
<br />
* '''[male]''', '''[female]''': They can contain all '''[unit_type]''' tags, to specify a variation of different gender for a unit.<br />
** '''inherit''': if ''yes'', inherits all the properties of the base unit. Defaults to yes.<br />
<br />
== See Also ==<br />
<br />
* [[AnimationWML]]<br />
* [[ReferenceWML]]<br />
* [[TerrainWML]]<br />
<br />
[[Category: WML Reference]]</div>Fabihttps://wiki.wesnoth.org/index.php?title=CampaignWML&diff=45238CampaignWML2012-02-12T15:41:59Z<p>Fabi: /* the [campaign] tag */</p>
<hr />
<div>{{WML Tags}}<br />
== the [campaign] tag ==<br />
<br />
<!--<br />
<br />
Dacyn and/or Invisible Philosopher -- please be careful<br />
you don't reduce the signal-to-noise ratio on the WML pages<br />
when editing! Eg. knowing that a tag is translatable is _important_<br />
for the 29 translations we have in progress. -- ott<br />
<br />
--><br />
<br />
This page describes how the campaign is displayed in the "Campaign" menu, and how it starts.<br />
<br />
'''[campaign]''' describes a campaign<br />
* '''id''': the internal campaign identifier used to classify saved games<br />
* '''icon''': the image displayed in the campaign selection menu<br />
* '''name''': (translatable) name displayed in the campaign selection menu<br />
* '''abbrev''': (translatable) abbreviation used as a prefix for savefile names made from this campaign<br />
* '''image''': the image shown in the information pane when this campaign is selected in the campaign selection menu (typically a transparent, 350×350 pixels portrait)<br />
* '''description''': (translatable) text shown in the information pane when this campaign is selected in the campaign selection menu<br />
* '''define'''='''''CAMPAIGN_SYMBOL''''' when this campaign is started, the preprocessor symbol '''''CAMPAIGN_SYMBOL''''' will be defined. See '''#ifdef''' in [[PreprocessorRef]] for how this can be used to isolate parts of the campaign file from other campaigns. Only the tags '''[campaign]''' and '''[binary_path]''' (see [[BinaryPathWML]]) should go outside of '''#ifdef ''CAMPAIGN_SYMBOL'''''. This symbol will be defined ''before'' any .cfg is preprocessed. Important note: starting with 1.7.13, [binary_path] does no longer need to be outside of the '''#ifdef ''CAMPAIGN_SYMBOL''''' block to make custom binary data available, which could easily cause overwrites. E.g. icon=data/add-ons/whatever/something.png is supposed to work. This seems to have been a bug since at least BfW 1.0 which means that practically all available examples of user made add-ons are wrong in this aspect.<br />
* '''extra_defines''': a comma(''',''') separated list of preprocessor symbols. Those symbols will be defined ''before'' any .cfg is preprocessed. Currently supported extra_defines are:<br />
** '''ENABLE_ARMAGEDDON_DRAKE''', that allows the advancement ''Inferno Drake'' -> ''Armageddon Drake''<br />
** '''ENABLE_DWARVISH_ARCANISTER''', that allows the advancement ''Dwarvish Runemaster'' -> ''Dwarvish Arcanister''<br />
** '''ENABLE_DWARVISH_RUNESMITH''', that allows the advancement ''Dwarvish Fighter'' -> ''Dwarvish Runesmith''<br />
** '''DISABLE_GRAND_MARSHAL''', that disallows the advancement ''General'' -> ''Grand Marshal''<br />
** '''ENABLE_ANCIENT_LICH''', that allows the advancement ''Lich'' -> ''Ancient Lich''<br />
** '''ENABLE_DEATH_KNIGHT''', that allows the advancement ''Revenant'' -> ''Death Knight''<br />{{DevFeature1.11}} 1.11.x also supports:<br />
** '''ENABLE_TROLL_SHAMAN''', that allows the advancement ''Troll Whelp'' -> ''Troll Shaman''<br />
** '''ENABLE_WOLF_ADVANCEMENT''', that allows the advancements ''Wolf'' -> ''Great Wolf'' -> ''Direwolf''<br />
* '''difficulties''': a comma(''',''') separated list of preprocessor symbols, exactly one of which will be stored depending on the difficulty setting chosen when the campaign is started. The symbols '''EASY''', '''NORMAL''', and '''HARD''' are usually used, and there are several macros in utils.cfg (see [[UtilWML]]) which check for these values to set WML keys to different values depending on difficulty. If you use different difficulty symbols, you may need to define your own versions of these macros.<br />
* '''difficulty_descriptions''': the menu of difficulties; this is a list of descriptions (see [[DescriptionWML]]) that correspond to different difficulty levels. Since each description is a menu option for a difficulty level, this must provide the same number of descriptions as there are levels in the ''difficulties'' list.<br />
* '''allow_difficulty_change''': {{DevFeature1.11}} Allows difficulty switching during an ongoing campaign. Default:yes<br />
* '''first_scenario''': the ID of the first scenario in the campaign; see ''id'' in [[ScenarioWML]]<br />
* '''rank''': a number that determines the order of campaigns in the campaign selection menu. Lower ''rank'' campaigns appear earlier, with unranked campaigns at the end. Currently the mainline campaigns use multiples of 10 from 0 to 399, with 0-99 for Novice campaigns, 100-199 for Intermediate campaigns, and 200-399 for Expert campaigns; if you specify this, it should not be less than 400. (Note: This replaces an older convention that topped out at 50.)<br />
* '''[about]''': inserts your own credits into the game's list of credits. The campaign's name automatically is inserted at the top of the rolling credits followed by title/text key pairs. There can be any number of '''[about]''' tags inside a '''[campaign]''' tag, but none of them will display credits if there is no "id" key present inside [campaign] (see above). The '''[about]''' tag has the following keys:<br />
** '''title''': (translatable) large text used to start a new subsection (writers, artists, units, balancing) in the rolling credits<br />
** '''text''': (translatable, but you probably won't want to make it such) smaller text which is displayed before the contributor names<br />
** '''[entry]''': Contains information about a single contributor. Only the ''name'' key will be used in-game, the other three keys are for display on the [[Credits]] page ('''note:''' the values of these keys will only display on the Credits page for mainline campaigns; they will not display for UMC campaigns)<br />
*** '''name''': The name of the contributor<br />
*** '''comment''': Optional short note about what that person did<br />
*** '''email''': Optional email address<br />
*** '''wikiuser''': Optional, the user name on the wiki<br />
* '''end_credits''': {{DevFeature1.11}} Whether to display the credits screen at the end of the campaign. Defaults to ''yes''.<br />
* '''end_text''': (translatable) Text that is shown centered in a black screen at the end of a campaign. Defaults to "The End".<br />
* '''end_text_duration''': Delay, in milliseconds, before displaying the game credits at the end of a campaign. In other words, for how much time '''end_text''' is displayed on screen. Defaults to 3500.<br />
<br />
== See Also ==<br />
<br />
* [[PreprocessorRef]]<br />
* [[ScenarioWML]]<br />
* [[ReferenceWML]]<br />
* [[PblWML]]<br />
<br />
<br />
[[Category: WML Reference]]</div>Fabihttps://wiki.wesnoth.org/index.php?title=EventWML&diff=43932EventWML2011-11-01T17:14:24Z<p>Fabi: /* Predefined 'name' Key Values */</p>
<hr />
<div>{{WML Tags}}<br />
== The [event] Tag ==<br />
<br />
This tag is a subtag of the [scenario], [unit_type] and [era] tags which is used to describe a set of [[ActionWML|actions]] which trigger at a certain point in a scenario. When used in a [scenario] tag (also includes [multiplayer], [tutorial] and [test]), the event only occurs in that scenario. When used in a [unit_type] tag, the event will occur in all scenarios in which a unit of that type appears in (only after such a unit appears during the scenario, however). When used in an [era], the event will occur in any scenario which is played using that era.<br />
<br />
This tag has keys and child tags that control when and if the event actions will be triggered. Most important of these is the '''name''' key. Without it, no error will be raised but the event will never fire. Therefore, from a practical standpoint, it can be considered mandatory. All of the others can be used or not and the event actions will fire either way.<br />
<br />
'''Lexicon side note:''' ''The word "event" in the [event] tag itself may be considered an abbreviation of the word "event handler" because it is technically not a game "event" but an event '''handler''' for the game events fired with the given 'name'. However, this distinction is usually unimportant in most discussions and the event handlers are therefore simply referred to as "events" in this documentation.''<br />
<br />
=== The 'name' Key (Mandatory) ===<br />
<br />
Usage:<br />
name=<value><br />
<br />
This key defines which game event or trigger your [event] tag will be handling. This 'name' key should not be confused with a descriptive comment; it is rather a precise value which must match the predefined game event's name to be valid.<br />
<br />
'''Lexicon side note:''' ''It is not uncommon to refer to these values as the 'trigger' for an event and, furthermore, to call an event by its 'trigger' name. For example, in an event containing '''name=moveto''', a person might refer to the event as a ''''moveto''' event' and/or refer to the ''''moveto''' trigger' in the event or even talk about the 'event trigger' when referring to the '''moveto''' value of the 'name' key in that event. Some or all of this usage can, in fact, be found throughout this page.''<br />
<br />
The '''name''' key can accept a list of comma separated values describing when the event will be triggered.* These values may be either predefined event types or custom event names not matching any predefined type.<br />
<br />
For example:<br />
<br />
name=attacker misses,defender misses<br />
<br />
''* Note that unless you use [[#first_time_only|first_time_only=no]], the event will fire only once, '''not''' once for each listed type.''<br />
<br />
==== Predefined 'name' Key Values ====<br />
<br />
All predefined event types are listed here along with a description of when this value will cause the event to be triggered. Any value ''not'' listed here is a custom event name which can be triggered only by a '''[fire_event]''' tag somewhere else. Spaces in event names can be interchanged with underscores (for example, '''name=new turn''' and '''name=new_turn''' are equivalent).<br />
<br />
; preload<br />
: Triggers before a scenario 'prestarts' and when loading a savegame -- before anything is shown on the screen at all. Can be used to set up the [[LuaWML|Lua]] environment: loading libraries, defining helper functions, etc.<br />
: '''Note:''' Unlike prestart and start, the preload event '''must be able to fire more than once!''' This is because it is triggered each time a savegame is loaded in addition to the initial time when it loads before the scenario 'prestart'. This means that it is effectively ''mandatory'' to have the [[#first_time_only|first_time_only=no]] key value in a preload event. <br />
<br />
; prestart<br />
: Triggers before a scenario 'starts' -- before anything is shown on the screen at all. Can be used to set up things like village ownership. For things displayed on-screen such as character dialog, use '''start''' instead.<br />
: '''Note:''' ''This value makes the [[#first_time_only|first_time_only]] key irrelevant since, by definition, it can only fire once.''<br />
<br />
; start<br />
: Triggers after the map is shown but before the scenario begins -- before players can 'do' anything.<br />
: '''Note:''' ''This value makes the [[#first_time_only|first_time_only]] key irrelevant since, by definition, it can only fire once.''<br />
<br />
; new turn<br />
: Triggers at the start of every turn (not side turn). See also [[#first_time_only|first_time_only=no]]. 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.<br />
<br />
; turn end {{DevFeature1.9}}<br />
: Triggers at the end of every turn (not side turn). See also [[#first_time_only|first_time_only=no]]. The WML variable '''side_number''' will contain the side that ended their turn.<br />
<br />
; turn ''X'' end {{DevFeature1.9}}<br />
: Triggers at the end of turn ''X''.<br />
<br />
; side turn<br />
: Triggers when a side is about to start 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. This is before any healing takes place for that side, before calculating income, and before restoring unit movement and status.<br />
<br />
; ai turn<br />
: 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. Note that this event might be called several times per turn in case that fallbacks to human or droiding is involved. I.e. it happens at the middle of turn of human side 1 if the human player droids his side. It happens after the selection of ai to play the turn but before AI is told that new turn has come.<br />
: '''Note:''' ''This event currently breaks replays since it is not explicitly saved in a replay and there is no AI involved in replays...''<br />
<br />
; turn refresh<br />
: Like '''side turn''', triggers just before a side is taking control but '''after''' healing, calculating income, and restoring unit movement and status.<br />
<br />
; turn ''X''<br />
: Triggers at the start of turn ''X''. It's the first side initialization event. <br />
:Side initialization events go in the order of: <br />
: 1) '''turn ''X''''' <br />
:2) '''new turn''' <br />
:3) '''side turn''' <br />
:4) '''side ''X'' turn''' <br />
:5) '''side turn ''X''''' <br />
:6) '''side ''X'' turn ''Y''''' <br />
:7) '''turn refresh''' <br />
:8) '''side ''X'' turn refresh''' <br />
:9) '''turn ''X'' refresh''' <br />
:10) '''side ''X'' turn ''Y'' refresh'''<br />
<br />
; side ''X'' turn ''Y''<br />
: This event triggers at the start of turn ''Y'' of side X {{DevFeature}}<br />
<br />
; side ''X'' turn<br />
: This event triggers at the start of any turn of side X {{DevFeature}}<br />
: '''Note:''' ''Of course, [[#first_time_only|first_time_only=no]] is needed for this event to be triggered more than once.''<br />
<br />
; side turn ''X''<br />
: This event triggers at the start of any side on turn X {{DevFeature1.9}}<br />
: '''Note:''' ''Of course, [[#first_time_only|first_time_only=no]] is needed for this event to be triggered more than once.''<br />
<br />
; side X turn Y refresh<br />
: This event triggers at the turn refresh for side X on turn Y {{DevFeature1.9}}<br />
<br />
; side ''X'' turn refresh<br />
: This event triggers at the turn refresh for side X {{DevFeature1.9}}<br />
: '''Note:''' ''Of course, [[#first_time_only|first_time_only=no]] is needed for this event to be triggered more than once.''<br />
<br />
; turn ''X'' refresh<br />
: This event triggers for any side at the refresh of turn X. {{DevFeature1.9}}<br />
: '''Note:''' ''Of course, [[#first_time_only|first_time_only=no]] is needed for this event to be triggered more than once.''<br />
<br />
; side turn end {{DevFeature1.9}}<br />
: Triggers after a side ends its turn. Like side turn, there are also some variations for specific combinations of side number and turn number. Here is the order in which the turn end events trigger:<br />
:1) '''side turn end''' <br />
:2) '''side ''X'' turn end''' <br />
:3) '''side turn ''X'' end''' <br />
:4) '''side ''X'' turn ''Y'' end''' <br />
:5) '''turn end''' <br />
:6) '''turn ''X'' end''' <br />
<br />
; time over<br />
: Triggers on turn ''turns''. (''turns'' is specified in [scenario])<br />
<br />
; enemies defeated<br />
: Triggers when all units with '''canrecruit=yes''' (that is, all leaders) not allied with side 1 are killed.<br />
<br />
; victory<br />
: 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]])<br />
<br />
; defeat<br />
: 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]])<br />
<br />
<br />
Filters (except [filter_condition] which is for all sorts of events) 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. <br />
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 the '''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 the '''secondary unit''' below). '' These units are also automatically stored in the variables 'unit' and 'second_unit' as if they had been stored using the '''[store_unit]''' tag. see [[SingleUnitWML]]<br />
<br />
; moveto<br />
: Triggers after the primary unit moves. Typically this is used when the primary unit gets to a particular location and a filter for the location of the primary unit is included; remember that this is the location that the primary unit lands on, not the location it started on or any location it travels on. If the unit moves to a village, the capture event will be fired before this event. <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 undo other changes to the game caused by the event. Thus it is up to the scenario designer to use this tag correctly.'' {{DevFeature}} $x2 and $y2 refer to the hex the unit came from.<br />
<br />
; sighted<br />
: '''important: "sighted" events are very buggy in general, especially if "delay shroud updates" is set to "yes". Avoid using them despite of them being (still) used a lot in mainline.''' {{DevFeature1.9}}: It is currently tested whether the introduction of the "whiteboard" feature is accepted, making it possible to remove the "delay shroud updates" option which could in return make this event stable again.<br />
: A '''sighted''' event is triggered when a fog or shroud is lifted from the primary ''unit''. This can happen when a ''second_unit'' moves to a nearby location and discovers the primary ''unit''. Alternatively, the primary ''unit'' might emerge "out of the mist" and be discovered simultaneously by all members of the enemy side: in this case, the ''second_unit'' is not set. (This is part of the sighted event's bugs.)<br />
<br />
: '''Note:''' The sighted event is ''only'' triggered when a unit moves from one location to another. When the player moves to attack an enemy unit and, in the process, removes the fog/shroud over an enemy unit, the sighted event does ''not'' fire. This makes the sighted event unreliable: It may or may not fire, depending on the user actions. (This may be part of the sighted event's bugs.)<br />
<br />
: '''Alternatives:''' It is sometimes possible to replace a sighted event by a moveto event with a [[StandardLocationFilter|location filter]] matching a nearby location. A [[FilterWML#Filtering_Vision|filter_vision]] filter may be useful in some cases.<br />
<br />
; attack<br />
: Triggers when the primary unit attacks the secondary unit.<br />
<br />
; attack end<br />
: Similar to '''attack''', but is triggered ''after'' the fight instead of before. Note that if either unit is killed during the fight, this event triggers before any '''die''' events.<br />
<br />
; attacker hits<br />
: Triggers when the the primary unit (the attacker) hits the secondary unit (the defender). The value of the WML variable '''damage_inflicted''' is set to the number of hitpoints inflicted by the attacker.<br />
<br />
; attacker misses<br />
: Same as ''attacker hits'', but is triggered when the attacker misses.<br />
<br />
; defender hits<br />
: Triggers when the primary unit (the attacker) is hit in retaliation by the secondary unit (the defender). The value of the WML variable '''damage_inflicted''' is set to the number of hitpoints inflicted by the defender.<br />
<br />
; defender misses<br />
: Same as ''defender hits'', but is triggered when the defender misses.<br />
<br />
; stone<br />
: Triggers when the primary unit is hit by an attack with the 'stones' ability (See ''stones'', [[AbilitiesWML]]) by the secondary unit (the unit with the 'stones' ability). In {{DevFeature}}, this event name is changed to "petrified".<br />
<br />
; last breath<br />
: Triggers when the primary unit is killed by the secondary unit, but before the death animation is triggered. Use this instead of name=die when you want the primary unit to make a final [message]. <br />
<br />
; die<br />
: Triggers when the primary unit is killed by the secondary unit. ''Note: The primary unit is not removed from the game until the end of this event. The primary unit can still be manipulated, will block other units from taking its hex, and will still be found by standard unit filters (except [have_unit]). To prevent this behavior, you can use [kill] to remove the unit immediately. However, this will stop any (still unfired) other events that also match the unit from firing afterwards, so use with caution.'' If you want to the primary unit to make a final [message], use name=last_breath, see above.<br />
<br />
; capture<br />
: Triggers when the 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. This event will be fired before the moveto event.<br />
<br />
; recruit<br />
: Triggers when the primary unit is recruited (by the secondary {{DevFeature1.9}}). (That is, when a unit is recruited it will trigger this event and this event's filter will filter that unit.).<br />
<br />
; prerecruit<br />
: Triggers when the primary unit is recruited (by the secondary {{DevFeature1.9}}) but before it is displayed.<br />
<br />
; recall<br />
: Triggers after the primary unit is recalled (by the secondary {{DevFeature1.9}}).<br />
<br />
; prerecall<br />
: Triggers when the primary unit is recalled (by the secondary {{DevFeature1.9}}) but before it is displayed.<br />
<br />
; advance<br />
: Triggers just before the primary unit is going to advance to another unit.<br />
<br />
; post advance<br />
: Triggers just after the primary unit has advanced to another unit.<br />
<br />
; select<br />
: Triggers when the primary unit is selected. Also triggers when ending a move, as the game keeps the moving unit selected by selecting it again at the end of movement. ''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.''<br />
<br />
; menu item ''X''<br />
: 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 />
<br />
==== Custom events ====<br />
<br />
An event with a custom name may be invoked using the [[InternalActionsWML#.5Bfire_event.5D|[fire_event]]] tag. Normally you'll use such custom events as named subroutines to be called by events with predefined types. One common case of this, for example, is that more than one '''sighted''' events might fire the same custom event that changes the scenario objectives.<br />
<br />
=== Optional Keys and Tags ===<br />
<br />
These keys and tags are more complex ways to filter when an event should trigger:<br />
<br />
==== first_time_only ====<br />
: Whether the event should be removed from the scenario after it is triggered. This key takes a [[ConditionalActionsWML#Boolean_Values|boolean]]; for example:<br />
: ''first_time_only=yes''<br />
:: Default behavior if key is omitted. The event will trigger the first time it can and never again.<br />
: ''first_time_only=no''<br />
:: The event will trigger every time the criteria are met instead of only the first time.<br />
<br />
==== id ====<br />
: If an id is specified, then the event will not be added if another event with the same id already exists. An id will also allow the event to be removed, see below.<br />
<br />
==== remove ====<br />
: Whether to remove an event instead of adding a new one. This key takes a [[ConditionalActionsWML#Boolean_Values|boolean]]; if true, then the contents of the event are ignored and the event with the specified id is removed instead. for example:<br />
[event]<br />
id=id_of_event_to_remove<br />
remove=yes<br />
[/event]<br />
<br />
==== [filter] ====<br />
: The event will only trigger if the primary unit matches this filter.<br />
:* [[StandardUnitFilter]]: selection criteria<br />
<br />
==== [filter_second] ====<br />
: Like [filter], but for the secondary unit.<br />
:* [[StandardUnitFilter]]: selection criteria<br />
<br />
==== [filter_attack] ====<br />
: Can be used to set additional filtering criteria for the primary unit and the 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''. For more information and other filter keys, see [[FilterWML]].<br />
:* '''name''': the name of the weapon used.<br />
:* '''range''': the range of the weapon used.<br />
:* '''special''': filter on the attack's special power.<br />
<br />
==== [filter_second_attack] ====<br />
: Like [filter_attack], but for the secondary unit.<br />
:* '''name''': the name of the weapon used.<br />
:* '''range''': the range of the weapon used.<br />
:* '''special''': filter on the attack's special power.<br />
<br />
==== [filter_condition] ====<br />
: {{DevFeature1.9}}<br />
: This tag makes sense inside any sort of event - even those that don't have units, or custom events,... The event will only trigger if this condition evaluates to true.<br />
:* True Condition Tags and Meta Condition Tags as described in [[ConditionalActionsWML]].<br />
: note: This tag is meant to be used when the firing of an event shall be based on variables/conditions which cannot be retrieved from the filtered units.<br />
<br />
==== [filter_side] ====<br />
: {{DevFeature1.9}}<br />
: The current side (usually the side $side_number) must match the passed [[StandardSideFilter]] for the event to fire.<br />
:* SSF tags and keys as arguments as described in [[StandardSideFilter]].<br />
: note: This tag makes most sense in side turn and turn refresh events. However, all wml events have a current side so one could also prevent e.g. a moveto event from firing if you put a [filter_side] tag there and the moving unit's side doesn't match.<br />
<br />
==== delayed_variable_substitution ====<br />
: This key is only relevant inside of a [[#Delayed Variable Substitution|nested event]] and controls when variable substitution will occur in those special case actions.<br />
<br />
=== Actions triggered by [event] ===<br />
<br />
After the trigger conditions have been met, all [[ActionWML|action tags]] within the [event] tag are executed in the order they are written in.<br />
<br />
There are 3 main types of actions:<br />
* direct actions ([[DirectActionsWML]]) which have a direct effect on gameplay<br />
* display actions ([[InterfaceActionsWML]]) which show something to the user<br />
* internal actions ([[InternalActionsWML]]) which are used by WML internally<br />
<br />
More details in [[ActionWML]].<br />
<br />
Several actions use standard filters to find out which units<br />
to execute the command on. These are denoted by the phrases<br />
"standard unit filter" and "standard location filter".<br />
<br />
=== Nested Events ===<br />
<br />
There is one special type of action: event creation. By placing an '''[event]''' tag inside another '''[event]''' tag, the nested event is spawned (created) when the parent (outer) event is encountered (when executing the contents of the parent event).<br />
<br />
([[#Nested Event Example|See Examples]])<br />
<br />
==== Delayed Variable Substitution ====<br />
<br />
Variable substitution for a nested event can happen either when it is spawned by the parent event or when it is triggered itself. This is controlled with the key '''delayed_variable_substitution''' which is used in the nested event.<br />
<br />
If this key is set to ''yes'', the variables in the nested event will contain values from the turn in which the ''nested'' event was triggered. ''This is the default behavior if the key is omitted.'' If set to ''no'', the variables in the nested event are set at the time the ''parent'' event is triggered.<br />
<br />
This behavior can be fine tuned with a special syntax when referencing variables. Instead of the normal '''$variable''' syntax, use '''$|variable''' to cause a variable to contain values relevant to the turn in which the nested event was triggered even when '''delayed_variable_substitution''' is set to ''no''. In this way you can have a mix of variables relevant to the parent and nested event trigger times.<br />
<br />
([[#Delayed Variable Substitution Example|See Examples]])<br />
<br />
== Multiplayer safety ==<br />
<br />
In multiplayer it is only safe to use WML that might require synchronization with other players because of input or random numbers (like [message] with input or options or [unstore_unit] where a unit might advance) in the following events. This is because in these cases WML needs data from other players to work right and/or do the same thing for all players. This data is only available after a network synchronization.<br />
<br />
List of synchronized events:<br />
* moveto<br />
* sighted <br />
* attack<br />
* attack_end <br />
* attacker hits <br />
* attacker misses <br />
* defender hits<br />
* defender misses <br />
* stone<br />
* last breath <br />
* menu item X<br />
* die<br />
* capture <br />
* recruit<br />
* prerecruit <br />
* recall <br />
* prerecall <br />
* advance <br />
* post_advance <br />
getting message options (etc) from the following events is not synchronized, except in the development version (1.9+svn):<br />
* new turn <br />
* side turn <br />
* turn X <br />
* side X turn <br />
* side X turn Y <br />
* turn refresh <br />
<br />
There is also the possibility of events that are normally synchronized when fired by the engine but can be non-synchronized when fired by WML tags from non-synchronized event. So when you are using them you must be extra careful. For example [unstore_unit] may trigger a unit advancement that will fire ''advance'' and ''post advance'' events.<br />
<br />
== A Trap for the Unwary ==<br />
<br />
You need to beware of using macros to generate events. If you include a macro expanding to an event definition twice, the event will be executed twice (not once) each time the trigger condition fires. Consider this code:<br />
<br />
#define DOUBLE<br />
[event]<br />
name=multiply_by_2<br />
{VARIABLE_OP 2_becomes_4 multiply 2}<br />
[/event]<br />
#enddef<br />
<br />
{DOUBLE}<br />
{DOUBLE}<br />
<br />
{VARIABLE 2_becomes_4 2}<br />
<br />
[fire_event]<br />
name=multiply_by_2<br />
[/fire_event]<br />
<br />
{DEBUG_MSG "$2_becomes_4 should be 4"}<br />
<br />
After it executes, the debug message will reveal that the variable has been set to 8, not 4.<br />
<br />
=== Event IDs ===<br />
<br />
{{DevFeature1.9}}<br />
<br />
This problem can be avoided by setting an '''id''' on the event, i.e.:<br />
<br />
#define DOUBLE<br />
[event]<br />
name=multiply_by_2<br />
id=doubler_event<br />
{VARIABLE_OP 2_becomes_4 multiply 2}<br />
[/event]<br />
#enddef<br />
<br />
Events with the same ID will only be accepted once by the engine no matter how many times they are included, and will only be saved once to the scenario's savefile. Events with an ID can also be removed by using the '''remove''' key, i.e.:<br />
<br />
[event]<br />
id=doubler_event<br />
remove=yes<br />
[/event]<br />
<br />
After that WML is encountered (at toplevel or after created from another event), the event with this ID is removed from the scenario wml, thus firing it has no effect. After an event is removed, it can still be re-added later.<br />
<br />
== Miscellaneous Notes and Examples ==<br />
<br />
=== Primary/Secondary Unit Speaker Example ===<br />
<br />
In events, the primary unit can be referred to as '''unit''' and the secondary unit can be referred to as '''second_unit''' in [message] tags using the '''speaker''' key. For example:<br />
<br />
[event]<br />
name=die<br />
[message]<br />
speaker='''second_unit'''<br />
message= _ "Hahaha! I finally killed you!"<br />
[/message]<br />
<br />
[message]<br />
speaker='''unit'''<br />
message= _ "It's not over yet! I'll come back to haunt you!"<br />
[/message]<br />
[/event]<br />
<br />
=== Nested Event Example ===<br />
<br />
An event is created for a portal that opens on turn 10. The parent (or 'outer') event executes on turn 10 at which point the nested moveto event is created. This nested event executes when a player steps on a certain spot.<br />
<br />
[event]<br />
name=turn 10<br />
<br />
[event]<br />
name=moveto<br />
<br />
[filter]<br />
x,y=5,8<br />
[/filter]<br />
<br />
# moving to 5,8 will trigger this event only on turn 10 and after<br />
[/event]<br />
[/event]<br />
<br />
An equivalent way of doing this would be to create a single moveto event with an '''[if]''' statement to check for turn number but using nested '''[event]''' tags is a convenient shortcut to accomplish this task without resorting to '''[if]''' statements.<br />
<br />
=== Delayed Variable Substitution Example ===<br />
<br />
This code will display a message showing the turn number on which the nested ''moveto'' event happens.<br />
<br />
[event]<br />
name=turn 10<br />
<br />
[event]<br />
name=moveto<br />
delayed_variable_substitution=yes<br />
<br />
[filter]<br />
x,y=5,8<br />
[/filter]<br />
<br />
{DEBUG_MSG "Turn $turn_number"} <br />
[/event]<br />
[/event]<br />
<br />
Since this is the default behavior for the '''delayed_variable_substitution''' key, the following example is identical.<br />
<br />
[event]<br />
name=turn 10<br />
<br />
[event]<br />
name=moveto<br />
<br />
[filter]<br />
x,y=5,8<br />
[/filter]<br />
<br />
{DEBUG_MSG "Turn $turn_number"} <br />
[/event]<br />
[/event]<br />
<br />
The following code will always display "Turn 10" when the nested ''moveto'' event happens. This is because the variable substitution is done when the parent event is triggered and spawns the nested event, ''not'' when the nested event is triggered.<br />
<br />
[event]<br />
name=turn 10<br />
<br />
[event]<br />
name=moveto<br />
delayed_variable_substitution=no<br />
<br />
[filter]<br />
x,y=5,8<br />
[/filter]<br />
<br />
{DEBUG_MSG "Turn $turn_number"} <br />
[/event]<br />
[/event]<br />
<br />
Finally, the following example is identical to the first two in that it will display a message showing the turn number on which the nested ''moveto'' event happens, despite the fact that the '''delayed_variable_substitution''' key is set to ''no''. This is because the special '''$|variable''' syntax is used.<br />
<br />
[event]<br />
name=turn 10<br />
<br />
[event]<br />
name=moveto<br />
delayed_variable_substitution=no<br />
<br />
[filter]<br />
x,y=5,8<br />
[/filter]<br />
<br />
{DEBUG_MSG "Turn $|turn_number"} <br />
[/event]<br />
[/event]<br />
<br />
=== Multiple Nested Events ===<br />
<br />
Every delayed_variable_substitution=no causes a variable substitution run on the subevent where it occurs at the spawn time of this event and on all following subevents. For any specific event, variable substitution happens at least one time when the event is executed. For each delayed=no key appearing in itself or in an event of an "older" generation, which is not the toplevel event, an additional variable substitution run is made.<br />
[event]# parent<br />
name=turn 2<br />
#delayed_variable_substitution=no # In the parent event, delayed= has no effect.<br />
<br />
[event]# child<br />
name=turn 3<br />
delayed_variable_substitution=no # Causes variable substitution in the child, grandchild and great-grandchild event<br />
# at execution time of the parent event = spawn time of the child event.<br />
<br />
[event]# grandchild<br />
name=turn 4<br />
delayed_variable_substitution=yes # no variable substitution in the grandchild and great-grandchild event<br />
# at execution time of the child event = spawn time of the grandchild event<br />
<br />
[event]# great-grandchild<br />
name=turn 5<br />
{DEBUG_MSG $turn_number}# output: 2 - value from the variable substitution at execution time of the parent event,<br />
# caused by delayed=no in the child event<br />
<br />
{DEBUG_MSG $||turn_number}# output: "$turn_number"<br />
# Each variable substitution transforms a "$|" to a "$" (except when no | left).<br />
<br />
{DEBUG_MSG $|turn_number}# output: 5 - from the variable substitution at execution time<br />
# of the great-grandchild event<br />
[/event]<br />
[/event]<br />
[/event]<br />
[/event]<br />
<br />
== See Also ==<br />
<br />
* [[DirectActionsWML]]<br />
* [[InternalActionsWML]]<br />
* [[InterfaceActionsWML]]<br />
* [[FilterWML]]<br />
* [[ReferenceWML]]<br />
<br />
<br />
[[Category: WML Reference]]</div>Fabihttps://wiki.wesnoth.org/index.php?title=Template:Compiling_Wesnoth&diff=43897Template:Compiling Wesnoth2011-10-24T22:54:03Z<p>Fabi: </p>
<hr />
<div>{| class="gallery" style="width:175px;float: right;border: 1px solid #B48648; color:#B48648; font-size: 8pt;margin-left;10px;"<br />
|-<br />
|<br />
<span style="float: right;"><small class="editlink noprint plainlinksneverexpand">[{{SERVER}}{{localurl:Template:Compiling Wesnoth|action=edit}} edit ]</small></span><br />
'''Compiling Wesnoth'''<br />
|-<br />
|Platforms<br />
* [[CompilingWesnoth|Linux or Unix]]<br />
* [[WesnothOnLinuxPDAs|Linux PDA]]<br />
* [[CompilingWesnothOnMacOSX|Mac OS X]]<br />
* [[CompilingWesnothOnWindows|MS Windows]]<br />
* [[CompilingWesnothOnSuSE|SuSE]]<br />
* [[CompilingWesnoth/CrossCompiling|cross-compiling]]<br />
|-<br />
|Tools<br />
* [[UsingAutotools|Autotools]] (abandoned)<br />
* [[ccache]]<br />
* [[CMake]]<br />
* [[Dev-Cpp|Dev-C++]]<br />
* [[EclipseCMake|Eclipse (CMake)]]<br />
* [[WesnothSVN|Subversion (SVN)]]<br />
* [[SCons]]<br />
|}</div>Fabihttps://wiki.wesnoth.org/index.php?title=Template:Compiling_Wesnoth&diff=43896Template:Compiling Wesnoth2011-10-24T22:51:39Z<p>Fabi: </p>
<hr />
<div>{| class="gallery" style="width:175px;float: right;border: 1px solid #B48648; color:#B48648; font-size: 8pt;margin-left;10px;"<br />
|-<br />
|<br />
<span style="float: right;"><small class="editlink noprint plainlinksneverexpand">[{{SERVER}}{{localurl:Template:Compiling Wesnoth|action=edit}} edit ]</small></span><br />
'''Compiling Wesnoth'''<br />
|-<br />
|Platforms<br />
* [[CompilingWesnoth|Linux or Unix]]<br />
* [[WesnothOnLinuxPDAs|Linux PDA]]<br />
* [[CompilingWesnothOnMacOSX|Mac OS X]]<br />
* [[CompilingWesnothOnWindows|MS Windows]]<br />
* [[CompilingWesnothOnSuSE|SuSE]]<br />
* [[CompilingWesnoth/CrossCompiling|cross-compiling]]<br />
|-<br />
|Tools<br />
* [[UsingAutotools|Autotools]] (abandoned)<br />
* [[ccache]]<br />
* [[CMake]]<br />
* [[EclipseCMake|Eclipse (CMake)]]<br />
* [[Dev-Cpp|Dev-C++]]<br />
* [[WesnothSVN|Subversion (SVN)]]<br />
* [[SCons]]<br />
|}</div>Fabihttps://wiki.wesnoth.org/index.php?title=StandardLocationFilter&diff=43655StandardLocationFilter2011-09-09T23:49:20Z<p>Fabi: </p>
<hr />
<div>{{WML Tags}}<br />
<br />
From [[FilterWML]], this is the standard way of filtering on locations.<br />
The term [[StandardLocationFilter]] means that the set of such keys and tags (see below) can appear at that point. Sometimes a [[StandardLocationFilter]] needs to be included in a [filter_location] tag. There are however many tags which accept the [[StandardLocationFilter]] directly as an argument such as [store_locations]. Generally, if the tag [filter_location] is not mentioned to be a possible subtag of the outer tag in question, then don't put it.<br />
<br />
The following attributes and sub-tags are permitted:<br />
<br />
* '''time_of_day''': filter matches only on a given time of day (one of lawful, chaotic, neutral or liminal). Note: ''chaotic'', ''lawful'', ''neutral'' and ''liminal''; these are not times of day, these are ''alignments''. To match against 'dawn', 'dusk', 'first watch' etc., use the '''time_of_day_id''' key described below.<br />
* '''time_of_day_id''': this accepts a list of one or more actual times of day, separated by commas. These IDs are taken from '''data/core/macros/schedules.cfg'''. Permissible values are case-sensitive: dawn, morning, afternoon, dusk, first_watch, second_watch, indoors, underground and deep_underground. <br />
* '''terrain''': comma separated list of terrains. (See also: [http://www.wesnoth.org/wiki/FilterWML#Filtering_Terrains Filtering Terrains]).<br />
* '''x,y''': the same as in the unit filter; supports any range ([http://www.wesnoth.org/wiki/StandardLocationFilter#Notes_about_Coordinate_Usage notes])<br />
* '''[filter]''' with a [[StandardUnitFilter]] as argument; if present a unit must also be there<br />
* '''owner_side''': the side of the owner, if this location is an owned village.<br />
* '''find_in''': name of an array or container variable; if present, the location will not match unless it is also found stored in the variable<br />
* '''radius''': matches if any location within the radius matches this filter ([http://www.wesnoth.org/wiki/StandardLocationFilter#Notes_about_Radius_Usage notes])<br />
* '''[filter_radius]''': a standard location filter; normally the radius extends outwards from matching locations one step at a time without checking any additional information-- however, if this tag is present, the radius will be restricted so that it can only expand outwards in the directions where it passes the given location filter<br />
* '''[and]''': an extra location filter. Unless a location matches the [and] filter, then it will be excluded. ''Note: [and],[or],and [not] extra location filters are considered after everything else in the containing filter (except radius, which is considered last in 1.3.8 and greater); they are then processed in the order encountered.''<br />
* '''[or]''': an extra location filter. If a location matches the [or] filter, then it will count as a match regardless of conditions in previous filters or the containing filter.<br />
* '''[not]''': an extra location filter. If a location matches the [not] filter, then that location will be excluded.<br />
* '''[filter_adjacent_location]''': a standard location filter; if present the correct number of adjacent locations must match this filter<br />
** '''count''': a number, range, or comma separated range; default "1-6"<br />
** '''adjacent''': a comma separated list of directions; default "n,ne,se,s,sw,nw"<br />
<br />
==Notes about Coordinate Usage==<br />
When specifying coordinates, the following keys are used:<br />
* '''x''': the first coordinate<br />
* '''y''': the second coordinate<br />
<br />
While some locations should only be one hex (like the starting position of a unit),<br />
others filter over multiple hexes.<br />
The following syntax is used to filter over multiple hexes:<br />
<br />
Dashes('''-''') are used to have the location be a range of hexes.<br />
There must be values before and after the dash;<br />
everything in between these numbers (inclusively) is part of the range.<br />
<br />
Commas(''',''') are used to separate coordinates into a list.<br />
The '''x''' and '''y''' lists are then paired up, with each pair representing one hex or range.<br />
<br />
Note: although the ordering of locations in a list generally does not matter,<br />
the action '''[move_unit_fake]''' takes in a list of hexes,<br />
and moves an image onto each of those hexes in order.<br />
<br />
==Notes about Radius Usage==<br />
:If you aren't storing any locations successfully, it may be because you put the radius or filters in the wrong place for them to combine correctly.<br />
[have_location]<br />
terrain=Gg^Vh<br />
[and]<br />
x=$x1<br />
y=$y1<br />
radius=1<br />
[/and]<br />
[/have_location]<br />
Note that the use of [and] here causes the radius to have a very different meaning. Normally, all of the criteria besides radius are checked, producing a set of hexes to which the radius is applied. This means, for example, that if you're trying to find "a hex without a unit on it within 5 hexes of (15, 23)", the code:<br />
[have_location]<br />
x,y=15,23<br />
radius=5<br />
[not]<br />
[filter]<br />
[/filter]<br />
[/not]<br />
[have_location]<br />
will not work! First, it looks for a hex with x=15, y=23 without a unit on it. Then, it returns that hex and all hexes within 5 of it. If (15, 23) happens to be occupied, then it will return no hexes, because "all hexes within 5 hexes of (no hexes)" is still "no hexes". Instead, put an [and] around the x,y and radius requirements, and it will separately find "(15, 23) and all hexes within 5 of it" and "each of those hexes that doesn't have a unit on it", producing the desired result.<br />
[[Category: WML Reference]]</div>Fabihttps://wiki.wesnoth.org/index.php?title=UnitTypeWML&diff=43644UnitTypeWML2011-09-08T17:13:59Z<p>Fabi: /* The [unit_type] tag */</p>
<hr />
<div>{{WML Tags}}<br />
== The [unit_type] tag ==<br />
<br />
Each '''[unit_type]''' tag defines one unit type. (for the use of [unit] to create a unit, see [[SingleUnitWML]])<br />
<br />
Unit animation syntax is described in [[AnimationWML]].<br />
<br />
The following key/tags are recognized:<br />
{| class="gallery" style="text-align:left;"<br />
|-<br />
! [advancefrom]<br />
| the previous level unit on the advancement tree<br />
- allows a campaign-specific unit to be spliced into an already existing advancement tree. It should generally be used only inside a campaign ifdef, to prevent changes to other campaigns. This tag makes changes to the ''advances_to'' and ''experience'' keys of a base unit to make it advance into this unit. It takes these keys:<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 the experience needed to advance is set to this value. ({{DevFeature1.9}}, in 1.8 it can only be lowered) If there are more than one [advancefrom] tags referencing the same base unit within the same preprocessor scope (e.g. a campaign #ifdef) with experience= keys, the lowest value of these is chosen. Note: this will also lower the experience required to advance to other units which the base unit can advance into.<br />
|-<br />
! advances_to<br />
| When this unit has'' experience'' greater than or equal to ''experience'', it is replaced by a unit of the type that the value of ''advances_to'' refers to. All modifications that have been done to the unit are applied to the unit it is replaced by. The special value 'null' says that the unit does not advance but gets an AMLA instead.<br />
|-<br />
! alignment <br />
| one of lawful/neutral/chaotic/liminal (See [[TimeWML]]). Default is "neutral".<br />
|-<br />
! attacks<br />
| the number of times that this unit can attack each turn.<br />
|-<br />
! cost<br />
| 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.<br />
|-<br />
! description<br />
| (translatable) the text displayed in the unit descriptor box for this unit. Default 'No description available...'. <br />
|-<br />
! do_not_list<br />
| Not used by the game, but by tools for browsing and listing the unit tree. If this is 'yes', the unit will be ignored by these tools. <br />
|-<br />
! ellipse<br />
| the ellipse image to display under the unit, which is normally team-colored. Default is the normal ellipse; "misc/ellipse-nozoc" is a dashed ellipse that should be used for units without zone of control.<br />
|-<br />
! experience<br />
| When this unit has experience greater than or equal to ''experience'', it is replaced by a unit with 0 experience of the type that the value of ''advances_to'' refers to. All modifications that have been done to the unit are applied to the unit it is replaced by.<br />
|-<br />
! gender<br />
| 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.<br />
|-<br />
! hide_help<br />
| determines if the unit type will appear in the in-game help. Possible values ''true'' and ''false'', defaults to ''false''.<br />
|-<br />
! hitpoints<br />
| the maximum HP that the unit has, and the HP it has when it is created.<br />
|-<br />
! id<br />
|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<br />
WARNING : characters "$", "&", "*", "(" and ")" are illegal for use in the unit id and must be avoided because they might lead to corrupted saved games<br />
|-<br />
! level<br />
| the amount of upkeep the unit costs. After this unit fights, its opponent gains ''level'' experience. See also kill_experience ([[GameConfigWML]]), and leadership ([[AbilitiesWML]]).<br />
|-<br />
! movement<br />
| the number of move points that this unit recieves each turn.<br />
|-<br />
! movement_type<br />
| See '''movetype''', [[UnitsWML]]. Note that the tags '''movement_costs''', '''defense''', and '''resistance''' can be used to modify this movetype.<br />
|-<br />
! name<br />
|(translatable) displayed in the Status Table for units of this type.<br />
|-<br />
! num_traits<br />
| the number of traits that units of this type should receive when they are recruited, overriding the value set in the [race] tag.<br />
|-<br />
! profile<br />
| the portrait image to use for this unit type. You can also set a portrait for an individual unit instead of the whole unit type (see [[SingleUnitWML]]). The engine first looks for the image in the transparent subdirectory and if found that image is used. If not found it will use the image as-is. Depending on the size the engine will or will not scale the image, the cuttoff currently is at 300x300. For images which should only be shown on the right side in the dialog append ~RIGHT() to the image.<br />
|-<br />
! small_profile {{DevFeature1.9}}<br />
| the image to use when a smaller portrait is needed than the one used for messages (e.g., in the help system). When this attribute is missing, the value of the '''profile''' attribute is used instead. When present, the heuristic for finding a transparent portrait is disabled for the '''profile''' attribute, so the correct '''profile''' should be set too. Note that image modifiers are allowed; they might be useful for cropping and rescaling a portrait:<br />
small_profile="portraits/elves/transparent/marksman+female.png~CROP(0,20,380,380)~SCALE(205,205)"<br />
profile="portraits/elves/transparent/marksman+female.png"<br />
|-<br />
! race<br />
| See '''[race]''', [[UnitsWML]]. Also used in standard unit filter (see [[FilterWML]]).<br />
|-<br />
! undead_variation<br />
| Which image to use when a unit of this type is killed by a unit with the plague ability.<br />
|-<br />
! usage<br />
| the way that the AI should recruit this unit, as determined by the scenario designer. (See ''recruitment_pattern'', [[AiWML]]). The following are conventions on usage:<br> ** ''scout'': Fast, mobile unit meant for exploration and village grabbing.<br> ** ''fighter'': Melee fighter, melee attack substantially more powerful than ranged.<br> ** ''archer'': Ranged fighter, ranged attack substantially more powerful than melee.<br> ** ''mixed fighter'': Melee and ranged fighter, melee and ranged attacks roughly equal.<br> ** ''healer'': Specialty 'heals' or 'cures'.<br>Note that this field affects only recruitment, not the AI's behavior in combat; that is always computed from attack power and hitpoints. <br />
|-<br />
! zoc<br />
| 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).<br />
|}<br />
==== After max level advancement (AMLA) ====<br />
* '''[advancement]''': describes what happens to a unit when it reaches the XP required for advancement. It is considered as an advancement in the same way as advancement described by '''advances_to'''; however, if the player chooses this advancement, the unit will have one or more effects applied to it instead of advancing.<br />
** '''always_display''': if set to true displays the AMLA option even if it is the only available one.<br />
** '''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.<br />
** '''image''': an image to display next to the description in the advancement menu.<br />
** '''max_times''': default 1. The maximum times the unit can be awarded this advancement.<br />
** '''strict_amla''': (yes|no) default=no. Disable the AMLA if the unit can advance to another unit.<br />
** '''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.<br />
*** example: <tt>require_amla=tough,tough,incr_damage</tt> assumes there exist other [advancement] options called ''id=tough'' and ''id=incr_damage''. Once ''tough'' is chosen twice and ''incr_damage'' is chosen once, then the current [advancement] will become available.<br />
*** ''require_amla=tough,incr_damage,tough'' is an equivalent way of expressing this.<br />
** '''[effect]''': A modification applied to the unit whenever this advancement is chosen. See [[EffectWML]]<br />
<br />
==== Attacks ====<br />
* '''[attack]''': one of the unit's attacks.<br />
** '''description''': a translatable text for name of the attack, to be displayed to the user.<br />
** '''name''': the name of the attack. Used as a default description, if ''description'' is not present, and to determine the default icon, if ''icon'' is not present (if ''name=x'' then ''icon=attacks/x.png'' is assumed unless present). Non-translatable. Used for the ''has_weapon'' key and animation filters; see [[StandardUnitFilter]] and [[AnimationWML]]<br />
** '''type''': the damage type of the attack. Used in determining resistance to this attack (see '''[resistances]''', [[UnitsWML]]).<br />
** '''[specials]''': contains the specials of the attack. See [[AbilitiesWML]].<br />
** '''icon''': the image to use as an icon for the attack in the attack choice menu, as a path relative to the images directory.<br />
** '''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.<br />
** '''damage''': the damage of this attack<br />
** '''number''': the number of strikes per attack this weapon has<br />
** '''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.<br />
For those two following settings, the engine usually chooses the attack with the best average total damages * weight (default weight = 1.0).<br />
** '''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<br />
** '''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 <br />
<br />
==== Animations ====<br />
See [[AnimationWML]] for details on how to specify animations for the unit.<br />
<br />
==== Other tags ====<br />
* '''[base_unit]''': Contains one attribute, '''id''', which must be the ID of a unit type. If specified, the UnitTypeWML for that unit is copied into this one. Subsequent attributes modify the copy. (1.3.7 and later versions only.)<br />
<br />
* '''[abilities]''': Defines the abilities of a unit. See [[AbilitiesWML]]<br />
<br />
* '''[event]''': Any [event] written inside the [unit_type] tag will get included into any scenario where a unit of this type appears in. Note that such events get included when a unit of this type first appears in the scenario, not automatically when the scenario begins (meaning that ''name=prestart'' events, for example, would usually never trigger). See [[EventWML]] and [[WML_Abilities]]<br />
<br />
* '''[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.<br />
** '''variation_name''': The name of the variation.<br />
** '''inherit''': if ''yes'', inherits all the properties of the base unit. Defaults to no.<br />
: All other keys in '''[variation]''' are the same as for '''[unit_type]''' itself.<br />
<br />
* '''[male]''', '''[female]''': They can contain all '''[unit_type]''' tags, to specify a variation of different gender for a unit.<br />
** '''inherit''': if ''yes'', inherits all the properties of the base unit. Defaults to yes.<br />
<br />
== See Also ==<br />
<br />
* [[AnimationWML]]<br />
* [[ReferenceWML]]<br />
* [[TerrainWML]]<br />
<br />
[[Category: WML Reference]]</div>Fabihttps://wiki.wesnoth.org/index.php?title=TimeWML&diff=43643TimeWML2011-09-08T17:10:42Z<p>Fabi: /* The [time] and [illuminated_time] tags */</p>
<hr />
<div>{{WML Tags}}<br />
<br />
The time of day influences damage done by lawful and chaotic units; this makes timing of your attack important.<br />
Graphically time of day is represented by a picture (landscape with sun or moon) in the status table, and by darkening the screen during night turns.<br />
<br />
Scenario author can schedule the times of day in scenario; use the pre-defined time macros, or create new times of day.<br />
<br />
== The [time] and [illuminated_time] tags ==<br />
<br />
The [time] tag is a subtag of the [scenario] tag. However, most scenarios do not use these directly, but usually use the ready macros '''{DAWN}, {MORNING}, {AFTERNOON}, {DUSK}, {FIRST_WATCH}, {SECOND_WATCH}''' and '''{UNDERGROUND}''' to specify the day-night cycle.<br />
See '''data/core/macros/schedules.cfg''' for the definitions of these IDs.<br />
<br />
The [time] tag describes a single turn of a day/night sequence. When a scenario is played, the first turn is described by the first [time] tag; the second described by the second, until there are no more. After all the tags have described a turn, the next turn is described by the first tag again.<br />
<br />
<br />
The [time] tag recognizes the following keys:<br />
<br />
* '''id''': the id by which you can reference this time, e.g. in the ''time_of_day'' tag of [[AiWML]].<br />
* '''name''': (translatable) the name displayed when the cursor is over the day/night image.<br />
* '''image''': the image displayed at the top of the Status Table during turns of this type.<br />
* '''mask''': the image displayed over all hexes during turns of this type.<br />
* '''lawful_bonus''': units with '''alignment=lawful''' do +''lawful_bonus'' % damage during turns of this type. Units with '''alignment=chaotic''' do -''lawful_bonus'' % damage. Units with '''alignment=neutral''' are unaffected by this key. Units with '''alignment=liminal''' do -(abs(''lawful_bonus'')) % damage. ''lawful_bonus'' can be a negative number. This is useful if you want to give Chaotic units an advantage instead of Lawful ones.<br />
* '''red''', '''green''', '''blue''': describe the tint of the screen during the time period. Appears to be an integer value from -255 to 255. See schedules.cfg for examples.<br />
* '''sound''': a sound to play (in sounds/) when changing into this time of day.<br />
<br />
=== Scheduling time ===<br />
<br />
The [scenario] tag contains a few [time] tags (or macros).<br />
These time tags are used in a loop, that is: first time tag is used during the first turn, then second one,... and when all time tags passed then again the first one, second one, etc.<br />
<br />
The typical day/night cycle looks like this:<br />
<br />
{DAWN}<br />
{MORNING}<br />
{AFTERNOON}<br />
{DUSK}<br />
{FIRST_WATCH}<br />
{SECOND_WATCH}<br />
<br />
To avoid day/night cycle, use a neutral time of day, for example:<br />
<br />
{DAWN}<br />
<br />
In underground, use a special time of day.<br />
It works like night; that is it gives advantage to chaotic units and disadvantage to lawful units.<br />
<br />
{UNDERGROUND}<br />
<br />
== See Also ==<br />
<br />
* [[ScenarioWML]]<br />
* [[ReferenceWML]]<br />
<br />
<br />
[[Category: WML Reference]]</div>Fabihttps://wiki.wesnoth.org/index.php?title=Timeline_of_Wesnoth&diff=42925Timeline of Wesnoth2011-06-07T00:12:52Z<p>Fabi: /* 123 YW */</p>
<hr />
<div>This is a chronological history of the country of Wesnoth and surrounding regions, gleaned from written accounts and verbal histories passed down through the generations. Portions of entries surrounded by parentheses and containing a question mark are assumed or unconfirmed information. The history is sorted by era, and within the era by date, using the Foundation of Wesnoth as a base. BW=Before Wesnoth, YW=Years Wesnoth. They function the same way as BC and AD do in our timekeeping system. Each of the eras is summarized before the timeline for that era begins. This history of the Great Continent is a subject of active scholarship.<br />
<br />
The world that Wesnoth resides in is called Irdya. Before the Fall and the (unchronicled) technological age, this name is only rarely used. <br />
<br />
<br />
'''Spoiler warning!'''<br />
This page contains plot spoilers to several campaigns.<br />
<br />
__NOTOC__<br />
[[#Prehistory - 20 YW: The Founding of Wesnoth|The Founding of Wesnoth]]<br />
<br />
[[#20-130 YW: The Taming of the Wild|The Taming of the Wild]]<br />
<br />
[[#200-350 YW: The Golden Age of Wesnoth|The Golden Age of Wesnoth]]<br />
<br />
[[#350-417 YW: The First Dark Age of Wesnoth|The First Dark Age of Wesnoth]]<br />
<br />
[[#417-530 YW: The Turmoil of Asheviere|The Turmoil of Asheviere]]<br />
<br />
[[#530-630 YW: The Age of Fear|The Age of Fear]]<br />
<br />
[[#628-673 YW: The Silver Age of Wesnoth|The Silver Age of Wesnoth]]<br />
<br />
[[#761-816 YW: The Legacy of Black-Eye Karun|The Legacy of Black-Eye Karun]]<br />
<br />
[[#After the Fall|After the Fall]]<br />
<br />
== Prehistory - 20 YW: The Founding of Wesnoth ==<br />
During the age of the Founding of Wesnoth, there were two important geographic locations, these being the Green Isle and the Great Continent. Haldric is the main historical figure at this time. This age ends with the founding of Wesnoth as a country in the Great Continent, and with Orcs attacking both elves and men from the sea.<br />
<br />
=== Prehistory ===<br />
* Elves and Dwarves inhabit the Great Continent.<br />
* Humans inhabit the distant West.<br />
* Haldric's people colonise the Green Isle from a continent further to the west.<br />
<br />
=== 200 BW ===<br />
* The Lich-Lords arrive on the Green Isle after losing a war in the distant West.<br />
* After a long war Haldric's people come to dominate the Green Isle.<br />
* The 'Wesfolk' and their Lich-Lords are pushed onto marginal lands.<br />
<br />
=== 12 BW ===<br />
* The Crown Prince of Southbay discovers the Great Continent.<br />
<br />
=== 11-7 BW ===<br />
* The Crown Prince makes several voyages between the Green Isle and the Great Continent.<br />
<br />
=== 6 BW ===<br />
* Following these voyages to the Great Continent, the elder Crown Prince falls ill and dies.<br />
* His younger brother is implicated in a plot to kill him.<br />
* As a distraction the younger Prince starts a war with the Wesfolk and their Lich-Lords.<br />
* The Lich-Lords sense they will be destroyed and open gates to the homeland of the Orcs in the West.<br />
<br />
=== 5-2 BW ===<br />
* The Green Isle is overrun with Orcs.<br />
* The Wesfolk desert their Lich-Lords as they fear becoming prey for the Orcs.<br />
* Prince Haldric leads the evacuation of the survivors to the Great Continent. '''The Rise of Wesnoth''' begins.<br />
<br />
=== 1 BW ===<br />
* Human settlers, led by Prince Haldric, arrive at the western coast of the Great Continent (the landfall occurs in the future Bay of Pearls) in large numbers.<br />
* Humans arrive in the middle of a simmering dispute between the Elves and Dwarves.<br />
* The Elves and Dwarves are distrustful of humans, and there is a small skirmish.<br />
* Messengers from Wesmere Forest come and ask Haldric to come before the Ka'lian.<br />
* Prince Haldric asks the Four Elvish Lords (Dionli, Logalmier, Aryad, and El'Isomithir) for help and land.<br />
* They set before him four quests to prove his worth, which he completes.<br />
<br />
=== 1 YW ===<br />
* Haldric is granted the plains north and south of the Great River.<br />
* Haldric agrees to a Pact of Mutual Defence with the Elves, but the Ka'lian decides it will betray him and allow humans and orcs to exhaust each other in war if the opportunity presents. Haldric, learning of this, considers the Pact a dead letter.<br />
* The Ruby of Fire is temporarily hidden, and the lich-lord Jevyan is deceived into believing it is held by the Elves. <br />
* Haldric founds the country of Wesnoth in the central plain south of the great River.<br />
* Reign of Haldric I begins. '''The Rise of Wesnoth''' ends.<br />
<br />
=== 2 YW ===<br />
* Orcs, following the ships fleeing from the Green Isle, begin to arrive on the Great Continent.<br />
* These Orcs are defeated by Haldric's forces.<br />
* Some of the Orcish survivors flee back to the Green Isle, others move to attack the Elves.<br />
* King Haldric helps the Elves fight the surviving Orcs.<br />
<br />
=== 8 YW ===<br />
* A second wave of Orcs arrive from the Green Isle; these Orcs begin claiming large portions of the northern Great Continent for themselves.<br />
* Erlornas of Wesmere is involved in the first direct elvish clash with orcs ('''An Orcish Incursion''' takes place in 8-9YW).<br />
* Haldric I publicly repudiates the Pact he spoke with the Elves, refusing to give aid.<br />
<br />
=== 9-11 YW ===<br />
* Many Elves are killed in battle by the Orcs.<br />
* Elvish emissaries are turned away from Wesnoth.<br />
<br />
=== 12 YW ===<br />
* Orcs fail to take the Wesmere Forest and instead march down the coast, devastating human settlements there.<br />
* Elves refuse to aid the Humans in confronting the Orcs.<br />
* Human refugees from the coastal settlements relocate in what will become known as the Great Central Plain. Dan'Tonk, which will become Wesnoth's largest city, is founded.<br />
<br />
=== 20 YW ===<br />
* Haldric I dies.<br />
* Haldric II ascends to the throne.<br />
* Kalenz and Landar escape an orcish invasion of their home in Lintanir Forest. '''The Legend of Wesmere''' begins.<br />
* Humans and elves decisively defeat the orcs at Tath, thus halting the orcish advance.<br />
* A new treaty between humans and elves is signed and King Haldric II allows emissaries of the Elves to return to Wesnoth.<br />
* Elves inform Haldric II of the danger posed by the unshielded Ruby of Fire.<br />
* Kalenz and Landar, later to become successive High Lords of the Elves, are able to sneak into an orcish camp by stealth and assassinate the Great Chief. A long orcish civil war for succession follows. The orcs are unable to undertake action against any other race during this period and Wesnoth enjoys a long period during which it can expand with little opposition.<br />
<br />
== 20-130 YW: The Taming of the Wild ==<br />
This era is that in which the kingdom of Wesnoth expanded and defined its borders, and settled the area which it had claimed for its own. The Taming of the Wild refers to the settling of the unsettled lands, as well as to the colonization of the Northlands. The end of this era is marked by friction between the city-state of Elensefar and the country of Wesnoth, which will continue for the next several hundred years.<br />
<br />
=== 21 YW ===<br />
* Founding of the Great Academy on Alduin.<br />
<br />
* Kalenz is relieved of command by the Ka'lian. He retires to Lintanir Forest with Cleodil. A faction of xenophobic elves begins to gether around Landar.<br />
<br />
=== 25-40 YW ===<br />
* In 25 YW Haldric II sends an expedition to retrieve the Ruby of Fire from its place of concealment.<br />
* Haldric II commissions a Dwarven tribe to build the Scepter of Fire with the Ruby of Fire as its centerpiece; Elves associated with Landar's faction attack during the transfer. '''Scepter of Fire''' begins.<br />
* Action of '''The Scepter of Fire''' takes place. Haldric II is informed that the Scepter was both completed and lost in the year 40. It will not be recovered for nearly 500 years.<br />
* With the death of Thursagan, the Runemaster, all runemasters are killed and runesmithing is lost for several centuries.<br />
<br />
=== 26-50 YW ===<br />
* Landar declares himself High Lord of the Elves, leading to civil war. <br />
<br />
=== 51 YW ===<br />
* Wesnothian New Writing (the script later called "steel-hand", to distinguish it from the more complex "brush-hand" cursive brought from the Green Isle) is promulgated by royal decree. From this date all royal documents and public inscriptions are in New Writing. It spreads rapidly via the mercantile class. The older brush-hand writing continues to be used for magical purposes, scholarship, and in certain elevated literary forms.<br />
<br />
=== 50-93 YW ===<br />
* Elvish civil war (and '''The Legend of Wesmere''') ends. Kalenz declared High Lord, begins reorganizing and militarizing Elvish society to fight the orcs. In late 93 YW he cedes control to a reconstituted Ka'lian and retires again to the Forest of Lintanir.<br />
<br />
=== 121 YW ===<br />
* Orcish civil war sputters to a halt. Raids on elves and humans resume. Period of uncontested human expansion ends, but the Wesnothian Army is more than equal to any of its opponents in battle.<br />
<br />
=== 122 YW ===<br />
* City of Elensefar is sacked by orcs.<br />
* Meneldur, a sailor of Elensefar, sets out on a quest to regain the city. UMC '''Saving Elensefar''' begins.<br />
<br />
=== 123 YW ===<br />
* Elensefar is retaken by Meneldur along with Undead from the Green Isle.<br />
* Elensefar becomes an independent city-state for the first time. UMC '''Saving Elensefar''' ends.<br />
<br />
=== 161-164 YW ===<br />
* The newly crowned king sought to make safe once and for all the wildlands that separated the human cities surrounding Weldyn and the coastal regions of Elensefar.<br />
* The grand army of Wesnoth, personally led by the High Council of Archmagi, destroyed all enemies residing within Wesnoth.<br />
* The city-state of Elensefar is formally united to the kingdom. Settlements from it spread north of the river into the new frontier province of Annuvin, carefully avoiding the margins of Wesmere Forest.<br />
<br />
=== 164-176 YW ===<br />
* During this twelve year span, the western fortress of Halstead was erected in the very heart of the western wilderlands.<br />
<br />
=== 199 YW ===<br />
* Emboldened by the far-reaching arm of Halstead's protection, settlement in the west explodes<br />
* The settlements of Aldril and Carcyn grow to become major cities, the first as an important port due to its position on the Bay of Pearls, and the second as a stop on the road to Elensefar and military outpost along the Great River<br />
* Settlers from Carcyn cross the Great River to establish the first settlements north of it and east of Wesmere.<br />
<br />
== 200-350 YW: The Golden Age of Wesnoth ==<br />
The Golden Age of Wesnoth was the time of the great kings, and of peace and prosperity within the kingdom. The Orcs had suffered a grave defeat at the hands of Wesnoth and Elensefar seventy-five years earlier, so they did not pose much of a threat, and whenever they did attack they were quickly defeated. This allowed the army to lessen in size, and the kings of this age to undertake the great public works they are renowned for. The era ends when the king of Wesnoth dies without an heir, and a new dynasty begins.<br />
<br />
=== 251 YW ===<br />
* Cleodil, wife of Kalenz, dies.<br />
<br />
=== 350 YW ===<br />
* Disintegration of the Kingdom follows the death of Haldric IV.<br />
* Elensefar remains a province of Wesnoth but exerts increasing independence due to isolation.<br />
* Treaty between lord of Elensefar and king of Wesnoth signed.<br />
<br />
== 350-417 YW: The First Dark Age of Wesnoth ==<br />
The first Dark Age was a time of strife and invasion. When Haldric IV died, he left Wesnoth without a king, and the next 70 years were marked by short-lived dynasties, attacks by ever more aggressive orcs, and the further separation of Wesnoth and Elensefar. The Dark Age ended when Garard I took the throne, and began a new dynasty that would last for several hundred years.<br />
<br />
=== 360 YW ===<br />
* Malin Keshar born in Parthyn.<br />
<br />
=== 363 YW ===<br />
* Last of Kalenz's children dies. Kalenz, condemned to outlive his offspring by the potion of Crelanu, leaves the Forest of Lintanir and begins wandering the Great Continent.<br />
<br />
* Village of Maghre terrorized by a minor necromancer. Action of '''A Tale of Two Brothers''' takes place.<br />
<br />
=== 389 YW ===<br />
* Garard, a future king of Wesnoth, is born.<br />
* Malin Keshar returns to Parthyn from the Academy at Alduin. '''Descent Into Darkness''' begins.<br />
<br />
== 417-530 YW: The Turmoil of Asheviere ==<br />
King Garard's dynasty was long-lived and productive, but it was also punctuated by significant turmoil: the end of the first king's reign was marred by orcish and undead raids, and the second was murdered by his own wife and son. It was not until 517 YW that the usurpation of the throne by Queen Mother Asheviere was ended.<br />
<br />
=== 417 YW ===<br />
* Ending years of strife and division, Garard I seizes the throne and becomes king of Wesnoth, beginning the [[Garardine Dynasty]].<br />
<br />
=== 440 YW ===<br />
* Crown Prince Garard II is born.<br />
<br />
=== 442 YW ===<br />
* Delfador, later called "the Great", is born.<br />
<br />
=== 450 YW ===<br />
* Prince Arand is born.<br />
<br />
=== 468 YW ===<br />
* Zorlan becomes Great Chief of the northern orcs<br />
* Delfador graduates from the Great Academy. '''Delfador's Memoirs''' begins.<br />
<br />
=== 470 YW ===<br />
* Garard I dies; Garard II ascends to the throne of Wesnoth<br />
* Orcs under Great Chief Zorlan and undead raised by the necromancer Iliah-Malal raid Wesnoth's borders. All but the first and the last three scenarios of '''Delfador's Memoirs''' take place in this year.<br />
* Control of the Estmarks is effectively lost during this war, not to be regained for decades. Outposts are built on the near side of the Weldyn to repel orc raids. The long watch of the River Guard begins.<br />
<br />
=== 478 YW ===<br />
* Garard II marries Asheviere.<br />
* Garard issues the Edict of the Scepter, providing that the crown shall settle after his death on whichever member of the royal family successfully retrieves it from the Caverns of Flame.<br />
<br />
=== 480 YW ===<br />
* Crown Prince Eldred is born.<br />
<br />
=== 483 YW ===<br />
* Erain and Ethyn, identical twins and brothers of Eldred, are born.<br />
<br />
=== 498 YW ===<br />
* Princess Li'sar is born.<br />
<br />
=== 500 YW ===<br />
* Prince Konrad is born, the youngest of several sons of Prince Arand.<br />
* Wesnoth and the orcs of the north go to war.<br />
<br />
=== 501 YW ===<br />
<br />
===== Betrayal on the battlefield =====<br />
* Garard leads his army to orc encampment at Galcadar by the Ford of Abez.<br />
* Garard's forces split into two groups, one led by himself and the other by his son Eldred.<br />
* Eldred betrays his father and attacks him with the troops under his control.<br />
* Eldred slays King Garard and his uncle Prince Arand on the battlefield of Abez.<br />
<br />
===== Reprisal =====<br />
* Delfador escapes the battle and heads to Weldyn.<br />
* Eldred gives tribute to the Orcish king, who stops his attacks.<br />
* Delfador gathers a force of Loyalists to avenge Garard's Death.<br />
* Eldred's forces confront Delfador's Loyalists at Weldyn.<br />
* The Loyalists are defeated, but Eldred is slain by Delfador in the fight.<br />
<br />
===== Asheviere seizes power =====<br />
* Asheviere orders the slaughter of Garard's nephews and declares herself Queen of Wesnoth.<br />
* Hearing of the news Delfador infiltrates the palace.<br />
* Delfador finds the youngest prince Konrad as he is slain.<br />
* Delfador flees, taking Konrad's body for burial to the land of the Elves.<br />
* While traveling through Wesnoth, Elf Lady Parandra finds an orphaned human child.<br />
* Parandra and Delfador agree to give the orphan the identity of Prince Konrad.<br />
* Delfador and Konrad flee to live in refuge with the Wood Elves of the great southwestern forest.<br />
<br />
===== The country resists Asheviere =====<br />
* Elensefar refuses to submit to Asheviere and declares itself an independent city-state.<br />
* After several defeats, Wesnoth's army retreats from the remote areas of the kingdom. The western Wesnothian border recedes, is fixed, and remains heavily defended.<br />
* As a result of the loyalist withdrawal, several small human communities on the west coast of the Great Continent live in relative independence while elves flourish in the great forest to the southwest of Wesnoth.<br />
* A band of Wesnoth citizens organizes resistance to Asheviere's siezure of power. They are eventually forced to abandon their home and settle in the Three Sisters ('''Liberty''').<br />
<br />
=== 502-517 YW ===<br />
* Delfador raises Konrad under the protection of the Elves.<br />
<br />
=== 517 YW ===<br />
* Asheviere hires Orcish forces to hunt down her nephew-in-law Konrad.<br />
* Orcish forces converge on Delfador's refuge.<br />
* Konrad flees his home with the elves and embark upon a quest to regain the throne of Wesnoth. '''Heir To The Throne''' begins.<br />
<br />
=== 518 YW ===<br />
* Konrad crosses the Great River into the Northlands on a search for the Sceptre of Fire.<br />
* They enter the Caves of Knalga, allied with Princess Li'sar, and find it.<br />
* They return to Wesnoth and claim the throne. '''Heir to the Throne''' ends.<br />
<br />
=== 522 YW ===<br />
* Birth of Princess Ana'sar.<br />
<br />
=== 530 YW ===<br />
* Wesnothian colonists begin reclaiming the Estmarks.<br />
<br />
=== 544 YW ===<br />
* With both sides of the lower Weldyn River again civilized territory, the River Guard posts south of Soradoc are abandoned. Wesnothian military activity shifts eastward into the Estmarks.<br />
<br />
== 530-630 YW: The Age of Fear ==<br />
The Age of Fear takes its names from the events of the end of the era. On the surface, the first 90 years were very uneventful. However, during this time unexplainable magical events took place, especially in the eastern lands. Previously tamed lands were slowly claimed by wilderness as fear and paranoia gradually overshadowed the spirit of pioneering and adventure displayed earlier in Wesnoth's history. In the last 10 years of the age, Wesnoth bore the brunt of the most powerful Undead attack ever and was nearly destroyed. By the end of the era, most of Wesnoth had been made barren, most of the great buildings inside and outside of Weldyn were razed, and the population of Wesnoth was half of what it had been.<br />
<br />
It was in this era that certain areas of the chaotic Northlands were for the first time put into any kind of law and order. A small group of humans and dwarves, accepting anyone of any race who wished to join, formed themselves into the "Northern Alliance”, with the vision of making the Northlands safe to live in. Over time, this alliance grew slowly but steadily in power. By the end of the era, the alliance had succeeded in making a few small areas, including Knalga and the surrounding regions, stable and prosperous. Consequently, many people evacuated from the wasteland that most of Wesnoth had become and moved north - depleting the population of Wesnoth still further.<br />
<br />
=== 533 YW ===<br />
* Delfador succumbs to old age and dies, his body is entombed alongside his staff in Eregonor.<br />
* The next great sage of Wesnoth, Dacyn, is born.<br />
<br />
=== 534 YW ===<br />
<br />
* The small community of Dwarven Doors, in the Northlands just outside Knalga, rebels against the Orcish overlords. '''Northern Rebirth''' begins.<br />
* The residents, led by Tallin, head underground and find dwarves, whom they ally with.<br />
* Their combined forces destroy a lich who is attempting to claim Knalga as his own.<br />
<br />
=== 535 YW ===<br />
<br />
* The warlord-aspirant Rakshas attacks Tallin and his forces, but does not penetrate the dwarves' defences.<br />
* To help defeat the orcs, Tallin secures the help of two Liches, and rescues an elvish princess to secure the help of the elves.<br />
* Assisted by his new allies, Tallin smashes the forces of Rakshas.<br />
* According to some historians, Tallin and the elvish princess are married; others say they parted in bad blood.<br />
* To preserve the new-found peace in the Northlands, Tallin and his allies form the Northern Alliance. '''Northern Rebirth''' ends.<br />
<br />
=== 550 YW ===<br />
<br />
* Lord Hamel of Knalga sends an expedition to Kal Kartha to determine the fate of the Hammer of Thursagan ('''The Hammer of Thursagan''' takes place in late 550 YW to early 551 YW.).<br />
* Dwarves at Knalga and elsewhere begin to reclaim the lost art of runesmithing.<br />
* Wesnothian colonization expands southward past Fort Tahn.<br />
<br />
=== 563 YW ===<br />
* Konrad and Li'sar die after an extraordinarily long reign.<br />
* Princess Ana'sar becomes queen.<br />
* The seer Galdren becomes prominent at the court of Weldyn.<br />
<br />
=== 585 YW ===<br />
* Queen Ana'sar retires.<br />
* Haldric VII becomes king of Wesnoth.<br />
<br />
=== 589 YW ===<br />
* Dacyn the White Mage and Ravanal, an eastern wizard, compete to be the king's advisor.<br />
* The seer Galdren dies after advising Haldric VII to choose Dacyn.<br />
* The king does as Galdren advises.<br />
<br />
=== 593 YW ===<br />
* Ravanal reveals that he has turned to evil, and flees from Weldyn.<br />
* Konrad II is born.<br />
* Certain southern frontier regions are formally annexed to the Kingdom of Wesnoth as the Province of Kerlath.<br />
<br />
=== 598 YW ===<br />
* South Guard organized as a semi-detached formation of the Royal Army, to protect the inhabitants of the frontier province of Kerlath.<br />
<br />
=== 607 YW ===<br />
* South Guard ceases reporting. Haldric VII sends Deoran, son of Haldiel, to investigate. '''The South Guard''' takes place in 607-608 YW. <br />
<br />
=== 612 YW ===<br />
* Haldric VII dies. Konrad II is crowned King of Wesnoth.<br />
* Dacyn continues his duties as advisor with Konrad II.<br />
<br />
=== 625 YW ===<br />
* Mysterious disappearances of livestock and peasants cause partial evacuation of the the '''Estmark Hills'''. Lords of the Horse Plains report increased banditry from there.<br />
* Konrad II sends Dacyn with Owaec and Gweddry to man the old River Guard strongpoints. '''Eastern Invasion''' begins.<br />
<br />
=== 626 YW ===<br />
* Mal-Ravanal attacks the middle outpost where Gweddry and Dacyn are stationed.<br />
* Dacyn and Gweddry travel to the northern outpost, and, with Owaec, retreat into the northlands.<br />
* In the Far North, the merfolk city of Jotha is overrun by undead. The action of '''Dead Water''' takes place.<br />
<br />
=== 627 YW ===<br />
* Wesnoth's last defences are broken and the undead march on Wesnoth<br />
* In the northlands, the orcs drive Gweddry's army back across the river.<br />
* Weldyn is besieged.<br />
* Gweddry breaks through undead lines to reach Weldyn.<br />
* A council is held.<br />
* Gweddry's army is fortunate and kills Mal-Ravanal. '''Eastern Invasion''' ends.<br />
* Wesnoth is saved, but large portions have been laid waste by the undead.<br />
<br />
== 628-673 YW: The Silver Age of Wesnoth ==<br />
<br />
The Silver Age, or restoration of the Wesnothian kingdom, essentially coincides with the rest of the long and successful reign of Konrad II. During this period Wesnoth largely recovered from the damage that Mal-Ravanal's undead attack had done. It would, however, never quite regain the majesty it had at the height of its power.<br />
<br />
The Northlands, aided by a second wave of colonization north from Wesnoth, become more civilised and stable. Although nowhere near as prosperous as Wesnoth was during its Golden Age, the Northlands developed towns of significant size and a thriving - if somewhat dangerous - trade network. <br />
<br />
Four major powers soon came to dominate much of the Northlands. First there were the dwarves, who controlled most of the mountains and a vast array of underground tunnels and caverns. To the east, shrouded in mystery, lay the Elvish forests which continued to be inaccessible to anyone not of elvish blood. The remaining landscape was dominated either by orcish tribes, or independent human earldoms. As competition for the land grew fierce, wars smoldered between human and orcish forces. <br />
<br />
=== 628-635 YW ===<br />
* Konrad II begins his attempt to rebuild Wesnoth.<br />
<br />
=== 673 YW ===<br />
* Konrad II dies, bringing the [[Garardine Dynasty]] to an end. Second Wesnothian civil war begins.<br />
<br />
== 761-816 YW: The Legacy of Black-Eye Karun ==<br />
<br />
After decades of struggle, Black-Eye Karun becomes the first warlord since the assassination of Great Chief Brurbar in 20 YW to unite all the different squabbling orcish tribes under his banner. Among his many accomplishments as a Sovereign, his most famous is the creation of the Great Council. <br />
<br />
Karun was a far-sighted individual and he knew that after his death the orcish tribes would once again turn to fighting among themselves, with little he could do to prevent that and consequent peril from the Wesnothians and elves.<br />
<br />
Consequently, Karun selected from among all the different tribes six of the most sober and wisest orcs and thus created the Great Council. It was the Great Council's job to stay aloof from any tribal or territorial squabbling amongst the orcs, but yet always remain there to give advice to whomever came to seek it. In order to preserve the orcish race in the event of an emergency, he invested in them the power to call up The Great Horde. It was established that every orc, no matter what tribe he came from, must obey the summons of The Great Horde and follow wholeheartedly the leader that the Great Council put at the head of The Great Horde.<br />
<br />
===816 YW===<br />
* Rahul I (Lord Protector of the Northern Alliance) and Black Eye Karun sign a peace treaty ending a 15 year war between the humans and the orcs. Soon after this Karun, is ambushed and killed in mysterious circumstances.<br />
<br />
===842 YW===<br />
* War once again breaks out between the orcish tribes and the northern human earldoms as humans break the long standing treaty and attempt to colonise orcish lands. In response, the Great Council set up by the Black Eye Karun calls upon The Great Horde and bestows leadership of it upon Kapou’e; '''Son of the Black Eye''' begins.<br />
<br />
===843 YW===<br />
* Half of the Great Council is treacherously slain by the allied human forces and orcish unity disintegrates. Faced with the extermination of all the orcs on the Great Continent, Kapou’e forcibly asserts his control over the orcish territories and defeats the enemy forces. The Northern Alliance arrives on the scene in time for the final battle and helps Kapou’e defeat the forces of the northern earldoms, who had broken the treaty. Kapou’e then assumes the position of Sovereign over the northern tribes, and his rule ushers in an unprecedented era of unity and prosperity for the orcs.<br />
<br />
===852 YW===<br />
*Kapou’e repels a large elvish invasion.<br />
<br />
===858 YW===<br />
<br />
*The humans once again stage an invasion but prove to be no match for the united orcish forces under the leadership of Kapou’e. '''Son of the Black Eye''' ends.<br />
<br />
==After the Fall==<br />
At some unknown point in the future, an unspeakable cataclysm scorched the surface of the lands. Forests died, hills turned into rocky wastelands and fields became barren deserts. In the apocalypse allies turned against each other and friends fought over what few resources remained. The great nations were destroyed, and huge numbers of people died. Still amidst the chaos somehow small groups of people survived, sheltered in hidden places. In this post-apocalyptic world survival is a daily struggle as a few remaining tribes eke out an existence among the ruins of fallen empires. Heroic bands of elves, nomadic refugee humans, savage hordes of orcs and dark necromancers all forge new lives under the merciless dual suns, Sela and Naia, of this new Wesnoth.<br />
<br />
===??? Post-Wesnoth===<br />
<br />
* The Quenoth elves adapt to life in barren world of the Great Southern Desert. Over time they lost their affinity for the woodlands of their ancestry and embrace life in the sandy wastelands.<br />
* Under the leadership of Tanuil, the Quenoth elves build and sustain a fortified village around a rare oasis. The village thrives amidst the hostilities of the desert.<br />
* One night, a meteor storm rains from the sky and destroys the village of the Quenoth elves. '''Under the Burning Suns''' begins. The next day, Tanuil, like many others, is missing and presumed dead. Kalehssar (Kaleh), nephew of Tanuil, takes leadership of the remaining Quenoth elves as the surviving next of kin.<br />
* Kaleh, heeding the voice of his god Eloh in his dreams, gathers the remaining Quenoth elves and leads them north to a new promised land, foregoing rebuilding of their desert village.<br />
* The Quenoth elves battle their way north through Undead, Orcs, Bandits and other evil, venturing underground beneath a large mountain range at the command of Eloh.<br />
* Befriending unexpected allies underground, Kaleh's forces survive to the other side of the mountain.<br />
* Keratur, son of Tanuil and survivor of the cataclysm, insane with fright attacks Kaleh. Kaleh defeats Keratur.<br />
* Kaleh defies commands given him by a vision of Eloh.<br />
* The Quenoth reach the ocean. Aided by Merfolk, they escape the mainland and head for a newly discovered island, a place where the Quenoth may settle in peace.<br />
* On the island, the Quenoth confront Yechnagoth, the Eater of Souls and impersonator of Eloh. Yechnagoth and army are destroyed by the Quenoth.<br />
* Kaleh and the elves settle on their newfound, and newly named, Quenoth Isle. '''Under the Burning Suns''' ends.<br />
<br />
== History Credits ==<br />
<br />
* Timelined by Kamahawk and Turin. Revised to incorporate material from later version of Legend of Wesmere and reconcile different versions of the history of the Scepter of Fire by Eric S. Raymond.<br />
<br />
* History derived from:<br />
** Eastern Invasion<br />
** Heir to the Throne<br />
** Legend of Wesmere<br />
** Liberty<br />
** Northern Rebirth<br />
** The Hammer of Thursagan<br />
** The Rise of Wesnoth<br />
** Under the Burning Suns<br />
** Dead Water<br />
** Delfador's Memoirs<br />
<br />
* Setting details derived from:<br />
** Invasion from the Unknown<br />
<br />
== See Also ==<br />
<br />
* [[Geography of Wesnoth]]<br />
* [[Poetry of Wesnoth]]<br />
* [[Races]]<br />
* [[FactionHistory]]<br />
<br />
[[Category:World of Wesnoth]]<br />
[[Category:History]]</div>Fabihttps://wiki.wesnoth.org/index.php?title=Timeline_of_Wesnoth&diff=42924Timeline of Wesnoth2011-06-07T00:11:56Z<p>Fabi: /* 122 YW */</p>
<hr />
<div>This is a chronological history of the country of Wesnoth and surrounding regions, gleaned from written accounts and verbal histories passed down through the generations. Portions of entries surrounded by parentheses and containing a question mark are assumed or unconfirmed information. The history is sorted by era, and within the era by date, using the Foundation of Wesnoth as a base. BW=Before Wesnoth, YW=Years Wesnoth. They function the same way as BC and AD do in our timekeeping system. Each of the eras is summarized before the timeline for that era begins. This history of the Great Continent is a subject of active scholarship.<br />
<br />
The world that Wesnoth resides in is called Irdya. Before the Fall and the (unchronicled) technological age, this name is only rarely used. <br />
<br />
<br />
'''Spoiler warning!'''<br />
This page contains plot spoilers to several campaigns.<br />
<br />
__NOTOC__<br />
[[#Prehistory - 20 YW: The Founding of Wesnoth|The Founding of Wesnoth]]<br />
<br />
[[#20-130 YW: The Taming of the Wild|The Taming of the Wild]]<br />
<br />
[[#200-350 YW: The Golden Age of Wesnoth|The Golden Age of Wesnoth]]<br />
<br />
[[#350-417 YW: The First Dark Age of Wesnoth|The First Dark Age of Wesnoth]]<br />
<br />
[[#417-530 YW: The Turmoil of Asheviere|The Turmoil of Asheviere]]<br />
<br />
[[#530-630 YW: The Age of Fear|The Age of Fear]]<br />
<br />
[[#628-673 YW: The Silver Age of Wesnoth|The Silver Age of Wesnoth]]<br />
<br />
[[#761-816 YW: The Legacy of Black-Eye Karun|The Legacy of Black-Eye Karun]]<br />
<br />
[[#After the Fall|After the Fall]]<br />
<br />
== Prehistory - 20 YW: The Founding of Wesnoth ==<br />
During the age of the Founding of Wesnoth, there were two important geographic locations, these being the Green Isle and the Great Continent. Haldric is the main historical figure at this time. This age ends with the founding of Wesnoth as a country in the Great Continent, and with Orcs attacking both elves and men from the sea.<br />
<br />
=== Prehistory ===<br />
* Elves and Dwarves inhabit the Great Continent.<br />
* Humans inhabit the distant West.<br />
* Haldric's people colonise the Green Isle from a continent further to the west.<br />
<br />
=== 200 BW ===<br />
* The Lich-Lords arrive on the Green Isle after losing a war in the distant West.<br />
* After a long war Haldric's people come to dominate the Green Isle.<br />
* The 'Wesfolk' and their Lich-Lords are pushed onto marginal lands.<br />
<br />
=== 12 BW ===<br />
* The Crown Prince of Southbay discovers the Great Continent.<br />
<br />
=== 11-7 BW ===<br />
* The Crown Prince makes several voyages between the Green Isle and the Great Continent.<br />
<br />
=== 6 BW ===<br />
* Following these voyages to the Great Continent, the elder Crown Prince falls ill and dies.<br />
* His younger brother is implicated in a plot to kill him.<br />
* As a distraction the younger Prince starts a war with the Wesfolk and their Lich-Lords.<br />
* The Lich-Lords sense they will be destroyed and open gates to the homeland of the Orcs in the West.<br />
<br />
=== 5-2 BW ===<br />
* The Green Isle is overrun with Orcs.<br />
* The Wesfolk desert their Lich-Lords as they fear becoming prey for the Orcs.<br />
* Prince Haldric leads the evacuation of the survivors to the Great Continent. '''The Rise of Wesnoth''' begins.<br />
<br />
=== 1 BW ===<br />
* Human settlers, led by Prince Haldric, arrive at the western coast of the Great Continent (the landfall occurs in the future Bay of Pearls) in large numbers.<br />
* Humans arrive in the middle of a simmering dispute between the Elves and Dwarves.<br />
* The Elves and Dwarves are distrustful of humans, and there is a small skirmish.<br />
* Messengers from Wesmere Forest come and ask Haldric to come before the Ka'lian.<br />
* Prince Haldric asks the Four Elvish Lords (Dionli, Logalmier, Aryad, and El'Isomithir) for help and land.<br />
* They set before him four quests to prove his worth, which he completes.<br />
<br />
=== 1 YW ===<br />
* Haldric is granted the plains north and south of the Great River.<br />
* Haldric agrees to a Pact of Mutual Defence with the Elves, but the Ka'lian decides it will betray him and allow humans and orcs to exhaust each other in war if the opportunity presents. Haldric, learning of this, considers the Pact a dead letter.<br />
* The Ruby of Fire is temporarily hidden, and the lich-lord Jevyan is deceived into believing it is held by the Elves. <br />
* Haldric founds the country of Wesnoth in the central plain south of the great River.<br />
* Reign of Haldric I begins. '''The Rise of Wesnoth''' ends.<br />
<br />
=== 2 YW ===<br />
* Orcs, following the ships fleeing from the Green Isle, begin to arrive on the Great Continent.<br />
* These Orcs are defeated by Haldric's forces.<br />
* Some of the Orcish survivors flee back to the Green Isle, others move to attack the Elves.<br />
* King Haldric helps the Elves fight the surviving Orcs.<br />
<br />
=== 8 YW ===<br />
* A second wave of Orcs arrive from the Green Isle; these Orcs begin claiming large portions of the northern Great Continent for themselves.<br />
* Erlornas of Wesmere is involved in the first direct elvish clash with orcs ('''An Orcish Incursion''' takes place in 8-9YW).<br />
* Haldric I publicly repudiates the Pact he spoke with the Elves, refusing to give aid.<br />
<br />
=== 9-11 YW ===<br />
* Many Elves are killed in battle by the Orcs.<br />
* Elvish emissaries are turned away from Wesnoth.<br />
<br />
=== 12 YW ===<br />
* Orcs fail to take the Wesmere Forest and instead march down the coast, devastating human settlements there.<br />
* Elves refuse to aid the Humans in confronting the Orcs.<br />
* Human refugees from the coastal settlements relocate in what will become known as the Great Central Plain. Dan'Tonk, which will become Wesnoth's largest city, is founded.<br />
<br />
=== 20 YW ===<br />
* Haldric I dies.<br />
* Haldric II ascends to the throne.<br />
* Kalenz and Landar escape an orcish invasion of their home in Lintanir Forest. '''The Legend of Wesmere''' begins.<br />
* Humans and elves decisively defeat the orcs at Tath, thus halting the orcish advance.<br />
* A new treaty between humans and elves is signed and King Haldric II allows emissaries of the Elves to return to Wesnoth.<br />
* Elves inform Haldric II of the danger posed by the unshielded Ruby of Fire.<br />
* Kalenz and Landar, later to become successive High Lords of the Elves, are able to sneak into an orcish camp by stealth and assassinate the Great Chief. A long orcish civil war for succession follows. The orcs are unable to undertake action against any other race during this period and Wesnoth enjoys a long period during which it can expand with little opposition.<br />
<br />
== 20-130 YW: The Taming of the Wild ==<br />
This era is that in which the kingdom of Wesnoth expanded and defined its borders, and settled the area which it had claimed for its own. The Taming of the Wild refers to the settling of the unsettled lands, as well as to the colonization of the Northlands. The end of this era is marked by friction between the city-state of Elensefar and the country of Wesnoth, which will continue for the next several hundred years.<br />
<br />
=== 21 YW ===<br />
* Founding of the Great Academy on Alduin.<br />
<br />
* Kalenz is relieved of command by the Ka'lian. He retires to Lintanir Forest with Cleodil. A faction of xenophobic elves begins to gether around Landar.<br />
<br />
=== 25-40 YW ===<br />
* In 25 YW Haldric II sends an expedition to retrieve the Ruby of Fire from its place of concealment.<br />
* Haldric II commissions a Dwarven tribe to build the Scepter of Fire with the Ruby of Fire as its centerpiece; Elves associated with Landar's faction attack during the transfer. '''Scepter of Fire''' begins.<br />
* Action of '''The Scepter of Fire''' takes place. Haldric II is informed that the Scepter was both completed and lost in the year 40. It will not be recovered for nearly 500 years.<br />
* With the death of Thursagan, the Runemaster, all runemasters are killed and runesmithing is lost for several centuries.<br />
<br />
=== 26-50 YW ===<br />
* Landar declares himself High Lord of the Elves, leading to civil war. <br />
<br />
=== 51 YW ===<br />
* Wesnothian New Writing (the script later called "steel-hand", to distinguish it from the more complex "brush-hand" cursive brought from the Green Isle) is promulgated by royal decree. From this date all royal documents and public inscriptions are in New Writing. It spreads rapidly via the mercantile class. The older brush-hand writing continues to be used for magical purposes, scholarship, and in certain elevated literary forms.<br />
<br />
=== 50-93 YW ===<br />
* Elvish civil war (and '''The Legend of Wesmere''') ends. Kalenz declared High Lord, begins reorganizing and militarizing Elvish society to fight the orcs. In late 93 YW he cedes control to a reconstituted Ka'lian and retires again to the Forest of Lintanir.<br />
<br />
=== 121 YW ===<br />
* Orcish civil war sputters to a halt. Raids on elves and humans resume. Period of uncontested human expansion ends, but the Wesnothian Army is more than equal to any of its opponents in battle.<br />
<br />
=== 122 YW ===<br />
* City of Elensefar is sacked by orcs.<br />
* Meneldur, a sailor of Elensefar, sets out on a quest to regain the city. UMC '''Saving Elensefar''' begins.<br />
<br />
=== 123 YW ===<br />
* Elensefar is retaken by Meneldur along with Undead from the Green Isle.<br />
* Elensefar becomes an independent city-state for the first time.<br />
<br />
=== 161-164 YW ===<br />
* The newly crowned king sought to make safe once and for all the wildlands that separated the human cities surrounding Weldyn and the coastal regions of Elensefar.<br />
* The grand army of Wesnoth, personally led by the High Council of Archmagi, destroyed all enemies residing within Wesnoth.<br />
* The city-state of Elensefar is formally united to the kingdom. Settlements from it spread north of the river into the new frontier province of Annuvin, carefully avoiding the margins of Wesmere Forest.<br />
<br />
=== 164-176 YW ===<br />
* During this twelve year span, the western fortress of Halstead was erected in the very heart of the western wilderlands.<br />
<br />
=== 199 YW ===<br />
* Emboldened by the far-reaching arm of Halstead's protection, settlement in the west explodes<br />
* The settlements of Aldril and Carcyn grow to become major cities, the first as an important port due to its position on the Bay of Pearls, and the second as a stop on the road to Elensefar and military outpost along the Great River<br />
* Settlers from Carcyn cross the Great River to establish the first settlements north of it and east of Wesmere.<br />
<br />
== 200-350 YW: The Golden Age of Wesnoth ==<br />
The Golden Age of Wesnoth was the time of the great kings, and of peace and prosperity within the kingdom. The Orcs had suffered a grave defeat at the hands of Wesnoth and Elensefar seventy-five years earlier, so they did not pose much of a threat, and whenever they did attack they were quickly defeated. This allowed the army to lessen in size, and the kings of this age to undertake the great public works they are renowned for. The era ends when the king of Wesnoth dies without an heir, and a new dynasty begins.<br />
<br />
=== 251 YW ===<br />
* Cleodil, wife of Kalenz, dies.<br />
<br />
=== 350 YW ===<br />
* Disintegration of the Kingdom follows the death of Haldric IV.<br />
* Elensefar remains a province of Wesnoth but exerts increasing independence due to isolation.<br />
* Treaty between lord of Elensefar and king of Wesnoth signed.<br />
<br />
== 350-417 YW: The First Dark Age of Wesnoth ==<br />
The first Dark Age was a time of strife and invasion. When Haldric IV died, he left Wesnoth without a king, and the next 70 years were marked by short-lived dynasties, attacks by ever more aggressive orcs, and the further separation of Wesnoth and Elensefar. The Dark Age ended when Garard I took the throne, and began a new dynasty that would last for several hundred years.<br />
<br />
=== 360 YW ===<br />
* Malin Keshar born in Parthyn.<br />
<br />
=== 363 YW ===<br />
* Last of Kalenz's children dies. Kalenz, condemned to outlive his offspring by the potion of Crelanu, leaves the Forest of Lintanir and begins wandering the Great Continent.<br />
<br />
* Village of Maghre terrorized by a minor necromancer. Action of '''A Tale of Two Brothers''' takes place.<br />
<br />
=== 389 YW ===<br />
* Garard, a future king of Wesnoth, is born.<br />
* Malin Keshar returns to Parthyn from the Academy at Alduin. '''Descent Into Darkness''' begins.<br />
<br />
== 417-530 YW: The Turmoil of Asheviere ==<br />
King Garard's dynasty was long-lived and productive, but it was also punctuated by significant turmoil: the end of the first king's reign was marred by orcish and undead raids, and the second was murdered by his own wife and son. It was not until 517 YW that the usurpation of the throne by Queen Mother Asheviere was ended.<br />
<br />
=== 417 YW ===<br />
* Ending years of strife and division, Garard I seizes the throne and becomes king of Wesnoth, beginning the [[Garardine Dynasty]].<br />
<br />
=== 440 YW ===<br />
* Crown Prince Garard II is born.<br />
<br />
=== 442 YW ===<br />
* Delfador, later called "the Great", is born.<br />
<br />
=== 450 YW ===<br />
* Prince Arand is born.<br />
<br />
=== 468 YW ===<br />
* Zorlan becomes Great Chief of the northern orcs<br />
* Delfador graduates from the Great Academy. '''Delfador's Memoirs''' begins.<br />
<br />
=== 470 YW ===<br />
* Garard I dies; Garard II ascends to the throne of Wesnoth<br />
* Orcs under Great Chief Zorlan and undead raised by the necromancer Iliah-Malal raid Wesnoth's borders. All but the first and the last three scenarios of '''Delfador's Memoirs''' take place in this year.<br />
* Control of the Estmarks is effectively lost during this war, not to be regained for decades. Outposts are built on the near side of the Weldyn to repel orc raids. The long watch of the River Guard begins.<br />
<br />
=== 478 YW ===<br />
* Garard II marries Asheviere.<br />
* Garard issues the Edict of the Scepter, providing that the crown shall settle after his death on whichever member of the royal family successfully retrieves it from the Caverns of Flame.<br />
<br />
=== 480 YW ===<br />
* Crown Prince Eldred is born.<br />
<br />
=== 483 YW ===<br />
* Erain and Ethyn, identical twins and brothers of Eldred, are born.<br />
<br />
=== 498 YW ===<br />
* Princess Li'sar is born.<br />
<br />
=== 500 YW ===<br />
* Prince Konrad is born, the youngest of several sons of Prince Arand.<br />
* Wesnoth and the orcs of the north go to war.<br />
<br />
=== 501 YW ===<br />
<br />
===== Betrayal on the battlefield =====<br />
* Garard leads his army to orc encampment at Galcadar by the Ford of Abez.<br />
* Garard's forces split into two groups, one led by himself and the other by his son Eldred.<br />
* Eldred betrays his father and attacks him with the troops under his control.<br />
* Eldred slays King Garard and his uncle Prince Arand on the battlefield of Abez.<br />
<br />
===== Reprisal =====<br />
* Delfador escapes the battle and heads to Weldyn.<br />
* Eldred gives tribute to the Orcish king, who stops his attacks.<br />
* Delfador gathers a force of Loyalists to avenge Garard's Death.<br />
* Eldred's forces confront Delfador's Loyalists at Weldyn.<br />
* The Loyalists are defeated, but Eldred is slain by Delfador in the fight.<br />
<br />
===== Asheviere seizes power =====<br />
* Asheviere orders the slaughter of Garard's nephews and declares herself Queen of Wesnoth.<br />
* Hearing of the news Delfador infiltrates the palace.<br />
* Delfador finds the youngest prince Konrad as he is slain.<br />
* Delfador flees, taking Konrad's body for burial to the land of the Elves.<br />
* While traveling through Wesnoth, Elf Lady Parandra finds an orphaned human child.<br />
* Parandra and Delfador agree to give the orphan the identity of Prince Konrad.<br />
* Delfador and Konrad flee to live in refuge with the Wood Elves of the great southwestern forest.<br />
<br />
===== The country resists Asheviere =====<br />
* Elensefar refuses to submit to Asheviere and declares itself an independent city-state.<br />
* After several defeats, Wesnoth's army retreats from the remote areas of the kingdom. The western Wesnothian border recedes, is fixed, and remains heavily defended.<br />
* As a result of the loyalist withdrawal, several small human communities on the west coast of the Great Continent live in relative independence while elves flourish in the great forest to the southwest of Wesnoth.<br />
* A band of Wesnoth citizens organizes resistance to Asheviere's siezure of power. They are eventually forced to abandon their home and settle in the Three Sisters ('''Liberty''').<br />
<br />
=== 502-517 YW ===<br />
* Delfador raises Konrad under the protection of the Elves.<br />
<br />
=== 517 YW ===<br />
* Asheviere hires Orcish forces to hunt down her nephew-in-law Konrad.<br />
* Orcish forces converge on Delfador's refuge.<br />
* Konrad flees his home with the elves and embark upon a quest to regain the throne of Wesnoth. '''Heir To The Throne''' begins.<br />
<br />
=== 518 YW ===<br />
* Konrad crosses the Great River into the Northlands on a search for the Sceptre of Fire.<br />
* They enter the Caves of Knalga, allied with Princess Li'sar, and find it.<br />
* They return to Wesnoth and claim the throne. '''Heir to the Throne''' ends.<br />
<br />
=== 522 YW ===<br />
* Birth of Princess Ana'sar.<br />
<br />
=== 530 YW ===<br />
* Wesnothian colonists begin reclaiming the Estmarks.<br />
<br />
=== 544 YW ===<br />
* With both sides of the lower Weldyn River again civilized territory, the River Guard posts south of Soradoc are abandoned. Wesnothian military activity shifts eastward into the Estmarks.<br />
<br />
== 530-630 YW: The Age of Fear ==<br />
The Age of Fear takes its names from the events of the end of the era. On the surface, the first 90 years were very uneventful. However, during this time unexplainable magical events took place, especially in the eastern lands. Previously tamed lands were slowly claimed by wilderness as fear and paranoia gradually overshadowed the spirit of pioneering and adventure displayed earlier in Wesnoth's history. In the last 10 years of the age, Wesnoth bore the brunt of the most powerful Undead attack ever and was nearly destroyed. By the end of the era, most of Wesnoth had been made barren, most of the great buildings inside and outside of Weldyn were razed, and the population of Wesnoth was half of what it had been.<br />
<br />
It was in this era that certain areas of the chaotic Northlands were for the first time put into any kind of law and order. A small group of humans and dwarves, accepting anyone of any race who wished to join, formed themselves into the "Northern Alliance”, with the vision of making the Northlands safe to live in. Over time, this alliance grew slowly but steadily in power. By the end of the era, the alliance had succeeded in making a few small areas, including Knalga and the surrounding regions, stable and prosperous. Consequently, many people evacuated from the wasteland that most of Wesnoth had become and moved north - depleting the population of Wesnoth still further.<br />
<br />
=== 533 YW ===<br />
* Delfador succumbs to old age and dies, his body is entombed alongside his staff in Eregonor.<br />
* The next great sage of Wesnoth, Dacyn, is born.<br />
<br />
=== 534 YW ===<br />
<br />
* The small community of Dwarven Doors, in the Northlands just outside Knalga, rebels against the Orcish overlords. '''Northern Rebirth''' begins.<br />
* The residents, led by Tallin, head underground and find dwarves, whom they ally with.<br />
* Their combined forces destroy a lich who is attempting to claim Knalga as his own.<br />
<br />
=== 535 YW ===<br />
<br />
* The warlord-aspirant Rakshas attacks Tallin and his forces, but does not penetrate the dwarves' defences.<br />
* To help defeat the orcs, Tallin secures the help of two Liches, and rescues an elvish princess to secure the help of the elves.<br />
* Assisted by his new allies, Tallin smashes the forces of Rakshas.<br />
* According to some historians, Tallin and the elvish princess are married; others say they parted in bad blood.<br />
* To preserve the new-found peace in the Northlands, Tallin and his allies form the Northern Alliance. '''Northern Rebirth''' ends.<br />
<br />
=== 550 YW ===<br />
<br />
* Lord Hamel of Knalga sends an expedition to Kal Kartha to determine the fate of the Hammer of Thursagan ('''The Hammer of Thursagan''' takes place in late 550 YW to early 551 YW.).<br />
* Dwarves at Knalga and elsewhere begin to reclaim the lost art of runesmithing.<br />
* Wesnothian colonization expands southward past Fort Tahn.<br />
<br />
=== 563 YW ===<br />
* Konrad and Li'sar die after an extraordinarily long reign.<br />
* Princess Ana'sar becomes queen.<br />
* The seer Galdren becomes prominent at the court of Weldyn.<br />
<br />
=== 585 YW ===<br />
* Queen Ana'sar retires.<br />
* Haldric VII becomes king of Wesnoth.<br />
<br />
=== 589 YW ===<br />
* Dacyn the White Mage and Ravanal, an eastern wizard, compete to be the king's advisor.<br />
* The seer Galdren dies after advising Haldric VII to choose Dacyn.<br />
* The king does as Galdren advises.<br />
<br />
=== 593 YW ===<br />
* Ravanal reveals that he has turned to evil, and flees from Weldyn.<br />
* Konrad II is born.<br />
* Certain southern frontier regions are formally annexed to the Kingdom of Wesnoth as the Province of Kerlath.<br />
<br />
=== 598 YW ===<br />
* South Guard organized as a semi-detached formation of the Royal Army, to protect the inhabitants of the frontier province of Kerlath.<br />
<br />
=== 607 YW ===<br />
* South Guard ceases reporting. Haldric VII sends Deoran, son of Haldiel, to investigate. '''The South Guard''' takes place in 607-608 YW. <br />
<br />
=== 612 YW ===<br />
* Haldric VII dies. Konrad II is crowned King of Wesnoth.<br />
* Dacyn continues his duties as advisor with Konrad II.<br />
<br />
=== 625 YW ===<br />
* Mysterious disappearances of livestock and peasants cause partial evacuation of the the '''Estmark Hills'''. Lords of the Horse Plains report increased banditry from there.<br />
* Konrad II sends Dacyn with Owaec and Gweddry to man the old River Guard strongpoints. '''Eastern Invasion''' begins.<br />
<br />
=== 626 YW ===<br />
* Mal-Ravanal attacks the middle outpost where Gweddry and Dacyn are stationed.<br />
* Dacyn and Gweddry travel to the northern outpost, and, with Owaec, retreat into the northlands.<br />
* In the Far North, the merfolk city of Jotha is overrun by undead. The action of '''Dead Water''' takes place.<br />
<br />
=== 627 YW ===<br />
* Wesnoth's last defences are broken and the undead march on Wesnoth<br />
* In the northlands, the orcs drive Gweddry's army back across the river.<br />
* Weldyn is besieged.<br />
* Gweddry breaks through undead lines to reach Weldyn.<br />
* A council is held.<br />
* Gweddry's army is fortunate and kills Mal-Ravanal. '''Eastern Invasion''' ends.<br />
* Wesnoth is saved, but large portions have been laid waste by the undead.<br />
<br />
== 628-673 YW: The Silver Age of Wesnoth ==<br />
<br />
The Silver Age, or restoration of the Wesnothian kingdom, essentially coincides with the rest of the long and successful reign of Konrad II. During this period Wesnoth largely recovered from the damage that Mal-Ravanal's undead attack had done. It would, however, never quite regain the majesty it had at the height of its power.<br />
<br />
The Northlands, aided by a second wave of colonization north from Wesnoth, become more civilised and stable. Although nowhere near as prosperous as Wesnoth was during its Golden Age, the Northlands developed towns of significant size and a thriving - if somewhat dangerous - trade network. <br />
<br />
Four major powers soon came to dominate much of the Northlands. First there were the dwarves, who controlled most of the mountains and a vast array of underground tunnels and caverns. To the east, shrouded in mystery, lay the Elvish forests which continued to be inaccessible to anyone not of elvish blood. The remaining landscape was dominated either by orcish tribes, or independent human earldoms. As competition for the land grew fierce, wars smoldered between human and orcish forces. <br />
<br />
=== 628-635 YW ===<br />
* Konrad II begins his attempt to rebuild Wesnoth.<br />
<br />
=== 673 YW ===<br />
* Konrad II dies, bringing the [[Garardine Dynasty]] to an end. Second Wesnothian civil war begins.<br />
<br />
== 761-816 YW: The Legacy of Black-Eye Karun ==<br />
<br />
After decades of struggle, Black-Eye Karun becomes the first warlord since the assassination of Great Chief Brurbar in 20 YW to unite all the different squabbling orcish tribes under his banner. Among his many accomplishments as a Sovereign, his most famous is the creation of the Great Council. <br />
<br />
Karun was a far-sighted individual and he knew that after his death the orcish tribes would once again turn to fighting among themselves, with little he could do to prevent that and consequent peril from the Wesnothians and elves.<br />
<br />
Consequently, Karun selected from among all the different tribes six of the most sober and wisest orcs and thus created the Great Council. It was the Great Council's job to stay aloof from any tribal or territorial squabbling amongst the orcs, but yet always remain there to give advice to whomever came to seek it. In order to preserve the orcish race in the event of an emergency, he invested in them the power to call up The Great Horde. It was established that every orc, no matter what tribe he came from, must obey the summons of The Great Horde and follow wholeheartedly the leader that the Great Council put at the head of The Great Horde.<br />
<br />
===816 YW===<br />
* Rahul I (Lord Protector of the Northern Alliance) and Black Eye Karun sign a peace treaty ending a 15 year war between the humans and the orcs. Soon after this Karun, is ambushed and killed in mysterious circumstances.<br />
<br />
===842 YW===<br />
* War once again breaks out between the orcish tribes and the northern human earldoms as humans break the long standing treaty and attempt to colonise orcish lands. In response, the Great Council set up by the Black Eye Karun calls upon The Great Horde and bestows leadership of it upon Kapou’e; '''Son of the Black Eye''' begins.<br />
<br />
===843 YW===<br />
* Half of the Great Council is treacherously slain by the allied human forces and orcish unity disintegrates. Faced with the extermination of all the orcs on the Great Continent, Kapou’e forcibly asserts his control over the orcish territories and defeats the enemy forces. The Northern Alliance arrives on the scene in time for the final battle and helps Kapou’e defeat the forces of the northern earldoms, who had broken the treaty. Kapou’e then assumes the position of Sovereign over the northern tribes, and his rule ushers in an unprecedented era of unity and prosperity for the orcs.<br />
<br />
===852 YW===<br />
*Kapou’e repels a large elvish invasion.<br />
<br />
===858 YW===<br />
<br />
*The humans once again stage an invasion but prove to be no match for the united orcish forces under the leadership of Kapou’e. '''Son of the Black Eye''' ends.<br />
<br />
==After the Fall==<br />
At some unknown point in the future, an unspeakable cataclysm scorched the surface of the lands. Forests died, hills turned into rocky wastelands and fields became barren deserts. In the apocalypse allies turned against each other and friends fought over what few resources remained. The great nations were destroyed, and huge numbers of people died. Still amidst the chaos somehow small groups of people survived, sheltered in hidden places. In this post-apocalyptic world survival is a daily struggle as a few remaining tribes eke out an existence among the ruins of fallen empires. Heroic bands of elves, nomadic refugee humans, savage hordes of orcs and dark necromancers all forge new lives under the merciless dual suns, Sela and Naia, of this new Wesnoth.<br />
<br />
===??? Post-Wesnoth===<br />
<br />
* The Quenoth elves adapt to life in barren world of the Great Southern Desert. Over time they lost their affinity for the woodlands of their ancestry and embrace life in the sandy wastelands.<br />
* Under the leadership of Tanuil, the Quenoth elves build and sustain a fortified village around a rare oasis. The village thrives amidst the hostilities of the desert.<br />
* One night, a meteor storm rains from the sky and destroys the village of the Quenoth elves. '''Under the Burning Suns''' begins. The next day, Tanuil, like many others, is missing and presumed dead. Kalehssar (Kaleh), nephew of Tanuil, takes leadership of the remaining Quenoth elves as the surviving next of kin.<br />
* Kaleh, heeding the voice of his god Eloh in his dreams, gathers the remaining Quenoth elves and leads them north to a new promised land, foregoing rebuilding of their desert village.<br />
* The Quenoth elves battle their way north through Undead, Orcs, Bandits and other evil, venturing underground beneath a large mountain range at the command of Eloh.<br />
* Befriending unexpected allies underground, Kaleh's forces survive to the other side of the mountain.<br />
* Keratur, son of Tanuil and survivor of the cataclysm, insane with fright attacks Kaleh. Kaleh defeats Keratur.<br />
* Kaleh defies commands given him by a vision of Eloh.<br />
* The Quenoth reach the ocean. Aided by Merfolk, they escape the mainland and head for a newly discovered island, a place where the Quenoth may settle in peace.<br />
* On the island, the Quenoth confront Yechnagoth, the Eater of Souls and impersonator of Eloh. Yechnagoth and army are destroyed by the Quenoth.<br />
* Kaleh and the elves settle on their newfound, and newly named, Quenoth Isle. '''Under the Burning Suns''' ends.<br />
<br />
== History Credits ==<br />
<br />
* Timelined by Kamahawk and Turin. Revised to incorporate material from later version of Legend of Wesmere and reconcile different versions of the history of the Scepter of Fire by Eric S. Raymond.<br />
<br />
* History derived from:<br />
** Eastern Invasion<br />
** Heir to the Throne<br />
** Legend of Wesmere<br />
** Liberty<br />
** Northern Rebirth<br />
** The Hammer of Thursagan<br />
** The Rise of Wesnoth<br />
** Under the Burning Suns<br />
** Dead Water<br />
** Delfador's Memoirs<br />
<br />
* Setting details derived from:<br />
** Invasion from the Unknown<br />
<br />
== See Also ==<br />
<br />
* [[Geography of Wesnoth]]<br />
* [[Poetry of Wesnoth]]<br />
* [[Races]]<br />
* [[FactionHistory]]<br />
<br />
[[Category:World of Wesnoth]]<br />
[[Category:History]]</div>Fabihttps://wiki.wesnoth.org/index.php?title=Timeline_of_Wesnoth&diff=42923Timeline of Wesnoth2011-06-06T23:52:52Z<p>Fabi: /* ??? Post-Wesnoth */</p>
<hr />
<div>This is a chronological history of the country of Wesnoth and surrounding regions, gleaned from written accounts and verbal histories passed down through the generations. Portions of entries surrounded by parentheses and containing a question mark are assumed or unconfirmed information. The history is sorted by era, and within the era by date, using the Foundation of Wesnoth as a base. BW=Before Wesnoth, YW=Years Wesnoth. They function the same way as BC and AD do in our timekeeping system. Each of the eras is summarized before the timeline for that era begins. This history of the Great Continent is a subject of active scholarship.<br />
<br />
The world that Wesnoth resides in is called Irdya. Before the Fall and the (unchronicled) technological age, this name is only rarely used. <br />
<br />
<br />
'''Spoiler warning!'''<br />
This page contains plot spoilers to several campaigns.<br />
<br />
__NOTOC__<br />
[[#Prehistory - 20 YW: The Founding of Wesnoth|The Founding of Wesnoth]]<br />
<br />
[[#20-130 YW: The Taming of the Wild|The Taming of the Wild]]<br />
<br />
[[#200-350 YW: The Golden Age of Wesnoth|The Golden Age of Wesnoth]]<br />
<br />
[[#350-417 YW: The First Dark Age of Wesnoth|The First Dark Age of Wesnoth]]<br />
<br />
[[#417-530 YW: The Turmoil of Asheviere|The Turmoil of Asheviere]]<br />
<br />
[[#530-630 YW: The Age of Fear|The Age of Fear]]<br />
<br />
[[#628-673 YW: The Silver Age of Wesnoth|The Silver Age of Wesnoth]]<br />
<br />
[[#761-816 YW: The Legacy of Black-Eye Karun|The Legacy of Black-Eye Karun]]<br />
<br />
[[#After the Fall|After the Fall]]<br />
<br />
== Prehistory - 20 YW: The Founding of Wesnoth ==<br />
During the age of the Founding of Wesnoth, there were two important geographic locations, these being the Green Isle and the Great Continent. Haldric is the main historical figure at this time. This age ends with the founding of Wesnoth as a country in the Great Continent, and with Orcs attacking both elves and men from the sea.<br />
<br />
=== Prehistory ===<br />
* Elves and Dwarves inhabit the Great Continent.<br />
* Humans inhabit the distant West.<br />
* Haldric's people colonise the Green Isle from a continent further to the west.<br />
<br />
=== 200 BW ===<br />
* The Lich-Lords arrive on the Green Isle after losing a war in the distant West.<br />
* After a long war Haldric's people come to dominate the Green Isle.<br />
* The 'Wesfolk' and their Lich-Lords are pushed onto marginal lands.<br />
<br />
=== 12 BW ===<br />
* The Crown Prince of Southbay discovers the Great Continent.<br />
<br />
=== 11-7 BW ===<br />
* The Crown Prince makes several voyages between the Green Isle and the Great Continent.<br />
<br />
=== 6 BW ===<br />
* Following these voyages to the Great Continent, the elder Crown Prince falls ill and dies.<br />
* His younger brother is implicated in a plot to kill him.<br />
* As a distraction the younger Prince starts a war with the Wesfolk and their Lich-Lords.<br />
* The Lich-Lords sense they will be destroyed and open gates to the homeland of the Orcs in the West.<br />
<br />
=== 5-2 BW ===<br />
* The Green Isle is overrun with Orcs.<br />
* The Wesfolk desert their Lich-Lords as they fear becoming prey for the Orcs.<br />
* Prince Haldric leads the evacuation of the survivors to the Great Continent. '''The Rise of Wesnoth''' begins.<br />
<br />
=== 1 BW ===<br />
* Human settlers, led by Prince Haldric, arrive at the western coast of the Great Continent (the landfall occurs in the future Bay of Pearls) in large numbers.<br />
* Humans arrive in the middle of a simmering dispute between the Elves and Dwarves.<br />
* The Elves and Dwarves are distrustful of humans, and there is a small skirmish.<br />
* Messengers from Wesmere Forest come and ask Haldric to come before the Ka'lian.<br />
* Prince Haldric asks the Four Elvish Lords (Dionli, Logalmier, Aryad, and El'Isomithir) for help and land.<br />
* They set before him four quests to prove his worth, which he completes.<br />
<br />
=== 1 YW ===<br />
* Haldric is granted the plains north and south of the Great River.<br />
* Haldric agrees to a Pact of Mutual Defence with the Elves, but the Ka'lian decides it will betray him and allow humans and orcs to exhaust each other in war if the opportunity presents. Haldric, learning of this, considers the Pact a dead letter.<br />
* The Ruby of Fire is temporarily hidden, and the lich-lord Jevyan is deceived into believing it is held by the Elves. <br />
* Haldric founds the country of Wesnoth in the central plain south of the great River.<br />
* Reign of Haldric I begins. '''The Rise of Wesnoth''' ends.<br />
<br />
=== 2 YW ===<br />
* Orcs, following the ships fleeing from the Green Isle, begin to arrive on the Great Continent.<br />
* These Orcs are defeated by Haldric's forces.<br />
* Some of the Orcish survivors flee back to the Green Isle, others move to attack the Elves.<br />
* King Haldric helps the Elves fight the surviving Orcs.<br />
<br />
=== 8 YW ===<br />
* A second wave of Orcs arrive from the Green Isle; these Orcs begin claiming large portions of the northern Great Continent for themselves.<br />
* Erlornas of Wesmere is involved in the first direct elvish clash with orcs ('''An Orcish Incursion''' takes place in 8-9YW).<br />
* Haldric I publicly repudiates the Pact he spoke with the Elves, refusing to give aid.<br />
<br />
=== 9-11 YW ===<br />
* Many Elves are killed in battle by the Orcs.<br />
* Elvish emissaries are turned away from Wesnoth.<br />
<br />
=== 12 YW ===<br />
* Orcs fail to take the Wesmere Forest and instead march down the coast, devastating human settlements there.<br />
* Elves refuse to aid the Humans in confronting the Orcs.<br />
* Human refugees from the coastal settlements relocate in what will become known as the Great Central Plain. Dan'Tonk, which will become Wesnoth's largest city, is founded.<br />
<br />
=== 20 YW ===<br />
* Haldric I dies.<br />
* Haldric II ascends to the throne.<br />
* Kalenz and Landar escape an orcish invasion of their home in Lintanir Forest. '''The Legend of Wesmere''' begins.<br />
* Humans and elves decisively defeat the orcs at Tath, thus halting the orcish advance.<br />
* A new treaty between humans and elves is signed and King Haldric II allows emissaries of the Elves to return to Wesnoth.<br />
* Elves inform Haldric II of the danger posed by the unshielded Ruby of Fire.<br />
* Kalenz and Landar, later to become successive High Lords of the Elves, are able to sneak into an orcish camp by stealth and assassinate the Great Chief. A long orcish civil war for succession follows. The orcs are unable to undertake action against any other race during this period and Wesnoth enjoys a long period during which it can expand with little opposition.<br />
<br />
== 20-130 YW: The Taming of the Wild ==<br />
This era is that in which the kingdom of Wesnoth expanded and defined its borders, and settled the area which it had claimed for its own. The Taming of the Wild refers to the settling of the unsettled lands, as well as to the colonization of the Northlands. The end of this era is marked by friction between the city-state of Elensefar and the country of Wesnoth, which will continue for the next several hundred years.<br />
<br />
=== 21 YW ===<br />
* Founding of the Great Academy on Alduin.<br />
<br />
* Kalenz is relieved of command by the Ka'lian. He retires to Lintanir Forest with Cleodil. A faction of xenophobic elves begins to gether around Landar.<br />
<br />
=== 25-40 YW ===<br />
* In 25 YW Haldric II sends an expedition to retrieve the Ruby of Fire from its place of concealment.<br />
* Haldric II commissions a Dwarven tribe to build the Scepter of Fire with the Ruby of Fire as its centerpiece; Elves associated with Landar's faction attack during the transfer. '''Scepter of Fire''' begins.<br />
* Action of '''The Scepter of Fire''' takes place. Haldric II is informed that the Scepter was both completed and lost in the year 40. It will not be recovered for nearly 500 years.<br />
* With the death of Thursagan, the Runemaster, all runemasters are killed and runesmithing is lost for several centuries.<br />
<br />
=== 26-50 YW ===<br />
* Landar declares himself High Lord of the Elves, leading to civil war. <br />
<br />
=== 51 YW ===<br />
* Wesnothian New Writing (the script later called "steel-hand", to distinguish it from the more complex "brush-hand" cursive brought from the Green Isle) is promulgated by royal decree. From this date all royal documents and public inscriptions are in New Writing. It spreads rapidly via the mercantile class. The older brush-hand writing continues to be used for magical purposes, scholarship, and in certain elevated literary forms.<br />
<br />
=== 50-93 YW ===<br />
* Elvish civil war (and '''The Legend of Wesmere''') ends. Kalenz declared High Lord, begins reorganizing and militarizing Elvish society to fight the orcs. In late 93 YW he cedes control to a reconstituted Ka'lian and retires again to the Forest of Lintanir.<br />
<br />
=== 121 YW ===<br />
* Orcish civil war sputters to a halt. Raids on elves and humans resume. Period of uncontested human expansion ends, but the Wesnothian Army is more than equal to any of its opponents in battle.<br />
<br />
=== 122 YW ===<br />
* City of Elensefar is sacked by orcs.<br />
* Meneldur, a sailor of Elensefar, sets out on a quest to regain the city.<br />
<br />
=== 123 YW ===<br />
* Elensefar is retaken by Meneldur along with Undead from the Green Isle.<br />
* Elensefar becomes an independent city-state for the first time.<br />
<br />
=== 161-164 YW ===<br />
* The newly crowned king sought to make safe once and for all the wildlands that separated the human cities surrounding Weldyn and the coastal regions of Elensefar.<br />
* The grand army of Wesnoth, personally led by the High Council of Archmagi, destroyed all enemies residing within Wesnoth.<br />
* The city-state of Elensefar is formally united to the kingdom. Settlements from it spread north of the river into the new frontier province of Annuvin, carefully avoiding the margins of Wesmere Forest.<br />
<br />
=== 164-176 YW ===<br />
* During this twelve year span, the western fortress of Halstead was erected in the very heart of the western wilderlands.<br />
<br />
=== 199 YW ===<br />
* Emboldened by the far-reaching arm of Halstead's protection, settlement in the west explodes<br />
* The settlements of Aldril and Carcyn grow to become major cities, the first as an important port due to its position on the Bay of Pearls, and the second as a stop on the road to Elensefar and military outpost along the Great River<br />
* Settlers from Carcyn cross the Great River to establish the first settlements north of it and east of Wesmere.<br />
<br />
== 200-350 YW: The Golden Age of Wesnoth ==<br />
The Golden Age of Wesnoth was the time of the great kings, and of peace and prosperity within the kingdom. The Orcs had suffered a grave defeat at the hands of Wesnoth and Elensefar seventy-five years earlier, so they did not pose much of a threat, and whenever they did attack they were quickly defeated. This allowed the army to lessen in size, and the kings of this age to undertake the great public works they are renowned for. The era ends when the king of Wesnoth dies without an heir, and a new dynasty begins.<br />
<br />
=== 251 YW ===<br />
* Cleodil, wife of Kalenz, dies.<br />
<br />
=== 350 YW ===<br />
* Disintegration of the Kingdom follows the death of Haldric IV.<br />
* Elensefar remains a province of Wesnoth but exerts increasing independence due to isolation.<br />
* Treaty between lord of Elensefar and king of Wesnoth signed.<br />
<br />
== 350-417 YW: The First Dark Age of Wesnoth ==<br />
The first Dark Age was a time of strife and invasion. When Haldric IV died, he left Wesnoth without a king, and the next 70 years were marked by short-lived dynasties, attacks by ever more aggressive orcs, and the further separation of Wesnoth and Elensefar. The Dark Age ended when Garard I took the throne, and began a new dynasty that would last for several hundred years.<br />
<br />
=== 360 YW ===<br />
* Malin Keshar born in Parthyn.<br />
<br />
=== 363 YW ===<br />
* Last of Kalenz's children dies. Kalenz, condemned to outlive his offspring by the potion of Crelanu, leaves the Forest of Lintanir and begins wandering the Great Continent.<br />
<br />
* Village of Maghre terrorized by a minor necromancer. Action of '''A Tale of Two Brothers''' takes place.<br />
<br />
=== 389 YW ===<br />
* Garard, a future king of Wesnoth, is born.<br />
* Malin Keshar returns to Parthyn from the Academy at Alduin. '''Descent Into Darkness''' begins.<br />
<br />
== 417-530 YW: The Turmoil of Asheviere ==<br />
King Garard's dynasty was long-lived and productive, but it was also punctuated by significant turmoil: the end of the first king's reign was marred by orcish and undead raids, and the second was murdered by his own wife and son. It was not until 517 YW that the usurpation of the throne by Queen Mother Asheviere was ended.<br />
<br />
=== 417 YW ===<br />
* Ending years of strife and division, Garard I seizes the throne and becomes king of Wesnoth, beginning the [[Garardine Dynasty]].<br />
<br />
=== 440 YW ===<br />
* Crown Prince Garard II is born.<br />
<br />
=== 442 YW ===<br />
* Delfador, later called "the Great", is born.<br />
<br />
=== 450 YW ===<br />
* Prince Arand is born.<br />
<br />
=== 468 YW ===<br />
* Zorlan becomes Great Chief of the northern orcs<br />
* Delfador graduates from the Great Academy. '''Delfador's Memoirs''' begins.<br />
<br />
=== 470 YW ===<br />
* Garard I dies; Garard II ascends to the throne of Wesnoth<br />
* Orcs under Great Chief Zorlan and undead raised by the necromancer Iliah-Malal raid Wesnoth's borders. All but the first and the last three scenarios of '''Delfador's Memoirs''' take place in this year.<br />
* Control of the Estmarks is effectively lost during this war, not to be regained for decades. Outposts are built on the near side of the Weldyn to repel orc raids. The long watch of the River Guard begins.<br />
<br />
=== 478 YW ===<br />
* Garard II marries Asheviere.<br />
* Garard issues the Edict of the Scepter, providing that the crown shall settle after his death on whichever member of the royal family successfully retrieves it from the Caverns of Flame.<br />
<br />
=== 480 YW ===<br />
* Crown Prince Eldred is born.<br />
<br />
=== 483 YW ===<br />
* Erain and Ethyn, identical twins and brothers of Eldred, are born.<br />
<br />
=== 498 YW ===<br />
* Princess Li'sar is born.<br />
<br />
=== 500 YW ===<br />
* Prince Konrad is born, the youngest of several sons of Prince Arand.<br />
* Wesnoth and the orcs of the north go to war.<br />
<br />
=== 501 YW ===<br />
<br />
===== Betrayal on the battlefield =====<br />
* Garard leads his army to orc encampment at Galcadar by the Ford of Abez.<br />
* Garard's forces split into two groups, one led by himself and the other by his son Eldred.<br />
* Eldred betrays his father and attacks him with the troops under his control.<br />
* Eldred slays King Garard and his uncle Prince Arand on the battlefield of Abez.<br />
<br />
===== Reprisal =====<br />
* Delfador escapes the battle and heads to Weldyn.<br />
* Eldred gives tribute to the Orcish king, who stops his attacks.<br />
* Delfador gathers a force of Loyalists to avenge Garard's Death.<br />
* Eldred's forces confront Delfador's Loyalists at Weldyn.<br />
* The Loyalists are defeated, but Eldred is slain by Delfador in the fight.<br />
<br />
===== Asheviere seizes power =====<br />
* Asheviere orders the slaughter of Garard's nephews and declares herself Queen of Wesnoth.<br />
* Hearing of the news Delfador infiltrates the palace.<br />
* Delfador finds the youngest prince Konrad as he is slain.<br />
* Delfador flees, taking Konrad's body for burial to the land of the Elves.<br />
* While traveling through Wesnoth, Elf Lady Parandra finds an orphaned human child.<br />
* Parandra and Delfador agree to give the orphan the identity of Prince Konrad.<br />
* Delfador and Konrad flee to live in refuge with the Wood Elves of the great southwestern forest.<br />
<br />
===== The country resists Asheviere =====<br />
* Elensefar refuses to submit to Asheviere and declares itself an independent city-state.<br />
* After several defeats, Wesnoth's army retreats from the remote areas of the kingdom. The western Wesnothian border recedes, is fixed, and remains heavily defended.<br />
* As a result of the loyalist withdrawal, several small human communities on the west coast of the Great Continent live in relative independence while elves flourish in the great forest to the southwest of Wesnoth.<br />
* A band of Wesnoth citizens organizes resistance to Asheviere's siezure of power. They are eventually forced to abandon their home and settle in the Three Sisters ('''Liberty''').<br />
<br />
=== 502-517 YW ===<br />
* Delfador raises Konrad under the protection of the Elves.<br />
<br />
=== 517 YW ===<br />
* Asheviere hires Orcish forces to hunt down her nephew-in-law Konrad.<br />
* Orcish forces converge on Delfador's refuge.<br />
* Konrad flees his home with the elves and embark upon a quest to regain the throne of Wesnoth. '''Heir To The Throne''' begins.<br />
<br />
=== 518 YW ===<br />
* Konrad crosses the Great River into the Northlands on a search for the Sceptre of Fire.<br />
* They enter the Caves of Knalga, allied with Princess Li'sar, and find it.<br />
* They return to Wesnoth and claim the throne. '''Heir to the Throne''' ends.<br />
<br />
=== 522 YW ===<br />
* Birth of Princess Ana'sar.<br />
<br />
=== 530 YW ===<br />
* Wesnothian colonists begin reclaiming the Estmarks.<br />
<br />
=== 544 YW ===<br />
* With both sides of the lower Weldyn River again civilized territory, the River Guard posts south of Soradoc are abandoned. Wesnothian military activity shifts eastward into the Estmarks.<br />
<br />
== 530-630 YW: The Age of Fear ==<br />
The Age of Fear takes its names from the events of the end of the era. On the surface, the first 90 years were very uneventful. However, during this time unexplainable magical events took place, especially in the eastern lands. Previously tamed lands were slowly claimed by wilderness as fear and paranoia gradually overshadowed the spirit of pioneering and adventure displayed earlier in Wesnoth's history. In the last 10 years of the age, Wesnoth bore the brunt of the most powerful Undead attack ever and was nearly destroyed. By the end of the era, most of Wesnoth had been made barren, most of the great buildings inside and outside of Weldyn were razed, and the population of Wesnoth was half of what it had been.<br />
<br />
It was in this era that certain areas of the chaotic Northlands were for the first time put into any kind of law and order. A small group of humans and dwarves, accepting anyone of any race who wished to join, formed themselves into the "Northern Alliance”, with the vision of making the Northlands safe to live in. Over time, this alliance grew slowly but steadily in power. By the end of the era, the alliance had succeeded in making a few small areas, including Knalga and the surrounding regions, stable and prosperous. Consequently, many people evacuated from the wasteland that most of Wesnoth had become and moved north - depleting the population of Wesnoth still further.<br />
<br />
=== 533 YW ===<br />
* Delfador succumbs to old age and dies, his body is entombed alongside his staff in Eregonor.<br />
* The next great sage of Wesnoth, Dacyn, is born.<br />
<br />
=== 534 YW ===<br />
<br />
* The small community of Dwarven Doors, in the Northlands just outside Knalga, rebels against the Orcish overlords. '''Northern Rebirth''' begins.<br />
* The residents, led by Tallin, head underground and find dwarves, whom they ally with.<br />
* Their combined forces destroy a lich who is attempting to claim Knalga as his own.<br />
<br />
=== 535 YW ===<br />
<br />
* The warlord-aspirant Rakshas attacks Tallin and his forces, but does not penetrate the dwarves' defences.<br />
* To help defeat the orcs, Tallin secures the help of two Liches, and rescues an elvish princess to secure the help of the elves.<br />
* Assisted by his new allies, Tallin smashes the forces of Rakshas.<br />
* According to some historians, Tallin and the elvish princess are married; others say they parted in bad blood.<br />
* To preserve the new-found peace in the Northlands, Tallin and his allies form the Northern Alliance. '''Northern Rebirth''' ends.<br />
<br />
=== 550 YW ===<br />
<br />
* Lord Hamel of Knalga sends an expedition to Kal Kartha to determine the fate of the Hammer of Thursagan ('''The Hammer of Thursagan''' takes place in late 550 YW to early 551 YW.).<br />
* Dwarves at Knalga and elsewhere begin to reclaim the lost art of runesmithing.<br />
* Wesnothian colonization expands southward past Fort Tahn.<br />
<br />
=== 563 YW ===<br />
* Konrad and Li'sar die after an extraordinarily long reign.<br />
* Princess Ana'sar becomes queen.<br />
* The seer Galdren becomes prominent at the court of Weldyn.<br />
<br />
=== 585 YW ===<br />
* Queen Ana'sar retires.<br />
* Haldric VII becomes king of Wesnoth.<br />
<br />
=== 589 YW ===<br />
* Dacyn the White Mage and Ravanal, an eastern wizard, compete to be the king's advisor.<br />
* The seer Galdren dies after advising Haldric VII to choose Dacyn.<br />
* The king does as Galdren advises.<br />
<br />
=== 593 YW ===<br />
* Ravanal reveals that he has turned to evil, and flees from Weldyn.<br />
* Konrad II is born.<br />
* Certain southern frontier regions are formally annexed to the Kingdom of Wesnoth as the Province of Kerlath.<br />
<br />
=== 598 YW ===<br />
* South Guard organized as a semi-detached formation of the Royal Army, to protect the inhabitants of the frontier province of Kerlath.<br />
<br />
=== 607 YW ===<br />
* South Guard ceases reporting. Haldric VII sends Deoran, son of Haldiel, to investigate. '''The South Guard''' takes place in 607-608 YW. <br />
<br />
=== 612 YW ===<br />
* Haldric VII dies. Konrad II is crowned King of Wesnoth.<br />
* Dacyn continues his duties as advisor with Konrad II.<br />
<br />
=== 625 YW ===<br />
* Mysterious disappearances of livestock and peasants cause partial evacuation of the the '''Estmark Hills'''. Lords of the Horse Plains report increased banditry from there.<br />
* Konrad II sends Dacyn with Owaec and Gweddry to man the old River Guard strongpoints. '''Eastern Invasion''' begins.<br />
<br />
=== 626 YW ===<br />
* Mal-Ravanal attacks the middle outpost where Gweddry and Dacyn are stationed.<br />
* Dacyn and Gweddry travel to the northern outpost, and, with Owaec, retreat into the northlands.<br />
* In the Far North, the merfolk city of Jotha is overrun by undead. The action of '''Dead Water''' takes place.<br />
<br />
=== 627 YW ===<br />
* Wesnoth's last defences are broken and the undead march on Wesnoth<br />
* In the northlands, the orcs drive Gweddry's army back across the river.<br />
* Weldyn is besieged.<br />
* Gweddry breaks through undead lines to reach Weldyn.<br />
* A council is held.<br />
* Gweddry's army is fortunate and kills Mal-Ravanal. '''Eastern Invasion''' ends.<br />
* Wesnoth is saved, but large portions have been laid waste by the undead.<br />
<br />
== 628-673 YW: The Silver Age of Wesnoth ==<br />
<br />
The Silver Age, or restoration of the Wesnothian kingdom, essentially coincides with the rest of the long and successful reign of Konrad II. During this period Wesnoth largely recovered from the damage that Mal-Ravanal's undead attack had done. It would, however, never quite regain the majesty it had at the height of its power.<br />
<br />
The Northlands, aided by a second wave of colonization north from Wesnoth, become more civilised and stable. Although nowhere near as prosperous as Wesnoth was during its Golden Age, the Northlands developed towns of significant size and a thriving - if somewhat dangerous - trade network. <br />
<br />
Four major powers soon came to dominate much of the Northlands. First there were the dwarves, who controlled most of the mountains and a vast array of underground tunnels and caverns. To the east, shrouded in mystery, lay the Elvish forests which continued to be inaccessible to anyone not of elvish blood. The remaining landscape was dominated either by orcish tribes, or independent human earldoms. As competition for the land grew fierce, wars smoldered between human and orcish forces. <br />
<br />
=== 628-635 YW ===<br />
* Konrad II begins his attempt to rebuild Wesnoth.<br />
<br />
=== 673 YW ===<br />
* Konrad II dies, bringing the [[Garardine Dynasty]] to an end. Second Wesnothian civil war begins.<br />
<br />
== 761-816 YW: The Legacy of Black-Eye Karun ==<br />
<br />
After decades of struggle, Black-Eye Karun becomes the first warlord since the assassination of Great Chief Brurbar in 20 YW to unite all the different squabbling orcish tribes under his banner. Among his many accomplishments as a Sovereign, his most famous is the creation of the Great Council. <br />
<br />
Karun was a far-sighted individual and he knew that after his death the orcish tribes would once again turn to fighting among themselves, with little he could do to prevent that and consequent peril from the Wesnothians and elves.<br />
<br />
Consequently, Karun selected from among all the different tribes six of the most sober and wisest orcs and thus created the Great Council. It was the Great Council's job to stay aloof from any tribal or territorial squabbling amongst the orcs, but yet always remain there to give advice to whomever came to seek it. In order to preserve the orcish race in the event of an emergency, he invested in them the power to call up The Great Horde. It was established that every orc, no matter what tribe he came from, must obey the summons of The Great Horde and follow wholeheartedly the leader that the Great Council put at the head of The Great Horde.<br />
<br />
===816 YW===<br />
* Rahul I (Lord Protector of the Northern Alliance) and Black Eye Karun sign a peace treaty ending a 15 year war between the humans and the orcs. Soon after this Karun, is ambushed and killed in mysterious circumstances.<br />
<br />
===842 YW===<br />
* War once again breaks out between the orcish tribes and the northern human earldoms as humans break the long standing treaty and attempt to colonise orcish lands. In response, the Great Council set up by the Black Eye Karun calls upon The Great Horde and bestows leadership of it upon Kapou’e; '''Son of the Black Eye''' begins.<br />
<br />
===843 YW===<br />
* Half of the Great Council is treacherously slain by the allied human forces and orcish unity disintegrates. Faced with the extermination of all the orcs on the Great Continent, Kapou’e forcibly asserts his control over the orcish territories and defeats the enemy forces. The Northern Alliance arrives on the scene in time for the final battle and helps Kapou’e defeat the forces of the northern earldoms, who had broken the treaty. Kapou’e then assumes the position of Sovereign over the northern tribes, and his rule ushers in an unprecedented era of unity and prosperity for the orcs.<br />
<br />
===852 YW===<br />
*Kapou’e repels a large elvish invasion.<br />
<br />
===858 YW===<br />
<br />
*The humans once again stage an invasion but prove to be no match for the united orcish forces under the leadership of Kapou’e. '''Son of the Black Eye''' ends.<br />
<br />
==After the Fall==<br />
At some unknown point in the future, an unspeakable cataclysm scorched the surface of the lands. Forests died, hills turned into rocky wastelands and fields became barren deserts. In the apocalypse allies turned against each other and friends fought over what few resources remained. The great nations were destroyed, and huge numbers of people died. Still amidst the chaos somehow small groups of people survived, sheltered in hidden places. In this post-apocalyptic world survival is a daily struggle as a few remaining tribes eke out an existence among the ruins of fallen empires. Heroic bands of elves, nomadic refugee humans, savage hordes of orcs and dark necromancers all forge new lives under the merciless dual suns, Sela and Naia, of this new Wesnoth.<br />
<br />
===??? Post-Wesnoth===<br />
<br />
* The Quenoth elves adapt to life in barren world of the Great Southern Desert. Over time they lost their affinity for the woodlands of their ancestry and embrace life in the sandy wastelands.<br />
* Under the leadership of Tanuil, the Quenoth elves build and sustain a fortified village around a rare oasis. The village thrives amidst the hostilities of the desert.<br />
* One night, a meteor storm rains from the sky and destroys the village of the Quenoth elves. '''Under the Burning Suns''' begins. The next day, Tanuil, like many others, is missing and presumed dead. Kalehssar (Kaleh), nephew of Tanuil, takes leadership of the remaining Quenoth elves as the surviving next of kin.<br />
* Kaleh, heeding the voice of his god Eloh in his dreams, gathers the remaining Quenoth elves and leads them north to a new promised land, foregoing rebuilding of their desert village.<br />
* The Quenoth elves battle their way north through Undead, Orcs, Bandits and other evil, venturing underground beneath a large mountain range at the command of Eloh.<br />
* Befriending unexpected allies underground, Kaleh's forces survive to the other side of the mountain.<br />
* Keratur, son of Tanuil and survivor of the cataclysm, insane with fright attacks Kaleh. Kaleh defeats Keratur.<br />
* Kaleh defies commands given him by a vision of Eloh.<br />
* The Quenoth reach the ocean. Aided by Merfolk, they escape the mainland and head for a newly discovered island, a place where the Quenoth may settle in peace.<br />
* On the island, the Quenoth confront Yechnagoth, the Eater of Souls and impersonator of Eloh. Yechnagoth and army are destroyed by the Quenoth.<br />
* Kaleh and the elves settle on their newfound, and newly named, Quenoth Isle. '''Under the Burning Suns''' ends.<br />
<br />
== History Credits ==<br />
<br />
* Timelined by Kamahawk and Turin. Revised to incorporate material from later version of Legend of Wesmere and reconcile different versions of the history of the Scepter of Fire by Eric S. Raymond.<br />
<br />
* History derived from:<br />
** Eastern Invasion<br />
** Heir to the Throne<br />
** Legend of Wesmere<br />
** Liberty<br />
** Northern Rebirth<br />
** The Hammer of Thursagan<br />
** The Rise of Wesnoth<br />
** Under the Burning Suns<br />
** Dead Water<br />
** Delfador's Memoirs<br />
<br />
* Setting details derived from:<br />
** Invasion from the Unknown<br />
<br />
== See Also ==<br />
<br />
* [[Geography of Wesnoth]]<br />
* [[Poetry of Wesnoth]]<br />
* [[Races]]<br />
* [[FactionHistory]]<br />
<br />
[[Category:World of Wesnoth]]<br />
[[Category:History]]</div>Fabihttps://wiki.wesnoth.org/index.php?title=Timeline_of_Wesnoth&diff=42922Timeline of Wesnoth2011-06-06T23:42:54Z<p>Fabi: /* 761-816 YW: The Legacy of Black-Eye Karun */</p>
<hr />
<div>This is a chronological history of the country of Wesnoth and surrounding regions, gleaned from written accounts and verbal histories passed down through the generations. Portions of entries surrounded by parentheses and containing a question mark are assumed or unconfirmed information. The history is sorted by era, and within the era by date, using the Foundation of Wesnoth as a base. BW=Before Wesnoth, YW=Years Wesnoth. They function the same way as BC and AD do in our timekeeping system. Each of the eras is summarized before the timeline for that era begins. This history of the Great Continent is a subject of active scholarship.<br />
<br />
The world that Wesnoth resides in is called Irdya. Before the Fall and the (unchronicled) technological age, this name is only rarely used. <br />
<br />
<br />
'''Spoiler warning!'''<br />
This page contains plot spoilers to several campaigns.<br />
<br />
__NOTOC__<br />
[[#Prehistory - 20 YW: The Founding of Wesnoth|The Founding of Wesnoth]]<br />
<br />
[[#20-130 YW: The Taming of the Wild|The Taming of the Wild]]<br />
<br />
[[#200-350 YW: The Golden Age of Wesnoth|The Golden Age of Wesnoth]]<br />
<br />
[[#350-417 YW: The First Dark Age of Wesnoth|The First Dark Age of Wesnoth]]<br />
<br />
[[#417-530 YW: The Turmoil of Asheviere|The Turmoil of Asheviere]]<br />
<br />
[[#530-630 YW: The Age of Fear|The Age of Fear]]<br />
<br />
[[#628-673 YW: The Silver Age of Wesnoth|The Silver Age of Wesnoth]]<br />
<br />
[[#761-816 YW: The Legacy of Black-Eye Karun|The Legacy of Black-Eye Karun]]<br />
<br />
[[#After the Fall|After the Fall]]<br />
<br />
== Prehistory - 20 YW: The Founding of Wesnoth ==<br />
During the age of the Founding of Wesnoth, there were two important geographic locations, these being the Green Isle and the Great Continent. Haldric is the main historical figure at this time. This age ends with the founding of Wesnoth as a country in the Great Continent, and with Orcs attacking both elves and men from the sea.<br />
<br />
=== Prehistory ===<br />
* Elves and Dwarves inhabit the Great Continent.<br />
* Humans inhabit the distant West.<br />
* Haldric's people colonise the Green Isle from a continent further to the west.<br />
<br />
=== 200 BW ===<br />
* The Lich-Lords arrive on the Green Isle after losing a war in the distant West.<br />
* After a long war Haldric's people come to dominate the Green Isle.<br />
* The 'Wesfolk' and their Lich-Lords are pushed onto marginal lands.<br />
<br />
=== 12 BW ===<br />
* The Crown Prince of Southbay discovers the Great Continent.<br />
<br />
=== 11-7 BW ===<br />
* The Crown Prince makes several voyages between the Green Isle and the Great Continent.<br />
<br />
=== 6 BW ===<br />
* Following these voyages to the Great Continent, the elder Crown Prince falls ill and dies.<br />
* His younger brother is implicated in a plot to kill him.<br />
* As a distraction the younger Prince starts a war with the Wesfolk and their Lich-Lords.<br />
* The Lich-Lords sense they will be destroyed and open gates to the homeland of the Orcs in the West.<br />
<br />
=== 5-2 BW ===<br />
* The Green Isle is overrun with Orcs.<br />
* The Wesfolk desert their Lich-Lords as they fear becoming prey for the Orcs.<br />
* Prince Haldric leads the evacuation of the survivors to the Great Continent. '''The Rise of Wesnoth''' begins.<br />
<br />
=== 1 BW ===<br />
* Human settlers, led by Prince Haldric, arrive at the western coast of the Great Continent (the landfall occurs in the future Bay of Pearls) in large numbers.<br />
* Humans arrive in the middle of a simmering dispute between the Elves and Dwarves.<br />
* The Elves and Dwarves are distrustful of humans, and there is a small skirmish.<br />
* Messengers from Wesmere Forest come and ask Haldric to come before the Ka'lian.<br />
* Prince Haldric asks the Four Elvish Lords (Dionli, Logalmier, Aryad, and El'Isomithir) for help and land.<br />
* They set before him four quests to prove his worth, which he completes.<br />
<br />
=== 1 YW ===<br />
* Haldric is granted the plains north and south of the Great River.<br />
* Haldric agrees to a Pact of Mutual Defence with the Elves, but the Ka'lian decides it will betray him and allow humans and orcs to exhaust each other in war if the opportunity presents. Haldric, learning of this, considers the Pact a dead letter.<br />
* The Ruby of Fire is temporarily hidden, and the lich-lord Jevyan is deceived into believing it is held by the Elves. <br />
* Haldric founds the country of Wesnoth in the central plain south of the great River.<br />
* Reign of Haldric I begins. '''The Rise of Wesnoth''' ends.<br />
<br />
=== 2 YW ===<br />
* Orcs, following the ships fleeing from the Green Isle, begin to arrive on the Great Continent.<br />
* These Orcs are defeated by Haldric's forces.<br />
* Some of the Orcish survivors flee back to the Green Isle, others move to attack the Elves.<br />
* King Haldric helps the Elves fight the surviving Orcs.<br />
<br />
=== 8 YW ===<br />
* A second wave of Orcs arrive from the Green Isle; these Orcs begin claiming large portions of the northern Great Continent for themselves.<br />
* Erlornas of Wesmere is involved in the first direct elvish clash with orcs ('''An Orcish Incursion''' takes place in 8-9YW).<br />
* Haldric I publicly repudiates the Pact he spoke with the Elves, refusing to give aid.<br />
<br />
=== 9-11 YW ===<br />
* Many Elves are killed in battle by the Orcs.<br />
* Elvish emissaries are turned away from Wesnoth.<br />
<br />
=== 12 YW ===<br />
* Orcs fail to take the Wesmere Forest and instead march down the coast, devastating human settlements there.<br />
* Elves refuse to aid the Humans in confronting the Orcs.<br />
* Human refugees from the coastal settlements relocate in what will become known as the Great Central Plain. Dan'Tonk, which will become Wesnoth's largest city, is founded.<br />
<br />
=== 20 YW ===<br />
* Haldric I dies.<br />
* Haldric II ascends to the throne.<br />
* Kalenz and Landar escape an orcish invasion of their home in Lintanir Forest. '''The Legend of Wesmere''' begins.<br />
* Humans and elves decisively defeat the orcs at Tath, thus halting the orcish advance.<br />
* A new treaty between humans and elves is signed and King Haldric II allows emissaries of the Elves to return to Wesnoth.<br />
* Elves inform Haldric II of the danger posed by the unshielded Ruby of Fire.<br />
* Kalenz and Landar, later to become successive High Lords of the Elves, are able to sneak into an orcish camp by stealth and assassinate the Great Chief. A long orcish civil war for succession follows. The orcs are unable to undertake action against any other race during this period and Wesnoth enjoys a long period during which it can expand with little opposition.<br />
<br />
== 20-130 YW: The Taming of the Wild ==<br />
This era is that in which the kingdom of Wesnoth expanded and defined its borders, and settled the area which it had claimed for its own. The Taming of the Wild refers to the settling of the unsettled lands, as well as to the colonization of the Northlands. The end of this era is marked by friction between the city-state of Elensefar and the country of Wesnoth, which will continue for the next several hundred years.<br />
<br />
=== 21 YW ===<br />
* Founding of the Great Academy on Alduin.<br />
<br />
* Kalenz is relieved of command by the Ka'lian. He retires to Lintanir Forest with Cleodil. A faction of xenophobic elves begins to gether around Landar.<br />
<br />
=== 25-40 YW ===<br />
* In 25 YW Haldric II sends an expedition to retrieve the Ruby of Fire from its place of concealment.<br />
* Haldric II commissions a Dwarven tribe to build the Scepter of Fire with the Ruby of Fire as its centerpiece; Elves associated with Landar's faction attack during the transfer. '''Scepter of Fire''' begins.<br />
* Action of '''The Scepter of Fire''' takes place. Haldric II is informed that the Scepter was both completed and lost in the year 40. It will not be recovered for nearly 500 years.<br />
* With the death of Thursagan, the Runemaster, all runemasters are killed and runesmithing is lost for several centuries.<br />
<br />
=== 26-50 YW ===<br />
* Landar declares himself High Lord of the Elves, leading to civil war. <br />
<br />
=== 51 YW ===<br />
* Wesnothian New Writing (the script later called "steel-hand", to distinguish it from the more complex "brush-hand" cursive brought from the Green Isle) is promulgated by royal decree. From this date all royal documents and public inscriptions are in New Writing. It spreads rapidly via the mercantile class. The older brush-hand writing continues to be used for magical purposes, scholarship, and in certain elevated literary forms.<br />
<br />
=== 50-93 YW ===<br />
* Elvish civil war (and '''The Legend of Wesmere''') ends. Kalenz declared High Lord, begins reorganizing and militarizing Elvish society to fight the orcs. In late 93 YW he cedes control to a reconstituted Ka'lian and retires again to the Forest of Lintanir.<br />
<br />
=== 121 YW ===<br />
* Orcish civil war sputters to a halt. Raids on elves and humans resume. Period of uncontested human expansion ends, but the Wesnothian Army is more than equal to any of its opponents in battle.<br />
<br />
=== 122 YW ===<br />
* City of Elensefar is sacked by orcs.<br />
* Meneldur, a sailor of Elensefar, sets out on a quest to regain the city.<br />
<br />
=== 123 YW ===<br />
* Elensefar is retaken by Meneldur along with Undead from the Green Isle.<br />
* Elensefar becomes an independent city-state for the first time.<br />
<br />
=== 161-164 YW ===<br />
* The newly crowned king sought to make safe once and for all the wildlands that separated the human cities surrounding Weldyn and the coastal regions of Elensefar.<br />
* The grand army of Wesnoth, personally led by the High Council of Archmagi, destroyed all enemies residing within Wesnoth.<br />
* The city-state of Elensefar is formally united to the kingdom. Settlements from it spread north of the river into the new frontier province of Annuvin, carefully avoiding the margins of Wesmere Forest.<br />
<br />
=== 164-176 YW ===<br />
* During this twelve year span, the western fortress of Halstead was erected in the very heart of the western wilderlands.<br />
<br />
=== 199 YW ===<br />
* Emboldened by the far-reaching arm of Halstead's protection, settlement in the west explodes<br />
* The settlements of Aldril and Carcyn grow to become major cities, the first as an important port due to its position on the Bay of Pearls, and the second as a stop on the road to Elensefar and military outpost along the Great River<br />
* Settlers from Carcyn cross the Great River to establish the first settlements north of it and east of Wesmere.<br />
<br />
== 200-350 YW: The Golden Age of Wesnoth ==<br />
The Golden Age of Wesnoth was the time of the great kings, and of peace and prosperity within the kingdom. The Orcs had suffered a grave defeat at the hands of Wesnoth and Elensefar seventy-five years earlier, so they did not pose much of a threat, and whenever they did attack they were quickly defeated. This allowed the army to lessen in size, and the kings of this age to undertake the great public works they are renowned for. The era ends when the king of Wesnoth dies without an heir, and a new dynasty begins.<br />
<br />
=== 251 YW ===<br />
* Cleodil, wife of Kalenz, dies.<br />
<br />
=== 350 YW ===<br />
* Disintegration of the Kingdom follows the death of Haldric IV.<br />
* Elensefar remains a province of Wesnoth but exerts increasing independence due to isolation.<br />
* Treaty between lord of Elensefar and king of Wesnoth signed.<br />
<br />
== 350-417 YW: The First Dark Age of Wesnoth ==<br />
The first Dark Age was a time of strife and invasion. When Haldric IV died, he left Wesnoth without a king, and the next 70 years were marked by short-lived dynasties, attacks by ever more aggressive orcs, and the further separation of Wesnoth and Elensefar. The Dark Age ended when Garard I took the throne, and began a new dynasty that would last for several hundred years.<br />
<br />
=== 360 YW ===<br />
* Malin Keshar born in Parthyn.<br />
<br />
=== 363 YW ===<br />
* Last of Kalenz's children dies. Kalenz, condemned to outlive his offspring by the potion of Crelanu, leaves the Forest of Lintanir and begins wandering the Great Continent.<br />
<br />
* Village of Maghre terrorized by a minor necromancer. Action of '''A Tale of Two Brothers''' takes place.<br />
<br />
=== 389 YW ===<br />
* Garard, a future king of Wesnoth, is born.<br />
* Malin Keshar returns to Parthyn from the Academy at Alduin. '''Descent Into Darkness''' begins.<br />
<br />
== 417-530 YW: The Turmoil of Asheviere ==<br />
King Garard's dynasty was long-lived and productive, but it was also punctuated by significant turmoil: the end of the first king's reign was marred by orcish and undead raids, and the second was murdered by his own wife and son. It was not until 517 YW that the usurpation of the throne by Queen Mother Asheviere was ended.<br />
<br />
=== 417 YW ===<br />
* Ending years of strife and division, Garard I seizes the throne and becomes king of Wesnoth, beginning the [[Garardine Dynasty]].<br />
<br />
=== 440 YW ===<br />
* Crown Prince Garard II is born.<br />
<br />
=== 442 YW ===<br />
* Delfador, later called "the Great", is born.<br />
<br />
=== 450 YW ===<br />
* Prince Arand is born.<br />
<br />
=== 468 YW ===<br />
* Zorlan becomes Great Chief of the northern orcs<br />
* Delfador graduates from the Great Academy. '''Delfador's Memoirs''' begins.<br />
<br />
=== 470 YW ===<br />
* Garard I dies; Garard II ascends to the throne of Wesnoth<br />
* Orcs under Great Chief Zorlan and undead raised by the necromancer Iliah-Malal raid Wesnoth's borders. All but the first and the last three scenarios of '''Delfador's Memoirs''' take place in this year.<br />
* Control of the Estmarks is effectively lost during this war, not to be regained for decades. Outposts are built on the near side of the Weldyn to repel orc raids. The long watch of the River Guard begins.<br />
<br />
=== 478 YW ===<br />
* Garard II marries Asheviere.<br />
* Garard issues the Edict of the Scepter, providing that the crown shall settle after his death on whichever member of the royal family successfully retrieves it from the Caverns of Flame.<br />
<br />
=== 480 YW ===<br />
* Crown Prince Eldred is born.<br />
<br />
=== 483 YW ===<br />
* Erain and Ethyn, identical twins and brothers of Eldred, are born.<br />
<br />
=== 498 YW ===<br />
* Princess Li'sar is born.<br />
<br />
=== 500 YW ===<br />
* Prince Konrad is born, the youngest of several sons of Prince Arand.<br />
* Wesnoth and the orcs of the north go to war.<br />
<br />
=== 501 YW ===<br />
<br />
===== Betrayal on the battlefield =====<br />
* Garard leads his army to orc encampment at Galcadar by the Ford of Abez.<br />
* Garard's forces split into two groups, one led by himself and the other by his son Eldred.<br />
* Eldred betrays his father and attacks him with the troops under his control.<br />
* Eldred slays King Garard and his uncle Prince Arand on the battlefield of Abez.<br />
<br />
===== Reprisal =====<br />
* Delfador escapes the battle and heads to Weldyn.<br />
* Eldred gives tribute to the Orcish king, who stops his attacks.<br />
* Delfador gathers a force of Loyalists to avenge Garard's Death.<br />
* Eldred's forces confront Delfador's Loyalists at Weldyn.<br />
* The Loyalists are defeated, but Eldred is slain by Delfador in the fight.<br />
<br />
===== Asheviere seizes power =====<br />
* Asheviere orders the slaughter of Garard's nephews and declares herself Queen of Wesnoth.<br />
* Hearing of the news Delfador infiltrates the palace.<br />
* Delfador finds the youngest prince Konrad as he is slain.<br />
* Delfador flees, taking Konrad's body for burial to the land of the Elves.<br />
* While traveling through Wesnoth, Elf Lady Parandra finds an orphaned human child.<br />
* Parandra and Delfador agree to give the orphan the identity of Prince Konrad.<br />
* Delfador and Konrad flee to live in refuge with the Wood Elves of the great southwestern forest.<br />
<br />
===== The country resists Asheviere =====<br />
* Elensefar refuses to submit to Asheviere and declares itself an independent city-state.<br />
* After several defeats, Wesnoth's army retreats from the remote areas of the kingdom. The western Wesnothian border recedes, is fixed, and remains heavily defended.<br />
* As a result of the loyalist withdrawal, several small human communities on the west coast of the Great Continent live in relative independence while elves flourish in the great forest to the southwest of Wesnoth.<br />
* A band of Wesnoth citizens organizes resistance to Asheviere's siezure of power. They are eventually forced to abandon their home and settle in the Three Sisters ('''Liberty''').<br />
<br />
=== 502-517 YW ===<br />
* Delfador raises Konrad under the protection of the Elves.<br />
<br />
=== 517 YW ===<br />
* Asheviere hires Orcish forces to hunt down her nephew-in-law Konrad.<br />
* Orcish forces converge on Delfador's refuge.<br />
* Konrad flees his home with the elves and embark upon a quest to regain the throne of Wesnoth. '''Heir To The Throne''' begins.<br />
<br />
=== 518 YW ===<br />
* Konrad crosses the Great River into the Northlands on a search for the Sceptre of Fire.<br />
* They enter the Caves of Knalga, allied with Princess Li'sar, and find it.<br />
* They return to Wesnoth and claim the throne. '''Heir to the Throne''' ends.<br />
<br />
=== 522 YW ===<br />
* Birth of Princess Ana'sar.<br />
<br />
=== 530 YW ===<br />
* Wesnothian colonists begin reclaiming the Estmarks.<br />
<br />
=== 544 YW ===<br />
* With both sides of the lower Weldyn River again civilized territory, the River Guard posts south of Soradoc are abandoned. Wesnothian military activity shifts eastward into the Estmarks.<br />
<br />
== 530-630 YW: The Age of Fear ==<br />
The Age of Fear takes its names from the events of the end of the era. On the surface, the first 90 years were very uneventful. However, during this time unexplainable magical events took place, especially in the eastern lands. Previously tamed lands were slowly claimed by wilderness as fear and paranoia gradually overshadowed the spirit of pioneering and adventure displayed earlier in Wesnoth's history. In the last 10 years of the age, Wesnoth bore the brunt of the most powerful Undead attack ever and was nearly destroyed. By the end of the era, most of Wesnoth had been made barren, most of the great buildings inside and outside of Weldyn were razed, and the population of Wesnoth was half of what it had been.<br />
<br />
It was in this era that certain areas of the chaotic Northlands were for the first time put into any kind of law and order. A small group of humans and dwarves, accepting anyone of any race who wished to join, formed themselves into the "Northern Alliance”, with the vision of making the Northlands safe to live in. Over time, this alliance grew slowly but steadily in power. By the end of the era, the alliance had succeeded in making a few small areas, including Knalga and the surrounding regions, stable and prosperous. Consequently, many people evacuated from the wasteland that most of Wesnoth had become and moved north - depleting the population of Wesnoth still further.<br />
<br />
=== 533 YW ===<br />
* Delfador succumbs to old age and dies, his body is entombed alongside his staff in Eregonor.<br />
* The next great sage of Wesnoth, Dacyn, is born.<br />
<br />
=== 534 YW ===<br />
<br />
* The small community of Dwarven Doors, in the Northlands just outside Knalga, rebels against the Orcish overlords. '''Northern Rebirth''' begins.<br />
* The residents, led by Tallin, head underground and find dwarves, whom they ally with.<br />
* Their combined forces destroy a lich who is attempting to claim Knalga as his own.<br />
<br />
=== 535 YW ===<br />
<br />
* The warlord-aspirant Rakshas attacks Tallin and his forces, but does not penetrate the dwarves' defences.<br />
* To help defeat the orcs, Tallin secures the help of two Liches, and rescues an elvish princess to secure the help of the elves.<br />
* Assisted by his new allies, Tallin smashes the forces of Rakshas.<br />
* According to some historians, Tallin and the elvish princess are married; others say they parted in bad blood.<br />
* To preserve the new-found peace in the Northlands, Tallin and his allies form the Northern Alliance. '''Northern Rebirth''' ends.<br />
<br />
=== 550 YW ===<br />
<br />
* Lord Hamel of Knalga sends an expedition to Kal Kartha to determine the fate of the Hammer of Thursagan ('''The Hammer of Thursagan''' takes place in late 550 YW to early 551 YW.).<br />
* Dwarves at Knalga and elsewhere begin to reclaim the lost art of runesmithing.<br />
* Wesnothian colonization expands southward past Fort Tahn.<br />
<br />
=== 563 YW ===<br />
* Konrad and Li'sar die after an extraordinarily long reign.<br />
* Princess Ana'sar becomes queen.<br />
* The seer Galdren becomes prominent at the court of Weldyn.<br />
<br />
=== 585 YW ===<br />
* Queen Ana'sar retires.<br />
* Haldric VII becomes king of Wesnoth.<br />
<br />
=== 589 YW ===<br />
* Dacyn the White Mage and Ravanal, an eastern wizard, compete to be the king's advisor.<br />
* The seer Galdren dies after advising Haldric VII to choose Dacyn.<br />
* The king does as Galdren advises.<br />
<br />
=== 593 YW ===<br />
* Ravanal reveals that he has turned to evil, and flees from Weldyn.<br />
* Konrad II is born.<br />
* Certain southern frontier regions are formally annexed to the Kingdom of Wesnoth as the Province of Kerlath.<br />
<br />
=== 598 YW ===<br />
* South Guard organized as a semi-detached formation of the Royal Army, to protect the inhabitants of the frontier province of Kerlath.<br />
<br />
=== 607 YW ===<br />
* South Guard ceases reporting. Haldric VII sends Deoran, son of Haldiel, to investigate. '''The South Guard''' takes place in 607-608 YW. <br />
<br />
=== 612 YW ===<br />
* Haldric VII dies. Konrad II is crowned King of Wesnoth.<br />
* Dacyn continues his duties as advisor with Konrad II.<br />
<br />
=== 625 YW ===<br />
* Mysterious disappearances of livestock and peasants cause partial evacuation of the the '''Estmark Hills'''. Lords of the Horse Plains report increased banditry from there.<br />
* Konrad II sends Dacyn with Owaec and Gweddry to man the old River Guard strongpoints. '''Eastern Invasion''' begins.<br />
<br />
=== 626 YW ===<br />
* Mal-Ravanal attacks the middle outpost where Gweddry and Dacyn are stationed.<br />
* Dacyn and Gweddry travel to the northern outpost, and, with Owaec, retreat into the northlands.<br />
* In the Far North, the merfolk city of Jotha is overrun by undead. The action of '''Dead Water''' takes place.<br />
<br />
=== 627 YW ===<br />
* Wesnoth's last defences are broken and the undead march on Wesnoth<br />
* In the northlands, the orcs drive Gweddry's army back across the river.<br />
* Weldyn is besieged.<br />
* Gweddry breaks through undead lines to reach Weldyn.<br />
* A council is held.<br />
* Gweddry's army is fortunate and kills Mal-Ravanal. '''Eastern Invasion''' ends.<br />
* Wesnoth is saved, but large portions have been laid waste by the undead.<br />
<br />
== 628-673 YW: The Silver Age of Wesnoth ==<br />
<br />
The Silver Age, or restoration of the Wesnothian kingdom, essentially coincides with the rest of the long and successful reign of Konrad II. During this period Wesnoth largely recovered from the damage that Mal-Ravanal's undead attack had done. It would, however, never quite regain the majesty it had at the height of its power.<br />
<br />
The Northlands, aided by a second wave of colonization north from Wesnoth, become more civilised and stable. Although nowhere near as prosperous as Wesnoth was during its Golden Age, the Northlands developed towns of significant size and a thriving - if somewhat dangerous - trade network. <br />
<br />
Four major powers soon came to dominate much of the Northlands. First there were the dwarves, who controlled most of the mountains and a vast array of underground tunnels and caverns. To the east, shrouded in mystery, lay the Elvish forests which continued to be inaccessible to anyone not of elvish blood. The remaining landscape was dominated either by orcish tribes, or independent human earldoms. As competition for the land grew fierce, wars smoldered between human and orcish forces. <br />
<br />
=== 628-635 YW ===<br />
* Konrad II begins his attempt to rebuild Wesnoth.<br />
<br />
=== 673 YW ===<br />
* Konrad II dies, bringing the [[Garardine Dynasty]] to an end. Second Wesnothian civil war begins.<br />
<br />
== 761-816 YW: The Legacy of Black-Eye Karun ==<br />
<br />
After decades of struggle, Black-Eye Karun becomes the first warlord since the assassination of Great Chief Brurbar in 20 YW to unite all the different squabbling orcish tribes under his banner. Among his many accomplishments as a Sovereign, his most famous is the creation of the Great Council. <br />
<br />
Karun was a far-sighted individual and he knew that after his death the orcish tribes would once again turn to fighting among themselves, with little he could do to prevent that and consequent peril from the Wesnothians and elves.<br />
<br />
Consequently, Karun selected from among all the different tribes six of the most sober and wisest orcs and thus created the Great Council. It was the Great Council's job to stay aloof from any tribal or territorial squabbling amongst the orcs, but yet always remain there to give advice to whomever came to seek it. In order to preserve the orcish race in the event of an emergency, he invested in them the power to call up The Great Horde. It was established that every orc, no matter what tribe he came from, must obey the summons of The Great Horde and follow wholeheartedly the leader that the Great Council put at the head of The Great Horde.<br />
<br />
===816 YW===<br />
* Rahul I (Lord Protector of the Northern Alliance) and Black Eye Karun sign a peace treaty ending a 15 year war between the humans and the orcs. Soon after this Karun, is ambushed and killed in mysterious circumstances.<br />
<br />
===842 YW===<br />
* War once again breaks out between the orcish tribes and the northern human earldoms as humans break the long standing treaty and attempt to colonise orcish lands. In response, the Great Council set up by the Black Eye Karun calls upon The Great Horde and bestows leadership of it upon Kapou’e; '''Son of the Black Eye''' begins.<br />
<br />
===843 YW===<br />
* Half of the Great Council is treacherously slain by the allied human forces and orcish unity disintegrates. Faced with the extermination of all the orcs on the Great Continent, Kapou’e forcibly asserts his control over the orcish territories and defeats the enemy forces. The Northern Alliance arrives on the scene in time for the final battle and helps Kapou’e defeat the forces of the northern earldoms, who had broken the treaty. Kapou’e then assumes the position of Sovereign over the northern tribes, and his rule ushers in an unprecedented era of unity and prosperity for the orcs.<br />
<br />
===852 YW===<br />
*Kapou’e repels a large elvish invasion.<br />
<br />
===858 YW===<br />
<br />
*The humans once again stage an invasion but prove to be no match for the united orcish forces under the leadership of Kapou’e. '''Son of the Black Eye''' ends.<br />
<br />
==After the Fall==<br />
At some unknown point in the future, an unspeakable cataclysm scorched the surface of the lands. Forests died, hills turned into rocky wastelands and fields became barren deserts. In the apocalypse allies turned against each other and friends fought over what few resources remained. The great nations were destroyed, and huge numbers of people died. Still amidst the chaos somehow small groups of people survived, sheltered in hidden places. In this post-apocalyptic world survival is a daily struggle as a few remaining tribes eke out an existence among the ruins of fallen empires. Heroic bands of elves, nomadic refugee humans, savage hordes of orcs and dark necromancers all forge new lives under the merciless dual suns, Sela and Naia, of this new Wesnoth.<br />
<br />
===??? Post-Wesnoth===<br />
<br />
* The Quenoth elves adapt to life in barren world of the Great Southern Desert. Over time they lost their affinity for the woodlands of their ancestry and embrace life in the sandy wastelands.<br />
* Under the leadership of Tanuil, the Quenoth elves build and sustain a fortified village around a rare oasis. The village thrives amidst the hostilities of the desert.<br />
* One night, a meteor storm rains from the sky and destroys the village of the Quenoth elves. The next day, Tanuil, like many others, is missing and presumed dead. Kalehssar (Kaleh), nephew of Tanuil, takes leadership of the remaining Quenoth elves as the surviving next of kin.<br />
* Kaleh, heeding the voice of his god Eloh in his dreams, gathers the remaining Quenoth elves and leads them north to a new promised land, foregoing rebuilding of their desert village.<br />
* The Quenoth elves battle their way north through Undead, Orcs, Bandits and other evil, venturing underground beneath a large mountain range at the command of Eloh.<br />
* Befriending unexpected allies underground, Kaleh's forces survive to the other side of the mountain.<br />
* Keratur, son of Tanuil and survivor of the cataclysm, insane with fright attacks Kaleh. Kaleh defeats Keratur.<br />
* Kaleh defies commands given him by a vision of Eloh.<br />
* The Quenoth reach the ocean. Aided by Merfolk, they escape the mainland and head for a newly discovered island, a place where the Quenoth may settle in peace.<br />
* On the island, the Quenoth confront Yechnagoth, the Eater of Souls and impersonator of Eloh. Yechnagoth and army are destroyed by the Quenoth.<br />
* Kaleh and the elves settle on their newfound, and newly named, Quenoth Isle.<br />
<br />
== History Credits ==<br />
<br />
* Timelined by Kamahawk and Turin. Revised to incorporate material from later version of Legend of Wesmere and reconcile different versions of the history of the Scepter of Fire by Eric S. Raymond.<br />
<br />
* History derived from:<br />
** Eastern Invasion<br />
** Heir to the Throne<br />
** Legend of Wesmere<br />
** Liberty<br />
** Northern Rebirth<br />
** The Hammer of Thursagan<br />
** The Rise of Wesnoth<br />
** Under the Burning Suns<br />
** Dead Water<br />
** Delfador's Memoirs<br />
<br />
* Setting details derived from:<br />
** Invasion from the Unknown<br />
<br />
== See Also ==<br />
<br />
* [[Geography of Wesnoth]]<br />
* [[Poetry of Wesnoth]]<br />
* [[Races]]<br />
* [[FactionHistory]]<br />
<br />
[[Category:World of Wesnoth]]<br />
[[Category:History]]</div>Fabihttps://wiki.wesnoth.org/index.php?title=Timeline_of_Wesnoth&diff=42921Timeline of Wesnoth2011-06-06T23:31:07Z<p>Fabi: /* 20 YW */</p>
<hr />
<div>This is a chronological history of the country of Wesnoth and surrounding regions, gleaned from written accounts and verbal histories passed down through the generations. Portions of entries surrounded by parentheses and containing a question mark are assumed or unconfirmed information. The history is sorted by era, and within the era by date, using the Foundation of Wesnoth as a base. BW=Before Wesnoth, YW=Years Wesnoth. They function the same way as BC and AD do in our timekeeping system. Each of the eras is summarized before the timeline for that era begins. This history of the Great Continent is a subject of active scholarship.<br />
<br />
The world that Wesnoth resides in is called Irdya. Before the Fall and the (unchronicled) technological age, this name is only rarely used. <br />
<br />
<br />
'''Spoiler warning!'''<br />
This page contains plot spoilers to several campaigns.<br />
<br />
__NOTOC__<br />
[[#Prehistory - 20 YW: The Founding of Wesnoth|The Founding of Wesnoth]]<br />
<br />
[[#20-130 YW: The Taming of the Wild|The Taming of the Wild]]<br />
<br />
[[#200-350 YW: The Golden Age of Wesnoth|The Golden Age of Wesnoth]]<br />
<br />
[[#350-417 YW: The First Dark Age of Wesnoth|The First Dark Age of Wesnoth]]<br />
<br />
[[#417-530 YW: The Turmoil of Asheviere|The Turmoil of Asheviere]]<br />
<br />
[[#530-630 YW: The Age of Fear|The Age of Fear]]<br />
<br />
[[#628-673 YW: The Silver Age of Wesnoth|The Silver Age of Wesnoth]]<br />
<br />
[[#761-816 YW: The Legacy of Black-Eye Karun|The Legacy of Black-Eye Karun]]<br />
<br />
[[#After the Fall|After the Fall]]<br />
<br />
== Prehistory - 20 YW: The Founding of Wesnoth ==<br />
During the age of the Founding of Wesnoth, there were two important geographic locations, these being the Green Isle and the Great Continent. Haldric is the main historical figure at this time. This age ends with the founding of Wesnoth as a country in the Great Continent, and with Orcs attacking both elves and men from the sea.<br />
<br />
=== Prehistory ===<br />
* Elves and Dwarves inhabit the Great Continent.<br />
* Humans inhabit the distant West.<br />
* Haldric's people colonise the Green Isle from a continent further to the west.<br />
<br />
=== 200 BW ===<br />
* The Lich-Lords arrive on the Green Isle after losing a war in the distant West.<br />
* After a long war Haldric's people come to dominate the Green Isle.<br />
* The 'Wesfolk' and their Lich-Lords are pushed onto marginal lands.<br />
<br />
=== 12 BW ===<br />
* The Crown Prince of Southbay discovers the Great Continent.<br />
<br />
=== 11-7 BW ===<br />
* The Crown Prince makes several voyages between the Green Isle and the Great Continent.<br />
<br />
=== 6 BW ===<br />
* Following these voyages to the Great Continent, the elder Crown Prince falls ill and dies.<br />
* His younger brother is implicated in a plot to kill him.<br />
* As a distraction the younger Prince starts a war with the Wesfolk and their Lich-Lords.<br />
* The Lich-Lords sense they will be destroyed and open gates to the homeland of the Orcs in the West.<br />
<br />
=== 5-2 BW ===<br />
* The Green Isle is overrun with Orcs.<br />
* The Wesfolk desert their Lich-Lords as they fear becoming prey for the Orcs.<br />
* Prince Haldric leads the evacuation of the survivors to the Great Continent. '''The Rise of Wesnoth''' begins.<br />
<br />
=== 1 BW ===<br />
* Human settlers, led by Prince Haldric, arrive at the western coast of the Great Continent (the landfall occurs in the future Bay of Pearls) in large numbers.<br />
* Humans arrive in the middle of a simmering dispute between the Elves and Dwarves.<br />
* The Elves and Dwarves are distrustful of humans, and there is a small skirmish.<br />
* Messengers from Wesmere Forest come and ask Haldric to come before the Ka'lian.<br />
* Prince Haldric asks the Four Elvish Lords (Dionli, Logalmier, Aryad, and El'Isomithir) for help and land.<br />
* They set before him four quests to prove his worth, which he completes.<br />
<br />
=== 1 YW ===<br />
* Haldric is granted the plains north and south of the Great River.<br />
* Haldric agrees to a Pact of Mutual Defence with the Elves, but the Ka'lian decides it will betray him and allow humans and orcs to exhaust each other in war if the opportunity presents. Haldric, learning of this, considers the Pact a dead letter.<br />
* The Ruby of Fire is temporarily hidden, and the lich-lord Jevyan is deceived into believing it is held by the Elves. <br />
* Haldric founds the country of Wesnoth in the central plain south of the great River.<br />
* Reign of Haldric I begins. '''The Rise of Wesnoth''' ends.<br />
<br />
=== 2 YW ===<br />
* Orcs, following the ships fleeing from the Green Isle, begin to arrive on the Great Continent.<br />
* These Orcs are defeated by Haldric's forces.<br />
* Some of the Orcish survivors flee back to the Green Isle, others move to attack the Elves.<br />
* King Haldric helps the Elves fight the surviving Orcs.<br />
<br />
=== 8 YW ===<br />
* A second wave of Orcs arrive from the Green Isle; these Orcs begin claiming large portions of the northern Great Continent for themselves.<br />
* Erlornas of Wesmere is involved in the first direct elvish clash with orcs ('''An Orcish Incursion''' takes place in 8-9YW).<br />
* Haldric I publicly repudiates the Pact he spoke with the Elves, refusing to give aid.<br />
<br />
=== 9-11 YW ===<br />
* Many Elves are killed in battle by the Orcs.<br />
* Elvish emissaries are turned away from Wesnoth.<br />
<br />
=== 12 YW ===<br />
* Orcs fail to take the Wesmere Forest and instead march down the coast, devastating human settlements there.<br />
* Elves refuse to aid the Humans in confronting the Orcs.<br />
* Human refugees from the coastal settlements relocate in what will become known as the Great Central Plain. Dan'Tonk, which will become Wesnoth's largest city, is founded.<br />
<br />
=== 20 YW ===<br />
* Haldric I dies.<br />
* Haldric II ascends to the throne.<br />
* Kalenz and Landar escape an orcish invasion of their home in Lintanir Forest. '''The Legend of Wesmere''' begins.<br />
* Humans and elves decisively defeat the orcs at Tath, thus halting the orcish advance.<br />
* A new treaty between humans and elves is signed and King Haldric II allows emissaries of the Elves to return to Wesnoth.<br />
* Elves inform Haldric II of the danger posed by the unshielded Ruby of Fire.<br />
* Kalenz and Landar, later to become successive High Lords of the Elves, are able to sneak into an orcish camp by stealth and assassinate the Great Chief. A long orcish civil war for succession follows. The orcs are unable to undertake action against any other race during this period and Wesnoth enjoys a long period during which it can expand with little opposition.<br />
<br />
== 20-130 YW: The Taming of the Wild ==<br />
This era is that in which the kingdom of Wesnoth expanded and defined its borders, and settled the area which it had claimed for its own. The Taming of the Wild refers to the settling of the unsettled lands, as well as to the colonization of the Northlands. The end of this era is marked by friction between the city-state of Elensefar and the country of Wesnoth, which will continue for the next several hundred years.<br />
<br />
=== 21 YW ===<br />
* Founding of the Great Academy on Alduin.<br />
<br />
* Kalenz is relieved of command by the Ka'lian. He retires to Lintanir Forest with Cleodil. A faction of xenophobic elves begins to gether around Landar.<br />
<br />
=== 25-40 YW ===<br />
* In 25 YW Haldric II sends an expedition to retrieve the Ruby of Fire from its place of concealment.<br />
* Haldric II commissions a Dwarven tribe to build the Scepter of Fire with the Ruby of Fire as its centerpiece; Elves associated with Landar's faction attack during the transfer. '''Scepter of Fire''' begins.<br />
* Action of '''The Scepter of Fire''' takes place. Haldric II is informed that the Scepter was both completed and lost in the year 40. It will not be recovered for nearly 500 years.<br />
* With the death of Thursagan, the Runemaster, all runemasters are killed and runesmithing is lost for several centuries.<br />
<br />
=== 26-50 YW ===<br />
* Landar declares himself High Lord of the Elves, leading to civil war. <br />
<br />
=== 51 YW ===<br />
* Wesnothian New Writing (the script later called "steel-hand", to distinguish it from the more complex "brush-hand" cursive brought from the Green Isle) is promulgated by royal decree. From this date all royal documents and public inscriptions are in New Writing. It spreads rapidly via the mercantile class. The older brush-hand writing continues to be used for magical purposes, scholarship, and in certain elevated literary forms.<br />
<br />
=== 50-93 YW ===<br />
* Elvish civil war (and '''The Legend of Wesmere''') ends. Kalenz declared High Lord, begins reorganizing and militarizing Elvish society to fight the orcs. In late 93 YW he cedes control to a reconstituted Ka'lian and retires again to the Forest of Lintanir.<br />
<br />
=== 121 YW ===<br />
* Orcish civil war sputters to a halt. Raids on elves and humans resume. Period of uncontested human expansion ends, but the Wesnothian Army is more than equal to any of its opponents in battle.<br />
<br />
=== 122 YW ===<br />
* City of Elensefar is sacked by orcs.<br />
* Meneldur, a sailor of Elensefar, sets out on a quest to regain the city.<br />
<br />
=== 123 YW ===<br />
* Elensefar is retaken by Meneldur along with Undead from the Green Isle.<br />
* Elensefar becomes an independent city-state for the first time.<br />
<br />
=== 161-164 YW ===<br />
* The newly crowned king sought to make safe once and for all the wildlands that separated the human cities surrounding Weldyn and the coastal regions of Elensefar.<br />
* The grand army of Wesnoth, personally led by the High Council of Archmagi, destroyed all enemies residing within Wesnoth.<br />
* The city-state of Elensefar is formally united to the kingdom. Settlements from it spread north of the river into the new frontier province of Annuvin, carefully avoiding the margins of Wesmere Forest.<br />
<br />
=== 164-176 YW ===<br />
* During this twelve year span, the western fortress of Halstead was erected in the very heart of the western wilderlands.<br />
<br />
=== 199 YW ===<br />
* Emboldened by the far-reaching arm of Halstead's protection, settlement in the west explodes<br />
* The settlements of Aldril and Carcyn grow to become major cities, the first as an important port due to its position on the Bay of Pearls, and the second as a stop on the road to Elensefar and military outpost along the Great River<br />
* Settlers from Carcyn cross the Great River to establish the first settlements north of it and east of Wesmere.<br />
<br />
== 200-350 YW: The Golden Age of Wesnoth ==<br />
The Golden Age of Wesnoth was the time of the great kings, and of peace and prosperity within the kingdom. The Orcs had suffered a grave defeat at the hands of Wesnoth and Elensefar seventy-five years earlier, so they did not pose much of a threat, and whenever they did attack they were quickly defeated. This allowed the army to lessen in size, and the kings of this age to undertake the great public works they are renowned for. The era ends when the king of Wesnoth dies without an heir, and a new dynasty begins.<br />
<br />
=== 251 YW ===<br />
* Cleodil, wife of Kalenz, dies.<br />
<br />
=== 350 YW ===<br />
* Disintegration of the Kingdom follows the death of Haldric IV.<br />
* Elensefar remains a province of Wesnoth but exerts increasing independence due to isolation.<br />
* Treaty between lord of Elensefar and king of Wesnoth signed.<br />
<br />
== 350-417 YW: The First Dark Age of Wesnoth ==<br />
The first Dark Age was a time of strife and invasion. When Haldric IV died, he left Wesnoth without a king, and the next 70 years were marked by short-lived dynasties, attacks by ever more aggressive orcs, and the further separation of Wesnoth and Elensefar. The Dark Age ended when Garard I took the throne, and began a new dynasty that would last for several hundred years.<br />
<br />
=== 360 YW ===<br />
* Malin Keshar born in Parthyn.<br />
<br />
=== 363 YW ===<br />
* Last of Kalenz's children dies. Kalenz, condemned to outlive his offspring by the potion of Crelanu, leaves the Forest of Lintanir and begins wandering the Great Continent.<br />
<br />
* Village of Maghre terrorized by a minor necromancer. Action of '''A Tale of Two Brothers''' takes place.<br />
<br />
=== 389 YW ===<br />
* Garard, a future king of Wesnoth, is born.<br />
* Malin Keshar returns to Parthyn from the Academy at Alduin. '''Descent Into Darkness''' begins.<br />
<br />
== 417-530 YW: The Turmoil of Asheviere ==<br />
King Garard's dynasty was long-lived and productive, but it was also punctuated by significant turmoil: the end of the first king's reign was marred by orcish and undead raids, and the second was murdered by his own wife and son. It was not until 517 YW that the usurpation of the throne by Queen Mother Asheviere was ended.<br />
<br />
=== 417 YW ===<br />
* Ending years of strife and division, Garard I seizes the throne and becomes king of Wesnoth, beginning the [[Garardine Dynasty]].<br />
<br />
=== 440 YW ===<br />
* Crown Prince Garard II is born.<br />
<br />
=== 442 YW ===<br />
* Delfador, later called "the Great", is born.<br />
<br />
=== 450 YW ===<br />
* Prince Arand is born.<br />
<br />
=== 468 YW ===<br />
* Zorlan becomes Great Chief of the northern orcs<br />
* Delfador graduates from the Great Academy. '''Delfador's Memoirs''' begins.<br />
<br />
=== 470 YW ===<br />
* Garard I dies; Garard II ascends to the throne of Wesnoth<br />
* Orcs under Great Chief Zorlan and undead raised by the necromancer Iliah-Malal raid Wesnoth's borders. All but the first and the last three scenarios of '''Delfador's Memoirs''' take place in this year.<br />
* Control of the Estmarks is effectively lost during this war, not to be regained for decades. Outposts are built on the near side of the Weldyn to repel orc raids. The long watch of the River Guard begins.<br />
<br />
=== 478 YW ===<br />
* Garard II marries Asheviere.<br />
* Garard issues the Edict of the Scepter, providing that the crown shall settle after his death on whichever member of the royal family successfully retrieves it from the Caverns of Flame.<br />
<br />
=== 480 YW ===<br />
* Crown Prince Eldred is born.<br />
<br />
=== 483 YW ===<br />
* Erain and Ethyn, identical twins and brothers of Eldred, are born.<br />
<br />
=== 498 YW ===<br />
* Princess Li'sar is born.<br />
<br />
=== 500 YW ===<br />
* Prince Konrad is born, the youngest of several sons of Prince Arand.<br />
* Wesnoth and the orcs of the north go to war.<br />
<br />
=== 501 YW ===<br />
<br />
===== Betrayal on the battlefield =====<br />
* Garard leads his army to orc encampment at Galcadar by the Ford of Abez.<br />
* Garard's forces split into two groups, one led by himself and the other by his son Eldred.<br />
* Eldred betrays his father and attacks him with the troops under his control.<br />
* Eldred slays King Garard and his uncle Prince Arand on the battlefield of Abez.<br />
<br />
===== Reprisal =====<br />
* Delfador escapes the battle and heads to Weldyn.<br />
* Eldred gives tribute to the Orcish king, who stops his attacks.<br />
* Delfador gathers a force of Loyalists to avenge Garard's Death.<br />
* Eldred's forces confront Delfador's Loyalists at Weldyn.<br />
* The Loyalists are defeated, but Eldred is slain by Delfador in the fight.<br />
<br />
===== Asheviere seizes power =====<br />
* Asheviere orders the slaughter of Garard's nephews and declares herself Queen of Wesnoth.<br />
* Hearing of the news Delfador infiltrates the palace.<br />
* Delfador finds the youngest prince Konrad as he is slain.<br />
* Delfador flees, taking Konrad's body for burial to the land of the Elves.<br />
* While traveling through Wesnoth, Elf Lady Parandra finds an orphaned human child.<br />
* Parandra and Delfador agree to give the orphan the identity of Prince Konrad.<br />
* Delfador and Konrad flee to live in refuge with the Wood Elves of the great southwestern forest.<br />
<br />
===== The country resists Asheviere =====<br />
* Elensefar refuses to submit to Asheviere and declares itself an independent city-state.<br />
* After several defeats, Wesnoth's army retreats from the remote areas of the kingdom. The western Wesnothian border recedes, is fixed, and remains heavily defended.<br />
* As a result of the loyalist withdrawal, several small human communities on the west coast of the Great Continent live in relative independence while elves flourish in the great forest to the southwest of Wesnoth.<br />
* A band of Wesnoth citizens organizes resistance to Asheviere's siezure of power. They are eventually forced to abandon their home and settle in the Three Sisters ('''Liberty''').<br />
<br />
=== 502-517 YW ===<br />
* Delfador raises Konrad under the protection of the Elves.<br />
<br />
=== 517 YW ===<br />
* Asheviere hires Orcish forces to hunt down her nephew-in-law Konrad.<br />
* Orcish forces converge on Delfador's refuge.<br />
* Konrad flees his home with the elves and embark upon a quest to regain the throne of Wesnoth. '''Heir To The Throne''' begins.<br />
<br />
=== 518 YW ===<br />
* Konrad crosses the Great River into the Northlands on a search for the Sceptre of Fire.<br />
* They enter the Caves of Knalga, allied with Princess Li'sar, and find it.<br />
* They return to Wesnoth and claim the throne. '''Heir to the Throne''' ends.<br />
<br />
=== 522 YW ===<br />
* Birth of Princess Ana'sar.<br />
<br />
=== 530 YW ===<br />
* Wesnothian colonists begin reclaiming the Estmarks.<br />
<br />
=== 544 YW ===<br />
* With both sides of the lower Weldyn River again civilized territory, the River Guard posts south of Soradoc are abandoned. Wesnothian military activity shifts eastward into the Estmarks.<br />
<br />
== 530-630 YW: The Age of Fear ==<br />
The Age of Fear takes its names from the events of the end of the era. On the surface, the first 90 years were very uneventful. However, during this time unexplainable magical events took place, especially in the eastern lands. Previously tamed lands were slowly claimed by wilderness as fear and paranoia gradually overshadowed the spirit of pioneering and adventure displayed earlier in Wesnoth's history. In the last 10 years of the age, Wesnoth bore the brunt of the most powerful Undead attack ever and was nearly destroyed. By the end of the era, most of Wesnoth had been made barren, most of the great buildings inside and outside of Weldyn were razed, and the population of Wesnoth was half of what it had been.<br />
<br />
It was in this era that certain areas of the chaotic Northlands were for the first time put into any kind of law and order. A small group of humans and dwarves, accepting anyone of any race who wished to join, formed themselves into the "Northern Alliance”, with the vision of making the Northlands safe to live in. Over time, this alliance grew slowly but steadily in power. By the end of the era, the alliance had succeeded in making a few small areas, including Knalga and the surrounding regions, stable and prosperous. Consequently, many people evacuated from the wasteland that most of Wesnoth had become and moved north - depleting the population of Wesnoth still further.<br />
<br />
=== 533 YW ===<br />
* Delfador succumbs to old age and dies, his body is entombed alongside his staff in Eregonor.<br />
* The next great sage of Wesnoth, Dacyn, is born.<br />
<br />
=== 534 YW ===<br />
<br />
* The small community of Dwarven Doors, in the Northlands just outside Knalga, rebels against the Orcish overlords. '''Northern Rebirth''' begins.<br />
* The residents, led by Tallin, head underground and find dwarves, whom they ally with.<br />
* Their combined forces destroy a lich who is attempting to claim Knalga as his own.<br />
<br />
=== 535 YW ===<br />
<br />
* The warlord-aspirant Rakshas attacks Tallin and his forces, but does not penetrate the dwarves' defences.<br />
* To help defeat the orcs, Tallin secures the help of two Liches, and rescues an elvish princess to secure the help of the elves.<br />
* Assisted by his new allies, Tallin smashes the forces of Rakshas.<br />
* According to some historians, Tallin and the elvish princess are married; others say they parted in bad blood.<br />
* To preserve the new-found peace in the Northlands, Tallin and his allies form the Northern Alliance. '''Northern Rebirth''' ends.<br />
<br />
=== 550 YW ===<br />
<br />
* Lord Hamel of Knalga sends an expedition to Kal Kartha to determine the fate of the Hammer of Thursagan ('''The Hammer of Thursagan''' takes place in late 550 YW to early 551 YW.).<br />
* Dwarves at Knalga and elsewhere begin to reclaim the lost art of runesmithing.<br />
* Wesnothian colonization expands southward past Fort Tahn.<br />
<br />
=== 563 YW ===<br />
* Konrad and Li'sar die after an extraordinarily long reign.<br />
* Princess Ana'sar becomes queen.<br />
* The seer Galdren becomes prominent at the court of Weldyn.<br />
<br />
=== 585 YW ===<br />
* Queen Ana'sar retires.<br />
* Haldric VII becomes king of Wesnoth.<br />
<br />
=== 589 YW ===<br />
* Dacyn the White Mage and Ravanal, an eastern wizard, compete to be the king's advisor.<br />
* The seer Galdren dies after advising Haldric VII to choose Dacyn.<br />
* The king does as Galdren advises.<br />
<br />
=== 593 YW ===<br />
* Ravanal reveals that he has turned to evil, and flees from Weldyn.<br />
* Konrad II is born.<br />
* Certain southern frontier regions are formally annexed to the Kingdom of Wesnoth as the Province of Kerlath.<br />
<br />
=== 598 YW ===<br />
* South Guard organized as a semi-detached formation of the Royal Army, to protect the inhabitants of the frontier province of Kerlath.<br />
<br />
=== 607 YW ===<br />
* South Guard ceases reporting. Haldric VII sends Deoran, son of Haldiel, to investigate. '''The South Guard''' takes place in 607-608 YW. <br />
<br />
=== 612 YW ===<br />
* Haldric VII dies. Konrad II is crowned King of Wesnoth.<br />
* Dacyn continues his duties as advisor with Konrad II.<br />
<br />
=== 625 YW ===<br />
* Mysterious disappearances of livestock and peasants cause partial evacuation of the the '''Estmark Hills'''. Lords of the Horse Plains report increased banditry from there.<br />
* Konrad II sends Dacyn with Owaec and Gweddry to man the old River Guard strongpoints. '''Eastern Invasion''' begins.<br />
<br />
=== 626 YW ===<br />
* Mal-Ravanal attacks the middle outpost where Gweddry and Dacyn are stationed.<br />
* Dacyn and Gweddry travel to the northern outpost, and, with Owaec, retreat into the northlands.<br />
* In the Far North, the merfolk city of Jotha is overrun by undead. The action of '''Dead Water''' takes place.<br />
<br />
=== 627 YW ===<br />
* Wesnoth's last defences are broken and the undead march on Wesnoth<br />
* In the northlands, the orcs drive Gweddry's army back across the river.<br />
* Weldyn is besieged.<br />
* Gweddry breaks through undead lines to reach Weldyn.<br />
* A council is held.<br />
* Gweddry's army is fortunate and kills Mal-Ravanal. '''Eastern Invasion''' ends.<br />
* Wesnoth is saved, but large portions have been laid waste by the undead.<br />
<br />
== 628-673 YW: The Silver Age of Wesnoth ==<br />
<br />
The Silver Age, or restoration of the Wesnothian kingdom, essentially coincides with the rest of the long and successful reign of Konrad II. During this period Wesnoth largely recovered from the damage that Mal-Ravanal's undead attack had done. It would, however, never quite regain the majesty it had at the height of its power.<br />
<br />
The Northlands, aided by a second wave of colonization north from Wesnoth, become more civilised and stable. Although nowhere near as prosperous as Wesnoth was during its Golden Age, the Northlands developed towns of significant size and a thriving - if somewhat dangerous - trade network. <br />
<br />
Four major powers soon came to dominate much of the Northlands. First there were the dwarves, who controlled most of the mountains and a vast array of underground tunnels and caverns. To the east, shrouded in mystery, lay the Elvish forests which continued to be inaccessible to anyone not of elvish blood. The remaining landscape was dominated either by orcish tribes, or independent human earldoms. As competition for the land grew fierce, wars smoldered between human and orcish forces. <br />
<br />
=== 628-635 YW ===<br />
* Konrad II begins his attempt to rebuild Wesnoth.<br />
<br />
=== 673 YW ===<br />
* Konrad II dies, bringing the [[Garardine Dynasty]] to an end. Second Wesnothian civil war begins.<br />
<br />
== 761-816 YW: The Legacy of Black-Eye Karun ==<br />
<br />
After decades of struggle, Black-Eye Karun becomes the first warlord since the assassination of Great Chief Brurbar in 23 YW to unite all the different squabbling orcish tribes under his banner. Among his many accomplishments as a Sovereign, his most famous is the creation of the Great Council. <br />
<br />
Karun was a far-sighted individual and he knew that after his death the orcish tribes would once again turn to fighting among themselves, with little he could do to prevent that and consequent peril from the Wesnothians and elves.<br />
<br />
Consequently, Karun selected from among all the different tribes six of the most sober and wisest orcs and thus created the Great Council. It was the Great Council's job to stay aloof from any tribal or territorial squabbling amongst the orcs, but yet always remain there to give advice to whomever came to seek it. In order to preserve the orcish race in the event of an emergency, he invested in them the power to call up The Great Horde. It was established that every orc, no matter what tribe he came from, must obey the summons of The Great Horde and follow wholeheartedly the leader that the Great Council put at the head of The Great Horde.<br />
<br />
===816 YW===<br />
* Rahul I (Lord Protector of the Northern Alliance) and Black Eye Karun sign a peace treaty ending a 15 year war between the humans and the orcs. Soon after this Karun, is ambushed and killed in mysterious circumstances.<br />
<br />
===842 YW===<br />
* War once again breaks out between the orcish tribes and the northern human earldoms as humans break the long standing treaty and attempt to colonise orcish lands. In response, the Great Council set up by the Black Eye Karun calls upon The Great Horde and bestows leadership of it upon Kapou’e; '''Son of the Black Eye''' begins.<br />
<br />
===843 YW===<br />
* Half of the Great Council is treacherously slain by the allied human forces and orcish unity disintegrates. Faced with the extermination of all the orcs on the Great Continent, Kapou’e forcibly asserts his control over the orcish territories and defeats the enemy forces. The Northern Alliance arrives on the scene in time for the final battle and helps Kapou’e defeat the forces of the northern earldoms, who had broken the treaty. Kapou’e then assumes the position of Sovereign over the northern tribes, and his rule ushers in an unprecedented era of unity and prosperity for the orcs.<br />
<br />
===852 YW===<br />
*Kapou’e repels a large elvish invasion.<br />
<br />
===858 YW===<br />
<br />
*The humans once again stage an invasion but prove to be no match for the united orcish forces under the leadership of Kapou’e. '''Son of the Black Eye''' ends.<br />
<br />
==After the Fall==<br />
At some unknown point in the future, an unspeakable cataclysm scorched the surface of the lands. Forests died, hills turned into rocky wastelands and fields became barren deserts. In the apocalypse allies turned against each other and friends fought over what few resources remained. The great nations were destroyed, and huge numbers of people died. Still amidst the chaos somehow small groups of people survived, sheltered in hidden places. In this post-apocalyptic world survival is a daily struggle as a few remaining tribes eke out an existence among the ruins of fallen empires. Heroic bands of elves, nomadic refugee humans, savage hordes of orcs and dark necromancers all forge new lives under the merciless dual suns, Sela and Naia, of this new Wesnoth.<br />
<br />
===??? Post-Wesnoth===<br />
<br />
* The Quenoth elves adapt to life in barren world of the Great Southern Desert. Over time they lost their affinity for the woodlands of their ancestry and embrace life in the sandy wastelands.<br />
* Under the leadership of Tanuil, the Quenoth elves build and sustain a fortified village around a rare oasis. The village thrives amidst the hostilities of the desert.<br />
* One night, a meteor storm rains from the sky and destroys the village of the Quenoth elves. The next day, Tanuil, like many others, is missing and presumed dead. Kalehssar (Kaleh), nephew of Tanuil, takes leadership of the remaining Quenoth elves as the surviving next of kin.<br />
* Kaleh, heeding the voice of his god Eloh in his dreams, gathers the remaining Quenoth elves and leads them north to a new promised land, foregoing rebuilding of their desert village.<br />
* The Quenoth elves battle their way north through Undead, Orcs, Bandits and other evil, venturing underground beneath a large mountain range at the command of Eloh.<br />
* Befriending unexpected allies underground, Kaleh's forces survive to the other side of the mountain.<br />
* Keratur, son of Tanuil and survivor of the cataclysm, insane with fright attacks Kaleh. Kaleh defeats Keratur.<br />
* Kaleh defies commands given him by a vision of Eloh.<br />
* The Quenoth reach the ocean. Aided by Merfolk, they escape the mainland and head for a newly discovered island, a place where the Quenoth may settle in peace.<br />
* On the island, the Quenoth confront Yechnagoth, the Eater of Souls and impersonator of Eloh. Yechnagoth and army are destroyed by the Quenoth.<br />
* Kaleh and the elves settle on their newfound, and newly named, Quenoth Isle.<br />
<br />
== History Credits ==<br />
<br />
* Timelined by Kamahawk and Turin. Revised to incorporate material from later version of Legend of Wesmere and reconcile different versions of the history of the Scepter of Fire by Eric S. Raymond.<br />
<br />
* History derived from:<br />
** Eastern Invasion<br />
** Heir to the Throne<br />
** Legend of Wesmere<br />
** Liberty<br />
** Northern Rebirth<br />
** The Hammer of Thursagan<br />
** The Rise of Wesnoth<br />
** Under the Burning Suns<br />
** Dead Water<br />
** Delfador's Memoirs<br />
<br />
* Setting details derived from:<br />
** Invasion from the Unknown<br />
<br />
== See Also ==<br />
<br />
* [[Geography of Wesnoth]]<br />
* [[Poetry of Wesnoth]]<br />
* [[Races]]<br />
* [[FactionHistory]]<br />
<br />
[[Category:World of Wesnoth]]<br />
[[Category:History]]</div>Fabihttps://wiki.wesnoth.org/index.php?title=SingleUnitWML&diff=42825SingleUnitWML2011-05-29T16:43:01Z<p>Fabi: /* How to describe a single unit */</p>
<hr />
<div>{{WML Tags}}<br />
== How to describe a single unit ==<br />
<br />
This tag, '''[unit]''', describes a single unit on the map, for example Konrad.<br />
It is different from the [unit_type] in [units], which describes a class of units. However it takes many of the same keys and thus can generally override the inherited properties from the associated [unit_type].<br />
<br />
[unit] can be used inside [side] ([[SideWML]]) for units present at start of the scenario, or as [[DirectActionsWML]] for units created during the game. (It is also used in save-files.)<br />
<br />
The following keys are recognized:<br />
* '''type''': the ID of the unit's unit type. See [[UnitTypeWML]].<br />
<br />
* '''side''': the side that the unit is on. It has to be an existing side, even if the unit is created in a variable.<br />
<br />
* '''gender''': can be set to male or female to designate the gender of the unit. Default is male, but if the unit has only a female variant it will be female.<br />
<br />
* '''x''', '''y''': the location of the unit. By default ( see '''placement''') if a location isn't provided and the side the unit will belong to has a recall list, the unit will be created on the recall list.<br />
<br />
* '''placement''': How the unit should be placed: can be one value or a comma-separated list of values. Default value is 'map,leader' for a leader given directly in [side], "" otherwise. By default, 'map,recall' is implicitly appended to the end of the list.<br />
** '''map''': If x,y are explicitly given and point to a valid on-map location - try to place the unit at the nearest free location to there, never overwriting existing units. Successful if x,y are given and a valid on-map vacant location near it can be found.<br />
** '''leader''': Try to place unit near the leader, if leader is not present or is in recall list - try to place unit near the start location for this side. Successful if a valid on-map vacant location can be found near leader or near start location.<br />
** '''recall''': Place unit on recall list. Always successful. <br />
** '''map_overwrite''': If x,y are explicitly given and point to a valid on-map location - try to place unit at this location, if there was a unit there - overwriting it, without firing events. <br />
<br />
* '''to_variable''': creates the unit into the given variable instead of placing it on the map.<br />
<br />
* '''id''': a unique identifier for the unit. This is not displayed to the player, but is to be used only for identifying and filtering for units. If not specified or when a unit is normally recruited, a random one will be generated for the unit to ensure that each unit has a unique ''id'' attribute. In older versions, the '''description''' attribute specified a unique ID.<br />
<br />
* '''name''': the user-visible name of the unit. Note that the player may use the "rename unit" action to change this.<br />
<br />
* '''generate_name''': (default=yes) will generate a new name if there isn't one specifed for the unit, as if the unit were a freshly-recruited one<br />
<br />
* '''unrenamable''': if 'yes', the user-visible name of the unit cannot be changed by the player (which is only possible when the unit is on the player's side anyway).<br />
<br />
* '''traits_description''': the description of the unit's traits which is displayed. However if it is not specified explicitly, the unit's actual traits' names will be used instead, so it is normally not necessary to set this.<br />
<br />
* '''random_traits''': "no" will prevent random trait generation for units. You should only need to set this for placed nonleaders in multiplayer games or if you want to give a unit less traits than it would normally get for its unit type. When generating traits for a unit, first traits the unit has already been given are excluded. Then "musthave" traits (undead, mechanical) for the unit type are given. Then for leaders ('''canrecruit=yes''') traits that are not available to "any" (currently that's all of them to avoid a multiplayer OOS issue, but later will be restricted based on multiplayer play balance issues) are removed from consideration. Then traits are added randomly until the maximum allowed for the unit type is reached or there are no more available traits. Random traits can now be used in MP games but only when spawned in an event, so not for leaders and other units in the [side] definition.<br />
<br />
* '''random_gender''': "yes" will cause the gender of the unit with male and female variations to be male 50% of the time, female 50% of the time. If the unit has only one gender variant it will always be given the correct one.<br />
<br />
* '''canrecruit''': a special key for leaders.<br />
** '''no''': default. Unit cannot recruit.<br />
** '''yes''': unit can recruit.<br />
: Normally when a team controls no units with '''canrecruit=yes''', that team loses. However, even if your team has lost you continue to play with whatever units you still have until the scenario is over. Usually scenarios end when only one team is left with a leader that can recruit, but special victory conditions can be set up in campaigns. Normally you want to set the leader of a side with '''canrecruit=yes'''. If you don't want the leader to recruit, it is usually better to just not give him any unit types to recruit, than to make a special victory condition. Units with '''canrecruit=yes''' are exempt from upkeep costs. So that leaders do not need to be given the ''loyal'' trait.<br />
: More than one unit with '''canrecruit=yes''' for the same side (see [[SideWML]]) are allowed in single player, if the side is human-controlled.<br />
<br />
* '''extra_recruit''': a list of unit types. The units recruit list, only working for units with '''canrecruit=yes'''. {{DevFeature1.9}}<br />
<br />
* '''variation''': the variation of itself the unit should be created as.<br />
<br />
* '''upkeep''': the amount of upkeep the unit costs.<br />
** '''loyal''' no upkeep cost. Can be changed by the effect 'loyal' (see [[EffectWML]])<br />
** '''full''': unit costs ''level'' upkeep (see [[UnitTypeWML]]).<br />
** An integer can be used to set the upkeep cost to that number.<br />
** The default is "full".<br />
** Leaders (units with '''canrecruit=yes''') never pay upkeep no matter what upkeep is set to.<br />
** Normally you don't want to muck with this value. If you want to give a side units without upkeep costs, give those units the 'loyal' trait.<br />
<br />
* '''overlays''': a list of images that are overlayed on the unit.<br />
<br />
* '''goto_x''':, '''goto_y''': UI settings that control courses. Default is 0,0 i.e. the unit is not on a course.<br />
<br />
* '''hitpoints''': the HP of the unit. Default is the max HP for ''type''.<br />
<br />
* '''experience''': the XP of the unit. Default is 0.<br />
<br />
* '''moves''': number of movement points the unit has left. Default is the movement for its unit type.<br />
<br />
* '''resting''': whether the unit has not moved yet this turn. Used to decide whether to give a unit rest healing.<br />
<br />
* '''role''': used in standard unit filter ([[FilterWML]]). Can be set using [role] (see [[InternalActionsWML]]).<br />
<br />
* '''ai_special''': causes the unit to act differently.<br />
** "guardian" the unit will not move, except to attack something in the turn it moves (so, it only can move if an enemy unit gets within range of it).<br />
<br />
* '''facing''': which way the unit is facing (this only affects how the unit is displayed).<br />
** Possible values are '''se''', '''s''', '''sw''', '''nw''', '''n''', '''ne'''. Using '''sw''' is preferred for a "reversed" facing (looking to the left) and '''se''' for a normal (looking to the right) facing.<br />
<br />
* '''profile''': sets a portrait image for this unit. If the unit type already has a portrait set, this is used instead for this unit. When the unit advances, if the value of profile is different from the unit-type portrait, that value is preserved. If the profile field is empty or the same as the unit-type portrait, the level-advance changes the unit portrait to the default for the new level and type. See [[UnitTypeWML]] for the rules used for locating files.<br />
** "unit_image" if given instead of a filename, uses the unit's base image as the portrait (in the same manner that unit types without portraits do by default).<br />
<br />
* '''small_profile''': {{DevFeature1.9}} sets a small portrait image for this unit. See the '''profile''' attribute above for advancement and special values. As with [[UnitTypeWML]], the location heuristic of the '''profile''' attribute is disabled when the '''small_profile''' attribute is provided.<br />
<br />
* '''animate''': if ''yes'', fades the unit in like when it's recruited/recalled.<br />
<br />
* '''[status]''' the status of the unit. This affects different features of the unit, for example whether the unit loses health each turn. Default for all keys is 'off', but this can be changed by the scenario or by special abilities (see [[AbilitiesWML]]). The status of a unit is displayed on the Status Table; each status modification ''statusmod'' is represented by the image '''misc/statusmod.png'''.<br />
** '''poisoned''': if 'yes', the unit loses 8 HP each turn. See also ''heals'', ''cures'', [[AbilitiesWML]].<br />
** '''slowed''': if 'yes', the unit has 50% of its normal movement and does half damage. When the controller of the unit's turn is over, ''slowed'' is set to 'off' <br />
** '''petrified''': if 'yes', the unit cannot move, attack, or be attacked.<br />
** '''uncovered''': if 'yes', the unit has performed an action (e.g. attacking) that causes it to no longer be hidden until the next turn.<br />
** '''guardian''': this is set to 'yes' by ai_special=guardian and clearing it will allow the unit to act normally again.<br />
** '''healable''': if set to 'no', the unit cannot be healed. {{DevFeature1.9}} ''healable'' is deprecated, use ''unhealable'' instead.<br />
** '''unhealable''': {{DevFeature1.9}} if set to 'yes', the unit cannot be healed.<br />
<br />
* '''[variables]''' a set of variables that will be stored when this unit is stored (See [store_unit], [[InternalActionsWML]]). The attribute '''variable'''='''value''' means that when the unit is stored in the array ''unit'', the variable '''unit'''.variables.''variable'' will have the value ''value'' (See [[VariablesWML]]).<br />
<br />
* '''[modifications]''' changes that have been made to the unit.<br />
** '''[trait]''' a trait the unit has. Same format as [trait], [[UnitsWML]].<br />
** '''[object]''' an object the unit has. Same format as [object], [[DirectActionsWML]].<br />
<br />
* '''[filter_recruit]''' A leader can only recruit those units which pass the SUF. Note that the '''this_unit''' variable is '''not valid''' in this context. {{DevFeature1.9}}<br />
<br />
* '''unit_description''': overrides the unit type description for this unit. You will probably want to set up a ''post_advance'' [[EventWML|event]] to override the default description after promotions. Or better, use an object with a profile [[EffectWML|effect(s)]] to filter on unit type and change the unit description and/or portrait.<br />
<br />
* '''[event]''' The event is copied from the contents of the created unit to the scenario. Everything valid in [scenario][event]s is valid in [unit][event]s. warning: Contrarily to [unit_type][event]s, a [unit] tag performs variable substitution before creating the unit. This can be worked around by using $|variable_name syntax. note: [unit][event] does currently (1.8.3, 1.9.0-svn) not work.<br />
<br />
== See Also ==<br />
<br />
* [[UnitTypeWML]]<br />
* [[ReferenceWML]]<br />
<br />
[[Category:WML Reference]]</div>Fabihttps://wiki.wesnoth.org/index.php?title=Template:WML_Tags&diff=42665Template:WML Tags2011-05-14T10:04:49Z<p>Fabi: </p>
<hr />
<div>{| class="gallery" style="width:225px;float: right;border: 1px solid #B48648; color:#B48648; font-size: 7pt;margin-left;10px;"<br />
|-<br />
|<br />
<span style="float: right;"><small class="editlink noprint plainlinksneverexpand">[{{SERVER}}{{localurl:Template:WML Tags|action=edit}} edit ]</small></span><br />
'''WML Tags'''<br />
<br />
|-<br />
|''A:'' <br />
[[AbilitiesWML|abilities]],<br />
[[CampaignWML|about]],<br />
[[AdvancedPreferenceWML|advanced_preference]],<br />
[[UnitTypeWML|advancefrom]],<br />
[[UnitTypeWML|advancement]],<br />
[[StatisticalScenarioWML#The_.5Bteam.5D_tag|advances]],<br />
[[AiWML#the_.5Bai.5D_tag|ai]],<br />
[[DirectActionsWML#.5Ballow_recruit.5D|allow_recruit]],<br />
[[DirectActionsWML#.5Ballow_extra_recruit.5D|allow_extra_recruit]],<br />
[[DirectActionsWML#.5Ballow_undo.5D|allow_undo]],<br />
[[ConditionalActionsWML#Meta_Condition_Tags|and]],<br />
[[InterfaceActionsWML#.5Banimate_unit.5D|animate_unit]],<br />
[[AnimationWML|animation]],<br />
[[VariablesWML#Array|array]],<br />
[[UnitTypeWML#Attacks|attack]],<br />
[[AnimationWML|attack_filter]], <br />
[[StatisticalScenarioWML#The_.5Bteam.5D_tag|attacks]],<br />
[[AiWML#the_.5Bai.5D_tag|avoid]];<br />
|-<br />
|''B:'' <br />
[[UnitTypeWML#Other_tags|base_unit]], [[BinaryPathWML|binary_path]], [[HelpWML#Help_System_Topic_Markup|bold]], [[EditorWML#The_.5Bbrush.5D_tag|brush]];<br />
|-<br />
|''C:'' <br />
[[CampaignWML#The_.5Bcampaign.5D_tag|campaign]],<br />
[[DirectActionsWML#.5Bcapture_village.5D|capture_village]],<br />
[[ConditionalActionsWML#.5Bswitch.5D|case]],<br />
[[InterfaceActionsWML#.5Bchat.5D|chat]],<br />
[[ReplayWML|choose]],<br />
[[PersistenceWML|clear_global_variable]],<br />
[[InternalActionsWML|clear_variable]],<br />
[[InterfaceActionsWML#.5Bcolour_adjust.5D|colour_adjust]],<br />
command([[InterfaceActionsWML|action]], [[ReplayWML|replay]]);<br />
|-<br />
|''D:'' <br />
[[AbilitiesWML|damage]],<br />
[[StatisticalScenarioWML|deaths]],<br />
[[AnimationWML|defend]],<br />
[[StatisticalScenarioWML|defends]],<br />
[[UnitTypeWML|defense]],<br />
[[InterfaceActionsWML#.5Bdelay.5D|delay]],<br />
[[InterfaceActionsWML#.5Bdeprecated_message.5D|deprecated_message]],<br />
[[ReplayWML|destination]],<br />
[[DirectActionsWML#.5Bdisallow_recruit.5D|disallow_recruit]],<br />
[[DirectActionsWML#.5Bdisallow_extra_recruit.5D|disallow_extra_recruit]],<br />
[[ConditionalActionsWML#.5Bwhile.5D|do]];<br />
|-<br />
|''E:'' <br />
[[EditorWML|editor_group]],<br />
[[EditorWML|editor_music]], <br />
[[EditorWML|editor_times]],<br />
[[EditorWML|editor_tool_hint]],<br />
[[EffectWML|effect]],<br />
else ([[ConditionalActionsWML#.5Bif.5D|action]], [[AnimationWML#.5Bif.5D_and_.5Belse.5D|animation]]),<br />
[[DirectActionsWML#.5Bendlevel.5D|endlevel]],<br />
end_turn&nbsp;([[DirectActionsWML#.5Bend_turn.5D|action]], [[ReplayWML|replay]]),<br />
[[EraWML|era]],<br />
[[EventWML|event]],<br />
[[ThemeWML|expenses]];<br />
|-<br />
|''F:'' <br />
[[EventWML#.5Bfilter.5D|filter]],<br />
[[FilterWML|filter]],<br />
[[AnimationWML|filter_attack]],<br />
[[EventWML#.5Bfilter_attack.5D|filter_attack]],<br />
[[EventWML#.5Bfilter_condition.5D|filter_condition]],<br />
[[FilterWML|filter_location]],<br />
[[EventWML#.5Bfilter_second.5D|filter_second]],<br />
[[FilterWML|filter_second]],<br />
[[AnimationWML|filter_second_attack]],<br />
[[EventWML#.5Bfilter_second_attack.5D|filter_second_attack]],<br />
[[FilterWML#Filtering_Vision|filter_vision]],<br />
[[StandardUnitFilter|filter_wml]],<br />
[[InternalActionsWML|fire_event]],<br />
[[InterfaceActionsWML#.5Bfloataing_text.5D|floating_text]],<br />
[[HelpWML|format]],<br />
[[AnimationWML|frame]];<br />
|-<br />
|''G:'' <br />
[[GameConfigWML|game_config]],<br />
[[ScenarioWML|generator]],<br />
[[PersistenceWML|get_global_variable]],<br />
gold([[DirectActionsWML#.5Bgold.5D|action]], [[ThemeWML|theme]]);<br />
|-<br />
|''H:'' <br />
[[DirectActionsWML#.5Bharm_unit.5D|harm_unit]],<br />
[[ConditionalActionsWML#Condition_Tags|have_location]],<br />
[[ConditionalActionsWML#Condition_Tags|have_unit]],<br />
[[HelpWML|header]],<br />
[[DirectActionsWML#.5Bheal_unit.5D|heal_unit]],<br />
[[UnitsWML|hide_help]],<br />
[[InterfaceActionsWML#.5Bhide_unit.5D|hide_unit]];<br />
|-<br />
|''I:'' <br />
if ([[ConditionalActionsWML#.5Bif.5D|action]], [[AnimationWML#.5Bif.5D_and_.5Belse.5D|animation]]),<br />
[[TimeWML|illuminated_time]],<br />
[[TerrainGraphicsWML|image]],<br />
[[HelpWML|img]],<br />
[[ThemeWML|income]],<br />
[[ReplayWML|init_side]],<br />
[[InternalActionsWML|insert_tag]],<br />
[[InterfaceActionsWML#.5Binspect.5D|inspect]],<br />
[[HelpWML|italic]],<br />
[[InterfaceActionsWML#.5Bitem.5D|item]];<br />
|-<br />
|''J:''<br />
[[HelpWML|jump]],<br />
[[InternalActionsWML|join]];<br />
|-<br />
|''K:'' <br />
[[DirectActionsWML#.5Bkill.5D|kill]],<br />
[[StatisticalScenarioWML|killed]];<br />
|-<br />
|''L:'' <br />
label&nbsp;([[InterfaceActionsWML#.5Blabel.5D|map]], [[ThemeWML|theme]]),<br />
[[LanguageWML|language]],<br />
[[AiWML|leader_goal]],<br />
[[LocaleWML|locale]],<br />
[[LuaWML|lua]];<br />
|-<br />
|''M:'' <br />
[[ThemeWML|main_map]],<br />
[[ThemeWML|menu]],<br />
[[InterfaceActionsWML#.5Bmessage.5D|message]],<br />
[[ThemeWML|mini_map]],<br />
[[AnimationWML|missile_frame]],<br />
[[SingleUnitWML|modifications]],<br />
[[DirectActionsWML#.5Bmodify_side.5D|modify_side]],<br />
[[DirectActionsWML#.5Bmodify_turns.5D|modify_turns]],<br />
[[ReplayWML|move]],<br />
[[DirectActionsWML#.5Bmove_unit.5D|move_unit]],<br />
[[DirectActionsWML#.5Bmodify_ai.5D|modify_ai]],<br />
[[DirectActionsWML#.5Bmodify_unit.5D|modify_unit]],<br />
[[InterfaceActionsWML#.5Bmove_unit_fake.5D|move_unit_fake]],<br />
[[InterfaceActionsWML#.5Bmove_units_fake.5D|move_units_fake]],<br />
[[UnitTypeWML|movement costs]],<br />
[[UnitsWML|movetype]],<br />
[[ScenarioWML|multiplayer]],<br />
[[EraWML|multiplayer_side]],<br />
[[MusicListWML#.5Bmusic.5D|music]];<br />
|-<br />
|''N:'' <br />
[[ConditionalActionsWML#Meta_Condition_Tags|not]],<br />
[[FilterWML|not]],<br />
[[ThemeWML|num_units]];<br />
|-<br />
|''O:'' <br />
[[DirectActionsWML#.5Bobject.5D|object]],<br />
[[InterfaceActionsWML#.5Bobjectives.5D|objectives]],<br />
[[InterfaceActionsWML#.5Bobjectives.5D|objective]],<br />
[[ThemeWML|observers]],<br />
[[InterfaceActionsWML#.5Bopen_help.5D|open_help]],<br />
[[InterfaceActionsWML|option]],<br />
[[ConditionalActionsWML#Meta_Condition_Tags|or]];<br />
|-<br />
|''P:'' <br />
[[ThemeWML|panel]], [[IntroWML|part]], [[DirectActionsWML#.5Bpetrify.5D|petrify]], [[DirectActionsWML#.5Bplace_shroud.5D|place_shroud]], [[ThemeWML|position]],<br />
[[InterfaceActionsWML#.5Bprint.5D|print]], [[AiWML|protect_location]], [[AiWML|protect_unit]];<br />
|-<br />
|''R:'' <br />
[[UnitsWML|race]], [[ReplayWML|random]], recall&nbsp;([[DirectActionsWML#.5Brecall.5D|action]], <br />
[[ReplayWML|replay]]), [[StatisticalScenarioWML|recalls]],<br />
[[ReplayWML|recruit]], [[StatisticalScenarioWML|recruits]], [[InterfaceActionsWML#.5Bredraw.5D|redraw]],<br />
[[HelpWML|ref]], [[DirectActionsWML|remove_shroud]], [[InterfaceActionsWML#.5Bremove_unit_overlay.5D|remove_unit_overlay]],<br />
[[InterfaceActionsWML#.5Bremoveitem.5D|removeitem]], [[InterfaceActionsWML#.5Bremove_sound_source.5D|remove_sound_source]], <br />
[[DirectActionsWML#.5Breplace_map.5D|replace_map]], [[DirectActionsWML#.5Breplace_schedule.5D|replace_schedule]], [[SavefileWML|replay]], [[SavefileWML|replay_start]],<br />
[[UnitTypeWML|resistance]], [[ThemeWML|resolution]], [[ReplayWML|results]], [[InternalActionsWML|role]];<br />
|-<br />
|''S:'' <br />
[[SavefileWML|save]], [[ScenarioWML|scenario]],<br />
[[InterfaceActionsWML#.5Bscroll.5D|scroll]], [[InterfaceActionsWML#.5Bscroll_to.5D|scroll_to]],<br />
[[InterfaceActionsWML#.5Bscroll_to_unit.5D|scroll_to_unit]], [[AnimationWML|secondary_attack_filter]], [[AnimationWML|secondary_unit_filter]], [[HelpWML|section]], [[InterfaceActionsWML#.5Bselect_unit.5D|select_unit]], [[PersistenceWML|set_global_variable]],<br />
[[InterfaceActionsWML#.5Bset_menu_item.5D|set_menu_item]], [[DirectActionsWML#.5Bset_recruit.5D|set_recruit]],<br />
[[DirectActionsWML#.5Bset_extra_recruit.5D|set_extra_recruit]],<br />
[[InternalActionsWML|set_variable]], [[InternalActionsWML|set_variables]], [[InterfaceActionsWML#.5Bshow_objectives.5D|show_objectives]],<br />
[[SideWML|side]], [[ThemeWML|side_playing]], [[SavefileWML|snapshot]],<br />
[[InterfaceActionsWML#.5Bsound.5D|sound]], [[InterfaceActionsWML#.5Bsound_source.5D|sound_source]], [[ReplayWML|source]], [[EventWML|special_filter]], [[EventWML|special_filter_second]],<br />
[[InternalActionsWML|split]],<br />
[[StatisticalScenarioWML#The_.5Bstatistics.5D_tag|statistics]],<br />
status([[SingleUnitWML|single unit]], [[ThemeWML|theme]]), [[InternalActionsWML#.5Bstore_gold.5D|store_gold]], [[InternalActionsWML#.5Bstore_locations.5D|store_locations]],<br />
[[InternalActionsWML#.5Bstore_map_dimensions.5D|store_map_dimensions]],<br />
[[InternalActionsWML#.5Bstore_side.5D|store_side]], [[InternalActionsWML#.5Bstore_starting_location.5D|store_starting_location]], [[InternalActionsWML#.5Bstore_time_of_day.5D|store_time_of_day]], [[InternalActionsWML#.5Bstore_unit.5D|store_unit]], [[InternalActionsWML#.5Bstore_villages.5D|store_villages]],[[IntroWML|story]],<br />
[[ConditionalActionsWML#.5Bswitch.5D|switch]];<br />
|-<br />
|''T:'' <br />
[[AiWML|target]],<br />
[[StatisticalScenarioWML#The_.5Bteam.5D_tag|team]],<br />
teleport ([[DirectActionsWML#.5Bteleport.5D|action]], [[AbilitiesWML|ability]]), [[AnimationWML|teleport_anim]],<br />
[[DirectActionsWML#.5Bterrain.5D|terrain]], [[TerrainGraphicsWML|terrain_graphics]], [[TerrainMaskWML|terrain_mask]], [[TerrainWML|terrain_type]], [[ScenarioWML#Test_scenario|test]],<br />
[[WesCamp|textdomain]], [[InterfaceActionsWML|text_input]], [[ThemeWML|theme]], [[ConditionalActionsWML#.5Bif.5D|then]],<br />
[[TerrainGraphicsWML|tile]], [[TimeWML|time]], time_area&nbsp;([[DirectActionsWML#.5Btime_area.5D|action]], [[ScenarioWML|scenario]]), <br />
[[ThemeWML|time_of_day]],<br />
[[HelpWML|topic]], [[HelpWML|toplevel]], [[SingleUnitWML|trait]], [[DirectActionsWML#.5Btransform_unit.5D|transform_unit]], [[DirectActionsWML#.5Btunnel.5D|tunnel]], [[ThemeWML|turn]], [[ScenarioWML|tutorial]];<br />
|-<br />
|''U:'' <br />
[[InterfaceActionsWML#.5Bunhide_unit.5D|unhide_unit]], [[SingleUnitWML|unit]],<br />
[[ThemeWML|unit_abilities]], [[ThemeWML|unit_alignment]], [[ThemeWML|unit_description]], [[AnimationWML|unit_filter]], [[ThemeWML|unit_hp]], [[ThemeWML|unit_image]], [[ThemeWML|unit_level]], [[ThemeWML|unit_moves]],<br />
[[InterfaceActionsWML#.5Bunit_overlay.5D|unit_overlay]], [[ThemeWML|unit_profile]], [[ThemeWML|unit_status]],<br />
[[ThemeWML|unit_traits]], [[UnitTypeWML|unit_type]], [[ThemeWML|unit_weapons]], [[ThemeWML|unit_xp]],<br />
[[UnitsWML|units]], [[DirectActionsWML#.5Bunpetrify.5D|unpetrify]], [[DirectActionsWML#.5Bunstore_unit.5D|unstore_unit]], [[ThemeWML|upkeep]];<br />
|-<br />
| ''V:'' <br />
[[ConditionalActionsWML#Condition_Tags|variable]],<br />
[[VariablesWML|variables]],<br />
[[SideWML|village]],<br />
[[ThemeWML|villages]],<br />
[[InterfaceActionsWML#.5Bvolume.5D|volume]];<br />
|-<br />
| ''W:'' <br />
[[ConditionalActionsWML#.5Bwhile.5D|while]],<br />
[[InterfaceActionsWML#.5Bwml_message.5D|wml_message]];<br />
|}<br />
<br />
<includeonly>[[Category:WML Reference]]</includeonly><br />
<br />
<noinclude>An box with all the WML tags, each linking to the page they are described in. This box should be included in each of the WML reference pages.</noinclude></div>Fabihttps://wiki.wesnoth.org/index.php?title=SingleUnitWML&diff=42664SingleUnitWML2011-05-14T09:59:16Z<p>Fabi: /* How to describe a single unit */</p>
<hr />
<div>{{WML Tags}}<br />
== How to describe a single unit ==<br />
<br />
This tag, '''[unit]''', describes a single unit on the map, for example Konrad.<br />
It is different from the [unit_type] in [units], which describes a class of units. However it takes many of the same keys and thus can generally override the inherited properties from the associated [unit_type].<br />
<br />
[unit] can be used inside [side] ([[SideWML]]) for units present at start of the scenario, or as [[DirectActionsWML]] for units created during the game. (It is also used in save-files.)<br />
<br />
The following keys are recognized:<br />
* '''type''': the ID of the unit's unit type. See [[UnitTypeWML]].<br />
<br />
* '''side''': the side that the unit is on. It has to be an existing side, even if the unit is created in a variable.<br />
<br />
* '''gender''': can be set to male or female to designate the gender of the unit. Default is male, but if the unit has only a female variant it will be female.<br />
<br />
* '''x''', '''y''': the location of the unit. By default ( see '''placement''') if a location isn't provided and the side the unit will belong to has a recall list, the unit will be created on the recall list.<br />
<br />
* '''placement''': How the unit should be placed: can be one value or a comma-separated list of values. Default value is 'map,leader' for a leader given directly in [side], "" otherwise. By default, 'map,recall' is implicitly appended to the end of the list.<br />
** '''map''': If x,y are explicitly given and point to a valid on-map location - try to place the unit at the nearest free location to there, never overwriting existing units. Successful if x,y are given and a valid on-map vacant location near it can be found.<br />
** '''leader''': Try to place unit near the leader, if leader is not present or is in recall list - try to place unit near the start location for this side. Successful if a valid on-map vacant location can be found near leader or near start location.<br />
** '''recall''': Place unit on recall list. Always successful. <br />
** '''map_overwrite''': If x,y are explicitly given and point to a valid on-map location - try to place unit at this location, if there was a unit there - overwriting it, without firing events. <br />
<br />
* '''to_variable''': creates the unit into the given variable instead of placing it on the map.<br />
<br />
* '''id''': a unique identifier for the unit. This is not displayed to the player, but is to be used only for identifying and filtering for units. If not specified or when a unit is normally recruited, a random one will be generated for the unit to ensure that each unit has a unique ''id'' attribute. In older versions, the '''description''' attribute specified a unique ID.<br />
<br />
* '''name''': the user-visible name of the unit. Note that the player may use the "rename unit" action to change this.<br />
<br />
* '''generate_name''': (default=yes) will generate a new name if there isn't one specifed for the unit, as if the unit were a freshly-recruited one<br />
<br />
* '''unrenamable''': if 'yes', the user-visible name of the unit cannot be changed by the player (which is only possible when the unit is on the player's side anyway).<br />
<br />
* '''traits_description''': the description of the unit's traits which is displayed. However if it is not specified explicitly, the unit's actual traits' names will be used instead, so it is normally not necessary to set this.<br />
<br />
* '''random_traits''': "no" will prevent random trait generation for units. You should only need to set this for placed nonleaders in multiplayer games or if you want to give a unit less traits than it would normally get for its unit type. When generating traits for a unit, first traits the unit has already been given are excluded. Then "musthave" traits (undead, mechanical) for the unit type are given. Then for leaders ('''canrecruit=yes''') traits that are not available to "any" (currently that's all of them to avoid a multiplayer OOS issue, but later will be restricted based on multiplayer play balance issues) are removed from consideration. Then traits are added randomly until the maximum allowed for the unit type is reached or there are no more available traits. Random traits can now be used in MP games but only when spawned in an event, so not for leaders and other units in the [side] definition.<br />
<br />
* '''random_gender''': "yes" will cause the gender of the unit with male and female variations to be male 50% of the time, female 50% of the time. If the unit has only one gender variant it will always be given the correct one.<br />
<br />
* '''canrecruit''': a special key for leaders.<br />
** '''no''': default. Unit cannot recruit.<br />
** '''yes''': unit can recruit.<br />
: Normally when a team controls no units with '''canrecruit=yes''', that team loses. However, even if your team has lost you continue to play with whatever units you still have until the scenario is over. Usually scenarios end when only one team is left with a leader that can recruit, but special victory conditions can be set up in campaigns. Normally you want to set the leader of a side with '''canrecruit=yes'''. If you don't want the leader to recruit, it is usually better to just not give him any unit types to recruit, than to make a special victory condition. Units with '''canrecruit=yes''' are exempt from upkeep costs. So that leaders do not need to be given the ''loyal'' trait.<br />
: More than one unit with '''canrecruit=yes''' for the same side (see [[SideWML]]) are allowed in single player, if the side is human-controlled.<br />
<br />
* '''extra_recruit''': a list of unit types. The units recruit list, only working for units with '''canrecruit=yes'''. {{DevFeature1.9}}<br />
<br />
* '''variation''': the variation of itself the unit should be created as.<br />
<br />
* '''upkeep''': the amount of upkeep the unit costs.<br />
** '''loyal''' no upkeep cost. Can be changed by the effect 'loyal' (see [[EffectWML]])<br />
** '''full''': unit costs ''level'' upkeep (see [[UnitTypeWML]]).<br />
** An integer can be used to set the upkeep cost to that number.<br />
** The default is "full".<br />
** Leaders (units with '''canrecruit=yes''') never pay upkeep no matter what upkeep is set to.<br />
** Normally you don't want to muck with this value. If you want to give a side units without upkeep costs, give those units the 'loyal' trait.<br />
<br />
* '''overlays''': a list of images that are overlayed on the unit.<br />
<br />
* '''goto_x''':, '''goto_y''': UI settings that control courses. Default is 0,0 i.e. the unit is not on a course.<br />
<br />
* '''hitpoints''': the HP of the unit. Default is the max HP for ''type''.<br />
<br />
* '''experience''': the XP of the unit. Default is 0.<br />
<br />
* '''moves''': number of movement points the unit has left. Default is the movement for its unit type.<br />
<br />
* '''resting''': whether the unit has not moved yet this turn. Used to decide whether to give a unit rest healing.<br />
<br />
* '''role''': used in standard unit filter ([[FilterWML]]). Can be set using [role] (see [[InternalActionsWML]]).<br />
<br />
* '''ai_special''': causes the unit to act differently.<br />
** "guardian" the unit will not move, except to attack something in the turn it moves (so, it only can move if an enemy unit gets within range of it).<br />
<br />
* '''facing''': which way the unit is facing (this only affects how the unit is displayed).<br />
** Possible values are '''se''', '''s''', '''sw''', '''nw''', '''n''', '''ne'''. Using '''sw''' is preferred for a "reversed" facing (looking to the left) and '''se''' for a normal (looking to the right) facing.<br />
<br />
* '''profile''': sets a portrait image for this unit. If the unit type already has a portrait set, this is used instead for this unit. When the unit advances, if the value of profile is different from the unit-type portrait, that value is preserved. If the profile field is empty or the same as the unit-type portrait, the level-advance changes the unit portrait to the default for the new level and type. See [[UnitTypeWML]] for the rules used for locating files.<br />
** "unit_image" if given instead of a filename, uses the unit's base image as the portrait (in the same manner that unit types without portraits do by default).<br />
<br />
* '''small_profile''': {{DevFeature1.9}} sets a small portrait image for this unit. See the '''profile''' attribute above for advancement and special values. As with [[UnitTypeWML]], the location heuristic of the '''profile''' attribute is disabled when the '''small_profile''' attribute is provided.<br />
<br />
* '''animate''': if ''yes'', fades the unit in like when it's recruited/recalled.<br />
<br />
* '''[status]''' the status of the unit. This affects different features of the unit, for example whether the unit loses health each turn. Default for all keys is 'off', but this can be changed by the scenario or by special abilities (see [[AbilitiesWML]]). The status of a unit is displayed on the Status Table; each status modification ''statusmod'' is represented by the image '''misc/statusmod.png'''.<br />
** '''poisoned''': if 'yes', the unit loses 8 HP each turn. See also ''heals'', ''cures'', [[AbilitiesWML]].<br />
** '''slowed''': if 'yes', the unit has 50% of its normal movement and does half damage. When the controller of the unit's turn is over, ''slowed'' is set to 'off' <br />
** '''petrified''': if 'yes', the unit cannot move, attack, or be attacked.<br />
** '''uncovered''': if 'yes', the unit has performed an action (e.g. attacking) that causes it to no longer be hidden until the next turn.<br />
** '''guardian''': this is set to 'yes' by ai_special=guardian and clearing it will allow the unit to act normally again.<br />
** '''healable''': if set to 'no', the unit cannot be healed. {{DevFeature1.9}} ''healable'' is deprecated, use ''unhealable'' instead.<br />
** '''unhealable''': {{DevFeature1.9}} if set to 'yes', the unit cannot be healed.<br />
<br />
* '''[variables]''' a set of variables that will be stored when this unit is stored (See [store_unit], [[InternalActionsWML]]). The attribute '''variable'''='''value''' means that when the unit is stored in the array ''unit'', the variable '''unit'''.variables.''variable'' will have the value ''value'' (See [[VariablesWML]]).<br />
<br />
* '''[modifications]''' changes that have been made to the unit.<br />
** '''[trait]''' a trait the unit has. Same format as [trait], [[UnitsWML]].<br />
** '''[object]''' an object the unit has. Same format as [object], [[DirectActionsWML]].<br />
<br />
* '''unit_description''': overrides the unit type description for this unit. You will probably want to set up a ''post_advance'' [[EventWML|event]] to override the default description after promotions. Or better, use an object with a profile [[EffectWML|effect(s)]] to filter on unit type and change the unit description and/or portrait.<br />
<br />
* '''[event]''' The event is copied from the contents of the created unit to the scenario. Everything valid in [scenario][event]s is valid in [unit][event]s. warning: Contrarily to [unit_type][event]s, a [unit] tag performs variable substitution before creating the unit. This can be worked around by using $|variable_name syntax. note: [unit][event] does currently (1.8.3, 1.9.0-svn) not work.<br />
<br />
== See Also ==<br />
<br />
* [[UnitTypeWML]]<br />
* [[ReferenceWML]]<br />
<br />
[[Category:WML Reference]]</div>Fabihttps://wiki.wesnoth.org/index.php?title=DirectActionsWML&diff=42663DirectActionsWML2011-05-14T09:50:01Z<p>Fabi: /* Direct actions */</p>
<hr />
<div>{{WML Tags}}<br />
== Direct actions ==<br />
<br />
Direct actions are actions that have a direct effect on gameplay. They can be used inside of [[EventWML|events]].<br />
<br />
The following tags are actions:<br />
<br />
=== [endlevel] ===<br />
Ends the scenario.<br />
* '''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. {{DevFeature}}: All values for result=... except victory and defeat are being discarded in favor of modifying '''[endlevel]''' behaviour with single keys.<br />
Unless ''result=defeat'', the following keys can also be used:<br />
* '''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.<br />
* '''carryover_report''': whether the player should receive a summary of the scenario outcome, the default is carryover_report=yes.<br />
* '''save''': whether a start-of-scenario save should be created for the next scenario, the default is save=yes. Do not confuse this with saving of replays for the current scenario.<br />
* '''linger_mode''': If ...=yes, the screen is greyed out and there's the possibility to save before advancing to the next scenario, the default is linger_mode=yes.<br />
* '''reveal_map''': (Multiplayer only) (Default is 'yes') If 'no', shroud doesn't disappear when game ended. {{DevFeature1.9}}<br />
* '''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''.<br />
<br />
When the result is "victory" the following keys can be used:<br />
* '''carryover_percentage''': by default 80% of the gold is carried over to the next scenario, with this key the amount can be changed.<br />
* '''carryover_add''': if true the gold will be added to the starting gold the next scenario, if false the next scenario will start with the amount of the current scenario (after taxes) or the minimum in the next scenario. Default is false.<br />
* '''music''': (default specified in '''[scenario]''' or '''[game_config]''' tags) a comma-separated list of music tracks from which one will be chosen and played once after any events related to the end of level result are executed; by default, victory_music is used on victory, and defeat_music on defeat.<br />
* '''end_text''': Text that is shown centered in a black screen at the end of a campaign. Defaults to "The End". Note that this has cumulative effects over the campaign - it persists even if the endlevel does not trigger the end of the campaign. See also [[CampaignWML]].<br />
* '''end_text_duration''': Delay, in milliseconds, before displaying the game credits at the end of a campaign. In other words, for how much time '''end_text''' is displayed on screen. Defaults to 3500. Note that this has cumulative effects over the campaign - it persists even if the endlevel does not trigger the end of the campaign. See also [[CampaignWML]].<br />
<br />
=== [unit] ===<br />
Places a unit on the map. For syntax see [[SingleUnitWML]].<br />
* {{Short Note:Predefined Macro|GENERIC_UNIT}}<br />
* '''to_variable''': spawn directly into a variable instead of on the map.<br />
<br />
=== [recall] ===<br />
Recalls a unit. The unit is recalled free of charge, and is placed near the leader.<br />
* [[StandardUnitFilter]]: the first matching unit will be recalled. If no units match this tag is ignored. Do not use a [filter] tag. If a comma separated list is given, every unit currently considered for recall is checked against all the types (not each single one of the types against all units).<br />
* '''x,y''': the unit is placed here instead of next to the leader.<br />
* '''show''': yes/no, default yes: whether the unit is animated (faded in) or instantly displayed<br />
* '''fire_event''': {{DevFeature1.9}} boolean yes|no (default no); whether any according prerecall or recall events shall be fired. In pre-1.9.3 these events are all automatically fired and it can't be turned off.<br />
* '''check_passability''': {{DevFeature1.9}} (boolean yes|no, default yes): If yes, checks for terrain passability when placing the unit (a nearby passable hex is chosen). Before 1.9 this key is always "no".<br />
<br />
=== [teleport] ===<br />
Teleports a unit on map. {{Short Note:Predefined Macro|TELEPORT_UNIT}}<br />
* '''[filter]''': [[StandardUnitFilter]] the first unit matching this filter will be teleported.<br />
* '''x,y''': the position to teleport to.<br />
* '''clear_shroud''': should shroud be cleared on arrival<br />
* '''animate''': should a teleport animation be played (if the unit doesn't have a teleport animation, it will fade out/fade in)<br />
* '''ignore_passability''': {{DevFeature}} normally, units will not be teleported into terrain that is impassable for them. Setting this attribute to "yes" permits it. {{DevFeature1.9}}Renamed to check_passability (default yes).<br />
<br />
(Note: There is also a ability named teleport, see [[AbilitiesWML]].)<br />
<br />
=== [terrain_mask] ===<br />
Changes the terrain on the map. See [[TerrainMaskWML]].<br />
<br />
=== [terrain] ===<br />
Changes the terrain on the map.<br />
* '''terrain''': the character of the terrain to use. See [[TerrainCodesWML]] to see what letter a type of terrain uses.<br />
* '''x,y''': the position (or range of positions) to change. {{DevFeature1.9}}: [terrain] accepts a [[StandardLocationFilter]]. This [[StandardLocationFilter]]'s terrain= key is used for the new terrain, filtering by terrain can be done with a nested [[StandardLocationFilter]]: [and]terrain=terrain_string_to_be_filtered_for.<br />
* '''layer''': (overlay|base|both, default=both) only change the specified layer.<br />
* '''replace_if_failed''': (default=no) When replacing just one layer failed, try to replace the whole terrain. If '''terrain''' is an overlay only terrain, use the default_base as base layer. If the terrain has no default base, do nothing.<br />
<br />
=== [gold] ===<br />
Gives one side gold.<br />
* '''amount''': the amount of gold to give.<br />
* '''side''': (default=1) the number of the side to give the gold to; {{DevFeature1.9}} takes a comma-separated list as of 1.9.5.<br />
* '''[filter_side]''' {{DevFeature1.9}} with a [[StandardSideFilter]] as argument<br />
<br />
=== [unstore_unit] ===<br />
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 [[InternalActionsWML#.5Bstore_unit.5D|[store_unit]]], [[ConditionalActionsWML#.5Bwhile.5D|[while]]] and [[InternalActionsWML#.5Bclear_variable.5D|[clear_variable]]]. Note units with a negative amount of hitpoints will be unstored with 1 hitpoint.<br />
* '''variable''': the name of the variable.<br />
* '''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. <br />
* '''check_passability''': {{DevFeature1.9}} (boolean yes|no, default yes): If yes, checks for terrain passability when placing the unit. This key has no effect if find_vacant=no (no check performed then). Before 1.9 this key is always "no".<br />
* '''text''': (translatable) floating text to display above the unit, such as a damage amount<br />
* '''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.)<br />
* '''advance''': (default=true) if true the unit is advanced if it has enough XP. When modifying XP make sure to do it from inside a [[EventWML#Multiplayer_safety|synchronized event]] or it may lead to OOS errors especially when several advancement paths exist. Note that advance and post advance events are called, so infinite loops can happen.<br />
* '''fire_event''': {{DevFeature1.9}}(boolean yes|no, default no) Whether any advance/post advance events shall be fired if an advancement takes place, no effect otherwise. Before 1.9 this is always "yes".<br />
* '''x''' ,'''y''': override unit location, "x,y=recall, recall" will put the unit on the unit's side's recall list.<br />
<br />
=== [allow_recruit] ===<br />
Allows a side to recruit units it couldn't previously recruit.<br />
* '''type''': the types of units that the side can now recruit.<br />
* '''side''': (default=1) the number of the side that is being allowed to recruit the units {{DevFeature1.9}} side= can be a comma-separated list<br />
<br />
=== [allow_extra_recruit] ===<br />
{{DevFeature1.9}}; Allows a leader to recruit units it couldn't previously recruit.<br />
* '''type''': the types of units that the unit can now recruit.<br />
* '''[filter]''' with a [[StandardUnitFilter]] as argument. All units matching this filter are modified. Matches on recall list units too.<br />
<br />
=== [disallow_recruit] ===<br />
Prevents a side from recruiting units it could previously recruit.<br />
* '''type''': the types of units that the side can no longer recruit.<br />
* '''side''': (default=1) the number of the side that may no longer recruit the units. {{DevFeature1.9}} side= can be a comma-separated list<br />
<br />
=== [disallow_extra_recruit] ===<br />
{{DevFeature1.9}}; Prevents a leader from recruiting units it could previously recruit.<br />
* '''type''': the types of units that the side can no longer recruit.<br />
* '''[filter]''' with a [[StandardUnitFilter]] as argument. All units matching this filter are modified. Matches on recall list units too.<br />
<br />
=== [set_recruit] ===<br />
Sets the units a side can recruit.<br />
* '''recruit''': the types of units that the side can now recruit.<br />
* '''side''': (default=1) the number of the side that is having its recruitment set. {{DevFeature1.9}} side= can be a comma-separated list<br />
<br />
=== [set_extra_recruit] === <br />
{{DevFeature1.9}}; Sets the units a leader can recruit.<br />
* '''recruit''': the types of units that the leader can now recruit.<br />
* '''[filter]''' with a [[StandardUnitFilter]] as argument. All units matching this filter are modified. Matches on recall list units too.<br />
<br />
=== [modify_side] ===<br />
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!'''<br />
* '''side''': (default=1) the number of the side that is to be changed.<br />
* '''[filter_side]''' {{DevFeature1.9}} with a [[StandardSideFilter]] as argument<br />
* '''income''': the income given at the begining of each turn.<br />
* '''team_name''': the team in which the side plays the scenario.<br />
* '''user_team_name''': a translatable string representing the team's description. This has no effect on alliances. Defaults to ''team_name''.<br />
* '''gold''': the amount of gold the side owns.<br />
* '''village_gold''': the income setting per village for the side.<br />
* '''controller''': the identifier string of the side's controller. Uses the same syntax of the ''controller'' key in the [[SideWML|[side]]] tag.<br />
* '''fog''': a boolean string (yes/no) describing the status of Fog for the side.<br />
* '''shroud''': a boolean string describing the status of Shroud for the side.<br />
* '''hidden''': a boolean string specifying whether side is shown in status table.<br />
* '''[ai]''': replaces a side's AI parameters with the new specified ones. Uses the same syntax described in [[AiWML]].<br />
* '''switch_ai''': {{DevFeature}} replaces a side ai with a new AI from specified file(ignoring those AI parameters above). Path to file follows the usual WML convention.<br />
* '''share_maps''': {{DevFeature}} change the share_maps side attribute. Be sure to use shroud=yes for that side and have it as an ally<br />
* '''share_view''': {{DevFeature}} change the share_view side attribute. Be sure to use fog=yes for that side and have it as an ally<br />
<br />
=== [modify_turns] ===<br />
Modifies the turn limit in the middle of a scenario.<br />
* '''value''': the new turn limit.<br />
* '''add''': if used instead of ''value'', specifies the number of turns to add to the current limit (can be negative).<br />
* '''current''': changes the current turn number after applying turn limit modifications, if any. It is possible to change the current turn number to a greater one than the current only; also, it is not possible to change the turn number to exceed the turn limit.<br />
<br />
=== [capture_village] ===<br />
Changes the ownership of a village.<br />
* '''side''': the side that takes control of the village. This side needs to have a leader (canrecruit=yes). If the side key is not given, the village will become neutral.<br />
* '''x, y''': the location of the village. Can be a comma-separated list and/or location ranges. {{DevFeature1.9}}: [capture_village] accepts a full SLF; all village locations matching the filter are affected.<br />
<br />
=== [kill] ===<br />
Removes all units (including units in a recall list) that match the filter from the game.<br />
* [[StandardUnitFilter]]: Selection criterion; do not use a [filter] tag.<br />
* '''animate''': if 'yes', displays the unit dying (fading away).<br />
* '''fire_event''': if 'yes', triggers any appropriate 'die' events (See [[EventWML]]). Note that any 'last breath' and '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. In the stable version, the variable second_unit in each of these die and last breath events is always the same as the variable unit (the dying unit). Note that events are only fired for killed units that have been on the map (as opposed to recall list).<br />
* '''[secondary_unit]''' {{DevFeature1.9}} with a [[StandardUnitFilter]] as argument. Do not use a [filter] tag. Has an effect only if fire_event=yes. The first on-map unit matching the filter becomes second_unit in any fired die and last breath events. If an on-map unit matches and if there are several units killed with a single [kill] tag, second_unit is this same unit for all of them. If no on-map unit matches or [secondary_unit] isn't present, the variable second_unit in each of the die and last breath events is always the same as the variable unit (the dying unit).<br />
<br />
=== [move_unit] ===<br />
{{DevFeature1.9}}; works like the MOVE_UNIT macro.<br />
* [[StandardUnitFilter]] as argument; do not use a [filter] tag. All units matching the filter are moved. If the target location is occupied, the nearest free passable location is chosen. All target locations passed (see below) need to be passable hexes for the particular moved units.<br />
* '''to_x''' (unsigned integer): The units are moved to this x coordinate. Can be a comma-separated list, in which case the unit follows this given path during the move.<br />
* '''to_y''' (unsigned integer): The units are moved to this y coordinate. Can be a comma-separated list.<br />
* '''fire_event''' (optional, boolean yes|no, default no): Whether any according moveto events shall be fired. The target location ($x1, $y1 in the event) may not be the same location that the unit was tried to be moved to, if the original target location is occupied or impassable.<br />
* '''check_passability''' (boolean yes|no, default yes): Whether the terrain the unit is moved to should be checked for suiting the unit. (If it does not, a nearby suitable hex is chosen.)<br />
<br />
=== [modify_ai] ===<br />
* '''[filter_side]''' {{DevFeature1.9}} with a [[StandardSideFilter]] as argument<br />
Changes the AI for a specified side. See [[Customizing_AI_in_Wesnoth_1.8#.5Bmodify_ai.5D_tag]]<br />
<br />
=== [modify_unit] ===<br />
{{DevFeature1.9}}; works similar to the MODIFY_UNIT macro.<br />
* '''[filter]''' with a [[StandardUnitFilter]] as argument. All units matching this filter are modified. Matches on recall list units too.<br />
* Accepts generally the syntax inside of wml unit variables created by [store_unit] which can be viewed in a savefile or by using the :inspect command. Can add traits with immediate effect. Cannot remove things. Subtags with the same name must be written in the correct order to match them with the tag they are supposed to modify.<br />
example usage (see also the test scenario):<br />
[modify_unit]<br />
[filter]<br />
type=Troll Rocklobber<br />
[/filter]<br />
hitpoints=10<br />
[modifications]<br />
[trait]<br />
# first trait is unmodified<br />
[/trait]<br />
{TRAIT_HEALTHY}# second trait is replaced with the healthy trait<br />
[/modifications]<br />
[/modify_unit]<br />
<br />
The unit which is currently modified is accessible via $this_unit, e.g. hitpoints = "$($this_unit.hitpoints / 2)" to set the hitpoints of all units to half of their particular maxima. This this_unit variable is independent from the this_unit variable available in the SUF used to determine which units to modify (first all matching units are gathered, and then all those are modified).<br />
<br />
note: The syntax allowed is somehow vague. Just try things and possibly correct/add/modify this documentation. (a [http://forums.wesnoth.org/viewtopic.php?f=21&t=31676& forum thread] discusses some related issues).<br />
<br />
=== [transform_unit] ===<br />
{{DevFeature1.9}}; transforms every unit matching the filter to the given unit type. Keeps intact hitpoints, experience and status. If the unit is transformed to a non-living type (undead or mechanical), it will be also unpoisoned.<br />
* [[StandardUnitFilter]]: do not use a [filter] tag.<br />
* '''transform_to''': the unit type in which all the units matching the filter will be transformed. If missing, the units will follow their normal advancement.<br />
<br />
=== [petrify] ===<br />
{{DevFeature1.9}}(This tag did never exist until r47553 (from 1.9.3 on), although it was already documented.)<br />
<br />
* [[StandardUnitFilter]] as an argument. Do not use a [filter] tag. All units matching this filter are petrified. Recall list units are included.<br />
<br />
=== [unpetrify] ===<br />
* [[StandardUnitFilter]] as an argument. {{DevFeature1.9}}: Do not use a [filter] tag. All units matching this filter are unpetrified {{DevFeature1.9}}: recall list units included.<br />
<br />
=== [object] ===<br />
Gives some unit an object and removes all items on the tile the unit is on.<br />
* '''id''': (Optional) 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.<br />
* '''[effect]''': one or more effect elements may be listed. See [[EffectWML]] for a description of [effect].<br />
* '''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).<br />
* '''[filter]''' with a [[StandardUnitFilter]] as argument. 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.<br />
* '''[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.<br />
* '''silent''': whether or not messages should be suppressed. Default is "no".<br />
* '''image''': the displayed image of the object.<br />
* '''name''': (translatable) displayed as a caption of the image.<br />
<br />
* '''description''': (translatable) displayed as a message of the image.<br />
* '''cannot_use_message''': (translatable) displayed instead of '''description''' if no unit passes the filter test.<br />
* 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.<br />
* 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.<br />
<br />
=== [remove_shroud] ===<br />
Removes some shroud from the map for a certain side (only relevant for sides that have shroud=yes).<br />
* '''side''': (default=1) the side for which to remove shroud. {{DevFeature1.9}} takes a comma-separated list as of 1.9.5.<br />
* '''[filter_side]''' {{DevFeature1.9}} with a [[StandardSideFilter]] as argument<br />
* [[StandardLocationFilter]]: the range of tiles for which shroud should be removed<br />
<br />
=== [place_shroud] ===<br />
Places some shroud on the map for a certain side (only relevant for sides that have shroud=yes).<br />
* '''side''': (default=1) the side for which to place shroud. {{DevFeature1.9}} takes a comma-separated list as of 1.9.5.<br />
* '''[filter_side]''' {{DevFeature1.9}} with a [[StandardSideFilter]] as argument<br />
* [[StandardLocationFilter]]: the range of tiles on which shroud should be placed<br />
<br />
=== [allow_undo] ===<br />
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.<br />
* 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.<br />
<br />
=== [heal_unit] ===<br />
Heal a unit. The variable '''$heal_amount''' will be set to the exact number of points healed (i.e can be lesser than the parameter '''amount''' if the unit is fully healed). {{DevFeature1.9}} $heal_amount contains only the number of hitpoints the first unit that was found got healed (no change, actually).<br />
* '''[filter]''': [[StandardUnitFilter]] the first unit matching the filter will be healed. If no filter is supplied, it is tried to take the unit at $x1, $y1. {{DevFeature1.9}} All matching on-map units are healed.<br />
* '''[filter_second]''': [[StandardUnitFilter]] all the units matching the filter ''and'' having the ''heals'' ability will have their animation played (if ''animate'' is set to true) {{DevFeature1.9}}...for each of the units healed.<br />
* '''amount''': (integer, default full) the maximum points the unit(s) will be healed. Can't set below 1 or above max_hitpoints. If "full", sets hitpoints to max_hitpoints. Before 1.9 the default is 0.<br />
* '''animate''': a boolean which indicate if the healing animations must be played. (default no)<br />
* '''moves''': {{DevFeature1.9}} (integer, default 0) The maximum current movement points the units will be "healed". Can't set below 0 or above max_moves. If "full", sets moves to max_moves.<br />
* '''restore_attacks''': {{DevFeature1.9}} (boolean, default no) Whether the units' attacks_left should be reset to their max_attacks (usually 1).<br />
* '''restore_statuses''': {{DevFeature1.9}} (boolean, default yes) Whether standard statuses should be reset to "no". This affects poisoned, slowed, petrified and unhealable. Before 1.9 this is always "no".<br />
<br />
=== [harm_unit] ===<br />
{{DevFeature1.9}}Harms every unit matching the filter, for the specific damage amount.<br />
* '''[filter]''': [[StandardUnitFilter]] all matching units will be harmed (required).<br />
* '''amount''': the amount of damage that will be done (required).<br />
* '''alignment''': (default neutral) applies an alignment to the damage, this means that if alignment=chaotic, the damage will be increased at night and reduced at day.<br />
* '''damage_type''': if present, amount will be altered by unit resistance to the damage type specified.<br />
* '''kill''': (default yes) if yes, when an harmed unit goes to or below 0 HP, it is killed; if no its HP are set to 1.<br />
* '''fire_event''': (default no) if yes, when a unit is killed by harming, the corresponding events are fired.<br />
* '''animate''': (default no) if yes, scrolls to each unit before harming it and plays its defense and death animations.<br />
* '''[secondary_attack]''': sets the weapon against which the unit harmed will defend, to allow playing specific defense animations. Takes a weapon filter as argument, see [[FilterWML]].<br />
* '''delay''': if animate=yes, sets the delay (in milliseconds, default 500) between each unit harming.<br />
* '''variable''': if present, the damage caused to the unit, altered by resistances, will be stored in a WML array with the given name, under the "harm_amount" key.<br />
* '''poisoned, slowed, petrified, unhealable''': (default no) if yes, every harmed unit that doesn't already have such status will have it set.<br />
<br />
=== [time_area] ===<br />
How a day should progress in a given area. Everywhere not specified in a [time_area] tag is affected by the [time] and [illuminated_time] tags in the [scenario] tag.<br />
* [[StandardLocationFilter]]: the locations to affect.<br />
* [[TimeWML]]: the new schedule.<br />
* '''id''': an unique identifier assigned to a time_area. Optional, unless you want to remove the time_area later. Can be a comma-separated list when removing time_areas, see below.<br />
* '''remove''': (boolean) yes/no value. Indicates whether the specified time_area should be removed. Requires an identifier. If no identifier is used, however, all time_areas are removed.<br />
<br />
=== [end_turn] ===<br />
End the current side's turn. {{DevFeature}} The current event is finished before the turn is ended. Also, if the current event (where the tag appears) has been fired by another event, that event (and the complete stack of other possible parent events) is ended before [end_turn] comes into affect. Also, events following the event stack that fired [end_turn] are not omitted (e.g. [end_turn] is used by a side turn event and a turn refresh event does something afterwards).<br />
<br />
=== [replace_map] ===<br />
<br />
Replaces the entire map.<br />
* '''map''': Content of a wesnoth map file. example:<br />
map="{campaigns/Heir_To_The_Throne/maps/01_The_Elves_Besieged.map}"<br />
* '''expand''': if 'yes', allows the map size to increase. The expansion direction is currently always bottom-right.<br />
* '''shrink''': if 'yes', allows the map size to decrease. If the map size is reduced, any units that would no longer be on the map due to its coordinates no longer existing will be put into the recall list.<br />
<br />
=== [replace_schedule] ===<br />
Replace the time of day schedule of the entire scenario. {{DevFeature1.9}}<br />
* [[TimeWML]]: the new schedule.<br />
<br />
=== [tunnel] ===<br />
<br />
{{DevFeature1.9}}<br />
<br />
Create a tunnel between some locations, later usable by units to move from source hex to target hex (using the movement cost of unit on the target terrain). ([http://forums.wesnoth.org/viewtopic.php?f=21&t=14749&p=405667&hilit=tunnel#p405667 source])<br />
<br />
* '''id''' identifier for the tunnel, to allow removing (optional).<br />
* '''remove''': (boolean) yes/no value. If yes, removes all defined tunnels with the same ID (then only id= is necessary). (default: no)<br />
* '''bidirectional''': (boolean) if yes, creates also a tunnel in the other direction. (default: yes)<br />
* '''always_visible''': (boolean) if yes, the possible movement of enemies under fog can be seen. (default: no)<br />
* '''[source]''': [[StandardLocationFilter]] the source hex(es) (required).<br />
* '''[target]''': [[StandardLocationFilter]] the target hex(es) (required).<br />
* '''[filter]''': [[StandardUnitFilter]] the units which can use the tunnel (required). Leave empty for "all units".<br />
<br />
(Note: The tunnel tag can also be used inside the [[AbilitiesWML|[teleport]]] ability, without remove= and id=).<br />
<br />
== Useful Macros ==<br />
There are some predefined macros that you find useful for direct actions. You can find a complete list along with a detailed explanation of how they work [http://www.wesnoth.org/macro-reference.xhtml here].<br />
* '''{MOVE_UNIT}''': Moves a unit to another location in the map and the player sees the movement (unlike [teleport])<br />
* '''{FULL_HEAL}''': Brings a unit to full HP<br />
* '''{LOYAL_UNIT}''': Create a loyal unit<br />
* '''{MODIFY_TERRAIN_MASK}''': Modify an area of terrain<br />
<br />
== See Also ==<br />
<br />
* [[InternalActionsWML]]<br />
* [[InterfaceActionsWML]]<br />
* [[EventWML]]<br />
* [[ReferenceWML]]<br />
<br />
[[Category: WML Reference]]<br />
[[Category: ActionsWML]]</div>Fabihttps://wiki.wesnoth.org/index.php?title=SoC_Ideas_Multiplayer_Improvements_2011&diff=41138SoC Ideas Multiplayer Improvements 20112011-03-25T00:14:56Z<p>Fabi: /* Unification of multiplayer and singleplayer in the engine */</p>
<hr />
<div>{{SoC2011Idea}}<br />
<br />
<br />
=Description=<br />
<h2>Reengineer Wesnoth's multiplayer engine</h2><br />
<br />
More info at [[SoC_Ideas_Multiplayer_Improvements_2011]]<br />
<br />
<br />
Wesnoth includes a lot of multiplayer content, like 'standard' scenarios, custom scenarios and multiplayer campaigns. However, when creating a multiplayer game, the player's options are highly limited - for example, it is not possible to select the difficulty level before starting the scenario, and it is not possible to allow the scenario to set what 'variables' can be customized by players before game is started (there's only global 'use map settings' flag and some control over sides). We want to reengineer the architecture of Wesnoth's multiplayer engine to allow it to support those things.<br />
<br />
{{#dpl:<br />
|resultsheader=''There are %PAGES% submitted student proposals for this idea''<br />
|oneresultheader=''There is 1 submitted student proposal for this idea''<br />
|suppresserrors=true<br />
|noresultsheader=''There are no submitted student proposals for this idea''<br />
|category=Summer of Code 2011 Student Page&SoC Ideas Multiplayer Improvements 2011<br />
|notcategory=SoC 2011 Not Submitted To Google<br />
|include=#Description<br />
|mode=userformat<br />
|format=,,<br/>See [[%PAGE%|%TITLE%]] for more information.<br/><br/>,<br />
}}<br />
<br />
= Required knowledge =<br />
* Solid C++ skills, especially the ability to read existing code.<br />
<br />
=Additional Information=<br />
== Difficulty levels in MP ==<br />
Wesnoth includes a lot of text data config files which need to be 'parsed' before game starts. Difficulty needs to be known at the time we parse those config files. Currently, we parse those files before entering the multiplayer lobby. As a consequence, we cannot select difficulty in multiplayer game (the data's already parsed at the point when the game is created). Note that parsing takes a lot of time, so, if we do it while already connected to MP server, we need to add workarounds to ensure it doesn't think the client disconnected.<br />
<br />
== Game creation screen ==<br />
We want the multiplayer game creation screen to be different and better. We think that we need different screens for normal MP scenarios, 'custom' MP scenarios and for MP campaigns.<br />
<br />
== Unification of multiplayer and singleplayer in the engine==<br />
A really long-term goal would be to reduce the complexity of the codebase by merging SP and MP (making SP a special case of MP and allow seamless transition between both). There is a number of steps which could be taken to gradually move closer to this goal.<br />
<br />
=== Details ===<br />
This task was always considered very hard in the past throughout the developer community, experiences with the <br />
transformation of the "Legend of Wesmere" taken into account that may actually not be true.<br />
<br />
Replacing every [scenario] with a [multiplayer] tag and including it's files together with every other content that is guarded by the MULTIPLAYER pre-processor symbol makes the scenarios of the campaign in question available in the create game dialogue of the mp lobby.<br />
<br />
== Under the hood ==<br />
Wesnoth uses a pre-processor to organise its file hierarchy and to make use of macros.<br />
This system is used to load only a certain subset of all available WML code depending on the current needs.<br />
<br />
A freshly started Wesnoth instance does neither know about the inners of single player campaigns nor multiplayer content.<br />
The player is able to choose between the mainline campaigns before the wml tree gets re-parsed because the [campaign] tag hosted in the campaign's _main.cfg contains all needed information and it's parsed from game start.<br />
<br />
But the engine does only read the _main.cfg when the whole directory was included by a pre-processor directive.<br />
If you allow me to show you some wml code you will discover that the rest of the campaign is guarded by a pre-processor symbol.<br />
<br />
From the _main.cfg of "Heir To The Throne":<br />
.<br />
.<br />
.<br />
[campaign]<br />
id=Heir_To_The_Throne<br />
.<br />
.<br />
.<br />
define=CAMPAIGN_HEIR_TO_THE_THRONE<br />
extra_defines=SOMETHING, ANYTHING # inserted as example<br />
.<br />
.<br />
.<br />
[/campaign]<br />
.<br />
.<br />
.<br />
#ifdef CAMPAIGN_HEIR_TO_THE_THRONE<br />
[binary_path]<br />
path=data/campaigns/Heir_To_The_Throne<br />
[/binary_path]<br />
[+units]<br />
{campaigns/Heir_To_The_Throne/units}<br />
[/units]<br />
<br />
{campaigns/Heir_To_The_Throne/utils}<br />
{campaigns/Heir_To_The_Throne/scenarios}<br />
#endif<br />
.<br />
.<br />
.<br />
If the player selects the campaign he will be asked for the difficulty level of the campaign.<br />
After that the whole wmltree while be re-parsed, this time with the additional defines:<br />
CAMPAIGN_HEIR_TO_THE_THRONE<br />
one of EASY NORMAL HARD<br />
SOMETHING<br />
ANYTHING<br />
<br />
=Whom to ask about this=<br />
Ask Crab_ and/or fendrin on #wesnoth-dev<br />
<br />
=Possible pre-gsoc tasks=<br />
<br />
* Talk with devs, users, and MP devs about UI design of MP creation screens and show some prototypes of game creation screens for MP campaigns, and custom MP scenarios<br />
<br />
* Hack in a way to select difficulty before MP scenario start (doesn't need to be done cleanly, can be a prototype hack)<br />
<br />
* Add a new attribute to game creation screen, to allow each player to select a number from 1 to 100 and make it available to WML code as a variable after scenario starts. Bonus points if you allow host to see the variable in the game creation screen and allow him to change it and lock it down for any particular player.<br />
<br />
* write or download a small MP campaign and report on any MP campaign support bugs that you find.<br />
<br />
* implement a lobby command to make the player who issued that command host and start a game with specified parameters, bypassing side selection screen.<br />
<br />
* Make yourself familiar with the multiplayer port of the "Legend of Wesmere" campaign. Try to understand why and how the difficulty setting is handled in its case.<br />
<br />
* Implement a simple GUI2 frontend for the :droid in-game console command.</div>Fabihttps://wiki.wesnoth.org/index.php?title=SoC_Ideas_Eclipse_Plugin2011&diff=40756SoC Ideas Eclipse Plugin20112011-03-10T19:45:23Z<p>Fabi: /* Additional Information */</p>
<hr />
<div>{{SoC2011Idea}}<br />
<br />
= Description =<br />
<h2>Enhance & polish the Wesnoth Eclipse Plugin</h2><br />
More info at [[SoC_Ideas_Eclipse_Plugin2011]]<br />
<br />
A java-based Eclipse plugin was created in 2010 to allow easier creation and modification of User-Made Content for Wesnoth. You should extend this work and polish existing features in terms of usability and performance, and add new features.<br />
<br />
{{#dpl:<br />
|resultsheader=''There are %PAGES% submitted student proposals for this idea''<br />
|oneresultheader=''There is 1 submitted student proposal for this idea''<br />
|suppresserrors=true<br />
|noresultsheader=''There are no submitted student proposals for this idea''<br />
|category=Summer of Code 2011 Student Page&SoC Ideas Eclipse Plugin2011<br />
|notcategory=SoC 2011 Not Submitted To Google<br />
|include=#Description<br />
|mode=userformat<br />
|format=,,<br/>See [[%PAGE%|%TITLE%]] for more information.<br/><br/>,<br />
}}<br />
<br />
= Additional Information =<br />
<br />
== General plugin information ==<br />
Current plugin's webpage: http://eclipse.wesnoth.org/<br />
<br />
Older (but may be still actual for some points) page: http://wiki.wesnoth.org/SoC_Ideas_Eclipse_Plugin<br />
<br />
The plugin is available on svn in the folder: ''trunk/utils/java'' (link for svn: [http://svn.gna.org/viewcvs/wesnoth/trunk/utils/java/]).<br />
<br />
The plugin uses Xtext [http://www.eclipse.org/Xtext/] for the editor component which provides a very good DSL framework to be used with the WML language.<br />
<br />
== Support for multiple Wesnoth installations ==<br />
- There should be support for handling multiple Wesnoth installations, each one of them with different binaries/wml tools and so on.<br />
<br />
- The user should be able to use the feature in an easy way that should restart the eclipse workspace as few as possible.<br />
<br />
== Enhance the autocomplete feature ==<br />
The current autocomplete feature works just for a small amount of keys/tags. There should be an easy way (possibly even allow non-eclipse-plugin developers to modify it) specifying the tags we want to autocomplete on or implement autocomplete for:<br />
- events<br />
- variables<br />
- attributes<br />
- attributes values - e.g.: true/false, yes/no<br />
- macros<br />
<br />
== Plugin documentation ==<br />
The plugin is lacking proper documentation. There is only a readme [http://eclipse.wesnoth.org/doc_howto.html] that specifies just a quick overview of the plugin. To gain more popularity it should be much more documented:<br />
<br />
- Create some usage videos, showing off the cool features: wizards, auto-complete, macro navigation<br />
- Create multiple step-by-step readme documents for different wizards<br />
<br />
== Automatic/headless building ==<br />
Currently the plugin and it's update site is built "in-house". That means you have to pop eclipse, clear current version, and run the build again. There should be a way of automatic - without the need for eclipse - building the plugin's update site & creating the standalone build also. <br />
<br />
== Other ideas ==<br />
You can also give other ideas you think are worthy to be implemented.<br />
<br />
== Possible pre-gsoc tasks ==<br />
- Make yourself familiar with basic WML syntax.<br />
- Try the emacs plugin (data/tools/emacs_mode) to see an example of a wml ide.<br />
- Install the eclipse UMC plugin and use it to write a simple campaign or multiplayer scenario.<br />
<br />
= Whom to ask about this =<br />
If you want more information regarding the plugin please contact timotei/timotei21 on IRC.<br />
The mentor of the last gsoc eclipse plugin project was fendrin on IRC.</div>Fabihttps://wiki.wesnoth.org/index.php?title=SoC_Ideas_Eclipse_Plugin2011&diff=40755SoC Ideas Eclipse Plugin20112011-03-10T19:36:34Z<p>Fabi: /* Whom to ask about this */</p>
<hr />
<div>{{SoC2011Idea}}<br />
<br />
= Description =<br />
<h2>Enhance & polish the Wesnoth Eclipse Plugin</h2><br />
More info at [[SoC_Ideas_Eclipse_Plugin2011]]<br />
<br />
A java-based Eclipse plugin was created in 2010 to allow easier creation and modification of User-Made Content for Wesnoth. You should extend this work and polish existing features in terms of usability and performance, and add new features.<br />
<br />
{{#dpl:<br />
|resultsheader=''There are %PAGES% submitted student proposals for this idea''<br />
|oneresultheader=''There is 1 submitted student proposal for this idea''<br />
|suppresserrors=true<br />
|noresultsheader=''There are no submitted student proposals for this idea''<br />
|category=Summer of Code 2011 Student Page&SoC Ideas Eclipse Plugin2011<br />
|notcategory=SoC 2011 Not Submitted To Google<br />
|include=#Description<br />
|mode=userformat<br />
|format=,,<br/>See [[%PAGE%|%TITLE%]] for more information.<br/><br/>,<br />
}}<br />
<br />
= Additional Information =<br />
<br />
== General plugin information ==<br />
Current plugin's webpage: http://eclipse.wesnoth.org/<br />
<br />
Older (but may be still actual for some points) page: http://wiki.wesnoth.org/SoC_Ideas_Eclipse_Plugin<br />
<br />
The plugin is available on svn in the folder: ''trunk/utils/java'' (link for svn: [http://svn.gna.org/viewcvs/wesnoth/trunk/utils/java/]).<br />
<br />
The plugin uses Xtext [http://www.eclipse.org/Xtext/] for the editor component which provides a very good DSL framework to be used with the WML language.<br />
<br />
== Support for multiple Wesnoth installations ==<br />
- There should be support for handling multiple Wesnoth installations, each one of them with different binaries/wml tools and so on.<br />
<br />
- The user should be able to use the feature in an easy way that should restart the eclipse workspace as few as possible.<br />
<br />
== Enhance the autocomplete feature ==<br />
The current autocomplete feature works just for a small amount of keys/tags. There should be an easy way (possibly even allow non-eclipse-plugin developers to modify it) specifying the tags we want to autocomplete on or implement autocomplete for:<br />
- events<br />
- variables<br />
- attributes<br />
- attributes values - e.g.: true/false, yes/no<br />
- macros<br />
<br />
== Plugin documentation ==<br />
The plugin is lacking proper documentation. There is only a readme [http://eclipse.wesnoth.org/doc_howto.html] that specifies just a quick overview of the plugin. To gain more popularity it should be much more documented:<br />
<br />
- Create some usage videos, showing off the cool features: wizards, auto-complete, macro navigation<br />
- Create multiple step-by-step readme documents for different wizards<br />
<br />
== Automatic/headless building ==<br />
Currently the plugin and it's update site is built "in-house". That means you have to pop eclipse, clear current version, and run the build again. There should be a way of automatic - without the need for eclipse - building the plugin's update site & creating the standalone build also. <br />
<br />
== Other ideas ==<br />
You can also give other ideas you think are worthy to be implemented.<br />
<br />
= Whom to ask about this =<br />
If you want more information regarding the plugin please contact timotei/timotei21 on IRC.<br />
The mentor of the last gsoc eclipse plugin project was fendrin on IRC.</div>Fabihttps://wiki.wesnoth.org/index.php?title=SoC_Information_for_Google&diff=40730SoC Information for Google2011-03-09T22:37:25Z<p>Fabi: /* What criteria did you use to select the individuals who will act as mentors for your organization? Please be as specific as possible. */</p>
<hr />
<div>{{Template:SoC2011}}<br />
<br />
== SoC Information for Google ==<br />
This is the info that we submit to google as Application in Summer of Code (current status: 2010). The submitter automatically becomes primary Admin. Most entries are mandatory and have to be filled out before the application can be submitted.<br />
<br />
==== Organization Name: ====<br />
Battle for Wesnoth<br />
<br />
==== Description: ====<br />
''Battle for Wesnoth'', or simply ''Wesnoth'', is a free, turn-based strategy game with role-playing elements that was designed in June 2003 by David White (Sirp).<br />
<br />
Although the core rules are fairly simple and meant to be easily learned[1], they provide interesting gameplay and rich tactical options. A major strength of the project is the Wesnoth Markup Language (WML) for writing scenarios. Programming skills are not required to compose with it, and a large WML-modding community has generated a great deal of user-maintained content. We polish the best of this content and lift it into our official release tree.<br />
<br />
The first stable release (1.0) was on October 2, 2005, and the latest stable release (1.8) happened in april 2010. Version 1.8 is a major stable checkpoint, and 1.10 is not anticipated before the end of 2011. The currentdevelopment cycle (1.9, leading to 1.10) will premier significant changes in gameplay, UI, and development tools, with many new concepts being introduced. That makes this year probably one of the best years for a SoC student to join, since the open-ended 1.9 will mean much more space to develop novel ideas<br />
<br />
''Wesnoth'' is one of the most successful open-source game projects in existence, with an exceptionally large developer base and user community:<br />
<br />
* According to Ohloh, a site that collects activity statistics on open-source projects, the ''Wesnoth'' development effort is in the top 2% of largest and most active projects.<br />
* We support two multiplayer game servers (stable and development) with a usual minimum load of more than a hundred players.<br />
* More than two thousands downloads a day<br />
* 4.5 million downloads via SourceForge; many more via various mirrors of Linux distributions<br />
* Best rated game at the Linux Game Tome[2]<br />
* Game of the year 2007, 2008, 2009, and 2010 at LinuxQuestions.org[3][4]<br />
* In general, ''Wesnoth'' tends to show up in the first or second position whenever anyone compiles a list of top open-source games.<br />
<br />
''Wesnoth'''s most notable features include:<br />
<br />
* A mature project with continuing active development and frequent improvements<br />
* High quality artwork: both original graphics and music<br />
* Well-balanced by a tireless team of playtesters<br />
* Fun, unique gameplay<br />
* Even after six years of development and with a very solid, fun product already created, there are still plenty of new developers; the number of commits to Subversion is still increasing<br />
* Strong support of internationalization with many supported languages, thus experience in working with non-native English speakers. In fact, more than half of our developers are not native English speakers.<br />
<br />
[1] http://www.wesnoth.org/wiki/WesnothPhilosophy<br />
<br />
[2] http://www.happypenguin.org/list?sort=avg_rating<br />
<br />
[3] http://www.linuxquestions.org/questions/linux-news-59/2009-linuxquestions.org-members-choice-award-winners-788028/<br />
<br />
[4] http://www.linuxquestions.org/questions/2010-linuxquestions-org-members-choice-awards-93/open-source-game-of-the-year-855937/<br />
<br />
==== Home page: ====<br />
http://www.wesnoth.org/<br />
<br />
==== Main Organization License: ====<br />
GNU General Public License version 2.0 (GPLv2) [Dropdown box answer!]<br />
<br />
==== Why is your organization applying to participate in GSoC 2011? What do you hope to gain by participating? ====<br />
Most of our developers have particular areas of interest in which they work. Though they are efficient in their areas, there are other, presently uncovered, areas of the code with a need for improvements but a high barrier to entry for casual contributors.<br />
<br />
Our previous SoC experience shows that a motivated, full-time, student can be brought up to date in any area fairly quickly.<br />
<br />
By bringing new people in and allowing them to be actively responsible for an area of code, we hope to kickstart some areas of the project that are currently lagging behind.<br />
<br />
Moreover, our previous experiences has shown us that SoC developers tend to stay after the end of the Summer of Code and become valuable members of our community. This has been a win in all directions and we want it to happen again.<br />
<br />
==== If accepted, would this be your first year participating in GSoC? ====<br />
No<br />
<br />
==== Did your organization participate in past GSoCs? If so, please summarize your involvement and the successes and challenges of your participation. ====<br />
2008 results:<br />
Wesnoth participated in GSoC 2008 with four students. Out of these, two were great successes (that is they became full-fledge developers before the actual start of GSoC), did huge improvement during GSoC (A new recruitment algorithm for the AI and the basic structure for a new map editor, the student finished this work after the summer), and are still active developers in the Wesnoth community.<br />
<br />
Of the two other, one of them was very active for the first half of GSoC and provided some useful infrastructure for AI development that we used as base in GSoC 2009, but was much less active and didn't reach expectations for the second half of GSoC. The lesson we learned is that great students should be left on their own, that's the best way to have them work, but average students should be monitored much more closely than we did. If things seems to start to go wrong, it's important to react very quick, to meet with other mentors and get things back on track early.<br />
<br />
Timezone problems were also a serious barrier for student/mentor communication, and we will take that more into account when pairing mentors and students<br />
<br />
For our other students, multiple problems collectively led to failure<br />
* We should enforce IRC communication, E-mail is a barrier. This applies both for students and mentors. Both should be on IRC several hours a day, with overlapping hours.<br />
* We should be more strict about mid-term evaluation. If the student is slightly lacking at mid-term we should give a clear message that he needs to get back on track.<br />
<br />
<br />
2009 results:<br />
In 2009 we mentored 6 students as part of Summer of Code. Out of these 5 projects were a success. From those 5 developers 3 are still part of our core development group and still maintain and improve the work they submitted as part of Summer of Code. One of the students even became the "head" of our AI development department and mentored a student this year. For a summary of the 2009 results have a look at [1].<br />
<br />
Sadly one student was not able to continue his work past midterm due to his computer failing completely as well as personal problems that we won't delve into further here. It was not a salvageable situation.<br />
<br />
2010 results:<br />
In 2010 we mentored 4 students as part of Summer of Code, all the projects were a success. from those 4 developers, 1 is still part of our code development team and maintains the work he has done as part of Summer of Code.<br />
<br />
[1] http://forums.wesnoth.org/viewtopic.php?f=5&t=26955<br />
<br />
==== If your organization participated in past GSoCs, please let us know the ratio of students passing to students allocated, e.g. 2006: 3/6 for 3 out of 6 students passed in 2006. ====<br />
2008: 2/4<br />
2009: 5/6<br />
2010: 4/4<br />
<br />
==== What is the URL for your ideas page? ====<br />
http://wiki.wesnoth.org/SummerOfCodeIdeas<br />
<br />
==== What is the main development mailing list for your organization? This question will be shown to students who would like to get more information about applying to your organization for GSoC 2011. If your organization uses more than one list, please make sure to include a description of the list so students know which to use. ====<br />
The main development mailing list is "wesnoth-dev@gna.org". Our main means of communications is our IRC channel on freenode. If you have questions you should ask them in #wesnoth-dev on irc.freenode.net and wait for a reply (might take some hours!). The Wesnoth related channels are logged in public and the logs tend to be read by developers.<br />
<br />
==== What is the main IRC channel for your organization? ====<br />
#wesnoth-dev on irc.freenode.net<br />
<br />
==== Does your organization have an application template you would like to see students use? If so, please provide it now. Please note that it is a very good idea to ask students to provide you with their contact information as part of your template. Their contact details will not be shared with you automatically via the GSoC 2011 site. ====<br />
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. So please beside just answering these questions consider visiting us in IRC: #wesnoth-dev on irc.freenode.net. This is where most of our work takes place and participating in IRC is mandatory for GSoC students participating with Wesnoth. Our experience is that this is the easiest way to communicate and solve problems that come up.<br />
<br />
If you want to participate in GSoC as a student please copy http://wiki.wesnoth.org/SoC2011_Template_of_Student_page to a new page and fill it with the answers to the following questions<br />
<br />
Again, participating on IRC will be highly considered, you should not hesitate to ask any questions there, including how to fill a good proposal. We highly value your capacity to communicate and work in a team, so help other students, actively ask for proposal criticism, this can only help your proposal<br />
<br />
1) Basics<br />
<br />
1.1) Write a small introduction to yourself.<br />
<br />
1.2) State your preferred email address.<br />
<br />
1.3) If you have chosen a nick for IRC and Wesnoth forums, what is it?<br />
<br />
1.4) Why do you want to participate in summer of code?<br />
<br />
1.5) What are you studying, subject, level and school? <br />
<br />
1.6) What country are you from, at what time are you most likely to be able to join IRC?<br />
<br />
1.7) Do you have other commitments for the summer period ? Do you plan to take any vacations ? If yes, when.<br />
<br />
<br />
2) Experience<br />
<br />
2.1) What programs/software have you worked on before?<br />
<br />
2.2) Have you developed software in a team environment before? (As opposed to hacking on something on your own)<br />
<br />
2.3) Have you participated to the Google Summer of Code before? As a mentor or a student? In what project? Were you successful? If not, why?<br />
<br />
2.4) Are you already involved with any open source development projects? If yes, please describe the project and the scope of your involvement.<br />
<br />
2.5) Gaming experience - Are you a gamer?<br />
<br />
2.5.1) What type of gamer are you?<br />
<br />
2.5.2) What type of games? <br />
<br />
2.5.3) What type of opponents do you prefer? <br />
<br />
2.5.4) Are you more interested in story or gameplay?<br />
<br />
2.5.5) Have you played Wesnoth? If so, tell us roughly for how long and whether you lean towards single player or multiplayer.<br />
<br />
We do not plan to favor Wesnoth players as such, but some particular projects require a good feeling for the game which is hard to get without having played intensively.<br />
<br />
2.6) If you have contributed any patches to Wesnoth, please list them below. You can also list patches that have been submitted but not committed yet and patches that have not been specifically written for GSoC. If you have gained commit access to our SVN (during the evaluation period or earlier) please state so.<br />
<br />
<br />
3) Communication skills<br />
<br />
3.1) Though most of our developers are not native English speakers, English is the project's working language. Describe your fluency level in written English.<br />
<br />
3.2) What spoken languages are you fluent in?<br />
<br />
<br />
3.3) Are you good at interacting with other players? Our developer community is friendly, but the player community can be a bit rough.<br />
<br />
3.4) Do you give constructive advice? <br />
<br />
3.5) Do you receive advice well? <br />
<br />
3.6) Are you good at sorting useful criticisms from useless ones?<br />
<br />
3.7) How autonomous are you when developing ? Would you rather discuss intensively changes and not start coding until you know what you want to do or would you rather code a proof of concept to "see how it turn out", taking the risk of having it thrown away if it doesn't match what the project want<br />
<br />
<br />
4) Project<br />
<br />
4.1) Did you select a project from our list? If that is the case, what project did you select? What do you want to especially concentrate on?<br />
<br />
4.2) If you have invented your own project, please describe the project and the scope.<br />
<br />
4.3) Why did you choose this project?<br />
<br />
4.4) Include an estimated timeline for your work on the project. Don't forget to mention special things like "I booked holidays between A and B" and "I got an exam at ABC and won't be doing much then".<br />
<br />
4.5) Include as much technical detail about your implementation as you can<br />
<br />
4.6) What do you expect to gain from this project?<br />
<br />
4.7) What would make you stay in the Wesnoth community after the conclusion of SOC? <br />
<br />
<br />
5) Practical considerations<br />
<br />
5.1) Are you familiar with any of the following tools or languages?<br />
* Subversion (used for all commits)<br />
* C++ (language used for all the normal source code)<br />
* STL, Boost, Sdl (C++ libraries used by Wesnoth)<br />
* Python (optional, mainly used for tools)<br />
* build environments (eg cmake/autotools/scons)<br />
* WML (the wesnoth specific scenario language)<br />
* Lua (used in combination with WML to create scenarios)<br />
<br />
5.2) Which tools do you normally use for development? Why do you use them?<br />
<br />
5.3) What programming languages are you fluent in?<br />
<br />
5.4) Would you mind talking with your mentor on telephone / internet phone? We would like to have a backup way for communications for the case that somehow emails and IRC do fail. If you are willing to do so, please do list a phone number (including international code) so that we are able to contact you. You should probably *only* add this number in the application for you submit to google since the info in the wiki is available in public. We will *not* make any use of your number unless some case of "there is no way to contact you" does arise!<br />
<br />
<br />
In general please try to be as verbose as possible in your answers and feel free to elaborate.<br />
<br />
==== What criteria did you use to select the individuals who will act as mentors for your organization? Please be as specific as possible. ====<br />
Our first criterion was that all the people had to be volunteers. According to other open source projects and our experience from the last two years, being a SoC mentor takes a lot of time and the person has to be ready to spend quite some time with the student.<br />
<br />
Boucman is one of the oldest active developers around. He has rewritten the whole animation engine and made it an easily pluggable system allowing artists to easily specify exactly how they want the units to appear. He also started many community oriented projects like the Art Contribution[1] section of the wiki (now deprecated) and the WML Reference Manual[2]. He is responsible for dispatching and sorting the patches at http://patches.wesnoth.org that has created the new developer process we currently use. Boucman was a mentor in 2008, 2009 and 2010.<br />
<br />
Iurii Chernyi (Crab) has joined the team in 2009, taking part in Google Summer of Code 2009, and staying with the project as a developer after successful completion of GSoC. He's an expert on all aspects of current Wesnoth AI codebase (having fully reorganized it as part of GSoC 2009), and has fixed numerous bugs all over Wesnoth. He was a GSoC mentor and a GCI mentor and administrator in 2010. He is experienced in teaching other people, in areas like programming languages and math.<br />
<br />
Fendrin has some skills on both ends of the Wesnoth world, knowing parts of the c++ engine and how to use the Wesnoth markup language. He is the coder and maintainer of Wesnoth's first multiplayer campaign that is hosted in the mainline repository. His experience as a content developer ensures that there is an eye kept on the usability of those new features which are accessible to content designers. Fendrin was a mentor in 2010. <br />
<br />
Mordante is one of the most active developers on our IRC channel. Not only has he done preliminary studies and coding in multiple areas that are candidates for Summer of Code ideas, he also is one of the coders with the best overview of the Wesnoth code. A large part of his work involves refactoring and polishing existing code. Next to that he's very active with fixing bugs which leads him to all areas in the code base. He is currently completing a rewrite of the Wesnoth GUI library, making all windows configurable through WML. This should make it easier to use Wesnoth on different resolutions, from small handheld devices to large 30 inch screens. Mordante was a mentor in 2008, 2009 and 2010.<br />
<br />
All other developers listed in the ideas page are the leading capacities we do have for the respecting areas. Have a look at our list of "people who to contact" [3] for an easy reference. In general all our developers will mentor all students. That is, questions should just be asked in our IRC channel, where basically every developer who has an idea can and will directly answer.<br />
<br />
When choosing the mentors, we have kept in mind that most developers can answer most technical questions, and we have chosen people that are well known for interacting with new-comers/external developers and can provide general guidance and design advice, more than people with specific technical knowledge.<br />
<br />
[1] http://wiki.wesnoth.org/UnsortedContrib<br />
<br />
[2] http://wiki.wesnoth.org/ReferenceWML<br />
<br />
[3] http://wiki.wesnoth.org/SoC_People_to_bug_on_IRC<br />
<br />
==== What is your plan for dealing with disappearing students? ====<br />
The first thing to do is to avoid this situation altogether. <br />
<br />
Wesnoth is a game, and as such has lots of developers that are not coders. In particular, artists are well known in the Wesnoth community for being very sensitive about criticism and our community is used to people being sensitive to critics. <br />
<br />
We will try to choose students that accept criticism and are able to filter constructive criticism from useless one. The Wesnoth developer community is used to judging people according to these criteria and the special title we are going to give to applicants will allow us to easily spot any such problems and discuss them before they grow out of control.<br />
<br />
If a student disappears, their mentor will be in charge of recontacting the student to see what is going wrong (available time, tension with other developers, with members of the community etc...). Depending on the actual problem, the mentor and the student will have to agree on possible ways to defuse the problem.<br />
<br />
If a student disappears completely and there is no way to get back to them, there is little the project can do except salvaging whatever can be salvaged from the code (the students will have SVN write access, so most of the work will be committed either to trunk or to a specific branch) and find a core developer to take on the job. This will probably be slower and less effective for the project, but it's the best we can do.<br />
<br />
==== What is your plan for dealing with disappearing mentors? ====<br />
All our mentors are long time developers that volunteered for the job, so we don't expect that to happen. We observed in during the last years the amount of time required to mentor, and our mentors accepted the job knowing the amount of work it involved. All of this years mentors mentored last year as well.<br />
<br />
However, should it happen, we would continue to mentor as a developer community the student until we find a new "official" mentor to take on the job.<br />
<br />
==== What steps will you take to encourage students to interact with your project's community before, during and after the program? ====<br />
Wesnoth has a particularly healthy community, both for developers and for players. <br />
<br />
Our general policy regarding new coders has always been "two (non trival) patches... you're in". With other words, anybody that is able to get two non-trivial patches applied is offered commit privileges.<br />
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 [1] (these projects are usually a couple of hours long and hve been chosen to provide easy access to the respective area of code). This year, we also have added some simple coding tasks directly related to our GSoC ideas to be able to test students more specifically on their future project<br />
<br />
Usually, patches go back and forth a couple of times, to make sure that all secondary things are in place (indenting, coding style, modified buildfiles 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 keep our project alive.<br />
<br />
If the student is proactive and ready to join IRC, all the developers are usually very welcoming, and good at directing newcomers to quickly give useful results.<br />
<br />
In 2008, 2009 and 2010 all students that were accepted (and a couple more) managed to have commit access before the start of the coding phase. We consider that this policy was successful and we plan to keep it this year.<br />
<br />
We also plan to give a special forum title to any students. This will allow all forum members to tell them apart from normal users and give them read/write access to the developer only forums. This will also allow us to quickly spot any problem they might have interacting with the player community. We have a very mature developer community, but our player community is made of all sort of people of all age and education, and it can sometimes be rough.<br />
<br />
Last, our experience from previous years is that students that participate in the community during the evaluation period will stay active in the community after that period. In previous years this has been a discriminating criterias for students of similar level, and overall we never had problems of students working "behind a black wall." Our selection process tend to favor students who participate, and participation hasn't been a problem so far.<br />
<br />
[1] http://wiki.wesnoth.org/EasyCoding<br />
<br />
==== If you are a small or new organization applying to GSoC, please list a larger, established GSoC organization or a Googler that can vouch for you here. ====<br />
<br />
==== If you are a large organization who is vouching for a small organization applying to GSoC for their first time this year, please list their name and why you think they'd be good candidates for GSoC here: ====<br />
* Darktable:<br />
Darktable (see http://darktable.sourceforge.net/ and https://sourceforge.net/apps/trac/darktable/wiki/GSOC) is an open source raw development tool.<br />
<br />
There are currently no major open source raw development tools. Multiple tools cover the need (ufraw, rawtherapee etc...) but most of them are targeting technical users with interest in photography or signal processing experts rather than "normal" photographer. <br />
<br />
Darktable has a very good UI designed around what most photographers expects. It is also a project which is at this interesting stage where there is a solid infrastructure and it needs developer to do the fun part of adding new feature. This is the stage of a project which is the most interesting for developers to join.<br />
<br />
The Darktable development community is rather small (3 active developers plus occasional contributors). It could use the extra manpower but is large enough to mentor a student into a core developer pretty fast. <br />
<br />
Chances of a student finding it interesting are high, chances of the student bringing major contributions to the project are very high<br />
<br />
One of the experienced wesnoth mentor (boucman) is an active member of the Darktable community and has been spearheading the GSoC effort for that community and will offer advice and participation for the new mentors in that community. Wesnoth has had a dedicated IRC channel for mentor discussion which could be used by smaller projects for advice if the need arise<br />
<br />
* Unknown Horizons:<br />
Unknown Horizons (http://www.unknown-horizons.org/) is a 2D realtime strategy simulation with an emphasis on economy and city building. <br />
<br />
This is a smaller open source game project with a really dedicated core team of developers. During our talks with the dev who wants to work as admin it was easy to see that they do think about what they do and got some well working infrastructure. Even though the team is rather small at the moment, they are well suited to handle some students and the project has a proven record of being able to actually release something and continue working on the code. Beside their abilities it is always good to support open source gaming, especially when it comes to rather underrepresented areas like real time strategy games.<br />
<br />
==== Anything else you'd like to tell us? ====<br />
There is nothing more to say.<br />
<br />
==== Backup Admin (Link ID): ====<br />
noy<br />
<br />
==== Admin Agreement: ====<br />
(some terms of service by Google that have to be agreed upon)</div>Fabihttps://wiki.wesnoth.org/index.php?title=SoC_Information_for_Google&diff=40729SoC Information for Google2011-03-09T22:17:06Z<p>Fabi: /* What criteria did you use to select the individuals who will act as mentors for your organization? Please be as specific as possible. */</p>
<hr />
<div>{{Template:SoC2011}}<br />
<br />
== SoC Information for Google ==<br />
This is the info that we submit to google as Application in Summer of Code (current status: 2010). The submitter automatically becomes primary Admin. Most entries are mandatory and have to be filled out before the application can be submitted.<br />
<br />
==== Organization Name: ====<br />
Battle for Wesnoth<br />
<br />
==== Description: ====<br />
''Battle for Wesnoth'', or simply ''Wesnoth'', is a free, turn-based strategy game with role-playing elements that was designed in June 2003 by David White (Sirp).<br />
<br />
Although the core rules are fairly simple and meant to be easily learned[1], they provide interesting gameplay and rich tactical options. A major strength of the project is the Wesnoth Markup Language (WML) for writing scenarios. Programming skills are not required to compose with it, and a large WML-modding community has generated a great deal of user-maintained content. We polish the best of this content and lift it into our official release tree.<br />
<br />
The first stable release (1.0) was on October 2, 2005, and the latest stable release (1.8) happened in april 2010. Version 1.8 is a major stable checkpoint, and 1.10 is not anticipated before the end of 2011. The currentdevelopment cycle (1.9, leading to 1.10) will premier significant changes in gameplay, UI, and development tools, with many new concepts being introduced. That makes this year probably one of the best years for a SoC student to join, since the open-ended 1.9 will mean much more space to develop novel ideas<br />
<br />
''Wesnoth'' is one of the most successful open-source game projects in existence, with an exceptionally large developer base and user community:<br />
<br />
* According to Ohloh, a site that collects activity statistics on open-source projects, the ''Wesnoth'' development effort is in the top 2% of largest and most active projects.<br />
* We support two multiplayer game servers (stable and development) with a usual minimum load of more than a hundred players.<br />
* More than two thousands downloads a day<br />
* 4.5 million downloads via SourceForge; many more via various mirrors of Linux distributions<br />
* Best rated game at the Linux Game Tome[2]<br />
* Game of the year 2007, 2008, 2009, and 2010 at LinuxQuestions.org[3][4]<br />
* In general, ''Wesnoth'' tends to show up in the first or second position whenever anyone compiles a list of top open-source games.<br />
<br />
''Wesnoth'''s most notable features include:<br />
<br />
* A mature project with continuing active development and frequent improvements<br />
* High quality artwork: both original graphics and music<br />
* Well-balanced by a tireless team of playtesters<br />
* Fun, unique gameplay<br />
* Even after six years of development and with a very solid, fun product already created, there are still plenty of new developers; the number of commits to Subversion is still increasing<br />
* Strong support of internationalization with many supported languages, thus experience in working with non-native English speakers. In fact, more than half of our developers are not native English speakers.<br />
<br />
[1] http://www.wesnoth.org/wiki/WesnothPhilosophy<br />
<br />
[2] http://www.happypenguin.org/list?sort=avg_rating<br />
<br />
[3] http://www.linuxquestions.org/questions/linux-news-59/2009-linuxquestions.org-members-choice-award-winners-788028/<br />
<br />
[4] http://www.linuxquestions.org/questions/2010-linuxquestions-org-members-choice-awards-93/open-source-game-of-the-year-855937/<br />
<br />
==== Home page: ====<br />
http://www.wesnoth.org/<br />
<br />
==== Main Organization License: ====<br />
GNU General Public License version 2.0 (GPLv2) [Dropdown box answer!]<br />
<br />
==== Why is your organization applying to participate in GSoC 2011? What do you hope to gain by participating? ====<br />
Most of our developers have particular areas of interest in which they work. Though they are efficient in their areas, there are other, presently uncovered, areas of the code with a need for improvements but a high barrier to entry for casual contributors.<br />
<br />
Our previous SoC experience shows that a motivated, full-time, student can be brought up to date in any area fairly quickly.<br />
<br />
By bringing new people in and allowing them to be actively responsible for an area of code, we hope to kickstart some areas of the project that are currently lagging behind.<br />
<br />
Moreover, our previous experiences has shown us that SoC developers tend to stay after the end of the Summer of Code and become valuable members of our community. This has been a win in all directions and we want it to happen again.<br />
<br />
==== If accepted, would this be your first year participating in GSoC? ====<br />
No<br />
<br />
==== Did your organization participate in past GSoCs? If so, please summarize your involvement and the successes and challenges of your participation. ====<br />
2008 results:<br />
Wesnoth participated in GSoC 2008 with four students. Out of these, two were great successes (that is they became full-fledge developers before the actual start of GSoC), did huge improvement during GSoC (A new recruitment algorithm for the AI and the basic structure for a new map editor, the student finished this work after the summer), and are still active developers in the Wesnoth community.<br />
<br />
Of the two other, one of them was very active for the first half of GSoC and provided some useful infrastructure for AI development that we used as base in GSoC 2009, but was much less active and didn't reach expectations for the second half of GSoC. The lesson we learned is that great students should be left on their own, that's the best way to have them work, but average students should be monitored much more closely than we did. If things seems to start to go wrong, it's important to react very quick, to meet with other mentors and get things back on track early.<br />
<br />
Timezone problems were also a serious barrier for student/mentor communication, and we will take that more into account when pairing mentors and students<br />
<br />
For our other students, multiple problems collectively led to failure<br />
* We should enforce IRC communication, E-mail is a barrier. This applies both for students and mentors. Both should be on IRC several hours a day, with overlapping hours.<br />
* We should be more strict about mid-term evaluation. If the student is slightly lacking at mid-term we should give a clear message that he needs to get back on track.<br />
<br />
<br />
2009 results:<br />
In 2009 we mentored 6 students as part of Summer of Code. Out of these 5 projects were a success. From those 5 developers 3 are still part of our core development group and still maintain and improve the work they submitted as part of Summer of Code. One of the students even became the "head" of our AI development department and mentored a student this year. For a summary of the 2009 results have a look at [1].<br />
<br />
Sadly one student was not able to continue his work past midterm due to his computer failing completely as well as personal problems that we won't delve into further here. It was not a salvageable situation.<br />
<br />
2010 results:<br />
In 2010 we mentored 4 students as part of Summer of Code, all the projects were a success. from those 4 developers, 1 is still part of our code development team and maintains the work he has done as part of Summer of Code.<br />
<br />
[1] http://forums.wesnoth.org/viewtopic.php?f=5&t=26955<br />
<br />
==== If your organization participated in past GSoCs, please let us know the ratio of students passing to students allocated, e.g. 2006: 3/6 for 3 out of 6 students passed in 2006. ====<br />
2008: 2/4<br />
2009: 5/6<br />
2010: 4/4<br />
<br />
==== What is the URL for your ideas page? ====<br />
http://wiki.wesnoth.org/SummerOfCodeIdeas<br />
<br />
==== What is the main development mailing list for your organization? This question will be shown to students who would like to get more information about applying to your organization for GSoC 2011. If your organization uses more than one list, please make sure to include a description of the list so students know which to use. ====<br />
The main development mailing list is "wesnoth-dev@gna.org". Our main means of communications is our IRC channel on freenode. If you have questions you should ask them in #wesnoth-dev on irc.freenode.net and wait for a reply (might take some hours!). The Wesnoth related channels are logged in public and the logs tend to be read by developers.<br />
<br />
==== What is the main IRC channel for your organization? ====<br />
#wesnoth-dev on irc.freenode.net<br />
<br />
==== Does your organization have an application template you would like to see students use? If so, please provide it now. Please note that it is a very good idea to ask students to provide you with their contact information as part of your template. Their contact details will not be shared with you automatically via the GSoC 2011 site. ====<br />
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. So please beside just answering these questions consider visiting us in IRC: #wesnoth-dev on irc.freenode.net. This is where most of our work takes place and participating in IRC is mandatory for GSoC students participating with Wesnoth. Our experience is that this is the easiest way to communicate and solve problems that come up.<br />
<br />
If you want to participate in GSoC as a student please copy http://wiki.wesnoth.org/SoC2011_Template_of_Student_page to a new page and fill it with the answers to the following questions<br />
<br />
Again, participating on IRC will be highly considered, you should not hesitate to ask any questions there, including how to fill a good proposal. We highly value your capacity to communicate and work in a team, so help other students, actively ask for proposal criticism, this can only help your proposal<br />
<br />
1) Basics<br />
<br />
1.1) Write a small introduction to yourself.<br />
<br />
1.2) State your preferred email address.<br />
<br />
1.3) If you have chosen a nick for IRC and Wesnoth forums, what is it?<br />
<br />
1.4) Why do you want to participate in summer of code?<br />
<br />
1.5) What are you studying, subject, level and school? <br />
<br />
1.6) What country are you from, at what time are you most likely to be able to join IRC?<br />
<br />
1.7) Do you have other commitments for the summer period ? Do you plan to take any vacations ? If yes, when.<br />
<br />
<br />
2) Experience<br />
<br />
2.1) What programs/software have you worked on before?<br />
<br />
2.2) Have you developed software in a team environment before? (As opposed to hacking on something on your own)<br />
<br />
2.3) Have you participated to the Google Summer of Code before? As a mentor or a student? In what project? Were you successful? If not, why?<br />
<br />
2.4) Are you already involved with any open source development projects? If yes, please describe the project and the scope of your involvement.<br />
<br />
2.5) Gaming experience - Are you a gamer?<br />
<br />
2.5.1) What type of gamer are you?<br />
<br />
2.5.2) What type of games? <br />
<br />
2.5.3) What type of opponents do you prefer? <br />
<br />
2.5.4) Are you more interested in story or gameplay?<br />
<br />
2.5.5) Have you played Wesnoth? If so, tell us roughly for how long and whether you lean towards single player or multiplayer.<br />
<br />
We do not plan to favor Wesnoth players as such, but some particular projects require a good feeling for the game which is hard to get without having played intensively.<br />
<br />
2.6) If you have contributed any patches to Wesnoth, please list them below. You can also list patches that have been submitted but not committed yet and patches that have not been specifically written for GSoC. If you have gained commit access to our SVN (during the evaluation period or earlier) please state so.<br />
<br />
<br />
3) Communication skills<br />
<br />
3.1) Though most of our developers are not native English speakers, English is the project's working language. Describe your fluency level in written English.<br />
<br />
3.2) What spoken languages are you fluent in?<br />
<br />
<br />
3.3) Are you good at interacting with other players? Our developer community is friendly, but the player community can be a bit rough.<br />
<br />
3.4) Do you give constructive advice? <br />
<br />
3.5) Do you receive advice well? <br />
<br />
3.6) Are you good at sorting useful criticisms from useless ones?<br />
<br />
3.7) How autonomous are you when developing ? Would you rather discuss intensively changes and not start coding until you know what you want to do or would you rather code a proof of concept to "see how it turn out", taking the risk of having it thrown away if it doesn't match what the project want<br />
<br />
<br />
4) Project<br />
<br />
4.1) Did you select a project from our list? If that is the case, what project did you select? What do you want to especially concentrate on?<br />
<br />
4.2) If you have invented your own project, please describe the project and the scope.<br />
<br />
4.3) Why did you choose this project?<br />
<br />
4.4) Include an estimated timeline for your work on the project. Don't forget to mention special things like "I booked holidays between A and B" and "I got an exam at ABC and won't be doing much then".<br />
<br />
4.5) Include as much technical detail about your implementation as you can<br />
<br />
4.6) What do you expect to gain from this project?<br />
<br />
4.7) What would make you stay in the Wesnoth community after the conclusion of SOC? <br />
<br />
<br />
5) Practical considerations<br />
<br />
5.1) Are you familiar with any of the following tools or languages?<br />
* Subversion (used for all commits)<br />
* C++ (language used for all the normal source code)<br />
* STL, Boost, Sdl (C++ libraries used by Wesnoth)<br />
* Python (optional, mainly used for tools)<br />
* build environments (eg cmake/autotools/scons)<br />
* WML (the wesnoth specific scenario language)<br />
* Lua (used in combination with WML to create scenarios)<br />
<br />
5.2) Which tools do you normally use for development? Why do you use them?<br />
<br />
5.3) What programming languages are you fluent in?<br />
<br />
5.4) Would you mind talking with your mentor on telephone / internet phone? We would like to have a backup way for communications for the case that somehow emails and IRC do fail. If you are willing to do so, please do list a phone number (including international code) so that we are able to contact you. You should probably *only* add this number in the application for you submit to google since the info in the wiki is available in public. We will *not* make any use of your number unless some case of "there is no way to contact you" does arise!<br />
<br />
<br />
In general please try to be as verbose as possible in your answers and feel free to elaborate.<br />
<br />
==== What criteria did you use to select the individuals who will act as mentors for your organization? Please be as specific as possible. ====<br />
Our first criterion was that all the people had to be volunteers. According to other open source projects and our experience from the last two years, being a SoC mentor takes a lot of time and the person has to be ready to spend quite some time with the student.<br />
<br />
Boucman is one of the oldest active developers around. He has rewritten the whole animation engine and made it an easily pluggable system allowing artists to easily specify exactly how they want the units to appear. He also started many community oriented projects like the Art Contribution[1] section of the wiki (now deprecated) and the WML Reference Manual[2]. He is responsible for dispatching and sorting the patches at http://patches.wesnoth.org that has created the new developer process we currently use. Boucman was a mentor in 2008, 2009 and 2010.<br />
<br />
Iurii Chernyi (Crab) has joined the team in 2009, taking part in Google Summer of Code 2009, and staying with the project as a developer after successful completion of GSoC. He's an expert on all aspects of current Wesnoth AI codebase (having fully reorganized it as part of GSoC 2009), and has fixed numerous bugs all over Wesnoth. He was a GSoC mentor and a GCI mentor and administrator in 2010. He is experienced in teaching other people, in areas like programming languages and math.<br />
<br />
Fendrin has some skills on both ends of the Wesnoth world, knowing parts of the c++ engine and how to use the Wesnoth markup language. His experience as a content developer ensures that there is an eye kept on the usability of those new features which are accessible to content designers. Fendrin was a mentor in 2010. <br />
<br />
Mordante is one of the most active developers on our IRC channel. Not only has he done preliminary studies and coding in multiple areas that are candidates for Summer of Code ideas, he also is one of the coders with the best overview of the Wesnoth code. A large part of his work involves refactoring and polishing existing code. Next to that he's very active with fixing bugs which leads him to all areas in the code base. He is currently completing a rewrite of the Wesnoth GUI library, making all windows configurable through WML. This should make it easier to use Wesnoth on different resolutions, from small handheld devices to large 30 inch screens. Mordante was a mentor in 2008, 2009 and 2010.<br />
<br />
All other developers listed in the ideas page are the leading capacities we do have for the respecting areas. Have a look at our list of "people who to contact" [3] for an easy reference. In general all our developers will mentor all students. That is, questions should just be asked in our IRC channel, where basically every developer who has an idea can and will directly answer.<br />
<br />
When choosing the mentors, we have kept in mind that most developers can answer most technical questions, and we have chosen people that are well known for interacting with new-comers/external developers and can provide general guidance and design advice, more than people with specific technical knowledge.<br />
<br />
[1] http://wiki.wesnoth.org/UnsortedContrib<br />
<br />
[2] http://wiki.wesnoth.org/ReferenceWML<br />
<br />
[3] http://wiki.wesnoth.org/SoC_People_to_bug_on_IRC<br />
<br />
==== What is your plan for dealing with disappearing students? ====<br />
The first thing to do is to avoid this situation altogether. <br />
<br />
Wesnoth is a game, and as such has lots of developers that are not coders. In particular, artists are well known in the Wesnoth community for being very sensitive about criticism and our community is used to people being sensitive to critics. <br />
<br />
We will try to choose students that accept criticism and are able to filter constructive criticism from useless one. The Wesnoth developer community is used to judging people according to these criteria and the special title we are going to give to applicants will allow us to easily spot any such problems and discuss them before they grow out of control.<br />
<br />
If a student disappears, their mentor will be in charge of recontacting the student to see what is going wrong (available time, tension with other developers, with members of the community etc...). Depending on the actual problem, the mentor and the student will have to agree on possible ways to defuse the problem.<br />
<br />
If a student disappears completely and there is no way to get back to them, there is little the project can do except salvaging whatever can be salvaged from the code (the students will have SVN write access, so most of the work will be committed either to trunk or to a specific branch) and find a core developer to take on the job. This will probably be slower and less effective for the project, but it's the best we can do.<br />
<br />
==== What is your plan for dealing with disappearing mentors? ====<br />
All our mentors are long time developers that volunteered for the job, so we don't expect that to happen. We observed in during the last years the amount of time required to mentor, and our mentors accepted the job knowing the amount of work it involved. All of this years mentors mentored last year as well.<br />
<br />
However, should it happen, we would continue to mentor as a developer community the student until we find a new "official" mentor to take on the job.<br />
<br />
==== What steps will you take to encourage students to interact with your project's community before, during and after the program? ====<br />
Wesnoth has a particularly healthy community, both for developers and for players. <br />
<br />
Our general policy regarding new coders has always been "two (non trival) patches... you're in". With other words, anybody that is able to get two non-trivial patches applied is offered commit privileges.<br />
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 [1] (these projects are usually a couple of hours long and hve been chosen to provide easy access to the respective area of code). This year, we also have added some simple coding tasks directly related to our GSoC ideas to be able to test students more specifically on their future project<br />
<br />
Usually, patches go back and forth a couple of times, to make sure that all secondary things are in place (indenting, coding style, modified buildfiles 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 keep our project alive.<br />
<br />
If the student is proactive and ready to join IRC, all the developers are usually very welcoming, and good at directing newcomers to quickly give useful results.<br />
<br />
In 2008, 2009 and 2010 all students that were accepted (and a couple more) managed to have commit access before the start of the coding phase. We consider that this policy was successful and we plan to keep it this year.<br />
<br />
We also plan to give a special forum title to any students. This will allow all forum members to tell them apart from normal users and give them read/write access to the developer only forums. This will also allow us to quickly spot any problem they might have interacting with the player community. We have a very mature developer community, but our player community is made of all sort of people of all age and education, and it can sometimes be rough.<br />
<br />
Last, our experience from previous years is that students that participate in the community during the evaluation period will stay active in the community after that period. In previous years this has been a discriminating criterias for students of similar level, and overall we never had problems of students working "behind a black wall." Our selection process tend to favor students who participate, and participation hasn't been a problem so far.<br />
<br />
[1] http://wiki.wesnoth.org/EasyCoding<br />
<br />
==== If you are a small or new organization applying to GSoC, please list a larger, established GSoC organization or a Googler that can vouch for you here. ====<br />
<br />
==== If you are a large organization who is vouching for a small organization applying to GSoC for their first time this year, please list their name and why you think they'd be good candidates for GSoC here: ====<br />
* Darktable:<br />
Darktable (see http://darktable.sourceforge.net/ and https://sourceforge.net/apps/trac/darktable/wiki/GSOC) is an open source raw development tool.<br />
<br />
There are currently no major open source raw development tools. Multiple tools cover the need (ufraw, rawtherapee etc...) but most of them are targeting technical users with interest in photography or signal processing experts rather than "normal" photographer. <br />
<br />
Darktable has a very good UI designed around what most photographers expects. It is also a project which is at this interesting stage where there is a solid infrastructure and it needs developer to do the fun part of adding new feature. This is the stage of a project which is the most interesting for developers to join.<br />
<br />
The Darktable development community is rather small (3 active developers plus occasional contributors). It could use the extra manpower but is large enough to mentor a student into a core developer pretty fast. <br />
<br />
Chances of a student finding it interesting are high, chances of the student bringing major contributions to the project are very high<br />
<br />
One of the experienced wesnoth mentor (boucman) is an active member of the Darktable community and has been spearheading the GSoC effort for that community and will offer advice and participation for the new mentors in that community. Wesnoth has had a dedicated IRC channel for mentor discussion which could be used by smaller projects for advice if the need arise<br />
<br />
* Unknown Horizons:<br />
Unknown Horizons (http://www.unknown-horizons.org/) is a 2D realtime strategy simulation with an emphasis on economy and city building. <br />
<br />
This is a smaller open source game project with a really dedicated core team of developers. During our talks with the dev who wants to work as admin it was easy to see that they do think about what they do and got some well working infrastructure. Even though the team is rather small at the moment, they are well suited to handle some students and the project has a proven record of being able to actually release something and continue working on the code. Beside their abilities it is always good to support open source gaming, especially when it comes to rather underrepresented areas like real time strategy games.<br />
<br />
==== Anything else you'd like to tell us? ====<br />
There is nothing more to say.<br />
<br />
==== Backup Admin (Link ID): ====<br />
noy<br />
<br />
==== Admin Agreement: ====<br />
(some terms of service by Google that have to be agreed upon)</div>Fabihttps://wiki.wesnoth.org/index.php?title=SoC_Ideas_Multiplayer_Improvements_2011&diff=40706SoC Ideas Multiplayer Improvements 20112011-03-09T14:16:13Z<p>Fabi: /* Under the hood */</p>
<hr />
<div>{{SoC2011Idea}}<br />
<br />
<br />
=Description=<br />
<h2>Reengineer Wesnoth's multiplayer engine</h2><br />
<br />
More info at [[SoC_Ideas_Multiplayer_Improvements_2011]]<br />
<br />
<br />
Wesnoth includes a lot of multiplayer content, like 'standard' scenarios, custom scenarios and multiplayer campaigns. However, when creating a multiplayer game, the player's options are highly limited - for example, it is not possible to select the difficulty level before starting the scenario, and it is not possible to allow the scenario to set what 'variables' can be customized by players before game is started (there's only global 'use map settings' flag and some control over sides). We want to reengineer the architecture of Wesnoth's multiplayer engine to allow it to support those things.<br />
<br />
{{#dpl:<br />
|resultsheader=''There are %PAGES% submitted student proposals for this idea''<br />
|oneresultheader=''There is 1 submitted student proposal for this idea''<br />
|suppresserrors=true<br />
|noresultsheader=''There are no submitted student proposals for this idea''<br />
|category=Summer of Code 2011 Student Page&SoC Ideas Multiplayer Improvements<br />
|notcategory=SoC 2011 Not Submitted To Google<br />
|include=#Description<br />
|mode=userformat<br />
|format=,,<br/>See [[%PAGE%|%TITLE%]] for more information.<br/><br/>,<br />
}}<br />
<br />
=Additional Information=<br />
== Difficulty levels in MP ==<br />
Wesnoth includes a lot of text data config files which need to be 'parsed' before game starts. Difficulty needs to be known at the time we parse those config files. Currently, we parse those files before entering the multiplayer lobby. As a consequence, we cannot select difficulty in multiplayer game (data's already parsed at the point when the game is created). Note that parsing takes a lot of time, so, if we do it while already connected to MP server, we need to add workarounds to ensure it doesn't think the client is dead.<br />
<br />
== Game creation screen ==<br />
We want the multiplayer game creation screen to be different and better. We think that we need different screens for normal MP scenarios, 'custom' MP scenarios and for MP campaigns.<br />
<br />
== Unification of multiplayer and singleplayer in the engine==<br />
A really long-term goal would be to reduce the complexity of the codebase by merging SP and MP (making SP a special case of MP and allow seamless transition between both). There is a number of steps which could be taken to gradually move closer to this goal.<br />
<br />
== Under the hood ==<br />
Wesnoth uses a pre-processor to organise its file hierarchy and to make use of macros.<br />
This system is used to load only a certain subset of all available WML code depending on the current needs.<br />
<br />
A freshly started Wesnoth instance does neither know about the inners of single player campaigns nor multiplayer content.<br />
The player is able to choose between the mainline campaigns before the wml tree gets re-parsed because the [campaign] tag hosted in the campaign's _main.cfg contains all needed information and it's parsed from game start.<br />
<br />
But the engine does only read the _main.cfg when the whole directory was included by a pre-processor directive.<br />
If you allow me to show you some wml code you will discover that the rest of the campaign is guarded by a pre-processor symbol.<br />
<br />
From the _main.cfg of "Heir To The Throne":<br />
.<br />
.<br />
.<br />
[campaign]<br />
id=Heir_To_The_Throne<br />
.<br />
.<br />
.<br />
define=CAMPAIGN_HEIR_TO_THE_THRONE<br />
extra_defines=SOMETHING, ANYTHING # inserted as example<br />
.<br />
.<br />
.<br />
[/campaign]<br />
.<br />
.<br />
.<br />
#ifdef CAMPAIGN_HEIR_TO_THE_THRONE<br />
[binary_path]<br />
path=data/campaigns/Heir_To_The_Throne<br />
[/binary_path]<br />
[+units]<br />
{campaigns/Heir_To_The_Throne/units}<br />
[/units]<br />
<br />
{campaigns/Heir_To_The_Throne/utils}<br />
{campaigns/Heir_To_The_Throne/scenarios}<br />
#endif<br />
.<br />
.<br />
.<br />
If the player selects the campaign he will be asked for the difficult level of the campaign.<br />
After that the whole wmltree while be re-parsed, this time with the additional defines:<br />
CAMPAIGN_HEIR_TO_THE_THRONE<br />
one of EASY NORMAL HARD<br />
SOMETHING<br />
ANYTHING<br />
<br />
=Whom to ask about this=<br />
Ask Crab_ and/or fendrin on #wesnoth-dev<br />
<br />
=Possible pre-gsoc tasks=<br />
<br />
* Talk with devs, users, and MP devs about UI design of MP creation screens and show some prototypes of game creation screens for MP campaigns, and custom MP scenarios<br />
<br />
* Hack in a way to select difficulty before MP scenario start (doesn't need to be done cleanly, can be a prototype hack)<br />
<br />
* Add a new attribute to game creation screen, to allow each player to select a number from 1 to 100 and make it available to WML code as a variable after scenario starts. Bonus points if you allow host to see the variable in the game creation screen and allow him to change it and lock it down for any particular player.<br />
<br />
* write or download a small MP campaign and report on any MP campaign support bugs that you find.<br />
<br />
* implement a lobby command to make the player who issued that command host and start a game with specified parameters, bypassing side selection screen.<br />
<br />
* Make yourself familiar with the multiplayer port of the "Legend of Wesmere" campaign. Try to understand why and how the difficult setting is handled in it's case.</div>Fabihttps://wiki.wesnoth.org/index.php?title=SoC_Ideas_Multiplayer_Improvements_2011&diff=40705SoC Ideas Multiplayer Improvements 20112011-03-09T13:59:44Z<p>Fabi: /* Under the hood */</p>
<hr />
<div>{{SoC2011Idea}}<br />
<br />
<br />
=Description=<br />
<h2>Reengineer Wesnoth's multiplayer engine</h2><br />
<br />
More info at [[SoC_Ideas_Multiplayer_Improvements_2011]]<br />
<br />
<br />
Wesnoth includes a lot of multiplayer content, like 'standard' scenarios, custom scenarios and multiplayer campaigns. However, when creating a multiplayer game, the player's options are highly limited - for example, it is not possible to select the difficulty level before starting the scenario, and it is not possible to allow the scenario to set what 'variables' can be customized by players before game is started (there's only global 'use map settings' flag and some control over sides). We want to reengineer the architecture of Wesnoth's multiplayer engine to allow it to support those things.<br />
<br />
{{#dpl:<br />
|resultsheader=''There are %PAGES% submitted student proposals for this idea''<br />
|oneresultheader=''There is 1 submitted student proposal for this idea''<br />
|suppresserrors=true<br />
|noresultsheader=''There are no submitted student proposals for this idea''<br />
|category=Summer of Code 2011 Student Page&SoC Ideas Multiplayer Improvements<br />
|notcategory=SoC 2011 Not Submitted To Google<br />
|include=#Description<br />
|mode=userformat<br />
|format=,,<br/>See [[%PAGE%|%TITLE%]] for more information.<br/><br/>,<br />
}}<br />
<br />
=Additional Information=<br />
== Difficulty levels in MP ==<br />
Wesnoth includes a lot of text data config files which need to be 'parsed' before game starts. Difficulty needs to be known at the time we parse those config files. Currently, we parse those files before entering the multiplayer lobby. As a consequence, we cannot select difficulty in multiplayer game (data's already parsed at the point when the game is created). Note that parsing takes a lot of time, so, if we do it while already connected to MP server, we need to add workarounds to ensure it doesn't think the client is dead.<br />
<br />
== Game creation screen ==<br />
We want the multiplayer game creation screen to be different and better. We think that we need different screens for normal MP scenarios, 'custom' MP scenarios and for MP campaigns.<br />
<br />
== Unification of multiplayer and singleplayer in the engine==<br />
A really long-term goal would be to reduce the complexity of the codebase by merging SP and MP (making SP a special case of MP and allow seamless transition between both). There is a number of steps which could be taken to gradually move closer to this goal.<br />
<br />
== Under the hood ==<br />
Wesnoth uses a pre-processor to organise its file hierarchy and to make use of macros.<br />
This system is used to load only a certain subset of all available WML code depending on the current needs.<br />
<br />
A freshly started Wesnoth instance does neither know about the inners of single player campaigns nor multiplayer content.<br />
The player is able to choose between the mainline campaigns before the wml tree gets re-parsed because the [campaign] tag hosted in the campaign's _main.cfg contains all needed information and it's parsed from game start.<br />
<br />
But the engine does only read the _main.cfg when the whole directory was included by a pre-processor directive.<br />
If you allow me to show you some wml code you will discover that the rest of the campaign is guarded by a pre-processor symbol:<br />
<br />
.<br />
.<br />
.<br />
[campaign]<br />
id=Heir_To_The_Throne<br />
.<br />
.<br />
.<br />
define=CAMPAIGN_HEIR_TO_THE_THRONE<br />
.<br />
.<br />
.<br />
[/campaign]<br />
.<br />
.<br />
.<br />
#ifdef CAMPAIGN_HEIR_TO_THE_THRONE<br />
[binary_path]<br />
path=data/campaigns/Heir_To_The_Throne<br />
[/binary_path]<br />
[+units]<br />
{campaigns/Heir_To_The_Throne/units}<br />
[/units]<br />
<br />
{campaigns/Heir_To_The_Throne/utils}<br />
{campaigns/Heir_To_The_Throne/scenarios}<br />
#endif<br />
.<br />
.<br />
.<br />
<br />
=Whom to ask about this=<br />
Ask Crab_ and/or fendrin on #wesnoth-dev<br />
<br />
=Possible pre-gsoc tasks=<br />
<br />
* Talk with devs, users, and MP devs about UI design of MP creation screens and show some prototypes of game creation screens for MP campaigns, and custom MP scenarios<br />
<br />
* Hack in a way to select difficulty before MP scenario start (doesn't need to be done cleanly, can be a prototype hack)<br />
<br />
* Add a new attribute to game creation screen, to allow each player to select a number from 1 to 100 and make it available to WML code as a variable after scenario starts. Bonus points if you allow host to see the variable in the game creation screen and allow him to change it and lock it down for any particular player.<br />
<br />
* write or download a small MP campaign and report on any MP campaign support bugs that you find.<br />
<br />
* implement a lobby command to make the player who issued that command host and start a game with specified parameters, bypassing side selection screen.<br />
<br />
* Make yourself familiar with the multiplayer port of the "Legend of Wesmere" campaign. Try to understand why and how the difficult setting is handled in it's case.</div>Fabihttps://wiki.wesnoth.org/index.php?title=SoC_Ideas_Multiplayer_Improvements_2011&diff=40704SoC Ideas Multiplayer Improvements 20112011-03-09T13:56:29Z<p>Fabi: /* Under the hood */</p>
<hr />
<div>{{SoC2011Idea}}<br />
<br />
<br />
=Description=<br />
<h2>Reengineer Wesnoth's multiplayer engine</h2><br />
<br />
More info at [[SoC_Ideas_Multiplayer_Improvements_2011]]<br />
<br />
<br />
Wesnoth includes a lot of multiplayer content, like 'standard' scenarios, custom scenarios and multiplayer campaigns. However, when creating a multiplayer game, the player's options are highly limited - for example, it is not possible to select the difficulty level before starting the scenario, and it is not possible to allow the scenario to set what 'variables' can be customized by players before game is started (there's only global 'use map settings' flag and some control over sides). We want to reengineer the architecture of Wesnoth's multiplayer engine to allow it to support those things.<br />
<br />
{{#dpl:<br />
|resultsheader=''There are %PAGES% submitted student proposals for this idea''<br />
|oneresultheader=''There is 1 submitted student proposal for this idea''<br />
|suppresserrors=true<br />
|noresultsheader=''There are no submitted student proposals for this idea''<br />
|category=Summer of Code 2011 Student Page&SoC Ideas Multiplayer Improvements<br />
|notcategory=SoC 2011 Not Submitted To Google<br />
|include=#Description<br />
|mode=userformat<br />
|format=,,<br/>See [[%PAGE%|%TITLE%]] for more information.<br/><br/>,<br />
}}<br />
<br />
=Additional Information=<br />
== Difficulty levels in MP ==<br />
Wesnoth includes a lot of text data config files which need to be 'parsed' before game starts. Difficulty needs to be known at the time we parse those config files. Currently, we parse those files before entering the multiplayer lobby. As a consequence, we cannot select difficulty in multiplayer game (data's already parsed at the point when the game is created). Note that parsing takes a lot of time, so, if we do it while already connected to MP server, we need to add workarounds to ensure it doesn't think the client is dead.<br />
<br />
== Game creation screen ==<br />
We want the multiplayer game creation screen to be different and better. We think that we need different screens for normal MP scenarios, 'custom' MP scenarios and for MP campaigns.<br />
<br />
== Unification of multiplayer and singleplayer in the engine==<br />
A really long-term goal would be to reduce the complexity of the codebase by merging SP and MP (making SP a special case of MP and allow seamless transition between both). There is a number of steps which could be taken to gradually move closer to this goal.<br />
<br />
== Under the hood ==<br />
Wesnoth uses a pre-processor to organise its file hierarchy and to make use of macros.<br />
This system is used to load only a certain subset of all available WML code depending on the current needs.<br />
<br />
A freshly started Wesnoth instance does neither know about the inners of single player campaigns nor multiplayer content.<br />
The player is able to choose between the mainline campaigns before the wml tree gets re-parsed because the [campaign] tag hosted in the campaign's _main.cfg contains all needed information and it's parsed from game start.<br />
<br />
But the engine does only read the _main.cfg when the whole directory was included by a pre-processor directive.<br />
If you allow me to show you some wml code you will discover that the rest of the campaign is guarded by a pre-processor symbol:<br />
<br />
.<br />
.<br />
.<br />
[campaign]<br />
id=Heir_To_The_Throne<br />
.<br />
.<br />
.<br />
define=CAMPAIGN_HEIR_TO_THE_THRONE<br />
.<br />
.<br />
.<br />
[/campaign]<br />
.<br />
.<br />
.<br />
#ifdef CAMPAIGN_HEIR_TO_THE_THRONE<br />
[binary_path]<br />
path=data/campaigns/Heir_To_The_Throne<br />
[/binary_path]<br />
[+units]<br />
{campaigns/Heir_To_The_Throne/units}<br />
[/units]<br />
<br />
{campaigns/Heir_To_The_Throne/utils}<br />
{campaigns/Heir_To_The_Throne/scenarios}<br />
#endif<br />
<br />
=Whom to ask about this=<br />
Ask Crab_ and/or fendrin on #wesnoth-dev<br />
<br />
=Possible pre-gsoc tasks=<br />
<br />
* Talk with devs, users, and MP devs about UI design of MP creation screens and show some prototypes of game creation screens for MP campaigns, and custom MP scenarios<br />
<br />
* Hack in a way to select difficulty before MP scenario start (doesn't need to be done cleanly, can be a prototype hack)<br />
<br />
* Add a new attribute to game creation screen, to allow each player to select a number from 1 to 100 and make it available to WML code as a variable after scenario starts. Bonus points if you allow host to see the variable in the game creation screen and allow him to change it and lock it down for any particular player.<br />
<br />
* write or download a small MP campaign and report on any MP campaign support bugs that you find.<br />
<br />
* implement a lobby command to make the player who issued that command host and start a game with specified parameters, bypassing side selection screen.<br />
<br />
* Make yourself familiar with the multiplayer port of the "Legend of Wesmere" campaign. Try to understand why and how the difficult setting is handled in it's case.</div>Fabi