https://wiki.wesnoth.org/api.php?action=feedcontributions&feedformat=atom&user=Pentarctagon 2026-05-09T12:17:22Z User contributions MediaWiki 1.31.16 https://wiki.wesnoth.org/index.php?title=PblWML&diff=75029 2026-05-02T15:44:44Z

<p>Pentarctagon: /* primary_authors */</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 level 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 /> &lt;b&gt;Note:&lt;/b&gt; Be aware that translations in the .pbl-files are '''not''' used, so don't mark these strings as translatable. {{DevFeature1.15|4}} The translations in the .pbl-files are used, but they are used as a plain text instead of Gettext strings, 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 [[ImagePathFunctions]] to recolor it. For example: <br /> <br /> ::icon=&quot;units/elves-wood/archer+female-sword-1.png~RC(magenta&gt;brightorange)&quot;<br /> :or<br /> ::icon=&quot;units/human-peasants/peasant-ranged.png~RC(magenta&gt;white)~CS(24,24,24)&quot;<br /> :or<br /> ::icon=&quot;units/human-peasants/ruffian.png~RC(magenta&gt;green)~BLIT(units/human-peasants/woodsman.png~RC(magenta&gt;lightblue),18,12)&quot;<br /> <br /> : Because the add-on manager's UI is dark, recoloring to light colors looks usually better. [https://irydacea.me/projects/wespal Wespal] is a tool that provides a convenient way to preview recolored unit sprites without needing to launch the game with specific WML or Lua edits.<br /> <br /> : {{DevFeature1.13|12}} Instead of a standard Wesnoth image, a [[DataURI]] can also be used. This way, an image can be directly included into the _server.pbl file. Take care to leave no trailing newline.<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 /> : '''This value is required'''.<br /> <br /> === version ===<br /> : Displayed to the right of the title; it is merely 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 or between these numbers. The string of numbers will be modified on the server by inserting or appending zeros as neccesary to meet the required format. All this is necessary for the “Update All” button to work correctly. ([[#Version Key Examples|See Examples]])<br /> : '''This value is required'''.<br /> <br /> === author ===<br /> : Displayed to the right of the version; it is merely 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 /> : {{DevFeature1.17|3}} When using forum_auth, this value is a single forum account name which will have the ability to upload new versions of the add-on, delete the add-on from the add-ons server, and update the secondary_authors field.<br /> <br /> : {{DevFeature1.19|7}} This value is now used the same as it was pre-forum_auth. It is only used to display in the addons manager.<br /> <br /> : '''This value is required'''.<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 /> : {{DevFeature1.15|12}}<br /> <br /> : It is no longer required to keep the passphrase in the .pbl file at all. If it is not present, then Wesnoth will prompt for it to be entered when uploading or deleting an add-on.<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 /> : '''This value is required'''.<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 /> === tags ===<br /> {{DevFeature1.13|12}}<br /> : An optional string including a comma-separated list of keywords used for matching add-ons when typing terms into the Filter box on the top left of the Add-ons Manager. There are no specific requirements on the syntax of the keywords listed here, but a general recommendation is to keep them relevant for players. For example, one might include the add-on's acronym in the tags, the names or acronyms of add-ons to which it is related, and so on.<br /> <br /> {{DevFeature1.15|13}} The in-game add-ons manager will show all the tags in the UI, and also includes a drop-down list of tags to filter by. Not all tags are listed in the filter box, and the exact list of tags supported may change before 1.16 is released, but the list is currently:<br /> <br /> * '''cooperative''': All human players are on the same team, versus the AI<br /> * '''cosmetic''': These make the game look different, without changing gameplay<br /> * '''difficulty''': Can make campaigns easier or harder<br /> * '''rng''': Modify the randomness in the combat mechanics, or remove it entirely<br /> * '''survival''': Fight against waves of enemies<br /> * '''terraforming''': Players can change the terrain<br /> <br /> For example, if an A New Land style add-on had tags ''building'', ''terraforming'', ''anl'', ''city'', and ''survival'' then it would be shown if either ''Terraforming'' or ''Survival'' was selected in the drop-down; the other tags wouldn't affect the filtering.<br /> <br /> === core ===<br /> {{DevFeature1.13|0}}<br /> : An optional string defining the id of the core which the addon is designed for. Defaults to &quot;''default''&quot;. Don't specify for an addon which is of type &quot;''core''&quot; itself. Note: DO NOT SET this unless you know why you need it! Giving it an invalid value can lead to mysterious errors with your campaign failing to load!<br /> <br /> === translate ===<br /> : If set to ''true'', the add-on would have been sent to and updated with [[WesCamp|WesCamp-i18n]], if that project were still active. However, as WesCamp is no longer active, this no longer does anything.<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 /> : Note: WesCamp was abandoned in 2014. Instead, please refer to:<br /> * [[GettextForWesnothDevelopers]]<br /> * [[GettextForTranslators#For_add-ons]]<br /> * forum thread: [https://r.wesnoth.org/t46366 Guide: Translating your UMC without WesCamp].<br /> <br /> === type ===<br /> : Indicates the type of the add-on; used to filter listings in the downloads manager dialog. Acceptable 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 ({{DevFeature1.13|11}} can also used for single-player modifications, although it's still called ''mod_mp'').<br /> :* ''media'': miscellaneous resources for UMC authors/users, for example, music packs, packages of general-purpose WML, etc. &lt;small&gt;Note: Shows as Resources, not Media, in the add-ons interface&lt;/small&gt;<br /> :* ''other'': The type to use when no other type fits.<br /> : '''Note:''' If your add-on contains two or more separate multiplayer scenarios, use ''map_pack''.<br /> <br /> : '''This value is required'''.<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 /> : '''This value is required if forum_auth is not set to true'''.<br /> <br /> === forum_auth ===<br /> {{DevFeature1.17|3}}<br /> : When set to ''true'', you will be prompted for your forum password when uploading your add-on. The username(s) available to select will be populated from the '''author''' field (before 1.19.7) or the '''primary_authors''' field (1.19.7+). If the username dropdown is empty, make sure to confirm that either the '''author''' or '''primary_authors''' field is present and spelled correctly, depending on what version of Wesnoth you are running.<br /> <br /> When set to true, the ''passphrase'' and ''email'' fields are also not required.<br /> <br /> === primary_authors ===<br /> {{DevFeature1.19|7}}<br /> : A comma-delimited list of forum accounts that are allowed to upload new versions of the add-on or delete the add-on from the add-ons server.<br /> <br /> : '''Note:''' Due to limitations with Wesnoth's schema validation, this attribute needs to be on the line after '''forum_auth'''.<br /> <br /> === secondary_authors ===<br /> : A comma-delimited list of forum accounts that are allowed to upload new versions of the add-on, but aren't allowed to delete the add-on.<br /> <br /> === [feedback] ===<br /> : 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 /> : 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, this topic_id corresponds to the series of digits in the ''t=YYYYY'' portion of a URL like &lt;code&gt;&lt;nowiki&gt;http://forums.wesnoth.org/viewtopic.php?f=XX&amp;t=YYYYY&lt;/nowiki&gt;&lt;/code&gt;. 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 /> === [translation] ===<br /> {{DevFeature1.15|4}}<br /> : Multiple [translation] tags can be used to provide the addon with a localized title and description to be seen in the addons manager. However, it should be noted that the declared translations won't influence the list of supported locales as it depends only on the presence of .mo and .po files for corresponding languages.<br /> <br /> ==== language ====<br /> : The target language code for the translation. The codes for each language are given in the big table on [https://www.wesnoth.org/gettext/] . You can use either its contracted version (like ''sv'' for Swedish) or a more precise variety (like ''zh_CN'' or ''ca_ES@valencia'').<br /> : '''This value is required'''.<br /> <br /> ==== title ====<br /> : The translation of addon's title for the target language.<br /> : '''This value is required'''.<br /> <br /> ==== description ====<br /> : The translation of addon's description for the target language.<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 /> {{DevFeature1.17|13}} the schema validation rejects many of the '''good''' examples. https://github.com/wesnoth/wesnoth/issues/7396<br /> <br /> The following are examples of '''good''' version values:<br /> <br /> version=&quot;1.5&quot;<br /> version=&quot;0.11.4&quot;<br /> version=&quot;0.1.4beta&quot;<br /> version=&quot;1.5c&quot;<br /> <br /> The following are examples of '''bad''' version values:<br /> <br /> version=&quot;Beta1.5&quot;<br /> version=&quot;Incomplete (0.3.4)&quot;<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 /> 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 &lt; 1.0<br /> 1.5 &lt; 1.5c<br /> 1.0 &lt; 1.0.1<br /> 1.0c &lt; 1.0.1a<br /> 1.0.1a &lt; 1.0.1c<br /> 1.0 Final &lt; 1.0.1 Beta<br /> <br /> === Example .pbl File ===<br /> <br /> &lt;syntaxhighlight lang=wml&gt;<br /> title=&quot;My Campaign&quot;<br /> type=&quot;campaign&quot;<br /> icon=&quot;misc/ball.png&quot;<br /> version=&quot;0.1.2&quot;<br /> author=&quot;Me, artwork by myself&quot;<br /> passphrase=&quot;This is like a password; see the security note in the documentation above before choosing a value of your own&quot;<br /> description=&quot;You get to kill a lot of bad guys. But only the first map is done.&quot;<br /> email=&quot;name@example.com&quot;<br /> [feedback]<br /> topic_id=12345<br /> [/feedback]<br /> # Note: the translation feature works on version 1.14.14, 1.15.4 and later only<br /> [translation]<br /> language=&quot;ru&quot;<br /> title=&quot;Моя Кампания&quot;<br /> description=&quot;Вам придётся завалить немало плохишей. Но пока что готова лишь первая карта.&quot;<br /> [/translation]<br /> [translation]<br /> language=&quot;zh_CN&quot;<br /> title=&quot;我的竞选&quot;<br /> description=&quot;你会杀死很多坏人。 但是只完成了第一张地图。(translated online)&quot;<br /> [/translation]<br /> &lt;/syntaxhighlight&gt;<br /> <br /> == See Also ==<br /> <br /> * [[IGNFileFormat]]<br /> * [[FancyAddonIcons]]<br /> * [[ReferenceWML]]<br /> * [[CampaignServerWML]]<br /> <br /> [[Category: WML Reference]]</div>

Pentarctagon https://wiki.wesnoth.org/index.php?title=Template:DevDownload&diff=74999 2026-04-23T23:50:42Z

<p>Pentarctagon: </p> <hr /> <div>&lt;noinclude&gt;<br /> == Development (1.19 branch) ==<br /> &lt;/noinclude&gt;<br /> ==== Windows (10 1903 and later) {{{4|}}} ====<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.23 | filename=wesnoth-1.19.23-win64.exe |<br /> hash=69d2d16d491d1cb374a9a687cd23b803b44775ecb8339641abe45bef4bd273d9}}<br /> <br /> ==== macOS (10.13 and later) {{{5|}}} ====<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.23 | filename=Wesnoth_1.19.23.dmg |<br /> hash=44ecfc8257a0bb48baa958b86e300b2f01d46952deddd0e1770e87160f3958e7}}<br /> <br /> ==== Source code ====<br /> * [https://github.com/wesnoth/wesnoth/blob/master/INSTALL.md Compiling Wesnoth] - How to compile the source code<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.23 | filename=wesnoth-1.19.23.tar.bz2 |<br /> hash=f5bd748ead5b0b9c838fa95ac6142cceac74354db4e57e1f9de5b9369bd39d48}}</div>

Pentarctagon https://wiki.wesnoth.org/index.php?title=Template:DevDownload&diff=74997 2026-04-23T16:05:26Z

<p>Pentarctagon: </p> <hr /> <div>&lt;noinclude&gt;<br /> == Development (1.19 branch) ==<br /> &lt;/noinclude&gt;<br /> ==== Windows (10 1903 and later) {{{4|}}} ====<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.22 | filename=wesnoth-1.19.22-win64.exe |<br /> hash=805a9da0b230f4334431704ba0cea6b8dcb4613da2530fcf1f315ff382ec67e2}}<br /> <br /> ==== macOS (10.13 and later) {{{5|}}} ====<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.22 | filename=Wesnoth_1.19.22.dmg |<br /> hash=e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855}}<br /> <br /> ==== Source code ====<br /> * [https://github.com/wesnoth/wesnoth/blob/master/INSTALL.md Compiling Wesnoth] - How to compile the source code<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.22 | filename=wesnoth-1.19.22.tar.bz2 |<br /> hash=dccf874092cf42dfbef61e30217f55d40ab4608532ff6dba3be7c052ca3e0c66}}</div>

Pentarctagon https://wiki.wesnoth.org/index.php?title=Template:StableDownload&diff=74996 2026-04-23T16:05:08Z

<p>Pentarctagon: </p> <hr /> <div>&lt;noinclude&gt;<br /> == Stable (1.18 branch) ==<br /> &lt;/noinclude&gt;<br /> ==== Windows (10 1903 and later, 64-bit only) {{{4|}}} ====<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth-1.18 |<br /> version=1.18.7 | filename=wesnoth-1.18.7-win64.exe |<br /> hash=1ebe433b8f7b526944b63d15caf11f42481375130431237b3f1139a517c7c7bb}}<br /> <br /> ==== macOS (10.12 and later) {{{5|}}} ====<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth-1.18 |<br /> version=1.18.7 | filename=Wesnoth_1.18.7.dmg |<br /> hash=258f797ad4ae1f82b4479706875a372857c17130e221689c56647234513eca5f}}<br /> <br /> ==== Source code ====<br /> * [https://github.com/wesnoth/wesnoth/blob/master/INSTALL.md Compiling Wesnoth] - How to compile the source code<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth-1.18 |<br /> version=1.18.7 | filename=wesnoth-1.18.7.tar.bz2 |<br /> hash=d6b50cfdf4388954a1c3da66a61abacdc7643a17aa78a16196e16e720a661fc2}}</div>

Pentarctagon https://wiki.wesnoth.org/index.php?title=CompatibilityStandardsV2&diff=74995 2026-04-23T15:57:16Z

<p>Pentarctagon: /* Deprecation levels - When to remove deprecated features */</p> <hr /> <div>As a piece of software matures, there are often new designs, paradigms, and idioms developed which are superior to old ones. This creates an inherent conflict between the need for progress and the need for compatibility. Wesnoth is no exception. This document describes Wesnoth's approach toward resolving that conflict in a way which is most beneficial to both goals, as well as the rationale behind this approach.<br /> <br /> == Policy ==<br /> This policy defines how the creation of new Wesnoth APIs and the deprecation and removal of old ones are to be handled. For the purposes of this document &quot;API&quot; means &quot;any technical channel by which a content creator interacts with the game engine&quot;. This includes, but is not limited to: preprocessor macros, WML tags, WFL functions, IPFs, and the Lua API. Note that this policy applies only to software APIs. Core content such as sprites, portraits, animations, lore, etc. are to be updated freely, without consideration for stylistic or literary conflicts that such content changes may present to add-ons.<br /> <br /> === When to deprecate ===<br /> ==== Adding a better API ====<br /> Any time a superior API is introduced which has '''complete feature-parity''' with an existing API, the old one should be immediately deprecated. Note that in most cases, in order to be considered to have &quot;complete feature-parity&quot;, the API should be available in the same language or area of the code as the obsolete one was. For example, the introduction of a more powerful API in Lua which can accomplish a superset of the functionality which had previously been available with a certain WML tag would not obsolete that WML tag. Exceptions can be made to this rule in cases where it is clear that the feature does not make a lot of sense in its current language or area, and was merely there for legacy reasons (such as the proper place for it not having been introduced yet at the time of its creation). Such exceptions should be determined by developer consensus.<br /> <br /> ==== Preventing needed fixes or improvements ====<br /> In such cases where a feature is preventing an important new feature from being added or makes it impossible to fix a problem impacting players, it can be preferable to deprecate the API to allow for the necessary changes to be made. APIs deprecated for this reason should still follow the deprecation schedule as normal, unless the fix or improvement is urgently needed.<br /> <br /> ==== Actively harmful ====<br /> If an API is found to cause significant problems for players or UMC authors, such as being prone to causing crashes while also very difficult to properly fix, corrupting saves and replays when not used correctly while being difficult to use correctly, or other similar situations, then such APIs should be deprecated and removed regardless of whether there is a replacement available.<br /> <br /> ==== Unused ====<br /> Any API that is not used in mainline and also is not used by the most recent version of an add-on on the add-ons server of the current or previous stable release can be deprecated. For example, if an add-on for 1.16 uses a deprecated API but the updated version of the add-on for 1.18 does not, then that add-on is not considered as currently using the API. Once deprecated for this reason, a new add-on being uploaded that uses the API is not a reason to undeprecate it.<br /> <br /> This does not need to be a passive process where developers simply check the add-ons server for whether an API is used - developers who want to deprecate an API for removal can proactively talk to and work with UMC authors to help update their add-ons to remove usage of said API. This can be anything from talking with them online about how to update to submitting updated code directly (ie: opening a PR against an add-on's public git repository).<br /> <br /> Deprecating and then removing APIs that are unused is the most preferred approach since their removal does not have any impact on UMC authors.<br /> <br /> === When NOT to deprecate ===<br /> ==== Style ====<br /> Deprecation should not be done purely for reasons of style. This is very subjective and prone to change as new contributors join and current contributors leave or become less active. As such, allowing deprecation for stylistic reasons would lead to entirely unnecessary work for UMC authors as developer preferences change over time.<br /> <br /> ==== Renaming ====<br /> While there can be exceptions, it is rarely a net positive to deprecate an API simply for the sake of renaming it to something else. It is preferable to either add a second name for the same function, leaving the old name as-is, or simply live with the current name rather than expecting all UMC authors using the API to update to the new name.<br /> <br /> ==== Any other reason ====<br /> Accepted reasons for deprecating APIs should be something that's discussed and agreed upon by the development team while also, ideally, including UMC authors. It should not become the norm that additional reasons to deprecate APIs are treated as exceptions and left as an increasingly forgotten discussion on Discord, IRC, or the forums - they should be added to here with the reasoning behind them.<br /> <br /> === Deprecation awareness ===<br /> ==== Conflicting goals ====<br /> When deprecating APIs there is an inherent conflict in terms of how to make UMC authors aware of the deprecation. After all, if they aren't aware something is deprecated, they can't know they may need to update their add-on. Therefore, deprecations need to be displayed in a place where they will see them and most UMC authors don't look at Wesnoth's logs unless there's some other issue they're investigating. At the same time, deprecation warnings aren't relevant to players and spamming deprecation warnings is not an effective way of communicating what the issues are.<br /> <br /> ==== A middle ground ====<br /> Each deprecated feature should make use of an appropriate deprecation function call for that language or subsystem to ensure that the appropriate deprecation notice is printed to the log output. Additionally, deprecation warnings should be displayed in-game in the following cases:<br /> * If the player is running a development version, level 3 and level 4 deprecations should be shown in-game by default.<br /> * If the player enables debug mode then all deprecation warnings should be shown, regardless of whether they're using a stable release or a development release.<br /> <br /> ==== Documentation ====<br /> It is also not enough to only display a warning at runtime when something deprecated is encountered. It is the responsibility of the development team to proactively make UMC authors aware of the deprecations and removals being done. To accomplish this:<br /> * When an API is deprecated, and again if it's later removed, its deprecation or removal must be documented in the appropriate section of the changelog for the version it was deprecated or removed in.<br /> * Likewise, it should be added to https://wiki.wesnoth.org/CompatibilityBreakingChanges<br /> <br /> Additionally, it is not enough to simply say that an API is deprecated. In the deprecation message itself as well as in the changelog and https://wiki.wesnoth.org/CompatibilityBreakingChanges, a description must be included as to why it was deprecated or removed and how UMC authors can update their add-ons to address it.<br /> <br /> Lastly, it should be understood that &quot;removed&quot; doesn't necessarily mean that the API is entirely gone from Wesnoth's codebase. There is no maintenance burden to keeping macro or method stubs that do nothing aside from printing an error message describing what was removed and why. Keeping such stubs around is highly encouraged as it is helpful for UMC authors trying to update very old add-ons to the current version of Wesnoth.<br /> <br /> === How to deprecate ===<br /> Every effort should be made to create the simplest possible wrappers which will translate from an obsolete API to the updated one. Such wrappers should ideally be organized into their own compatibility file or module, and set up in such a way that the internals of the updated API will not affect how the old calls get wrapped to the new one. Essentially, the idea is to create a set-it-and-forget-it compatibility wrapper which will continue to work regardless of updates made to the newer API.<br /> <br /> Additionally, in all cases where it's practical, the wmllint tool must be updated to be able to automatically handle updating add-ons for anything that's been deprecated except for APIs deprecated at level 1. While developers are still heavily encouraged to add wmllint support for level 1 deprecations, it is not required as these do not show deprecation warnings by default and are expected to continue working indefinitely.<br /> <br /> === Deprecation levels - When to remove deprecated features ===<br /> While creating simple compatibility wrappers should be possible most of the time, it would be unreasonable to assume that this approach will be viable in absolutely every case. Wesnoth's compatibility policy therefore has four different levels of deprecation which are used to set expectations for when and if an API is expected to be removed:<br /> <br /> #Deprecated indefinitely &amp;mdash; This deprecation level is for changes which have newer preferred alternatives but, barring any unforeseen issues, have little to no maintenance impact and should be kept indefinitely in order to reduce the work required for UMC authors to maintain their content. For example, functions or attributes which have had their names changed, macros which have been replaced with tags, or simple wrappers with little to no maintenance overhead. If future large scale changes make it impractical to maintain an API deprecated at this level then the deprecation level should be raised accordingly. This is generally the preferred deprecation level - higher deprecation levels are for APIs which are intended for eventual removal and must be weighed against the maintenance work this forces upon UMC authors.<br /> #Deprecated with the intention of future removal &amp;mdash; This deprecation level is for APIs which will be removed in a future version, but the version they are removed in has not yet have been decided. Barring urgent circumstances, all APIs that are deprecated with the intention of being removed '''must''' start with being deprecated at level 2 for 1-2 development cycles at minimum depending on the impact of the API's removal on UMC authors. Once the API has spent the necessary amount of time at deprecation level 2, it can be moved to deprecation level 3. It is not allowed to deprecate an API at level 2 and change it to level 3 in the same development cycle. There is no maximum amount of time that an API can remain deprecated at level 2.<br /> #Deprecated for removal in a specific version &amp;mdash; This deprecation level is for APIs which were previously deprecated at level 2 and now have a future version at which they will be removed. The version an API is removed in must be at least two development cycles after the API was deprecated at level 2. It is not allowed to move an API to deprecation level 3 and then remove it in the same development cycle.<br /> #Removed without deprecation &amp;mdash; This level should be used EXTREMELY rarely, and only in cases where it is ABSOLUTELY NECESSARY. Occasionally, an update to a feature will change the underlying architecture in such a fundamental way that the old paradigm cannot coexist with the new one no matter how much redundant code one would create. While this kind of scenario is extremely rare, and every effort should be made to find creative solutions to avoid it, there are occasionally cases where it truly is impossible to maintain both methods even in the short term. This level should only be used with broad developer consensus, after the majority of active developers familiar with the feature in question have given at least some thought to trying to deprecate gracefully and failed. This level should also be used for macro and method stubs containing only an error message describing what was removed and why, as well as if an API feature is found to have a security vulnerability which can't be fixed.<br /> <br /> APIs that are clearly labeled as being experimental, such as a WML tag having &quot;experimental&quot; in the name or a lua function having &quot;experimental&quot; in its name or package, can be be removed or deprecated at any level at any time. These are APIs which UMC authors use at their own risk.<br /> <br /> == Rationale ==<br /> The above policy is the result of a large amount of thought, discussion, and debate. Following is a brief outline of the considerations and goals on both sides of the problem, why there is an inherent conflict between them, some failed approaches to resolving the conflict, and how the final policy ultimately maximizes the pursuit of both goals.<br /> <br /> === The Problem - The paradox of progress ===<br /> Invariably, as development on any project moves forward, developers will realize that there are better, cleaner, or more elegant ways to structure things than they had been previously. These changes can be to improve efficiency, make an API more intuitive, keep code better organized, make common tasks more straightforward, or accomplish any number of other positive things. These changes can also make the development of additional features much more viable. In short, progress is good.<br /> <br /> On the other hand, a content-heavy program such as Wesnoth relies on the ability of content creators to efficiently create, maintain, and update their content. Too many changes all at once will force creators of existing content to spend obscene amounts time updating their creations just to keeping them up-to-date and in working order. This can lead to a high amount of frustration, a drop in motivation, and a decline in content being created. In short, progress is bad.<br /> <br /> === Backwards Compatibility - benefits and drawbacks ===<br /> Most of the time, older paradigms can still be maintained in a manner in which they coexist with the newer ones. This allows for existing content to continue functioning, while at the same time allowing and encouraging new content to be created using the newer methods. However, maintaining such code can be problematic in the following ways:<br /> #There may eventually be architectural changes a developer would want to make where the old method's square peg no longer fits, even forcibly, into the new method's round hole.<br /> #Having compatibility code hanging around may, depending on how it is implemented, mean that any updates made to the feature, module, or subsystem in question would have to made in both the new, cleaner design, and the older, poorly structured one, adding more work for developers.<br /> <br /> === The Naive Approach - Deprecate and remove everything old ===<br /> One approach to balancing old and new is to deprecate the old and slate its eventual removal after either a certain amount of time has passed or a certain number of subsequent versions have been released. This sounds good in theory, but in practice, there will be many changes which are minor or cosmetic in nature and which will add up. Things like replacing macros with WML tags, updating the name of an API call or order of parameters to be more consistent with other similar functions, or switching from a functional to an object-oriented structure are very good for organizational purposes, but will result in a large amount of maintenance required on the part of content creators to keep existing code operational, and for very little real gain. This approach invariably leads to the situation where so much is being changed from one version to the next that creators turn into maintainers, forced to spend nearly all of their time trying to stay ahead of the update curve in an attempt to keep their existing content working, and leaving them very little time and motivation to create new content. And of course, by the time they're finished painstakingly updating their existing code for every little change made for the current release, whoops, there's a new release with a whole slew of new changes that need accounting for. It simply becomes unmanageable.<br /> <br /> === The Naive Approach - Deprecate and remove only when necessary ===<br /> The opposite approach would be to keep all existing paradigms until they actively interfere with a new architecture or create a double-maintenance problem. While this approach does cut down on the maintenance burden by ensuring that content using an older design continues to work, it hinders progress by the fact that the moment at which it first becomes clear that an architectural or double-maintenance problem will occur is exactly the same moment at which keeping the old structure around becomes problematic. Beginning a deprecation cycle at that point and then having to &quot;wait out&quot; the old paradigm will cause an unacceptable delay in development.<br /> <br /> === The Middle Ground - Deprecate everything old, remove only when necessary ===<br /> Most of the time, older APIs can be implemented in terms of their newer, cleaner counterparts through the use of things like simple wrappers, parse-translators which re-write the older paradigm's code in terms of the new one, or other relatively low-maintenance &quot;set-it-and-forget-it&quot; approaches. These simple wrappers are not really detrimental to making progress, don't require updating when the new APIs internals are changed, and can usually be organized into their own files and/or modules so that they don't clutter the cleaner code. Many such wrappers will never truly present either of the backwards compatibility drawbacks mentioned above. As such, there is really no detriment to keeping them around indefinitely. However, occasionally, a new idea or approach will be put forth that updates the newer paradigm in such a way that the older one can no longer cleanly wrap to it. This usually happens, as inspiration is wont to do, suddenly, unexpectedly, and without warning. As such developers need the flexibility to be able to remove outdated code as freely as possible when the situation requires. Therefore, the ideal solution would be to deprecate any API which has newer, feature-complete ways to do it, while leaving it in the codebase until such time as its presence becomes a hindrance. Essentially, deprecation need not necessarily mean &quot;this WILL be removed&quot; so much as &quot;this is now a candidate for removal&quot;. By separating the concepts of deprecation and removal, both goals can be better served.<br /> <br /> === Undefined removal timeline - issues encountered ===<br /> In practice however, simply stating something is a candidate for removal while providing no further information on when it will actually be removed causes multiple issues:<br /> * When a deprecated API is causing a maintenance burden worthy of removal is a subjective decision, often leading to debates over removal any time a developer decides it's time for an API to be removed, initially deprecated, or moved to a higher deprecation level.<br /> * Lack of developer incentive to provide good documentation and support for the deprecation of the API given there's no particular timeline for when it will actually cause issues for UMC authors.<br /> * UMC authors often don't find out about deprecated APIs and so can't possibly migrate to the new APIs.<br /> * UMC authors aren't provided the documentation or tooling support needed to make updating their add-ons easier.<br /> * UMC authors may simply decide there's no reason to update to the new API even if they know it's deprecated and how to update their add-on. After all, why spend time updating APIs that may stick around forever?<br /> * Giving a version that an API '''may''' be removed instead of a version that it '''will''' be removed is not as clear as it may seem to UMC authors who aren't already aware of how Wesnoth handles deprecation. This can lead to UMC authors ignoring deprecation warnings after seeing such warnings for APIs which provide a version that's years old.<br /> <br /> === Certainty is also a benefit ===<br /> Wesnoth continues to exist today in large part because of the content made by its community. As such, developers should always be sparing in what they choose to deprecate and what they choose to remove, so that UMC authors can update their content to the latest version of Wesnoth without needing to make a herculean effort every couple of years.<br /> <br /> But, for cases where APIs are removed, the benefit of providing certainty for when that will happen outweighs the flexibility of being able remove them at any time after they been marked as deprecated. It encourages developers to provide the documentation and tooling support to make it easier for UMC authors to update their add-ons, and it lets UMC authors know when they can expect deprecated APIs to be removed rather than it effectively happening at random when a developer decides a deprecated API needs to be dropped.<br /> <br /> === More Complex Cases - One size does not fit all ===<br /> There may, however, be cases where the obsolete API cannot be implemented cleanly in terms of the updated one and must be maintained separately, or, in extremely rare cases, cannot coexist at all. There needs to be some leeway for such cases as well. In the former case, it therefore makes sense to allow for a feature to be deprecated pending removal after the shortest reasonable deprecation period. In the latter case, there is obviously no choice but to make the change and remove the old immediately. Developers should, naturally, be encouraged to find creative solutions to avoid such cases, but it is inevitable that there will eventually be a few cases where no graceful transition procedure can be found. These more aggressive forms of deprecation should only be done with developer consensus, and only after all options of creating a backwards-compatible transition have been exhausted.<br /> <br /> === Graphics - The exception that proves the rule ===<br /> The one area where backwards compatibility should NOT be a factor is graphical changes. Any change to the terrain graphics, unit sprites, or portrait images has the potential to result in visually-incompatible custom content. Core content creators cannot be expected to maintain a deprecated visual style alongside a more modern one, as any approach toward doing so would add an unreasonable amount of bloat and overhead, and make it very difficult for core graphics to be updated without having to do double the work. In addition, add-ons will continue to function even with such visual incompatibilities present, they just won't look right. As such, it can be said that stylistic incompatibilities fall more within the realm of content than of code, and it is not unreasonable to expect a content creator to... well... create content. Expecting the graphical style to remain backwards-compatible would be just as unreasonable as expecting stories, help descriptions, or other forms of lore to never change because they may introduce plot holes into add-on stories. Essentially, since the goal of the software portion of Wesnoth is, at its heart, merely to facilitate the creation and advancement of this kind of content, core content needs to be free to develop unhindered by considerations for add-on content.</div>

Pentarctagon https://wiki.wesnoth.org/index.php?title=CompatibilityStandardsV2&diff=74994 2026-04-23T15:54:15Z

<p>Pentarctagon: /* Deprecation levels - When to remove deprecated features */</p> <hr /> <div>As a piece of software matures, there are often new designs, paradigms, and idioms developed which are superior to old ones. This creates an inherent conflict between the need for progress and the need for compatibility. Wesnoth is no exception. This document describes Wesnoth's approach toward resolving that conflict in a way which is most beneficial to both goals, as well as the rationale behind this approach.<br /> <br /> == Policy ==<br /> This policy defines how the creation of new Wesnoth APIs and the deprecation and removal of old ones are to be handled. For the purposes of this document &quot;API&quot; means &quot;any technical channel by which a content creator interacts with the game engine&quot;. This includes, but is not limited to: preprocessor macros, WML tags, WFL functions, IPFs, and the Lua API. Note that this policy applies only to software APIs. Core content such as sprites, portraits, animations, lore, etc. are to be updated freely, without consideration for stylistic or literary conflicts that such content changes may present to add-ons.<br /> <br /> === When to deprecate ===<br /> ==== Adding a better API ====<br /> Any time a superior API is introduced which has '''complete feature-parity''' with an existing API, the old one should be immediately deprecated. Note that in most cases, in order to be considered to have &quot;complete feature-parity&quot;, the API should be available in the same language or area of the code as the obsolete one was. For example, the introduction of a more powerful API in Lua which can accomplish a superset of the functionality which had previously been available with a certain WML tag would not obsolete that WML tag. Exceptions can be made to this rule in cases where it is clear that the feature does not make a lot of sense in its current language or area, and was merely there for legacy reasons (such as the proper place for it not having been introduced yet at the time of its creation). Such exceptions should be determined by developer consensus.<br /> <br /> ==== Preventing needed fixes or improvements ====<br /> In such cases where a feature is preventing an important new feature from being added or makes it impossible to fix a problem impacting players, it can be preferable to deprecate the API to allow for the necessary changes to be made. APIs deprecated for this reason should still follow the deprecation schedule as normal, unless the fix or improvement is urgently needed.<br /> <br /> ==== Actively harmful ====<br /> If an API is found to cause significant problems for players or UMC authors, such as being prone to causing crashes while also very difficult to properly fix, corrupting saves and replays when not used correctly while being difficult to use correctly, or other similar situations, then such APIs should be deprecated and removed regardless of whether there is a replacement available.<br /> <br /> ==== Unused ====<br /> Any API that is not used in mainline and also is not used by the most recent version of an add-on on the add-ons server of the current or previous stable release can be deprecated. For example, if an add-on for 1.16 uses a deprecated API but the updated version of the add-on for 1.18 does not, then that add-on is not considered as currently using the API. Once deprecated for this reason, a new add-on being uploaded that uses the API is not a reason to undeprecate it.<br /> <br /> This does not need to be a passive process where developers simply check the add-ons server for whether an API is used - developers who want to deprecate an API for removal can proactively talk to and work with UMC authors to help update their add-ons to remove usage of said API. This can be anything from talking with them online about how to update to submitting updated code directly (ie: opening a PR against an add-on's public git repository).<br /> <br /> Deprecating and then removing APIs that are unused is the most preferred approach since their removal does not have any impact on UMC authors.<br /> <br /> === When NOT to deprecate ===<br /> ==== Style ====<br /> Deprecation should not be done purely for reasons of style. This is very subjective and prone to change as new contributors join and current contributors leave or become less active. As such, allowing deprecation for stylistic reasons would lead to entirely unnecessary work for UMC authors as developer preferences change over time.<br /> <br /> ==== Renaming ====<br /> While there can be exceptions, it is rarely a net positive to deprecate an API simply for the sake of renaming it to something else. It is preferable to either add a second name for the same function, leaving the old name as-is, or simply live with the current name rather than expecting all UMC authors using the API to update to the new name.<br /> <br /> ==== Any other reason ====<br /> Accepted reasons for deprecating APIs should be something that's discussed and agreed upon by the development team while also, ideally, including UMC authors. It should not become the norm that additional reasons to deprecate APIs are treated as exceptions and left as an increasingly forgotten discussion on Discord, IRC, or the forums - they should be added to here with the reasoning behind them.<br /> <br /> === Deprecation awareness ===<br /> ==== Conflicting goals ====<br /> When deprecating APIs there is an inherent conflict in terms of how to make UMC authors aware of the deprecation. After all, if they aren't aware something is deprecated, they can't know they may need to update their add-on. Therefore, deprecations need to be displayed in a place where they will see them and most UMC authors don't look at Wesnoth's logs unless there's some other issue they're investigating. At the same time, deprecation warnings aren't relevant to players and spamming deprecation warnings is not an effective way of communicating what the issues are.<br /> <br /> ==== A middle ground ====<br /> Each deprecated feature should make use of an appropriate deprecation function call for that language or subsystem to ensure that the appropriate deprecation notice is printed to the log output. Additionally, deprecation warnings should be displayed in-game in the following cases:<br /> * If the player is running a development version, level 3 and level 4 deprecations should be shown in-game by default.<br /> * If the player enables debug mode then all deprecation warnings should be shown, regardless of whether they're using a stable release or a development release.<br /> <br /> ==== Documentation ====<br /> It is also not enough to only display a warning at runtime when something deprecated is encountered. It is the responsibility of the development team to proactively make UMC authors aware of the deprecations and removals being done. To accomplish this:<br /> * When an API is deprecated, and again if it's later removed, its deprecation or removal must be documented in the appropriate section of the changelog for the version it was deprecated or removed in.<br /> * Likewise, it should be added to https://wiki.wesnoth.org/CompatibilityBreakingChanges<br /> <br /> Additionally, it is not enough to simply say that an API is deprecated. In the deprecation message itself as well as in the changelog and https://wiki.wesnoth.org/CompatibilityBreakingChanges, a description must be included as to why it was deprecated or removed and how UMC authors can update their add-ons to address it.<br /> <br /> Lastly, it should be understood that &quot;removed&quot; doesn't necessarily mean that the API is entirely gone from Wesnoth's codebase. There is no maintenance burden to keeping macro or method stubs that do nothing aside from printing an error message describing what was removed and why. Keeping such stubs around is highly encouraged as it is helpful for UMC authors trying to update very old add-ons to the current version of Wesnoth.<br /> <br /> === How to deprecate ===<br /> Every effort should be made to create the simplest possible wrappers which will translate from an obsolete API to the updated one. Such wrappers should ideally be organized into their own compatibility file or module, and set up in such a way that the internals of the updated API will not affect how the old calls get wrapped to the new one. Essentially, the idea is to create a set-it-and-forget-it compatibility wrapper which will continue to work regardless of updates made to the newer API.<br /> <br /> Additionally, in all cases where it's practical, the wmllint tool must be updated to be able to automatically handle updating add-ons for anything that's been deprecated except for APIs deprecated at level 1. While developers are still heavily encouraged to add wmllint support for level 1 deprecations, it is not required as these do not show deprecation warnings by default and are expected to continue working indefinitely.<br /> <br /> === Deprecation levels - When to remove deprecated features ===<br /> While creating simple compatibility wrappers should be possible most of the time, it would be unreasonable to assume that this approach will be viable in absolutely every case. Wesnoth's compatibility policy therefore has four different levels of deprecation which are used to set expectations for when and if an API is expected to be removed:<br /> <br /> #Deprecated indefinitely &amp;mdash; This deprecation level is for changes which have newer preferred alternatives but, barring any unforeseen issues, have little to no maintenance impact and should be kept indefinitely in order to reduce the work required for UMC authors to maintain their content. For example, functions or attributes which have had their names changed, macros which have been replaced with tags, or simple wrappers with little to no maintenance overhead. If future large scale changes make it impractical to maintain an API deprecated at this level then the deprecation level should be raised accordingly. This is generally the preferred deprecation level - higher deprecation levels are for APIs which are intended for eventual removal and must be weighed against the maintenance work this forces upon UMC authors.<br /> #Deprecated with the intention of future removal &amp;mdash; This deprecation level is for APIs which will be removed in a future version, but the version they are removed in has not yet have been decided. Barring urgent circumstances, all APIs that are deprecated with the intention of being removed '''must''' start with being deprecated at level 2 for 1-2 development cycles at minimum depending on the impact of the API's removal on UMC authors. Once the API has spent the necessary amount of time at deprecation level 2, it can be moved to deprecation level 3. It is not allowed to deprecate an API at level 2 and change it to level 3 in the same development cycle. There is no maximum amount of time that an API can remain deprecated at level 2.<br /> #Deprecated for removal in a specific version &amp;mdash; This deprecation level is for APIs which were previously deprecated at level 2 and now have a future version at which they will be removed. The version an API is removed in must be at least two development cycles after the API was deprecated at level 2. It is not allowed to move an API to deprecation level 3 and then remove it in the same development cycle.<br /> #Removed without deprecation &amp;mdash; This level should be used EXTREMELY rarely, and only in cases where it is ABSOLUTELY NECESSARY. Occasionally, an update to a feature will change the underlying architecture in such a fundamental way that the old paradigm cannot coexist with the new one no matter how much redundant code one would create. While this kind of scenario is extremely rare, and every effort should be made to find creative solutions to avoid it, there are occasionally cases where it truly is impossible to maintain both methods even in the short term. This level should only be used with broad developer consensus, after the majority of active developers familiar with the feature in question have given at least some thought to trying to deprecate gracefully and failed. This level should also be used for macro and method stubs containing only an error message describing what was removed and why, as well as if an API feature is found to have a security vulnerability which can't be fixed.<br /> <br /> APIs that are clearly labeled as being experimental, such as a WML tag having &quot;experimental&quot; in the name or a lua function having &quot;experimental&quot; in its name or package, can be be removed at any time. These are APIs which UMC authors use at their own risk.<br /> <br /> == Rationale ==<br /> The above policy is the result of a large amount of thought, discussion, and debate. Following is a brief outline of the considerations and goals on both sides of the problem, why there is an inherent conflict between them, some failed approaches to resolving the conflict, and how the final policy ultimately maximizes the pursuit of both goals.<br /> <br /> === The Problem - The paradox of progress ===<br /> Invariably, as development on any project moves forward, developers will realize that there are better, cleaner, or more elegant ways to structure things than they had been previously. These changes can be to improve efficiency, make an API more intuitive, keep code better organized, make common tasks more straightforward, or accomplish any number of other positive things. These changes can also make the development of additional features much more viable. In short, progress is good.<br /> <br /> On the other hand, a content-heavy program such as Wesnoth relies on the ability of content creators to efficiently create, maintain, and update their content. Too many changes all at once will force creators of existing content to spend obscene amounts time updating their creations just to keeping them up-to-date and in working order. This can lead to a high amount of frustration, a drop in motivation, and a decline in content being created. In short, progress is bad.<br /> <br /> === Backwards Compatibility - benefits and drawbacks ===<br /> Most of the time, older paradigms can still be maintained in a manner in which they coexist with the newer ones. This allows for existing content to continue functioning, while at the same time allowing and encouraging new content to be created using the newer methods. However, maintaining such code can be problematic in the following ways:<br /> #There may eventually be architectural changes a developer would want to make where the old method's square peg no longer fits, even forcibly, into the new method's round hole.<br /> #Having compatibility code hanging around may, depending on how it is implemented, mean that any updates made to the feature, module, or subsystem in question would have to made in both the new, cleaner design, and the older, poorly structured one, adding more work for developers.<br /> <br /> === The Naive Approach - Deprecate and remove everything old ===<br /> One approach to balancing old and new is to deprecate the old and slate its eventual removal after either a certain amount of time has passed or a certain number of subsequent versions have been released. This sounds good in theory, but in practice, there will be many changes which are minor or cosmetic in nature and which will add up. Things like replacing macros with WML tags, updating the name of an API call or order of parameters to be more consistent with other similar functions, or switching from a functional to an object-oriented structure are very good for organizational purposes, but will result in a large amount of maintenance required on the part of content creators to keep existing code operational, and for very little real gain. This approach invariably leads to the situation where so much is being changed from one version to the next that creators turn into maintainers, forced to spend nearly all of their time trying to stay ahead of the update curve in an attempt to keep their existing content working, and leaving them very little time and motivation to create new content. And of course, by the time they're finished painstakingly updating their existing code for every little change made for the current release, whoops, there's a new release with a whole slew of new changes that need accounting for. It simply becomes unmanageable.<br /> <br /> === The Naive Approach - Deprecate and remove only when necessary ===<br /> The opposite approach would be to keep all existing paradigms until they actively interfere with a new architecture or create a double-maintenance problem. While this approach does cut down on the maintenance burden by ensuring that content using an older design continues to work, it hinders progress by the fact that the moment at which it first becomes clear that an architectural or double-maintenance problem will occur is exactly the same moment at which keeping the old structure around becomes problematic. Beginning a deprecation cycle at that point and then having to &quot;wait out&quot; the old paradigm will cause an unacceptable delay in development.<br /> <br /> === The Middle Ground - Deprecate everything old, remove only when necessary ===<br /> Most of the time, older APIs can be implemented in terms of their newer, cleaner counterparts through the use of things like simple wrappers, parse-translators which re-write the older paradigm's code in terms of the new one, or other relatively low-maintenance &quot;set-it-and-forget-it&quot; approaches. These simple wrappers are not really detrimental to making progress, don't require updating when the new APIs internals are changed, and can usually be organized into their own files and/or modules so that they don't clutter the cleaner code. Many such wrappers will never truly present either of the backwards compatibility drawbacks mentioned above. As such, there is really no detriment to keeping them around indefinitely. However, occasionally, a new idea or approach will be put forth that updates the newer paradigm in such a way that the older one can no longer cleanly wrap to it. This usually happens, as inspiration is wont to do, suddenly, unexpectedly, and without warning. As such developers need the flexibility to be able to remove outdated code as freely as possible when the situation requires. Therefore, the ideal solution would be to deprecate any API which has newer, feature-complete ways to do it, while leaving it in the codebase until such time as its presence becomes a hindrance. Essentially, deprecation need not necessarily mean &quot;this WILL be removed&quot; so much as &quot;this is now a candidate for removal&quot;. By separating the concepts of deprecation and removal, both goals can be better served.<br /> <br /> === Undefined removal timeline - issues encountered ===<br /> In practice however, simply stating something is a candidate for removal while providing no further information on when it will actually be removed causes multiple issues:<br /> * When a deprecated API is causing a maintenance burden worthy of removal is a subjective decision, often leading to debates over removal any time a developer decides it's time for an API to be removed, initially deprecated, or moved to a higher deprecation level.<br /> * Lack of developer incentive to provide good documentation and support for the deprecation of the API given there's no particular timeline for when it will actually cause issues for UMC authors.<br /> * UMC authors often don't find out about deprecated APIs and so can't possibly migrate to the new APIs.<br /> * UMC authors aren't provided the documentation or tooling support needed to make updating their add-ons easier.<br /> * UMC authors may simply decide there's no reason to update to the new API even if they know it's deprecated and how to update their add-on. After all, why spend time updating APIs that may stick around forever?<br /> * Giving a version that an API '''may''' be removed instead of a version that it '''will''' be removed is not as clear as it may seem to UMC authors who aren't already aware of how Wesnoth handles deprecation. This can lead to UMC authors ignoring deprecation warnings after seeing such warnings for APIs which provide a version that's years old.<br /> <br /> === Certainty is also a benefit ===<br /> Wesnoth continues to exist today in large part because of the content made by its community. As such, developers should always be sparing in what they choose to deprecate and what they choose to remove, so that UMC authors can update their content to the latest version of Wesnoth without needing to make a herculean effort every couple of years.<br /> <br /> But, for cases where APIs are removed, the benefit of providing certainty for when that will happen outweighs the flexibility of being able remove them at any time after they been marked as deprecated. It encourages developers to provide the documentation and tooling support to make it easier for UMC authors to update their add-ons, and it lets UMC authors know when they can expect deprecated APIs to be removed rather than it effectively happening at random when a developer decides a deprecated API needs to be dropped.<br /> <br /> === More Complex Cases - One size does not fit all ===<br /> There may, however, be cases where the obsolete API cannot be implemented cleanly in terms of the updated one and must be maintained separately, or, in extremely rare cases, cannot coexist at all. There needs to be some leeway for such cases as well. In the former case, it therefore makes sense to allow for a feature to be deprecated pending removal after the shortest reasonable deprecation period. In the latter case, there is obviously no choice but to make the change and remove the old immediately. Developers should, naturally, be encouraged to find creative solutions to avoid such cases, but it is inevitable that there will eventually be a few cases where no graceful transition procedure can be found. These more aggressive forms of deprecation should only be done with developer consensus, and only after all options of creating a backwards-compatible transition have been exhausted.<br /> <br /> === Graphics - The exception that proves the rule ===<br /> The one area where backwards compatibility should NOT be a factor is graphical changes. Any change to the terrain graphics, unit sprites, or portrait images has the potential to result in visually-incompatible custom content. Core content creators cannot be expected to maintain a deprecated visual style alongside a more modern one, as any approach toward doing so would add an unreasonable amount of bloat and overhead, and make it very difficult for core graphics to be updated without having to do double the work. In addition, add-ons will continue to function even with such visual incompatibilities present, they just won't look right. As such, it can be said that stylistic incompatibilities fall more within the realm of content than of code, and it is not unreasonable to expect a content creator to... well... create content. Expecting the graphical style to remain backwards-compatible would be just as unreasonable as expecting stories, help descriptions, or other forms of lore to never change because they may introduce plot holes into add-on stories. Essentially, since the goal of the software portion of Wesnoth is, at its heart, merely to facilitate the creation and advancement of this kind of content, core content needs to be free to develop unhindered by considerations for add-on content.</div>

Pentarctagon https://wiki.wesnoth.org/index.php?title=CompatibilityStandardsV2&diff=74993 2026-04-23T15:33:54Z

<p>Pentarctagon: /* Deprecation levels - When to remove deprecated features */</p> <hr /> <div>As a piece of software matures, there are often new designs, paradigms, and idioms developed which are superior to old ones. This creates an inherent conflict between the need for progress and the need for compatibility. Wesnoth is no exception. This document describes Wesnoth's approach toward resolving that conflict in a way which is most beneficial to both goals, as well as the rationale behind this approach.<br /> <br /> == Policy ==<br /> This policy defines how the creation of new Wesnoth APIs and the deprecation and removal of old ones are to be handled. For the purposes of this document &quot;API&quot; means &quot;any technical channel by which a content creator interacts with the game engine&quot;. This includes, but is not limited to: preprocessor macros, WML tags, WFL functions, IPFs, and the Lua API. Note that this policy applies only to software APIs. Core content such as sprites, portraits, animations, lore, etc. are to be updated freely, without consideration for stylistic or literary conflicts that such content changes may present to add-ons.<br /> <br /> === When to deprecate ===<br /> ==== Adding a better API ====<br /> Any time a superior API is introduced which has '''complete feature-parity''' with an existing API, the old one should be immediately deprecated. Note that in most cases, in order to be considered to have &quot;complete feature-parity&quot;, the API should be available in the same language or area of the code as the obsolete one was. For example, the introduction of a more powerful API in Lua which can accomplish a superset of the functionality which had previously been available with a certain WML tag would not obsolete that WML tag. Exceptions can be made to this rule in cases where it is clear that the feature does not make a lot of sense in its current language or area, and was merely there for legacy reasons (such as the proper place for it not having been introduced yet at the time of its creation). Such exceptions should be determined by developer consensus.<br /> <br /> ==== Preventing needed fixes or improvements ====<br /> In such cases where a feature is preventing an important new feature from being added or makes it impossible to fix a problem impacting players, it can be preferable to deprecate the API to allow for the necessary changes to be made. APIs deprecated for this reason should still follow the deprecation schedule as normal, unless the fix or improvement is urgently needed.<br /> <br /> ==== Actively harmful ====<br /> If an API is found to cause significant problems for players or UMC authors, such as being prone to causing crashes while also very difficult to properly fix, corrupting saves and replays when not used correctly while being difficult to use correctly, or other similar situations, then such APIs should be deprecated and removed regardless of whether there is a replacement available.<br /> <br /> ==== Unused ====<br /> Any API that is not used in mainline and also is not used by the most recent version of an add-on on the add-ons server of the current or previous stable release can be deprecated. For example, if an add-on for 1.16 uses a deprecated API but the updated version of the add-on for 1.18 does not, then that add-on is not considered as currently using the API. Once deprecated for this reason, a new add-on being uploaded that uses the API is not a reason to undeprecate it.<br /> <br /> This does not need to be a passive process where developers simply check the add-ons server for whether an API is used - developers who want to deprecate an API for removal can proactively talk to and work with UMC authors to help update their add-ons to remove usage of said API. This can be anything from talking with them online about how to update to submitting updated code directly (ie: opening a PR against an add-on's public git repository).<br /> <br /> Deprecating and then removing APIs that are unused is the most preferred approach since their removal does not have any impact on UMC authors.<br /> <br /> === When NOT to deprecate ===<br /> ==== Style ====<br /> Deprecation should not be done purely for reasons of style. This is very subjective and prone to change as new contributors join and current contributors leave or become less active. As such, allowing deprecation for stylistic reasons would lead to entirely unnecessary work for UMC authors as developer preferences change over time.<br /> <br /> ==== Renaming ====<br /> While there can be exceptions, it is rarely a net positive to deprecate an API simply for the sake of renaming it to something else. It is preferable to either add a second name for the same function, leaving the old name as-is, or simply live with the current name rather than expecting all UMC authors using the API to update to the new name.<br /> <br /> ==== Any other reason ====<br /> Accepted reasons for deprecating APIs should be something that's discussed and agreed upon by the development team while also, ideally, including UMC authors. It should not become the norm that additional reasons to deprecate APIs are treated as exceptions and left as an increasingly forgotten discussion on Discord, IRC, or the forums - they should be added to here with the reasoning behind them.<br /> <br /> === Deprecation awareness ===<br /> ==== Conflicting goals ====<br /> When deprecating APIs there is an inherent conflict in terms of how to make UMC authors aware of the deprecation. After all, if they aren't aware something is deprecated, they can't know they may need to update their add-on. Therefore, deprecations need to be displayed in a place where they will see them and most UMC authors don't look at Wesnoth's logs unless there's some other issue they're investigating. At the same time, deprecation warnings aren't relevant to players and spamming deprecation warnings is not an effective way of communicating what the issues are.<br /> <br /> ==== A middle ground ====<br /> Each deprecated feature should make use of an appropriate deprecation function call for that language or subsystem to ensure that the appropriate deprecation notice is printed to the log output. Additionally, deprecation warnings should be displayed in-game in the following cases:<br /> * If the player is running a development version, level 3 and level 4 deprecations should be shown in-game by default.<br /> * If the player enables debug mode then all deprecation warnings should be shown, regardless of whether they're using a stable release or a development release.<br /> <br /> ==== Documentation ====<br /> It is also not enough to only display a warning at runtime when something deprecated is encountered. It is the responsibility of the development team to proactively make UMC authors aware of the deprecations and removals being done. To accomplish this:<br /> * When an API is deprecated, and again if it's later removed, its deprecation or removal must be documented in the appropriate section of the changelog for the version it was deprecated or removed in.<br /> * Likewise, it should be added to https://wiki.wesnoth.org/CompatibilityBreakingChanges<br /> <br /> Additionally, it is not enough to simply say that an API is deprecated. In the deprecation message itself as well as in the changelog and https://wiki.wesnoth.org/CompatibilityBreakingChanges, a description must be included as to why it was deprecated or removed and how UMC authors can update their add-ons to address it.<br /> <br /> Lastly, it should be understood that &quot;removed&quot; doesn't necessarily mean that the API is entirely gone from Wesnoth's codebase. There is no maintenance burden to keeping macro or method stubs that do nothing aside from printing an error message describing what was removed and why. Keeping such stubs around is highly encouraged as it is helpful for UMC authors trying to update very old add-ons to the current version of Wesnoth.<br /> <br /> === How to deprecate ===<br /> Every effort should be made to create the simplest possible wrappers which will translate from an obsolete API to the updated one. Such wrappers should ideally be organized into their own compatibility file or module, and set up in such a way that the internals of the updated API will not affect how the old calls get wrapped to the new one. Essentially, the idea is to create a set-it-and-forget-it compatibility wrapper which will continue to work regardless of updates made to the newer API.<br /> <br /> Additionally, in all cases where it's practical, the wmllint tool must be updated to be able to automatically handle updating add-ons for anything that's been deprecated except for APIs deprecated at level 1. While developers are still heavily encouraged to add wmllint support for level 1 deprecations, it is not required as these do not show deprecation warnings by default and are expected to continue working indefinitely.<br /> <br /> === Deprecation levels - When to remove deprecated features ===<br /> While creating simple compatibility wrappers should be possible most of the time, it would be unreasonable to assume that this approach will be viable in absolutely every case. Wesnoth's compatibility policy therefore has four different levels of deprecation which are used to set expectations for when and if an API is expected to be removed:<br /> <br /> #Deprecated indefinitely &amp;mdash; This deprecation level is for changes which have newer preferred alternatives but, barring any unforeseen issues, have little to no maintenance impact and should be kept indefinitely in order to reduce the work required for UMC authors to maintain their content. For example, functions or attributes which have had their names changed, macros which have been replaced with tags, or simple wrappers with little to no maintenance overhead. If future large scale changes make it impractical to maintain an API deprecated at this level then the deprecation level should be raised accordingly. This is generally the preferred deprecation level - higher deprecation levels are for APIs which are intended for eventual removal and must be weighed against the maintenance work this forces upon UMC authors.<br /> #Deprecated with the intention of future removal &amp;mdash; This deprecation level is for APIs which will be removed in a future version, but the version they are removed in has not yet have been decided. Barring urgent circumstances, all APIs that are deprecated with the intention of being removed '''must''' start with being deprecated at level 2 for 1-2 development cycles at minimum depending on the impact of the API's removal on UMC authors. Once the API has spent the necessary amount of time at deprecation level 2, it can be moved to deprecation level 3. It is not allowed to deprecate an API at level 2 and change it to level 3 in the same development cycle. There is no maximum amount of time that an API can remain deprecated at level 2.<br /> #Deprecated for removal in a specific version &amp;mdash; This deprecation level is for APIs which were previously deprecated at level 2 and now have a future version at which they will be removed. The version an API is removed in must be at least two development cycles after the API was deprecated at level 2. It is not allowed to move an API to deprecation level 3 and then remove it in the same development cycle.<br /> #Removed without deprecation &amp;mdash; This level should be used EXTREMELY rarely, and only in cases where it is ABSOLUTELY NECESSARY. Occasionally, an update to a feature will change the underlying architecture in such a fundamental way that the old paradigm cannot coexist with the new one no matter how much redundant code one would create. While this kind of scenario is extremely rare, and every effort should be made to find creative solutions to avoid it, there are occasionally cases where it truly is impossible to maintain both methods even in the short term. This level should only be used with broad developer consensus, after the majority of active developers familiar with the feature in question have given at least some thought to trying to deprecate gracefully and failed. This level should also be used for macro and method stubs containing only an error message describing what was removed and why, as well as if an API feature is found to have a security vulnerability which can't be fixed.<br /> <br /> == Rationale ==<br /> The above policy is the result of a large amount of thought, discussion, and debate. Following is a brief outline of the considerations and goals on both sides of the problem, why there is an inherent conflict between them, some failed approaches to resolving the conflict, and how the final policy ultimately maximizes the pursuit of both goals.<br /> <br /> === The Problem - The paradox of progress ===<br /> Invariably, as development on any project moves forward, developers will realize that there are better, cleaner, or more elegant ways to structure things than they had been previously. These changes can be to improve efficiency, make an API more intuitive, keep code better organized, make common tasks more straightforward, or accomplish any number of other positive things. These changes can also make the development of additional features much more viable. In short, progress is good.<br /> <br /> On the other hand, a content-heavy program such as Wesnoth relies on the ability of content creators to efficiently create, maintain, and update their content. Too many changes all at once will force creators of existing content to spend obscene amounts time updating their creations just to keeping them up-to-date and in working order. This can lead to a high amount of frustration, a drop in motivation, and a decline in content being created. In short, progress is bad.<br /> <br /> === Backwards Compatibility - benefits and drawbacks ===<br /> Most of the time, older paradigms can still be maintained in a manner in which they coexist with the newer ones. This allows for existing content to continue functioning, while at the same time allowing and encouraging new content to be created using the newer methods. However, maintaining such code can be problematic in the following ways:<br /> #There may eventually be architectural changes a developer would want to make where the old method's square peg no longer fits, even forcibly, into the new method's round hole.<br /> #Having compatibility code hanging around may, depending on how it is implemented, mean that any updates made to the feature, module, or subsystem in question would have to made in both the new, cleaner design, and the older, poorly structured one, adding more work for developers.<br /> <br /> === The Naive Approach - Deprecate and remove everything old ===<br /> One approach to balancing old and new is to deprecate the old and slate its eventual removal after either a certain amount of time has passed or a certain number of subsequent versions have been released. This sounds good in theory, but in practice, there will be many changes which are minor or cosmetic in nature and which will add up. Things like replacing macros with WML tags, updating the name of an API call or order of parameters to be more consistent with other similar functions, or switching from a functional to an object-oriented structure are very good for organizational purposes, but will result in a large amount of maintenance required on the part of content creators to keep existing code operational, and for very little real gain. This approach invariably leads to the situation where so much is being changed from one version to the next that creators turn into maintainers, forced to spend nearly all of their time trying to stay ahead of the update curve in an attempt to keep their existing content working, and leaving them very little time and motivation to create new content. And of course, by the time they're finished painstakingly updating their existing code for every little change made for the current release, whoops, there's a new release with a whole slew of new changes that need accounting for. It simply becomes unmanageable.<br /> <br /> === The Naive Approach - Deprecate and remove only when necessary ===<br /> The opposite approach would be to keep all existing paradigms until they actively interfere with a new architecture or create a double-maintenance problem. While this approach does cut down on the maintenance burden by ensuring that content using an older design continues to work, it hinders progress by the fact that the moment at which it first becomes clear that an architectural or double-maintenance problem will occur is exactly the same moment at which keeping the old structure around becomes problematic. Beginning a deprecation cycle at that point and then having to &quot;wait out&quot; the old paradigm will cause an unacceptable delay in development.<br /> <br /> === The Middle Ground - Deprecate everything old, remove only when necessary ===<br /> Most of the time, older APIs can be implemented in terms of their newer, cleaner counterparts through the use of things like simple wrappers, parse-translators which re-write the older paradigm's code in terms of the new one, or other relatively low-maintenance &quot;set-it-and-forget-it&quot; approaches. These simple wrappers are not really detrimental to making progress, don't require updating when the new APIs internals are changed, and can usually be organized into their own files and/or modules so that they don't clutter the cleaner code. Many such wrappers will never truly present either of the backwards compatibility drawbacks mentioned above. As such, there is really no detriment to keeping them around indefinitely. However, occasionally, a new idea or approach will be put forth that updates the newer paradigm in such a way that the older one can no longer cleanly wrap to it. This usually happens, as inspiration is wont to do, suddenly, unexpectedly, and without warning. As such developers need the flexibility to be able to remove outdated code as freely as possible when the situation requires. Therefore, the ideal solution would be to deprecate any API which has newer, feature-complete ways to do it, while leaving it in the codebase until such time as its presence becomes a hindrance. Essentially, deprecation need not necessarily mean &quot;this WILL be removed&quot; so much as &quot;this is now a candidate for removal&quot;. By separating the concepts of deprecation and removal, both goals can be better served.<br /> <br /> === Undefined removal timeline - issues encountered ===<br /> In practice however, simply stating something is a candidate for removal while providing no further information on when it will actually be removed causes multiple issues:<br /> * When a deprecated API is causing a maintenance burden worthy of removal is a subjective decision, often leading to debates over removal any time a developer decides it's time for an API to be removed, initially deprecated, or moved to a higher deprecation level.<br /> * Lack of developer incentive to provide good documentation and support for the deprecation of the API given there's no particular timeline for when it will actually cause issues for UMC authors.<br /> * UMC authors often don't find out about deprecated APIs and so can't possibly migrate to the new APIs.<br /> * UMC authors aren't provided the documentation or tooling support needed to make updating their add-ons easier.<br /> * UMC authors may simply decide there's no reason to update to the new API even if they know it's deprecated and how to update their add-on. After all, why spend time updating APIs that may stick around forever?<br /> * Giving a version that an API '''may''' be removed instead of a version that it '''will''' be removed is not as clear as it may seem to UMC authors who aren't already aware of how Wesnoth handles deprecation. This can lead to UMC authors ignoring deprecation warnings after seeing such warnings for APIs which provide a version that's years old.<br /> <br /> === Certainty is also a benefit ===<br /> Wesnoth continues to exist today in large part because of the content made by its community. As such, developers should always be sparing in what they choose to deprecate and what they choose to remove, so that UMC authors can update their content to the latest version of Wesnoth without needing to make a herculean effort every couple of years.<br /> <br /> But, for cases where APIs are removed, the benefit of providing certainty for when that will happen outweighs the flexibility of being able remove them at any time after they been marked as deprecated. It encourages developers to provide the documentation and tooling support to make it easier for UMC authors to update their add-ons, and it lets UMC authors know when they can expect deprecated APIs to be removed rather than it effectively happening at random when a developer decides a deprecated API needs to be dropped.<br /> <br /> === More Complex Cases - One size does not fit all ===<br /> There may, however, be cases where the obsolete API cannot be implemented cleanly in terms of the updated one and must be maintained separately, or, in extremely rare cases, cannot coexist at all. There needs to be some leeway for such cases as well. In the former case, it therefore makes sense to allow for a feature to be deprecated pending removal after the shortest reasonable deprecation period. In the latter case, there is obviously no choice but to make the change and remove the old immediately. Developers should, naturally, be encouraged to find creative solutions to avoid such cases, but it is inevitable that there will eventually be a few cases where no graceful transition procedure can be found. These more aggressive forms of deprecation should only be done with developer consensus, and only after all options of creating a backwards-compatible transition have been exhausted.<br /> <br /> === Graphics - The exception that proves the rule ===<br /> The one area where backwards compatibility should NOT be a factor is graphical changes. Any change to the terrain graphics, unit sprites, or portrait images has the potential to result in visually-incompatible custom content. Core content creators cannot be expected to maintain a deprecated visual style alongside a more modern one, as any approach toward doing so would add an unreasonable amount of bloat and overhead, and make it very difficult for core graphics to be updated without having to do double the work. In addition, add-ons will continue to function even with such visual incompatibilities present, they just won't look right. As such, it can be said that stylistic incompatibilities fall more within the realm of content than of code, and it is not unreasonable to expect a content creator to... well... create content. Expecting the graphical style to remain backwards-compatible would be just as unreasonable as expecting stories, help descriptions, or other forms of lore to never change because they may introduce plot holes into add-on stories. Essentially, since the goal of the software portion of Wesnoth is, at its heart, merely to facilitate the creation and advancement of this kind of content, core content needs to be free to develop unhindered by considerations for add-on content.</div>

Pentarctagon https://wiki.wesnoth.org/index.php?title=CompatibilityStandardsV2&diff=74992 2026-04-23T15:33:26Z

<p>Pentarctagon: /* When to deprecate */</p> <hr /> <div>As a piece of software matures, there are often new designs, paradigms, and idioms developed which are superior to old ones. This creates an inherent conflict between the need for progress and the need for compatibility. Wesnoth is no exception. This document describes Wesnoth's approach toward resolving that conflict in a way which is most beneficial to both goals, as well as the rationale behind this approach.<br /> <br /> == Policy ==<br /> This policy defines how the creation of new Wesnoth APIs and the deprecation and removal of old ones are to be handled. For the purposes of this document &quot;API&quot; means &quot;any technical channel by which a content creator interacts with the game engine&quot;. This includes, but is not limited to: preprocessor macros, WML tags, WFL functions, IPFs, and the Lua API. Note that this policy applies only to software APIs. Core content such as sprites, portraits, animations, lore, etc. are to be updated freely, without consideration for stylistic or literary conflicts that such content changes may present to add-ons.<br /> <br /> === When to deprecate ===<br /> ==== Adding a better API ====<br /> Any time a superior API is introduced which has '''complete feature-parity''' with an existing API, the old one should be immediately deprecated. Note that in most cases, in order to be considered to have &quot;complete feature-parity&quot;, the API should be available in the same language or area of the code as the obsolete one was. For example, the introduction of a more powerful API in Lua which can accomplish a superset of the functionality which had previously been available with a certain WML tag would not obsolete that WML tag. Exceptions can be made to this rule in cases where it is clear that the feature does not make a lot of sense in its current language or area, and was merely there for legacy reasons (such as the proper place for it not having been introduced yet at the time of its creation). Such exceptions should be determined by developer consensus.<br /> <br /> ==== Preventing needed fixes or improvements ====<br /> In such cases where a feature is preventing an important new feature from being added or makes it impossible to fix a problem impacting players, it can be preferable to deprecate the API to allow for the necessary changes to be made. APIs deprecated for this reason should still follow the deprecation schedule as normal, unless the fix or improvement is urgently needed.<br /> <br /> ==== Actively harmful ====<br /> If an API is found to cause significant problems for players or UMC authors, such as being prone to causing crashes while also very difficult to properly fix, corrupting saves and replays when not used correctly while being difficult to use correctly, or other similar situations, then such APIs should be deprecated and removed regardless of whether there is a replacement available.<br /> <br /> ==== Unused ====<br /> Any API that is not used in mainline and also is not used by the most recent version of an add-on on the add-ons server of the current or previous stable release can be deprecated. For example, if an add-on for 1.16 uses a deprecated API but the updated version of the add-on for 1.18 does not, then that add-on is not considered as currently using the API. Once deprecated for this reason, a new add-on being uploaded that uses the API is not a reason to undeprecate it.<br /> <br /> This does not need to be a passive process where developers simply check the add-ons server for whether an API is used - developers who want to deprecate an API for removal can proactively talk to and work with UMC authors to help update their add-ons to remove usage of said API. This can be anything from talking with them online about how to update to submitting updated code directly (ie: opening a PR against an add-on's public git repository).<br /> <br /> Deprecating and then removing APIs that are unused is the most preferred approach since their removal does not have any impact on UMC authors.<br /> <br /> === When NOT to deprecate ===<br /> ==== Style ====<br /> Deprecation should not be done purely for reasons of style. This is very subjective and prone to change as new contributors join and current contributors leave or become less active. As such, allowing deprecation for stylistic reasons would lead to entirely unnecessary work for UMC authors as developer preferences change over time.<br /> <br /> ==== Renaming ====<br /> While there can be exceptions, it is rarely a net positive to deprecate an API simply for the sake of renaming it to something else. It is preferable to either add a second name for the same function, leaving the old name as-is, or simply live with the current name rather than expecting all UMC authors using the API to update to the new name.<br /> <br /> ==== Any other reason ====<br /> Accepted reasons for deprecating APIs should be something that's discussed and agreed upon by the development team while also, ideally, including UMC authors. It should not become the norm that additional reasons to deprecate APIs are treated as exceptions and left as an increasingly forgotten discussion on Discord, IRC, or the forums - they should be added to here with the reasoning behind them.<br /> <br /> === Deprecation awareness ===<br /> ==== Conflicting goals ====<br /> When deprecating APIs there is an inherent conflict in terms of how to make UMC authors aware of the deprecation. After all, if they aren't aware something is deprecated, they can't know they may need to update their add-on. Therefore, deprecations need to be displayed in a place where they will see them and most UMC authors don't look at Wesnoth's logs unless there's some other issue they're investigating. At the same time, deprecation warnings aren't relevant to players and spamming deprecation warnings is not an effective way of communicating what the issues are.<br /> <br /> ==== A middle ground ====<br /> Each deprecated feature should make use of an appropriate deprecation function call for that language or subsystem to ensure that the appropriate deprecation notice is printed to the log output. Additionally, deprecation warnings should be displayed in-game in the following cases:<br /> * If the player is running a development version, level 3 and level 4 deprecations should be shown in-game by default.<br /> * If the player enables debug mode then all deprecation warnings should be shown, regardless of whether they're using a stable release or a development release.<br /> <br /> ==== Documentation ====<br /> It is also not enough to only display a warning at runtime when something deprecated is encountered. It is the responsibility of the development team to proactively make UMC authors aware of the deprecations and removals being done. To accomplish this:<br /> * When an API is deprecated, and again if it's later removed, its deprecation or removal must be documented in the appropriate section of the changelog for the version it was deprecated or removed in.<br /> * Likewise, it should be added to https://wiki.wesnoth.org/CompatibilityBreakingChanges<br /> <br /> Additionally, it is not enough to simply say that an API is deprecated. In the deprecation message itself as well as in the changelog and https://wiki.wesnoth.org/CompatibilityBreakingChanges, a description must be included as to why it was deprecated or removed and how UMC authors can update their add-ons to address it.<br /> <br /> Lastly, it should be understood that &quot;removed&quot; doesn't necessarily mean that the API is entirely gone from Wesnoth's codebase. There is no maintenance burden to keeping macro or method stubs that do nothing aside from printing an error message describing what was removed and why. Keeping such stubs around is highly encouraged as it is helpful for UMC authors trying to update very old add-ons to the current version of Wesnoth.<br /> <br /> === How to deprecate ===<br /> Every effort should be made to create the simplest possible wrappers which will translate from an obsolete API to the updated one. Such wrappers should ideally be organized into their own compatibility file or module, and set up in such a way that the internals of the updated API will not affect how the old calls get wrapped to the new one. Essentially, the idea is to create a set-it-and-forget-it compatibility wrapper which will continue to work regardless of updates made to the newer API.<br /> <br /> Additionally, in all cases where it's practical, the wmllint tool must be updated to be able to automatically handle updating add-ons for anything that's been deprecated except for APIs deprecated at level 1. While developers are still heavily encouraged to add wmllint support for level 1 deprecations, it is not required as these do not show deprecation warnings by default and are expected to continue working indefinitely.<br /> <br /> === Deprecation levels - When to remove deprecated features ===<br /> While creating simple compatibility wrappers should be possible most of the time, it would be unreasonable to assume that this approach will be viable in absolutely every case. Wesnoth's compatibility policy therefore has four different levels of deprecation which are used to set expectations for when and if an API is expected to be removed:<br /> <br /> #Deprecated indefinitely &amp;mdash; This deprecation level is for changes which have newer preferred alternatives but, barring any unforeseen issues, have little to no maintenance impact and should be kept indefinitely in order to reduce the work required for UMC authors to maintain their content. For example, functions or attributes which have had their names changed, macros which have been replaced with tags, or simple wrappers with little to no maintenance overhead. If future large scale changes make it impractical to maintain an API deprecated at this level then the deprecation level should be raised accordingly. This is generally the preferred deprecation level - higher deprecation levels are for APIs which are intended for eventual removal and must be weighed against the maintenance work this forces upon UMC authors.<br /> #Deprecated with the intention of future removal &amp;mdash; This deprecation level is for APIs which will be removed in a future version, but the version they are removed in has not yet have been decided. Barring urgent circumstances, all APIs that are deprecated with the intention of being removed '''must''' start with being deprecated at level 2 for 1-2 development cycles at minimum depending on the impact of the API's removal on UMC authors. Once the API has spent the necessary amount of time at deprecation level 2, it can be moved to deprecation level 3. It is not allowed to deprecate an API at level 2 and change it to level 3 in the same development cycle. There is no maximum amount of time that an API can remain deprecated at level 2.<br /> #Deprecated for removal in a specific version &amp;mdash; This deprecation level is for APIs which were previously deprecated at level 2 and now have a future version at which they will be removed. The version an API is removed in must be at least two development cycles after the API was deprecated at level 2. It is not allowed to move an API to deprecation level 3 and then remove it in the same development cycle.<br /> #Removed without deprecation &amp;mdash; This level should be used EXTREMELY rarely, and only in cases where it is ABSOLUTELY NECESSARY. Occasionally, an update to a feature will change the underlying architecture in such a fundamental way that the old paradigm cannot coexist with the new one no matter how much redundant code one would create. While this kind of scenario is extremely rare, and every effort should be made to find creative solutions to avoid it, there are occasionally cases where it truly is impossible to maintain both methods even in the short term. This level should only be used with broad developer consensus, after the majority of active developers familiar with the feature in question have given at least some thought to trying to deprecate gracefully and failed. This level should also be used for macro and method stubs containing only an error message describing what was removed and why.<br /> <br /> == Rationale ==<br /> The above policy is the result of a large amount of thought, discussion, and debate. Following is a brief outline of the considerations and goals on both sides of the problem, why there is an inherent conflict between them, some failed approaches to resolving the conflict, and how the final policy ultimately maximizes the pursuit of both goals.<br /> <br /> === The Problem - The paradox of progress ===<br /> Invariably, as development on any project moves forward, developers will realize that there are better, cleaner, or more elegant ways to structure things than they had been previously. These changes can be to improve efficiency, make an API more intuitive, keep code better organized, make common tasks more straightforward, or accomplish any number of other positive things. These changes can also make the development of additional features much more viable. In short, progress is good.<br /> <br /> On the other hand, a content-heavy program such as Wesnoth relies on the ability of content creators to efficiently create, maintain, and update their content. Too many changes all at once will force creators of existing content to spend obscene amounts time updating their creations just to keeping them up-to-date and in working order. This can lead to a high amount of frustration, a drop in motivation, and a decline in content being created. In short, progress is bad.<br /> <br /> === Backwards Compatibility - benefits and drawbacks ===<br /> Most of the time, older paradigms can still be maintained in a manner in which they coexist with the newer ones. This allows for existing content to continue functioning, while at the same time allowing and encouraging new content to be created using the newer methods. However, maintaining such code can be problematic in the following ways:<br /> #There may eventually be architectural changes a developer would want to make where the old method's square peg no longer fits, even forcibly, into the new method's round hole.<br /> #Having compatibility code hanging around may, depending on how it is implemented, mean that any updates made to the feature, module, or subsystem in question would have to made in both the new, cleaner design, and the older, poorly structured one, adding more work for developers.<br /> <br /> === The Naive Approach - Deprecate and remove everything old ===<br /> One approach to balancing old and new is to deprecate the old and slate its eventual removal after either a certain amount of time has passed or a certain number of subsequent versions have been released. This sounds good in theory, but in practice, there will be many changes which are minor or cosmetic in nature and which will add up. Things like replacing macros with WML tags, updating the name of an API call or order of parameters to be more consistent with other similar functions, or switching from a functional to an object-oriented structure are very good for organizational purposes, but will result in a large amount of maintenance required on the part of content creators to keep existing code operational, and for very little real gain. This approach invariably leads to the situation where so much is being changed from one version to the next that creators turn into maintainers, forced to spend nearly all of their time trying to stay ahead of the update curve in an attempt to keep their existing content working, and leaving them very little time and motivation to create new content. And of course, by the time they're finished painstakingly updating their existing code for every little change made for the current release, whoops, there's a new release with a whole slew of new changes that need accounting for. It simply becomes unmanageable.<br /> <br /> === The Naive Approach - Deprecate and remove only when necessary ===<br /> The opposite approach would be to keep all existing paradigms until they actively interfere with a new architecture or create a double-maintenance problem. While this approach does cut down on the maintenance burden by ensuring that content using an older design continues to work, it hinders progress by the fact that the moment at which it first becomes clear that an architectural or double-maintenance problem will occur is exactly the same moment at which keeping the old structure around becomes problematic. Beginning a deprecation cycle at that point and then having to &quot;wait out&quot; the old paradigm will cause an unacceptable delay in development.<br /> <br /> === The Middle Ground - Deprecate everything old, remove only when necessary ===<br /> Most of the time, older APIs can be implemented in terms of their newer, cleaner counterparts through the use of things like simple wrappers, parse-translators which re-write the older paradigm's code in terms of the new one, or other relatively low-maintenance &quot;set-it-and-forget-it&quot; approaches. These simple wrappers are not really detrimental to making progress, don't require updating when the new APIs internals are changed, and can usually be organized into their own files and/or modules so that they don't clutter the cleaner code. Many such wrappers will never truly present either of the backwards compatibility drawbacks mentioned above. As such, there is really no detriment to keeping them around indefinitely. However, occasionally, a new idea or approach will be put forth that updates the newer paradigm in such a way that the older one can no longer cleanly wrap to it. This usually happens, as inspiration is wont to do, suddenly, unexpectedly, and without warning. As such developers need the flexibility to be able to remove outdated code as freely as possible when the situation requires. Therefore, the ideal solution would be to deprecate any API which has newer, feature-complete ways to do it, while leaving it in the codebase until such time as its presence becomes a hindrance. Essentially, deprecation need not necessarily mean &quot;this WILL be removed&quot; so much as &quot;this is now a candidate for removal&quot;. By separating the concepts of deprecation and removal, both goals can be better served.<br /> <br /> === Undefined removal timeline - issues encountered ===<br /> In practice however, simply stating something is a candidate for removal while providing no further information on when it will actually be removed causes multiple issues:<br /> * When a deprecated API is causing a maintenance burden worthy of removal is a subjective decision, often leading to debates over removal any time a developer decides it's time for an API to be removed, initially deprecated, or moved to a higher deprecation level.<br /> * Lack of developer incentive to provide good documentation and support for the deprecation of the API given there's no particular timeline for when it will actually cause issues for UMC authors.<br /> * UMC authors often don't find out about deprecated APIs and so can't possibly migrate to the new APIs.<br /> * UMC authors aren't provided the documentation or tooling support needed to make updating their add-ons easier.<br /> * UMC authors may simply decide there's no reason to update to the new API even if they know it's deprecated and how to update their add-on. After all, why spend time updating APIs that may stick around forever?<br /> * Giving a version that an API '''may''' be removed instead of a version that it '''will''' be removed is not as clear as it may seem to UMC authors who aren't already aware of how Wesnoth handles deprecation. This can lead to UMC authors ignoring deprecation warnings after seeing such warnings for APIs which provide a version that's years old.<br /> <br /> === Certainty is also a benefit ===<br /> Wesnoth continues to exist today in large part because of the content made by its community. As such, developers should always be sparing in what they choose to deprecate and what they choose to remove, so that UMC authors can update their content to the latest version of Wesnoth without needing to make a herculean effort every couple of years.<br /> <br /> But, for cases where APIs are removed, the benefit of providing certainty for when that will happen outweighs the flexibility of being able remove them at any time after they been marked as deprecated. It encourages developers to provide the documentation and tooling support to make it easier for UMC authors to update their add-ons, and it lets UMC authors know when they can expect deprecated APIs to be removed rather than it effectively happening at random when a developer decides a deprecated API needs to be dropped.<br /> <br /> === More Complex Cases - One size does not fit all ===<br /> There may, however, be cases where the obsolete API cannot be implemented cleanly in terms of the updated one and must be maintained separately, or, in extremely rare cases, cannot coexist at all. There needs to be some leeway for such cases as well. In the former case, it therefore makes sense to allow for a feature to be deprecated pending removal after the shortest reasonable deprecation period. In the latter case, there is obviously no choice but to make the change and remove the old immediately. Developers should, naturally, be encouraged to find creative solutions to avoid such cases, but it is inevitable that there will eventually be a few cases where no graceful transition procedure can be found. These more aggressive forms of deprecation should only be done with developer consensus, and only after all options of creating a backwards-compatible transition have been exhausted.<br /> <br /> === Graphics - The exception that proves the rule ===<br /> The one area where backwards compatibility should NOT be a factor is graphical changes. Any change to the terrain graphics, unit sprites, or portrait images has the potential to result in visually-incompatible custom content. Core content creators cannot be expected to maintain a deprecated visual style alongside a more modern one, as any approach toward doing so would add an unreasonable amount of bloat and overhead, and make it very difficult for core graphics to be updated without having to do double the work. In addition, add-ons will continue to function even with such visual incompatibilities present, they just won't look right. As such, it can be said that stylistic incompatibilities fall more within the realm of content than of code, and it is not unreasonable to expect a content creator to... well... create content. Expecting the graphical style to remain backwards-compatible would be just as unreasonable as expecting stories, help descriptions, or other forms of lore to never change because they may introduce plot holes into add-on stories. Essentially, since the goal of the software portion of Wesnoth is, at its heart, merely to facilitate the creation and advancement of this kind of content, core content needs to be free to develop unhindered by considerations for add-on content.</div>

Pentarctagon https://wiki.wesnoth.org/index.php?title=CompatibilityStandardsV2&diff=74988 2026-04-20T22:54:45Z

<p>Pentarctagon: /* Deprecation levels - When to remove deprecated features */</p> <hr /> <div>As a piece of software matures, there are often new designs, paradigms, and idioms developed which are superior to old ones. This creates an inherent conflict between the need for progress and the need for compatibility. Wesnoth is no exception. This document describes Wesnoth's approach toward resolving that conflict in a way which is most beneficial to both goals, as well as the rationale behind this approach.<br /> <br /> == Policy ==<br /> This policy defines how the creation of new Wesnoth APIs and the deprecation and removal of old ones are to be handled. For the purposes of this document &quot;API&quot; means &quot;any technical channel by which a content creator interacts with the game engine&quot;. This includes, but is not limited to: preprocessor macros, WML tags, WFL functions, IPFs, and the Lua API. Note that this policy applies only to software APIs. Core content such as sprites, portraits, animations, lore, etc. are to be updated freely, without consideration for stylistic or literary conflicts that such content changes may present to add-ons.<br /> <br /> === When to deprecate ===<br /> ==== Adding a better API ====<br /> Any time a superior API is introduced which has '''complete feature-parity''' with an existing API, the old one should be immediately deprecated. Note that in most cases, in order to be considered to have &quot;complete feature-parity&quot;, the API should be available in the same language or area of the code as the obsolete one was. For example, the introduction of a more powerful API in Lua which can accomplish a superset of the functionality which had previously been available with a certain WML tag would not obsolete that WML tag. Exceptions can be made to this rule in cases where it is clear that the feature does not make a lot of sense in its current language or area, and was merely there for legacy reasons (such as the proper place for it not having been introduced yet at the time of its creation). Such exceptions should be determined by developer consensus.<br /> <br /> ==== Preventing needed fixes or improvements ====<br /> In such cases where a feature is preventing an important new feature from being added or makes it impossible to fix a problem impacting players, it can be preferable to deprecate the API to allow for the necessary changes to be made. APIs deprecated for this reason should still follow the deprecation schedule as normal, unless the fix or improvement is urgently needed.<br /> <br /> ==== Actively harmful ====<br /> If an API is found to cause significant problems for players or UMC authors, such as being prone to causing crashes while also very difficult to properly fix, corrupting saves and replays when not used correctly while being difficult to use correctly, or other similar situations, then such APIs should be deprecated and removed regardless of whether there is a replacement available.<br /> <br /> ==== Security ====<br /> If an API is found to have a security flaw that can't be fixed, then it should not be deprecated, it should be immediately removed.<br /> <br /> ==== Unused ====<br /> Any API that is not used in mainline and also is not used by the most recent version of an add-on on the add-ons server of the current or previous stable release can be deprecated. For example, if an add-on for 1.16 uses a deprecated API but the updated version of the add-on for 1.18 does not, then that add-on is not considered as currently using the API. Once deprecated for this reason, a new add-on being uploaded that uses the API is not a reason to undeprecate it.<br /> <br /> This does not need to be a passive process where developers simply check the add-ons server for whether an API is used - developers who want to deprecate an API for removal can proactively talk to and work with UMC authors to help update their add-ons to remove usage of said API. This can be anything from talking with them online about how to update to submitting updated code directly (ie: opening a PR against an add-on's public git repository).<br /> <br /> Deprecating and then removing APIs that are unused is the most preferred approach since their removal does not have any impact on UMC authors.<br /> <br /> === When NOT to deprecate ===<br /> ==== Style ====<br /> Deprecation should not be done purely for reasons of style. This is very subjective and prone to change as new contributors join and current contributors leave or become less active. As such, allowing deprecation for stylistic reasons would lead to entirely unnecessary work for UMC authors as developer preferences change over time.<br /> <br /> ==== Renaming ====<br /> While there can be exceptions, it is rarely a net positive to deprecate an API simply for the sake of renaming it to something else. It is preferable to either add a second name for the same function, leaving the old name as-is, or simply live with the current name rather than expecting all UMC authors using the API to update to the new name.<br /> <br /> ==== Any other reason ====<br /> Accepted reasons for deprecating APIs should be something that's discussed and agreed upon by the development team while also, ideally, including UMC authors. It should not become the norm that additional reasons to deprecate APIs are treated as exceptions and left as an increasingly forgotten discussion on Discord, IRC, or the forums - they should be added to here with the reasoning behind them.<br /> <br /> === Deprecation awareness ===<br /> ==== Conflicting goals ====<br /> When deprecating APIs there is an inherent conflict in terms of how to make UMC authors aware of the deprecation. After all, if they aren't aware something is deprecated, they can't know they may need to update their add-on. Therefore, deprecations need to be displayed in a place where they will see them and most UMC authors don't look at Wesnoth's logs unless there's some other issue they're investigating. At the same time, deprecation warnings aren't relevant to players and spamming deprecation warnings is not an effective way of communicating what the issues are.<br /> <br /> ==== A middle ground ====<br /> Each deprecated feature should make use of an appropriate deprecation function call for that language or subsystem to ensure that the appropriate deprecation notice is printed to the log output. Additionally, deprecation warnings should be displayed in-game in the following cases:<br /> * If the player is running a development version, level 3 and level 4 deprecations should be shown in-game by default.<br /> * If the player enables debug mode then all deprecation warnings should be shown, regardless of whether they're using a stable release or a development release.<br /> <br /> ==== Documentation ====<br /> It is also not enough to only display a warning at runtime when something deprecated is encountered. It is the responsibility of the development team to proactively make UMC authors aware of the deprecations and removals being done. To accomplish this:<br /> * When an API is deprecated, and again if it's later removed, its deprecation or removal must be documented in the appropriate section of the changelog for the version it was deprecated or removed in.<br /> * Likewise, it should be added to https://wiki.wesnoth.org/CompatibilityBreakingChanges<br /> <br /> Additionally, it is not enough to simply say that an API is deprecated. In the deprecation message itself as well as in the changelog and https://wiki.wesnoth.org/CompatibilityBreakingChanges, a description must be included as to why it was deprecated or removed and how UMC authors can update their add-ons to address it.<br /> <br /> Lastly, it should be understood that &quot;removed&quot; doesn't necessarily mean that the API is entirely gone from Wesnoth's codebase. There is no maintenance burden to keeping macro or method stubs that do nothing aside from printing an error message describing what was removed and why. Keeping such stubs around is highly encouraged as it is helpful for UMC authors trying to update very old add-ons to the current version of Wesnoth.<br /> <br /> === How to deprecate ===<br /> Every effort should be made to create the simplest possible wrappers which will translate from an obsolete API to the updated one. Such wrappers should ideally be organized into their own compatibility file or module, and set up in such a way that the internals of the updated API will not affect how the old calls get wrapped to the new one. Essentially, the idea is to create a set-it-and-forget-it compatibility wrapper which will continue to work regardless of updates made to the newer API.<br /> <br /> Additionally, in all cases where it's practical, the wmllint tool must be updated to be able to automatically handle updating add-ons for anything that's been deprecated except for APIs deprecated at level 1. While developers are still heavily encouraged to add wmllint support for level 1 deprecations, it is not required as these do not show deprecation warnings by default and are expected to continue working indefinitely.<br /> <br /> === Deprecation levels - When to remove deprecated features ===<br /> While creating simple compatibility wrappers should be possible most of the time, it would be unreasonable to assume that this approach will be viable in absolutely every case. Wesnoth's compatibility policy therefore has four different levels of deprecation which are used to set expectations for when and if an API is expected to be removed:<br /> <br /> #Deprecated indefinitely &amp;mdash; This deprecation level is for changes which have newer preferred alternatives but, barring any unforeseen issues, have little to no maintenance impact and should be kept indefinitely in order to reduce the work required for UMC authors to maintain their content. For example, functions or attributes which have had their names changed, macros which have been replaced with tags, or simple wrappers with little to no maintenance overhead. If future large scale changes make it impractical to maintain an API deprecated at this level then the deprecation level should be raised accordingly. This is generally the preferred deprecation level - higher deprecation levels are for APIs which are intended for eventual removal and must be weighed against the maintenance work this forces upon UMC authors.<br /> #Deprecated with the intention of future removal &amp;mdash; This deprecation level is for APIs which will be removed in a future version, but the version they are removed in has not yet have been decided. Barring urgent circumstances, all APIs that are deprecated with the intention of being removed '''must''' start with being deprecated at level 2 for 1-2 development cycles at minimum depending on the impact of the API's removal on UMC authors. Once the API has spent the necessary amount of time at deprecation level 2, it can be moved to deprecation level 3. It is not allowed to deprecate an API at level 2 and change it to level 3 in the same development cycle. There is no maximum amount of time that an API can remain deprecated at level 2.<br /> #Deprecated for removal in a specific version &amp;mdash; This deprecation level is for APIs which were previously deprecated at level 2 and now have a future version at which they will be removed. The version an API is removed in must be at least two development cycles after the API was deprecated at level 2. It is not allowed to move an API to deprecation level 3 and then remove it in the same development cycle.<br /> #Removed without deprecation &amp;mdash; This level should be used EXTREMELY rarely, and only in cases where it is ABSOLUTELY NECESSARY. Occasionally, an update to a feature will change the underlying architecture in such a fundamental way that the old paradigm cannot coexist with the new one no matter how much redundant code one would create. While this kind of scenario is extremely rare, and every effort should be made to find creative solutions to avoid it, there are occasionally cases where it truly is impossible to maintain both methods even in the short term. This level should only be used with broad developer consensus, after the majority of active developers familiar with the feature in question have given at least some thought to trying to deprecate gracefully and failed. This level should also be used for macro and method stubs containing only an error message describing what was removed and why.<br /> <br /> == Rationale ==<br /> The above policy is the result of a large amount of thought, discussion, and debate. Following is a brief outline of the considerations and goals on both sides of the problem, why there is an inherent conflict between them, some failed approaches to resolving the conflict, and how the final policy ultimately maximizes the pursuit of both goals.<br /> <br /> === The Problem - The paradox of progress ===<br /> Invariably, as development on any project moves forward, developers will realize that there are better, cleaner, or more elegant ways to structure things than they had been previously. These changes can be to improve efficiency, make an API more intuitive, keep code better organized, make common tasks more straightforward, or accomplish any number of other positive things. These changes can also make the development of additional features much more viable. In short, progress is good.<br /> <br /> On the other hand, a content-heavy program such as Wesnoth relies on the ability of content creators to efficiently create, maintain, and update their content. Too many changes all at once will force creators of existing content to spend obscene amounts time updating their creations just to keeping them up-to-date and in working order. This can lead to a high amount of frustration, a drop in motivation, and a decline in content being created. In short, progress is bad.<br /> <br /> === Backwards Compatibility - benefits and drawbacks ===<br /> Most of the time, older paradigms can still be maintained in a manner in which they coexist with the newer ones. This allows for existing content to continue functioning, while at the same time allowing and encouraging new content to be created using the newer methods. However, maintaining such code can be problematic in the following ways:<br /> #There may eventually be architectural changes a developer would want to make where the old method's square peg no longer fits, even forcibly, into the new method's round hole.<br /> #Having compatibility code hanging around may, depending on how it is implemented, mean that any updates made to the feature, module, or subsystem in question would have to made in both the new, cleaner design, and the older, poorly structured one, adding more work for developers.<br /> <br /> === The Naive Approach - Deprecate and remove everything old ===<br /> One approach to balancing old and new is to deprecate the old and slate its eventual removal after either a certain amount of time has passed or a certain number of subsequent versions have been released. This sounds good in theory, but in practice, there will be many changes which are minor or cosmetic in nature and which will add up. Things like replacing macros with WML tags, updating the name of an API call or order of parameters to be more consistent with other similar functions, or switching from a functional to an object-oriented structure are very good for organizational purposes, but will result in a large amount of maintenance required on the part of content creators to keep existing code operational, and for very little real gain. This approach invariably leads to the situation where so much is being changed from one version to the next that creators turn into maintainers, forced to spend nearly all of their time trying to stay ahead of the update curve in an attempt to keep their existing content working, and leaving them very little time and motivation to create new content. And of course, by the time they're finished painstakingly updating their existing code for every little change made for the current release, whoops, there's a new release with a whole slew of new changes that need accounting for. It simply becomes unmanageable.<br /> <br /> === The Naive Approach - Deprecate and remove only when necessary ===<br /> The opposite approach would be to keep all existing paradigms until they actively interfere with a new architecture or create a double-maintenance problem. While this approach does cut down on the maintenance burden by ensuring that content using an older design continues to work, it hinders progress by the fact that the moment at which it first becomes clear that an architectural or double-maintenance problem will occur is exactly the same moment at which keeping the old structure around becomes problematic. Beginning a deprecation cycle at that point and then having to &quot;wait out&quot; the old paradigm will cause an unacceptable delay in development.<br /> <br /> === The Middle Ground - Deprecate everything old, remove only when necessary ===<br /> Most of the time, older APIs can be implemented in terms of their newer, cleaner counterparts through the use of things like simple wrappers, parse-translators which re-write the older paradigm's code in terms of the new one, or other relatively low-maintenance &quot;set-it-and-forget-it&quot; approaches. These simple wrappers are not really detrimental to making progress, don't require updating when the new APIs internals are changed, and can usually be organized into their own files and/or modules so that they don't clutter the cleaner code. Many such wrappers will never truly present either of the backwards compatibility drawbacks mentioned above. As such, there is really no detriment to keeping them around indefinitely. However, occasionally, a new idea or approach will be put forth that updates the newer paradigm in such a way that the older one can no longer cleanly wrap to it. This usually happens, as inspiration is wont to do, suddenly, unexpectedly, and without warning. As such developers need the flexibility to be able to remove outdated code as freely as possible when the situation requires. Therefore, the ideal solution would be to deprecate any API which has newer, feature-complete ways to do it, while leaving it in the codebase until such time as its presence becomes a hindrance. Essentially, deprecation need not necessarily mean &quot;this WILL be removed&quot; so much as &quot;this is now a candidate for removal&quot;. By separating the concepts of deprecation and removal, both goals can be better served.<br /> <br /> === Undefined removal timeline - issues encountered ===<br /> In practice however, simply stating something is a candidate for removal while providing no further information on when it will actually be removed causes multiple issues:<br /> * When a deprecated API is causing a maintenance burden worthy of removal is a subjective decision, often leading to debates over removal any time a developer decides it's time for an API to be removed, initially deprecated, or moved to a higher deprecation level.<br /> * Lack of developer incentive to provide good documentation and support for the deprecation of the API given there's no particular timeline for when it will actually cause issues for UMC authors.<br /> * UMC authors often don't find out about deprecated APIs and so can't possibly migrate to the new APIs.<br /> * UMC authors aren't provided the documentation or tooling support needed to make updating their add-ons easier.<br /> * UMC authors may simply decide there's no reason to update to the new API even if they know it's deprecated and how to update their add-on. After all, why spend time updating APIs that may stick around forever?<br /> * Giving a version that an API '''may''' be removed instead of a version that it '''will''' be removed is not as clear as it may seem to UMC authors who aren't already aware of how Wesnoth handles deprecation. This can lead to UMC authors ignoring deprecation warnings after seeing such warnings for APIs which provide a version that's years old.<br /> <br /> === Certainty is also a benefit ===<br /> Wesnoth continues to exist today in large part because of the content made by its community. As such, developers should always be sparing in what they choose to deprecate and what they choose to remove, so that UMC authors can update their content to the latest version of Wesnoth without needing to make a herculean effort every couple of years.<br /> <br /> But, for cases where APIs are removed, the benefit of providing certainty for when that will happen outweighs the flexibility of being able remove them at any time after they been marked as deprecated. It encourages developers to provide the documentation and tooling support to make it easier for UMC authors to update their add-ons, and it lets UMC authors know when they can expect deprecated APIs to be removed rather than it effectively happening at random when a developer decides a deprecated API needs to be dropped.<br /> <br /> === More Complex Cases - One size does not fit all ===<br /> There may, however, be cases where the obsolete API cannot be implemented cleanly in terms of the updated one and must be maintained separately, or, in extremely rare cases, cannot coexist at all. There needs to be some leeway for such cases as well. In the former case, it therefore makes sense to allow for a feature to be deprecated pending removal after the shortest reasonable deprecation period. In the latter case, there is obviously no choice but to make the change and remove the old immediately. Developers should, naturally, be encouraged to find creative solutions to avoid such cases, but it is inevitable that there will eventually be a few cases where no graceful transition procedure can be found. These more aggressive forms of deprecation should only be done with developer consensus, and only after all options of creating a backwards-compatible transition have been exhausted.<br /> <br /> === Graphics - The exception that proves the rule ===<br /> The one area where backwards compatibility should NOT be a factor is graphical changes. Any change to the terrain graphics, unit sprites, or portrait images has the potential to result in visually-incompatible custom content. Core content creators cannot be expected to maintain a deprecated visual style alongside a more modern one, as any approach toward doing so would add an unreasonable amount of bloat and overhead, and make it very difficult for core graphics to be updated without having to do double the work. In addition, add-ons will continue to function even with such visual incompatibilities present, they just won't look right. As such, it can be said that stylistic incompatibilities fall more within the realm of content than of code, and it is not unreasonable to expect a content creator to... well... create content. Expecting the graphical style to remain backwards-compatible would be just as unreasonable as expecting stories, help descriptions, or other forms of lore to never change because they may introduce plot holes into add-on stories. Essentially, since the goal of the software portion of Wesnoth is, at its heart, merely to facilitate the creation and advancement of this kind of content, core content needs to be free to develop unhindered by considerations for add-on content.</div>

Pentarctagon https://wiki.wesnoth.org/index.php?title=CompatibilityStandardsV2&diff=74987 2026-04-20T22:54:33Z

<p>Pentarctagon: /* Deprecation levels - When to remove deprecated features */</p> <hr /> <div>As a piece of software matures, there are often new designs, paradigms, and idioms developed which are superior to old ones. This creates an inherent conflict between the need for progress and the need for compatibility. Wesnoth is no exception. This document describes Wesnoth's approach toward resolving that conflict in a way which is most beneficial to both goals, as well as the rationale behind this approach.<br /> <br /> == Policy ==<br /> This policy defines how the creation of new Wesnoth APIs and the deprecation and removal of old ones are to be handled. For the purposes of this document &quot;API&quot; means &quot;any technical channel by which a content creator interacts with the game engine&quot;. This includes, but is not limited to: preprocessor macros, WML tags, WFL functions, IPFs, and the Lua API. Note that this policy applies only to software APIs. Core content such as sprites, portraits, animations, lore, etc. are to be updated freely, without consideration for stylistic or literary conflicts that such content changes may present to add-ons.<br /> <br /> === When to deprecate ===<br /> ==== Adding a better API ====<br /> Any time a superior API is introduced which has '''complete feature-parity''' with an existing API, the old one should be immediately deprecated. Note that in most cases, in order to be considered to have &quot;complete feature-parity&quot;, the API should be available in the same language or area of the code as the obsolete one was. For example, the introduction of a more powerful API in Lua which can accomplish a superset of the functionality which had previously been available with a certain WML tag would not obsolete that WML tag. Exceptions can be made to this rule in cases where it is clear that the feature does not make a lot of sense in its current language or area, and was merely there for legacy reasons (such as the proper place for it not having been introduced yet at the time of its creation). Such exceptions should be determined by developer consensus.<br /> <br /> ==== Preventing needed fixes or improvements ====<br /> In such cases where a feature is preventing an important new feature from being added or makes it impossible to fix a problem impacting players, it can be preferable to deprecate the API to allow for the necessary changes to be made. APIs deprecated for this reason should still follow the deprecation schedule as normal, unless the fix or improvement is urgently needed.<br /> <br /> ==== Actively harmful ====<br /> If an API is found to cause significant problems for players or UMC authors, such as being prone to causing crashes while also very difficult to properly fix, corrupting saves and replays when not used correctly while being difficult to use correctly, or other similar situations, then such APIs should be deprecated and removed regardless of whether there is a replacement available.<br /> <br /> ==== Security ====<br /> If an API is found to have a security flaw that can't be fixed, then it should not be deprecated, it should be immediately removed.<br /> <br /> ==== Unused ====<br /> Any API that is not used in mainline and also is not used by the most recent version of an add-on on the add-ons server of the current or previous stable release can be deprecated. For example, if an add-on for 1.16 uses a deprecated API but the updated version of the add-on for 1.18 does not, then that add-on is not considered as currently using the API. Once deprecated for this reason, a new add-on being uploaded that uses the API is not a reason to undeprecate it.<br /> <br /> This does not need to be a passive process where developers simply check the add-ons server for whether an API is used - developers who want to deprecate an API for removal can proactively talk to and work with UMC authors to help update their add-ons to remove usage of said API. This can be anything from talking with them online about how to update to submitting updated code directly (ie: opening a PR against an add-on's public git repository).<br /> <br /> Deprecating and then removing APIs that are unused is the most preferred approach since their removal does not have any impact on UMC authors.<br /> <br /> === When NOT to deprecate ===<br /> ==== Style ====<br /> Deprecation should not be done purely for reasons of style. This is very subjective and prone to change as new contributors join and current contributors leave or become less active. As such, allowing deprecation for stylistic reasons would lead to entirely unnecessary work for UMC authors as developer preferences change over time.<br /> <br /> ==== Renaming ====<br /> While there can be exceptions, it is rarely a net positive to deprecate an API simply for the sake of renaming it to something else. It is preferable to either add a second name for the same function, leaving the old name as-is, or simply live with the current name rather than expecting all UMC authors using the API to update to the new name.<br /> <br /> ==== Any other reason ====<br /> Accepted reasons for deprecating APIs should be something that's discussed and agreed upon by the development team while also, ideally, including UMC authors. It should not become the norm that additional reasons to deprecate APIs are treated as exceptions and left as an increasingly forgotten discussion on Discord, IRC, or the forums - they should be added to here with the reasoning behind them.<br /> <br /> === Deprecation awareness ===<br /> ==== Conflicting goals ====<br /> When deprecating APIs there is an inherent conflict in terms of how to make UMC authors aware of the deprecation. After all, if they aren't aware something is deprecated, they can't know they may need to update their add-on. Therefore, deprecations need to be displayed in a place where they will see them and most UMC authors don't look at Wesnoth's logs unless there's some other issue they're investigating. At the same time, deprecation warnings aren't relevant to players and spamming deprecation warnings is not an effective way of communicating what the issues are.<br /> <br /> ==== A middle ground ====<br /> Each deprecated feature should make use of an appropriate deprecation function call for that language or subsystem to ensure that the appropriate deprecation notice is printed to the log output. Additionally, deprecation warnings should be displayed in-game in the following cases:<br /> * If the player is running a development version, level 3 and level 4 deprecations should be shown in-game by default.<br /> * If the player enables debug mode then all deprecation warnings should be shown, regardless of whether they're using a stable release or a development release.<br /> <br /> ==== Documentation ====<br /> It is also not enough to only display a warning at runtime when something deprecated is encountered. It is the responsibility of the development team to proactively make UMC authors aware of the deprecations and removals being done. To accomplish this:<br /> * When an API is deprecated, and again if it's later removed, its deprecation or removal must be documented in the appropriate section of the changelog for the version it was deprecated or removed in.<br /> * Likewise, it should be added to https://wiki.wesnoth.org/CompatibilityBreakingChanges<br /> <br /> Additionally, it is not enough to simply say that an API is deprecated. In the deprecation message itself as well as in the changelog and https://wiki.wesnoth.org/CompatibilityBreakingChanges, a description must be included as to why it was deprecated or removed and how UMC authors can update their add-ons to address it.<br /> <br /> Lastly, it should be understood that &quot;removed&quot; doesn't necessarily mean that the API is entirely gone from Wesnoth's codebase. There is no maintenance burden to keeping macro or method stubs that do nothing aside from printing an error message describing what was removed and why. Keeping such stubs around is highly encouraged as it is helpful for UMC authors trying to update very old add-ons to the current version of Wesnoth.<br /> <br /> === How to deprecate ===<br /> Every effort should be made to create the simplest possible wrappers which will translate from an obsolete API to the updated one. Such wrappers should ideally be organized into their own compatibility file or module, and set up in such a way that the internals of the updated API will not affect how the old calls get wrapped to the new one. Essentially, the idea is to create a set-it-and-forget-it compatibility wrapper which will continue to work regardless of updates made to the newer API.<br /> <br /> Additionally, in all cases where it's practical, the wmllint tool must be updated to be able to automatically handle updating add-ons for anything that's been deprecated except for APIs deprecated at level 1. While developers are still heavily encouraged to add wmllint support for level 1 deprecations, it is not required as these do not show deprecation warnings by default and are expected to continue working indefinitely.<br /> <br /> === Deprecation levels - When to remove deprecated features ===<br /> While creating simple compatibility wrappers should be possible most of the time, it would be unreasonable to assume that this approach will be viable in absolutely every case. Wesnoth's compatibility policy therefore has four different levels of deprecation which are used to set expectations for when and if an API is expected to be removed:<br /> <br /> #Deprecated indefinitely &amp;mdash; This deprecation level is for changes which have newer preferred alternatives but, barring any unforeseen issues, have little to no maintenance impact and should be kept indefinitely in order to reduce the work required for UMC authors to maintain their content. For example, functions or attributes which have had their names changed, macros which have been replaced with tags, or simple wrappers with little to no maintenance overhead. If future large scale changes make it impractical to maintain an API deprecated at this level then the deprecation level should be raised accordingly. This is generally the preferred deprecation level - higher deprecation levels are for APIs which are intended for eventual removal and must be weighed against the maintenance work this forces upon UMC authors.<br /> #Deprecated with the intention of future removal &amp;mdash; This deprecation level is for APIs which will be removed in a future version, but the version they are removed in has not yet have been decided. Barring urgent circumstances, all APIs that are deprecated with the intention of being removed '''must''' start with being deprecated at level 2 for 1-2 development cycles at minimum depending on the impact of the API's removal on UMC authors. Once the API has spent the necessary amount of time at deprecation level 2, it can be moved to deprecation level 3. It is not allowed to deprecate an API at level 2 and change it to level 3 in the same development cycle. There is no maximum amount of time that an API can remain deprecated at level 2.<br /> #Deprecated for removal in a specific version &amp;mdash; This deprecation level is for APIs which were previously deprecated at level 2 and now have a future version at which they will be removed. The version an API is removed in must be at least two development cycles after the API was deprecated at level 2. It is not allowed to move an API to deprecation level 3 and then remove it in the same development cycle.<br /> #Removed without deprecation &amp;mdash; This level should be used EXTREMELY rarely, and only in cases where it is ABSOLUTELY NECESSARY. Occasionally, an update to a feature will change the underlying architecture in such a fundamental way that the old paradigm cannot coexist with the new one no matter how much redundant code one would create. While this kind of scenario is extremely rare, and every effort should be made to find creative solutions to avoid it, there are occasionally cases where it truly is impossible to maintain both methods even in the short term. This level should only be used with broad developer consensus, after the majority of active developers familiar with the feature in question have given at least some thought to trying to deprecate gracefully and failed.<br /> <br /> This level should also be used for macro and method stubs containing only an error message describing what was removed and why.<br /> <br /> == Rationale ==<br /> The above policy is the result of a large amount of thought, discussion, and debate. Following is a brief outline of the considerations and goals on both sides of the problem, why there is an inherent conflict between them, some failed approaches to resolving the conflict, and how the final policy ultimately maximizes the pursuit of both goals.<br /> <br /> === The Problem - The paradox of progress ===<br /> Invariably, as development on any project moves forward, developers will realize that there are better, cleaner, or more elegant ways to structure things than they had been previously. These changes can be to improve efficiency, make an API more intuitive, keep code better organized, make common tasks more straightforward, or accomplish any number of other positive things. These changes can also make the development of additional features much more viable. In short, progress is good.<br /> <br /> On the other hand, a content-heavy program such as Wesnoth relies on the ability of content creators to efficiently create, maintain, and update their content. Too many changes all at once will force creators of existing content to spend obscene amounts time updating their creations just to keeping them up-to-date and in working order. This can lead to a high amount of frustration, a drop in motivation, and a decline in content being created. In short, progress is bad.<br /> <br /> === Backwards Compatibility - benefits and drawbacks ===<br /> Most of the time, older paradigms can still be maintained in a manner in which they coexist with the newer ones. This allows for existing content to continue functioning, while at the same time allowing and encouraging new content to be created using the newer methods. However, maintaining such code can be problematic in the following ways:<br /> #There may eventually be architectural changes a developer would want to make where the old method's square peg no longer fits, even forcibly, into the new method's round hole.<br /> #Having compatibility code hanging around may, depending on how it is implemented, mean that any updates made to the feature, module, or subsystem in question would have to made in both the new, cleaner design, and the older, poorly structured one, adding more work for developers.<br /> <br /> === The Naive Approach - Deprecate and remove everything old ===<br /> One approach to balancing old and new is to deprecate the old and slate its eventual removal after either a certain amount of time has passed or a certain number of subsequent versions have been released. This sounds good in theory, but in practice, there will be many changes which are minor or cosmetic in nature and which will add up. Things like replacing macros with WML tags, updating the name of an API call or order of parameters to be more consistent with other similar functions, or switching from a functional to an object-oriented structure are very good for organizational purposes, but will result in a large amount of maintenance required on the part of content creators to keep existing code operational, and for very little real gain. This approach invariably leads to the situation where so much is being changed from one version to the next that creators turn into maintainers, forced to spend nearly all of their time trying to stay ahead of the update curve in an attempt to keep their existing content working, and leaving them very little time and motivation to create new content. And of course, by the time they're finished painstakingly updating their existing code for every little change made for the current release, whoops, there's a new release with a whole slew of new changes that need accounting for. It simply becomes unmanageable.<br /> <br /> === The Naive Approach - Deprecate and remove only when necessary ===<br /> The opposite approach would be to keep all existing paradigms until they actively interfere with a new architecture or create a double-maintenance problem. While this approach does cut down on the maintenance burden by ensuring that content using an older design continues to work, it hinders progress by the fact that the moment at which it first becomes clear that an architectural or double-maintenance problem will occur is exactly the same moment at which keeping the old structure around becomes problematic. Beginning a deprecation cycle at that point and then having to &quot;wait out&quot; the old paradigm will cause an unacceptable delay in development.<br /> <br /> === The Middle Ground - Deprecate everything old, remove only when necessary ===<br /> Most of the time, older APIs can be implemented in terms of their newer, cleaner counterparts through the use of things like simple wrappers, parse-translators which re-write the older paradigm's code in terms of the new one, or other relatively low-maintenance &quot;set-it-and-forget-it&quot; approaches. These simple wrappers are not really detrimental to making progress, don't require updating when the new APIs internals are changed, and can usually be organized into their own files and/or modules so that they don't clutter the cleaner code. Many such wrappers will never truly present either of the backwards compatibility drawbacks mentioned above. As such, there is really no detriment to keeping them around indefinitely. However, occasionally, a new idea or approach will be put forth that updates the newer paradigm in such a way that the older one can no longer cleanly wrap to it. This usually happens, as inspiration is wont to do, suddenly, unexpectedly, and without warning. As such developers need the flexibility to be able to remove outdated code as freely as possible when the situation requires. Therefore, the ideal solution would be to deprecate any API which has newer, feature-complete ways to do it, while leaving it in the codebase until such time as its presence becomes a hindrance. Essentially, deprecation need not necessarily mean &quot;this WILL be removed&quot; so much as &quot;this is now a candidate for removal&quot;. By separating the concepts of deprecation and removal, both goals can be better served.<br /> <br /> === Undefined removal timeline - issues encountered ===<br /> In practice however, simply stating something is a candidate for removal while providing no further information on when it will actually be removed causes multiple issues:<br /> * When a deprecated API is causing a maintenance burden worthy of removal is a subjective decision, often leading to debates over removal any time a developer decides it's time for an API to be removed, initially deprecated, or moved to a higher deprecation level.<br /> * Lack of developer incentive to provide good documentation and support for the deprecation of the API given there's no particular timeline for when it will actually cause issues for UMC authors.<br /> * UMC authors often don't find out about deprecated APIs and so can't possibly migrate to the new APIs.<br /> * UMC authors aren't provided the documentation or tooling support needed to make updating their add-ons easier.<br /> * UMC authors may simply decide there's no reason to update to the new API even if they know it's deprecated and how to update their add-on. After all, why spend time updating APIs that may stick around forever?<br /> * Giving a version that an API '''may''' be removed instead of a version that it '''will''' be removed is not as clear as it may seem to UMC authors who aren't already aware of how Wesnoth handles deprecation. This can lead to UMC authors ignoring deprecation warnings after seeing such warnings for APIs which provide a version that's years old.<br /> <br /> === Certainty is also a benefit ===<br /> Wesnoth continues to exist today in large part because of the content made by its community. As such, developers should always be sparing in what they choose to deprecate and what they choose to remove, so that UMC authors can update their content to the latest version of Wesnoth without needing to make a herculean effort every couple of years.<br /> <br /> But, for cases where APIs are removed, the benefit of providing certainty for when that will happen outweighs the flexibility of being able remove them at any time after they been marked as deprecated. It encourages developers to provide the documentation and tooling support to make it easier for UMC authors to update their add-ons, and it lets UMC authors know when they can expect deprecated APIs to be removed rather than it effectively happening at random when a developer decides a deprecated API needs to be dropped.<br /> <br /> === More Complex Cases - One size does not fit all ===<br /> There may, however, be cases where the obsolete API cannot be implemented cleanly in terms of the updated one and must be maintained separately, or, in extremely rare cases, cannot coexist at all. There needs to be some leeway for such cases as well. In the former case, it therefore makes sense to allow for a feature to be deprecated pending removal after the shortest reasonable deprecation period. In the latter case, there is obviously no choice but to make the change and remove the old immediately. Developers should, naturally, be encouraged to find creative solutions to avoid such cases, but it is inevitable that there will eventually be a few cases where no graceful transition procedure can be found. These more aggressive forms of deprecation should only be done with developer consensus, and only after all options of creating a backwards-compatible transition have been exhausted.<br /> <br /> === Graphics - The exception that proves the rule ===<br /> The one area where backwards compatibility should NOT be a factor is graphical changes. Any change to the terrain graphics, unit sprites, or portrait images has the potential to result in visually-incompatible custom content. Core content creators cannot be expected to maintain a deprecated visual style alongside a more modern one, as any approach toward doing so would add an unreasonable amount of bloat and overhead, and make it very difficult for core graphics to be updated without having to do double the work. In addition, add-ons will continue to function even with such visual incompatibilities present, they just won't look right. As such, it can be said that stylistic incompatibilities fall more within the realm of content than of code, and it is not unreasonable to expect a content creator to... well... create content. Expecting the graphical style to remain backwards-compatible would be just as unreasonable as expecting stories, help descriptions, or other forms of lore to never change because they may introduce plot holes into add-on stories. Essentially, since the goal of the software portion of Wesnoth is, at its heart, merely to facilitate the creation and advancement of this kind of content, core content needs to be free to develop unhindered by considerations for add-on content.</div>

Pentarctagon https://wiki.wesnoth.org/index.php?title=CompatibilityStandardsV2&diff=74986 2026-04-19T02:40:35Z

<p>Pentarctagon: Created page with &quot;As a piece of software matures, there are often new designs, paradigms, and idioms developed which are superior to old ones. This creates an inherent conflict between the need...&quot;</p> <hr /> <div>As a piece of software matures, there are often new designs, paradigms, and idioms developed which are superior to old ones. This creates an inherent conflict between the need for progress and the need for compatibility. Wesnoth is no exception. This document describes Wesnoth's approach toward resolving that conflict in a way which is most beneficial to both goals, as well as the rationale behind this approach.<br /> <br /> == Policy ==<br /> This policy defines how the creation of new Wesnoth APIs and the deprecation and removal of old ones are to be handled. For the purposes of this document &quot;API&quot; means &quot;any technical channel by which a content creator interacts with the game engine&quot;. This includes, but is not limited to: preprocessor macros, WML tags, WFL functions, IPFs, and the Lua API. Note that this policy applies only to software APIs. Core content such as sprites, portraits, animations, lore, etc. are to be updated freely, without consideration for stylistic or literary conflicts that such content changes may present to add-ons.<br /> <br /> === When to deprecate ===<br /> ==== Adding a better API ====<br /> Any time a superior API is introduced which has '''complete feature-parity''' with an existing API, the old one should be immediately deprecated. Note that in most cases, in order to be considered to have &quot;complete feature-parity&quot;, the API should be available in the same language or area of the code as the obsolete one was. For example, the introduction of a more powerful API in Lua which can accomplish a superset of the functionality which had previously been available with a certain WML tag would not obsolete that WML tag. Exceptions can be made to this rule in cases where it is clear that the feature does not make a lot of sense in its current language or area, and was merely there for legacy reasons (such as the proper place for it not having been introduced yet at the time of its creation). Such exceptions should be determined by developer consensus.<br /> <br /> ==== Preventing needed fixes or improvements ====<br /> In such cases where a feature is preventing an important new feature from being added or makes it impossible to fix a problem impacting players, it can be preferable to deprecate the API to allow for the necessary changes to be made. APIs deprecated for this reason should still follow the deprecation schedule as normal, unless the fix or improvement is urgently needed.<br /> <br /> ==== Actively harmful ====<br /> If an API is found to cause significant problems for players or UMC authors, such as being prone to causing crashes while also very difficult to properly fix, corrupting saves and replays when not used correctly while being difficult to use correctly, or other similar situations, then such APIs should be deprecated and removed regardless of whether there is a replacement available.<br /> <br /> ==== Security ====<br /> If an API is found to have a security flaw that can't be fixed, then it should not be deprecated, it should be immediately removed.<br /> <br /> ==== Unused ====<br /> Any API that is not used in mainline and also is not used by the most recent version of an add-on on the add-ons server of the current or previous stable release can be deprecated. For example, if an add-on for 1.16 uses a deprecated API but the updated version of the add-on for 1.18 does not, then that add-on is not considered as currently using the API. Once deprecated for this reason, a new add-on being uploaded that uses the API is not a reason to undeprecate it.<br /> <br /> This does not need to be a passive process where developers simply check the add-ons server for whether an API is used - developers who want to deprecate an API for removal can proactively talk to and work with UMC authors to help update their add-ons to remove usage of said API. This can be anything from talking with them online about how to update to submitting updated code directly (ie: opening a PR against an add-on's public git repository).<br /> <br /> Deprecating and then removing APIs that are unused is the most preferred approach since their removal does not have any impact on UMC authors.<br /> <br /> === When NOT to deprecate ===<br /> ==== Style ====<br /> Deprecation should not be done purely for reasons of style. This is very subjective and prone to change as new contributors join and current contributors leave or become less active. As such, allowing deprecation for stylistic reasons would lead to entirely unnecessary work for UMC authors as developer preferences change over time.<br /> <br /> ==== Renaming ====<br /> While there can be exceptions, it is rarely a net positive to deprecate an API simply for the sake of renaming it to something else. It is preferable to either add a second name for the same function, leaving the old name as-is, or simply live with the current name rather than expecting all UMC authors using the API to update to the new name.<br /> <br /> ==== Any other reason ====<br /> Accepted reasons for deprecating APIs should be something that's discussed and agreed upon by the development team while also, ideally, including UMC authors. It should not become the norm that additional reasons to deprecate APIs are treated as exceptions and left as an increasingly forgotten discussion on Discord, IRC, or the forums - they should be added to here with the reasoning behind them.<br /> <br /> === Deprecation awareness ===<br /> ==== Conflicting goals ====<br /> When deprecating APIs there is an inherent conflict in terms of how to make UMC authors aware of the deprecation. After all, if they aren't aware something is deprecated, they can't know they may need to update their add-on. Therefore, deprecations need to be displayed in a place where they will see them and most UMC authors don't look at Wesnoth's logs unless there's some other issue they're investigating. At the same time, deprecation warnings aren't relevant to players and spamming deprecation warnings is not an effective way of communicating what the issues are.<br /> <br /> ==== A middle ground ====<br /> Each deprecated feature should make use of an appropriate deprecation function call for that language or subsystem to ensure that the appropriate deprecation notice is printed to the log output. Additionally, deprecation warnings should be displayed in-game in the following cases:<br /> * If the player is running a development version, level 3 and level 4 deprecations should be shown in-game by default.<br /> * If the player enables debug mode then all deprecation warnings should be shown, regardless of whether they're using a stable release or a development release.<br /> <br /> ==== Documentation ====<br /> It is also not enough to only display a warning at runtime when something deprecated is encountered. It is the responsibility of the development team to proactively make UMC authors aware of the deprecations and removals being done. To accomplish this:<br /> * When an API is deprecated, and again if it's later removed, its deprecation or removal must be documented in the appropriate section of the changelog for the version it was deprecated or removed in.<br /> * Likewise, it should be added to https://wiki.wesnoth.org/CompatibilityBreakingChanges<br /> <br /> Additionally, it is not enough to simply say that an API is deprecated. In the deprecation message itself as well as in the changelog and https://wiki.wesnoth.org/CompatibilityBreakingChanges, a description must be included as to why it was deprecated or removed and how UMC authors can update their add-ons to address it.<br /> <br /> Lastly, it should be understood that &quot;removed&quot; doesn't necessarily mean that the API is entirely gone from Wesnoth's codebase. There is no maintenance burden to keeping macro or method stubs that do nothing aside from printing an error message describing what was removed and why. Keeping such stubs around is highly encouraged as it is helpful for UMC authors trying to update very old add-ons to the current version of Wesnoth.<br /> <br /> === How to deprecate ===<br /> Every effort should be made to create the simplest possible wrappers which will translate from an obsolete API to the updated one. Such wrappers should ideally be organized into their own compatibility file or module, and set up in such a way that the internals of the updated API will not affect how the old calls get wrapped to the new one. Essentially, the idea is to create a set-it-and-forget-it compatibility wrapper which will continue to work regardless of updates made to the newer API.<br /> <br /> Additionally, in all cases where it's practical, the wmllint tool must be updated to be able to automatically handle updating add-ons for anything that's been deprecated except for APIs deprecated at level 1. While developers are still heavily encouraged to add wmllint support for level 1 deprecations, it is not required as these do not show deprecation warnings by default and are expected to continue working indefinitely.<br /> <br /> === Deprecation levels - When to remove deprecated features ===<br /> While creating simple compatibility wrappers should be possible most of the time, it would be unreasonable to assume that this approach will be viable in absolutely every case. Wesnoth's compatibility policy therefore has four different levels of deprecation which are used to set expectations for when and if an API is expected to be removed:<br /> <br /> #Deprecated indefinitely &amp;mdash; This deprecation level is for changes which have newer preferred alternatives but, barring any unforeseen issues, have little to no maintenance impact and should be kept indefinitely in order to reduce the work required for UMC authors to maintain their content. For example, functions or attributes which have had their names changed, macros which have been replaced with tags, macro stubs containing only an error message describing what was removed and why, or simple wrappers with little to no maintenance overhead. If future large scale changes make it impractical to maintain an API deprecated at this level then the deprecation level should be raised accordingly. This is generally the preferred deprecation level - higher deprecation levels are for APIs which are intended for eventual removal and must be weighed against the maintenance work this forces upon UMC authors.<br /> #Deprecated with the intention of future removal &amp;mdash; This deprecation level is for APIs which will be removed in a future version, but the version they are removed in has not yet have been decided. Barring urgent circumstances, all APIs that are deprecated with the intention of being removed '''must''' start with being deprecated at level 2 for 1-2 development cycles at minimum depending on the impact of the API's removal on UMC authors. Once the API has spent the necessary amount of time at deprecation level 2, it can be moved to deprecation level 3. It is not allowed to deprecate an API at level 2 and change it to level 3 in the same development cycle. There is no maximum amount of time that an API can remain deprecated at level 2.<br /> #Deprecated for removal in a specific version &amp;mdash; This deprecation level is for APIs which were previously deprecated at level 2 and now have a future version at which they will be removed. The version an API is removed in must be at least two development cycles after the API was deprecated at level 2. It is not allowed to move an API to deprecation level 3 and then remove it in the same development cycle.<br /> #Removed without deprecation &amp;mdash; This level should be used EXTREMELY rarely, and only in cases where it is ABSOLUTELY NECESSARY. Occasionally, an update to a feature will change the underlying architecture in such a fundamental way that the old paradigm cannot coexist with the new one no matter how much redundant code one would create. While this kind of scenario is extremely rare, and every effort should be made to find creative solutions to avoid it, there are occasionally cases where it truly is impossible to maintain both methods even in the short term. This level should only be used with broad developer consensus, after the majority of active developers familiar with the feature in question have given at least some thought to trying to deprecate gracefully and failed.<br /> <br /> == Rationale ==<br /> The above policy is the result of a large amount of thought, discussion, and debate. Following is a brief outline of the considerations and goals on both sides of the problem, why there is an inherent conflict between them, some failed approaches to resolving the conflict, and how the final policy ultimately maximizes the pursuit of both goals.<br /> <br /> === The Problem - The paradox of progress ===<br /> Invariably, as development on any project moves forward, developers will realize that there are better, cleaner, or more elegant ways to structure things than they had been previously. These changes can be to improve efficiency, make an API more intuitive, keep code better organized, make common tasks more straightforward, or accomplish any number of other positive things. These changes can also make the development of additional features much more viable. In short, progress is good.<br /> <br /> On the other hand, a content-heavy program such as Wesnoth relies on the ability of content creators to efficiently create, maintain, and update their content. Too many changes all at once will force creators of existing content to spend obscene amounts time updating their creations just to keeping them up-to-date and in working order. This can lead to a high amount of frustration, a drop in motivation, and a decline in content being created. In short, progress is bad.<br /> <br /> === Backwards Compatibility - benefits and drawbacks ===<br /> Most of the time, older paradigms can still be maintained in a manner in which they coexist with the newer ones. This allows for existing content to continue functioning, while at the same time allowing and encouraging new content to be created using the newer methods. However, maintaining such code can be problematic in the following ways:<br /> #There may eventually be architectural changes a developer would want to make where the old method's square peg no longer fits, even forcibly, into the new method's round hole.<br /> #Having compatibility code hanging around may, depending on how it is implemented, mean that any updates made to the feature, module, or subsystem in question would have to made in both the new, cleaner design, and the older, poorly structured one, adding more work for developers.<br /> <br /> === The Naive Approach - Deprecate and remove everything old ===<br /> One approach to balancing old and new is to deprecate the old and slate its eventual removal after either a certain amount of time has passed or a certain number of subsequent versions have been released. This sounds good in theory, but in practice, there will be many changes which are minor or cosmetic in nature and which will add up. Things like replacing macros with WML tags, updating the name of an API call or order of parameters to be more consistent with other similar functions, or switching from a functional to an object-oriented structure are very good for organizational purposes, but will result in a large amount of maintenance required on the part of content creators to keep existing code operational, and for very little real gain. This approach invariably leads to the situation where so much is being changed from one version to the next that creators turn into maintainers, forced to spend nearly all of their time trying to stay ahead of the update curve in an attempt to keep their existing content working, and leaving them very little time and motivation to create new content. And of course, by the time they're finished painstakingly updating their existing code for every little change made for the current release, whoops, there's a new release with a whole slew of new changes that need accounting for. It simply becomes unmanageable.<br /> <br /> === The Naive Approach - Deprecate and remove only when necessary ===<br /> The opposite approach would be to keep all existing paradigms until they actively interfere with a new architecture or create a double-maintenance problem. While this approach does cut down on the maintenance burden by ensuring that content using an older design continues to work, it hinders progress by the fact that the moment at which it first becomes clear that an architectural or double-maintenance problem will occur is exactly the same moment at which keeping the old structure around becomes problematic. Beginning a deprecation cycle at that point and then having to &quot;wait out&quot; the old paradigm will cause an unacceptable delay in development.<br /> <br /> === The Middle Ground - Deprecate everything old, remove only when necessary ===<br /> Most of the time, older APIs can be implemented in terms of their newer, cleaner counterparts through the use of things like simple wrappers, parse-translators which re-write the older paradigm's code in terms of the new one, or other relatively low-maintenance &quot;set-it-and-forget-it&quot; approaches. These simple wrappers are not really detrimental to making progress, don't require updating when the new APIs internals are changed, and can usually be organized into their own files and/or modules so that they don't clutter the cleaner code. Many such wrappers will never truly present either of the backwards compatibility drawbacks mentioned above. As such, there is really no detriment to keeping them around indefinitely. However, occasionally, a new idea or approach will be put forth that updates the newer paradigm in such a way that the older one can no longer cleanly wrap to it. This usually happens, as inspiration is wont to do, suddenly, unexpectedly, and without warning. As such developers need the flexibility to be able to remove outdated code as freely as possible when the situation requires. Therefore, the ideal solution would be to deprecate any API which has newer, feature-complete ways to do it, while leaving it in the codebase until such time as its presence becomes a hindrance. Essentially, deprecation need not necessarily mean &quot;this WILL be removed&quot; so much as &quot;this is now a candidate for removal&quot;. By separating the concepts of deprecation and removal, both goals can be better served.<br /> <br /> === Undefined removal timeline - issues encountered ===<br /> In practice however, simply stating something is a candidate for removal while providing no further information on when it will actually be removed causes multiple issues:<br /> * When a deprecated API is causing a maintenance burden worthy of removal is a subjective decision, often leading to debates over removal any time a developer decides it's time for an API to be removed, initially deprecated, or moved to a higher deprecation level.<br /> * Lack of developer incentive to provide good documentation and support for the deprecation of the API given there's no particular timeline for when it will actually cause issues for UMC authors.<br /> * UMC authors often don't find out about deprecated APIs and so can't possibly migrate to the new APIs.<br /> * UMC authors aren't provided the documentation or tooling support needed to make updating their add-ons easier.<br /> * UMC authors may simply decide there's no reason to update to the new API even if they know it's deprecated and how to update their add-on. After all, why spend time updating APIs that may stick around forever?<br /> * Giving a version that an API '''may''' be removed instead of a version that it '''will''' be removed is not as clear as it may seem to UMC authors who aren't already aware of how Wesnoth handles deprecation. This can lead to UMC authors ignoring deprecation warnings after seeing such warnings for APIs which provide a version that's years old.<br /> <br /> === Certainty is also a benefit ===<br /> Wesnoth continues to exist today in large part because of the content made by its community. As such, developers should always be sparing in what they choose to deprecate and what they choose to remove, so that UMC authors can update their content to the latest version of Wesnoth without needing to make a herculean effort every couple of years.<br /> <br /> But, for cases where APIs are removed, the benefit of providing certainty for when that will happen outweighs the flexibility of being able remove them at any time after they been marked as deprecated. It encourages developers to provide the documentation and tooling support to make it easier for UMC authors to update their add-ons, and it lets UMC authors know when they can expect deprecated APIs to be removed rather than it effectively happening at random when a developer decides a deprecated API needs to be dropped.<br /> <br /> === More Complex Cases - One size does not fit all ===<br /> There may, however, be cases where the obsolete API cannot be implemented cleanly in terms of the updated one and must be maintained separately, or, in extremely rare cases, cannot coexist at all. There needs to be some leeway for such cases as well. In the former case, it therefore makes sense to allow for a feature to be deprecated pending removal after the shortest reasonable deprecation period. In the latter case, there is obviously no choice but to make the change and remove the old immediately. Developers should, naturally, be encouraged to find creative solutions to avoid such cases, but it is inevitable that there will eventually be a few cases where no graceful transition procedure can be found. These more aggressive forms of deprecation should only be done with developer consensus, and only after all options of creating a backwards-compatible transition have been exhausted.<br /> <br /> === Graphics - The exception that proves the rule ===<br /> The one area where backwards compatibility should NOT be a factor is graphical changes. Any change to the terrain graphics, unit sprites, or portrait images has the potential to result in visually-incompatible custom content. Core content creators cannot be expected to maintain a deprecated visual style alongside a more modern one, as any approach toward doing so would add an unreasonable amount of bloat and overhead, and make it very difficult for core graphics to be updated without having to do double the work. In addition, add-ons will continue to function even with such visual incompatibilities present, they just won't look right. As such, it can be said that stylistic incompatibilities fall more within the realm of content than of code, and it is not unreasonable to expect a content creator to... well... create content. Expecting the graphical style to remain backwards-compatible would be just as unreasonable as expecting stories, help descriptions, or other forms of lore to never change because they may introduce plot holes into add-on stories. Essentially, since the goal of the software portion of Wesnoth is, at its heart, merely to facilitate the creation and advancement of this kind of content, core content needs to be free to develop unhindered by considerations for add-on content.</div>

Pentarctagon https://wiki.wesnoth.org/index.php?title=CompatibilityBreakingChanges&diff=74974 2026-04-14T02:07:13Z

<p>Pentarctagon: Pentarctagon moved page User:Bssarkar/CompatibilityBreakingChanges to CompatibilityBreakingChanges</p> <hr /> <div>This lists removed WML functionality and helpful hints for avoiding pitfalls.<br /> <br /> The previous list is available [https://forums.wesnoth.org/viewtopic.php?t=58532 here].<br /> <br /> == Compatibility breaking changes between 1.18 and 1.19/1.20 ==<br /> <br /> === Compatibility breaking (requires updates to work) ===<br /> <br /> * '''[kill]''' now reduces target unit hitpoints to 0 before triggering '''last_breath, die''' events. This affects mentioned events that rely on [have_unit] conditions.<br /> * WFL Removed properties '''unit.side''' and '''terrain.owner'''. Use '''unit.side_number''' and '''terrain.owner_side''' instead. They return 1-indexed side, removed properties returned 0-indexed side.<br /> * Abilities with both '''add''' and '''sub''' now calculate value differently<br /> * rotate_loc_around formula now works<br /> * [era] with id=era_dunefolk does not exist anymore<br /> * [side]'s leader attribute has been removed<br /> * [side]'s [variables] tag is now used to set side variables. Use [side]'s [leader] tag to set a unit variable.<br /> * Setting gold to decimal value fails with error. Previously it was converted to int automatically. As of 1.19.21, automatic conversion is only done in [gold], but not in Lua or [modify_side].<br /> * The following macros were removed ([https://github.com/wesnoth/wesnoth/pull/11126 #11126])<br /> ** EARLY_FINISH_BONUS_NOTE<br /> ** NO_EARLY_FINISH_BONUS_NOTE<br /> ** NO_GOLD_CARRYOVER_NOTE<br /> ** NEW_GOLD_CARRYOVER_NOTE_100<br /> ** NEW_GOLD_CARRYOVER_NOTE_40<br /> ** NEW_GOLD_CARRYOVER_NOTE_20<br /> ** MISSILE_FRAME_FIREBALL<br /> ** MESSAGE<br /> ** STORY_PART_SPEECH<br /> ** LOYAL_UNDEAD_UNIT<br /> ** ON_SIGHTING<br /> ** MAKE_AI_SIDE_PERSISTENT<br /> ** DRAKE_FLYING_ANIM<br /> ** NO_INTERRUPT_NO_UNDO<br /> ** ENABLE_NIGHTBLADE<br /> <br /> === Deprecations (will continue to work for now) ===<br /> * rechange [experimental_filter_ability/active] and [experimental_filter_specials] to [filter_ability] and [filter_specials] and make &quot;experimental_&quot; deprecated.<br /> <br /> === New features (help fill this list, https://wiki.wesnoth.org/Special:WhatLinksHere/Template:DevFeature1.19) ===<br /> * StandardAbilityFilter, including [https://github.com/wesnoth/wesnoth/pull/7814 7814]<br /> * [resistance] min_value<br /> * [attack] alignment<br /> * New events '''unit_hits''', '''unit_misses'''<br /> * Positive '''attack_weight''' now affects weapon selection<br /> * Unit attack [effect]+Lua+formula API min_range and max_range<br /> * Lua unit attributes fearless and healthy<br /> * wesnoth.game_config shows some color-related values<br /> * wesnoth.units.rebuild<br /> * stringx.ends_with, stringx.starts_with<br /> * Unit formula new attributes objects, advancements_taken, traits_count, objects_count, advancements_taken_count, fearless, healthy<br /> * Formula functions lerp_index, ends_with, replace_all, starts_with, get_palette<br /> * Custom themes https://wiki.wesnoth.org/GUIToolkit#Custom_themes<br /> * Abilities and specials now support [event] (does not work correctly due to [issue]10819[/issue])<br /> * Ability &amp; Weapon specials registry ([https://github.com/wesnoth/wesnoth/pull/10644 10644]) (does not work correctly if ability contains [event] due to [issue]10819[/issue])<br /> * [effect][remove_specials]<br /> * Expose unit pick dialog to Lua as a simple API call ([https://github.com/wesnoth/wesnoth/pull/8829 8829])<br /> * [fire_event][data] can be accessed from other event as $data<br /> * Unit Type Editor<br /> * [era]auto_sort allows to use custom faction ordering<br /> * [terrain_defaults] formula is now working as expected in case formula evaluates to null<br /> * [set_menu_item] description substitutes variables when rightclick is used<br /> * [defense]<br /> * [resistance_defaults] is not causing OOS in random maps anymore<br /> * Ability/weapon special descriptions support po variables in descriptions like '''$add''', '''$sub''' etc that contain the value of the relevant key. ([https://github.com/wesnoth/wesnoth/pull/10053 10053], [https://github.com/wesnoth/wesnoth/pull/10293 10293], [https://github.com/wesnoth/wesnoth/pull/10749 10749])<br /> * Ability/weapon special help page ids now follow the format: '''ability_&lt;unique_id&gt;''' or '''weaponspecial_&lt;unique_id&gt;''' ([https://github.com/wesnoth/wesnoth/pull/11012 11012]).<br /> * A lot more functions were added to https://wiki.wesnoth.org/LuaAPI/types/widget with https://wiki.wesnoth.org/index.php?title=LuaAPI%2Ftypes%2Fwidget&amp;type=revision&amp;diff=74843&amp;oldid=74842</div>

Pentarctagon https://wiki.wesnoth.org/index.php?title=User:Bssarkar/CompatibilityBreakingChanges&diff=74975 2026-04-14T02:07:13Z

<p>Pentarctagon: Pentarctagon moved page User:Bssarkar/CompatibilityBreakingChanges to CompatibilityBreakingChanges</p> <hr /> <div>#REDIRECT [[CompatibilityBreakingChanges]]</div>

Pentarctagon https://wiki.wesnoth.org/index.php?title=PreprocessorRef&diff=74973 2026-04-13T15:42:13Z

<p>Pentarctagon: /* #deprecated */</p> <hr /> <div>{{WML Tags}}<br /> == Overview ==<br /> <br /> Wesnoth loads just one configuration file directly: '''data/_main.cfg'''. However, the '''WML preprocessor''' allows the inclusion of more files. Whenever a WML file is read by Wesnoth, it is passed through the preprocessor.<br /> <br /> The preprocessor can interpret a simple language of string expansions known as ''macros''. A macro should always be defined '''before''' the place where it needs to be used.<br /> <br /> The preprocessor is applied recursively, so included files will be parsed for macros, and after macro expansion will be parsed for macros again, and so on. As a result, you should not write a recursive macro that references itself, because it will cause errors (but, alas, not necessarily error messages).<br /> <br /> == Preprocessor directives ==<br /> <br /> The following directives are used to create and use ''macros'', i.e. shortcuts which reduce repetition of information. See [https://www.wesnoth.org/macro-reference.html the macro reference] for the list of predefined core macros.<br /> <br /> Macros have scoping rules such that addons have separate preprocessing contexts, meaning that they can be overridden however an author of UMC wishes to override them, without worrying about breaking other add-ons.<br /> <br /> The preprocessor has changed several times, so don't expect old Wesnoth versions to behave exactly the same as the current stable and development series.<br /> <br /> '''Note:''' In multiplayer scenarios, these directives will appear to work only for the host and not for other clients. This is because the preprocessor is run only on the host, and the clients receive the resultant WML from the server. It's particularly important to keep this in mind before using preprocessor conditionals.<br /> <br /> === #define ===<br /> <br /> '''Syntax: #define ''symbol'' [''parameters''] ''&lt;newline&gt;'' ''substitution'' #enddef'''<br /> <br /> All subsequent occurences of '''{''symbol'' [''arguments'']}''' (see below) will be replaced by the contents of the ''substitution'' block, with all occurrences of any parameter {''parameter''} within ''substitution'' replaced by the corresponding value in ''arguments''. &lt;code&gt;#define-#enddef&lt;/code&gt; blocks cannot be nested inside another &lt;code&gt;#define&lt;/code&gt;, as of Wesnoth 1.19.<br /> <br /> As an example, the ENEMY_UNIT macro for the [[#Macro inclusions|macro inclusion]] example below could be defined as follows:<br /> <br /> &lt;syntaxhighlight lang=&quot;wml&quot;&gt;<br /> #define ENEMY_UNIT TYPE X Y<br /> ## the ordering above is important, since the preprocessor does not distinguish<br /> ## data into different types; only the ordering is used to determine which<br /> ## arguments apply to which parameters.<br /> [unit]<br /> type={TYPE} ## the unit will be of type TYPE, so different<br /> ## instantiations<br /> ## of this macro can create different units.<br /> x={X}<br /> y={Y}<br /> side=2 ## the unit will be an enemy, regardless of the parameter<br /> ## values. This reduces &quot;repetition of information&quot;,<br /> ## since it is no longer necessary to specify<br /> ## each created unit as an enemy.<br /> [/unit]<br /> #enddef<br /> &lt;/syntaxhighlight&gt;<br /> <br /> (See [[SingleUnitWML]] for further information on creating units using WML.)<br /> <br /> '''Important note:''' Although macros may look like they're simplifying the code, they do not help with wml bloating. Macros are very good at ''disguising'' WML bloat, but they do nothing to ''alleviate'' it. So instead of using macros to generate redundant and repetitive instructions, you should be considering how to eliminate redundancy through programming techniques of abstraction. The most popular way to improve your code is using custom [[EventWML|events]] and [[InternalActionsWML#.5Bfire_event.5D|fire_event]] tags. See also: [[Wml_optimisation|WML Optimisation]].<br /> <br /> ==== Whitespace in Macros ====<br /> <br /> When expanding a macro, '''''all''''' whitespace in the definition of the macro is preserved. The &lt;tt&gt;#arg&lt;/tt&gt; declarations for optional arguments are removed including the final newline. The body of the optional argument (the default value) is similarly processed just as if it were a macro, so all whitespace is preserved.<br /> <br /> There are two main practical implications of these rules:<br /> <br /> * When using a macro to define simple constants to be used inline in the middle of an attribute value, the entire content and the &lt;tt&gt;#enddef&lt;/tt&gt; must be on one line, like so:<br /> : &lt;syntaxhighlight lang=wml&gt;<br /> #define MY_CONSTANT<br /> 42#enddef&lt;/syntaxhighlight&gt;<br /> * If using a macro inside a quoted string, you should not indent the contents of the macro, as the indentation will be preserved upon macro substitution.<br /> * Similarly if you use an optional argument in the middle of an attribute value, the entire content and the &lt;tt&gt;#endarg&lt;/tt&gt; must be on one line, like so:<br /> : &lt;syntaxhighlight lang=wml&gt;<br /> #define MY_MACRO<br /> #arg OPTIONAL_ARG<br /> default#endarg<br /> key = &quot;composite {OPTIONAL_ARG} value&quot;<br /> #enddef&lt;/syntaxhighlight&gt;<br /> <br /> === #arg ===<br /> <br /> {{DevFeature1.13|7}} <br /> <br /> '''Syntax: #arg ''symbol'' ''&lt;newline&gt;'' ''default value'' #endarg'''<br /> <br /> Defines an optional argument for a macro along with its default value. Optional arguments can be used to make a macro more flexible and to allow its user to specify certain parameters only when necessary.<br /> <br /> For example, one could define a shortcut macro for [message] with only one required argument (the text displayed), but several optional ones:<br /> <br /> &lt;syntaxhighlight lang=&quot;wml&quot;&gt;<br /> #define MESSAGE TEXT<br /> <br /> #arg SPEAKER_ID<br /> narrator#endarg<br /> <br /> #arg CAPTION<br /> #endarg<br /> <br /> #arg SOUND<br /> #endarg<br /> <br /> #arg IMG<br /> #endarg<br /> <br /> [message]<br /> speaker={SPEAKER_ID}<br /> message={TEXT}<br /> caption={CAPTION}<br /> sound={SOUND}<br /> image={IMG}<br /> [/message]<br /> #enddef<br /> &lt;/syntaxhighlight&gt;<br /> <br /> The caller of the macro can then decide which, if any, of the default values to override:<br /> &lt;syntaxhighlight lang=&quot;wml&quot;&gt;<br /> {MESSAGE _&quot;Halt!&quot; SPEAKER_ID=&quot;Guard Captain&quot;}<br /> {MESSAGE _&quot;Two days pass...&quot; IMG=wesnoth-icon.png SOUND=ambient/morning.ogg}<br /> {MESSAGE _&quot;...&quot;}<br /> {MESSAGE _&quot;Welcome!&quot; CAPTION=_&quot;Elóndra's shop of wonders&quot; IMG=portraits/elves/shyde.png}<br /> {MESSAGE _&quot;*smash*&quot; SPEAKER_ID=&quot;Bridge Troll&quot; SOUND=mace.ogg}<br /> &lt;/syntaxhighlight&gt;<br /> <br /> For a multiline optional argument defined and called as follows:<br /> &lt;syntaxhighlight lang=&quot;wml&quot;&gt;<br /> #define MY_MACRO<br /> #arg MULTILINE<br /> [some_tag]<br /> some_attribute = &quot;some value&quot;<br /> [/some_tag]<br /> #endarg<br /> ...<br /> #enddef<br /> <br /> {MY_MACRO (MULTILINE=[other_tag]<br /> other_attribute = &quot;other value&quot;<br /> [/other_tag])}<br /> &lt;/syntaxhighlight&gt;<br /> <br /> '''Note:''' As with #enddef, the final line break before #endarg is included in the default value. This means that if the symbol is used in the middle of a line, you should place the #endarg immediately after the value has ended, without a line break in between.<br /> <br /> === #undef ===<br /> <br /> '''Syntax:''' '''#undef ''symbol'' '''<br /> <br /> Removes the previous definition of the macro named ''symbol''. Wesnoth expects this to be done when overriding an existing macro, and will warn you if you redefine an existing macro without an explicit #undef before it.<br /> <br /> === Inclusion directive {} ===<br /> <br /> This directive can be used to include macros, single files or sets of files from a target directory.<br /> <br /> ==== File/directory inclusions ====<br /> <br /> '''Syntax: {''path''}'''<br /> <br /> Includes the file with the specified ''path'', which will in turn run the preprocessor on it and perform any required substitutions or inclusions within it. The ''path'' may not contain ''..'' or the inclusion will be skipped.<br /> <br /> The exact location in which the ''path'' will be resolved will depend on its prefix:<br /> <br /> * '''{''path''}''': If ''path'' isn't a known macro (see below), the game will assume it's a relative path to a file in the main game '''data/''' directory and include it.<br /> * '''{~''path''}''': As above, but instead of the game data directory, the path is resolved relative to the user '''data/''' directory, where user made add-ons can normally be found.<br /> * '''{./''path''}''': The path is resolved relative to the location of the current file containing this inclusion.<br /> <br /> Information for locating the user data and game data directories can be found in [[EditingWesnoth]].<br /> <br /> Forward slashes ('''/''') should '''always''' be used as the path delimiter, even if your platform uses a different symbol such as colons (''':''') or backslashes ('''\''')! It is also very important to respect the '''actual letter case''' used to name files and directories for compatibility with case-sensitive filesystems on Unix-based operating systems.<br /> <br /> When ''path'' points to a directory instead of a file, the preprocessor will include all files found within with the '''.cfg''' extension, in alphabetical order; files without this extension (such as '''.map''' or '''.png''' files) are ignored.<br /> <br /> Some directories are handled in a special fashion according to their contents:<br /> <br /> * If there's a file named '''_main.cfg''' in the target directory, only that file will be included and preprocessed. It may include other files from its own directory or subdirectories within it, of course. This is used for managing WML directories as self-contained packages, like user made add-ons.<br /> * If there are files named '''_main.cfg''' in subdirectories of the target and there isn't one in the target itself, they will be all preprocessed. Given the following layout:<br /> dir/<br /> dir/a/_main.cfg<br /> dir/a/other.cfg<br /> dir/b/_main.cfg<br /> dir/b/other.cfg<br /> dir/other.cfg<br /> Using '''{dir}''' will cause dir/a/_main.cfg, dir/b/_main.cfg and dir/other.cfg to be included.<br /> * If there's a file named '''_final.cfg''' but no '''_main.cfg''', the file is guaranteed to be included and processed ''after'' all the other files in the directory.<br /> * If there's a file named '''_initial.cfg''' but no '''_main.cfg''', the file is guaranteed to be included and processed ''before'' all the other files in the directory.<br /> <br /> ==== Macro inclusions ====<br /> <br /> '''Syntax: {''symbol'' [''arguments''] [''optional arguments'']}'''<br /> <br /> If the macro named ''symbol'' is defined, the preprocessor will replace this instruction by the expression ''symbol'' was previously defined as, using ''arguments'' as parameters. The number of normal arguments must be exactly the same as in the original definition or an error will occur. Optional arguments can only be placed '''after''' all normal arguments, however they can be specified in any order desired.<br /> <br /> You can create multiple word arguments by using parentheses to delimit the contents. If they are already quoted, space inside quotes will be preserved even without parentheses. For example, in '''{ENEMY_UNIT Wolf Rider 18 24}''' the four words will be interpreted as separate arguments and cause the preprocessor to fail since the macro was defined above with only three; instead, you should use '''{ENEMY_UNIT (Wolf Rider) 18 24}'''.<br /> <br /> Optional arguments can also be delimited by placing parentheses, however they must be placed around both the argument name '''and''' content:<br /> <br /> &lt;syntaxhighlight lang=&quot;wml&quot;&gt;<br /> {MESSAGE _&quot;I'll smash you!&quot; (SPEAKER_ID=Bridge Troll) } # Correct<br /> {MESSAGE _&quot;I'll smash you!&quot; SPEAKER_ID=(Bridge Troll) } # Wrong<br /> &lt;/syntaxhighlight&gt;<br /> <br /> This way even complex arguments can be passed:<br /> <br /> &lt;syntaxhighlight lang=&quot;wml&quot;&gt;<br /> {MODIFY_UNIT (<br /> [filter_adjacent]<br /> canrecruit=yes<br /> [/filter_adjacent]<br /> ) side 2}<br /> &lt;/syntaxhighlight&gt;<br /> <br /> Using the name of an existing macro as the name of a macro argument is possible, but the argument will always take precedence over the original macro:<br /> <br /> &lt;syntaxhighlight lang=&quot;wml&quot;&gt;<br /> #define VARIABLE<br /> #enddef<br /> #define MACRO VARIABLE<br /> {VARIABLE} # is calling for the argument, not for the macro above<br /> #enddef<br /> &lt;/syntaxhighlight&gt;<br /> <br /> === #ifdef and #ifndef ===<br /> <br /> Unlike the other preprocessor directives, '''#ifdef''' and '''#ifndef''' are not mere conveniences. They are often necessary to distinguish between different gameplay modes or difficulties (see [[#Built-in macros|Built-in macros]] below).<br /> <br /> '''Syntax:''' '''#ifdef ''symbol'' ''substitution-if-defined'' [#else ''substitution-if-not-defined'' ] #endif'''<br /> <br /> If ''symbol'' has been defined with '''#define''' or as a built-in macro, the whole block will be replaced by ''substitution-if-defined''. If not, it will be replaced by ''substitution-if-not-defined'' if it is available.<br /> <br /> '''#ifndef''' is the exact opposite of '''#ifdef''', reversing the logic:<br /> <br /> '''Syntax:''' '''#ifndef ''symbol'' ''substitution-if-not-defined'' [#else ''substitution-if-defined''] #endif'''<br /> <br /> === #ifhave and #ifnhave ===<br /> <br /> '''Syntax:''' '''#ifhave ''path'' ''substitution-if-path-exists'' [#else ''substitution-if-path-does-not-exist''] #endif'''<br /> <br /> Checks for the existence of a file. Uses the same relative paths as [[#Inclusion_directive_.7B.7D|include directives]].<br /> <br /> Example:<br /> <br /> &lt;syntaxhighlight lang=&quot;wml&quot;&gt;<br /> #ifhave ~add-ons/My_Addon/_main.cfg<br /> {MY_ADDON_MACROS}<br /> #endif<br /> &lt;/syntaxhighlight&gt;<br /> <br /> '''#ifnhave''' does the opposite of '''#ifhave''':<br /> <br /> '''Syntax:''' '''#ifnhave ''path'' ''substitution-if-path-does-not-exist'' [#else ''substitution-if-path-exists''] #endif'''<br /> <br /> === #ifver and #ifnver ===<br /> <br /> '''Syntax:''' '''#ifver ''symbol'' ''operator'' ''version-number'' ''&lt;newline&gt;'' ''substitution-if-condition-met'' [#else ''substitution-if-condition-not-met''] #endif'''<br /> <br /> Compares a version number defined in a macro against an argument for conditional block inclusions, like ''#ifdef'' and ''#ifhave''. ''operator'' is one of ''=='' (equal), ''!='' (not equal), ''&lt;'' (less), ''&lt;='' (less or equal), ''&gt;'' (greater), ''&gt;='' (greater or equal). The specified ''symbol'' should have been previously defined as plain text without more macro inclusions within it, and it must not require any arguments.<br /> <br /> Versions with text suffixes are sorted in binary order and come after all versions with the same number. The most common suffixes begin with &quot;+&quot;, but as this represents multiple possible versions, comparing versions against it is not recommended.<br /> <br /> Example:<br /> &lt;syntaxhighlight lang=&quot;wml&quot;&gt;<br /> #ifver WESNOTH_VERSION &gt;= 1.9.7+<br /> [message]<br /> speaker=narrator<br /> message= _ &quot;I’m on Wesnoth 1.9.7+, 1.9.8 or later!&quot;<br /> [/message]<br /> #else<br /> #ifver WESNOTH_VERSION == 1.9.7<br /> [message]<br /> speaker=narrator<br /> message= _ &quot;I’m on Wesnoth 1.9.7, and I’ll include some workaround code for bug #9001!&quot;<br /> [/message]<br /> #endif<br /> #endif<br /> &lt;/syntaxhighlight&gt;<br /> <br /> '''#ifnver''' does the opposite of '''#ifver''':<br /> <br /> '''Syntax:''' '''#ifnver ''symbol'' ''operator'' ''version-number'' ''&lt;newline&gt;'' ''substitution-if-condition-not-met'' [#else ''substitution-if-condition-met''] #endif'''<br /> <br /> === #error ===<br /> <br /> '''Syntax:''' '''#error [''message'']'''<br /> <br /> Causes the WML preprocessor to fail unconditionally upon encountering the line. For add-ons, this will cause the game to display an error and return to the titlescreen if the add-on is required for the user's action (such as playing a campaign or loading a saved game). For core WML, this will cause the game to quit entirely.<br /> <br /> Please note that in spite of the example below, it is '''not''' advisable to use this mechanism in published add-ons for version or feature-checking, since the message is not displayed in a form that permits translation and the additional trace information may confuse players. This directive is only intended as a debugging aid for content creators.<br /> <br /> Example:<br /> &lt;syntaxhighlight lang=&quot;wml&quot;&gt;<br /> #ifver WESNOTH_VERSION &lt; 1.11.10<br /> #error This add-on does not support Wesnoth 1.11.10!<br /> #endif<br /> &lt;/syntaxhighlight&gt;<br /> <br /> === #warning ===<br /> <br /> '''Syntax:''' '''#warning [''message'']'''<br /> <br /> Causes the WML preprocessor to emit a warning upon encountering the line. The message will '''only''' be relayed to stderr, not to the player in the game UI. This directive is only intended as a debugging aid for content creators.<br /> <br /> Example:<br /> &lt;syntaxhighlight lang=&quot;wml&quot;&gt;<br /> #ifver WESNOTH_VERSION &lt; 1.11.10<br /> #warning On Wesnoth 1.11.9 or earlier, bug workarounds enabled!<br /> #endif<br /> &lt;/syntaxhighlight&gt;<br /> <br /> === #deprecated ===<br /> <br /> {{DevFeature1.13|11}}<br /> <br /> '''Syntax:''' '''#deprecated 1 [''message'']'''<br /> <br /> '''Syntax:''' '''#deprecated 2 ''version'' [''message'']'''<br /> <br /> '''Syntax:''' '''#deprecated 3 ''version'' [''message'']'''<br /> <br /> '''Syntax:''' '''#deprecated 4 [''message'']'''<br /> <br /> The first argument is the deprecation level, while ''version'' is the first Wesnoth version where this deprecated file/macro might to be removed. ''message'' is the optional deprecation message. The recommended usage is to provide ''message''.<br /> <br /> The effect of this directive depends on whether it appears within a macro definition.<br /> <br /> * If it appears at file level, outside any macro definition, then it immediately outputs a warning saying that the file is deprecated, with the provided message. Multiple '''#deprecated''' directives at toplevel in a single file will result in separate messages.<br /> * If it appears inside a macro definition ('''#define ... #enddef'''), then it doesn't output anything. Instead, it marks the macro as deprecated. When that macro is later used, only then will the preprocessor output a warning saying that the macro is deprecated, with the provided message. Multiple '''#deprecated''' directives within a single macro will be merged into one message.<br /> <br /> Note that deprecation messages will only appear if they have been set to. {{DevFeature1.13|12}} This can be done by enabling debug mode, or by going to Advanced Preferences and setting the log-level for the deprecation logdomain. (This can also be done on the command-line.)<br /> <br /> If you provide a deprecation level of 2 or 3, it is required to indicate the earliest version in which the feature could be removed. However, if you provide a deprecation level of 1 or 4, any provided ''version'' will instead be parsed as part of the message, so you will probably not want to provide one at all. Other deprecation levels are not valid. See the documentation for [[InterfaceActionsWML#.5Bdeprecated_message.5D|[deprecated_message]]] for the meaning of the various ''level'' values.<br /> <br /> == Built-in macros ==<br /> <br /> The following macros are automatically defined with empty contents (unless specified otherwise) by the game engine depending on the configuration or gameplay mode.<br /> <br /> Note that except during an actual game, '''MULTIPLAYER''', '''EDITOR''' and previous campaign defines, are not guaranteed to be undefined, especially when coming back to the titlescreen. So it is not enough to hide contents inside of an #ifdef to prevent them from being seen by the campaign selection dialog, for example for multiplayer specific '''[campaign]'''s or '''[modification]'''s '''type=mp''' must be used. <br /> <br /> * A campaign define symbol (see ''define'' in [[CampaignWML]]): defined when playing a single-player campaign.<br /> * A campaign difficulty level, usually '''EASY''', '''NORMAL''' or '''HARD''' (see ''difficulties'' in [[CampaignWML]]): defined according to the chosen difficulty when starting a single-player campaign, also stored in saved games.<br /> * '''MULTIPLAYER''': defined when in multiplayer mode.<br /> * '''EDITOR''': defined when running the built-in map editor.<br /> * '''DEBUG_MODE''': defined when the game has been launched in debug mode (i.e. with '''-d''' or '''--debug''' in the command line). Can also be set by typing &lt;code&gt;:&lt;/code&gt; to bring up [[CommandMode]], then typing &lt;code&gt;debug&lt;/code&gt;, and then restarting the scenario.<br /> * '''APPLE''': defined while processing the main game data when running on Mac OS X. This primarily exists to switch Control for Command in hotkeys, which is why there are no defines for other platforms.<br /> * '''WESNOTH_VERSION''': defined containing just the game version number when running the WML preprocessor.<br /> * '''CURRENT_FILE''': Expands to the name of the current WML file.<br /> * '''CURRENT_DIRECTORY''': Expands to the preprocessor path of the parent directory for the current WML file (e.g. for &lt;code&gt;&amp;lt;user data dir&amp;gt;/data/add-ons/My_Addon/_main.cfg&lt;/code&gt; this evaluates to &lt;code&gt;~add-ons/My_Addon&lt;/code&gt;). <br /> * '''LEFT_BRACE''': {{DevFeature1.15|2}} Expands to &lt;code&gt;{&lt;/code&gt;.<br /> * '''RIGHT_BRACE''': {{DevFeature1.15|2}} Expands to &lt;code&gt;}&lt;/code&gt;.<br /> * '''SCHEMA_VALIDATION''': defined if the validator is being run.<br /> * '''__WMLUNITS__''': defined when the tool to create [https://units.wesnoth.org units.wesnoth.org] is being run.<br /> <br /> A ''very large'' number of additional macros are provided as part of the default game core WML. For a full list of those, check the [https://www.wesnoth.org/macro-reference.html macro reference].<br /> <br /> == Command-line preprocessor ==<br /> <br /> '''Syntax: --preprocess ''&amp;lt;source file/directory&gt;'' ''&lt;target directory&gt;'' '''<br /> <br /> Or the short form:<br /> <br /> '''Syntax: -p ''&amp;lt;source file/directory&gt;'' ''&lt;target directory&gt;'' '''<br /> <br /> You can specify a list of predefined defines with:<br /> <br /> '''Syntax: --preprocess-defines=DEFINE1,DEFINE2,etc'''<br /> <br /> comma separated list of defines to be used by '--preprocess' command. If 'SKIP_CORE' is in the define list the data/core won't be preprocessed.<br /> <br /> The command will first preprocess '''data/core/macros''' and '''data/core/terrain-graphics''', and afterwards the specified path. You can specify a single file to be preprocessed (if you want to preprocess multiple separate files, you'll need to run a different command line for each one), or an entire directory, which will be preprocessed according to the rules used by the inclusion directive above.<br /> <br /> The resulting preprocessed files will be written in the target directory. There will be two types of files: .cfg files --- the normal ones, and .plain files containing line markers and textdomain changes.<br /> <br /> If by chance, the simple macro define doesn't suffice, you can use:<br /> <br /> '''Syntax: --preprocess-input-macros &lt;file&gt;'''<br /> <br /> To import an existing file that contains macros, and they will be available in the defines database before processing the specified files.<br /> <br /> There is also the possibility to export the preprocessed defines/macro list with:<br /> <br /> '''Syntax: --preprocess-output-macros [&lt;target file&gt;]'''<br /> <br /> This file could be fed to the 'input-macros' argument next time you run it. For example, a scenario would be: parsing just the core first time, and for the intended target files, you would add SKIP_CORE but import the generated macros file - that will be faster than preprocessing the core again. If the target file is not specified, the output file will be _MACROS_.cfg in the target directory of the preprocess's command.<br /> <br /> If ''file/directory'' and ''target directory'' are not absolute paths, they will be considered relative to the current directory.<br /> <br /> Some examples:<br /> <br /> * Preprocess the entire tutorial dir, and write the results in the ~/result folder:<br /> -p ~/wesnoth/data/campaigns/tutorial ~/result<br /> * Add the MULTIPLAYER define to the list and preprocess a scenario's config file:<br /> -p ~/.wesnoth/data/add-ons/My_Campaign/scenarios/01_First_Scenario.cfg ~/result --preprocess-defines=MULTIPLAYER<br /> * Add the MY_CAMPAIGN and HARD defines before preprocessing a campaign's files:<br /> -p ~/.wesnoth/data/add-ons/My_Campaign ~/result --preprocess-defines=MY_CAMPAIGN,HARD<br /> * File myfile.cfg depends on macros defined in data/gui/macros/_initial.cfg:<br /> -p data/gui/macros/_initial.cfg /tmp --preprocess-output-macros=macros<br /> -p myfile.cfg ~/result --preprocess-input-macros=/tmp/macros<br /> <br /> When it starts getting complicated, such as a file that depends on multiple other files, it is probably easiest to simply &quot;include&quot; the dependencies:<br /> <br /> * File myfile.cfg depends on macros defined in data/gui/macros/_initial.cfg:<br /> Add {gui/macros/_initial.cfg} to the beginning of myfile.cfg<br /> -p myfile.cfg ~/result<br /> <br /> If you want a more detailed (and potentially overwhelming) log, you can simply add the switches '''--log-debug=all''' or '''--log-info=all''' to the command line, so you can see how things are preprocessed in detail.<br /> <br /> == See Also ==<br /> <br /> * [[SyntaxWML]] (explains relationship between comments and preprocessor directives)<br /> * [[ReferenceWML]]<br /> <br /> [[Category: WML Reference]]</div>

Pentarctagon https://wiki.wesnoth.org/index.php?title=Template:DevDownload&diff=74962 2026-04-09T00:19:14Z

<p>Pentarctagon: </p> <hr /> <div>&lt;noinclude&gt;<br /> == Development (1.19 branch) ==<br /> &lt;/noinclude&gt;<br /> ==== Windows (10 1903 and later) {{{4|}}} ====<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.22 | filename=wesnoth-1.19.22-win64.exe |<br /> hash=805a9da0b230f4334431704ba0cea6b8dcb4613da2530fcf1f315ff382ec67e2}}<br /> <br /> ==== macOS (10.13 and later) {{{5|}}} ====<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.21 | filename=Wesnoth_1.19.21.dmg |<br /> hash=ef44157e1056fae915df935b8cb32af88d2072eaa8e8ac2c856a4d78d40e7fd9}}<br /> <br /> ==== Source code ====<br /> * [https://github.com/wesnoth/wesnoth/blob/master/INSTALL.md Compiling Wesnoth] - How to compile the source code<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.22 | filename=wesnoth-1.19.22.tar.bz2 |<br /> hash=dccf874092cf42dfbef61e30217f55d40ab4608532ff6dba3be7c052ca3e0c66}}</div>

Pentarctagon https://wiki.wesnoth.org/index.php?title=Template:StableDownload&diff=74961 2026-04-09T00:18:43Z

<p>Pentarctagon: </p> <hr /> <div>&lt;noinclude&gt;<br /> == Stable (1.18 branch) ==<br /> &lt;/noinclude&gt;<br /> ==== Windows (10 1903 and later, 64-bit only) {{{4|}}} ====<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth-1.18 |<br /> version=1.18.7 | filename=wesnoth-1.18.7-win64.exe |<br /> hash=1ebe433b8f7b526944b63d15caf11f42481375130431237b3f1139a517c7c7bb}}<br /> <br /> ==== macOS (10.12 and later) {{{5|}}} ====<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth-1.18 |<br /> version=1.18.6 | filename=Wesnoth_1.18.6.dmg |<br /> hash=1b9a0ba71c11a386ea0daef357cb508f5c9dc792eed71eff1a3783c056214c93}}<br /> <br /> ==== Source code ====<br /> * [https://github.com/wesnoth/wesnoth/blob/master/INSTALL.md Compiling Wesnoth] - How to compile the source code<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth-1.18 |<br /> version=1.18.7 | filename=wesnoth-1.18.7.tar.bz2 |<br /> hash=d6b50cfdf4388954a1c3da66a61abacdc7643a17aa78a16196e16e720a661fc2}}</div>

Pentarctagon https://wiki.wesnoth.org/index.php?title=Template:DevDownload&diff=74953 2026-03-30T01:57:23Z

<p>Pentarctagon: </p> <hr /> <div>&lt;noinclude&gt;<br /> == Development (1.19 branch) ==<br /> &lt;/noinclude&gt;<br /> ==== Windows (10 1903 and later) {{{4|}}} ====<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.22 | filename=wesnoth-1.19.22-win64.exe |<br /> hash=805a9da0b230f4334431704ba0cea6b8dcb4613da2530fcf1f315ff382ec67e2}}<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.21 | filename=wesnoth-1.19.21-win64.exe |<br /> hash=7492d586fa192b5d60dfbc4265567e344993401aed6a63d03dc53db130cbbcbb}}<br /> <br /> ==== macOS (10.13 and later) {{{5|}}} ====<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.21 | filename=Wesnoth_1.19.21.dmg |<br /> hash=ef44157e1056fae915df935b8cb32af88d2072eaa8e8ac2c856a4d78d40e7fd9}}<br /> <br /> ==== Source code ====<br /> * [https://github.com/wesnoth/wesnoth/blob/master/INSTALL.md Compiling Wesnoth] - How to compile the source code<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.22 | filename=wesnoth-1.19.22.tar.bz2 |<br /> hash=dccf874092cf42dfbef61e30217f55d40ab4608532ff6dba3be7c052ca3e0c66}}<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.21 | filename=wesnoth-1.19.21.tar.bz2 |<br /> hash=d97521cda6717c0a76f3830d68e8918975ca88310e0f6d693db9b62c0585b16d}}</div>

Pentarctagon https://wiki.wesnoth.org/index.php?title=PblWML&diff=74932 2026-03-29T03:38:43Z

<p>Pentarctagon: /* forum_auth */</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 level 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 /> &lt;b&gt;Note:&lt;/b&gt; Be aware that translations in the .pbl-files are '''not''' used, so don't mark these strings as translatable. {{DevFeature1.15|4}} The translations in the .pbl-files are used, but they are used as a plain text instead of Gettext strings, 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 [[ImagePathFunctions]] to recolor it. For example: <br /> <br /> ::icon=&quot;units/elves-wood/archer+female-sword-1.png~RC(magenta&gt;brightorange)&quot;<br /> :or<br /> ::icon=&quot;units/human-peasants/peasant-ranged.png~RC(magenta&gt;white)~CS(24,24,24)&quot;<br /> :or<br /> ::icon=&quot;units/human-peasants/ruffian.png~RC(magenta&gt;green)~BLIT(units/human-peasants/woodsman.png~RC(magenta&gt;lightblue),18,12)&quot;<br /> <br /> : Because the add-on manager's UI is dark, recoloring to light colors looks usually better. [https://irydacea.me/projects/wespal Wespal] is a tool that provides a convenient way to preview recolored unit sprites without needing to launch the game with specific WML or Lua edits.<br /> <br /> : {{DevFeature1.13|12}} Instead of a standard Wesnoth image, a [[DataURI]] can also be used. This way, an image can be directly included into the _server.pbl file. Take care to leave no trailing newline.<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 /> : '''This value is required'''.<br /> <br /> === version ===<br /> : Displayed to the right of the title; it is merely 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 or between these numbers. The string of numbers will be modified on the server by inserting or appending zeros as neccesary to meet the required format. All this is necessary for the “Update All” button to work correctly. ([[#Version Key Examples|See Examples]])<br /> : '''This value is required'''.<br /> <br /> === author ===<br /> : Displayed to the right of the version; it is merely 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 /> : {{DevFeature1.17|3}} When using forum_auth, this value is a single forum account name which will have the ability to upload new versions of the add-on, delete the add-on from the add-ons server, and update the secondary_authors field.<br /> <br /> : {{DevFeature1.19|7}} This value is now used the same as it was pre-forum_auth. It is only used to display in the addons manager.<br /> <br /> : '''This value is required'''.<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 /> : {{DevFeature1.15|12}}<br /> <br /> : It is no longer required to keep the passphrase in the .pbl file at all. If it is not present, then Wesnoth will prompt for it to be entered when uploading or deleting an add-on.<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 /> : '''This value is required'''.<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 /> === tags ===<br /> {{DevFeature1.13|12}}<br /> : An optional string including a comma-separated list of keywords used for matching add-ons when typing terms into the Filter box on the top left of the Add-ons Manager. There are no specific requirements on the syntax of the keywords listed here, but a general recommendation is to keep them relevant for players. For example, one might include the add-on's acronym in the tags, the names or acronyms of add-ons to which it is related, and so on.<br /> <br /> {{DevFeature1.15|13}} The in-game add-ons manager will show all the tags in the UI, and also includes a drop-down list of tags to filter by. Not all tags are listed in the filter box, and the exact list of tags supported may change before 1.16 is released, but the list is currently:<br /> <br /> * '''cooperative''': All human players are on the same team, versus the AI<br /> * '''cosmetic''': These make the game look different, without changing gameplay<br /> * '''difficulty''': Can make campaigns easier or harder<br /> * '''rng''': Modify the randomness in the combat mechanics, or remove it entirely<br /> * '''survival''': Fight against waves of enemies<br /> * '''terraforming''': Players can change the terrain<br /> <br /> For example, if an A New Land style add-on had tags ''building'', ''terraforming'', ''anl'', ''city'', and ''survival'' then it would be shown if either ''Terraforming'' or ''Survival'' was selected in the drop-down; the other tags wouldn't affect the filtering.<br /> <br /> === core ===<br /> {{DevFeature1.13|0}}<br /> : An optional string defining the id of the core which the addon is designed for. Defaults to &quot;''default''&quot;. Don't specify for an addon which is of type &quot;''core''&quot; itself. Note: DO NOT SET this unless you know why you need it! Giving it an invalid value can lead to mysterious errors with your campaign failing to load!<br /> <br /> === translate ===<br /> : If set to ''true'', the add-on would have been sent to and updated with [[WesCamp|WesCamp-i18n]], if that project were still active. However, as WesCamp is no longer active, this no longer does anything.<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 /> : Note: WesCamp was abandoned in 2014. Instead, please refer to:<br /> * [[GettextForWesnothDevelopers]]<br /> * [[GettextForTranslators#For_add-ons]]<br /> * forum thread: [https://r.wesnoth.org/t46366 Guide: Translating your UMC without WesCamp].<br /> <br /> === type ===<br /> : Indicates the type of the add-on; used to filter listings in the downloads manager dialog. Acceptable 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 ({{DevFeature1.13|11}} can also used for single-player modifications, although it's still called ''mod_mp'').<br /> :* ''media'': miscellaneous resources for UMC authors/users, for example, music packs, packages of general-purpose WML, etc. &lt;small&gt;Note: Shows as Resources, not Media, in the add-ons interface&lt;/small&gt;<br /> :* ''other'': The type to use when no other type fits.<br /> : '''Note:''' If your add-on contains two or more separate multiplayer scenarios, use ''map_pack''.<br /> <br /> : '''This value is required'''.<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 /> : '''This value is required if forum_auth is not set to true'''.<br /> <br /> === forum_auth ===<br /> {{DevFeature1.17|3}}<br /> : When set to ''true'', you will be prompted for your forum password when uploading your add-on. The username(s) available to select will be populated from the '''author''' field (before 1.19.7) or the '''primary_authors''' field (1.19.7+). If the username dropdown is empty, make sure to confirm that either the '''author''' or '''primary_authors''' field is present and spelled correctly, depending on what version of Wesnoth you are running.<br /> <br /> When set to true, the ''passphrase'' and ''email'' fields are also not required.<br /> <br /> === primary_authors ===<br /> {{DevFeature1.19|7}}<br /> : A comma-delimited list of forum accounts that are allowed to upload new versions of the add-on or delete the add-on from the add-ons server.<br /> <br /> === secondary_authors ===<br /> : A comma-delimited list of forum accounts that are allowed to upload new versions of the add-on, but aren't allowed to delete the add-on.<br /> <br /> === [feedback] ===<br /> : 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 /> : 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, this topic_id corresponds to the series of digits in the ''t=YYYYY'' portion of a URL like &lt;code&gt;&lt;nowiki&gt;http://forums.wesnoth.org/viewtopic.php?f=XX&amp;t=YYYYY&lt;/nowiki&gt;&lt;/code&gt;. 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 /> === [translation] ===<br /> {{DevFeature1.15|4}}<br /> : Multiple [translation] tags can be used to provide the addon with a localized title and description to be seen in the addons manager. However, it should be noted that the declared translations won't influence the list of supported locales as it depends only on the presence of .mo and .po files for corresponding languages.<br /> <br /> ==== language ====<br /> : The target language code for the translation. The codes for each language are given in the big table on [https://www.wesnoth.org/gettext/] . You can use either its contracted version (like ''sv'' for Swedish) or a more precise variety (like ''zh_CN'' or ''ca_ES@valencia'').<br /> : '''This value is required'''.<br /> <br /> ==== title ====<br /> : The translation of addon's title for the target language.<br /> : '''This value is required'''.<br /> <br /> ==== description ====<br /> : The translation of addon's description for the target language.<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 /> {{DevFeature1.17|13}} the schema validation rejects many of the '''good''' examples. https://github.com/wesnoth/wesnoth/issues/7396<br /> <br /> The following are examples of '''good''' version values:<br /> <br /> version=&quot;1.5&quot;<br /> version=&quot;0.11.4&quot;<br /> version=&quot;0.1.4beta&quot;<br /> version=&quot;1.5c&quot;<br /> <br /> The following are examples of '''bad''' version values:<br /> <br /> version=&quot;Beta1.5&quot;<br /> version=&quot;Incomplete (0.3.4)&quot;<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 /> 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 &lt; 1.0<br /> 1.5 &lt; 1.5c<br /> 1.0 &lt; 1.0.1<br /> 1.0c &lt; 1.0.1a<br /> 1.0.1a &lt; 1.0.1c<br /> 1.0 Final &lt; 1.0.1 Beta<br /> <br /> === Example .pbl File ===<br /> <br /> &lt;syntaxhighlight lang=wml&gt;<br /> title=&quot;My Campaign&quot;<br /> type=&quot;campaign&quot;<br /> icon=&quot;misc/ball.png&quot;<br /> version=&quot;0.1.2&quot;<br /> author=&quot;Me, artwork by myself&quot;<br /> passphrase=&quot;This is like a password; see the security note in the documentation above before choosing a value of your own&quot;<br /> description=&quot;You get to kill a lot of bad guys. But only the first map is done.&quot;<br /> email=&quot;name@example.com&quot;<br /> [feedback]<br /> topic_id=12345<br /> [/feedback]<br /> # Note: the translation feature works on version 1.14.14, 1.15.4 and later only<br /> [translation]<br /> language=&quot;ru&quot;<br /> title=&quot;Моя Кампания&quot;<br /> description=&quot;Вам придётся завалить немало плохишей. Но пока что готова лишь первая карта.&quot;<br /> [/translation]<br /> [translation]<br /> language=&quot;zh_CN&quot;<br /> title=&quot;我的竞选&quot;<br /> description=&quot;你会杀死很多坏人。 但是只完成了第一张地图。(translated online)&quot;<br /> [/translation]<br /> &lt;/syntaxhighlight&gt;<br /> <br /> == See Also ==<br /> <br /> * [[IGNFileFormat]]<br /> * [[FancyAddonIcons]]<br /> * [[ReferenceWML]]<br /> * [[CampaignServerWML]]<br /> <br /> [[Category: WML Reference]]</div>

Pentarctagon https://wiki.wesnoth.org/index.php?title=Template:DevDownload&diff=74892 2026-03-09T01:08:56Z

<p>Pentarctagon: </p> <hr /> <div>&lt;noinclude&gt;<br /> == Development (1.19 branch) ==<br /> &lt;/noinclude&gt;<br /> ==== Windows (10 1903 and later) {{{4|}}} ====<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.21 | filename=wesnoth-1.19.21-win64.exe |<br /> hash=7492d586fa192b5d60dfbc4265567e344993401aed6a63d03dc53db130cbbcbb}}<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.20 | filename=wesnoth-1.19.20-win64.exe |<br /> hash=c55a71350f5aab18074a5cc781bc66a56a29086624df85f4e155d5a1a4e966f9}}<br /> <br /> ==== macOS (10.13 and later) {{{5|}}} ====<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.21 | filename=Wesnoth_1.19.21.dmg |<br /> hash=ef44157e1056fae915df935b8cb32af88d2072eaa8e8ac2c856a4d78d40e7fd9}}<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.20 | filename=Wesnoth_1.19.20.dmg |<br /> hash=9a0df54edbbffb503f527a1b8007b7860eace3cfb9b94207c2ad21047171eb94}}<br /> <br /> ==== Source code ====<br /> * [https://github.com/wesnoth/wesnoth/blob/master/INSTALL.md Compiling Wesnoth] - How to compile the source code<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.21 | filename=wesnoth-1.19.21.tar.bz2 |<br /> hash=d97521cda6717c0a76f3830d68e8918975ca88310e0f6d693db9b62c0585b16d}}<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.20 | filename=wesnoth-1.19.20.tar.bz2 |<br /> hash=48f883f8cd3ea008f9170aeaa9fb9ebb486202dd72f455ae131363fc3d164f8f}}</div>

Pentarctagon https://wiki.wesnoth.org/index.php?title=MultiplayerServerWML&diff=74861 2026-02-22T15:17:36Z

<p>Pentarctagon: /* Game setup (the phase from creation to start) */</p> <hr /> <div>This page describes the [[WML]] used to communicate with the multiplayer server for Wesnoth, [[wesnothd]].<br /> <br /> == The handshake ==<br /> <br /> The client sends four bytes, then the server replies with four bytes. To get a new connection number, the client will send these four bytes: 0x00 0x00 0x00 0x00. The server then sends back the connection number (wesnothd calls this number the &quot;socket number&quot;). Since 1.13+ the server no longer is using socket numbers to keep track of clients and always sends the same number to them all. Since 1.15+ client can also send 0x00 0x00 0x00 0x01 instead to request entire connection to be [https://github.com/wesnoth/wesnoth/blob/2f8136951cd77526188cf8d0fb2cf21eaa2ebe63/src/server/common/server_base.hpp#L60-L76 encapsulated in TLS] immediately '''after'''. If the handshake is successful, the server will be the first to send a data package. All packages are in [http://en.wikipedia.org/wiki/Gzip gzip] format and are preceded by four bytes that specify the size of the package to come in '''big-endian''' (network byte order). Below you'll find information about what data the (unzipped) packages contain. Unpacked WML uses utf-8 charset.<br /> <br /> == The login procedure ==<br /> <br /> * server request (optional)<br /> ** '''[version]'''<br /> <br /> * client response<br /> ** '''[version]'''<br /> *** '''version''': The client's version string.<br /> *** '''client_source''': The client's distribution info. (Steam, SourceForge, App Store, etc.)<br /> <br /> * server response (if the server does not accept this version)<br /> ** '''[redirect]'''<br /> *** '''host''': The host you should connect to.<br /> *** '''port''': The port you should connect to.<br /> *** '''version''': A comma-separated list of globs that this server should accept (e.g. &quot;1.0*,1.2*,1.4*,1.7*,1.8*&quot;)<br /> ** or '''[reject]''' (if the version is unknown)<br /> *** '''accepted_versions''': A comma-separated list of globs that this server does accept<br /> <br /> * server request<br /> ** '''[mustlogin]'''<br /> <br /> * client response<br /> ** '''[login]'''<br /> *** '''username''': The username the client would like to have.<br /> *** '''password''': The hashed password, created from the password and salt received from the server. More information about how this password is being generated, including a real world example, can be found in the file [http://forum.wesnoth.org/download/file.php?id=41145 HashedPasswords.pdf] (885 KiB). Since version 1.15+ if TLS was successfully established before then password will be passed as is, without hashing, relying on TLS for secrecy. Passing password hashes is no longer supported to free the client from responsibility to support all hash schemes the forum can potentially use. Client will emit error instead of trying to send password if TLS wasn't established.<br /> <br /> * server response<br /> ** '''[join_lobby]'''<br /> *** '''is_moderator''': &quot;yes&quot; if the user is a moderator, &quot;no&quot; otherwise.<br /> *** '''profile_url_prefix''': The external URL prefix for player profiles (empty if the server doesn't have an attached database)<br /> ** or '''[error]''' (server is waiting for another '''[login]''' message now)<br /> *** '''message''': The error message.<br /> *** '''password_request''': If not empty the server asks the client to provide a password for its desired username.<br /> *** '''phpbb_encryption''': If &quot;yes&quot; the client will encrypt the password using phpbb's algorithm.<br /> *** '''random_salt''': Random salt sent to the client for mixing with the password hash.<br /> *** '''hash_seed''': Salt generated from the original hash that is required to recreate it.<br /> *** '''salt''': Salt generated from the original hash that is required to recreate it.<br /> *** '''force_confirmation''': Display an ok/cancel dialog with the content of the 'message' key.<br /> <br /> * server response<br /> ** '''[gamelist]'''<br /> *** '''[game]''' (repeated)<br /> **** '''id''': A unique id of the game.<br /> **** '''name''': The title of the game.<br /> **** '''mp_scenario''': The id of the scenario.<br /> **** '''mp_era''': The id of the used era.<br /> **** '''mp_use_map_settings''': Does the game use the map settings specified in the scenario.<br /> **** '''mp_fog''': Does the game use fog.<br /> **** '''mp_shroud''': Does the game use shroud.<br /> **** '''mp_village_gold''': The number of gold per village.<br /> **** '''experience_modifier''': The experience setting.<br /> **** '''mp_countdown''': Does the game use a timer.<br /> **** '''mp_countdown_reservoir_time''': Upper limit of the possibly available time.<br /> **** '''mp_countdown_init_time''': Initial time.<br /> **** '''mp_countdown_action_bonus''': Time bonus per action.<br /> **** '''mp_countdown_turn_bonus''': Time bonus per turn.<br /> **** '''map_data''': The map data. ''Notice: not sent to lobby if the game uses shroud''<br /> **** '''hash''': The hash value of the map_data.<br /> **** '''observer''': Are observers allowed or not.<br /> **** '''human_sides''': The number of sides played by humans.<br /> **** '''slots''': The number of vacant/max slots.<br /> **** '''[slot_data]''' replaces '''slots''' since {{DevFeature1.13|12}}<br /> ***** '''max''': The number of total slots.<br /> ***** '''vacant''': The number of vacant slots.<br /> **** '''turn''': The current turn/max turn.<br /> **** '''[turn_data]''' replaces '''turn''' since {{DevFeature1.13|12}}<br /> ***** '''current''': The current turn number.<br /> ***** '''max''': The total number of turns.<br /> **** '''[modification]''' Modifications used in this game. See [[ModificationWML]].<br /> ***** '''id''': ID of the modification.<br /> ***** '''name''': Name of the modification.<br /> ***** '''addon_id''': ID of the addon the modification is from.<br /> ***** '''require_modification''': A boolean value; if set to yes, all players have to have this modification installed to join the game.<br /> **** '''[options]''' Options selected for this game. See [[OptionWML]].<br /> ***** '''[campaign|era|modification|multiplayer]'''<br /> ****** '''id''': ID of the addon the campaign|era|modification|multiplayer (scenario) is from.<br /> ****** '''[option]'''<br /> ******* '''id''': ID of the option.<br /> ******* '''value''': Value of the option.<br /> ** '''[user]''' (repeated)<br /> *** '''name''': The username of the player.<br /> *** '''game_id''': The ID of the game the player is in.<br /> *** '''location''': The name of the game the player is in.<br /> *** '''available''': &quot;yes&quot; if the player is in the lobby; &quot;no&quot; if in a game.<br /> Many of the keys under [game] are described more indepth on the [[ScenarioWML]] page.<br /> <br /> == Error messages ==<br /> <br /> * '''[error]'''<br /> ** '''message''': The error message.<br /> ** '''password_request''': This is a response to a login attempt. The client needs to send a password on another login attempt.<br /> ** '''force_confirmation''': Confirmation to login even if there is an existing client with the same name. If login is continued then that existing client is getting kicked.<br /> <br /> == Chat (lobby and in-game) ==<br /> <br /> * '''[message]'''<br /> ** '''sender''': (optional - filled by the server) The sender of the message.<br /> ** '''message''': The message itself.<br /> ** '''room''': The room the message is from/to<br /> * '''[whisper]'''<br /> ** '''receiver''': The receiver of the whisper<br /> ** '''sender''': (optional - filled by the server) The sender of the whisper.<br /> ** '''message''': The message itself.<br /> <br /> == Nickname registration related commands (lobby and in-game) ==<br /> <br /> * '''[nickserv]'''<br /> ** '''[info]''': Request info about another username.<br /> *** '''name''': The username.<br /> <br /> == Updating the lobby state ==<br /> <br /> * '''[gamelist_diff]''': server message - basically a [[DiffWML|diff]] from two gamelists, which also includes the user list.<br /> <br /> * '''[observer]''' or '''[observer_quit]''': server message - players joining([observer_quit] - quitting the lobby &quot;game&quot;)/quitting([observer] - joining the lobby &quot;game&quot;) a game<br /> ** '''name''': Username of the player/observer.<br /> * '''[refresh_lobby]''': Request the full gamelist.<br /> <br /> == Game setup (the phase from creation to start) ==<br /> To create a game the client sends:<br /> * '''[create_game]'''<br /> ** '''name''': The title of the game.<br /> ** '''password''': The password to use to join the game.<br /> ** '''ignored''': The list of ignored players from the host.<br /> ** '''auto_hosted''': True if this request is from a bot or a server-side queue, false otherwise.<br /> ** '''queue_type''': Either &quot;normal&quot; or &quot;server_preset&quot;.<br /> ** '''queue_id''': The ID of the queue this game is being created from.<br /> <br /> followed by a message with the scenario options as under [game] (see above) plus the scenario data ([time], [era], [side], etc. see [[ScenarioWML]])<br /> <br /> * '''[join]'''<br /> ** '''id''': The id of the game.<br /> ** '''observe''': Join the game as an observer.<br /> <br /> * '''[scenario_diff]''': [[DiffWML|diff]] of the [[ScenarioWML]] (side changes, etc.)<br /> <br /> * '''[start_game]''': sent by the host to start a game<br /> * '''[leave_game]''': sent by the client when it leaves a game; sent by the server to make a client leave a game<br /> ** '''reason''': optional reason if sent by the server and was initiated by moderator action<br /> <br /> == In-game communication ==<br /> <br /> Normal scenario communication ([[ReplayWML]]):<br /> * '''[turn]'''<br /> ** '''[command]''': (repeated) can contain all the tags you can find in a [[ReplayWML|replay]]: [recruit], [move], [end_turn], etc.<br /> *** '''[speak]'''<br /> **** '''message''': text of the message<br /> **** '''id''': the sender<br /> **** '''team_name''': the name of the team the message is for - empty if it's a public message<br /> <br /> Multiplayer specific communication:<br /> * '''[request_choice]'''<br /> ** '''request_id''': unique ID of the choice request<br /> ** '''[random_seed]''': client requests a random number (used for attacks for example)<br /> ** '''[change_controller_wml]''': change controller request from scenario WML<br /> *** '''side''': side number<br /> *** '''old_controller''': old [[SideWML#controller|controller]] value<br /> *** '''new_controller''': new [[SideWML#controller|controller]] value<br /> * '''[store_next_scenario]''': sent by the host - the scenario data (see [[ScenarioWML]]) to advance to the next scenario<br /> * '''[notify_next_scenario]''': sent by the server to tell players that the data for the next scenario is available<br /> * '''[load_next_scenario]''': sent by the client to request the data for the next scenario<br /> * '''[next_scenario]''': data for the next scenario (see [[ScenarioWML]]), sent by the server on request<br /> <br /> * '''[info]''': sent by the host on game end - info about the game state<br /> ** '''type''': &quot;termination&quot; <br /> ** '''condition''': the termination reason<br /> <br /> If a player leaves this is sent to the host for all sides he owned.<br /> * '''side_drop''': The number of a side that dropped because a player left.<br /> * '''controller''': The controller of that side. (&quot;ai&quot;, &quot;network&quot;)<br /> <br /> Client commands:<br /> * '''[change_controller]''': a player (un)droids one of his sides or assigns control to someone else (The host can assign control for any side.)<br /> ** '''side''': the side to change controller<br /> ** '''player''': the nickname of the player to take control<br /> ** '''controller''': the new controller: &quot;human&quot; or &quot;human_ai&quot;<br /> ** '''own_side''': &quot;yes&quot;<br /> * '''[muteall]''': the host mutes/unmutes all observers - toggles<br /> * '''[mute]''': the host mutes an observer - toggles<br /> ** '''username''': the username of the observer - if not specified the servers returns a list of muted usernames<br /> * '''[kick]''' or '''[ban]''': the host kicks/bans a player/observer<br /> ** '''username''': the username of the player/observer<br /> <br /> == Game history ==<br /> This is a request to query a set of 11 rows of game history data based on the provided search criteria. The official client calls this from the Match History button in the multiplayer lobby to display 10 rows of data. The 11th row is used as a flag to indicate whether there is more data to be queried or not via the right/left arrows on the dialog.<br /> <br /> * '''[game_history_request]'''<br /> ** '''offset''': where in the result set to start returning data from. If there are 50 results and offset 10 is given, then rows 10-21 will be returned.<br /> ** '''search_player''': the forum username of the player to search for.<br /> ** '''search_game_name''': the name of the game to filter results by. Can use the * (matches any character before or after it's used) and _ (matches any single character) wildcards.<br /> ** '''search_content_type''': the type of content to filter by. Must be one of:<br /> *** '''0''': scenario<br /> *** '''1''': era<br /> *** '''2''':modification<br /> ** '''search_content''': The content to filter by. This is the ID of the content, not the name displayed on the UI, due to the translated name getting stored in the database.<br /> <br /> == Queues ==<br /> Queue info sent to the client on join or when the server's config is reloaded and the queue information has changed:<br /> * '''[queue_update]'''<br /> ** '''queue_id''': The server's unique ID for the queue.<br /> ** '''action''': One of add/update/remove.<br /> ** '''display_name''': The text to show in the list of queues in the lobby. Only used by add/update.<br /> ** '''players_required''': How many players are required before a game is started. Only used by add/update.<br /> <br /> When there are enough players to start a game, the last player to join the queue is chosen as the host and their client is told to create the game with the provided settings. This skips the game creation screen and goes straight to the staging screen. The other players in the queue are then told to join that game using the normal [join] command:<br /> * '''[create_game]'''<br /> ** '''queue_id''': The ID of the queue to create the game for.<br /> ** '''[game]'''<br /> *** '''scenario''': The ID of the scenario to create the game for.<br /> *** '''era''': The ID of the era to use.<br /> *** '''fog''': Whether to have fog enabled.<br /> *** '''shroud''': Whether to have shroud enabled.<br /> *** '''village_gold''': How much gold each village provides.<br /> *** '''village_support''': How much unit support each village provides<br /> *** '''experience_modifier''': The experience modifier to use.<br /> *** '''countdown''': Not currently used, set to false.<br /> *** '''random_start_time''': Whether to start at a random time of day.<br /> *** '''shuffle_sides''': Whether to shuffle the sides' starting positions.<br /> <br /> == Administrative commands ==<br /> * '''[query]'''<br /> ** '''type''': The type of query. See [[ServerAdministration]] for details.<br /> <br /> == See also ==<br /> [https://github.com/renom/fastbot fastbot] - the bot for tournaments which implements the protocol, can log in into the lobby and host games. Written in Go. <br /> [[Category:WML Reference]]<br /> [[Category:Server Documentation]]</div>

Pentarctagon https://wiki.wesnoth.org/index.php?title=MultiplayerServerWML&diff=74860 2026-02-22T15:14:33Z

<p>Pentarctagon: /* Queues */</p> <hr /> <div>This page describes the [[WML]] used to communicate with the multiplayer server for Wesnoth, [[wesnothd]].<br /> <br /> == The handshake ==<br /> <br /> The client sends four bytes, then the server replies with four bytes. To get a new connection number, the client will send these four bytes: 0x00 0x00 0x00 0x00. The server then sends back the connection number (wesnothd calls this number the &quot;socket number&quot;). Since 1.13+ the server no longer is using socket numbers to keep track of clients and always sends the same number to them all. Since 1.15+ client can also send 0x00 0x00 0x00 0x01 instead to request entire connection to be [https://github.com/wesnoth/wesnoth/blob/2f8136951cd77526188cf8d0fb2cf21eaa2ebe63/src/server/common/server_base.hpp#L60-L76 encapsulated in TLS] immediately '''after'''. If the handshake is successful, the server will be the first to send a data package. All packages are in [http://en.wikipedia.org/wiki/Gzip gzip] format and are preceded by four bytes that specify the size of the package to come in '''big-endian''' (network byte order). Below you'll find information about what data the (unzipped) packages contain. Unpacked WML uses utf-8 charset.<br /> <br /> == The login procedure ==<br /> <br /> * server request (optional)<br /> ** '''[version]'''<br /> <br /> * client response<br /> ** '''[version]'''<br /> *** '''version''': The client's version string.<br /> *** '''client_source''': The client's distribution info. (Steam, SourceForge, App Store, etc.)<br /> <br /> * server response (if the server does not accept this version)<br /> ** '''[redirect]'''<br /> *** '''host''': The host you should connect to.<br /> *** '''port''': The port you should connect to.<br /> *** '''version''': A comma-separated list of globs that this server should accept (e.g. &quot;1.0*,1.2*,1.4*,1.7*,1.8*&quot;)<br /> ** or '''[reject]''' (if the version is unknown)<br /> *** '''accepted_versions''': A comma-separated list of globs that this server does accept<br /> <br /> * server request<br /> ** '''[mustlogin]'''<br /> <br /> * client response<br /> ** '''[login]'''<br /> *** '''username''': The username the client would like to have.<br /> *** '''password''': The hashed password, created from the password and salt received from the server. More information about how this password is being generated, including a real world example, can be found in the file [http://forum.wesnoth.org/download/file.php?id=41145 HashedPasswords.pdf] (885 KiB). Since version 1.15+ if TLS was successfully established before then password will be passed as is, without hashing, relying on TLS for secrecy. Passing password hashes is no longer supported to free the client from responsibility to support all hash schemes the forum can potentially use. Client will emit error instead of trying to send password if TLS wasn't established.<br /> <br /> * server response<br /> ** '''[join_lobby]'''<br /> *** '''is_moderator''': &quot;yes&quot; if the user is a moderator, &quot;no&quot; otherwise.<br /> *** '''profile_url_prefix''': The external URL prefix for player profiles (empty if the server doesn't have an attached database)<br /> ** or '''[error]''' (server is waiting for another '''[login]''' message now)<br /> *** '''message''': The error message.<br /> *** '''password_request''': If not empty the server asks the client to provide a password for its desired username.<br /> *** '''phpbb_encryption''': If &quot;yes&quot; the client will encrypt the password using phpbb's algorithm.<br /> *** '''random_salt''': Random salt sent to the client for mixing with the password hash.<br /> *** '''hash_seed''': Salt generated from the original hash that is required to recreate it.<br /> *** '''salt''': Salt generated from the original hash that is required to recreate it.<br /> *** '''force_confirmation''': Display an ok/cancel dialog with the content of the 'message' key.<br /> <br /> * server response<br /> ** '''[gamelist]'''<br /> *** '''[game]''' (repeated)<br /> **** '''id''': A unique id of the game.<br /> **** '''name''': The title of the game.<br /> **** '''mp_scenario''': The id of the scenario.<br /> **** '''mp_era''': The id of the used era.<br /> **** '''mp_use_map_settings''': Does the game use the map settings specified in the scenario.<br /> **** '''mp_fog''': Does the game use fog.<br /> **** '''mp_shroud''': Does the game use shroud.<br /> **** '''mp_village_gold''': The number of gold per village.<br /> **** '''experience_modifier''': The experience setting.<br /> **** '''mp_countdown''': Does the game use a timer.<br /> **** '''mp_countdown_reservoir_time''': Upper limit of the possibly available time.<br /> **** '''mp_countdown_init_time''': Initial time.<br /> **** '''mp_countdown_action_bonus''': Time bonus per action.<br /> **** '''mp_countdown_turn_bonus''': Time bonus per turn.<br /> **** '''map_data''': The map data. ''Notice: not sent to lobby if the game uses shroud''<br /> **** '''hash''': The hash value of the map_data.<br /> **** '''observer''': Are observers allowed or not.<br /> **** '''human_sides''': The number of sides played by humans.<br /> **** '''slots''': The number of vacant/max slots.<br /> **** '''[slot_data]''' replaces '''slots''' since {{DevFeature1.13|12}}<br /> ***** '''max''': The number of total slots.<br /> ***** '''vacant''': The number of vacant slots.<br /> **** '''turn''': The current turn/max turn.<br /> **** '''[turn_data]''' replaces '''turn''' since {{DevFeature1.13|12}}<br /> ***** '''current''': The current turn number.<br /> ***** '''max''': The total number of turns.<br /> **** '''[modification]''' Modifications used in this game. See [[ModificationWML]].<br /> ***** '''id''': ID of the modification.<br /> ***** '''name''': Name of the modification.<br /> ***** '''addon_id''': ID of the addon the modification is from.<br /> ***** '''require_modification''': A boolean value; if set to yes, all players have to have this modification installed to join the game.<br /> **** '''[options]''' Options selected for this game. See [[OptionWML]].<br /> ***** '''[campaign|era|modification|multiplayer]'''<br /> ****** '''id''': ID of the addon the campaign|era|modification|multiplayer (scenario) is from.<br /> ****** '''[option]'''<br /> ******* '''id''': ID of the option.<br /> ******* '''value''': Value of the option.<br /> ** '''[user]''' (repeated)<br /> *** '''name''': The username of the player.<br /> *** '''game_id''': The ID of the game the player is in.<br /> *** '''location''': The name of the game the player is in.<br /> *** '''available''': &quot;yes&quot; if the player is in the lobby; &quot;no&quot; if in a game.<br /> Many of the keys under [game] are described more indepth on the [[ScenarioWML]] page.<br /> <br /> == Error messages ==<br /> <br /> * '''[error]'''<br /> ** '''message''': The error message.<br /> ** '''password_request''': This is a response to a login attempt. The client needs to send a password on another login attempt.<br /> ** '''force_confirmation''': Confirmation to login even if there is an existing client with the same name. If login is continued then that existing client is getting kicked.<br /> <br /> == Chat (lobby and in-game) ==<br /> <br /> * '''[message]'''<br /> ** '''sender''': (optional - filled by the server) The sender of the message.<br /> ** '''message''': The message itself.<br /> ** '''room''': The room the message is from/to<br /> * '''[whisper]'''<br /> ** '''receiver''': The receiver of the whisper<br /> ** '''sender''': (optional - filled by the server) The sender of the whisper.<br /> ** '''message''': The message itself.<br /> <br /> == Nickname registration related commands (lobby and in-game) ==<br /> <br /> * '''[nickserv]'''<br /> ** '''[info]''': Request info about another username.<br /> *** '''name''': The username.<br /> <br /> == Updating the lobby state ==<br /> <br /> * '''[gamelist_diff]''': server message - basically a [[DiffWML|diff]] from two gamelists, which also includes the user list.<br /> <br /> * '''[observer]''' or '''[observer_quit]''': server message - players joining([observer_quit] - quitting the lobby &quot;game&quot;)/quitting([observer] - joining the lobby &quot;game&quot;) a game<br /> ** '''name''': Username of the player/observer.<br /> * '''[refresh_lobby]''': Request the full gamelist.<br /> <br /> == Game setup (the phase from creation to start) ==<br /> To create a game the client sends:<br /> * '''[create_game]'''<br /> ** '''name''': The title of the game.<br /> ** '''password''': The password to use to join the game.<br /> ** '''ignored''': The list of ignored players from the host.<br /> ** '''auto_hosted''': True if this request is from a bot, false otherwise.<br /> <br /> followed by a message with the scenario options as under [game] (see above) plus the scenario data ([time], [era], [side], etc. see [[ScenarioWML]])<br /> <br /> * '''[join]'''<br /> ** '''id''': The id of the game.<br /> ** '''observe''': Join the game as an observer.<br /> <br /> * '''[scenario_diff]''': [[DiffWML|diff]] of the [[ScenarioWML]] (side changes, etc.)<br /> <br /> * '''[start_game]''': sent by the host to start a game<br /> * '''[leave_game]''': sent by the client when it leaves a game; sent by the server to make a client leave a game<br /> ** '''reason''': optional reason if sent by the server and was initiated by moderator action<br /> <br /> == In-game communication ==<br /> <br /> Normal scenario communication ([[ReplayWML]]):<br /> * '''[turn]'''<br /> ** '''[command]''': (repeated) can contain all the tags you can find in a [[ReplayWML|replay]]: [recruit], [move], [end_turn], etc.<br /> *** '''[speak]'''<br /> **** '''message''': text of the message<br /> **** '''id''': the sender<br /> **** '''team_name''': the name of the team the message is for - empty if it's a public message<br /> <br /> Multiplayer specific communication:<br /> * '''[request_choice]'''<br /> ** '''request_id''': unique ID of the choice request<br /> ** '''[random_seed]''': client requests a random number (used for attacks for example)<br /> ** '''[change_controller_wml]''': change controller request from scenario WML<br /> *** '''side''': side number<br /> *** '''old_controller''': old [[SideWML#controller|controller]] value<br /> *** '''new_controller''': new [[SideWML#controller|controller]] value<br /> * '''[store_next_scenario]''': sent by the host - the scenario data (see [[ScenarioWML]]) to advance to the next scenario<br /> * '''[notify_next_scenario]''': sent by the server to tell players that the data for the next scenario is available<br /> * '''[load_next_scenario]''': sent by the client to request the data for the next scenario<br /> * '''[next_scenario]''': data for the next scenario (see [[ScenarioWML]]), sent by the server on request<br /> <br /> * '''[info]''': sent by the host on game end - info about the game state<br /> ** '''type''': &quot;termination&quot; <br /> ** '''condition''': the termination reason<br /> <br /> If a player leaves this is sent to the host for all sides he owned.<br /> * '''side_drop''': The number of a side that dropped because a player left.<br /> * '''controller''': The controller of that side. (&quot;ai&quot;, &quot;network&quot;)<br /> <br /> Client commands:<br /> * '''[change_controller]''': a player (un)droids one of his sides or assigns control to someone else (The host can assign control for any side.)<br /> ** '''side''': the side to change controller<br /> ** '''player''': the nickname of the player to take control<br /> ** '''controller''': the new controller: &quot;human&quot; or &quot;human_ai&quot;<br /> ** '''own_side''': &quot;yes&quot;<br /> * '''[muteall]''': the host mutes/unmutes all observers - toggles<br /> * '''[mute]''': the host mutes an observer - toggles<br /> ** '''username''': the username of the observer - if not specified the servers returns a list of muted usernames<br /> * '''[kick]''' or '''[ban]''': the host kicks/bans a player/observer<br /> ** '''username''': the username of the player/observer<br /> <br /> == Game history ==<br /> This is a request to query a set of 11 rows of game history data based on the provided search criteria. The official client calls this from the Match History button in the multiplayer lobby to display 10 rows of data. The 11th row is used as a flag to indicate whether there is more data to be queried or not via the right/left arrows on the dialog.<br /> <br /> * '''[game_history_request]'''<br /> ** '''offset''': where in the result set to start returning data from. If there are 50 results and offset 10 is given, then rows 10-21 will be returned.<br /> ** '''search_player''': the forum username of the player to search for.<br /> ** '''search_game_name''': the name of the game to filter results by. Can use the * (matches any character before or after it's used) and _ (matches any single character) wildcards.<br /> ** '''search_content_type''': the type of content to filter by. Must be one of:<br /> *** '''0''': scenario<br /> *** '''1''': era<br /> *** '''2''':modification<br /> ** '''search_content''': The content to filter by. This is the ID of the content, not the name displayed on the UI, due to the translated name getting stored in the database.<br /> <br /> == Queues ==<br /> Queue info sent to the client on join or when the server's config is reloaded and the queue information has changed:<br /> * '''[queue_update]'''<br /> ** '''queue_id''': The server's unique ID for the queue.<br /> ** '''action''': One of add/update/remove.<br /> ** '''display_name''': The text to show in the list of queues in the lobby. Only used by add/update.<br /> ** '''players_required''': How many players are required before a game is started. Only used by add/update.<br /> <br /> When there are enough players to start a game, the last player to join the queue is chosen as the host and their client is told to create the game with the provided settings. This skips the game creation screen and goes straight to the staging screen. The other players in the queue are then told to join that game using the normal [join] command:<br /> * '''[create_game]'''<br /> ** '''queue_id''': The ID of the queue to create the game for.<br /> ** '''[game]'''<br /> *** '''scenario''': The ID of the scenario to create the game for.<br /> *** '''era''': The ID of the era to use.<br /> *** '''fog''': Whether to have fog enabled.<br /> *** '''shroud''': Whether to have shroud enabled.<br /> *** '''village_gold''': How much gold each village provides.<br /> *** '''village_support''': How much unit support each village provides<br /> *** '''experience_modifier''': The experience modifier to use.<br /> *** '''countdown''': Not currently used, set to false.<br /> *** '''random_start_time''': Whether to start at a random time of day.<br /> *** '''shuffle_sides''': Whether to shuffle the sides' starting positions.<br /> <br /> == Administrative commands ==<br /> * '''[query]'''<br /> ** '''type''': The type of query. See [[ServerAdministration]] for details.<br /> <br /> == See also ==<br /> [https://github.com/renom/fastbot fastbot] - the bot for tournaments which implements the protocol, can log in into the lobby and host games. Written in Go. <br /> [[Category:WML Reference]]<br /> [[Category:Server Documentation]]</div>

Pentarctagon https://wiki.wesnoth.org/index.php?title=MultiplayerServerWML&diff=74859 2026-02-22T15:13:08Z

<p>Pentarctagon: /* Queues */</p> <hr /> <div>This page describes the [[WML]] used to communicate with the multiplayer server for Wesnoth, [[wesnothd]].<br /> <br /> == The handshake ==<br /> <br /> The client sends four bytes, then the server replies with four bytes. To get a new connection number, the client will send these four bytes: 0x00 0x00 0x00 0x00. The server then sends back the connection number (wesnothd calls this number the &quot;socket number&quot;). Since 1.13+ the server no longer is using socket numbers to keep track of clients and always sends the same number to them all. Since 1.15+ client can also send 0x00 0x00 0x00 0x01 instead to request entire connection to be [https://github.com/wesnoth/wesnoth/blob/2f8136951cd77526188cf8d0fb2cf21eaa2ebe63/src/server/common/server_base.hpp#L60-L76 encapsulated in TLS] immediately '''after'''. If the handshake is successful, the server will be the first to send a data package. All packages are in [http://en.wikipedia.org/wiki/Gzip gzip] format and are preceded by four bytes that specify the size of the package to come in '''big-endian''' (network byte order). Below you'll find information about what data the (unzipped) packages contain. Unpacked WML uses utf-8 charset.<br /> <br /> == The login procedure ==<br /> <br /> * server request (optional)<br /> ** '''[version]'''<br /> <br /> * client response<br /> ** '''[version]'''<br /> *** '''version''': The client's version string.<br /> *** '''client_source''': The client's distribution info. (Steam, SourceForge, App Store, etc.)<br /> <br /> * server response (if the server does not accept this version)<br /> ** '''[redirect]'''<br /> *** '''host''': The host you should connect to.<br /> *** '''port''': The port you should connect to.<br /> *** '''version''': A comma-separated list of globs that this server should accept (e.g. &quot;1.0*,1.2*,1.4*,1.7*,1.8*&quot;)<br /> ** or '''[reject]''' (if the version is unknown)<br /> *** '''accepted_versions''': A comma-separated list of globs that this server does accept<br /> <br /> * server request<br /> ** '''[mustlogin]'''<br /> <br /> * client response<br /> ** '''[login]'''<br /> *** '''username''': The username the client would like to have.<br /> *** '''password''': The hashed password, created from the password and salt received from the server. More information about how this password is being generated, including a real world example, can be found in the file [http://forum.wesnoth.org/download/file.php?id=41145 HashedPasswords.pdf] (885 KiB). Since version 1.15+ if TLS was successfully established before then password will be passed as is, without hashing, relying on TLS for secrecy. Passing password hashes is no longer supported to free the client from responsibility to support all hash schemes the forum can potentially use. Client will emit error instead of trying to send password if TLS wasn't established.<br /> <br /> * server response<br /> ** '''[join_lobby]'''<br /> *** '''is_moderator''': &quot;yes&quot; if the user is a moderator, &quot;no&quot; otherwise.<br /> *** '''profile_url_prefix''': The external URL prefix for player profiles (empty if the server doesn't have an attached database)<br /> ** or '''[error]''' (server is waiting for another '''[login]''' message now)<br /> *** '''message''': The error message.<br /> *** '''password_request''': If not empty the server asks the client to provide a password for its desired username.<br /> *** '''phpbb_encryption''': If &quot;yes&quot; the client will encrypt the password using phpbb's algorithm.<br /> *** '''random_salt''': Random salt sent to the client for mixing with the password hash.<br /> *** '''hash_seed''': Salt generated from the original hash that is required to recreate it.<br /> *** '''salt''': Salt generated from the original hash that is required to recreate it.<br /> *** '''force_confirmation''': Display an ok/cancel dialog with the content of the 'message' key.<br /> <br /> * server response<br /> ** '''[gamelist]'''<br /> *** '''[game]''' (repeated)<br /> **** '''id''': A unique id of the game.<br /> **** '''name''': The title of the game.<br /> **** '''mp_scenario''': The id of the scenario.<br /> **** '''mp_era''': The id of the used era.<br /> **** '''mp_use_map_settings''': Does the game use the map settings specified in the scenario.<br /> **** '''mp_fog''': Does the game use fog.<br /> **** '''mp_shroud''': Does the game use shroud.<br /> **** '''mp_village_gold''': The number of gold per village.<br /> **** '''experience_modifier''': The experience setting.<br /> **** '''mp_countdown''': Does the game use a timer.<br /> **** '''mp_countdown_reservoir_time''': Upper limit of the possibly available time.<br /> **** '''mp_countdown_init_time''': Initial time.<br /> **** '''mp_countdown_action_bonus''': Time bonus per action.<br /> **** '''mp_countdown_turn_bonus''': Time bonus per turn.<br /> **** '''map_data''': The map data. ''Notice: not sent to lobby if the game uses shroud''<br /> **** '''hash''': The hash value of the map_data.<br /> **** '''observer''': Are observers allowed or not.<br /> **** '''human_sides''': The number of sides played by humans.<br /> **** '''slots''': The number of vacant/max slots.<br /> **** '''[slot_data]''' replaces '''slots''' since {{DevFeature1.13|12}}<br /> ***** '''max''': The number of total slots.<br /> ***** '''vacant''': The number of vacant slots.<br /> **** '''turn''': The current turn/max turn.<br /> **** '''[turn_data]''' replaces '''turn''' since {{DevFeature1.13|12}}<br /> ***** '''current''': The current turn number.<br /> ***** '''max''': The total number of turns.<br /> **** '''[modification]''' Modifications used in this game. See [[ModificationWML]].<br /> ***** '''id''': ID of the modification.<br /> ***** '''name''': Name of the modification.<br /> ***** '''addon_id''': ID of the addon the modification is from.<br /> ***** '''require_modification''': A boolean value; if set to yes, all players have to have this modification installed to join the game.<br /> **** '''[options]''' Options selected for this game. See [[OptionWML]].<br /> ***** '''[campaign|era|modification|multiplayer]'''<br /> ****** '''id''': ID of the addon the campaign|era|modification|multiplayer (scenario) is from.<br /> ****** '''[option]'''<br /> ******* '''id''': ID of the option.<br /> ******* '''value''': Value of the option.<br /> ** '''[user]''' (repeated)<br /> *** '''name''': The username of the player.<br /> *** '''game_id''': The ID of the game the player is in.<br /> *** '''location''': The name of the game the player is in.<br /> *** '''available''': &quot;yes&quot; if the player is in the lobby; &quot;no&quot; if in a game.<br /> Many of the keys under [game] are described more indepth on the [[ScenarioWML]] page.<br /> <br /> == Error messages ==<br /> <br /> * '''[error]'''<br /> ** '''message''': The error message.<br /> ** '''password_request''': This is a response to a login attempt. The client needs to send a password on another login attempt.<br /> ** '''force_confirmation''': Confirmation to login even if there is an existing client with the same name. If login is continued then that existing client is getting kicked.<br /> <br /> == Chat (lobby and in-game) ==<br /> <br /> * '''[message]'''<br /> ** '''sender''': (optional - filled by the server) The sender of the message.<br /> ** '''message''': The message itself.<br /> ** '''room''': The room the message is from/to<br /> * '''[whisper]'''<br /> ** '''receiver''': The receiver of the whisper<br /> ** '''sender''': (optional - filled by the server) The sender of the whisper.<br /> ** '''message''': The message itself.<br /> <br /> == Nickname registration related commands (lobby and in-game) ==<br /> <br /> * '''[nickserv]'''<br /> ** '''[info]''': Request info about another username.<br /> *** '''name''': The username.<br /> <br /> == Updating the lobby state ==<br /> <br /> * '''[gamelist_diff]''': server message - basically a [[DiffWML|diff]] from two gamelists, which also includes the user list.<br /> <br /> * '''[observer]''' or '''[observer_quit]''': server message - players joining([observer_quit] - quitting the lobby &quot;game&quot;)/quitting([observer] - joining the lobby &quot;game&quot;) a game<br /> ** '''name''': Username of the player/observer.<br /> * '''[refresh_lobby]''': Request the full gamelist.<br /> <br /> == Game setup (the phase from creation to start) ==<br /> To create a game the client sends:<br /> * '''[create_game]'''<br /> ** '''name''': The title of the game.<br /> ** '''password''': The password to use to join the game.<br /> ** '''ignored''': The list of ignored players from the host.<br /> ** '''auto_hosted''': True if this request is from a bot, false otherwise.<br /> <br /> followed by a message with the scenario options as under [game] (see above) plus the scenario data ([time], [era], [side], etc. see [[ScenarioWML]])<br /> <br /> * '''[join]'''<br /> ** '''id''': The id of the game.<br /> ** '''observe''': Join the game as an observer.<br /> <br /> * '''[scenario_diff]''': [[DiffWML|diff]] of the [[ScenarioWML]] (side changes, etc.)<br /> <br /> * '''[start_game]''': sent by the host to start a game<br /> * '''[leave_game]''': sent by the client when it leaves a game; sent by the server to make a client leave a game<br /> ** '''reason''': optional reason if sent by the server and was initiated by moderator action<br /> <br /> == In-game communication ==<br /> <br /> Normal scenario communication ([[ReplayWML]]):<br /> * '''[turn]'''<br /> ** '''[command]''': (repeated) can contain all the tags you can find in a [[ReplayWML|replay]]: [recruit], [move], [end_turn], etc.<br /> *** '''[speak]'''<br /> **** '''message''': text of the message<br /> **** '''id''': the sender<br /> **** '''team_name''': the name of the team the message is for - empty if it's a public message<br /> <br /> Multiplayer specific communication:<br /> * '''[request_choice]'''<br /> ** '''request_id''': unique ID of the choice request<br /> ** '''[random_seed]''': client requests a random number (used for attacks for example)<br /> ** '''[change_controller_wml]''': change controller request from scenario WML<br /> *** '''side''': side number<br /> *** '''old_controller''': old [[SideWML#controller|controller]] value<br /> *** '''new_controller''': new [[SideWML#controller|controller]] value<br /> * '''[store_next_scenario]''': sent by the host - the scenario data (see [[ScenarioWML]]) to advance to the next scenario<br /> * '''[notify_next_scenario]''': sent by the server to tell players that the data for the next scenario is available<br /> * '''[load_next_scenario]''': sent by the client to request the data for the next scenario<br /> * '''[next_scenario]''': data for the next scenario (see [[ScenarioWML]]), sent by the server on request<br /> <br /> * '''[info]''': sent by the host on game end - info about the game state<br /> ** '''type''': &quot;termination&quot; <br /> ** '''condition''': the termination reason<br /> <br /> If a player leaves this is sent to the host for all sides he owned.<br /> * '''side_drop''': The number of a side that dropped because a player left.<br /> * '''controller''': The controller of that side. (&quot;ai&quot;, &quot;network&quot;)<br /> <br /> Client commands:<br /> * '''[change_controller]''': a player (un)droids one of his sides or assigns control to someone else (The host can assign control for any side.)<br /> ** '''side''': the side to change controller<br /> ** '''player''': the nickname of the player to take control<br /> ** '''controller''': the new controller: &quot;human&quot; or &quot;human_ai&quot;<br /> ** '''own_side''': &quot;yes&quot;<br /> * '''[muteall]''': the host mutes/unmutes all observers - toggles<br /> * '''[mute]''': the host mutes an observer - toggles<br /> ** '''username''': the username of the observer - if not specified the servers returns a list of muted usernames<br /> * '''[kick]''' or '''[ban]''': the host kicks/bans a player/observer<br /> ** '''username''': the username of the player/observer<br /> <br /> == Game history ==<br /> This is a request to query a set of 11 rows of game history data based on the provided search criteria. The official client calls this from the Match History button in the multiplayer lobby to display 10 rows of data. The 11th row is used as a flag to indicate whether there is more data to be queried or not via the right/left arrows on the dialog.<br /> <br /> * '''[game_history_request]'''<br /> ** '''offset''': where in the result set to start returning data from. If there are 50 results and offset 10 is given, then rows 10-21 will be returned.<br /> ** '''search_player''': the forum username of the player to search for.<br /> ** '''search_game_name''': the name of the game to filter results by. Can use the * (matches any character before or after it's used) and _ (matches any single character) wildcards.<br /> ** '''search_content_type''': the type of content to filter by. Must be one of:<br /> *** '''0''': scenario<br /> *** '''1''': era<br /> *** '''2''':modification<br /> ** '''search_content''': The content to filter by. This is the ID of the content, not the name displayed on the UI, due to the translated name getting stored in the database.<br /> <br /> == Queues ==<br /> Queue info sent to the client on join or when the server's config is reloaded and the queue information has changed:<br /> * '''[queue_update]'''<br /> ** '''queue_id''': The server's unique ID for the queue.<br /> ** '''action''': One of add/update/remove.<br /> ** '''display_name''': The text to show in the list of queues in the lobby. Only used by add/update.<br /> ** '''players_required''': How many players are required before a game is started. Only used by add/update.<br /> <br /> When there are enough players to start a game, the last player to join the queue is chosen as the host and their client is told to create the game with the provided settings. This skips the game creation screen and goes straight to the staging screen. The other players in the queue are then told to join that game:<br /> * '''[create_game]'''<br /> ** '''queue_id''': The ID of the queue to create the game for.<br /> ** '''[game]'''<br /> *** '''scenario''': The ID of the scenario to create the game for.<br /> *** '''era''': The ID of the era to use.<br /> *** '''fog''': Whether to have fog enabled.<br /> *** '''shroud''': Whether to have shroud enabled.<br /> *** '''village_gold''': How much gold each village provides.<br /> *** '''village_support''': How much unit support each village provides<br /> *** '''experience_modifier''': The experience modifier to use.<br /> *** '''countdown''': Not currently used, set to false.<br /> *** '''random_start_time''': Whether to start at a random time of day.<br /> *** '''shuffle_sides''': Whether to shuffle the sides' starting positions.<br /> <br /> == Administrative commands ==<br /> * '''[query]'''<br /> ** '''type''': The type of query. See [[ServerAdministration]] for details.<br /> <br /> == See also ==<br /> [https://github.com/renom/fastbot fastbot] - the bot for tournaments which implements the protocol, can log in into the lobby and host games. Written in Go. <br /> [[Category:WML Reference]]<br /> [[Category:Server Documentation]]</div>

Pentarctagon https://wiki.wesnoth.org/index.php?title=MultiplayerServerWML&diff=74858 2026-02-22T14:46:30Z

<p>Pentarctagon: /* Queues */</p> <hr /> <div>This page describes the [[WML]] used to communicate with the multiplayer server for Wesnoth, [[wesnothd]].<br /> <br /> == The handshake ==<br /> <br /> The client sends four bytes, then the server replies with four bytes. To get a new connection number, the client will send these four bytes: 0x00 0x00 0x00 0x00. The server then sends back the connection number (wesnothd calls this number the &quot;socket number&quot;). Since 1.13+ the server no longer is using socket numbers to keep track of clients and always sends the same number to them all. Since 1.15+ client can also send 0x00 0x00 0x00 0x01 instead to request entire connection to be [https://github.com/wesnoth/wesnoth/blob/2f8136951cd77526188cf8d0fb2cf21eaa2ebe63/src/server/common/server_base.hpp#L60-L76 encapsulated in TLS] immediately '''after'''. If the handshake is successful, the server will be the first to send a data package. All packages are in [http://en.wikipedia.org/wiki/Gzip gzip] format and are preceded by four bytes that specify the size of the package to come in '''big-endian''' (network byte order). Below you'll find information about what data the (unzipped) packages contain. Unpacked WML uses utf-8 charset.<br /> <br /> == The login procedure ==<br /> <br /> * server request (optional)<br /> ** '''[version]'''<br /> <br /> * client response<br /> ** '''[version]'''<br /> *** '''version''': The client's version string.<br /> *** '''client_source''': The client's distribution info. (Steam, SourceForge, App Store, etc.)<br /> <br /> * server response (if the server does not accept this version)<br /> ** '''[redirect]'''<br /> *** '''host''': The host you should connect to.<br /> *** '''port''': The port you should connect to.<br /> *** '''version''': A comma-separated list of globs that this server should accept (e.g. &quot;1.0*,1.2*,1.4*,1.7*,1.8*&quot;)<br /> ** or '''[reject]''' (if the version is unknown)<br /> *** '''accepted_versions''': A comma-separated list of globs that this server does accept<br /> <br /> * server request<br /> ** '''[mustlogin]'''<br /> <br /> * client response<br /> ** '''[login]'''<br /> *** '''username''': The username the client would like to have.<br /> *** '''password''': The hashed password, created from the password and salt received from the server. More information about how this password is being generated, including a real world example, can be found in the file [http://forum.wesnoth.org/download/file.php?id=41145 HashedPasswords.pdf] (885 KiB). Since version 1.15+ if TLS was successfully established before then password will be passed as is, without hashing, relying on TLS for secrecy. Passing password hashes is no longer supported to free the client from responsibility to support all hash schemes the forum can potentially use. Client will emit error instead of trying to send password if TLS wasn't established.<br /> <br /> * server response<br /> ** '''[join_lobby]'''<br /> *** '''is_moderator''': &quot;yes&quot; if the user is a moderator, &quot;no&quot; otherwise.<br /> *** '''profile_url_prefix''': The external URL prefix for player profiles (empty if the server doesn't have an attached database)<br /> ** or '''[error]''' (server is waiting for another '''[login]''' message now)<br /> *** '''message''': The error message.<br /> *** '''password_request''': If not empty the server asks the client to provide a password for its desired username.<br /> *** '''phpbb_encryption''': If &quot;yes&quot; the client will encrypt the password using phpbb's algorithm.<br /> *** '''random_salt''': Random salt sent to the client for mixing with the password hash.<br /> *** '''hash_seed''': Salt generated from the original hash that is required to recreate it.<br /> *** '''salt''': Salt generated from the original hash that is required to recreate it.<br /> *** '''force_confirmation''': Display an ok/cancel dialog with the content of the 'message' key.<br /> <br /> * server response<br /> ** '''[gamelist]'''<br /> *** '''[game]''' (repeated)<br /> **** '''id''': A unique id of the game.<br /> **** '''name''': The title of the game.<br /> **** '''mp_scenario''': The id of the scenario.<br /> **** '''mp_era''': The id of the used era.<br /> **** '''mp_use_map_settings''': Does the game use the map settings specified in the scenario.<br /> **** '''mp_fog''': Does the game use fog.<br /> **** '''mp_shroud''': Does the game use shroud.<br /> **** '''mp_village_gold''': The number of gold per village.<br /> **** '''experience_modifier''': The experience setting.<br /> **** '''mp_countdown''': Does the game use a timer.<br /> **** '''mp_countdown_reservoir_time''': Upper limit of the possibly available time.<br /> **** '''mp_countdown_init_time''': Initial time.<br /> **** '''mp_countdown_action_bonus''': Time bonus per action.<br /> **** '''mp_countdown_turn_bonus''': Time bonus per turn.<br /> **** '''map_data''': The map data. ''Notice: not sent to lobby if the game uses shroud''<br /> **** '''hash''': The hash value of the map_data.<br /> **** '''observer''': Are observers allowed or not.<br /> **** '''human_sides''': The number of sides played by humans.<br /> **** '''slots''': The number of vacant/max slots.<br /> **** '''[slot_data]''' replaces '''slots''' since {{DevFeature1.13|12}}<br /> ***** '''max''': The number of total slots.<br /> ***** '''vacant''': The number of vacant slots.<br /> **** '''turn''': The current turn/max turn.<br /> **** '''[turn_data]''' replaces '''turn''' since {{DevFeature1.13|12}}<br /> ***** '''current''': The current turn number.<br /> ***** '''max''': The total number of turns.<br /> **** '''[modification]''' Modifications used in this game. See [[ModificationWML]].<br /> ***** '''id''': ID of the modification.<br /> ***** '''name''': Name of the modification.<br /> ***** '''addon_id''': ID of the addon the modification is from.<br /> ***** '''require_modification''': A boolean value; if set to yes, all players have to have this modification installed to join the game.<br /> **** '''[options]''' Options selected for this game. See [[OptionWML]].<br /> ***** '''[campaign|era|modification|multiplayer]'''<br /> ****** '''id''': ID of the addon the campaign|era|modification|multiplayer (scenario) is from.<br /> ****** '''[option]'''<br /> ******* '''id''': ID of the option.<br /> ******* '''value''': Value of the option.<br /> ** '''[user]''' (repeated)<br /> *** '''name''': The username of the player.<br /> *** '''game_id''': The ID of the game the player is in.<br /> *** '''location''': The name of the game the player is in.<br /> *** '''available''': &quot;yes&quot; if the player is in the lobby; &quot;no&quot; if in a game.<br /> Many of the keys under [game] are described more indepth on the [[ScenarioWML]] page.<br /> <br /> == Error messages ==<br /> <br /> * '''[error]'''<br /> ** '''message''': The error message.<br /> ** '''password_request''': This is a response to a login attempt. The client needs to send a password on another login attempt.<br /> ** '''force_confirmation''': Confirmation to login even if there is an existing client with the same name. If login is continued then that existing client is getting kicked.<br /> <br /> == Chat (lobby and in-game) ==<br /> <br /> * '''[message]'''<br /> ** '''sender''': (optional - filled by the server) The sender of the message.<br /> ** '''message''': The message itself.<br /> ** '''room''': The room the message is from/to<br /> * '''[whisper]'''<br /> ** '''receiver''': The receiver of the whisper<br /> ** '''sender''': (optional - filled by the server) The sender of the whisper.<br /> ** '''message''': The message itself.<br /> <br /> == Nickname registration related commands (lobby and in-game) ==<br /> <br /> * '''[nickserv]'''<br /> ** '''[info]''': Request info about another username.<br /> *** '''name''': The username.<br /> <br /> == Updating the lobby state ==<br /> <br /> * '''[gamelist_diff]''': server message - basically a [[DiffWML|diff]] from two gamelists, which also includes the user list.<br /> <br /> * '''[observer]''' or '''[observer_quit]''': server message - players joining([observer_quit] - quitting the lobby &quot;game&quot;)/quitting([observer] - joining the lobby &quot;game&quot;) a game<br /> ** '''name''': Username of the player/observer.<br /> * '''[refresh_lobby]''': Request the full gamelist.<br /> <br /> == Game setup (the phase from creation to start) ==<br /> To create a game the client sends:<br /> * '''[create_game]'''<br /> ** '''name''': The title of the game.<br /> ** '''password''': The password to use to join the game.<br /> ** '''ignored''': The list of ignored players from the host.<br /> ** '''auto_hosted''': True if this request is from a bot, false otherwise.<br /> <br /> followed by a message with the scenario options as under [game] (see above) plus the scenario data ([time], [era], [side], etc. see [[ScenarioWML]])<br /> <br /> * '''[join]'''<br /> ** '''id''': The id of the game.<br /> ** '''observe''': Join the game as an observer.<br /> <br /> * '''[scenario_diff]''': [[DiffWML|diff]] of the [[ScenarioWML]] (side changes, etc.)<br /> <br /> * '''[start_game]''': sent by the host to start a game<br /> * '''[leave_game]''': sent by the client when it leaves a game; sent by the server to make a client leave a game<br /> ** '''reason''': optional reason if sent by the server and was initiated by moderator action<br /> <br /> == In-game communication ==<br /> <br /> Normal scenario communication ([[ReplayWML]]):<br /> * '''[turn]'''<br /> ** '''[command]''': (repeated) can contain all the tags you can find in a [[ReplayWML|replay]]: [recruit], [move], [end_turn], etc.<br /> *** '''[speak]'''<br /> **** '''message''': text of the message<br /> **** '''id''': the sender<br /> **** '''team_name''': the name of the team the message is for - empty if it's a public message<br /> <br /> Multiplayer specific communication:<br /> * '''[request_choice]'''<br /> ** '''request_id''': unique ID of the choice request<br /> ** '''[random_seed]''': client requests a random number (used for attacks for example)<br /> ** '''[change_controller_wml]''': change controller request from scenario WML<br /> *** '''side''': side number<br /> *** '''old_controller''': old [[SideWML#controller|controller]] value<br /> *** '''new_controller''': new [[SideWML#controller|controller]] value<br /> * '''[store_next_scenario]''': sent by the host - the scenario data (see [[ScenarioWML]]) to advance to the next scenario<br /> * '''[notify_next_scenario]''': sent by the server to tell players that the data for the next scenario is available<br /> * '''[load_next_scenario]''': sent by the client to request the data for the next scenario<br /> * '''[next_scenario]''': data for the next scenario (see [[ScenarioWML]]), sent by the server on request<br /> <br /> * '''[info]''': sent by the host on game end - info about the game state<br /> ** '''type''': &quot;termination&quot; <br /> ** '''condition''': the termination reason<br /> <br /> If a player leaves this is sent to the host for all sides he owned.<br /> * '''side_drop''': The number of a side that dropped because a player left.<br /> * '''controller''': The controller of that side. (&quot;ai&quot;, &quot;network&quot;)<br /> <br /> Client commands:<br /> * '''[change_controller]''': a player (un)droids one of his sides or assigns control to someone else (The host can assign control for any side.)<br /> ** '''side''': the side to change controller<br /> ** '''player''': the nickname of the player to take control<br /> ** '''controller''': the new controller: &quot;human&quot; or &quot;human_ai&quot;<br /> ** '''own_side''': &quot;yes&quot;<br /> * '''[muteall]''': the host mutes/unmutes all observers - toggles<br /> * '''[mute]''': the host mutes an observer - toggles<br /> ** '''username''': the username of the observer - if not specified the servers returns a list of muted usernames<br /> * '''[kick]''' or '''[ban]''': the host kicks/bans a player/observer<br /> ** '''username''': the username of the player/observer<br /> <br /> == Game history ==<br /> This is a request to query a set of 11 rows of game history data based on the provided search criteria. The official client calls this from the Match History button in the multiplayer lobby to display 10 rows of data. The 11th row is used as a flag to indicate whether there is more data to be queried or not via the right/left arrows on the dialog.<br /> <br /> * '''[game_history_request]'''<br /> ** '''offset''': where in the result set to start returning data from. If there are 50 results and offset 10 is given, then rows 10-21 will be returned.<br /> ** '''search_player''': the forum username of the player to search for.<br /> ** '''search_game_name''': the name of the game to filter results by. Can use the * (matches any character before or after it's used) and _ (matches any single character) wildcards.<br /> ** '''search_content_type''': the type of content to filter by. Must be one of:<br /> *** '''0''': scenario<br /> *** '''1''': era<br /> *** '''2''':modification<br /> ** '''search_content''': The content to filter by. This is the ID of the content, not the name displayed on the UI, due to the translated name getting stored in the database.<br /> <br /> == Queues ==<br /> Queue info sent to the client on join or when the server's config is reloaded and the queue information has changed:<br /> * '''[queue_update]'''<br /> ** '''queue_id''': The server's unique ID for the queue.<br /> ** '''action''': One of add/update/remove.<br /> ** '''display_name''': The text to show in the list of queues in the lobby. Only used by add/update.<br /> ** '''players_required''': How many players are required before a game is started. Only used by add/update.<br /> <br /> == Administrative commands ==<br /> * '''[query]'''<br /> ** '''type''': The type of query. See [[ServerAdministration]] for details.<br /> <br /> == See also ==<br /> [https://github.com/renom/fastbot fastbot] - the bot for tournaments which implements the protocol, can log in into the lobby and host games. Written in Go. <br /> [[Category:WML Reference]]<br /> [[Category:Server Documentation]]</div>

Pentarctagon https://wiki.wesnoth.org/index.php?title=MultiplayerServerWML&diff=74857 2026-02-22T14:46:00Z

<p>Pentarctagon: </p> <hr /> <div>This page describes the [[WML]] used to communicate with the multiplayer server for Wesnoth, [[wesnothd]].<br /> <br /> == The handshake ==<br /> <br /> The client sends four bytes, then the server replies with four bytes. To get a new connection number, the client will send these four bytes: 0x00 0x00 0x00 0x00. The server then sends back the connection number (wesnothd calls this number the &quot;socket number&quot;). Since 1.13+ the server no longer is using socket numbers to keep track of clients and always sends the same number to them all. Since 1.15+ client can also send 0x00 0x00 0x00 0x01 instead to request entire connection to be [https://github.com/wesnoth/wesnoth/blob/2f8136951cd77526188cf8d0fb2cf21eaa2ebe63/src/server/common/server_base.hpp#L60-L76 encapsulated in TLS] immediately '''after'''. If the handshake is successful, the server will be the first to send a data package. All packages are in [http://en.wikipedia.org/wiki/Gzip gzip] format and are preceded by four bytes that specify the size of the package to come in '''big-endian''' (network byte order). Below you'll find information about what data the (unzipped) packages contain. Unpacked WML uses utf-8 charset.<br /> <br /> == The login procedure ==<br /> <br /> * server request (optional)<br /> ** '''[version]'''<br /> <br /> * client response<br /> ** '''[version]'''<br /> *** '''version''': The client's version string.<br /> *** '''client_source''': The client's distribution info. (Steam, SourceForge, App Store, etc.)<br /> <br /> * server response (if the server does not accept this version)<br /> ** '''[redirect]'''<br /> *** '''host''': The host you should connect to.<br /> *** '''port''': The port you should connect to.<br /> *** '''version''': A comma-separated list of globs that this server should accept (e.g. &quot;1.0*,1.2*,1.4*,1.7*,1.8*&quot;)<br /> ** or '''[reject]''' (if the version is unknown)<br /> *** '''accepted_versions''': A comma-separated list of globs that this server does accept<br /> <br /> * server request<br /> ** '''[mustlogin]'''<br /> <br /> * client response<br /> ** '''[login]'''<br /> *** '''username''': The username the client would like to have.<br /> *** '''password''': The hashed password, created from the password and salt received from the server. More information about how this password is being generated, including a real world example, can be found in the file [http://forum.wesnoth.org/download/file.php?id=41145 HashedPasswords.pdf] (885 KiB). Since version 1.15+ if TLS was successfully established before then password will be passed as is, without hashing, relying on TLS for secrecy. Passing password hashes is no longer supported to free the client from responsibility to support all hash schemes the forum can potentially use. Client will emit error instead of trying to send password if TLS wasn't established.<br /> <br /> * server response<br /> ** '''[join_lobby]'''<br /> *** '''is_moderator''': &quot;yes&quot; if the user is a moderator, &quot;no&quot; otherwise.<br /> *** '''profile_url_prefix''': The external URL prefix for player profiles (empty if the server doesn't have an attached database)<br /> ** or '''[error]''' (server is waiting for another '''[login]''' message now)<br /> *** '''message''': The error message.<br /> *** '''password_request''': If not empty the server asks the client to provide a password for its desired username.<br /> *** '''phpbb_encryption''': If &quot;yes&quot; the client will encrypt the password using phpbb's algorithm.<br /> *** '''random_salt''': Random salt sent to the client for mixing with the password hash.<br /> *** '''hash_seed''': Salt generated from the original hash that is required to recreate it.<br /> *** '''salt''': Salt generated from the original hash that is required to recreate it.<br /> *** '''force_confirmation''': Display an ok/cancel dialog with the content of the 'message' key.<br /> <br /> * server response<br /> ** '''[gamelist]'''<br /> *** '''[game]''' (repeated)<br /> **** '''id''': A unique id of the game.<br /> **** '''name''': The title of the game.<br /> **** '''mp_scenario''': The id of the scenario.<br /> **** '''mp_era''': The id of the used era.<br /> **** '''mp_use_map_settings''': Does the game use the map settings specified in the scenario.<br /> **** '''mp_fog''': Does the game use fog.<br /> **** '''mp_shroud''': Does the game use shroud.<br /> **** '''mp_village_gold''': The number of gold per village.<br /> **** '''experience_modifier''': The experience setting.<br /> **** '''mp_countdown''': Does the game use a timer.<br /> **** '''mp_countdown_reservoir_time''': Upper limit of the possibly available time.<br /> **** '''mp_countdown_init_time''': Initial time.<br /> **** '''mp_countdown_action_bonus''': Time bonus per action.<br /> **** '''mp_countdown_turn_bonus''': Time bonus per turn.<br /> **** '''map_data''': The map data. ''Notice: not sent to lobby if the game uses shroud''<br /> **** '''hash''': The hash value of the map_data.<br /> **** '''observer''': Are observers allowed or not.<br /> **** '''human_sides''': The number of sides played by humans.<br /> **** '''slots''': The number of vacant/max slots.<br /> **** '''[slot_data]''' replaces '''slots''' since {{DevFeature1.13|12}}<br /> ***** '''max''': The number of total slots.<br /> ***** '''vacant''': The number of vacant slots.<br /> **** '''turn''': The current turn/max turn.<br /> **** '''[turn_data]''' replaces '''turn''' since {{DevFeature1.13|12}}<br /> ***** '''current''': The current turn number.<br /> ***** '''max''': The total number of turns.<br /> **** '''[modification]''' Modifications used in this game. See [[ModificationWML]].<br /> ***** '''id''': ID of the modification.<br /> ***** '''name''': Name of the modification.<br /> ***** '''addon_id''': ID of the addon the modification is from.<br /> ***** '''require_modification''': A boolean value; if set to yes, all players have to have this modification installed to join the game.<br /> **** '''[options]''' Options selected for this game. See [[OptionWML]].<br /> ***** '''[campaign|era|modification|multiplayer]'''<br /> ****** '''id''': ID of the addon the campaign|era|modification|multiplayer (scenario) is from.<br /> ****** '''[option]'''<br /> ******* '''id''': ID of the option.<br /> ******* '''value''': Value of the option.<br /> ** '''[user]''' (repeated)<br /> *** '''name''': The username of the player.<br /> *** '''game_id''': The ID of the game the player is in.<br /> *** '''location''': The name of the game the player is in.<br /> *** '''available''': &quot;yes&quot; if the player is in the lobby; &quot;no&quot; if in a game.<br /> Many of the keys under [game] are described more indepth on the [[ScenarioWML]] page.<br /> <br /> == Error messages ==<br /> <br /> * '''[error]'''<br /> ** '''message''': The error message.<br /> ** '''password_request''': This is a response to a login attempt. The client needs to send a password on another login attempt.<br /> ** '''force_confirmation''': Confirmation to login even if there is an existing client with the same name. If login is continued then that existing client is getting kicked.<br /> <br /> == Chat (lobby and in-game) ==<br /> <br /> * '''[message]'''<br /> ** '''sender''': (optional - filled by the server) The sender of the message.<br /> ** '''message''': The message itself.<br /> ** '''room''': The room the message is from/to<br /> * '''[whisper]'''<br /> ** '''receiver''': The receiver of the whisper<br /> ** '''sender''': (optional - filled by the server) The sender of the whisper.<br /> ** '''message''': The message itself.<br /> <br /> == Nickname registration related commands (lobby and in-game) ==<br /> <br /> * '''[nickserv]'''<br /> ** '''[info]''': Request info about another username.<br /> *** '''name''': The username.<br /> <br /> == Updating the lobby state ==<br /> <br /> * '''[gamelist_diff]''': server message - basically a [[DiffWML|diff]] from two gamelists, which also includes the user list.<br /> <br /> * '''[observer]''' or '''[observer_quit]''': server message - players joining([observer_quit] - quitting the lobby &quot;game&quot;)/quitting([observer] - joining the lobby &quot;game&quot;) a game<br /> ** '''name''': Username of the player/observer.<br /> * '''[refresh_lobby]''': Request the full gamelist.<br /> <br /> == Game setup (the phase from creation to start) ==<br /> To create a game the client sends:<br /> * '''[create_game]'''<br /> ** '''name''': The title of the game.<br /> ** '''password''': The password to use to join the game.<br /> ** '''ignored''': The list of ignored players from the host.<br /> ** '''auto_hosted''': True if this request is from a bot, false otherwise.<br /> <br /> followed by a message with the scenario options as under [game] (see above) plus the scenario data ([time], [era], [side], etc. see [[ScenarioWML]])<br /> <br /> * '''[join]'''<br /> ** '''id''': The id of the game.<br /> ** '''observe''': Join the game as an observer.<br /> <br /> * '''[scenario_diff]''': [[DiffWML|diff]] of the [[ScenarioWML]] (side changes, etc.)<br /> <br /> * '''[start_game]''': sent by the host to start a game<br /> * '''[leave_game]''': sent by the client when it leaves a game; sent by the server to make a client leave a game<br /> ** '''reason''': optional reason if sent by the server and was initiated by moderator action<br /> <br /> == In-game communication ==<br /> <br /> Normal scenario communication ([[ReplayWML]]):<br /> * '''[turn]'''<br /> ** '''[command]''': (repeated) can contain all the tags you can find in a [[ReplayWML|replay]]: [recruit], [move], [end_turn], etc.<br /> *** '''[speak]'''<br /> **** '''message''': text of the message<br /> **** '''id''': the sender<br /> **** '''team_name''': the name of the team the message is for - empty if it's a public message<br /> <br /> Multiplayer specific communication:<br /> * '''[request_choice]'''<br /> ** '''request_id''': unique ID of the choice request<br /> ** '''[random_seed]''': client requests a random number (used for attacks for example)<br /> ** '''[change_controller_wml]''': change controller request from scenario WML<br /> *** '''side''': side number<br /> *** '''old_controller''': old [[SideWML#controller|controller]] value<br /> *** '''new_controller''': new [[SideWML#controller|controller]] value<br /> * '''[store_next_scenario]''': sent by the host - the scenario data (see [[ScenarioWML]]) to advance to the next scenario<br /> * '''[notify_next_scenario]''': sent by the server to tell players that the data for the next scenario is available<br /> * '''[load_next_scenario]''': sent by the client to request the data for the next scenario<br /> * '''[next_scenario]''': data for the next scenario (see [[ScenarioWML]]), sent by the server on request<br /> <br /> * '''[info]''': sent by the host on game end - info about the game state<br /> ** '''type''': &quot;termination&quot; <br /> ** '''condition''': the termination reason<br /> <br /> If a player leaves this is sent to the host for all sides he owned.<br /> * '''side_drop''': The number of a side that dropped because a player left.<br /> * '''controller''': The controller of that side. (&quot;ai&quot;, &quot;network&quot;)<br /> <br /> Client commands:<br /> * '''[change_controller]''': a player (un)droids one of his sides or assigns control to someone else (The host can assign control for any side.)<br /> ** '''side''': the side to change controller<br /> ** '''player''': the nickname of the player to take control<br /> ** '''controller''': the new controller: &quot;human&quot; or &quot;human_ai&quot;<br /> ** '''own_side''': &quot;yes&quot;<br /> * '''[muteall]''': the host mutes/unmutes all observers - toggles<br /> * '''[mute]''': the host mutes an observer - toggles<br /> ** '''username''': the username of the observer - if not specified the servers returns a list of muted usernames<br /> * '''[kick]''' or '''[ban]''': the host kicks/bans a player/observer<br /> ** '''username''': the username of the player/observer<br /> <br /> == Game history ==<br /> This is a request to query a set of 11 rows of game history data based on the provided search criteria. The official client calls this from the Match History button in the multiplayer lobby to display 10 rows of data. The 11th row is used as a flag to indicate whether there is more data to be queried or not via the right/left arrows on the dialog.<br /> <br /> * '''[game_history_request]'''<br /> ** '''offset''': where in the result set to start returning data from. If there are 50 results and offset 10 is given, then rows 10-21 will be returned.<br /> ** '''search_player''': the forum username of the player to search for.<br /> ** '''search_game_name''': the name of the game to filter results by. Can use the * (matches any character before or after it's used) and _ (matches any single character) wildcards.<br /> ** '''search_content_type''': the type of content to filter by. Must be one of:<br /> *** '''0''': scenario<br /> *** '''1''': era<br /> *** '''2''':modification<br /> ** '''search_content''': The content to filter by. This is the ID of the content, not the name displayed on the UI, due to the translated name getting stored in the database.<br /> <br /> == Queues ==<br /> Queue info sent to the client on join or when the server's config is reloaded and the queue information has changed:<br /> * '''[queue_update]'''<br /> ** '''queue_id''': The server's unique ID for the queue.<br /> ** '''action''': One of add/update/remove.<br /> ** '''display_name''': The text to show in the list of queues in the lobby.<br /> ** '''players_required''': How many players are required before a game is started.<br /> <br /> == Administrative commands ==<br /> * '''[query]'''<br /> ** '''type''': The type of query. See [[ServerAdministration]] for details.<br /> <br /> == See also ==<br /> [https://github.com/renom/fastbot fastbot] - the bot for tournaments which implements the protocol, can log in into the lobby and host games. Written in Go. <br /> [[Category:WML Reference]]<br /> [[Category:Server Documentation]]</div>

Pentarctagon https://wiki.wesnoth.org/index.php?title=Template:DevDownload&diff=74798 2026-02-05T00:41:55Z

<p>Pentarctagon: </p> <hr /> <div>&lt;noinclude&gt;<br /> == Development (1.19 branch) ==<br /> &lt;/noinclude&gt;<br /> ==== Windows (10 1903 and later) {{{4|}}} ====<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.20 | filename=wesnoth-1.19.20-win64.exe |<br /> hash=c55a71350f5aab18074a5cc781bc66a56a29086624df85f4e155d5a1a4e966f9}}<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.19 | filename=wesnoth-1.19.19-win64.exe |<br /> hash=1d2529daa2c585579176a88655133297b7e2b4ca634f45468bc2f13866604565}}<br /> <br /> ==== macOS (10.13 and later) {{{5|}}} ====<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.20 | filename=Wesnoth_1.19.20.dmg |<br /> hash=9a0df54edbbffb503f527a1b8007b7860eace3cfb9b94207c2ad21047171eb94}}<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.19 | filename=Wesnoth_1.19.19.dmg |<br /> hash=ac733dd52d01026448e7127b48eedfe69ad4b0d0c6089a367592c6d2d1c8d3fc}}<br /> <br /> ==== Source code ====<br /> * [https://github.com/wesnoth/wesnoth/blob/master/INSTALL.md Compiling Wesnoth] - How to compile the source code<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.20 | filename=wesnoth-1.19.20.tar.bz2 |<br /> hash=48f883f8cd3ea008f9170aeaa9fb9ebb486202dd72f455ae131363fc3d164f8f}}<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.19 | filename=wesnoth-1.19.19.tar.bz2 |<br /> hash=d4fba3ecc1a92293f90d623edfef97be7ed6abe963bdcd7134de256fb6977c1d}}</div>

Pentarctagon https://wiki.wesnoth.org/index.php?title=Template:DevDownload&diff=74796 2026-02-01T17:57:57Z

<p>Pentarctagon: </p> <hr /> <div>&lt;noinclude&gt;<br /> == Development (1.19 branch) ==<br /> &lt;/noinclude&gt;<br /> ==== Windows (10 1903 and later) {{{4|}}} ====<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.20 | filename=wesnoth-1.19.20-win64.exe |<br /> hash=c55a71350f5aab18074a5cc781bc66a56a29086624df85f4e155d5a1a4e966f9}}<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.19 | filename=wesnoth-1.19.19-win64.exe |<br /> hash=1d2529daa2c585579176a88655133297b7e2b4ca634f45468bc2f13866604565}}<br /> <br /> ==== macOS (10.13 and later) {{{5|}}} ====<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.19 | filename=Wesnoth_1.19.19.dmg |<br /> hash=ac733dd52d01026448e7127b48eedfe69ad4b0d0c6089a367592c6d2d1c8d3fc}}<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.18 | filename=Wesnoth_1.19.18.dmg |<br /> hash=e3c7490086c6d4200c991e54e541eb830ce2252a453a10ce07dfc0913fd3df23}}<br /> <br /> ==== Source code ====<br /> * [https://github.com/wesnoth/wesnoth/blob/master/INSTALL.md Compiling Wesnoth] - How to compile the source code<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.20 | filename=wesnoth-1.19.20.tar.bz2 |<br /> hash=48f883f8cd3ea008f9170aeaa9fb9ebb486202dd72f455ae131363fc3d164f8f}}<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.19 | filename=wesnoth-1.19.19.tar.bz2 |<br /> hash=d4fba3ecc1a92293f90d623edfef97be7ed6abe963bdcd7134de256fb6977c1d}}</div>

Pentarctagon https://wiki.wesnoth.org/index.php?title=Template:DevDownload&diff=74693 2025-12-31T01:45:23Z

<p>Pentarctagon: </p> <hr /> <div>&lt;noinclude&gt;<br /> == Development (1.19 branch) ==<br /> &lt;/noinclude&gt;<br /> ==== Windows (10 1903 and later) {{{4|}}} ====<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.19 | filename=wesnoth-1.19.19-win64.exe |<br /> hash=1d2529daa2c585579176a88655133297b7e2b4ca634f45468bc2f13866604565}}<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.18 | filename=wesnoth-1.19.18-win64.exe |<br /> hash=3bea895b5ac6520af3c7217283afcc7e17eb96924c3859e559fd04adb35f6fe8}}<br /> <br /> ==== macOS (10.13 and later) {{{5|}}} ====<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.19 | filename=Wesnoth_1.19.19.dmg |<br /> hash=ac733dd52d01026448e7127b48eedfe69ad4b0d0c6089a367592c6d2d1c8d3fc}}<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.18 | filename=Wesnoth_1.19.18.dmg |<br /> hash=e3c7490086c6d4200c991e54e541eb830ce2252a453a10ce07dfc0913fd3df23}}<br /> <br /> ==== Source code ====<br /> * [https://github.com/wesnoth/wesnoth/blob/master/INSTALL.md Compiling Wesnoth] - How to compile the source code<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.19 | filename=wesnoth-1.19.19.tar.bz2 |<br /> hash=d4fba3ecc1a92293f90d623edfef97be7ed6abe963bdcd7134de256fb6977c1d}}<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.18 | filename=wesnoth-1.19.18.tar.bz2 |<br /> hash=22c788998a7555def490ca559844a8721029e25a5529d8584dfbc15f2a579b72}}</div>

Pentarctagon https://wiki.wesnoth.org/index.php?title=Template:StableDownload&diff=74692 2025-12-31T01:19:29Z

<p>Pentarctagon: </p> <hr /> <div>&lt;noinclude&gt;<br /> == Stable (1.18 branch) ==<br /> &lt;/noinclude&gt;<br /> ==== Windows (10 1903 and later, 64-bit only) {{{4|}}} ====<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth-1.18 |<br /> version=1.18.6 | filename=wesnoth-1.18.6-win64.exe |<br /> hash=7365efdc70c127f6d0bfbc6a8f976e6cba1eec59f2bbfb6dc27644534670b162}}<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth-1.18 |<br /> version=1.18.5 | filename=wesnoth-1.18.5-win64.exe |<br /> hash=915d9c0374221782fbfaecd3ac8d8833b470c6ed6c059e6086d5082a28edf80f}}<br /> <br /> ==== macOS (10.12 and later) {{{5|}}} ====<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth-1.18 |<br /> version=1.18.6 | filename=Wesnoth_1.18.6.dmg |<br /> hash=1b9a0ba71c11a386ea0daef357cb508f5c9dc792eed71eff1a3783c056214c93}}<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth-1.18 |<br /> version=1.18.5 | filename=Wesnoth_1.18.5.dmg |<br /> hash=73e34ee58a7c81055bdf94f1b0646a524a992235682ce227fb8d3829af4061f1}}<br /> <br /> ==== Source code ====<br /> * [https://github.com/wesnoth/wesnoth/blob/master/INSTALL.md Compiling Wesnoth] - How to compile the source code<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth-1.18 |<br /> version=1.18.6 | filename=wesnoth-1.18.6.tar.bz2 |<br /> hash=6bb8b17854c974bc66cb7a2574a53fe9efb4d2c138bb1373032e57788204985e}}<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth-1.18 |<br /> version=1.18.5 | filename=wesnoth-1.18.5.tar.bz2 |<br /> hash=e15db3caf446d91d389fc275f10c1a9e7ca3c6176c3b8ce94f5ee4a7a0c81bd6}}</div>

Pentarctagon https://wiki.wesnoth.org/index.php?title=Release_Steps&diff=74680 2025-12-19T18:07:07Z

<p>Pentarctagon: </p> <hr /> <div>== Pre-release (stable only) ==<br /> * Start the string freeze two weeks before the release.<br /> * Do the pot update:<br /> &lt;nowiki&gt;<br /> scons pot-update update-po4a manual<br /> git add -A<br /> git commit -am &quot;pot-update and regenerate doc files&quot;&lt;/nowiki&gt;<br /> * Email the translator's mailing list stating that the string freeze is starting.<br /> <br /> == Release (stable and master branches) ==<br /> * Update [http://www.wesnoth.org/macro-reference.html macro-reference.html]:<br /> <br /> cd data/tools/<br /> make macro-reference.html<br /> * If stable<br /> scp macro-reference.html wesnoth@wesnoth.org:WWW/html/macro-reference.html<br /> * If master<br /> scp macro-reference.html wesnoth@wesnoth.org:WWW/html/macro-reference-1.&lt;version&gt;.html<br /> <br /> * Regenerate the game credits and paste the contents to [[Credits]] on the wiki:<br /> <br /> data/tools/about_cfg_to_wiki -w ./wesnoth &gt; ./about.wiki<br /> <br /> * Check the '''changelog_entries''' folder for entries and update the changelog as necessary.<br /> * Run the pot update (second time if this is a stable release).<br /> * Do the pre-tag commit (check a previous commit as an example - this removes the &quot;+dev&quot; suffix everywhere).<br /> * The the post-tag commit (check a previous commit as an example - this re-adds the &quot;+dev&quot; suffix everywhere).<br /> * Tag the pre-tag commit with:<br /> &lt;nowiki&gt;git tag -a &lt;version&gt; -m &quot;Wesnoth &lt;version&gt; (Alpha)&quot; &lt;commit hash&gt;&lt;/nowiki&gt;<br /> ::- (Alpha)/(Beta) is only added for dev releases depending on where we are in the release cycle.<br /> * Push the commits and the tag:<br /> &lt;nowiki&gt;git push<br /> git push origin &lt;version&gt;&lt;/nowiki&gt;<br /> * Ping the packagers on Discord that the release has been tagged:<br /> &lt;nowiki&gt;@packagers &lt;version&gt; has been tagged.&lt;/nowiki&gt;<br /> * Check that the new version is allowed on its respective multiplayer server.<br /> * Update the header in Discord's #development channel.<br /> * Upload master.zip and the patch to SourceForge to the respective version's folder for use by Android<br /> ** master.zip contains the folders<br /> *** data (data/core/music/ is removed)<br /> *** fonts<br /> *** images<br /> *** sounds<br /> *** translations<br /> ** For the patch, go to packaging/android/ and run <br /> <br /> &lt;nowiki&gt;./create_patch.sh oldtag newtag&lt;/nowiki&gt;<br /> <br /> Then upload the resulting patch.zip and manifest.txt next to master.zip.<br /> * Upload source code tarball to SourceForge and files.wesnoth.org (done by loonycyborg).<br /> * Send an email to the packagers mailing list (done by loonycyborg).<br /> * Upload the release to the various places Wesnoth is distributed (Steam, itch.io, SourceForge, macOS App Store, Flathub, F-Droid).<br /> ** Windows/Linux - handled by loonycyborg.<br /> ** macOS - handled by hrubymar.<br /> ** Android (F-Droid) - handled by LumiousE<br /> * Post the forum announcements.<br /> * Update the Downloads wiki page.<br /> ** url: https://wiki.wesnoth.org/Download<br /> ** dev template: https://wiki.wesnoth.org/Template:DevDownload#Development_.281.15_branch.29<br /> ** stable template: https://wiki.wesnoth.org/Template:StableDownload<br /> * Add the News forum post.<br /> * Post the Discord announcement.<br /> ** Make sure to publish it.<br /> ** Short link is: '''&lt;nowiki&gt;https://r.wesnoth.org/t#####&lt;/nowiki&gt;'''<br /> * Post the itch.io devlog (copy of the Discord announcement).<br /> * Update the wesnoth.org front page.<br /> ** See a previous version update commit to the '''wesmere''' repository.<br /> ** ssh into the website VM and execute the following shell commands (yes, it is specifically ''''make'''', not ''''make install''''!):<br /> &lt;nowiki&gt;sudo -iu wesnoth<br /> cd ~/git/wesmere/static<br /> git pull<br /> make&lt;/nowiki&gt;<br /> * Generate the Steam announcement by running the following command in your local wesnoth repository root:<br /> &lt;nowiki&gt;python3 data/tools/steam-changelog changelog.md &lt;version&gt; &gt; &lt;version&gt;.txt&lt;/nowiki&gt;<br /> * Post the Steam announcement.<br /> * Log into Wesnoth's Steam page.<br /> ** Click &quot;A Game Update&quot;.<br /> ** Pick &quot;Small Update&quot;.<br /> ** Paste the output of of the above python command into the event description.<br /> ** Click &quot;Link To Build&quot; and select the appropriate branch.<br /> ** Edit the appropriate .xcf file from the [https://github.com/wesnoth/resources/tree/master/social-media-assets Resources repository] ('''wesnoth_event_header.xcf''' for stable releases, '''wesnoth_beta_header.xcf''' for development releases) and export it to PNG.<br /> *** This requires the '''oldania''' font to be installed, which on Linux/Ubuntu-derivatives can be installed via the command:<br /> &lt;nowiki&gt;apt install fonts-adf-oldania&lt;/nowiki&gt;<br /> * Post the announcement to Fosstodon.<br /> * Post the announcement to Reddit. (Elvish_Hunter)<br /> ** Add the &quot;Development release&quot;/&quot;Stable release&quot; flair.<br /> ** Don't paste the link in the post, directly post it as a link.<br /> <br /> == New Stable Series ==<br /> === Beta 1 ===<br /> Write up the new Start page (ie: https://www.wesnoth.org/start/1.16/).<br /> <br /> === Beta 2 ===<br /> Make the new Start page available to Translators.<br /> <br /> === RC1 ===<br /> Before release, the new multiplayer server and add-ons server instances need to be setup. The server running the website status is owned by Iris - she needs to push updates to it.<br /> * Multiplayer server<br /> ** Needs no changes since it goes to port 15000 and then that redirects based on version. The existing dev multiplayer server will be reused as the new stable instance.<br /> ** The Discord website status bot and the site status page (https://status.wesnoth.org/ - bin/valen.pl) need to be updated to rename the dev version to the stable version.<br /> ** A new stable multiplayer instance needs to be added to the alternate server.<br /> <br /> * Add-ons server - The port is the version number, for example 1.16 is 15016, 1.18 is 15018, etc.<br /> ** C++ update (currently default_campaignd_port in addon/validation.cpp)<br /> ** Python update (data/tools/wesnoth/campaignserver_client.py)<br /> ** Website update (bin/valen.pl) in the valen repository to add the new instance.<br /> ** The Discord website status bot and the site status page (https://status.wesnoth.org/ - bin/valen.pl) need to be updated to add the new version.<br /> ** Add a 1.18 cron job for ~wesnoth/bin/update_addons in the websites VM and remove the 1.17 cron job.<br /> <br /> * Flatpak<br /> ** <br /> <br /> * Add screenshots to https://wiki.wesnoth.org/Screenshots<br /> <br /> * Start page - soft link the folder from the repository to the folder that shows up on the actual website:<br /> &lt;nowiki&gt;<br /> cd /srv/www/html/start<br /> ln -s /home/git/wesnoth/start/&lt;version&gt;&lt;/nowiki&gt;<br /> <br /> * Update ci_main.yml to use the new branch instead of the master branch.<br /> <br /> [[Category:Release_Notes]]</div>

Pentarctagon https://wiki.wesnoth.org/index.php?title=Release_Steps&diff=74679 2025-12-19T18:05:48Z

<p>Pentarctagon: </p> <hr /> <div>== Pre-release (stable only) ==<br /> * Start the string freeze two weeks before the release.<br /> * Do the pot update:<br /> &lt;nowiki&gt;<br /> scons pot-update update-po4a manual<br /> git add -A<br /> git commit -am &quot;pot-update and regenerate doc files&quot;&lt;/nowiki&gt;<br /> * Email the translator's mailing list stating that the string freeze is starting.<br /> <br /> == Release (stable and master branches) ==<br /> * Update [http://www.wesnoth.org/macro-reference.html macro-reference.html]:<br /> <br /> cd data/tools/<br /> make macro-reference.html<br /> * If stable<br /> scp macro-reference.html wesnoth@wesnoth.org:WWW/html/macro-reference.html<br /> * If master<br /> scp macro-reference.html wesnoth@wesnoth.org:WWW/html/macro-reference-1.&lt;version&gt;.html<br /> <br /> * Regenerate the game credits and paste the contents to [[Credits]] on the wiki:<br /> <br /> data/tools/about_cfg_to_wiki -w ./wesnoth &gt; ./about.wiki<br /> <br /> * Check the '''changelog_entries''' folder for entries and update the changelog as necessary.<br /> * Run the pot update (second time if this is a stable release).<br /> * Do the pre-tag commit (check a previous commit as an example - this removes the &quot;+dev&quot; suffix everywhere).<br /> * The the post-tag commit (check a previous commit as an example - this re-adds the &quot;+dev&quot; suffix everywhere).<br /> * Tag the pre-tag commit with:<br /> &lt;nowiki&gt;git tag -a &lt;version&gt; -m &quot;Wesnoth &lt;version&gt; (Alpha)&quot; &lt;commit hash&gt;&lt;/nowiki&gt;<br /> ::- (Alpha)/(Beta) is only added for dev releases depending on where we are in the release cycle.<br /> * Push the commits and the tag:<br /> &lt;nowiki&gt;git push<br /> git push origin &lt;version&gt;&lt;/nowiki&gt;<br /> * Ping the packagers on Discord that the release has been tagged:<br /> &lt;nowiki&gt;@packagers &lt;version&gt; has been tagged.&lt;/nowiki&gt;<br /> * Check that the new version is allowed on its respective multiplayer server.<br /> * Update the header in Discord's #development channel.<br /> * Upload master.zip and the patch to SourceForge to the respective version's folder for use by Android<br /> ** master.zip contains the folders<br /> *** data (data/core/music/ is removed)<br /> *** fonts<br /> *** images<br /> *** sounds<br /> *** translations<br /> ** For the patch, go to packaging/android/ and run &lt;nowiki&gt;./create_patch.sh oldtag newtag&lt;/nowiki&gt;. Then upload the resulting patch.zip and manifest.txt next to master.zip.<br /> * Upload source code tarball to SourceForge and files.wesnoth.org (done by loonycyborg).<br /> * Send an email to the packagers mailing list (done by loonycyborg).<br /> * Upload the release to the various places Wesnoth is distributed (Steam, itch.io, SourceForge, macOS App Store, Flathub, F-Droid).<br /> ** Windows/Linux - handled by loonycyborg.<br /> ** macOS - handled by hrubymar.<br /> ** Android (F-Droid) - handled by LumiousE<br /> * Post the forum announcements.<br /> * Update the Downloads wiki page.<br /> ** url: https://wiki.wesnoth.org/Download<br /> ** dev template: https://wiki.wesnoth.org/Template:DevDownload#Development_.281.15_branch.29<br /> ** stable template: https://wiki.wesnoth.org/Template:StableDownload<br /> * Add the News forum post.<br /> * Post the Discord announcement.<br /> ** Make sure to publish it.<br /> ** Short link is: '''&lt;nowiki&gt;https://r.wesnoth.org/t#####&lt;/nowiki&gt;'''<br /> * Post the itch.io devlog (copy of the Discord announcement).<br /> * Update the wesnoth.org front page.<br /> ** See a previous version update commit to the '''wesmere''' repository.<br /> ** ssh into the website VM and execute the following shell commands (yes, it is specifically ''''make'''', not ''''make install''''!):<br /> &lt;nowiki&gt;sudo -iu wesnoth<br /> cd ~/git/wesmere/static<br /> git pull<br /> make&lt;/nowiki&gt;<br /> * Generate the Steam announcement by running the following command in your local wesnoth repository root:<br /> &lt;nowiki&gt;python3 data/tools/steam-changelog changelog.md &lt;version&gt; &gt; &lt;version&gt;.txt&lt;/nowiki&gt;<br /> * Post the Steam announcement.<br /> * Log into Wesnoth's Steam page.<br /> ** Click &quot;A Game Update&quot;.<br /> ** Pick &quot;Small Update&quot;.<br /> ** Paste the output of of the above python command into the event description.<br /> ** Click &quot;Link To Build&quot; and select the appropriate branch.<br /> ** Edit the appropriate .xcf file from the [https://github.com/wesnoth/resources/tree/master/social-media-assets Resources repository] ('''wesnoth_event_header.xcf''' for stable releases, '''wesnoth_beta_header.xcf''' for development releases) and export it to PNG.<br /> *** This requires the '''oldania''' font to be installed, which on Linux/Ubuntu-derivatives can be installed via the command:<br /> &lt;nowiki&gt;apt install fonts-adf-oldania&lt;/nowiki&gt;<br /> * Post the announcement to Fosstodon.<br /> * Post the announcement to Reddit. (Elvish_Hunter)<br /> ** Add the &quot;Development release&quot;/&quot;Stable release&quot; flair.<br /> ** Don't paste the link in the post, directly post it as a link.<br /> <br /> == New Stable Series ==<br /> === Beta 1 ===<br /> Write up the new Start page (ie: https://www.wesnoth.org/start/1.16/).<br /> <br /> === Beta 2 ===<br /> Make the new Start page available to Translators.<br /> <br /> === RC1 ===<br /> Before release, the new multiplayer server and add-ons server instances need to be setup. The server running the website status is owned by Iris - she needs to push updates to it.<br /> * Multiplayer server<br /> ** Needs no changes since it goes to port 15000 and then that redirects based on version. The existing dev multiplayer server will be reused as the new stable instance.<br /> ** The Discord website status bot and the site status page (https://status.wesnoth.org/ - bin/valen.pl) need to be updated to rename the dev version to the stable version.<br /> ** A new stable multiplayer instance needs to be added to the alternate server.<br /> <br /> * Add-ons server - The port is the version number, for example 1.16 is 15016, 1.18 is 15018, etc.<br /> ** C++ update (currently default_campaignd_port in addon/validation.cpp)<br /> ** Python update (data/tools/wesnoth/campaignserver_client.py)<br /> ** Website update (bin/valen.pl) in the valen repository to add the new instance.<br /> ** The Discord website status bot and the site status page (https://status.wesnoth.org/ - bin/valen.pl) need to be updated to add the new version.<br /> ** Add a 1.18 cron job for ~wesnoth/bin/update_addons in the websites VM and remove the 1.17 cron job.<br /> <br /> * Flatpak<br /> ** <br /> <br /> * Add screenshots to https://wiki.wesnoth.org/Screenshots<br /> <br /> * Start page - soft link the folder from the repository to the folder that shows up on the actual website:<br /> &lt;nowiki&gt;<br /> cd /srv/www/html/start<br /> ln -s /home/git/wesnoth/start/&lt;version&gt;&lt;/nowiki&gt;<br /> <br /> * Update ci_main.yml to use the new branch instead of the master branch.<br /> <br /> [[Category:Release_Notes]]</div>

Pentarctagon https://wiki.wesnoth.org/index.php?title=Template:DevDownload&diff=74633 2025-11-19T04:56:37Z

<p>Pentarctagon: </p> <hr /> <div>&lt;noinclude&gt;<br /> == Development (1.19 branch) ==<br /> &lt;/noinclude&gt;<br /> ==== Windows (10 1903 and later) {{{4|}}} ====<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.18 | filename=wesnoth-1.19.18-win64.exe |<br /> hash=3bea895b5ac6520af3c7217283afcc7e17eb96924c3859e559fd04adb35f6fe8}}<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.17 | filename=wesnoth-1.19.17-win64.exe |<br /> hash=3043cf6db1dcd17c341ee8af7d625a9d561cc06fbf091297a0aa6d3f413b21bb}}<br /> <br /> ==== macOS (10.13 and later) {{{5|}}} ====<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.18 | filename=Wesnoth_1.19.18.dmg |<br /> hash=e3c7490086c6d4200c991e54e541eb830ce2252a453a10ce07dfc0913fd3df23}}<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.17 | filename=Wesnoth_1.19.17.dmg |<br /> hash=0216cd5837af30de1b072d325d11477fa8a1409b22e9fc3ebf46fcc78b8f10b2}}<br /> <br /> ==== Source code ====<br /> * [https://github.com/wesnoth/wesnoth/blob/master/INSTALL.md Compiling Wesnoth] - How to compile the source code<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.18 | filename=wesnoth-1.19.18.tar.bz2 |<br /> hash=22c788998a7555def490ca559844a8721029e25a5529d8584dfbc15f2a579b72}}<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.17 | filename=wesnoth-1.19.17.tar.bz2 |<br /> hash=7a4f65b3bd845fc923a8f745591062061f5f72cedd4f81edb93e42b8e6b162ea}}</div>

Pentarctagon https://wiki.wesnoth.org/index.php?title=Credits&diff=74632 2025-11-18T02:08:09Z

<p>Pentarctagon: </p> <hr /> <div>&lt;div class=&quot;tright&quot;&gt; __TOC__ &lt;/div&gt;<br /> __NOEDITSECTION__<br /> In July 2003, '''David White''' released the first version of Wesnoth. Since<br /> then, many people have joined the project, contributing in very different ways.<br /> <br /> To make any changes to this list, please modify<br /> &lt;code class=&quot;noframe&quot;&gt;about.cfg&lt;/code&gt; in the repo or ask any developer to do<br /> it for you.<br /> <br /> == Core Contributors ==<br /> === Programming ===<br /> * [mailto:dave&amp;#x40;whitevine&amp;#x2E;net David White] (Sirp) &amp;#8212; Founding Developer<br /> &lt;hr style='clear:none'&gt;<br /> * [mailto:AI0867&amp;#x40;gmail&amp;#x2E;com Alexander van Gessel] (AI/AI0867)<br /> * Alfredo Beaumont (ziberpunk) &amp;#8212; autotools<br /> * Ali El Gariani ([[User:Alink|alink]]) &amp;#8212; coder, bug fixes, optimizations, interface usability<br /> * András Salamon ([[User:Ott|ott]]) &amp;#8212; QA, bug fixing, subediting, game mechanics<br /> * Andreas Löf (Aginor)<br /> * Anonymissimus &amp;#8212; bug fixes and features mostly related to the wml engine or lua interface<br /> * [mailto:artemkhrapov2001ATyandexDOTru Artem Khrapov] ([[User:Kabachuha|kabachuha]]) &amp;#8212; addons server rework, incremental updates and uploads feature; i18n, UI and quality of life improvements; bugfixes<br /> * [mailto:dragonking&amp;#x40;o2&amp;#x2E;pl Bartek Waresiak] (Dragonking) &amp;#8212; unit balancing, Formula AI<br /> * Benoît Timbert ([[User:Noyga|Noyga]])<br /> * Bram Ridder (Morloth) &amp;#8212; editor improvements<br /> * [mailto:bruno&amp;#x40;wolff&amp;#x2E;to Bruno Wolff III] ([[User:bruno|bruno]]) &amp;#8212; campaign web interface, bug fixing, minor coder<br /> * Cameron Morland<br /> * Cédric Duval &amp;#8212; coder, internationalization manager<br /> * Charles Dang (vultraz) &amp;#8212; General fixes, cleanup and improvements to various areas.<br /> * Chris Beck (iceiceice/involution) &amp;#8212; Bug fixes and features esp. engine-related or multiplayer-related. Added WML unit testing system, improvements to travis-CI.<br /> * Celtic Minstrel<br /> * Daniel Franke (dfranke)<br /> * Daniel (gfgtdf)<br /> * David Hilton<br /> * Descacharrado<br /> * Dominic Bolin (Xan)<br /> * Elias Pschernig (allefant)<br /> * Elvish_Hunter<br /> * Eric S. Raymond (ESR) &amp;#8212; Macro library reorganization, major UI makeover introducing lightweight transparent popups and linger mode, maintenance tools for WML, eight campaigns lifted from UMC, one all-original campaign, editor refactoring, many many code cleanups, and svn-to-git migration.<br /> * Eugen Jiresch (euschn) &amp;#8212; savegame improvements<br /> * [mailto:fabianmueller5_at_gmx&amp;#x2E;de Fabian Müller] ([[User:fabi|fabi/fendrin]])<br /> * [mailto:gabrielmorin~_-AT-_~gmail&amp;#x2E;com Gabriel Morin] (gabba) &amp;#8212; Whiteboard project, naming hotseat players, delay shroud updates on game start.<br /> * Greg Copeland (Oracle) &amp;#8212; coding; Server optimizations.<br /> * Gregory Lundberg (TadCarlucci) &amp;#8212; Cleanup of campaigns code<br /> * [mailto:cornmander&amp;#x40;cornmander&amp;#x2E;com Gregory Shikhman] (corn) &amp;#8212; coding; upload log maintenance/improvements<br /> * Guillaume Melquiond (silene) &amp;#8212; coding, bug fixes<br /> * [mailto:billybiset&amp;#x40;gmail&amp;#x2E;com Guillermo Biset] (billynux) &amp;#8212; Bug fixer, remover of upload stats, network module rewrite, ANA, boost::asio<br /> * [mailto:shadowm2006&amp;#x40;gmail&amp;#x2E;com Iris Morelle] ([[User:Shadowm|Irydacea/shadowm]]) &amp;#8212; Miscellaneous WML, i18n and UI features, improvements and bugfixes; refactoring and extension of add-ons management code; features and refactoring of image-path functions mechanism; cache manager UI and paths/game version dialog; campaignd refactoring and maintenance<br /> * Jérémy Rosen ([[User:Boucman|Boucman]]) &amp;#8212; coder<br /> * [mailto:mcnabb&amp;#x40;gravity&amp;#x2E;psu&amp;#x2E;edu John W. C. McNabb] (Darth Fool) &amp;#8212; coder, graphics<br /> * Jon Daniel (worduk) &amp;#8212; coder, bug fixes<br /> * Jörg Hinrichs (Yogi Bear/YogiHH)<br /> * [mailto:justin&amp;#x2E;zaun&amp;#x40;gmail&amp;#x2E;com Justin Zaun] (jzaun) &amp;#8212; coder, scenario designer<br /> * Jyrki Vesterinen<br /> * Karol Nowak (grzywacz) &amp;#8212; bug fixes, sound sources, gp2x port<br /> * [mailto:erl&amp;#x40;erl&amp;#x2E;se Kristoffer Erlandsson] (erl) &amp;#8212; help system, editor<br /> * [mailto:lao&amp;#x2E;geek&amp;#x40;gmail&amp;#x2E;com Lao] ([[User:lao|lao]]) &amp;#8212; bug fixes and candidate to GSoC 2008<br /> * macabeus &amp;#8212; wesnoth-map-diff author<br /> * Mark de Wever ([[User:SkeletonCrew|Mordante/SkeletonCrew]]) &amp;#8212; coder, bug fixes, various features, multi-letter terrain system, gui system.<br /> * Martin Renold (maxy/martinxyz) &amp;#8212; performance and gui bug fixes<br /> * Matthias Kretz &amp;#8212; optimizations<br /> * Moritz Göbelbecker (mog) &amp;#8212; Work on the terrain engine<br /> * Nicolas Weeger (Ryo) &amp;#8212; Python API<br /> * [mailto:patrick_x99&amp;#x40;hotmail&amp;#x2E;com Patrick Parker] ([[User:Sapient|Sapient]]) &amp;#8212; improvements to user interface, WML engine, various features<br /> * [mailto:paniemin&amp;#x40;cc&amp;#x2E;hut&amp;#x2E;fi Pauli Nieminen] (suokko) &amp;#8212; Bug fixing; usually targeting MP or WML engine<br /> * [mailto:philippe&amp;#x2E;plantier&amp;#x40;naema&amp;#x2E;org Philippe Plantier] ([[User:Ayin|Ayin]]) &amp;#8212; several parts of the code, notably terrain graphics code<br /> * Rusty Russell (rusty)<br /> * Sergey Popov (loonycyborg) &amp;#8212; scons<br /> * singalen &amp;#8212; iOS port<br /> * slayer95<br /> * Soliton &amp;#8212; bug fixes and various small features usually in multiplayer context<br /> * Steve Cotton (octalot)<br /> * Steven Oxley (xonev)<br /> * [mailto:suvrax&amp;#x40;gmail&amp;#x2E;com Subhraman Sarkar] (LumiousE/babaissarkar) &amp;#8212; UI features, with bugfixes in various areas. Co-creator of Celes theme. WIP Android port (1.19).<br /> * Thomas Baumhauer (Baufo)<br /> * [mailto:timotei21&amp;#x40;gmail&amp;#x2E;com Timotei Dolean] (timotei) &amp;#8212; Eclipse UMC plugin<br /> * Tomasz Śniatowski (ilor) &amp;#8212; Editor<br /> * [mailto:ydirson&amp;#x40;altern&amp;#x2E;org Yann Dirson] &amp;#8212; gettext support, tinygui<br /> * [mailto:terraninfo&amp;#x40;terraninfo&amp;#x2E;net Yurii Chernyi] (Crab) &amp;#8212; AI<br /> === General Purpose Administration and Coordination ===<br /> * Pentarctagon &amp;#8212; Current release manager (1.15.4-present)<br /> &lt;hr style='clear:none'&gt;<br /> * Charles Dang (vultraz) &amp;#8212; Past release manager (1.13.3-1.15.3)<br /> * Crossbow/Miyo &amp;#8212; Past release manager<br /> * [mailto:shadowm2006&amp;#x40;gmail&amp;#x2E;com Iris Morelle] ([[User:Shadowm|Irydacea/shadowm]]) &amp;#8212; Past release manager (1.12.1-1.12.6 / 1.13.0-1.13.2)<br /> * [mailto:isaac&amp;#x40;sindominio&amp;#x2E;net Isaac Clerencia] &amp;#8212; Past release manager, Debian packager<br /> * [mailto:Crazy-Ivanovic&amp;#x40;gmx&amp;#x2E;net Nils Kneuper] (Ivanovic) &amp;#8212; Past release manager, internationalization manager, OpenPandora packager, A Tale of Two Brothers, German translation<br /> * Noy &amp;#8212; General purpose administration, unit balancing<br /> === Internationalization Managers ===<br /> * Cédric Duval &amp;#8212; coder, internationalization manager<br /> * David Philippi (Torangan) &amp;#8212; internationalization manager, wescamp<br /> * Mark Michelsen (skovbaer) &amp;#8212; Slackware packager<br /> * [mailto:Crazy-Ivanovic&amp;#x40;gmx&amp;#x2E;net Nils Kneuper] (Ivanovic) &amp;#8212; administrator, release manager, internationalization manager, OpenPandora packager, A Tale of Two Brothers, german translation<br /> * [mailto:susanna&amp;#x2E;bjorverud&amp;#x40;telia&amp;#x2E;com Susanna Björverud] (sanna)<br /> === Trailers ===<br /> * ancestral &amp;#8212; 1.12 trailer<br /> * Pedro Caseiro (Kasdel) &amp;#8212; 1.14 trailer<br /> * Felix Merveille (felixmerveille) &amp;#8212; 1.16 trailer edits and additions<br /> === Artwork and Graphics ===<br /> * Emilien Rotival (LordBob) &amp;#8212; portrait director - focus on loyalists, trolls, monsters<br /> * Francisco Muñoz (fmunoz) &amp;#8212; founding artist and former lead artist, worked consistently on all aspects till around v0.7-0.9.<br /> * Hogne Håskjold (frame/freim) &amp;#8212; terrain art director, made much of the current terrains (esp. mountains)<br /> * J.W. Bjerk ([[User:Eleazar|Eleazar]]) &amp;#8212; terrain art director (esp. Chasm, Cave, Water), sprite animations, various visual tweaks<br /> * James Woo (Pickslide) &amp;#8212; portraits (major focus on orcs and campaigns, especially UtBS, TEI, TSoF)<br /> * Kathrin Polikeit (Kitty) &amp;#8212; portrait director - focus on mages/necromancers, elvish, naga, merfolk, and troll unit trees<br /> * Lari Nieminen (zookeeper) &amp;#8212; sprite animation, various visual tweaks, titlescreen and campaign maps (v1.11+), water animations (v1.13+)<br /> * Neoriceisgood &amp;#8212; sprite creator and animator (major focus on drakes, dwarves, saurians)<br /> * Pekka Aikio (pekka) &amp;#8212; tiles, esp. castles, and attack icons<br /> * Phil Barber (thespaceinvader) &amp;#8212; Dwarf and Saurian portraits, most of the drake animations, and a large amount on other stuff, esp. the dwarves.<br /> * Richard Kettering ([[User:Jetryl|Jetrel]]) &amp;#8212; art director/slave, major focus on sprites, portraits, buildings, and icons<br /> * Timo Honkasalo (Sgt. Groovy) &amp;#8212; New high-res logo for the game<br /> &lt;hr style='clear:none'&gt;<br /> * Alex Jarocha-Ernst (Jormungandr) &amp;#8212; portraits<br /> * Christophe Anjard (Christophe33) &amp;#8212; made many of the old (c. v0.6) terrains, and some sprites for the dwarves<br /> * Erkki Lonkainen (Eternal) &amp;#8212; created and animated many replacement sprites (esp. ogre, orc assassin &amp; spear units, and cockatrice)<br /> * Jason Lutes &amp;#8212; portraits (major focus on humans, some campaign portraits)<br /> * Johann de Venecia (Johann) &amp;#8212; drew the new campaign story art for HttT<br /> * Leonhard &amp;#8212; made several of the new attack icons<br /> * Marcus Rosén (sleepwalker) &amp;#8212; Animations (esp. Saurians, Dwarves, Horseman), dunefolk sprites, and portraits (Mermaid Initiate &amp; Dune Herbalist)<br /> * Mark Goodenough (Ranger M) &amp;#8212; sprite animator<br /> * Maximiliano Buis (Redeth) &amp;#8212; Made nearly all of the idle animations, and some death animations (as of 1.3.1)<br /> * Michael Gil de Muro (grp21) &amp;#8212; portraits (for the campaign ‘The Rise of Wesnoth’)<br /> * MJ (czyzby) &amp;#8212; adjustments of the saurian sprites; animations for saurian spearthrower, javelineer, seer, and prophet<br /> * Moritz Göbelbecker (mog) &amp;#8212; tiles, esp. swamp, encampment, ice, and work with lava/chasm<br /> * Niall Burton (Leonard03) &amp;#8212; Minimalistic logo render<br /> * Peter Geinitz (Shadow/Wayfarer) &amp;#8212; sprite creator and animator<br /> * Robert Bolin (Zebulon) &amp;#8212; tiles, sprite editing and animations<br /> &lt;hr style='clear:none'&gt;<br /> * Andrew James Patterson (Kamahawk) &amp;#8212; sprites<br /> * antwerpz &amp;#8212; sprite creator/animator for old saurian units<br /> * Diego Brea (Cobretti) &amp;#8212; sprite creator/animator<br /> * EEL (EELuminatus) &amp;#8212; sprite animator, provided death animations for the woses, some of the orcs, and an attack animation for the revenant<br /> * Eli Dupree (Elvish Pillager) &amp;#8212; sprites and animations<br /> * Eric Holdos (Rev. V!)<br /> * Gareth Miller (Gafgarion) &amp;#8212; made some early sprites/tiles<br /> * Gerald Clears (Smok'em Jags) &amp;#8212; sprite animator<br /> * James Barton (Sangel) &amp;#8212; sprites<br /> * Jami &amp;#8212; rogue death and red mage idle animations<br /> * Jerzy Brzozowski (Mefisto) &amp;#8212; Various sprites and animations, tropical forests.<br /> * Jesse Holland (Kestenvarn) &amp;#8212; map illustrator of old titlescreen and campaign maps (v1.1 - v1.10)<br /> * Johanna Manninen (lohari) &amp;#8212; edited tiles, ported freeciv tiles used in very early versions of wesnoth<br /> * John Muccigrosso (Eponymous Archon) &amp;#8212; made some early sprites, such as the human bowmen<br /> * Kuno Raffin (lurker) &amp;#8212; Various terrain artwork<br /> * Michael Mielewczik (Mille) &amp;#8212; sprite animator<br /> * Mikko Kraft (Deserter) &amp;#8212; sprite animator<br /> * Musketaquid &amp;#8212; animated windmill / stone path<br /> * Slainte &amp;#8212; made sprites for c. v0.6 mages, also made many of the old attack icons<br /> * Simon Forsyth (Alarantalara) &amp;#8212; cave terrain<br /> * Stephen Metcalf (Neoskel) &amp;#8212; major help with shadow standardization (over half the units), made some missing zombie variants<br /> * Stephen Stone (Disto) &amp;#8212; sprite animator<br /> * Svetac &amp;#8212; made many of the old attack icons<br /> * Tristan Millner (tatmf) &amp;#8212; made old portrait of dwarven fighter<br /> * Zhukov &amp;#8212; sprite animator<br /> &lt;hr style='clear:none'&gt;<br /> * Aaron Redfern (A-Red) &amp;#8212; Sprites and animations<br /> * Adrian Sheehy (Major) &amp;#8212; various sprites animations<br /> * Alexander Brown (Cloud) &amp;#8212; Sprite animations<br /> * Anton Ecker (Kaldred) &amp;#8212; burnt villages<br /> * battlestar &amp;#8212; - some scenery graphics including burnt tent.<br /> * Ben Wenzel (artisticdude) &amp;#8212; Sprite animations<br /> * Blarumyrran &amp;#8212; New storm trident, staff and ankh item pictures, various attack icons, river ford tiles, drake and human city villages<br /> * Bora Orcal (bera) &amp;#8212; Goblin portrait sketches<br /> * Cernunnos &amp;#8212; merfolk villages<br /> * Charles Dang (vultraz) &amp;#8212; Icons for new editor and updated terrain icons<br /> * Chris Wilson (Valkier) &amp;#8212; portraits<br /> * Christian Sirviö (Girgistian) &amp;#8212; portraits (sketches), and some attack animations for the orcs<br /> * Clinton Bell &amp;#8212; various animations<br /> * Dan Gerhards (beetlenaut) &amp;#8212; various sprites and animations<br /> * Daniel Borgmann (dborg) &amp;#8212; semi-transparent map grid<br /> * Daniel Foerster (pydsigner/pyndragon) &amp;#8212; Icon overlays for the About dialog button<br /> * Kwandulin &amp;#8212; Standing animations (Skeleton Archer, Bone Shooter, Orcish Archer, Dwarvish Fighter, Ulfserker, Stalwart, Runesmith), minor fixes<br /> * doofus-01 &amp;#8212; orcish fort and villages, desert mountains, mine walls, sea forts, portraits for walking corpse and soulless<br /> * Elena Astanina (ayona) &amp;#8212; log-cabin villages<br /> * Eric Butler (Erk) &amp;#8212; desert and merfolk villages<br /> * Evan Crook (Flametrooper) &amp;#8212; sprite animator (TC conversion)<br /> * Garrett Wessner (Stilgar) &amp;#8212; gold coin pile<br /> * Gideon Chia (Deonjo) &amp;#8212; new ‘units’ icon for general status bar<br /> * Guangcong Luo (Zarel) &amp;#8212; Multiplayer status icons for 1.7.x<br /> * Highhole &amp;#8212; revised storm trident<br /> * Homunculus &amp;#8212; dead great tree terrain<br /> * [mailto:shadowm2006&amp;#x40;gmail&amp;#x2E;com Iris Morelle] ([[User:Shadowm|Irydacea/shadowm]]) &amp;#8212; Minor item/unit edits; animated lit brazier; ported gryphon rider animation to generic gryphon; Ancient Lich for 1.12.x<br /> * Irrevenant &amp;#8212; Skeleton archer death and recruit animations, new ankh touch ups, new dark adept touch ups, elvish marshal standing animation<br /> * Irwin Ismail (Swordy) &amp;#8212; original projectile/attack icon for chakram<br /> * Jason Frailey (Valdroni) &amp;#8212; scorpion portrait<br /> * Jimmy Olsson (Azlan) &amp;#8212; made old icons for windows version<br /> * Joakim Persson (JAP) &amp;#8212; Knalgan flag set<br /> * John Mercer (Stern) &amp;#8212; Giant Rat graphics<br /> * John-Robert Funck (XJaPaN) &amp;#8212; sprite animator<br /> * Jonatan Alamà (tin) &amp;#8212; made red logo used until before v1.0<br /> * Justin Nichols (JustinOperable) &amp;#8212; Portrait artwork<br /> * Kim Holm (DUHH) &amp;#8212; Portrait artwork<br /> * Lukasz Wawrowski (inferno8) &amp;#8212; Drake attack icons with fmunoz and map backgrounds for Isar’s Cross<br /> * Lordlewis &amp;#8212; mace item sprite<br /> * Luke Bunday (Amorphous) &amp;#8212; New (1.17) swordsman attack animation<br /> * Mattias Westlund (West) &amp;#8212; new color cursors<br /> * Nicholas Kerpan (Thrawn) &amp;#8212; human thief portrait<br /> * Pixelmind &amp;#8212; various animations<br /> * Randall Walls (slightcrazed) &amp;#8212; sprite animator<br /> * rhyging5 &amp;#8212; various animations<br /> * RusHHouR &amp;#8212; New signpost (1.4.1)<br /> * Samuel Wilson (megane) &amp;#8212; random dice icon fix after 1.4.0<br /> * Santiago Iborra (Quellion) &amp;#8212; Portrait artwork<br /> * Simeon Dear (Trilby) &amp;#8212; Sprite animations<br /> * Zoomo &amp;#8212; Sprite animations<br /> * Zaggy1024 &amp;#8212; Wolf rider death animation<br /> * Eisfrei &amp;#8212; Elvish shaman idle animations<br /> * Happy Wose &amp;#8212; Wose idle frames and Elder wose death animation<br /> * Wolfy &amp;#8212; Female arch mage idle animation<br /> * mystic x the unknown &amp;#8212; Mage death animation<br /> * Sonny T Yamada (SkyOne) &amp;#8212; shadow standardization of many campaign units<br /> * Vincent Langner (Vyncyn) &amp;#8212; Walking Corpse and Soulless wolf variations, young roc base and attack sprite<br /> * ZygoUgo &amp;#8212; Giant Rat portrait<br /> * ghype &amp;#8212; sprite animation and dunefolk base frames<br /> * Tony Moseley (Helmet) &amp;#8212; initial dragonfly sprites<br /> === Music ===<br /> * Aleksi Aubry-Carlson (Aleksi)<br /> * Doug Kaufman (dkaufman) &amp;#8212; http://dougkaufman.net/<br /> * Gianmarco Leone (gmlion)<br /> * Jeremy Nicoll (jeremy2/eltiare)<br /> * Joseph Toscano (ZhayTee) &amp;#8212; zhaymusic.com<br /> * Mattias Westlund (West) &amp;#8212; music coordinator/composer<br /> * Ryan Reilly (Rain)<br /> * Stephen Rozanc (TreizeCouleurs)<br /> * Timothy Pinkham (TimothyP)<br /> * Tyler Johnson<br /> === Sound Effects ===<br /> * Corey Woodworth (woodwizzle) &amp;#8212; hit and die sounds<br /> * J.W. Bjerk ([[User:Eleazar|Eleazar]])<br /> * Lari Nieminen (zookeeper) &amp;#8212; focus on attack, weapon and user interface sounds<br /> * Adam Rinsky (Action Jack) &amp;#8212; dwarf hit and die sounds<br /> * Leonardo Magno Sampaio (leorock116) &amp;#8212; mace, staff and club sounds<br /> === Campaign Design ===<br /> * Asa Swain (quartex) &amp;#8212; Under the Burning Suns<br /> * Astrid Halberkamp &amp;#8212; Campaign maintenance and various improvements<br /> * Benjamin Drieu<br /> * Charles Dang (vultraz) &amp;#8212; Campaign maintenance and various improvements<br /> * Dacyn<br /> * Dan Gerhards (beetlenaut) &amp;#8212; Dead Water, Secrets of the Ancients<br /> * David White (Sirp) &amp;#8212; Heir to the Throne<br /> * Eric J. Mesoy (Circon) &amp;#8212; A Tale of Two Brothers<br /> * Eric S. Raymond (ESR) &amp;#8212; The Hammer of Thursagan<br /> * esci &amp;#8212; Descent into Darkness<br /> * Francisco Muñoz (fmunoz) &amp;#8212; founding artist and former lead artist, worked consistently on all aspects till around v0.7-0.9.<br /> * James Spencer (Shade) &amp;#8212; The Rise of Wesnoth<br /> * Jeffrey ‘Sigurd’ Westcoat (SigurdFireDragon) &amp;#8212; Winds of Fate<br /> * Jonathan Kelly (name) &amp;#8212; Winds of Fate<br /> * Joseph Simmons (Turin) &amp;#8212; The Eastern Invasion, The Sceptre of Fire<br /> * Justin Zaun (jzaun) &amp;#8212; coder, scenario designer<br /> * Lari Nieminen (zookeeper) &amp;#8212; redesign of various scenarios and other enhancement<br /> * [mailto:Crazy-Ivanovic&amp;#x40;gmx&amp;#x2E;net Nils Kneuper] (Ivanovic) &amp;#8212; A Tale of Two Brothers<br /> * Santi/fnaek &amp;#8212; The Legend of Wesmere<br /> * Scott Klempner &amp;#8212; Heir to the Throne, The Rise of Wesnoth, Liberty<br /> * Taurus &amp;#8212; Northern Rebirth, Son of the Black-Eye<br /> * William Carey (aelius) &amp;#8212; The South Guard<br /> === Multiplayer Maps and Balancing ===<br /> * George Birthisel (happygrue/Wintermute) &amp;#8212; Unit balancing, Dunefolk Era<br /> * Hejnewar &amp;#8212; balancing for Age of Heroes, revised dunefolk<br /> * Jake Bailey (jb) &amp;#8212; multiplayer maps<br /> * Joshua Northey (Becephalus) &amp;#8212; multiplayer maps (mostly 2vs2 and up)<br /> * Mike Quiñones (Doc Paterson) &amp;#8212; multiplayer maps (mostly 1vs1)<br /> * Noy &amp;#8212; general purpose administration, unit balancing<br /> * Peter Groen (pg) &amp;#8212; multiplayer maps<br /> * Ruben Philipp Wickenhäuser (The Very Uhu) &amp;#8212; multiplayer maps<br /> * Soliton &amp;#8212; unit balancing<br /> * Tom Chance (telex4) &amp;#8212; multiplayer maps<br /> * [mailto:kleinfel&amp;#x40;wpi&amp;#x2E;edu Zack Kleinfeld] &amp;#8212; multiplayer maps, unit balancing<br /> === Packagers ===<br /> * ancestral &amp;#8212; Apple OS X packager (1.12.1 and later)<br /> * [mailto:hrubymar10&amp;#x40;gmail&amp;#x2E;com Martin Hrubý] ([[User:hrubymar10|hrubymar10]]) &amp;#8212; Apple macOS packager (1.13.11 and later)<br /> * Matthias Schoeck (mattsc) &amp;#8212; Apple OS X packager (1.11.8 and later)<br /> * [mailto:Crazy-Ivanovic&amp;#x40;gmx&amp;#x2E;net Nils Kneuper] (Ivanovic) &amp;#8212; OpenPandora packager<br /> * [mailto:pj&amp;#x40;pehjota&amp;#x2E;net P. J. McDermott] (pehjota) &amp;#8212; Debian/Ubuntu packager<br /> * Rhonda D'Vine (Rhonda) &amp;#8212; Debian/Ubuntu packager<br /> * Sebastian Kölle (aquileia) &amp;#8212; Visual Studio SDK maintainer<br /> * Sergey Popov (loonycyborg) &amp;#8212; Microsoft Windows packager and MinGW SDK maintainer<br /> * [mailto:ports&amp;#x40;toco-domains&amp;#x2E;de Torsten Zühlsdorff] &amp;#8212; FreeBSD Packager<br /> * Vincent Cheng (vincent_c) &amp;#8212; Debian/Ubuntu packager<br /> &lt;hr style='clear:none'&gt;<br /> * [mailto:ben&amp;#x40;happyspork&amp;#x2E;com Ben Anderman] (crimson_penguin) &amp;#8212; Apple OS X packager (for 1.5.6 and later)<br /> * Cyril Bouthors (CyrilB) &amp;#8212; Debian packager, patron<br /> * Darryl Dixon<br /> * edge<br /> * Isaac Clerencia &amp;#8212; Debian packager<br /> * Jay Hopping<br /> * Jörg Hinrichs (Yogi Bear/YogiHH) &amp;#8212; Microsoft Windows packager<br /> * Laurent Wacrenier (lwa) &amp;#8212; Apple OS X packager (for v1.4 and before)<br /> * Marcin Konicki (ahwayakchih) &amp;#8212; BeOS packager<br /> * Marcus Phillips (Sithrandel) &amp;#8212; Apple OS X packager (for v1.0 and before)<br /> * Mark Michelsen (skovbaer) &amp;#8212; Slackware packager<br /> * Muhammad Amir Ayub (anakayub) &amp;#8212; Apple OS X packager<br /> * Piotr Cychowski (Mist/cycholka) &amp;#8212; Microsoft Windows packager<br /> * singalen &amp;#8212; iOS port<br /> * Simon Forsyth (Alarantalara) &amp;#8212; Apple OS X Packager (1.9.6 and later)<br /> * Vlad Glagolev (Stealth) &amp;#8212; OpenBSD packager<br /> === Miscellaneous Contributors ===<br /> * Aaron Keisch-Walter (Exasperation)<br /> * Aaron Winter (Byteron)<br /> * Adam Leffew<br /> * Adrian Iosif (Zappaman)<br /> * Aishiko &amp;#8212; Unit instance recall cost implementation<br /> * Alek Bollig (binarycoder)<br /> * Alesis Novik<br /> * Alexander Lacson (max_torch)<br /> * Aline Riss (akihara)<br /> * Amir Hassan (kallaballa)<br /> * Andris Szell (bandita137)<br /> * André Knispel<br /> * Andrea Palmatè (afxgroup)<br /> * Andrius Šilinskas (thunderstruck)<br /> * Andrius Štikonas<br /> * Anja Keicher (ayne)<br /> * Astrid Halberkamp<br /> * August Vesterbacka<br /> * Ben Anderman (crimson_penguin) &amp;#8212; unit list<br /> * Boldizsár Lipka (lipk)<br /> * Brilliand<br /> * Burkay Özdemir (Velory) &amp;#8212; Poisoning improvement for Formula AI<br /> * chisquare130<br /> * Chris Carpenter (mordocai)<br /> * Chris Hopman (cjhopman)<br /> * Chris Mann (WildPenguin) &amp;#8212; Emacs WML-mode<br /> * Chusslove Illich (caslav.ilic) &amp;#8212; wmlxgetext improvements<br /> * Cody Burchell (nullmoose)<br /> * David Slabý (blaf)<br /> * Daniel Bruegmann<br /> * Daniel Santos<br /> * David Mikos (Coffee) &amp;#8212; Coder, animation framework improvements.<br /> * Denny Vaccaro (endercoaster)<br /> * Derek (Gambit)<br /> * devnexen<br /> * Discontinuum<br /> * DisherProject<br /> * Dmitry K. (nephro)<br /> * Doug Rosvick ([[User:dlr365|dlr365]])<br /> * dorng<br /> * dreamer-88<br /> * Dugi &amp;#8212; Context-free name generator<br /> * Duthlet<br /> * EarthCake<br /> * Edward Chernenko<br /> * Ekdohibs<br /> * elvish_sovereign<br /> * Ely Levy (Nakee)<br /> * Eric Gallager (egallager/cooljeanius)<br /> * Étienne Simon (ejls)<br /> * Etkin Baris Ozgul (pokhbocee) &amp;#8212; Lua AI<br /> * Eugene Kosov (kevg)<br /> * evanmiller<br /> * [mailto:eugeni&amp;#x2E;stepanov&amp;#x40;gmail&amp;#x2E;com Evgeniy Stepanov] &amp;#8212; NativeClient port<br /> * Evgeny Kapun<br /> * FAAB<br /> * Federico Pasco (neverEnough)<br /> * Fedor Khod'kov (teddy/fkhodkov)<br /> * Felix Bauer (flix)<br /> * Fernando Carmona (Ferk)<br /> * Floris Kint (Grimling)<br /> * Francesco Gigli (Jaramir)<br /> * Frank Richter (res)<br /> * Frédéric Wagner<br /> * Fredrik Wikstrom (salass00)<br /> * galegosimpatico<br /> * Galen Brooks (fluffbeast)<br /> * gh0st &amp;#8212; 2012 Google Code-in Students’ Micro AI development<br /> * Gothyoba<br /> * Gregory Gauthier (rjaguar3)<br /> * Groggy Dice (groggydice) &amp;#8212; wmllint enhancements<br /> * Guillaume Lestringant<br /> * [mailto:kevin&amp;#x2E;xgr&amp;#x40;gmail&amp;#x2E;com Guorui Xi] (Kevin_Xi)<br /> * Hans-Joachim Gurt (HaJo)<br /> * Herb Pah (haiz)<br /> * holius-fr<br /> * IceTyp<br /> * ilyapopov<br /> * J. Tyne (JaMiT)<br /> * J.R. Blain (Cowboy)<br /> * jstitch<br /> * Jacek Kominek (BroodKiller)<br /> * [mailto:benetnash&amp;#x40;icpnet&amp;#x2E;pl Jan Polak] (benetnash) &amp;#8212; Formula AI contributions<br /> * Jan Zvánovec (jaz)<br /> * [mailto:babataz&amp;#x40;gmail&amp;#x2E;com Jean-Baptiste Poittevin] (BBT)<br /> * Jeff Breidenbach (jab) &amp;#8212; Bilinear interpolation<br /> * [mailto:jleldridge27&amp;#x40;gmail&amp;#x2E;com Jeffrey Eldridge] (jleldridge)<br /> * Jérôme (segfault)<br /> * Jim Carroll (Jimm)<br /> * Jody Northup (Upthorn) &amp;#8212; Prospective student (world persistence)<br /> * Joeri Melis<br /> * Joey L. Maalouf (JDog)<br /> * [mailto:john&amp;#x40;jo&amp;#x2E;hnanthony&amp;#x2E;com John Anthony] &amp;#8212; campaignd work, mainly security-based<br /> * John B. Messerly (jbm)<br /> * John Harvey (johndh) &amp;#8212; minor race descriptions; bats, goblins, mechanical, merfolk, monster, naga, ogre<br /> * Jonathan Combs (ScegfOd) &amp;#8212; log activating dialog<br /> * Jonas Lihnell (Roze)<br /> * Jonas Kölker<br /> * [mailto:jorda&amp;#x40;ettin&amp;#x2E;org Jordà Polo] (ettin) &amp;#8212; website, i18n, ui<br /> * Josef Reidinger (qk)<br /> * Joseph Gelfand<br /> * Joshua Hudson<br /> * josteph<br /> * Jozrael<br /> * Justin DiSabatino (Turuk)<br /> * Kamil Kaczmarczyk (lampak)<br /> * [mailto:karl&amp;#x2E;miller&amp;#x2E;km&amp;#x40;gmail&amp;#x2E;com Karl Miller] (karlm)<br /> * Karol Kozub (automagic)<br /> * Kevin Montalva (Ryckes)<br /> * Kevin Yap (iKevinY)<br /> * Konrad Schwede (Konrad2)<br /> * Kristoffer Grönlund (kegie)<br /> * Krogen<br /> * Larkin Nickle (larbob/larb0b/larbawb)<br /> * Laurent Birtz<br /> * legoktm<br /> * leonardoInf<br /> * lilinitsy<br /> * Lovens Weche (LovCAPONE)<br /> * Luiz Fernando de Faria Pereira (lfernando)<br /> * [mailto:lutheroto&amp;#x40;gmail&amp;#x2E;com Luther Thompson]<br /> * lv-zheng<br /> * [mailto:code&amp;#x40;hryniuk&amp;#x2E;pl Łukasz Hryniuk]<br /> * Maksim Orlovich (SadEagle)<br /> * Mark McGuire (TronPaul)<br /> * Martin Bede &amp;#8212; 2012 Google Code-in Students’ Micro AI development<br /> * [mailto:hrubymar10&amp;#x40;gmail&amp;#x2E;com Martin Hrubý] ([[User:hrubymar10|hrubymar10]])<br /> * Mateusz Kolaczek (PL_kolek)<br /> * Matt Renfer (Des) &amp;#8212; Prose revision<br /> * Matthias Schoeck (mattsc) &amp;#8212; AI improvements<br /> * matthiaskrgr &amp;#8212; Running address sanitizer to catch leaks<br /> * Maxim Biro (nurupo)<br /> * Maximilian Fricke (madmax28)<br /> * Maximilian Lupke (malumalu)<br /> * Marius Spix (spixi)<br /> * Michael Flowers (MJ)<br /> * Michael Schmahl<br /> * Michael Strebel (Nostromus)<br /> * midzer<br /> * Miguel Zapico (elricz)<br /> * mstrebel<br /> * [mailto:greywhind&amp;#x40;users&amp;#x2E;sourceforge&amp;#x2E;net Nathan Partlan] ([[User:Greywhind|Greywhind]])<br /> * [mailto:nathan&amp;#x2E;b&amp;#x2E;walker&amp;#x40;vanderbilt&amp;#x2E;edu Nathan Walker] (RiftWalker)<br /> * neoedmund<br /> * newfrenchy83<br /> * Niall Burton (Leonard03)<br /> * niegenug<br /> * Nobun &amp;#8212; wmlxgettext<br /> * [mailto:zabivator&amp;#x40;gmail&amp;#x2E;com Oleg Tsarev]<br /> * Olivier Faure (PoignardAzur)<br /> * [mailto:pj&amp;#x40;pehjota&amp;#x2E;net P. J. McDermott] (pehjota) &amp;#8212; horizontal scrolling regression fix, systemd _wesnoth user, system Lua, update_copyrights improvements<br /> * [mailto:asqueados&amp;#x40;gmail&amp;#x2E;com Pablo J. Urbano Santos] ([[User:Lord Ork|Lord Ork]])<br /> * Patryk Obara (dreamer_)<br /> * Paul Smedley (Creeping)<br /> * Paŭlo Ebermann ([[User:Pauxlo|Pauxlo]])<br /> * PBechon<br /> * Peter Elmers<br /> * Peter Mawhorter ([[User:solsword|solsword]]) &amp;#8212; Python TC script upgrade<br /> * Petr Sobotka (Pietro)<br /> * [mailto:root&amp;#x40;delroth&amp;#x2E;is-a-geek&amp;#x2E;org Pierre Bourdon] (delroth)<br /> * pquentin<br /> * Pranav Deshpande (universecoder)<br /> * Priit Laes (plaes)<br /> * Pubudu Gunawardena (ugudu)<br /> * Qi Mo (qmo2015)<br /> * Quetzalcoatl<br /> * Randy Kostiuk (Randypk) &amp;#8212; Bug fixes<br /> * RatArmy (fujimo-t)<br /> * Reuben Rakete (rocketbang)<br /> * Richard Yao (srk9) &amp;#8212; Bug fixes<br /> * Rikard Falkeborn<br /> * Robert Spencer &amp;#8212; 2012 Google Code-in Students’ Micro AI development<br /> * Robert Wallace (Robertdebrus)<br /> * Rocco J Carello (rogue)<br /> * Roland Hautz (duncan_shriek)<br /> * Rolf Sievers (Lizard)<br /> * Ronny Standtke<br /> * rrigby<br /> * Ryan Frame<br /> * Ryan Henszey<br /> * Ryan Roden-Corrent (rcorre) &amp;#8212; Hotkey release and scroll key rebinding<br /> * [mailto:sachith500&amp;#x40;gmail&amp;#x2E;com Sachith Seneviratne] (sachith500) &amp;#8212; Bug fixes at the moment. GSoC Aspirant<br /> * Samuel Kim &amp;#8212; 2012 Google Code-in Students’ Micro AI development<br /> * Sean Yeh<br /> * Sebastian Goll (afran)<br /> * Sebastian Kölle (aquileia)<br /> * Serge Martin (EdB)<br /> * [mailto:stomasortiz&amp;#x40;gmail&amp;#x2E;com Sergio Tomás Ortiz]<br /> * Severin Glöckner (Shiki, Sevu)<br /> * Simon Forsyth (Alarantalara)<br /> * [mailto:simon_smith&amp;#x40;zen&amp;#x2E;co&amp;#x2E;uk Simon Smith] ([[User:Simons_Mith|Simons Mith]]) &amp;#8212; Style guide, help with the application of the style guide, and some tips<br /> * SoapGentoo<br /> * starius<br /> * Stéphane Gimenez (gim)<br /> * [mailto:Majora700&amp;#x40;gmail&amp;#x2E;com Steven Panek] ([[User:Espreon|Espreon]])<br /> * [mailto:sylecn&amp;#x40;gmail&amp;#x2E;com sylecn]<br /> * [mailto:nsytyi&amp;#x40;gmail&amp;#x2E;com Sytyi Nick] (Sytyi) &amp;#8212; WML validation<br /> * [mailto:ptablot&amp;#x40;mopong&amp;#x2E;net Talbot Pierre] (Trademark)<br /> * Tamas K. (negusnyul)<br /> * techtonik<br /> * the_beagle &amp;#8212; Wose race description<br /> * The Gnat<br /> * Thewodoros &amp;#8212; Eastern Invasion Maintenance<br /> * Thibault Févry (iwontbecreative) &amp;#8212; Some GCI tasks and utils/wiki_grabber.py cleanup.<br /> * Thom Diment (UnwiseOwl)<br /> * [mailto:hankerspace&amp;#x40;gmail&amp;#x2E;com Thomas Martinet] (hankerspace)<br /> * [mailto:thomas&amp;#x2E;prevost&amp;#x40;gmail&amp;#x2E;com Thomas Prevost] (zancdar)<br /> * Thonsew<br /> * Thorny23<br /> * Tobias Frei (ToBeFree)<br /> * Tomasz Sikorski (Tomsik)<br /> * Tommy Schmitz<br /> * Tommy (yobbo)<br /> * Toom Lõhmus (Ravana)<br /> * tsr<br /> * Valentin Deschaintre (Zazweda, Epyde) &amp;#8212; Zone guardian Micro AI<br /> * vitiv &amp;#8212; 2012 Google Code-in Students’ Micro AI development<br /> * [mailto:viy&amp;#x40;altlinux&amp;#x2E;org viy]<br /> * Vladimír Slávik &amp;#8212; Miscellaneous text formatting and translation engine related help<br /> * vn971, vgaming<br /> * walodar<br /> * Wedge009<br /> * Yang Yifan (Xara)<br /> * Zas<br /> === Bots ===<br /> * CIA<br /> * irker<br /> * janebot<br /> * shikadibot<br /> * wesbot<br /> == Translators ==<br /> === Afrikaans Translation ===<br /> * András Salamon (ott)<br /> * Erhard Eiselen<br /> * Len van Dalsen (Numbers13) &amp;#8212; current maintainer<br /> * Nico Oliver (nicoza)<br /> * Renier Maritz<br /> === Ancient Greek Translation ===<br /> * Mejri Ziad (hermestrismi) &amp;#8212; current maintainer<br /> === Arabic Translation ===<br /> * Amnay Mokhtari<br /> * Mejri Ziad (hermestrismi) &amp;#8212; current maintainer<br /> === Asturian Translation ===<br /> === Basque Translation ===<br /> * Alfredo Beaumont (ziberpunk)<br /> * Julen Landa (genars)<br /> * Mikel Olasagasti (Hey_neken)<br /> === Bengali Translation ===<br /> * [mailto:suvrax&amp;#x40;gmail&amp;#x2E;com Subhraman Sarkar] (LumiousE/babaissarkar) &amp;#8212; current maintainer<br /> * Tahsin J Khalid (Lord-Knightmare) &amp;#8212; maintainer (former)<br /> === Bulgarian Translation ===<br /> * Anton Tsigularov (Atilla)<br /> * Bono Nonchev<br /> * Denica Mincheva (Deni)<br /> * Georgi Dimitrov (oblak)<br /> * Ivan Petrov (TheWhiteKnight) &amp;#8212; current maintainer<br /> * Nikolay Vladimirov (Turki)<br /> * Steven Genchev (blademaster83) <br /> * Valentin Yankov (kartacha) <br /> === Catalan Translation ===<br /> * Carles Company (brrr)<br /> * Dan Rosàs Garcia (focks)<br /> * Daniel López (Azazelo)<br /> * Joan Queralt<br /> * Jonatan Alamà (tin)<br /> * [mailto:jorda&amp;#x40;ettin&amp;#x2E;org Jordà Polo] (ettin)<br /> * Jose Gordillo (kilder)<br /> * J.R. Dolcet Castro (Malin Keshar)<br /> * Marc Orcau<br /> * Mark Recasens<br /> * [mailto:miquel&amp;#x2E;angel&amp;#x2E;burgos&amp;#x40;gmail&amp;#x2E;com Miquel-Àngel Burgos i Fradeja] &amp;#8212; current maintainer<br /> * Pau Rul·lan Ferragut<br /> * Roberto Garcia (Motxales)<br /> === Chinese Translation ===<br /> * AxalaraFlameheart (AxalaraFlame)<br /> * Brian lee<br /> * chisquare130<br /> * [mailto:cloudidust&amp;#x40;gmail&amp;#x2E;com CloudiDust] ([[User:CloudiDust|CloudiDust]]) &amp;#8212; former maintainer<br /> * cryaciccl<br /> * D3dSun<br /> * Dionysus<br /> * 逆天的高级菜鸟 (Gaojicainiao)<br /> * Henry Zhu (Hardwood) &amp;#8212; iOS announcements translation into Chinese<br /> * Huang Hongye (Dugucloud) &amp;#8212; translation and image localization<br /> * Huang Huan<br /> * Huang Lechuan<br /> * leaf<br /> * Luojie-dune<br /> * MrKing<br /> * 网上佳公子<br /> * Owlet<br /> * pianton<br /> * SealMe<br /> * spider5<br /> * StephDC<br /> * [mailto:sylecn&amp;#x40;gmail&amp;#x2E;com sylecn]<br /> * Teamzhangmeng<br /> * vimacs &amp;#8212; current maintainer<br /> * vinneymail<br /> * wind<br /> * Yifan<br /> * yym514<br /> * zen<br /> === Chinese (Taiwan) Translation ===<br /> * 楊綮銘<br /> * 李昆融<br /> * 李信融<br /> === Croatian Translation ===<br /> * Ivica Đurenec (charlieh65)<br /> * Nino Gunjača<br /> === Czech Translation ===<br /> * Alexander Slávik (Olin)<br /> * Anežka Bubeníčková (Bubu)<br /> * Čestmír Houska<br /> * David Nečas (Yeti)<br /> * David Novotný (Draqen)<br /> * [mailto:jan&amp;#x2E;dedic&amp;#x40;gmail&amp;#x2E;com Jaromír Dědič]<br /> * Karel Doleček<br /> * Lukáš Faltýnek<br /> * [mailto:hrubymar10&amp;#x40;gmail&amp;#x2E;com Martin Hrubý] ([[User:hrubymar10|hrubymar10]])<br /> * Martin Šín<br /> * Michal Žejdl<br /> * Mintaka<br /> * [mailto:tapik&amp;#x40;buchtovi&amp;#x2E;cz Oto Buchta] ([[User:Tapik|tapik]])<br /> * Petr Kopač (Ferda)<br /> * Petr Kovár (Juans)<br /> * Rudolf Orság<br /> * Septim<br /> * Sofronius<br /> * Vít Komárek<br /> * Vít Krčál<br /> * Vladimír Slávik<br /> === Danish Translation ===<br /> * Anders K. Madsen (madsen)<br /> * Ask Hjorth Larsen<br /> * Bjarke Sørensen (basher)<br /> * Jesper Fuglsang Wolff (ulven)<br /> * Joe Hansen<br /> * Kenneth Nielsen<br /> * Mark Michelsen (skovbaer)<br /> * Mathias Bundgaard Svensson (freaken)<br /> * Ole Laursen<br /> === Dutch Translation ===<br /> * [mailto:AI0867&amp;#x40;gmail&amp;#x2E;com Alexander van Gessel] (AI/AI0867) &amp;#8212; previous translation maintainer<br /> * Arne Deprez<br /> * Astrid Halberkamp<br /> * Floris Kint (Grimling)<br /> * Foppe Benedictus<br /> * [mailto:oudshoorn&amp;#x40;eitri&amp;#x2E;nl IJsbrand Oudshoorn]<br /> * Joeri Melis<br /> * Jon Jacobs<br /> * Koen Douterloigne<br /> * Koen Vervloesem (koan)<br /> * Lala<br /> * Maarten Albrecht<br /> * Merijn de Vet &amp;#8212; translation maintainer<br /> * Orange_Pumpkin<br /> * Pieter Vermeylen (Onne)<br /> * Rico van Coevorden<br /> * Rob van der Vleugel<br /> * Roel Thijs (Roel)<br /> * Roger Koot<br /> * Thomas Hugo de Groot<br /> * Tobe Deprez<br /> * WimPapa<br /> === English (GB) Translation ===<br /> * András Salamon (ott)<br /> * Eric S. Raymond (ESR)<br /> * pjr<br /> * [mailto:Majora700&amp;#x40;gmail&amp;#x2E;com Steven Panek] ([[User:Espreon|Espreon]])<br /> * Thomas Hockings ([[User:Deusite|Deusite]])<br /> * Wedge009<br /> === English (Shaw) Translation ===<br /> * [mailto:arcriley&amp;#x40;ubuntu&amp;#x2E;com Arc Riley] ([[User:ArcRiley|ArcRiley]]) &amp;#8212; translation maintainer<br /> * [mailto:reportingsjr&amp;#x40;gmail&amp;#x2E;com Jon Neal] (reportingsjr)<br /> * [mailto:thomas&amp;#x40;thurman&amp;#x2E;org&amp;#x2E;uk Thomas Thurman] (marnanel)<br /> === Esperanto Translation ===<br /> * Aleksej Korgenkov (Grimpanto)<br /> * Alís Martínez<br /> * Francesco Lorenzon (Likso)<br /> * Ľubo Fajth<br /> * Luther Thompson<br /> * Maarten Albrecht<br /> * Mariano Street (mctpyt) &amp;#8212; translation maintainer<br /> * Rastislav Šarišský (Asto)<br /> === Estonian Translation ===<br /> * Kaido Kikkas (UncleOwl)<br /> * Mart Tõnso<br /> === Filipino Translation ===<br /> * Joset Anthony Zamora (eradicus)<br /> * Karen Eve Eso (keeve)<br /> === Finnish Translation ===<br /> * Ankka<br /> * Jaakko Muilu<br /> * Jaakko Saarikko &amp;#8212; translation maintainer<br /> * Jarkko Patteri (Jarkko)<br /> * Juhana Uuttu<br /> * Jussi Rautio (jgrr)<br /> * kko<br /> * Matias Parmala<br /> * Matias Pigg<br /> * Mikko Nikkilä (Miccoh)<br /> * Mikko Kraft (deserter)<br /> * Miriam Green<br /> * Niklas Laxström (Nikerabbit)<br /> * Olavi Peltoniemi (MrPringles)<br /> * Otto Oikarinen<br /> * paxed<br /> * Samu Voutilainen (Smar)<br /> * Santtu Pajukanta (Japsu)<br /> * Simo Sutela<br /> * Veikko Pukkila (swege)<br /> === French Translation ===<br /> * alberic89<br /> * Antoine Garnier<br /> * Antoine Imboden<br /> * Aurélien Brevers (Breversa)<br /> * Aurélien Paulus<br /> * Arnaud Garoux (La vie en wose)<br /> * Benoit Astruc<br /> * [mailto:benoit&amp;#x2E;timbert&amp;#x40;free&amp;#x2E;fr Benoît Timbert] ([[User:Noyga|Noyga]]) &amp;#8212; former translation maintainer<br /> * Bruno Fève (PP)<br /> * Cédric Duval<br /> * Damian Gryski (dmg)<br /> * [[User:Damien|Damien Jacquot]] &amp;#8212; former lead translator<br /> * DaringTremayne<br /> * David Pradier<br /> * Éric Pierre (Gari)<br /> * Fabrice Boulakia<br /> * Florence Guettaa (inflow)<br /> * François Mariage (Paquito)<br /> * François Orieux<br /> * Geoffroy Douillié ([[User:Gdou|gdou]])<br /> * Gérard Bodin (Gnork)<br /> * Guillaume Delacourt<br /> * Guillaume Duwelz-Rebert<br /> * Guillaume Guigou<br /> * [mailto:massart&amp;#x2E;guillaume&amp;#x40;wanadoo&amp;#x2E;fr Guillaume Massart] (Piou2fois)<br /> * Guillaume Melquiond (silene)<br /> * Guillaume Pascal<br /> * Ismaël Brunet Pac<br /> * Jean Privat (Tout)<br /> * Jean-Louis Passerin (Zoltic)<br /> * Jean-Luc Menut<br /> * Jean-Luc Richard (Le Gnome)<br /> * Jean-Joseph Paget<br /> * Jehan Hysseo (Jey)<br /> * Jérémy Rosen (Boucman)<br /> * Julien Moncel<br /> * Julien Tailleur<br /> * Marc Scheffer<br /> * Mathieu Guilbaud<br /> * Mendes Oulamara<br /> * Michel Poléni (Thanatloc)<br /> * Nicolas Boudin (Blurgk)<br /> * [mailto:philippe&amp;#x2E;plantier&amp;#x40;naema&amp;#x2E;org Philippe Plantier] ([[User:Ayin|Ayin]])<br /> * Philippe Rasquinet<br /> * Pierre Rudloff<br /> * Sébastien Raynaud (Galactic turkey)<br /> * Sylvain Jeanne<br /> * Thierry Bothorel<br /> * Solena Le Moigne<br /> * William Dupré<br /> * [mailto:ydirson&amp;#x40;altern&amp;#x2E;org Yann Dirson]<br /> === Friulian Translation ===<br /> === Galician Translation ===<br /> * [mailto:adriyetichaves&amp;#x40;gmail&amp;#x2E;com Adrián Chaves Fernández] (Gallaecio)<br /> * Fran Diéguez<br /> * Jacobo Abel Fernández García &amp;#8212; inactive<br /> * Javier Pico<br /> * Manuel Meixide<br /> * Marce Villarino<br /> * [mailto:leandro&amp;#x2E;regueiro&amp;#x40;gmail&amp;#x2E;com Leandro Regueiro] (unho) &amp;#8212; translation maintainer<br /> * Victor Portela<br /> * Proxecto Trasno &amp;#8212; translation project (http://trasno.net)<br /> === German Translation ===<br /> * Aaron Winter (Bitron)<br /> * Alexander Ginschel (mcpgal)<br /> * Alexander Laux<br /> * Alexander Zurek (Alresu)<br /> * Andre Schmidt (schmidta)<br /> * Boris Stumm (quijote_)<br /> * Celina Mainz (Mailina)<br /> * Chewan<br /> * Christoph Berg (chrber) &amp;#8212; former translation maintainer<br /> * Christoph Lange (madelgijs)<br /> * Drakefriend<br /> * Elias Fromm (Karpadorsch)<br /> * Elias Pschernig (allefant)<br /> * ghype<br /> * Iwan Gabovitch (qubodup)<br /> * Lennard<br /> * Lorenzo Hardt (HeroOfGaming)<br /> * Rhonda D'Vine (Rhonda)<br /> * Jan Greve (Jan)<br /> * Jan Heiner Laberenz (jan-heiner)<br /> * [mailto:loehnert&amp;#x2E;kde&amp;#x40;gmx&amp;#x2E;de Johannes Löhnert]<br /> * Kai Ensenbach<br /> * Konrad Schwede (Konrad2)<br /> * [mailto:marcel_miebach&amp;#x40;gmx&amp;#x2E;de Marcel Miebach] (retr0virus)<br /> * Mark de Wever ([[User:SkeletonCrew|Mordante/SkeletonCrew]])<br /> * Matthias Gianfelice (MatthiasG)<br /> * [mailto:Crazy-Ivanovic&amp;#x40;gmx&amp;#x2E;net Nils Kneuper] (Ivanovic)<br /> * Oliver Lange (Crommy)<br /> * René Genz (Sobek)<br /> * Ronny Standtke<br /> * Ruben Philipp Wickenhäuser (The Very Uhu)<br /> * Severin Glöckner (Shiki, Sevu) &amp;#8212; former translation maintainer<br /> * Simon Waldek (s1m0n)<br /> * Stephan Grochtmann (Schattenstephan)<br /> * Steve Cotton (octalot)<br /> * Tobias Schönau (SonIcco)<br /> * Uz-Valentin Friedrich<br /> * vonHalenbach<br /> * [mailto:Wuzzy&amp;#x40;disroot&amp;#x2E;org Wuzzy]<br /> === Greek Translation ===<br /> * Alexander Alexiou (Santi/fnaek)<br /> * Evangelos Papakirikou<br /> * Harry Kaimenas<br /> * Katerina Sykioti<br /> * Konstantinos Egarhos<br /> * Konstantinos Karasavvas<br /> * Mik2303<br /> * Nikos Astroylakis (Greek Dubbings Maker)<br /> * Nikos Papadopoulos (galicae)<br /> * Nikos the Great<br /> * Panagiotis Famelis (Kesnar)<br /> * Papadopoulos Themistoklis<br /> * Spiros, Giorgis<br /> === Hebrew Translation ===<br /> * Ariel Ben-Yehuda<br /> * Oron Peled<br /> * Ely Levy (Nakee)<br /> === Hungarian Translation ===<br /> * Barthalos Márton (Aldebaran Ghrelin)<br /> * Czakó Csaba (Horus)<br /> * Erdélyi Kristóf<br /> * Fábián Balázs (nermal93)<br /> * Hamar Krisztián<br /> * Kádár-Németh Krisztián (Rudanar Firmus)<br /> * Kékkői László (BlackEvil)<br /> * Kelemen Zoltán (kele)<br /> * Kovács Dániel (Consalamander)<br /> * Majsa Norbert (wias)<br /> * Máthé Katalin (katkadu)<br /> * Németh Tamás (nTOMasz)<br /> * Pintér Csaba (piere)<br /> * Salamon András (ott)<br /> * Soltész Adrián (majominia)<br /> * Széll Tamás (TomJoad)<br /> * Udvari Gábor (Udi)<br /> * Udvari Zsolt<br /> * Vasvári Péter (honorshark)<br /> === Icelandic Translation ===<br /> * Arngrímur Stefánsson<br /> * Gabríel A. Pétursson<br /> === Indonesian Translation ===<br /> * Ardhi (earthboy)<br /> * Benny Lin<br /> * [mailto:sevennightmare&amp;#x40;tutanota&amp;#x2E;de Irsyad Musthafa] &amp;#8212; translation maintainer<br /> * Iwan<br /> * [mailto:inkraiswitras&amp;#x40;yahoo&amp;#x2E;com Nicky Inkrais Witras] &amp;#8212; previous translation maintainer<br /> * [mailto:yuris_wicaksana&amp;#x40;yahoo&amp;#x2E;com Yuristyawan Pambudi Wicaksana] &amp;#8212; previous translation maintainer<br /> === Irish Translation ===<br /> * Mountain_King &amp;#8212; translation maintainer<br /> === Italian Translation ===<br /> * Alessandro Barbazza<br /> * Alessio D'Ascanio (otaku)<br /> * Americo Iacovizzi (DarkAmex)<br /> * [mailto:arosella&amp;#x40;yahoo&amp;#x2E;com Antonio Rosella]<br /> * crys0000<br /> * Elvish_Hunter<br /> * Eugenio Favalli (ElvenProgrammer)<br /> * Federico Tomassetti<br /> * Filippo Abbruzzo (Gwain)<br /> * isazi<br /> * Luciano Montanaro (Luciano)<br /> * Michele Maresi (mich)<br /> * RokStar<br /> * Stefano Coccato (BioHazardX)<br /> === Japanese Translation ===<br /> * BlueStar<br /> * clearpotion<br /> * h22<br /> * [mailto:broadbarredfirefish&amp;#x40;gmail&amp;#x2E;com Hironori Fujimoto] (RatArmy) &amp;#8212; translation maintainer<br /> * [mailto:iwaim&amp;#x2E;sub&amp;#x40;gmail&amp;#x2E;com IWAI, Masaharu] ([[User:Iwaim|iwaim]])<br /> * [mailto:kateitekino_hito&amp;#x40;yahoo&amp;#x2E;co&amp;#x2E;jp kateiteki]<br /> * kudoh<br /> * Maxwell Stibbard Hawkes<br /> * [mailto:mishanhideaki88&amp;#x40;gmail&amp;#x2E;com mishan]<br /> * いいむらなおき (amatubu) — Naoki Iimura<br /> * [mailto:okyada&amp;#x40;gmail&amp;#x2E;com 岡田信人 — Nobuhito Okada]<br /> * np<br /> * [mailto:pasta0915[at]gmail&amp;#x2E;com Shoot MORII] (pastak)<br /> * OOTA, Masato(oo)<br /> * Q<br /> * R.N<br /> * rouiza<br /> * [mailto:le&amp;#x2E;sahara&amp;#x40;gmail&amp;#x2E;com sahara]<br /> * Shigerello<br /> * [mailto:suto3suto3&amp;#x40;gmail&amp;#x2E;com suto3]<br /> * 瀟湘夜雨<br /> * Taigaku Okuiso<br /> * Takanobu Hirai<br /> * tamanegi<br /> * [mailto:yma9yma&amp;#x40;gmail&amp;#x2E;com yma]<br /> * Yuji Matsumoto<br /> === Korean Translation ===<br /> * mistzone &amp;#8212; current maintainer<br /> === Latin Translation ===<br /> * Eric S. Raymond (ESR) &amp;#8212; general semantician<br /> * Mark Polo (mpolo) &amp;#8212; original maintainer<br /> * Michael Babich ([[User:Aethaeryn|Aethaeryn]]) &amp;#8212; current maintainer<br /> * [mailto:Majora700&amp;#x40;gmail&amp;#x2E;com Steven Panek] ([[User:Espreon|Espreon]])<br /> * Thomas Hockings ([[User:Deusite|Deusite]])<br /> === Latvian Translation ===<br /> * Artis Rozentāls<br /> * Gvido Bruveris &amp;#8212; Maintainer<br /> * [mailto:rei4dan&amp;#x40;gmail&amp;#x2E;com Reinis Danne]<br /> === Lithuanian Translation ===<br /> * Andrius Štikonas<br /> * Deimantė Tankus (Diamond)<br /> * Jurgis Sūdžius (Dievas)<br /> * Lukas Gasiūnas (LucasLT)<br /> * Marius Tauba (morlock)<br /> * Raimundas Zabarauskas<br /> * Vytautas Šaltenis (rtfb)<br /> === Macedonian Translation ===<br /> * Dimitar Ilccov (Mythological)<br /> === Marathi Translation ===<br /> * [mailto:sujitrjadhav&amp;#x40;gmail&amp;#x2E;com सुजित जाधव] ([[User:sujitrjadhav|Sujit R Jadhav]])<br /> === Norwegian Translation ===<br /> * Asgeir Aakre (YbeRn00b)<br /> * Elias Nykrem (Bloodaxe) &amp;#8212; Maintainer<br /> * Erik J. Mesoy (Circon)<br /> * Gaute Jao (Gauteamus)<br /> * Hallvard Norheim Bø (Lysander)<br /> * Håvard Korsvoll<br /> * Pål Inge Larsen (PsyBird)<br /> * Susanne Mesoy (Rarlgland)<br /> === Old English Translation ===<br /> * [mailto:eirikvw&amp;#x40;aim&amp;#x2E;com Eirik Westcoat]<br /> * [mailto:axonfifty&amp;#x40;gmail&amp;#x2E;com Gottweiß]<br /> * [mailto:Majora700&amp;#x40;gmail&amp;#x2E;com Steven Panek] ([[User:Espreon|Espreon]]) &amp;#8212; Maintainer<br /> === Polish Translation ===<br /> * Adrian Pezda (Deidara)<br /> * Agata Chmiel<br /> * Arkadiusz Danilecki (szopen)<br /> * Bartek Waresiak (Dragonking)<br /> * Gabriela Waleńczak (Nalianora)<br /> * Jadwiga Bączkiewicz (Dwisia)<br /> * Jarom<br /> * Kamil Matuszewski (LiamTailor)<br /> * Karol Nowak (grzywacz)<br /> * Magdalena Chmiel (Ryouko)<br /> * Marek Kalnik (wdev)<br /> * Michał Hartliński<br /> * Michał Jedynak (Artanis)<br /> * Michał Ligowski (misiorysio)<br /> * Paweł Albecki (gidgnulur)<br /> * Paweł Jackowski (fatality)<br /> * Piotr Kruszewski (Hejnewar) &amp;#8212; Current maintainer<br /> * Piotr Makarewicz (ForPeace) &amp;#8212; Previous maintainer<br /> * Robert Wolniak (Szkodnix)<br /> * Roman Polesek (rimskij)<br /> * Sebastian Basierski<br /> * Tadeusz Kopeć<br /> * Zbigniew Banach (vonBureck)<br /> === Portuguese Translation ===<br /> * Carlos Sousa<br /> * Luis Passos<br /> * trewe &amp;#8212; Current maintainer<br /> === Portuguese (Brazil) Translation ===<br /> * Ambra Viviani Loos<br /> * Andrei Machado &amp;#8212; Current maintainer<br /> * Antonio Vildes Barbosa<br /> * Bruno Macabeus<br /> * Celso Goya<br /> * [mailto:cbterra&amp;#x40;gmail&amp;#x2E;com Claudio Terra]<br /> * Claus Aranha<br /> * Di Teixeira (Moroder)<br /> * Diego Inácio Goergen<br /> * [mailto:fred&amp;#x2E;maranhao&amp;#x40;gmail&amp;#x2E;com Fred Maranhão]<br /> * Hugo Neiva de Melo<br /> * Michel Loos<br /> * Renato Cunha<br /> * Ricardo Sodré Andrade<br /> * Romero Gonçalves<br /> * Sérgio de Miranda Costa<br /> * Tiago Souza (Salvador)<br /> === Romanian Translation ===<br /> * Unknown<br /> === Russian Translation ===<br /> * Aldarisvet &amp;#8212; Previous maintainer<br /> * [mailto:allryn&amp;#x40;pisem&amp;#x2E;net Aleksandr Aleks]<br /> * Alexandr Gridnev<br /> * Alexandr Menovchicov<br /> * Alexey Remizov<br /> * Alexey Zakharchenko<br /> * Andrey Tikhonov ([[User:tiandrey|tiandrey]])<br /> * Anthony Kolesov<br /> * Artem Khrapov ([[User:Kabachuha|kabachuha]]) &amp;#8212; Current maintainer<br /> * Azamat Hackimov ([[User:Winterheart|winterheart]])<br /> * [mailto:BabylonASАТyandexDОTru BabylonAS] ([[User:BabylonAS|BabylonAS]])<br /> * [[User:catbegemot|catbegemot]]<br /> * Danila Evstifeyev (MyOtheHedgeFox)<br /> * Denis Revin (Dut_Norshi)<br /> * Dmitry Brilev (dobryl)<br /> * Fardeil<br /> * Fedor Gavrilov (gallowzbird)<br /> * Fedor Khod'kov (teddy/fkhodkov)<br /> * Ilya Kaznacheev<br /> * Ilya Kotov<br /> * Ishayahu Lastov (Ishayahu)<br /> * Kirill Baranov<br /> * Mikhail Melnik (ZumZoom)<br /> * Nikita Ushkin<br /> * Roman Tuchin (Sankt)<br /> * Sergey Popov (loonycyborg)<br /> * Valentina Mukhamedzhanova (umirra)<br /> * Victor Sergienko (singalen)<br /> * [mailto:vicza&amp;#x40;zmail&amp;#x2E;ru Victor Zabavin]<br /> * Vlad Glagolev<br /> * Yellow Horror<br /> === Scottish Gaelic Translation ===<br /> * [mailto:fios&amp;#x40;foramnagaidhlig&amp;#x2E;net GunChleoc] &amp;#8212; Current maintainer<br /> === Serbian Translation ===<br /> * Branko Kokanovic (kokan)<br /> * [mailto:caslav&amp;#x2E;ilic&amp;#x40;gmx&amp;#x2E;net Caslav Ilic]<br /> * [mailto:daliborddjuric&amp;#x40;gmail&amp;#x2E;com Dalibor Djuric]<br /> * [mailto:sreckotoroman&amp;#x40;gmail&amp;#x2E;com Srecko Toroman] (FreeCraft)<br /> === Slovak Translation ===<br /> * Aceman<br /> * Ivan Kovacs<br /> * Ján Sučan (Bhujanga)<br /> * Marian Kluvanec<br /> * Martin Dzbor<br /> * Martin Plávala (Empy)<br /> * Michal Fusatý<br /> * [mailto:shoferek&amp;#x40;gmail&amp;#x2E;com Stanislav Hoferek] ([[User:Elven|Elven, Greenie knižnica]]) &amp;#8212; Current maintainer<br /> * [[User:Viliam|Viliam Bur]]<br /> === Slovenian Translation ===<br /> * Gregor Petrin<br /> * Jaka Kranjc (lynx)<br /> * Klemen Košir (nNa)<br /> * Matej Repinc<br /> === Spanish Translation ===<br /> * Alvin Eloy Luna Castro<br /> * Chucho Pulgoso<br /> * David Martínez Moreno<br /> * Diego Grande Rodríguez (Buhako)<br /> * Diego J.<br /> * Fernando Cerezal<br /> * Flamma<br /> * Francisco Muñoz (fmunoz)<br /> * Gabriel Rodríguez (Chewie)<br /> * [mailto:gusgins&amp;#x40;gmail&amp;#x2E;com Gustavo Gingins] (gins)<br /> * [mailto:shadowm2006&amp;#x40;gmail&amp;#x2E;com Iris Morelle] ([[User:Shadowm|Irydacea/shadowm]])<br /> * Iván Herrero (navitux)<br /> * Javier C.H. (perseo)<br /> * Jose Gordillo (kilder)<br /> * Jose Manuel Gomez (joseg)<br /> * Josu Díaz de Arcaya<br /> * Masacroso<br /> * Martín R. Dapás<br /> * Pedro Llorens (PeterPorty)<br /> * Roberto Romero (sildur)<br /> * Sebastián Lecchini (Sebas38760) &amp;#8212; current maintainer<br /> * Sergi March (sergi34)<br /> * [mailto:Majora700&amp;#x40;gmail&amp;#x2E;com Steven Panek] ([[User:Espreon|Espreon]])<br /> * [mailto:quianaaelonin&amp;#x40;gmail&amp;#x2E;com Víctor M. Estrada] (Aelonin/Darkmage)<br /> * Xavier Novella Sinde (XavierNovella)<br /> === Swedish Translation ===<br /> * Alex Alowersson &amp;#8212; current maintainer<br /> * Alexander Kjäll (capitol)<br /> * Andreas Tyrberg<br /> * Åse Petersson (tintin)<br /> * Elias Sevelin (aXidal)<br /> * Gustav Tiger<br /> * Hugo Gerlach (Entrimo)<br /> * Leo Danielson (Lugo Moll)<br /> * Niklas Bolmdahl<br /> * Stefan Bergström (tephlon)<br /> * [mailto:susanna&amp;#x2E;bjorverud&amp;#x40;telia&amp;#x2E;com Susanna Björverud] (sanna)<br /> * Ulrika Uddeborg<br /> * wint3r<br /> === Turkish Translation ===<br /> * Ali Erdem Karaçay(Arsivnet)<br /> * Enes Akın (yekialem)<br /> * İhsan Akın<br /> * Kosif<br /> * Nilgün Belma Bugüner<br /> * Pınar Yanardağ (moonquelle)<br /> * Selim Farsakoğlu<br /> === Ukrainian Translation ===<br /> * Anton Okhrimenko (AncientGeneral)<br /> * Andrii Serbovets (archdron)<br /> * ForestDragon<br /> * [mailto:mansonigor&amp;#x40;gmail&amp;#x2E;com Igor Paliychuk]<br /> * igorko<br /> * Oleksii Okhrimenko (lexa04)<br /> * [mailto:arobson&amp;#x40;yandex&amp;#x2E;ru robson] ([[User:Robson|Robson]])<br /> * Sergiy Tkach (Apromix)<br /> * singalen<br /> === Valencian (southern Catalan) Translation ===<br /> * Bernardo Arlandis<br /> * Robert Millan<br /> * Tomás Roig<br /> === Vietnamese Translation ===<br /> * Huynh Yen Loc<br /> * Le Ngoc Nguyen Chinh<br /> * Pham Hoang Duy<br /> * Pham Thanh Nam<br /> * Pham Thi Yen<br /> === Welsh Translation ===<br /> * Adam Pearce &amp;#8212; current maintainer<br /> === RACV’s Translation ===<br /> * Mario Rodríguez (Mavorte)<br /> == Descent Into Darkness ==<br /> === Original Campaign Design ===<br /> * esci<br /> === Latest Campaign Revision ===<br /> * nemaara<br /> === Artwork and Graphics Design ===<br /> * Blarumyrran &amp;#8212; story images<br /> * Emilien Rotival (LordBob) &amp;#8212; current portraits<br /> * theycallmerooster &amp;#8212; old portraits<br /> === Miscellaneous ===<br /> * josteph &amp;#8212; dialogue comments and revisions<br /> == The South Guard ==<br /> === Newest Campaign Version Rewrite ===<br /> * Dalas<br /> === Campaign Design ===<br /> * nemaara<br /> * William Carey (aelius) &amp;#8212; original campaign design<br /> === Campaign Maintenance ===<br /> * Dalas &amp;#8212; current maintainer<br /> * nemaara<br /> * Lari Nieminen (zookeeper)<br /> * Eric S. Raymond (ESR)<br /> * Wintermute<br /> === Artwork and Graphics Design ===<br /> * J.W. Bjerk (eleazar)<br /> * Kathrin Polikeit (Kitty) &amp;#8212; portraits<br /> * Lari Nieminen (zookeeper)<br /> * Scavenger &amp;#8212; new story images and Mal M'Brin portrait<br /> * rhyging5<br /> * Shadow<br /> * William Carey (aelius)<br /> == Winds of Fate ==<br /> === Authors ===<br /> * Jeffrey ‘Sigurd’ Westcoat (SigurdFireDragon)<br /> * Jonathan Kelly (name)<br /> === Graphics ===<br /> * Emilien Rotival (LordBob) &amp;#8212; story artwork<br /> * Lukasz Wawrowski (inferno8) &amp;#8212; storm wisp unit sprite and attack icons from Era of Magic<br /> * L. Shelby (velensk) &amp;#8212; stymphalian unit sprite from Era of Four Moons campaign<br /> * Lari Nieminen (zookeeper) &amp;#8212; journey map<br /> * Vincent Langner (Vyncyn) &amp;#8212; caravel unit sprite from Rashy Era<br /> === Alpha Testing ===<br /> * almkglor<br /> * Argesilao2<br /> * benkenobiwan<br /> * Cosmic<br /> * Hejnewar<br /> * IceTyp<br /> * josteph<br /> * Konrad2<br /> * Lord-Knightmare<br /> * Mirion147<br /> * octalot<br /> * Whiskeyjack<br /> === Based on Wings of Victory by: ===<br /> * Eric S. Raymond (esr)<br /> * Fabi/Fendrin<br /> == Northern Rebirth ==<br /> === Campaign Design ===<br /> * Taurus<br /> === Artwork and Graphics Design ===<br /> * Battlesquid<br /> * Nicholas Kerpan (Thrawn)<br /> * Richard Kettering (Jetrel)<br /> * Xandar86<br /> === Prose and Story Editing ===<br /> * Eric S. Raymond (ESR) &amp;#8212; prose, grammar, and WML assistance<br /> * Nathanel K. Stottlemyer (ShadowOfHassen) &amp;#8212; dialogue and narration revisions<br /> === Code and Translation Assistance ===<br /> * David Philippi (Torangan)<br /> * Scott Klempner<br /> === Campaign Maintenance ===<br /> * Charles Dang (vultraz)<br /> == The Rise Of Wesnoth ==<br /> === Campaign Design ===<br /> * James Spencer (Shade)<br /> === Campaign Maintenance ===<br /> * Dimitar Ilccov (Mythological)<br /> * Lari Nieminen (zookeeper) &amp;#8212; former maintainer<br /> * Scott Klempner<br /> === Artwork and Graphics Design ===<br /> * Blarumyrran &amp;#8212; the new Vampire Lady sprite<br /> * J.W. Bjerk (eleazar)<br /> * Lari Nieminen (zookeeper)<br /> * Emilien Rotival (LordBob) &amp;#8212; new portraits and story art<br /> * Michael Gil de Muro (grp21) &amp;#8212; old portraits<br /> * pixelmind &amp;#8212; Shek’kahan portrait<br /> === WML Contributors ===<br /> * Iris Morelle (Irydacea/shadowm)<br /> * Lari Nieminen (zookeeper)<br /> == Under the Burning Suns ==<br /> === Campaign Design ===<br /> * Asa Swain<br /> * Piotr Cychowski (Mist/cycholka)<br /> === Campaign Maintenance ===<br /> * Iris Morelle (Irydacea/shadowm)<br /> * Jan Rietema (Rhuvaen)<br /> * Lari Nieminen (zookeeper)<br /> * Piotr Cychowski (Mist/cycholka)<br /> * Simon Forsyth (Alarantalara)<br /> * Steven Panek (Espreon)<br /> === Artwork and Graphics Design ===<br /> * Dan Gerhards (beetlenaut) &amp;#8212; new Flesh Golem sprites<br /> * Kwandulin &amp;#8212; New Kaleh and Nym sprites<br /> * doofus-01 &amp;#8212; Monster Crab sprite<br /> * Hogne Haskjold (Frame)<br /> * Iris Morelle (Irydacea/shadowm)<br /> * J.W. Bjerk (Eleazar)<br /> * James Woo (Pickslide)<br /> * Javier Hoyos (Vendanna)<br /> * Marcus Rosén (sleepwalker) &amp;#8212; Dark Assassin sprite and animations<br /> * Mark Goodenough (Ranger M)<br /> * Mikolaj Machowski (Emdot)<br /> * Murray Cook (Zhukov)<br /> * Peter Geinitz (Shadow)<br /> * Richard Kettering (Jetrel)<br /> * Sangel<br /> * Samuel Wilson (megane)<br /> * Scott Klempner<br /> * Vincent Langner (Vyncyn) &amp;#8212; Spider Lich and Human Commander sprites<br /> * Zerovirus &amp;#8212; Naga Hunter sprite<br /> === Miscellaneous ===<br /> * Fabian Müller (Fabi/Fendrin)<br /> * Mark Polo<br /> * Matthias Schoeck (mattsc) &amp;#8212; Messenger AI<br /> * Isaac<br /> * Ringcaat (Thorin N. Tatge)<br /> * And special thanks to everyone else who I forgot to mention.<br /> == Dead Water ==<br /> === Campaign design and programming ===<br /> * Dan Gerhards (beetlenaut)<br /> === Script-doctoring and cleanup for mainline ===<br /> * Eric S. Raymond (ESR)<br /> === Artwork ===<br /> * Kathrin Polikeit (Kitty) &amp;#8212; Portraits for brawler, Kai Krellis, Gwabbo, and Caladon<br /> * Justin Nichols (JustinOperable) &amp;#8212; Portrait for Cylanna<br /> * Zerovirus &amp;#8212; Kai Krellis sprites<br /> * Francisco Muñoz (fmunoz) &amp;#8212; Attack icons<br /> == Dusk of Dawn ==<br /> === Author ===<br /> * GreenScarab<br /> === Prose and Story Editing, Code Preparation ===<br /> * Dalas<br /> === Art - Sprites ===<br /> * GreenScarab &amp;#8212; Stone Golem, Troll Earth-Shaker and Troll Initiate sprites<br /> === Wild and Beast Saurian Sprites ===<br /> * Skizzaltix, Faehen Era, add-ons server 1.2<br /> === Text Proofreading ===<br /> * Konrad2<br /> === WML Assistance ===<br /> * Refumee<br /> === Beta Testing ===<br /> * Refumee<br /> == Legend of Wesmere ==<br /> === Creator and Lead Designer ===<br /> * [mailto:moka1&amp;#x40;otenet&amp;#x2E;gr Spiros, George and Alexander Alexiou] ([[User:Santi|Santi/fnaek]]) &amp;#8212; Main designers, former maintainers.<br /> === Campaign Maintenance ===<br /> * Fabi/Fendrin &amp;#8212; Former maintainer<br /> * Spiros, George and Alexander Alexiou (Santi/fnaek)<br /> === Prose-doctoring and adaptation for mainline ===<br /> * Eric S. Raymond (esr)<br /> * Fabi/Fendrin &amp;#8212; Major WML rewrite for mainline<br /> === WML Assistance ===<br /> * Alexander van Gessel (AI/AI0867) &amp;#8212; bugfixing and general WML cleanups<br /> * Iris Morelle (Irydacea/shadowm) &amp;#8212; for A LOT of help with WML and interesting campaign suggestions<br /> * Lari Nieminen (zookeeper) &amp;#8212; for A LOT of help with WML<br /> === Artificial Intelligence ===<br /> * Yurii Chernyi (crab) &amp;#8212; coding of the new ai and help with corresponding redesigns<br /> === Graphics ===<br /> * Bora Orcal (bera) &amp;#8212; goblin horn rouser<br /> * Kathrin Polikeit (Kitty) &amp;#8212; who did a great job with portraits and other graphics<br /> -the main reason for having a polished campaign<br /> * Steven Panek (Espreon) &amp;#8212; map artist<br /> === Additional thanks to ===<br /> * Scott &amp;#8212; for help with WML, especially the use of store/unstore<br /> * WhiteWizard &amp;#8212; Initial porting to 1.2<br /> * Disto &amp;#8212; for elvish units<br /> * RedLTeut &amp;#8212; for great improvements to the initial invisible elvish units<br /> * Dacyn &amp;#8212; who was of great help in the beginning of this project<br /> * Big Bad Joe<br /> * breversa<br /> * Invisible Philosopher<br /> * js138<br /> * l'ultimo cruco<br /> * Mad Max<br /> * Rhuvaen<br /> * SelfishWeirdo<br /> * Scott<br /> * Sly<br /> * Teldar<br /> * Turin<br /> * And the rest of the Wesnoth community for feedback,<br /> criticism, help with WML code and graphics.<br /> == Son Of The Black Eye ==<br /> === Campaign Design ===<br /> * Benjamin Drieu (Benj) &amp;#8212; conception and original design<br /> * Taurus &amp;#8212; completion<br /> === Current Campaign Maintainer ===<br /> * Tahsin Jahin Khalid (Lord-Knightmare)<br /> === Campaign Maintainers (former) ===<br /> * Lari Nieminen (zookeeper)<br /> * Taurus<br /> === Prose, Grammatical and WML Assistance ===<br /> * Eric S. Raymond (ESR)<br /> === Artwork and Graphics ===<br /> * Christian Sirviö (Girgistian) &amp;#8212; portraits (sketches)<br /> * Phil Barber (thespaceinvader) &amp;#8212; portraits (coloring)<br /> * Sonny T Yamada (SkyOne) &amp;#8212; Sprite animations (defense and magic) of orcish shamans<br /> == Eastern Invasion ==<br /> === Newest Campaign Version Rewrite ===<br /> * Dalas<br /> === Original Campaign Design ===<br /> * Joseph Simmons (turin)<br /> === Prose and Story Editing, Code Preparation ===<br /> * nemaara<br /> === Artwork and Graphics Design ===<br /> * Aaron Redfern (A-Red) &amp;#8212; New Owaec sprites<br /> * Emilien Rotival (LordBob) &amp;#8212; new portraits<br /> * James Woo (Pickslide) &amp;#8212; old portraits<br /> * Neoriceisgood<br /> === Campaign Redesign Playtesters ===<br /> * Konrad2<br /> * Lord-Knightmare<br /> * Toranks<br /> === Campaign Maintenance ===<br /> * Dalas<br /> * Thewodoros<br /> === Previous Campaign Maintenance ===<br /> * Dimitar Ilccov (Mythological)<br /> * Lari Nieminen (zookeeper)<br /> * Astrid Halberkamp<br /> === Others ===<br /> * Eric S. Raymond (ESR)<br /> * Loci<br /> == Liberty ==<br /> === Original Campaign Design ===<br /> * Scott Klempner<br /> === Latest Rewrite ===<br /> * nemaara<br /> === Campaign Maintenance ===<br /> * Lari Nieminen (zookeeper)<br /> * Eric S. Raymond (ESR) &amp;#8212; Original prose-doctoring and preparation for mainline<br /> === Artwork and Graphics Design ===<br /> * Brendan Sellner<br /> * Kathrin Polikeit (Kitty) &amp;#8212; portraits<br /> * Shadow<br /> * Blarumyrran &amp;#8212; story images, Rogue Mage line sprites<br /> * Sonny T Yamada (SkyOne) &amp;#8212; Sprite animations (defense and attack) of Rogue Mage line<br /> * Dalas &amp;#8212; Modifying Harper's portrait<br /> == Secrets of the Ancients ==<br /> === Campaign Design, Programming, and Artwork ===<br /> * Dan Gerhards (beetlenaut)<br /> === Campaign Maintenance ===<br /> * Jeffrey ‘Sigurd’ Westcoat (SigurdFireDragon) &amp;#8212; former maintainer<br /> === Additional Artwork ===<br /> * Wussel &amp;#8212; Some improvements to the ship.<br /> == Sceptre of Fire ==<br /> === Campaign Design ===<br /> * Joseph Simmons (turin)<br /> === Campaign Maintenance ===<br /> * Lari Nieminen (zookeeper)<br /> * doofus-01<br /> * nemaara<br /> === WML Assistance ===<br /> * David Simmons (Dacyn)<br /> * Eli Dupree (Elvish Pillager)<br /> * Lari Nieminen (zookeeper)<br /> * MadMax<br /> === Artwork and Graphics Design ===<br /> * Asereje<br /> * Blarumyrran &amp;#8212; the new Dwarvish Miner sprite<br /> * Emilien Rotival (LordBob) &amp;#8212; new portraits<br /> * James Woo (Pickslide) &amp;#8212; old portraits<br /> * John-Robert Funck (XJaPaN)<br /> * JonasNL &amp;#8212; Dwarvish Miner attack and defense animations<br /> * Peter Geinitz (Wayfarer)<br /> * Pixelmind &amp;#8212; Khrakrahs portrait<br /> * Richard Kettering (Jetrel)<br /> * RusHHouR &amp;#8212; old gold and coal piles<br /> * doofus-01<br /> == Two Brothers ==<br /> === Campaign Design ===<br /> * Eric J. Mesoy (Circon)<br /> * Nils Kneuper (Ivanovic)<br /> === Prose and Story Edits ===<br /> * Eric S. Raymond (esr)<br /> * A-Red<br /> === Campaign Maintenance ===<br /> * Nils Kneuper (Ivanovic)<br /> * Charles Dang (vultraz)<br /> === Artwork and Graphics Design ===<br /> * Arkadiusz Danileki (szopen)<br /> * Kathrin Polikeit (Kitty) &amp;#8212; current portraits<br /> * MadMax<br /> * Stefan<br /> === Miscellaneous ===<br /> * Bartek Waresiak (Dragonking)<br /> * Christoph Berg (chrber)<br /> * Daravel<br /> * Jozrael<br /> * And special thanks to everyone else who I forgot to mention.<br /> == Heir To The Throne Classic ==<br /> === Campaign Design ===<br /> * David White (Sirp)<br /> === Campaign Maintenance ===<br /> * Dimitar Ilccov (Mythological)<br /> * Lari Nieminen (zookeeper) &amp;#8212; former maintainer<br /> * Scott Klempner<br /> === Artwork and Graphics Design ===<br /> * doofus-01 &amp;#8212; new sprites and animations (Princess, Battle Princess, Dark Queen, Sea Orc)<br /> * Emilien Rotival (LordBob) &amp;#8212; portraits (Delfador, Asheviere, Moremirmu)<br /> * Francisco Muñoz (fmunoz)<br /> * Kathrin Polikeit (Kitty) &amp;#8212; portraits (Konrad, Li'sar, Kalenz, Chantal)<br /> * Neoriceisgood<br /> * Richard Kettering (Jetrel)<br /> === Miscellaneous ===<br /> * Patrick Parker (Sapient) &amp;#8212; WML assistance<br /> == The Deceivers Gambit ==<br /> === Campaign Design ===<br /> * Dalas<br /> === Setting and Story ===<br /> * nemaara<br /> === Miscellaneous Graphics ===<br /> * inferno8<br /> * Maksiu<br /> * Mechanical<br /> == Heir To The Throne ==<br /> === Campaign Design ===<br /> * Dalas<br /> === Artwork and Graphics Design ===<br /> * doofus-01 &amp;#8212; new sprites and animations (Princess, Battle Princess, Dark Queen, Sea Orc)<br /> * Emilien Rotival (LordBob) &amp;#8212; portraits (Delfador, Asheviere, Moremirmu)<br /> * Francisco Muñoz (fmunoz)<br /> * Kathrin Polikeit (Kitty) &amp;#8212; portraits (Konrad, Li'sar, Kalenz, Chantal)<br /> * Neoriceisgood<br /> * Richard Kettering (Jetrel)<br /> === Miscellaneous ===<br /> * Patrick Parker (Sapient) &amp;#8212; WML assistance<br /> == The Hammer of Thursagan ==<br /> === Author ===<br /> * Eric S. Raymond (esr)<br /> === Special Guest Designer ===<br /> * Taurus<br /> === Art ===<br /> * Kim Holm (DUHH)<br /> * Phil Barber (thespaceinvader)<br /> * Vincent Langner (Vyncyn) &amp;#8212; New Dwarvish Witness line sprites and animations<br /> === Brainstorming, playtesting, and spousal support ===<br /> * Cathy O. Raymond<br /> === Campaign Maintenance ===<br /> * Charles Dang (vultraz)<br /> [[Category:Generated]]</div>

Pentarctagon https://wiki.wesnoth.org/index.php?title=Template:DevDownload&diff=74625 2025-11-11T00:55:56Z

<p>Pentarctagon: </p> <hr /> <div>&lt;noinclude&gt;<br /> == Development (1.19 branch) ==<br /> &lt;/noinclude&gt;<br /> ==== Windows (10 1903 and later) {{{4|}}} ====<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.17 | filename=wesnoth-1.19.17-win64.exe |<br /> hash=3043cf6db1dcd17c341ee8af7d625a9d561cc06fbf091297a0aa6d3f413b21bb}}<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.16 | filename=wesnoth-1.19.16-win64.exe |<br /> hash=4b52b3546c9c0d625058b60b018c967fdb793a04cf4700bc18388bb97f174907}}<br /> <br /> ==== macOS (10.13 and later) {{{5|}}} ====<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.17 | filename=Wesnoth_1.19.17.dmg |<br /> hash=0216cd5837af30de1b072d325d11477fa8a1409b22e9fc3ebf46fcc78b8f10b2}}<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.16 | filename=Wesnoth_1.19.16.dmg |<br /> hash=730ddcf8b7f4d0cafa6bf924598528ff1e71e152d91dc3d8e9974e62a93bb8b8}}<br /> <br /> ==== Source code ====<br /> * [https://github.com/wesnoth/wesnoth/blob/master/INSTALL.md Compiling Wesnoth] - How to compile the source code<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.17 | filename=wesnoth-1.19.17.tar.bz2 |<br /> hash=7a4f65b3bd845fc923a8f745591062061f5f72cedd4f81edb93e42b8e6b162ea}}<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.16 | filename=wesnoth-1.19.16.tar.bz2 |<br /> hash=280c24868b19148278e3dd2604efecdf93b376f2652823453abafb55e94d0130}}</div>

Pentarctagon https://wiki.wesnoth.org/index.php?title=InterfaceActionsWML&diff=74624 2025-11-10T17:18:21Z

<p>Pentarctagon: /* [sound_source] */</p> <hr /> <div>{{WML Tags}}<br /> == Interface actions ==<br /> <br /> Part of [[ActionWML]], interface actions are actions that do not have a direct effect on gameplay;<br /> instead, they show something to the player. The main interface tags<br /> are '''[message]''' and '''[objectives]''', but several other tags affect<br /> the interface also.<br /> <br /> == [inspect] ==<br /> This user interface instantly displays the gamestate inspector dialog at the current scenario state (the same one that can be brought up with [[CommandMode|the ''':inspect''' command]]), which can be used to inspect the values of WML variables, AI configuration, recall lists, and more.<br /> <br /> * '''name''': optional attribute to specify the name of this gamestate inspector dialog. It is just a label to help differentiate between different invocations of gamestate inspector dialog.<br /> <br /> == [message] ==<br /> The most commonly used interface action is [message], which displays a message to the user in a dialog box. It can also be used to take input from the user.<br /> <br /> The following key/tags are accepted for [message]:<br /> * [[StandardUnitFilter]]: The unit whose profile and name are displayed. Do not use a [filter] tag. If no unit matching this filter is found, the message is not displayed (The unit has probably been killed).&lt;br&gt;[message] elements should be constructed so that it is either guaranteed that a certain unit is alive, or so that dialog flows smoothly even if the message isn't displayed.<br /> <br /> * '''speaker''': an alternative to standard unit filter. You may specify as the value of the speaker attribute a unit id or any of the following special values:<br /> ** '''narrator''': the dialog box is displayed without a caption for the unit speaking or a unit image<br /> ** '''unit''': the primary unit for the event is speaking<br /> ** '''second_unit''': the secondary unit for the event is speaking<br /> <br /> * '''message''': (translatable) the text to display to the right of the image. ''message'' is sometimes multiple lines; if it is, be sure to use quotes(''' ' ''' or ''' &quot; ''')<br /> * '''male_message''', '''female_message''': {{DevFeature1.13|2}} (translatable) Used instead of ''message'' if the unit's gender matches. Never used if there is no unit (ie ''speaker=narrator''). {{DevFeature1.13|6}} This matches the primary unit, not the secondary unit.<br /> * '''wait_description''': {{DevFeature1.13|2}} the description of this message displayed when other players in a mp game wait for one player doing input in a [message] (with [option]s or [text_input]).<br /> * '''[show_if]''': if present then this message will only be displayed if the conditional statement in this tag is passed (see [[ConditionalActionsWML#Condition_Tags|ConditionalActionsWML]])<br /> * '''side_for''': (default: all sides) comma-separated list of sides for who message is shown. This will &lt;b&gt;not&lt;/b&gt; work with messages that take user input ([option]/[text_input]), which can only ever be shown to the current player. {{DevFeature1.13|0}} side_for= is now also accepted for messages with user input, it specifies on which side the message is shown (defaults to the currently playing side). For messages with input it does not accept a comma seperated list only a single number.<br /> * '''image''': (default: profile image of speaker) the image to display to the left of the message text. Append ~RIGHT() if you want the image to appear on the right side. <br /> ** {{DevFeature1.13|0}} &lt;b&gt;none:&lt;/b&gt; display no image<br /> * '''mirror''': {{DevFeature1.13|5}} whether to mirror the image specified by the '''image''' attribute.<br /> * '''second_image''': {{DevFeature1.13|6}} same as the '''image''' attribute, but the image is displayed on the right of the message text. {{DevFeature1.17|7}} not working anymore {{DevFeature1.19|9}} working again<br /> * '''second_mirror''': {{DevFeature1.13|6}} same as '''mirror''', but for the '''second_image''' attribute.<br /> * '''image_pos''': {{DevFeature1.13|5}} whether to show the image on the left or right; supercedes the use of ~RIGHT() described above<br /> * '''caption''': (default: name of speaker) the caption to display beside the image. Name to be displayed. Note: use a translation mark to avoid wmllint errors.<br /> * '''scroll''': Boolean specifying whether the game view should scroll to the speaking unit. Defaults to ''yes''.<br /> * '''highlight''': {{DevFeature1.13|5}} Boolean specifying whether to highlight the speaker. Defaults to ''yes''.<br /> * '''sound''': a sound effect (wav file) to play as the message is displayed. This can be a comma-separated list, from which one will be randomly chosen.<br /> * '''voice''', '''male_voice''', '''female_voice''': {{DevFeature1.13|?}} a sound to be played as the message is displayed. This can also be a comma-separated list, from which one will be randomly chosen. This is intended for voiceovers for the message. The gendered forms are applied the same as for '''message'''. They are never used when the speaker is the narrator - only '''voice''' is used in that case.<br /> * {{anchor|message-option|'''[option]'''}}: No '''[option]''' elements have to be used. If '''[option]''' elements are present, then each option will be displayed in a menu for the user to select one option. ''Note: Messages with options will not be shown at all in prestart events''<br /> ** '''message''': (translatable) the text displayed for the option. {{DevFeature1.15|1}} This is now a synonym for '''description='''.<br /> ** '''image''', '''label''', '''description''', '''default''': See [[DescriptionWML#WML_Format|DescriptionWML]].<br /> ** '''value''': {{DevFeature1.13|?}} Gives the option a value to be stored in a variable.<br /> ** '''[show_if]''': if present then this option will only be displayed if the conditional statement in this tag is passed (see [[ConditionalActionsWML#Condition_Tags|ConditionalActionsWML]])<br /> ** '''[command]''': an element containing actions which are executed if the option is selected.<br /> * '''variable''': {{DevFeature1.13|?}} If present, either the index or the value of the chosen option will be stored in the specified variable. Option indexing starts from 1. If option has '''[show_if]''' condition evaluated as false, then it is hidden and excluded from the indexing.<br /> * {{anchor|message-text_input|'''[text_input]'''}}: there can be only one [text_input] tag. this adds a text input field to the message. ''Note: Messages with text_input will not be shown at all in prestart events''<br /> ** '''variable''': the variable that the user's input will be written to<br /> ** '''label''': a text label to the left of the input field<br /> ** '''max_length''': the maximum number of characters that may be typed into the field<br /> ** '''text''': text that is written into the field in the beginning<br /> * Check [[EventWML#Multiplayer_safety]] to find out in which events you can safely use '''[option]''' and '''[text_input]''' without causing OOS.<br /> <br /> === Formatting ===<br /> '''[message]''' and other tags such as unit names (user_description), objectives, and floating text can make use of [https://docs.gtk.org/Pango/pango_markup.html#pango-markup Pango markup formatting codes].<br /> <br /> Prefer to use single quotes (') instead of double quotes (&quot;) within the formatting string, as double quotes would need to be escaped in WML (&quot;&quot;). Escaping markup can be done with [https://github.com/wesnoth/wesnoth/blob/9daa10a9f27c5a95520e871417bbd72aa52aa688/src/font/pango/escape.hpp#L38-L42 HTML entities].<br /> <br /> For example, if you wanted to write &quot;You are victorious!&quot; in large, italic, gold letters, you might write it this way:<br /> <br /> &lt;nowiki&gt;&lt;span color='#BCB088' size='large' font-style='italic'&gt;You are victorious!&lt;/span&gt;&lt;/nowiki&gt;<br /> <br /> <br /> These are the codes taken from the Pango markup formatting guide:<br /> <br /> *'''font''', '''font_desc''': A font description string, such as &quot;Sans Italic 12&quot;.<br /> *'''font_family''', '''face''': A font family name.<br /> *'''font_size''', '''size''': Font size in 1024ths of a point, or one of the absolute sizes 'xx-small', 'x-small', 'small', 'medium', 'large', 'x-large', 'xx-large', or one of the relative sizes 'smaller' or 'larger'.<br /> *'''font_style''', '''style''': One of 'normal', 'oblique', 'italic'.<br /> *'''font_weight''', '''weight''': One of 'ultralight', 'light', 'normal', 'bold', 'ultrabold', 'heavy', or a numeric weight.<br /> *'''font_variant''', '''variant''': One of 'normal' or 'smallcaps'.<br /> *'''font_stretch''', '''stretch''': One of 'ultracondensed', 'extracondensed', 'condensed', 'semicondensed', 'normal', 'semiexpanded', 'expanded', 'extraexpanded', 'ultraexpanded'.<br /> *'''foreground''', '''fgcolor''', '''color''': An RGB color specification such as '#00FF00' or a color name such as 'red'. The full list of color names may be found in Pango's [https://github.com/GNOME/pango/blob/main/tools/rgb.txt rgb.txt] file.<br /> *'''background, bgcolor''': An RGB color specification such as '#00FF00' or a color name such as 'red'.<br /> *'''underline''': One of 'none', 'single', 'double', 'low', 'error'.<br /> *'''underline_color''': The color of underlines; an RGB color specification such as '#00FF00' or a color name such as 'red'.<br /> *'''rise''': Vertical displacement, in 10000ths of an em. Can be negative for subscript, positive for superscript.<br /> *'''strikethrough''': 'true' or 'false' whether to strike through the text.<br /> *'''strikethrough_color''': The color of strikethrough lines; an RGB color specification such as '#00FF00' or a color name such as 'red'<br /> *'''fallback''': 'true' or 'false' whether to enable fallback. If disabled, then characters will only be used from the closest matching font on the system. No fallback will be done to other fonts on the system that might contain the characters in the text. Fallback is enabled by default. Most applications should not disable fallback.<br /> *'''letter_spacing''': Inter-letter spacing in 1024ths of a point.<br /> *'''gravity''': One of 'south', 'east', 'north', 'west', 'auto'.<br /> *'''gravity_hint''': One of 'natural', 'strong', 'line'.<br /> <br /> The following pango attributes are also available directly as attributes of the '''[message]''' tag:<br /> {{DevFeature1.13|4}}<br /> <br /> *'''font'''<br /> *'''font_family'''<br /> *'''font_size'''<br /> *'''font_style'''<br /> *'''font_weight'''<br /> *'''font_variant'''<br /> *'''font_stretch'''<br /> *'''color'''<br /> *'''bgcolor'''<br /> *'''underline'''<br /> *'''underline_color'''<br /> *'''rise'''<br /> *'''strikethrough'''<br /> *'''strikethrough_color'''<br /> *'''fallback'''<br /> *'''letter_spacing'''<br /> *'''gravity'''<br /> *'''gravity_hint'''<br /> <br /> == [objectives] ==<br /> The other tag used for plot development is '''[objectives]'''.<br /> The '''[objectives]''' tag overwrites any previously set objectives,<br /> and displays text which should describe the objectives of the scenario.<br /> Scenario objectives are displayed on the player's first turn after the tag is used,<br /> or as part of the event if it triggers during that player's turn.<br /> Objectives can also be accessed at any time in a scenario using the<br /> &quot;Scenario Objectives&quot; game menu option, making this tag useful for<br /> scenario-specific information that the player may need to refer to during play.<br /> <br /> Attributes of '''[objectives]''':<br /> * '''side''': Default '0'. The side to set the objectives for. A value of 0 sets objectives for all sides. note: There are side-specific objectives and default objectives, which are used in case a side doesn't have specific ones. Specifying 0 sets the default ones.<br /> * '''[[StandardSideFilter]]''' tags and keys: Sets the objectives of all matching sides to these passed specifications (the rest of this [objectives] tag). If no sides (such as when passing side=0) or all sides match, sets the default objectives, and the side specific ones for the matching sides otherwise.<br /> * '''bullet''': Default '• '. Replaces the default bullet, with whatever is passed, for all objectives, gold carryover notes, and notes defined with [note].<br /> * '''summary''': Displayed first in the objectives text, this should describe the basic objective for the overall scenario. Can be omitted.<br /> * '''note''': Displayed last in the objectives text, this is sometimes used for hints or additional information. Can be omitted.<br /> * '''victory_string''': Default ' _ &quot;Victory:&quot;', this text precedes the victory objectives. Can be set to &quot;&quot; too.<br /> * '''defeat_string''': Default ' _ &quot;Defeat:&quot;', this text precedes the defeat objectives. Can be set to &quot;&quot; too.<br /> * '''gold_carryover_string''': Default ' _ &quot;Gold carryover:&quot;', this text precedes the gold carryover information.<br /> * '''notes_string''': Default ' _ &quot;Notes:&quot;', this text precedes the notes.<br /> * '''silent''': Default: not present. If set to &quot;yes&quot;, the objectives are silently changed. Else, they will be shown to the user when appropriate.<br /> * '''delayed_variable_substitution''': {{DevFeature1.13|8}} If set to yes, any variables or [insert_tag] are not substituted right away. Instead, they are substituted whenever the objectives are actually viewed.<br /> <br /> Tags of '''[objectives]''':<br /> * {{anchor|objectives-objective|'''[objective]'''}}: describes a win or loss condition. Most scenarios have multiple win or loss conditions, so use a separate [objective] subtag for each line; this helps with translations.<br /> ** '''bullet''': Default '• ' or whatever is set in the parent [objectives] block. Replaces the default bullet, with whatever is provided, for the objective defined by the [objective] block.<br /> ** '''red''': Default '0' for winning objectives, '255' for losing objectives. Overrides the default red coloring of the entire objective, including the bullet.<br /> ** '''green''': Default '255' for winning objectives, '0' for losing objectives. Overrides the default green coloring of the entire objective, including the bullet.<br /> ** '''blue''': Default '0'. Overrides the default blue coloring of the entire objective, including the bullet.<br /> ** '''description''': text for the specific win or loss condition.<br /> ** '''caption''': a text which will be displayed above the ''description''. This can be used to display a subcategory of objectives below ''victory_string'' or ''defeat_string''.<br /> ** '''condition''': The color and placement of the text. Values are 'win'(colored green, placed after ''victory_string'') and 'lose'(colored red, placed after ''defeat_string'').<br /> ** '''show_turn_counter''': If set to yes, displays the number of turns remaining in the scenario. Default is no.<br /> ** '''[show_if]''': A condition that disables the objective if it doesn't hold. Conditional objectives are refreshed at '''[show_objectives]''' time only, or when manually opening the scenario objectives.<br /> * {{anchor|objectives-gold_carryover|'''[gold_carryover]'''}}: describes how the gold carryover works in this scenario. This is intended to be a more convenient way of displaying carryover information than using the note= key in [objectives].<br /> ** '''bullet''': Default '• ' or whatever is set in the parent [objectives] block. Replaces the default bullet with whatever is provided.<br /> ** '''red''': Default '255'. Overrides the default red coloring of the entire objective, including the bullet.<br /> ** '''green''': Default '255'. Overrides the default green coloring of the entire objective, including the bullet.<br /> ** '''blue''': Default '192'. Overrides the default blue coloring of the entire objective, including the bullet.<br /> ** '''bonus''' (boolean): whether an early finish bonus is granted. If omitted, early finish bonus is not mentioned.<br /> ** '''carryover_percentage''': the amount of carryover gold. If omitted, the amount is not mentioned.<br /> ** '''[show_if]''': {{DevFeature1.13|11}} Gold carryover will not be shown if the specified condition isn't met. Conditional gold carryover is refreshed at '''[show_objectives]''' time only.<br /> * {{anchor|objectives-note|'''[note]'''}}: describes a note, usually used for hints or additional information. This is an easier way of adding several notes than concatenating them together into a single string to use with the ''note='' key.<br /> ** '''bullet''': Default '• ' or whatever is set in the parent [objectives] block. Replaces the default bullet with whatever is provided for the note defined by the [note] block.<br /> ** '''red''': Default '255'. Overrides the default red coloring of the entire note, including the bullet.<br /> ** '''green''': Default '255'. Overrides the default green coloring of the entire note, including the bullet.<br /> ** '''blue''': Default '255'. Overrides the default blue coloring of the entire note, including the bullet.<br /> ** '''description''': the text of the note.<br /> ** '''[show_if]''': The note will not be shown if the specified condition isn't met. Conditional notes are refreshed at '''[show_objectives]''' time only.<br /> <br /> == [set_menu_item] ==<br /> This tag is used to add a custom option in the right-click context menu which can then be used to trigger arbitrary WML commands. The menu items can be set and modified during any event, for example during &quot;start&quot; or &quot;prestart&quot; events. The user can also assign hotkeys to these WML commands unless specified otherwise. When the hotkey is pressed the event will be fired/filtered at the current mouse position.<br /> <br /> '''Note:''' Due to limitations in portable devices where there are no scroll bars for context menus, there is a hard-coded limit of 7 custom WML menu items. If you really need to have more than 7 menu items, try combining some of them in a submenu. {{DevFeature1.13|0}} This limitation is being removed in a [http://forums.wesnoth.org/viewtopic.php?p=572554#p572554 future version] of Wesnoth.<br /> <br /> * '''id''': the unique id for this menu item. If a menu item with this id already exists, it allows you to set specific changes to that item. All menus will be sorted lexicographically by the id string. The ordering is underscores, digits, and finally letters.<br /> * '''description''': the in-game text that will appear for this item in the menu.<br /> * '''image''': the image to display next to this item, defaults to &quot;buttons/WML-custom.png&quot;<br /> * '''needs_select''': if ''yes'' (default ''no''), then the latest select event (see [[EventWML]]) that triggered before this menu item was chosen will be transmitted over the network before this menu item action will be. This only has any effect in networked multiplayer, and is intended to allow more elaborate menu item behaviour there without causing out of sync errors. If you don't know what this means, just leave it. {{DevFeature1.13|6}} ''needs_select=yes'' is deprecated, consider using manual variable syncing with [sync_variable].<br /> * '''synced''' {{DevFeature1.13|1}}: if ''no'' (default ''yes'') the command handler will only be run on the client that invoked the menu item; this means that changing the gamestate in a command handler of a menu item with ''synced=no'' will cause OOS<br /> * '''use_hotkey''': if ''no'' (default ''yes''), then the user cannot assign hotkeys to this menu item. If ''only'', the menu item is only accessible via hotkeys, not via right-click context; you can use this in combination with [default_hotkey] if you want custom hotkeys in your campaign/mp. <br /> * '''[show_if]''': If present, the menu item will only be available if the conditional statement (see [[ConditionalActionsWML#Condition_Tags|ConditionalActionsWML]]) within evaluates to true. When this is evaluated, the WML variables ''$x1'' and ''$y1'' will point to the location on which the context menu was invoked, so it's possible to for example only enable the option on empty hexes or on a particular unit.<br /> * '''[filter_location]''': contains a [[StandardLocationFilter]] similar to the one found inside Single Unit Filters. The menu item will only be available on matching locations.<br /> * '''[default_hotkey]''': contains a hotkey WML to specify what hotkey to assign to this, '''if the user has no hotkey assigned to this yet'''. (Unlike the rest of a menu item definition, modifying this tag has no effect on the game; it is only effective when initially defining a menu item.) Hotkey WML matches the format in the preferences file and contains the following keys:<br /> ** '''key''': a string that contains the key to assign to this.<br /> ** '''alt''', '''shift''', '''cmd'''(apple only), '''ctrl''': boolean values.<br /> ** '''repeat_on_hold''' {{DevFeature1.13|12}}: if ''yes'' (default ''no''), holding the hotkey will repeat the action continuously, unless it blocks input with something like '''[message]'''. Due to a bug, versions older than 1.13.12 always repeat the action, with no way to disable it.<br /> * '''[command]''': contains the WML actions to be executed when the menu item is selected. Again, the WML variables ''$x1'' and ''$y1'' will point to the location on which the context menu was invoked on.<br /> ** '''delayed_variable_substitution ''' (boolean yes|no, default: yes): If no, forces a variable substitution run onto the wml included in this [command] block. Use this, if you want variables which are to substitute to get the values they have at execution time of the event where this set_menu_item appears. Other than that, they get the values they have at invocation time of the menu item.<br /> <br /> == [clear_menu_item] ==<br /> <br /> Removes a menu item from the scenario.<br /> Normally menu items are, including all their defining wml, automatically carried over between scenarios. This tag prevents this. (The behavior is comparable to set_variable/clear_variable).<br /> * '''id''': (string): id of the menu item to clear. Can be a comma-separated list.<br /> <br /> == Other interface tags ==<br /> <br /> The following tags are also action tags:<br /> <br /> === [change_theme] ===<br /> <br /> {{DevFeature1.13|8}}<br /> <br /> Change the current interface theme.<br /> <br /> * '''theme''': The ID of the new theme. Use &lt;code&gt;theme=&lt;/code&gt; (empty key) to switch back to the theme that the player has selected in Preferences. On &lt;b&gt;1.14.2&lt;/b&gt; and later it is also possible to omit the key entirely to achieve the same effect (on previous versions this will crash the Lua engine).<br /> <br /> === [item] ===<br /> Makes a graphical item appear on a certain hex. Note this only places the graphics for an item. It does not make the item do anything. Use a moveto event to make moving onto the item do something. &lt;tt&gt;''('''Hint:''' There are a number of predefined items that are used in various campaigns that you can make use of. You can find [http://www.wesnoth.org/macro-reference.xhtml#file:items.cfg a list of them] if you look into the items.cfg file in the wesnoth install directory (under /data/core/macros).)''&lt;/tt&gt;<br /> * '''x''', '''y''': the location to place the item. (only for [event][item]: full [[StandardLocationFilter|SLF]] support)<br /> * '''image''': the image (in ''images/'' as .png) to place on the hex. This image is aligned with the center of the hex (which is 72 pixels wide and 72 pixels tall). It is drawn underneath units. ''('''Hint:''' To position a small image somewhere other than the center, [[ImagePathFunctions#Blit_Function|BLIT]] the image onto &lt;tt&gt;misc/blank-hex.png&lt;/tt&gt; (a blank 72x72 image). The image is centered since {{DevFeature1.17|7}}, previously the images were aligned to the top-left; however this difference doesn't affect any image BLITted onto blank-hex.png, as that is the same size as a hex.)''<br /> * '''halo''': an image to place centered on the hex. It is drawn on top of units. Use this instead of ''image'' if the image is bigger than the hex or if you want to animate an image ([https://github.com/wesnoth/wesnoth/issues/1219 #1219]). ''Example (where the integer after the colon is the duration of each frame or square bracket expansion as per [[AnimationWML]] is used): halo=scenery/fire1.png:100,scenery/fire2.png:100,scenery/fire3.png:100,scenery/fire4.png:100,scenery/fire5.png:100,scenery/fire6.png:100,scenery/fire7.png:100,scenery/fire8.png:100'' or equivalently (requires Wesnoth 1.11.2+): ''halo=scenery/fire[1~8].png:100''<br /> * '''name''' an id that can be used to remove the item.<br /> * '''team_name''': name of the team for which the item is to be displayed (hidden for others). For multiple teams just put all the names in one string, for example separated by commas. {{DevFeature1.15|0}} In 1.14 the '''[side]team_name''' attribute was expected to be a substring of this '''team_name'''. In 1.15 both are expected to be comma-separated lists of names and the item is visible if the lists intersect. ([https://github.com/wesnoth/wesnoth/pull/3533 #3533])<br /> * '''visible_in_fog''': whether the item should be visible through fog or not. Default yes.<br /> * '''submerge''': float, between 0 and 1: specifies how much of the image should be submerged. Gets multiplied with [[TerrainWML|[terrain]]]&lt;nowiki/&gt;submerge. Default 0.<br /> * '''z_order''': float: defines the order the items get drawn in. Default 0.<br /> * '''redraw''': (boolean yes|no, default: yes): If no, disables implicit calls to [[InterfaceActionsWML#.5Bredraw.5D|[redraw]]] when placing the items.<br /> * '''[filter_team]''': {{DevFeature1.15|0}} A [[StandardSideFilter]]. Set '''team_name''' to the union of all '''[side]team_name''' attributes of all sides that match the SSF. ([https://github.com/wesnoth/wesnoth/pull/3533 #3533])<br /> * {{DevFeature1.15|0}} If both '''team_name''' and '''[filter_team]''' are set, '''team_name''' is ignored.<br /> <br /> === [remove_item] ===<br /> Removes any graphical items on a given hex.<br /> * [[StandardLocationFilter]]: the hexes to remove items from<br /> * '''image''': if specified, only removes the given item if one of its 'image', 'halo' or 'name' attributes is exactly this value. (for 'halo' and 'image' this in particular means that the image name must include any [[ImagePathFunctions|image path functions]] appended to the original image name.)<br /> <br /> === [print] ===<br /> Displays a message across the screen. The message will disappear after a certain time, or when another [print] tag is encountered.<br /> * '''text''': (translatable) the text to display. Can be an empty string to remove a previous message without showing a new one.<br /> * '''size''': (default=12) the pointsize of the font to use<br /> * '''duration''': the length of time to display the text for.<br /> ** (Before 1.15.4) This is measured in the number of 'frames', and the default is 50. A frame in Wesnoth is usually displayed for around 30ms.<br /> ** {{DevFeature1.15|4}} This is measured in milliseconds. Don't use the default value, because it's a mere 50ms.<br /> ** {{DevFeature1.15|14}} The default is 5000 milliseconds.<br /> ** {{DevFeature1.15|14}} The string '''unlimited''' displays the text until it's removed by another [print] tag.<br /> * '''color''': (default '''0,0,0''') three comma-separated values giving the red, green and blue values (0-255).<br /> * '''red''', '''green''', '''blue''': deprecated, use color=0,0,0 instead.<br /> <br /> === [move_unit_fake] ===<br /> Moves an image of a unit along a certain path on the map. The path does not need to be a continuous list of adjacent hexes, so for example only the start and end points can be given, in which case the straightest line between those points will be calculated and used.<br /> * '''type''': the type of the unit whose image to use<br /> * '''x''': a comma-separated list of x locations to move along<br /> * '''y''': a comma-separated list of y locations to move along (x and y values are matched pairs)<br /> * '''side''': the side of the fake unit, used for team-coloring the fake unit<br /> * '''gender''': the gender of the fake unit. Example: gender=female<br /> * '''variation''': the variation of the fake unit. Example: variation=undead<br /> * '''image_mods''': [[ImagePathFunctions|image path functions]] sequence to be applied on the fake unit.<br /> * '''force_scroll''': Whether to scroll the map or not even when [[#.5Block_view.5D|[lock_view]]] is in effect or ''Follow Unit Actions'' is disabled in ''Advanced Preferences''. Defaults to ''yes'' starting with version '''1.11.6'''; the attribute did not exist in previous versions and this action behaved as if ''no'' was passed instead.<br /> <br /> === [move_units_fake] ===<br /> moves multiple images of units along paths on the map. These units are moved in lockstep.<br /> * '''force_scroll''': {{DevFeature1.15|0}} Has the same meaning as in [move_unit_fake] but a different default.<br /> * '''[fake_unit]''': A fake unit to move<br /> ** '''type''': the type of unit whose image to use<br /> ** '''x''': a comma-separated list of x locations to move along<br /> ** '''y''': a comma-separated list of y locations to move along (x and y values are matched pairs)<br /> ** '''side''': the side of the fake unit, used for team-coloring the fake unit<br /> ** '''skip_steps''': the number of steps to skip before this unit starts moving<br /> <br /> === [hide_unit] ===<br /> Temporarily prevents the engine from displaying the given unit. The unit does not become invisible, as it would be with the '''[hides]''' ability; it is still the same plain unit, but without an image. Useful in conjunction with '''[move_unit_fake]''': to move a leader unit into position on-screen. Until 1.8 each '''[hide_unit]''' tag only hides one unit.<br /> * [[StandardUnitFilter]]: All matching units will be hidden<br /> <br /> === [unhide_unit] ===<br /> Stops the currently hidden units from being hidden.<br /> * [[StandardUnitFilter]]: Only the matching units will be unhidden<br /> <br /> === [lock_view] ===<br /> Locks gamemap view scrolling for human players, so they cannot scroll the gamemap view until it is unlocked. WML or Lua actions such as '''[scroll_to]''' will continue to work normally, as they ignore this restriction; the locked/unlocked state is preserved when saving the current game.<br /> <br /> This feature is generally intended to be used in cutscenes to prevent the player scrolling away from scripted actions.<br /> <br /> {{DevFeature1.13|8}} This now also blocks the player from zooming the gamemap view. WML or Lua zoom will continue to work normally.<br /> <br /> === [unlock_view] ===<br /> Unlocks gamemap view scrolling for human players.<br /> <br /> === [scroll] ===<br /> Scroll a certain number of pixels in a given direction. Useful for earthquake/shaking effects.<br /> * '''x''', '''y''': the number of pixels to scroll along the x and y axis<br /> * '''side''': the side or sides for which this should happen. By default, the [scroll] happens for everyone.<br /> * '''[filter_side]''': a [[StandardSideFilter]] to select the sides for which this should happen. By default, the [scroll] happens for everyone.<br /> <br /> === [scroll_to] ===<br /> Scroll to a given hex<br /> * [[StandardLocationFilter]], do not use a [filter_location] sub-tag. If more than one location matches the filter, only the first matching location will be used.<br /> * '''check_fogged''': whether to scroll even to locations covered in fog or shroud. Possible values ''yes'' (don't scroll to fog) and ''no'' (scroll even to fog), with ''no'' as the default.<br /> * '''immediate''': whether to instantly warp to the target hex regardless of the scroll speed setting in Preferences (defaults to ''no'').<br /> * '''highlight''': {{DevFeature1.13|5}} Whether to highlight the hex being scrolled to (defaults to ''no'').<br /> * '''side''': the side or sides for which this should happen. By default, the [scroll_to] happens for everyone.<br /> * '''[filter_side]''': a [[StandardSideFilter]] to select the sides for which this should happen. By default, the [scroll_to] happens for everyone.<br /> <br /> === [scroll_to_unit] ===<br /> Scroll to a given unit<br /> * [[StandardUnitFilter]]; do not use a [filter] subtag.<br /> * '''check_fogged''': whether to scroll even to locations covered in fog or shroud. Possible values ''yes'' (don't scroll to fog) and ''no'' (scroll even to fog), with ''no'' as the default.<br /> * '''immediate''': whether to instantly warp to the target hex regardless of the scroll speed setting in Preferences (defaults to ''no'').<br /> * '''highlight''': {{DevFeature1.13|5}} Whether to highlight the hex the unit is on (defaults to ''no'').<br /> * '''for_side''': the side or sides for which this should happen. By default, the [scroll_to_unit] happens for everyone.<br /> * '''[for_side]''': a [[StandardSideFilter]] to select the sides for which this should happen. By default, the [scroll_to_unit] happens for everyone.<br /> <br /> === [select_unit] ===<br /> Selects a given unit.<br /> * [[StandardUnitFilter]]: The first unit found will be selected.<br /> * '''fire_event''': whether a ''select'' event should be triggered or not (def. ''no''). (Note that select events aren't multiplayer save.)<br /> * '''highlight''': whether the unit's current hex should be highlighted (def. ''yes'').<br /> <br /> '''Note:''' fire_event does not appear to work in 1.14 or 1.16.<br /> <br /> === [sound]===<br /> Plays a sound<br /> * '''name''': the filename of the sound to play (in ''sounds/'' as .wav or .ogg). This can be a comma-separated list, from which one sound will be chosen randomly.<br /> * '''repeat''': repeats the sound for a specified additional number of times (default=0)<br /> <br /> === [sound_source] ===<br /> Creates a sound source. &quot;Sound sources&quot; is a general name for a mechanism which makes possible for map elements to emit sounds according to some rules, where &quot;map elements&quot; can be specific locations or terrain types. For now, only sound sources tied to locations are supported.<br /> * '''id''': a unique identification key of the sound source<br /> * '''sounds''': a list of comma separated, randomly played sounds associated with the sound source<br /> * '''delay''': a numerical value (in milliseconds) of the minimal delay between two playbacks of the source's sound if the source remains visible on the screen; if one scrolls out and back in, the source will be considered as ready to play<br /> * '''chance''': a percentage (a value from 0 to 100) describing the chance of the source being activated every second after the delay has passed or when the source's location appears on the screen (note that it cannot play more than one file at the same time)<br /> * '''check_fogged''': possible values ''yes'' and ''no'' - ''yes'' means the source will not play if its locations are fogged<br /> * '''check_shrouded''': possible values ''yes'' and ''no'' - ''yes'' means the source will not play if its locations are shrouded<br /> * '''x,y''': similar to x,y as found in a [[StandardLocationFilter]], these are the locations associated with the sound source<br /> * '''fade_range''' (default = 14): distance in hexes that determines a &quot;circular&quot; area around the one specified by '''full_range''' where sound volume fades out linearly<br /> * '''full_range''' (default = 3): distance in hexes that determines a &quot;circular&quot; area where source plays with full volume, relative to screen center<br /> * '''loop''': number of times a sound sample should be looped if it stays visible. -1 means infinite (~65000)<br /> <br /> === [story] ===<br /> {{DevFeature1.13|8}}<br /> <br /> Shows the story screen.<br /> * '''title''': Default title used if a part does not specify one — unlike the intro storyscreen, the scenario name is not used as a default title.<br /> * '''[part]''', '''[if]''', '''[switch]''', '''[wml_message]''', '''[deprecated_message]''' : See [[IntroWML]].<br /> <br /> === [remove_sound_source] ===<br /> Removes a previously defined sound source.<br /> * '''id''': the identification key of the sound source to remove<br /> <br /> === [music] ===<br /> Switches to playing different music<br /> * '''name''': the filename of the music to play (in ''music/'' as .ogg)<br /> * see [[MusicListWML]] for the correct syntax<br /> <br /> === [volume] ===<br /> Changes the game volume to a percent of the preferences volume for the game being played. Values can go from 0 to 100: <br /> * '''music''': Changes the music volume.<br /> * '''sound''': Changes the sound volume.<br /> <br /> === [color_adjust] ===<br /> Adjust the color tint of terrain, by adjusting time-of-day coloring.<br /> * '''red''', '''green''', '''blue''': values from -255 to 255, the amount to tint by for each color<br /> <br /> === [screen_fade] ===<br /> {{DevFeature1.17|6}}<br /> <br /> Overlay the game display with the given color, fading over the specified duration. This can be used for screen fade effects.<br /> * '''red''', '''green''', '''blue''': values from 0 to 255, the final overlay color (defaults to 0,0,0)<br /> * '''alpha''': value from 0 to 255, the strength of the effect. 0 means no effect and can be used to fade in. 255 means fully opaque and can be used to fully fade out to the given color. Intermediate values will end up with a partial overlay tint on the game screen.<br /> * '''duration''': the length of time it will take to complete the fade, in milliseconds. If 0 the effect is immediate.<br /> <br /> === [delay] ===<br /> Pauses the game.<br /> * '''time''': the time to pause in milliseconds<br /> * '''accelerate ''' (boolean yes|no, default no): {{DevFeature1.13|0}} whether the delay is affected by acceleration. When [delay] is used to make an animation, this should be set to yes so that your animation matches the ones generated by the game.<br /> <br /> === [redraw] ===<br /> Redraws the screen (this normally isn't done during events, although some of the other interface actions cause the screen or parts of it to be redrawn).<br /> * '''clear_shroud''' (boolean yes|no, default no): If yes, clears fog and shroud around existing units. Useful if you, for example, spawn friendly units in the middle of an event and want the shroud to update accordingly (otherwise units that spawn inside fog would remain invisible for the duration of the event, since the fog would not automatically get cleared around them).<br /> * '''[[StandardSideFilter]]''': the sides for which to recalculate fog and shroud.<br /> * '''side''': If used (forces clear_shroud=yes), clears fog and shroud for that side.<br /> <br /> === [unit_overlay] ===<br /> Sets an image that will be drawn over a particular unit, and follow it around<br /> * [[StandardUnitFilter]]: All matching units will get the overlay (do not use [filter])<br /> * '''image''': the image to place on the unit<br /> * '''object_id''': object id to use, defaults to the '''image''' key with an &quot;overlay_&quot; prefix; this allows using [[DirectActionsWML#.5Bremove_object.5D|'''[remove_object]''']]<br /> * '''duration''': object duration<br /> <br /> === [remove_unit_overlay] ===<br /> Removes a particular overlayed image from a unit<br /> * [[StandardUnitFilter]]: The overlay will get removed from all matching units (do not use [filter])<br /> * '''image''': the image to remove from the unit<br /> * '''object_id''': object id to use<br /> Using [[DirectActionsWML#.5Bremove_object.5D|'''[remove_object]''']] is also possible, see https://github.com/wesnoth/wesnoth/commit/26c2f941f2bcdd89528481e114c0375ad2a46271<br /> <br /> === [animate_unit] ===<br /> Uses an animation of a unit to animate it on screen (if the unit has the corresponding animation).<br /> * '''flag''': The key to find the custom animation in the unit description (see the '''[extra_anim]''' description in [[AnimationWML]]). Standard animations can be triggered with the following keywords: ''leading recruited standing idling levelout levelin healing healed poisoned movement defend attack death victory pre_teleport post_teleport''<br /> * '''[filter]''' with a [[StandardUnitFilter]] as argument, see [[FilterWML]]. By default, the unit at the event location will be animated. You can use this tag to choose any other unit to animate.<br /> * '''[primary_attack]''': If this tag is not present, the filter for animation will be triggered with no attack. If it is here, all attacks from the unit will be filtered, and a matching one will be used to filter the animation. Takes a weapon filter as argument, see [[FilterWML]].<br /> * '''[secondary_attack]''': Similar to '''[primary_attack]'''. May be needed to trigger a defense animation correctly, if there are more than one animations available for the defending unit.<br /> * '''hits''': yes/no/hit/miss/kill: which according variation of a attack/defense animation shall be chosen (required)<br /> * '''text''': a text to hover during the animation <br /> * '''male_text''', '''female_text''': {{DevFeature1.13|2}} (translatable) gender-specific versions of the above<br /> * '''red''': red value for the text color (0-255)<br /> * '''green''': green value for the text color<br /> * '''blue''': blue value for the text color<br /> * '''with_bars''': yes/no: whether to display the status bars during the animation (e.g. the hitpoint bar)<br /> * '''[animate]''': a sub block with the same syntax as '''[animate_unit]''' except that the '''[filter]''' block is mandatory to find the unit. This block will find and animate another unit simultaneously.<br /> * '''[facing]''': a [[StandardLocationFilter]] specifying what hex the unit should be facing when animated<br /> <br /> === [label] ===<br /> Places a label on the map.<br /> * '''x''', '''y''': the location of the label. {{DevFeature1.13|1}} (only for [event][label]: full [[StandardLocationFilter|SLF]] support)<br /> * '''text''': what the label should say. If you put an empty string &lt;code&gt;&quot;&quot;&lt;/code&gt; as an argument, the label will be completely removed. Use this method if you want to remove a specific label from any location.<br /> * '''team_name''': if specified, the label will only be visible to the given team.<br /> * '''color''': color of the label. The format is r,g,b; r, g and b are numbers between 0 and 255. When you use Pango markup in the text, you cannot use this, but in that case you could colorize the text via Pango markup.<br /> * '''visible_in_fog''': whether the label should be visible through fog or not. Default yes.<br /> * '''visible_in_shroud''': whether the label should be visible through shroud or not. Default no.<br /> * '''immutable''': whether this label is protected from being removed or changed by players. Default yes.<br /> * '''category''': the Show/Hide Labels dialog allows showing/hiding all labels of a given category by toggling a checkbox.<br /> * '''tooltip''': A tooltip visible when putting the mouse over the hex the label is on<br /> * '''side''': the number of the side that placed the label. Can be 0 for labels placed by WML.<br /> <br /> === [floating_text]===<br /> Floats text (similar to the damage and healing numbers) on the given locations.<br /> * [[StandardLocationFilter]]: the text will be floated on all matching locations simultaneously (do not use [filter] unless you intend to match one or more units).<br /> * '''text''': the text to display.<br /> <br /> The default text color is &lt;span style=&quot;color: #6b8cff;&quot;&gt;'''#6b8cff'''&lt;/span&gt;. To change the color, use [[#Formatting|Pango markup]]. For example:<br /> <br /> &lt;pre&gt;<br /> # Float some golden yellow text at 20,20.<br /> [floating_text]<br /> x,y=20,20<br /> text=&quot;&lt;span color='#cccc33'&gt;&quot; + _ &quot;Your text here&quot; + &quot;&lt;/span&gt;&quot;<br /> [/floating_text]<br /> &lt;/pre&gt;<br /> <br /> === [deprecated_message] ===<br /> Shows a deprecated message in the message area, this feature is only intended to be used to warn about deprecated macros in mainline. The message is not translatable.<br /> * '''message''': the message to show.<br /> * '''level''': {{DevFeature1.13|10}} The deprecation level, a number from 1 to 3.<br /> * '''what''': {{DevFeature1.13|10}} The name of the thing being deprecated. Use this instead of '''message''' if possible; a stock message will be generated from it. Use '''message''' only if more information is required; it will be appended to the stock message. This should not be translatable<br /> * '''version''': {{DevFeature1.13|10}} For deprecation levels 2 and 3, this indicates the version in which the feature could be removed. It does ''not'' indicate the version in which it became deprecated. <br /> <br /> The meanings of the deprecation levels are as follows:<br /> <br /> # Deprecated, but will only be removed if absolutely necessary. The '''version''' key is ignored.<br /> # It will be removed no earlier than a specified version.<br /> # It will be removed in the next stable version<br /> # It has already been removed, leaving just a stub to inform users of how to update their code.<br /> <br /> Note that as of 1.13.11, deprecation messages show only in the log, not in the chat message area. The '''message''' can be translatable, but does not need to be.<br /> <br /> === [wml_message] ===<br /> Outputs a message to Wesnoth's console output. Intended for campaign designers to output silent text to the console, without annoying the player; then, that text might contain information useful for later bug-reporting. WML wrapper of [[LuaAPI/wesnoth#wesnoth.log]], see the link for more description.<br /> * '''message''': the message to show.<br /> * '''to_chat''': controls whether message is visible in chat, though logger=wml means message is visible anyways. Default ''no''.<br /> * '''logger''': one of '''info''', '''debug''', '''warning''', '''error''', '''wml'''. Default ''info''.<br /> <br /> === [test_condition] ===<br /> <br /> {{DevFeature1.13|2}}<br /> <br /> Evaluates the contained conditional tags. If they evaluate to the expected value, it prints out a message to the console explaining which part of the condition caused this result in a way similar to [wml_message]. This can be used if your conditional test is failing and you're not sure why.<br /> <br /> * '''result''': Whether you expect the conditions to fail or succeed. If no (the default), a message will be printed if the conditional tags fail. If yes, a message will instead be printed if the conditional tags pass.<br /> * '''logger''': Same as for [wml_message]. Defaults to &quot;warning&quot;.<br /> <br /> === [open_help] ===<br /> Opens the in-game help.<br /> * '''topic''': the id of the topic to open<br /> <br /> Examples of ids:<br /> * unit_Mage<br /> * unit_Dark Adept<br /> * weaponspecial_charge<br /> * terrain_human_castle<br /> <br /> The engine will print the topic ids if run from the command line with the ''--log-debug=help'' option.<br /> <br /> === [show_objectives] ===<br /> refreshes the objectives defined by [objectives] and its [show_if] tags, and displays them. (It is also called whenever the user explicitly asks for the objectives; this matters only if the tag was overridden by a [[LuaWML#register_wml_action|Lua]] script.)<br /> * '''side''': the side to show the objectives. If not set, all sides are used.<br /> * '''[[StandardSideFilter]]''' tags and keys: Tag affects the matching sides instead of just all or the one given by the integer value of the side= key.<br /> <br /> === [chat] ===<br /> Displays a message in the chat area, not visible for observers. Alternative unconditionally visible for everyone: [[LuaWML:Display#wesnoth.message]]. {{DevFeature1.13|9}} can be visible for observers.<br /> * '''speaker''': (default=&quot;WML&quot;) A string for the name of the sender of the message.<br /> * '''message''': The message that should be displayed.<br /> * '''observable''' (boolean yes|no, default yes): {{DevFeature1.13|9}} Whether the message is displayed for observers.<br /> * '''[[StandardSideFilter]]''' tags and keys as argument; if the same client controls multiple sides that match, then the message will only be displayed once.<br /> <br /> === [zoom] ===<br /> <br /> {{DevFeature1.13|8}}<br /> <br /> Changes the zoom level of the map.<br /> <br /> * '''factor''': The new zoom factor, measured as a multiple of the base zoom.<br /> * '''relative''': If yes, zoom relative to current zoom level. Otherwise, set the absolute zoom level. Default no.<br /> <br /> == Useful Macros ==<br /> There are some predefined macros that you find useful for interface 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 /> * '''{HIGHLIGHT_UNIT}''' Highlight a unit on the map. Use this to show important units<br /> * '''{HIGHLIGHT_IMAGE}''' Places and highlights an image on the map. Use this to show important items or locations<br /> * '''{SET_IMAGE}''' Places an image on the map which has no other function.<br /> * '''{QUAKE &lt;soundfile&gt;}''' Creates a tremor-like screenshake and plays &lt;soundfile&gt;. For example, '''{QUAKE (rumble.ogg)}'''.<br /> * '''{FLASH_WHITE}''' Flash the screen white momentarily. You can also replace WHITE with RED, BLUE or GREEN for a different colour.<br /> <br /> == See Also ==<br /> * [[DirectActionsWML]]<br /> * [[InternalActionsWML]]<br /> * [[EventWML]]<br /> * [[ReferenceWML]]<br /> <br /> <br /> [[Category: WML Reference]]<br /> [[Category: ActionsWML]]</div>

Pentarctagon https://wiki.wesnoth.org/index.php?title=Template:DevDownload&diff=74585 2025-11-02T16:40:32Z

<p>Pentarctagon: </p> <hr /> <div>&lt;noinclude&gt;<br /> == Development (1.19 branch) ==<br /> &lt;/noinclude&gt;<br /> ==== Windows (10 1903 and later) {{{4|}}} ====<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.17 | filename=wesnoth-1.19.17-win64.exe |<br /> hash=3043cf6db1dcd17c341ee8af7d625a9d561cc06fbf091297a0aa6d3f413b21bb}}<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.16 | filename=wesnoth-1.19.16-win64.exe |<br /> hash=4b52b3546c9c0d625058b60b018c967fdb793a04cf4700bc18388bb97f174907}}<br /> <br /> ==== macOS (10.13 and later) {{{5|}}} ====<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.16 | filename=Wesnoth_1.19.16.dmg |<br /> hash=730ddcf8b7f4d0cafa6bf924598528ff1e71e152d91dc3d8e9974e62a93bb8b8}}<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.15 | filename=Wesnoth_1.19.15.dmg |<br /> hash=099a179a1b12f4b0babc9ca7fcfaa6027af794cbb8301cd0a06488049f56e6ec}}<br /> <br /> ==== Source code ====<br /> * [https://github.com/wesnoth/wesnoth/blob/master/INSTALL.md Compiling Wesnoth] - How to compile the source code<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.17 | filename=wesnoth-1.19.17.tar.bz2 |<br /> hash=7a4f65b3bd845fc923a8f745591062061f5f72cedd4f81edb93e42b8e6b162ea}}<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.16 | filename=wesnoth-1.19.16.tar.bz2 |<br /> hash=280c24868b19148278e3dd2604efecdf93b376f2652823453abafb55e94d0130}}</div>

Pentarctagon https://wiki.wesnoth.org/index.php?title=Template:DevDownload&diff=74522 2025-09-25T21:56:23Z

<p>Pentarctagon: </p> <hr /> <div>&lt;noinclude&gt;<br /> == Development (1.19 branch) ==<br /> &lt;/noinclude&gt;<br /> ==== Windows (10 1903 and later) {{{4|}}} ====<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.16 | filename=wesnoth-1.19.16-win64.exe |<br /> hash=4b52b3546c9c0d625058b60b018c967fdb793a04cf4700bc18388bb97f174907}}<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.15 | filename=wesnoth-1.19.15-win64.exe |<br /> hash=a17bd1fcdc7bebbf4b83cca838e1882bece27d7f092646b88661a0d47b5dcd5e}}<br /> <br /> ==== macOS (10.13 and later) {{{5|}}} ====<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.16 | filename=Wesnoth_1.19.16.dmg |<br /> hash=730ddcf8b7f4d0cafa6bf924598528ff1e71e152d91dc3d8e9974e62a93bb8b8}}<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.15 | filename=Wesnoth_1.19.15.dmg |<br /> hash=099a179a1b12f4b0babc9ca7fcfaa6027af794cbb8301cd0a06488049f56e6ec}}<br /> <br /> ==== Source code ====<br /> * [https://github.com/wesnoth/wesnoth/blob/master/INSTALL.md Compiling Wesnoth] - How to compile the source code<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.16 | filename=wesnoth-1.19.16.tar.bz2 |<br /> hash=280c24868b19148278e3dd2604efecdf93b376f2652823453abafb55e94d0130}}<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.15 | filename=wesnoth-1.19.15.tar.bz2 |<br /> hash=22a2eedd40de70bc62e9e7e61d8277f6d7fcbef359efe28ed66821bcbd96378720ccd9831314322c}}</div>

Pentarctagon https://wiki.wesnoth.org/index.php?title=Template:DevDownload&diff=74504 2025-08-25T21:43:53Z

<p>Pentarctagon: </p> <hr /> <div>&lt;noinclude&gt;<br /> == Development (1.19 branch) ==<br /> &lt;/noinclude&gt;<br /> ==== Windows (10 1903 and later) {{{4|}}} ====<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.15 | filename=wesnoth-1.19.15-win64.exe |<br /> hash=a17bd1fcdc7bebbf4b83cca838e1882bece27d7f092646b88661a0d47b5dcd5e}}<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.14 | filename=wesnoth-1.19.14-win64.exe |<br /> hash=f4505fd37abc85f2f965169d871625cfc05a419ccaaf5e5290226134a4aab57a}}<br /> <br /> ==== macOS (10.13 and later) {{{5|}}} ====<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.15 | filename=Wesnoth_1.19.15.dmg |<br /> hash=099a179a1b12f4b0babc9ca7fcfaa6027af794cbb8301cd0a06488049f56e6ec}}<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.14 | filename=Wesnoth_1.19.14.dmg |<br /> hash=addf7943fceeb05ea368460af6f7dd1e73353aedaf67cdbace034177acff4c0e}}<br /> <br /> ==== Source code ====<br /> * [https://github.com/wesnoth/wesnoth/blob/master/INSTALL.md Compiling Wesnoth] - How to compile the source code<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.15 | filename=wesnoth-1.19.15.tar.bz2 |<br /> hash=22a2eedd40de70bc62e9e7e61d8277f6d7fcbef359efe28ed66821bcbd96378720ccd9831314322c}}<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.14 | filename=wesnoth-1.19.14.tar.bz2 |<br /> hash=320b0c4b79ddbbc3a0e534f3a8c5f4a5ca7f8055145e3f7b20ccd9831314322c}}</div>

Pentarctagon https://wiki.wesnoth.org/index.php?title=WesnothTranslations&diff=74456 2025-07-28T00:49:04Z

<p>Pentarctagon: </p> <hr /> <div>== Translations ==<br /> <br /> Wesnoth is currently being translated into the following languages. These languages are active, with maintainer.<br /> {| class=&quot;wikitable&quot;<br /> |-<br /> ! Translation !! Maintainer !! Contact<br /> |-<br /> | [[AncientGreekTranslation|Ancient Greek]] || Mejri Ziad (Hermestrismi)|| [mailto:beja.comuneATgmailDOTcom]<br /> |-<br /> | [[ArabicTranslation|Arabic]] || Mejri Ziad (Hermestrismi)|| [mailto:beja.comuneATgmailDOTcom]<br /> |-<br /> | [[BengaliTranslation|Bengali]] || Subhraman Sarkar (LumiousE) || lumious_e on Discord<br /> |-<br /> | [[BulgarianTranslation|Bulgarian]] || Ivan Petrov (TheWhiteKnight) || [mailto:vankata_petrovATabvDOTbg]<br /> |-<br /> | [[CatalanTranslation|Catalan]] || Miquel-Àngel Burgos i Fradeja || [mailto:miquel.angel.burgosATgmailDOTcom]<br /> |-<br /> | [[ChineseTranslation|Chinese]] || CloudiDust || [mailto:cloudidustATgmailDOTcom]<br /> |-<br /> | [[ChineseTaiwanTranslation|Chinese (Taiwan)]] || 楊綮銘 (Taiwan) || [mailto:steven2880ATgmailDOTcom]<br /> |-<br /> | [[CzechTranslation|Czech]] || Michal Žejdl || [mailto:lachimATemerDOTcz]<br /> |-<br /> | [[DutchTranslation|Dutch]] || Merijn de Vet || [mailto:merijndevetAThotmailDOTcom]<br /> |-<br /> | [[EnglishGBTranslation|English (GB)]] || Wedge009 || [mailto:wedge009ATwedge009DOTnet]<br /> |-<br /> | [[EnglishShawTranslation|English (Shaw)]] || Arc Riley || [mailto:ArcRileyATubuntuDOTcom]<br /> |-<br /> | [[Esperanto_translation|Esperanto]] || Mariano Street (mctpyt) || [mailto:mctpytATprotonDOTme]<br /> |-<br /> | [[FinnishTranslation|Finnish]] || Jaakko Saarikko (styxnix) || [mailto:jaakkoDOTsaarikkoATprotonmailDOTcom]<br /> |-<br /> | [[FrenchTranslation|French]] || demario || [mailto:wesnothfr-request@lists.tuxfamily.org?subject=subscribe mailing list]<br /> |-<br /> | [[GermanTranslation|German]] || Aaron Winter (Bitron) || <br /> |-<br /> | [[HungarianTranslation|Hungarian]] || Berda Jenő (bigbilly) || [mailto:big4billyATgmailDOTcom]<br /> |-<br /> | [[IndonesianTranslation|Indonesian]] || Irsyad Musthafa || [mailto:sevennightmareATtutanotaDOTde]<br /> |-<br /> | [[ItalianTranslation|Italian]] || Antonio Rosella || [mailto:arosellaATyahooDOTcom]<br /> |-<br /> | [[JapaneseTranslation|Japanese]] || Hironori Fujimoto (RatArmy) || [mailto:broadbarredfirefishATgmailDOTcom]<br /> |-<br /> | [[KoreanTranslation|Korean]] || mistzone || [mailto:drier22ATgmailDOTcom]<br /> |-<br /> | [[LatinTranslation|Latin]] || Daniel Faustmann || [mailto:donnerstag.freitag213@gmail.com]<br /> |-<br /> | [[NorwegianTranslation|Norwegian]] || Bloodaxe || [mailto:bloodaxenor@protonmail.com]<br /> |-<br /> | [[PolishTranslation|Polish]] || ForPeace || [https://forums.wesnoth.org/viewtopic.php?f=7&amp;t=3796 forum thread]<br /> |-<br /> | [[PortugueseTranslation|Portuguese Brazilian]] || Andrei Machado || [mailto:andreisp.machadoATyahooDOTcom]<br /> |-<br /> | [[PortugueseContinentalTranslation|Portuguese (European)]] || trewe || [mailto:sjrs456ATyahooDOTfr]<br /> |-<br /> | [[RussianTranslation|Russian]] || Artem Khrapov || ([[User:kabachuha|kabachuha]]) [mailto:artemkhrapov2001ATyandexDOTru]<br /> |-<br /> | [[Scottish_Gaelic_Translation|Scottish Gaelic]] || GunChleoc || [mailto:fiosAIGforamnagaidhligDOTnet]<br /> |-<br /> | [[SlovakTranslation#Preklad|Slovak]] || Stanislav Hoferek || [mailto:shoferek@gmail.com]<br /> |-<br /> | [[SpanishTranslation|Spanish]] || Toranks || [mailto:davinciATtoranksDOTes]<br /> |-<br /> | [[SwedishTranslation|Swedish]] || Alex Alowersson (fluxbird) || [mailto:alexalowersonATgmailDOTcom]<br /> |-<br /> | [[TurkishTranslation|Turkish]] || Nilgün Belma Bugüner || [mailto:nilgunATbelgelerDOTorg]<br /> |-<br /> | [[UkrainianTranslation|Ukrainian]] || Oleksii Okhrimenko (lexa04) || Discord: amakri Email: [mailto:ohrimaleATgmailDOTcom]<br /> |}<br /> <br /> Currenty unactive translations. If you wish to improve some of this languages, contact Ivanovic on Wesnoth Discord channel.<br /> <br /> {| class=&quot;wikitable&quot;<br /> |-<br /> ! Translation !! Maintainer !! Contact<br /> |-<br /> | [[AfrikaansTranslation|Afrikaans]] || None || N/A<br /> |-<br /> | [[BasqueTranslation|Basque]] || None || N/A<br /> |-<br /> | [[BurmeseTranslation|Burmese]] || None || N/A<br /> |-<br /> | [[CroatianTranslation|Croatian]] || None || N/A<br /> |-<br /> | [[DanishTranslation|Danish]] || None || N/A<br /> |-<br /> | [[GalicianTranslation|Galician]] || None || N/A<br /> |-<br /> | [[GreekTranslation|Greek]] || None || N/A<br /> |-<br /> | [[HebrewTranslation|Hebrew]] || None || N/A<br /> |-<br /> | [[IcelandicTranslation|Icelandic]] || None || N/A<br /> |-<br /> | [[IrishTranslation|Irish]] || None || N/A<br /> |-<br /> | [[LatvianTranslation|Latvian]] || None || N/A<br /> |-<br /> | [[LithuanianTranslation|Lithuanian]] || None || N/A<br /> |-<br /> | [[MarathiTranslation|Marathi]] || None || N/A<br /> |-<br /> | [[MacedonianTranslation|Macedonian]] || None || N/A<br /> |-<br /> | [[OldEnglishTranslation|Old English]] || None || N/A<br /> |-<br /> | [[RACVTranslation|RACV]] || None || N/A<br /> |-<br /> | [[RomanianTranslation|Romanian]] || None || N/A<br /> |-<br /> | [[SerbianTranslation|Serbian]] || None || N/A<br /> |-<br /> | [[SlovenianTranslation|Slovenian]] || None || N/A<br /> |-<br /> | [[SpanishLatinAmericanTranslation|Spanish (Latin American)]] || None || N/A<br /> |-<br /> | [[ValencianTranslation|Valencian]] || None || N/A<br /> |-<br /> | [[VietnameseTranslation|Vietnamese]] || None || N/A<br /> |}<br /> <br /> == Mailing List ==<br /> <br /> There now is a mailing list dedicated to translation matters. It is mainly intended to be used for informing translation maintainers about important changes, to announce string freezes and other special things. Everyone is free to subscribe to this list.<br /> <br /> * [https://listengine.tuxfamily.org/wesnoth.org/i18n/ List info, how to subscribe, and archives from April 2022]<br /> * [https://mailman.wesnoth.org/pipermail/i18n/ Old list archives (up until April 2022)]<br /> <br /> Please keep in mind that this list is not meant for discussing changes for one single translation but instead subjects which are relevant to all translations.<br /> <br /> == See also ==<br /> <br /> * [[WesnothTranslationsHowTo]]<br /> * [[ImageLocalization]]<br /> * [[GetText]]<br /> * [http://gettext.wesnoth.org Translations statistics (stable)]<br /> * [http://gettext.wesnoth.org/index.php?version=trunk&amp;package=alloff Translations statistics (development)]<br /> * [[GettextForTranslators#For_add-ons|Translating User Made Campaigns and add-ons]]<br /> * [[SpellingMistakes]]<br /> * [[CharactersStorys| Character descriptions for Translators (Spoiler Warning)]]<br /> * [[Poetry of Wesnoth Translations]]<br /> <br /> [[Category:Translations|*]]</div>

Pentarctagon https://wiki.wesnoth.org/index.php?title=WesnothTranslations&diff=74455 2025-07-28T00:48:48Z

<p>Pentarctagon: </p> <hr /> <div>== Translations ==<br /> <br /> Wesnoth is currently being translated into the following languages. These languages are active, with maintainer.<br /> {| class=&quot;wikitable&quot;<br /> |-<br /> ! Translation !! Maintainer !! Contact<br /> |-<br /> | [[AncientGreekTranslation|Ancient Greek]] || Mejri Ziad (Hermestrismi)|| [mailto:beja.comuneATgmailDOTcom]<br /> |-<br /> | [[ArabicTranslation|Arabic]] || Mejri Ziad (Hermestrismi)|| [mailto:beja.comuneATgmailDOTcom]<br /> |-<br /> | [[BengaliTranslation|Bengali]] || Subhraman Sarkar (LumiousE) || lumious_e on Discord<br /> |-<br /> | [[BulgarianTranslation|Bulgarian]] || Ivan Petrov (TheWhiteKnight) || [mailto:vankata_petrovATabvDOTbg]<br /> |-<br /> | [[CatalanTranslation|Catalan]] || Miquel-Àngel Burgos i Fradeja || [mailto:miquel.angel.burgosATgmailDOTcom]<br /> |-<br /> | [[ChineseTranslation|Chinese]] || CloudiDust || [mailto:cloudidustATgmailDOTcom]<br /> |-<br /> | [[ChineseTaiwanTranslation|Chinese (Taiwan)]] || 楊綮銘 (Taiwan) || [mailto:steven2880ATgmailDOTcom]<br /> |-<br /> | [[CzechTranslation|Czech]] || Michal Žejdl || [mailto:lachimATemerDOTcz]<br /> |-<br /> | [[DutchTranslation|Dutch]] || Merijn de Vet || [mailto:merijndevetAThotmailDOTcom]<br /> |-<br /> | [[EnglishGBTranslation|English (GB)]] || Wedge009 || [mailto:wedge009ATwedge009DOTnet]<br /> |-<br /> | [[EnglishShawTranslation|English (Shaw)]] || Arc Riley || [mailto:ArcRileyATubuntuDOTcom]<br /> |-<br /> | [[Esperanto_translation|Esperanto]] || Mariano Street (mctpyt) || [mailto:mctpytATprotonDOTme]<br /> |-<br /> | [[FinnishTranslation|Finnish]] || Jaakko Saarikko (styxnix) || [mailto:jaakkoDOTsaarikkoATprotonmailDOTcom]<br /> |-<br /> | [[FrenchTranslation|French]] || demario || [mailto:wesnothfr-request@lists.tuxfamily.org?subject=subscribe mailing list]<br /> |-<br /> | [[GermanTranslation|German]] || Aaron Winter (Bitron) || <br /> |-<br /> | [[HungarianTranslation|Hungarian]] || Berda Jenő (bigbilly) || [mailto:big4billyATgmailDOTcom]<br /> |-<br /> | [[IndonesianTranslation|Indonesian]] || Irsyad Musthafa || [mailto:sevennightmareATtutanotaDOTde]<br /> |-<br /> | [[ItalianTranslation|Italian]] || Antonio Rosella || [mailto:arosellaATyahooDOTcom]<br /> |-<br /> | [[JapaneseTranslation|Japanese]] || Hironori Fujimoto (RatArmy) || [mailto:broadbarredfirefishATgmailDOTcom]<br /> |-<br /> | [[KoreanTranslation|Korean]] || mistzone || [mailto:drier22ATgmailDOTcom]<br /> |-<br /> | [[LatinTranslation|Latin]] || Daniel Faustmann || [mailto:donnerstag.freitag213@gmail.com]<br /> |-<br /> | [[NorwegianTranslation|Norwegian]] || Bloodaxe || [mailto:bloodaxenor@protonmail.com]<br /> |-<br /> | [[PolishTranslation|Polish]] || ForPeace || [https://forums.wesnoth.org/viewtopic.php?f=7&amp;t=3796 forum thread]<br /> |-<br /> | [[PortugueseTranslation|Portuguese Brazilian]] || Andrei Machado || [mailto:andreisp.machadoATyahooDOTcom]<br /> |-<br /> | [[PortugueseContinentalTranslation|Portuguese (European)]] || trewe || [mailto:sjrs456ATyahooDOTfr]<br /> |-<br /> | [[RussianTranslation|Russian]] || Artem Khrapov || ([[User:kabachuha|kabachuha]]) [mailto:artemkhrapov2001ATyandexDOTru]<br /> |-<br /> | [[Scottish_Gaelic_Translation|Scottish Gaelic]] || GunChleoc || [mailto:fiosAIGforamnagaidhligDOTnet]<br /> |-<br /> | [[SlovakTranslation#Preklad|Slovak]] || Stanislav Hoferek || [mailto:shoferek@gmail.com]<br /> |-<br /> | [[SpanishTranslation|Spanish]] || Toranks || [mailto:davinciATtoranksDOTes]<br /> |-<br /> | [[SwedishTranslation|Swedish]] || Alex Alowersson (fluxbird) || [mailto:alexalowersonATgmailDOTcom]<br /> |-<br /> | [[TurkishTranslation|Turkish]] || Nilgün Belma Bugüner || [mailto:nilgunATbelgelerDOTorg]<br /> |-<br /> | [[UkrainianTranslation|Ukrainian]] || Oleksii Okhrimenko (lexa04) || Discord: amakri Email: [mailto:ohrimaleATgmailDOTcom]<br /> |}<br /> <br /> Currenty unactive translations. If you wish to improve some of this languages, contact Ivanovic on Wesnoth Discord channel.<br /> <br /> {| class=&quot;wikitable&quot;<br /> |-<br /> ! Translation !! Maintainer !! Contact<br /> |-<br /> | [[AfrikaansTranslation|Afrikaans]] || None || N/A<br /> |-<br /> | [[AncientGreekTranslation|Ancient Greek]] || None || N/A<br /> |-<br /> | [[BasqueTranslation|Basque]] || None || N/A<br /> |-<br /> | [[BurmeseTranslation|Burmese]] || None || N/A<br /> |-<br /> | [[CroatianTranslation|Croatian]] || None || N/A<br /> |-<br /> | [[DanishTranslation|Danish]] || None || N/A<br /> |-<br /> | [[GalicianTranslation|Galician]] || None || N/A<br /> |-<br /> | [[GreekTranslation|Greek]] || None || N/A<br /> |-<br /> | [[HebrewTranslation|Hebrew]] || None || N/A<br /> |-<br /> | [[IcelandicTranslation|Icelandic]] || None || N/A<br /> |-<br /> | [[IrishTranslation|Irish]] || None || N/A<br /> |-<br /> | [[LatvianTranslation|Latvian]] || None || N/A<br /> |-<br /> | [[LithuanianTranslation|Lithuanian]] || None || N/A<br /> |-<br /> | [[MarathiTranslation|Marathi]] || None || N/A<br /> |-<br /> | [[MacedonianTranslation|Macedonian]] || None || N/A<br /> |-<br /> | [[OldEnglishTranslation|Old English]] || None || N/A<br /> |-<br /> | [[RACVTranslation|RACV]] || None || N/A<br /> |-<br /> | [[RomanianTranslation|Romanian]] || None || N/A<br /> |-<br /> | [[SerbianTranslation|Serbian]] || None || N/A<br /> |-<br /> | [[SlovenianTranslation|Slovenian]] || None || N/A<br /> |-<br /> | [[SpanishLatinAmericanTranslation|Spanish (Latin American)]] || None || N/A<br /> |-<br /> | [[ValencianTranslation|Valencian]] || None || N/A<br /> |-<br /> | [[VietnameseTranslation|Vietnamese]] || None || N/A<br /> |}<br /> <br /> == Mailing List ==<br /> <br /> There now is a mailing list dedicated to translation matters. It is mainly intended to be used for informing translation maintainers about important changes, to announce string freezes and other special things. Everyone is free to subscribe to this list.<br /> <br /> * [https://listengine.tuxfamily.org/wesnoth.org/i18n/ List info, how to subscribe, and archives from April 2022]<br /> * [https://mailman.wesnoth.org/pipermail/i18n/ Old list archives (up until April 2022)]<br /> <br /> Please keep in mind that this list is not meant for discussing changes for one single translation but instead subjects which are relevant to all translations.<br /> <br /> == See also ==<br /> <br /> * [[WesnothTranslationsHowTo]]<br /> * [[ImageLocalization]]<br /> * [[GetText]]<br /> * [http://gettext.wesnoth.org Translations statistics (stable)]<br /> * [http://gettext.wesnoth.org/index.php?version=trunk&amp;package=alloff Translations statistics (development)]<br /> * [[GettextForTranslators#For_add-ons|Translating User Made Campaigns and add-ons]]<br /> * [[SpellingMistakes]]<br /> * [[CharactersStorys| Character descriptions for Translators (Spoiler Warning)]]<br /> * [[Poetry of Wesnoth Translations]]<br /> <br /> [[Category:Translations|*]]</div>

Pentarctagon https://wiki.wesnoth.org/index.php?title=Template:DevDownload&diff=74454 2025-07-27T02:10:16Z

<p>Pentarctagon: </p> <hr /> <div>&lt;noinclude&gt;<br /> == Development (1.19 branch) ==<br /> &lt;/noinclude&gt;<br /> ==== Windows (10 1903 and later) {{{4|}}} ====<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.14 | filename=wesnoth-1.19.14-win64.exe |<br /> hash=f4505fd37abc85f2f965169d871625cfc05a419ccaaf5e5290226134a4aab57a}}<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.13 | filename=wesnoth-1.19.13-win64.exe |<br /> hash=7a096d9b0171b59b1fa6d400b0537ea11b5ffc6702dc821f09b9250486fba30a}}<br /> <br /> ==== macOS (10.13 and later) {{{5|}}} ====<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.14 | filename=Wesnoth_1.19.14.dmg |<br /> hash=addf7943fceeb05ea368460af6f7dd1e73353aedaf67cdbace034177acff4c0e}}<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.13 | filename=Wesnoth_1.19.13.dmg |<br /> hash=6b2a854e96ed1ce0e06f58ba21a59d20e20ca259152c083fd330b8c0a681183f}}<br /> <br /> ==== Source code ====<br /> * [https://github.com/wesnoth/wesnoth/blob/master/INSTALL.md Compiling Wesnoth] - How to compile the source code<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.14 | filename=wesnoth-1.19.14.tar.bz2 |<br /> hash=320b0c4b79ddbbc3a0e534f3a8c5f4a5ca7f8055145e3f7b20ccd9831314322c}}<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.13 | filename=wesnoth-1.19.13.tar.bz2 |<br /> hash=1eea4bde4ccaf8afef6f502895bcde2bec42e8acec561c3944ac0703d8df4dde}}</div>

Pentarctagon https://wiki.wesnoth.org/index.php?title=Template:DevDownload&diff=74453 2025-07-27T02:09:29Z

<p>Pentarctagon: </p> <hr /> <div>&lt;noinclude&gt;<br /> == Development (1.19 branch) ==<br /> &lt;/noinclude&gt;<br /> ==== Windows (10 1903 and later) {{{4|}}} ====<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.14 | filename=wesnoth-1.19.14-win64.exe |<br /> hash=f4505fd37abc85f2f965169d871625cfc05a419ccaaf5e5290226134a4aab57a}}<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.13 | filename=wesnoth-1.19.13-win64.exe |<br /> hash=7a096d9b0171b59b1fa6d400b0537ea11b5ffc6702dc821f09b9250486fba30a}}<br /> <br /> ==== macOS (10.13 and later) {{{5|}}} ====<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.14 | filename=Wesnoth_1.19.14.dmg |<br /> hash=addf7943fceeb05ea368460af6f7dd1e73353aedaf67cdbace034177acff4c0e}}<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.13 | filename=Wesnoth_1.19.13.dmg |<br /> hash=6b2a854e96ed1ce0e06f58ba21a59d20e20ca259152c083fd330b8c0a681183f}}<br /> <br /> ==== Source code ====<br /> * [https://github.com/wesnoth/wesnoth/blob/master/INSTALL.md Compiling Wesnoth] - How to compile the source code<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.14 | filename=wesnoth-1.19.14.tar.bz2 |<br /> hash=320b0c4b79ddbbc3a0e534f3a8c5f4a5ca7f8055145e3f7b20ccd9831314322c}}<br /> * [https://github.com/wesnoth/wesnoth/blob/master/INSTALL.md Compiling Wesnoth] - How to compile the source code<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.13 | filename=wesnoth-1.19.13.tar.bz2 |<br /> hash=1eea4bde4ccaf8afef6f502895bcde2bec42e8acec561c3944ac0703d8df4dde}}</div>

Pentarctagon https://wiki.wesnoth.org/index.php?title=Project&diff=74452 2025-07-26T18:07:42Z

<p>Pentarctagon: </p> <hr /> <div>&lt;div class=&quot;tright&quot;&gt; __TOC__ &lt;/div&gt;<br /> <br /> &lt;i&gt;The Battle for Wesnoth&lt;/i&gt; is an [https://opensource.org/faq#osd open source] software project hosted on [https://github.com/wesnoth GitHub], created and maintained by &lt;i&gt;The Battle for Wesnoth Project&lt;/i&gt;, an [[Credits|international team of volunteers]] from diverse backgrounds. Conceived in 2003 by David White, &lt;i&gt;Wesnoth&lt;/i&gt; has caught the interest of a multitude of fans who have since contributed to different aspects of the game such as engine coding, content creation, art and music development, translation, packaging, testing, and community management.<br /> <br /> The Project is governed by the Project Manager and the Project Council as per the [https://www.wesnoth.org/constitution/ Project Constitution]. The current Project Manager [https://forums.wesnoth.org/viewtopic.php?t=55254 elected] by the development team for the Wesnoth 1.19.x development cycle is Pentarctagon. Past Project Managers include Charles Dang (vultraz), Iris Morelle (Irydacea), Nils Kneuper (Ivanovic) and Isaac Clerencia (isaac).<br /> <br /> The Wesnoth.org website, primary multiplayer server, and add-ons server facilities are managed by a few members of the project who staff the game's backend infrastructure.<br /> <br /> Funding for infrastructure and art and music commissions is provided by Software in the Public Interest, a US-based non-profit which manages revenue from donations made to Wesnoth through [https://liberapay.com/Wesnoth Liberapay] and [https://wesnoth.itch.io/battle-for-wesnoth itch.io]. While Software in the Public Interest financially supports the project, it does not have any involvement in its organization and direction. The current board of directors consists of Elvish_Hunter, Pentarctagon, and Soliton.<br /> <br /> == Content Creators ==<br /> <br /> Wesnoth's great replay value mainly stems from the great abundance of custom-made content developed by our talented community. It only takes a copy of the game, a text editor, creativity, and patience to create your own campaign, era, or multiplayer scenario!<br /> <br /> See [[Create]] for more information on the subject of user-made content development.<br /> <br /> == Artists ==<br /> <br /> There is plenty of room for improvement in areas such as animations and sound effects. User-made content creators are also always in need of new art, music, and sounds for their own projects!<br /> <br /> * [https://forums.wesnoth.org/viewforum.php?f=9 Mainline art contributions forum] &lt;small&gt;''Attribution &amp; copyright requirements for a contribution are outlined at [[ImageMetadata]]''&lt;/small&gt;<br /> * [https://forums.wesnoth.org/viewforum.php?f=18 Mainline art development forum]<br /> * [https://forums.wesnoth.org/viewforum.php?f=23 User-made art development forum]<br /> * [https://forums.wesnoth.org/viewforum.php?f=14 Music contributions forum]<br /> <br /> == Developers ==<br /> <br /> The project is always eager to welcome new contributors able to help by fixing [https://bugs.wesnoth.org/ bugs], cleaning up and improving on existing code, or implementing new and exciting features!<br /> <br /> * [[WesnothRepository]] — cloning and using our Git repository<br /> * [[CodingStandards]] and [[HackingWesnoth]] — information on our C++ style and coding conventions<br /> * [[PatchSubmissionGuidelines]] — instructions for submitting your code contributions<br /> * [[DeveloperGuide]] — additional information on commit messages, unit tests, etc.<br /> * [https://devdocs.wesnoth.org/ Source code documentation] — generated from the game's source code using Doxygen and updated daily.<br /> * [[ReferenceWML]] — information on the Wesnoth Markup Language (WML) and the game's Lua API<br /> * [[DeveloperResources]] — additional development-related links<br /> <br /> == Translators ==<br /> <br /> In order to better reach its audience, Wesnoth needs people able to translate the game into other languages from across the globe. If you consider yourself able to help, join the translation team for your language -- or if none has been established already, follow the instructions to start your own!<br /> <br /> * [[WesnothTranslations]] — includes a list of translation maintainers and useful links for prospective translators<br /> * [http://gettext.wesnoth.org Statistics]<br /> <br /> [[Category:Development]]</div>

Pentarctagon https://wiki.wesnoth.org/index.php?title=Release_Steps&diff=74442 2025-07-21T04:31:07Z

<p>Pentarctagon: </p> <hr /> <div>== Pre-release (stable only) ==<br /> * Start the string freeze two weeks before the release.<br /> * Do the pot update:<br /> &lt;nowiki&gt;<br /> scons pot-update update-po4a manual<br /> git add -A<br /> git commit -am &quot;pot-update and regenerate doc files&quot;&lt;/nowiki&gt;<br /> * Email the translator's mailing list stating that the string freeze is starting.<br /> <br /> == Release (stable and master branches) ==<br /> * Update [http://www.wesnoth.org/macro-reference.html macro-reference.html]:<br /> <br /> cd data/tools/<br /> make macro-reference.html<br /> * If stable<br /> scp macro-reference.html wesnoth@wesnoth.org:WWW/html/macro-reference.html<br /> * If master<br /> scp macro-reference.html wesnoth@wesnoth.org:WWW/html/macro-reference-1.&lt;version&gt;.html<br /> <br /> * Regenerate the game credits and paste the contents to [[Credits]] on the wiki:<br /> <br /> data/tools/about_cfg_to_wiki -w ./wesnoth &gt; ./about.wiki<br /> <br /> * Check the '''changelog_entries''' folder for entries and update the changelog as necessary.<br /> * Run the pot update (second time if this is a stable release).<br /> * Do the pre-tag commit (check a previous commit as an example - this removes the &quot;+dev&quot; suffix everywhere).<br /> * The the post-tag commit (check a previous commit as an example - this re-adds the &quot;+dev&quot; suffix everywhere).<br /> * Tag the pre-tag commit with:<br /> &lt;nowiki&gt;git tag -a &lt;version&gt; -m &quot;Wesnoth &lt;version&gt; (Alpha)&quot; &lt;commit hash&gt;&lt;/nowiki&gt;<br /> ::- (Alpha)/(Beta) is only added for dev releases depending on where we are in the release cycle.<br /> * Push the commits and the tag:<br /> &lt;nowiki&gt;git push<br /> git push origin &lt;version&gt;&lt;/nowiki&gt;<br /> * Ping the packagers on Discord that the release has been tagged:<br /> &lt;nowiki&gt;@packagers &lt;version&gt; has been tagged.&lt;/nowiki&gt;<br /> * Check that the new version is allowed on its respective multiplayer server.<br /> * Update the header in Discord's #development channel.<br /> * Upload music.zip and master.zip to SourceForge to the respective version's folder for use by Android<br /> ** master.zip contains the folders<br /> *** data (data/core/music/ is removed)<br /> *** fonts<br /> *** images<br /> *** sounds<br /> *** translations<br /> * Upload source code tarball to SourceForge and files.wesnoth.org (done by loonycyborg).<br /> * Send an email to the packagers mailing list (done by loonycyborg).<br /> * Upload the release to the various places Wesnoth is distributed (Steam, itch.io, SourceForge, macOS App Store, Flathub, F-Droid).<br /> ** Windows/Linux - handled by loonycyborg.<br /> ** macOS - handled by hrubymar.<br /> ** Android (F-Droid) - handled by LumiousE<br /> * Post the forum announcements.<br /> * Update the Downloads wiki page.<br /> ** url: https://wiki.wesnoth.org/Download<br /> ** dev template: https://wiki.wesnoth.org/Template:DevDownload#Development_.281.15_branch.29<br /> ** stable template: https://wiki.wesnoth.org/Template:StableDownload<br /> * Add the News forum post.<br /> * Post the Discord announcement.<br /> ** Make sure to publish it.<br /> ** Short link is: '''&lt;nowiki&gt;https://r.wesnoth.org/t#####&lt;/nowiki&gt;'''<br /> * Post the itch.io devlog (copy of the Discord announcement).<br /> * Update the wesnoth.org front page.<br /> ** See a previous version update commit to the '''wesmere''' repository.<br /> ** ssh into the website VM and execute the following shell commands (yes, it is specifically ''''make'''', not ''''make install''''!):<br /> &lt;nowiki&gt;sudo -iu wesnoth<br /> cd ~/git/wesmere/static<br /> git pull<br /> make&lt;/nowiki&gt;<br /> * Generate the Steam announcement by running the following command in your local wesnoth repository root:<br /> &lt;nowiki&gt;python3 data/tools/steam-changelog changelog.md &lt;version&gt; &gt; &lt;version&gt;.txt&lt;/nowiki&gt;<br /> * Post the Steam announcement.<br /> * Log into Wesnoth's Steam page.<br /> ** Click &quot;A Game Update&quot;.<br /> ** Pick &quot;Small Update&quot;.<br /> ** Paste the output of of the above python command into the event description.<br /> ** Click &quot;Link To Build&quot; and select the appropriate branch.<br /> ** Edit the appropriate .xcf file from the [https://github.com/wesnoth/resources/tree/master/social-media-assets Resources repository] ('''wesnoth_event_header.xcf''' for stable releases, '''wesnoth_beta_header.xcf''' for development releases) and export it to PNG.<br /> *** This requires the '''oldania''' font to be installed, which on Linux/Ubuntu-derivatives can be installed via the command:<br /> &lt;nowiki&gt;apt install fonts-adf-oldania&lt;/nowiki&gt;<br /> * Post the announcement to Fosstodon.<br /> * Post the announcement to Reddit. (Elvish_Hunter)<br /> ** Add the &quot;Development release&quot;/&quot;Stable release&quot; flair.<br /> ** Don't paste the link in the post, directly post it as a link.<br /> <br /> == New Stable Series ==<br /> === Beta 1 ===<br /> Write up the new Start page (ie: https://www.wesnoth.org/start/1.16/).<br /> <br /> === Beta 2 ===<br /> Make the new Start page available to Translators.<br /> <br /> === RC1 ===<br /> Before release, the new multiplayer server and add-ons server instances need to be setup. The server running the website status is owned by Iris - she needs to push updates to it.<br /> * Multiplayer server<br /> ** Needs no changes since it goes to port 15000 and then that redirects based on version. The existing dev multiplayer server will be reused as the new stable instance.<br /> ** The Discord website status bot and the site status page (https://status.wesnoth.org/ - bin/valen.pl) need to be updated to rename the dev version to the stable version.<br /> ** A new stable multiplayer instance needs to be added to the alternate server.<br /> <br /> * Add-ons server - The port is the version number, for example 1.16 is 15016, 1.18 is 15018, etc.<br /> ** C++ update (currently default_campaignd_port in addon/validation.cpp)<br /> ** Python update (data/tools/wesnoth/campaignserver_client.py)<br /> ** Website update (bin/valen.pl) in the valen repository to add the new instance.<br /> ** The Discord website status bot and the site status page (https://status.wesnoth.org/ - bin/valen.pl) need to be updated to add the new version.<br /> ** Add a 1.18 cron job for ~wesnoth/bin/update_addons in the websites VM and remove the 1.17 cron job.<br /> <br /> * Flatpak<br /> ** <br /> <br /> * Add screenshots to https://wiki.wesnoth.org/Screenshots<br /> <br /> * Start page - soft link the folder from the repository to the folder that shows up on the actual website:<br /> &lt;nowiki&gt;<br /> cd /srv/www/html/start<br /> ln -s /home/git/wesnoth/start/&lt;version&gt;&lt;/nowiki&gt;<br /> <br /> * Update ci_main.yml to use the new branch instead of the master branch.<br /> <br /> [[Category:Release_Notes]]</div>

Pentarctagon https://wiki.wesnoth.org/index.php?title=Release_Steps&diff=74441 2025-07-21T03:04:52Z

<p>Pentarctagon: </p> <hr /> <div>== Pre-release (stable only) ==<br /> * Start the string freeze two weeks before the release.<br /> * Do the pot update:<br /> &lt;nowiki&gt;<br /> scons pot-update update-po4a manual<br /> git add -A<br /> git commit -am &quot;pot-update and regenerate doc files&quot;&lt;/nowiki&gt;<br /> * Email the translator's mailing list stating that the string freeze is starting.<br /> <br /> == Release (stable and master branches) ==<br /> * Update [http://www.wesnoth.org/macro-reference.html macro-reference.html]:<br /> <br /> cd data/tools/<br /> make macro-reference.html<br /> * If stable<br /> scp macro-reference.html wesnoth@wesnoth.org:WWW/html/macro-reference.html<br /> * If master<br /> scp macro-reference.html wesnoth@wesnoth.org:WWW/html/macro-reference-1.&lt;version&gt;.html<br /> <br /> * Regenerate the game credits and paste the contents to [[Credits]] on the wiki:<br /> <br /> data/tools/about_cfg_to_wiki -w ./wesnoth &gt; ./about.wiki<br /> <br /> * Check the '''changelog_entries''' folder for entries and update the changelog as necessary.<br /> * Run the pot update (second time if this is a stable release).<br /> * Do the pre-tag commit (check a previous commit as an example - this removes the &quot;+dev&quot; suffix everywhere).<br /> * The the post-tag commit (check a previous commit as an example - this re-adds the &quot;+dev&quot; suffix everywhere).<br /> * Tag the pre-tag commit with:<br /> &lt;nowiki&gt;git tag -a &lt;version&gt; -m &quot;Wesnoth &lt;version&gt; (Alpha)&quot; &lt;commit hash&gt;&lt;/nowiki&gt;<br /> ::- (Alpha)/(Beta) is only added for dev releases depending on where we are in the release cycle.<br /> * Push the commits and the tag:<br /> &lt;nowiki&gt;git push<br /> git push origin &lt;version&gt;&lt;/nowiki&gt;<br /> * Ping the packagers on Discord that the release has been tagged:<br /> &lt;nowiki&gt;@packagers &lt;version&gt; has been tagged.&lt;/nowiki&gt;<br /> * Check that the new version is allowed on its respective multiplayer server.<br /> * Update the header in Discord's #development channel.<br /> * Add items to the Release Notes page on this wiki for the release.<br /> * Sync items on the Release Notes page to the changelog.<br /> * Upload source code tarball to SourceForge and files.wesnoth.org (done by loonycyborg).<br /> * Send an email to the packagers mailing list (done by loonycyborg).<br /> * Upload the release to the various places Wesnoth is distributed (Steam, itch.io, SourceForge, macOS App Store, Flathub, F-Droid).<br /> ** Windows/Linux - handled by loonycyborg.<br /> ** macOS - handled by hrubymar.<br /> ** Android (F-Droid) - handled by LumiousE<br /> * Post the forum announcements.<br /> * Update the Downloads wiki page.<br /> ** url: https://wiki.wesnoth.org/Download<br /> ** dev template: https://wiki.wesnoth.org/Template:DevDownload#Development_.281.15_branch.29<br /> ** stable template: https://wiki.wesnoth.org/Template:StableDownload<br /> * Add the News forum post.<br /> * Post the Discord announcement.<br /> ** Make sure to publish it.<br /> ** Short link is: '''&lt;nowiki&gt;https://r.wesnoth.org/t#####&lt;/nowiki&gt;'''<br /> * Post the itch.io devlog (copy of the Discord announcement).<br /> * Update the wesnoth.org front page.<br /> ** See a previous version update commit to the '''wesmere''' repository.<br /> ** ssh into the website VM and execute the following shell commands (yes, it is specifically ''''make'''', not ''''make install''''!):<br /> &lt;nowiki&gt;sudo -iu wesnoth<br /> cd ~/git/wesmere/static<br /> git pull<br /> make&lt;/nowiki&gt;<br /> * Generate the Steam announcement by running the following command in your local wesnoth repository root:<br /> &lt;nowiki&gt;python3 data/tools/steam-changelog changelog.md &lt;version&gt; &gt; &lt;version&gt;.txt&lt;/nowiki&gt;<br /> * Post the Steam announcement.<br /> * Log into Wesnoth's Steam page.<br /> ** Click &quot;A Game Update&quot;.<br /> ** Pick &quot;Small Update&quot;.<br /> ** Paste the output of of the above python command into the event description.<br /> ** Click &quot;Link To Build&quot; and select the appropriate branch.<br /> ** Edit the appropriate .xcf file from the [https://github.com/wesnoth/resources/tree/master/social-media-assets Resources repository] ('''wesnoth_event_header.xcf''' for stable releases, '''wesnoth_beta_header.xcf''' for development releases) and export it to PNG.<br /> *** This requires the '''oldania''' font to be installed, which on Linux/Ubuntu-derivatives can be installed via the command:<br /> &lt;nowiki&gt;apt install fonts-adf-oldania&lt;/nowiki&gt;<br /> * Post the announcement to Fosstodon.<br /> * Post the announcement to Reddit. (Elvish_Hunter)<br /> ** Add the &quot;Development release&quot;/&quot;Stable release&quot; flair.<br /> ** Don't paste the link in the post, directly post it as a link.<br /> <br /> == New Stable Series ==<br /> === Beta 1 ===<br /> Write up the new Start page (ie: https://www.wesnoth.org/start/1.16/).<br /> <br /> === Beta 2 ===<br /> Make the new Start page available to Translators.<br /> <br /> === RC1 ===<br /> Before release, the new multiplayer server and add-ons server instances need to be setup. The server running the website status is owned by Iris - she needs to push updates to it.<br /> * Multiplayer server<br /> ** Needs no changes since it goes to port 15000 and then that redirects based on version. The existing dev multiplayer server will be reused as the new stable instance.<br /> ** The Discord website status bot and the site status page (https://status.wesnoth.org/ - bin/valen.pl) need to be updated to rename the dev version to the stable version.<br /> ** A new stable multiplayer instance needs to be added to the alternate server.<br /> <br /> * Add-ons server - The port is the version number, for example 1.16 is 15016, 1.18 is 15018, etc.<br /> ** C++ update (currently default_campaignd_port in addon/validation.cpp)<br /> ** Python update (data/tools/wesnoth/campaignserver_client.py)<br /> ** Website update (bin/valen.pl) in the valen repository to add the new instance.<br /> ** The Discord website status bot and the site status page (https://status.wesnoth.org/ - bin/valen.pl) need to be updated to add the new version.<br /> ** Add a 1.18 cron job for ~wesnoth/bin/update_addons in the websites VM and remove the 1.17 cron job.<br /> <br /> * Flatpak<br /> ** <br /> <br /> * Add screenshots to https://wiki.wesnoth.org/Screenshots<br /> <br /> * Start page - soft link the folder from the repository to the folder that shows up on the actual website:<br /> &lt;nowiki&gt;<br /> cd /srv/www/html/start<br /> ln -s /home/git/wesnoth/start/&lt;version&gt;&lt;/nowiki&gt;<br /> <br /> * Update ci_main.yml to use the new branch instead of the master branch.<br /> <br /> [[Category:Release_Notes]]</div>

Pentarctagon https://wiki.wesnoth.org/index.php?title=Release_Steps&diff=74440 2025-07-21T02:51:54Z

<p>Pentarctagon: </p> <hr /> <div>== Pre-release (stable only) ==<br /> * Start the string freeze two weeks before the release.<br /> * Do the pot update:<br /> &lt;nowiki&gt;<br /> scons pot-update update-po4a manual<br /> git add -A<br /> git commit -am &quot;pot-update and regenerate doc files&quot;&lt;/nowiki&gt;<br /> * Email the translator's mailing list stating that the string freeze is starting.<br /> <br /> == Release (stable and master branches) ==<br /> * Update [http://www.wesnoth.org/macro-reference.html macro-reference.html]:<br /> <br /> cd data/tools/<br /> make macro-reference.html<br /> * If stable<br /> scp macro-reference.html wesnoth@wesnoth.org:WWW/html/macro-reference.html<br /> * If master<br /> scp macro-reference.html wesnoth@wesnoth.org:WWW/html/macro-reference-1.&lt;version&gt;.html<br /> <br /> * Regenerate the game credits and paste the contents to [[Credits]] on the wiki:<br /> <br /> data/tools/about_cfg_to_wiki -w ./wesnoth &gt; ./about.wiki<br /> <br /> * Check the '''changelog_entries''' folder for entries and update the changelog as necessary.<br /> * Run the pot update (second time if this is a stable release).<br /> * Do the pre-tag commit (check a previous commit as an example - this removes the &quot;+dev&quot; suffix everywhere).<br /> * The the post-tag commit (check a previous commit as an example - this re-adds the &quot;+dev&quot; suffix everywhere).<br /> * Tag the pre-tag commit with:<br /> &lt;nowiki&gt;git tag -a &lt;version&gt; -m &quot;Wesnoth &lt;version&gt; (Alpha)&quot; &lt;commit hash&gt;&lt;/nowiki&gt;<br /> ::- (Alpha)/(Beta) is only added for dev releases depending on where we are in the release cycle.<br /> * Push the commits and the tag:<br /> &lt;nowiki&gt;git push<br /> git push origin &lt;version&gt;&lt;/nowiki&gt;<br /> * Ping the packagers on Discord that the release has been tagged:<br /> &lt;nowiki&gt;@packagers &lt;version&gt; has been tagged.&lt;/nowiki&gt;<br /> * Check that the new version is allowed on its respective multiplayer server.<br /> * Update the header in Discord's #development channel.<br /> * Add items to the Release Notes page on this wiki for the release.<br /> * Sync items on the Release Notes page to the changelog.<br /> * Upload source code tarball to SourceForge and files.wesnoth.org (done by loonycyborg).<br /> * Send an email to the packagers mailing list (done by loonycyborg).<br /> * Upload the release to the various places Wesnoth is distributed (Steam, itch.io, SourceForge, macOS App Store, Flathub).<br /> ** Windows/Linux - handled by loonycyborg.<br /> ** macOS - handled by hrubymar.<br /> ** Android (F-Droid) - handled by LumiousE<br /> * Post the forum announcements.<br /> * Update the Downloads wiki page.<br /> ** url: https://wiki.wesnoth.org/Download<br /> ** dev template: https://wiki.wesnoth.org/Template:DevDownload#Development_.281.15_branch.29<br /> ** stable template: https://wiki.wesnoth.org/Template:StableDownload<br /> * Add the News forum post.<br /> * Post the Discord announcement.<br /> ** Make sure to publish it.<br /> ** Short link is: '''&lt;nowiki&gt;https://r.wesnoth.org/t#####&lt;/nowiki&gt;'''<br /> * Post the itch.io devlog (copy of the Discord announcement).<br /> * Update the wesnoth.org front page.<br /> ** See a previous version update commit to the '''wesmere''' repository.<br /> ** ssh into the website VM and execute the following shell commands (yes, it is specifically ''''make'''', not ''''make install''''!):<br /> &lt;nowiki&gt;sudo -iu wesnoth<br /> cd ~/git/wesmere/static<br /> git pull<br /> make&lt;/nowiki&gt;<br /> * Generate the Steam announcement by running the following command in your local wesnoth repository root:<br /> &lt;nowiki&gt;python3 data/tools/steam-changelog changelog.md &lt;version&gt; &gt; &lt;version&gt;.txt&lt;/nowiki&gt;<br /> * Post the Steam announcement.<br /> * Log into Wesnoth's Steam page.<br /> ** Click &quot;A Game Update&quot;.<br /> ** Pick &quot;Small Update&quot;.<br /> ** Paste the output of of the above python command into the event description.<br /> ** Click &quot;Link To Build&quot; and select the appropriate branch.<br /> ** Edit the appropriate .xcf file from the [https://github.com/wesnoth/resources/tree/master/social-media-assets Resources repository] ('''wesnoth_event_header.xcf''' for stable releases, '''wesnoth_beta_header.xcf''' for development releases) and export it to PNG.<br /> *** This requires the '''oldania''' font to be installed, which on Linux/Ubuntu-derivatives can be installed via the command:<br /> &lt;nowiki&gt;apt install fonts-adf-oldania&lt;/nowiki&gt;<br /> * Post the announcement to Fosstodon.<br /> * Post the announcement to Reddit. (Elvish_Hunter)<br /> ** Add the &quot;Development release&quot;/&quot;Stable release&quot; flair.<br /> ** Don't paste the link in the post, directly post it as a link.<br /> <br /> == New Stable Series ==<br /> === Beta 1 ===<br /> Write up the new Start page (ie: https://www.wesnoth.org/start/1.16/).<br /> <br /> === Beta 2 ===<br /> Make the new Start page available to Translators.<br /> <br /> === RC1 ===<br /> Before release, the new multiplayer server and add-ons server instances need to be setup. The server running the website status is owned by Iris - she needs to push updates to it.<br /> * Multiplayer server<br /> ** Needs no changes since it goes to port 15000 and then that redirects based on version. The existing dev multiplayer server will be reused as the new stable instance.<br /> ** The Discord website status bot and the site status page (https://status.wesnoth.org/ - bin/valen.pl) need to be updated to rename the dev version to the stable version.<br /> ** A new stable multiplayer instance needs to be added to the alternate server.<br /> <br /> * Add-ons server - The port is the version number, for example 1.16 is 15016, 1.18 is 15018, etc.<br /> ** C++ update (currently default_campaignd_port in addon/validation.cpp)<br /> ** Python update (data/tools/wesnoth/campaignserver_client.py)<br /> ** Website update (bin/valen.pl) in the valen repository to add the new instance.<br /> ** The Discord website status bot and the site status page (https://status.wesnoth.org/ - bin/valen.pl) need to be updated to add the new version.<br /> ** Add a 1.18 cron job for ~wesnoth/bin/update_addons in the websites VM and remove the 1.17 cron job.<br /> <br /> * Flatpak<br /> ** <br /> <br /> * Add screenshots to https://wiki.wesnoth.org/Screenshots<br /> <br /> * Start page - soft link the folder from the repository to the folder that shows up on the actual website:<br /> &lt;nowiki&gt;<br /> cd /srv/www/html/start<br /> ln -s /home/git/wesnoth/start/&lt;version&gt;&lt;/nowiki&gt;<br /> <br /> * Update ci_main.yml to use the new branch instead of the master branch.<br /> <br /> [[Category:Release_Notes]]</div>

Pentarctagon https://wiki.wesnoth.org/index.php?title=Template:DevDownload&diff=74409 2025-06-23T18:23:35Z

<p>Pentarctagon: </p> <hr /> <div>&lt;noinclude&gt;<br /> == Development (1.19 branch) ==<br /> &lt;/noinclude&gt;<br /> ==== Windows (10 1903 and later) {{{4|}}} ====<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.13 | filename=wesnoth-1.19.13-win64.exe |<br /> hash=7a096d9b0171b59b1fa6d400b0537ea11b5ffc6702dc821f09b9250486fba30a}}<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.12 | filename=wesnoth-1.19.12-win64.exe |<br /> hash=97f88140d55598f876ea4e148358fad1187437bae488c1e5d63bcd2bbd6aeaed}}<br /> <br /> ==== macOS (10.13 and later) {{{5|}}} ====<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.13 | filename=Wesnoth_1.19.13.dmg |<br /> hash=6b2a854e96ed1ce0e06f58ba21a59d20e20ca259152c083fd330b8c0a681183f}}<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.12 | filename=Wesnoth_1.19.12.dmg |<br /> hash=4361644e6ee6c9c2845080db2ebd025fa005fb601321dee98f261f345e9c7317}}<br /> <br /> ==== Source code ====<br /> * [https://github.com/wesnoth/wesnoth/blob/master/INSTALL.md Compiling Wesnoth] - How to compile the source code<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.13 | filename=wesnoth-1.19.13.tar.bz2 |<br /> hash=1eea4bde4ccaf8afef6f502895bcde2bec42e8acec561c3944ac0703d8df4dde}}<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.12 | filename=wesnoth-1.19.12.tar.bz2 |<br /> hash=9142678e9afd021cacb61ebef3959053040cf2c1b2a0f2996d7978329662c381}}</div>

Pentarctagon https://wiki.wesnoth.org/index.php?title=Template:DevDownload&diff=74303 2025-06-02T16:47:48Z

<p>Pentarctagon: </p> <hr /> <div>&lt;noinclude&gt;<br /> == Development (1.19 branch) ==<br /> &lt;/noinclude&gt;<br /> ==== Windows (10 1903 and later) {{{4|}}} ====<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.12 | filename=wesnoth-1.19.12-win64.exe |<br /> hash=97f88140d55598f876ea4e148358fad1187437bae488c1e5d63bcd2bbd6aeaed}}<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.11 | filename=wesnoth-1.19.11-win64.exe |<br /> hash=54e82026505108c48f9cebe8e17c7d2f6abd00ce9a9bf3bcd65bff77e927aae8}}<br /> <br /> ==== macOS (10.13 and later) {{{5|}}} ====<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.12 | filename=Wesnoth_1.19.12.dmg |<br /> hash=4361644e6ee6c9c2845080db2ebd025fa005fb601321dee98f261f345e9c7317}}<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.11 | filename=Wesnoth_1.19.11.dmg |<br /> hash=8563f3e6de8e0979e95c91441f85b61a76260fffd15ccdd42224be3a50c2b653}}<br /> <br /> ==== Source code ====<br /> * [https://github.com/wesnoth/wesnoth/blob/master/INSTALL.md Compiling Wesnoth] - How to compile the source code<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.12 | filename=wesnoth-1.19.12.tar.bz2 |<br /> hash=9142678e9afd021cacb61ebef3959053040cf2c1b2a0f2996d7978329662c381}}<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.11 | filename=wesnoth-1.19.11.tar.bz2 |<br /> hash=8a2397059080020f9505d17fd0ab3121e39eb2288838b4f43a4adebb1b87b0bc}}</div>

Pentarctagon https://wiki.wesnoth.org/index.php?title=Template:StableDownload&diff=74302 2025-06-02T16:46:53Z

<p>Pentarctagon: </p> <hr /> <div>&lt;noinclude&gt;<br /> == Stable (1.18 branch) ==<br /> &lt;/noinclude&gt;<br /> ==== Windows (10 1903 and later, 64-bit only) {{{4|}}} ====<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth-1.18 |<br /> version=1.18.5 | filename=wesnoth-1.18.5-win64.exe |<br /> hash=915d9c0374221782fbfaecd3ac8d8833b470c6ed6c059e6086d5082a28edf80f}}<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth-1.18 |<br /> version=1.18.4 | filename=wesnoth-1.18.4-win64.exe |<br /> hash=d7211ba46831bcc456a33cdb66d6c05cf55866eb3314c0880b72b1c8df324ac2}}<br /> <br /> ==== macOS (10.12 and later) {{{5|}}} ====<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth-1.18 |<br /> version=1.18.5 | filename=Wesnoth_1.18.5.dmg |<br /> hash=73e34ee58a7c81055bdf94f1b0646a524a992235682ce227fb8d3829af4061f1}}<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth-1.18 |<br /> version=1.18.4 | filename=Wesnoth_1.18.4.dmg |<br /> hash=a12904628042e42c2c1dd7292c54c72a199a591c3e13d823ac3236a421e1fbb8}}<br /> <br /> ==== Source code ====<br /> * [https://github.com/wesnoth/wesnoth/blob/master/INSTALL.md Compiling Wesnoth] - How to compile the source code<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth-1.18 |<br /> version=1.18.5 | filename=wesnoth-1.18.5.tar.bz2 |<br /> hash=e15db3caf446d91d389fc275f10c1a9e7ca3c6176c3b8ce94f5ee4a7a0c81bd6}}<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth-1.18 |<br /> version=1.18.4 | filename=wesnoth-1.18.4.tar.bz2 |<br /> hash=d7211ba46831bcc456a33cdb66d6c05cf55866eb3314c0880b72b1c8df324ac2}}</div>

Pentarctagon https://wiki.wesnoth.org/index.php?title=Template:DevDownload&diff=74285 2025-05-05T18:58:27Z

<p>Pentarctagon: </p> <hr /> <div>&lt;noinclude&gt;<br /> == Development (1.19 branch) ==<br /> &lt;/noinclude&gt;<br /> ==== Windows (10 1903 and later) {{{4|}}} ====<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.11 | filename=wesnoth-1.19.11-win64.exe |<br /> hash=54e82026505108c48f9cebe8e17c7d2f6abd00ce9a9bf3bcd65bff77e927aae8}}<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.10 | filename=wesnoth-1.19.10-win64.exe |<br /> hash=8ad9b6e55102d058ba54b3f45020b9b37ee401a0f6c6aa5df442e478a5b809c9}}<br /> <br /> ==== macOS (10.13 and later) {{{5|}}} ====<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.11 | filename=Wesnoth_1.19.11.dmg |<br /> hash=8563f3e6de8e0979e95c91441f85b61a76260fffd15ccdd42224be3a50c2b653}}<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.10 | filename=Wesnoth_1.19.10.dmg |<br /> hash=8b73b69f908e9c894d3229abdf5f55e40ce6aabfca5cad90a8e9e6c050e1b377}}<br /> <br /> ==== Source code ====<br /> * [https://github.com/wesnoth/wesnoth/blob/master/INSTALL.md Compiling Wesnoth] - How to compile the source code<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.11 | filename=wesnoth-1.19.11.tar.bz2 |<br /> hash=8a2397059080020f9505d17fd0ab3121e39eb2288838b4f43a4adebb1b87b0bc}}<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.10 | filename=wesnoth-1.19.10.tar.bz2 |<br /> hash=c435d76d35bb336ad64ac80040c8b9e046571f80b51794f16a41b99b6b99e78f}}</div>

Pentarctagon https://wiki.wesnoth.org/index.php?title=Template:DevDownload&diff=74233 2025-03-23T17:03:20Z

<p>Pentarctagon: </p> <hr /> <div>&lt;noinclude&gt;<br /> == Development (1.19 branch) ==<br /> &lt;/noinclude&gt;<br /> ==== Windows (10 1903 and later) {{{4|}}} ====<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.10 | filename=wesnoth-1.19.10-win64.exe |<br /> hash=8ad9b6e55102d058ba54b3f45020b9b37ee401a0f6c6aa5df442e478a5b809c9}}<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.9 | filename=wesnoth-1.19.9-win64.exe |<br /> hash=ec5217a67846b18678d2585304e154c6e009f1b45c5a85d09459c629510f84e4}}<br /> <br /> ==== macOS (10.13 and later) {{{5|}}} ====<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.10 | filename=Wesnoth_1.19.10.dmg |<br /> hash=8b73b69f908e9c894d3229abdf5f55e40ce6aabfca5cad90a8e9e6c050e1b377}}<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.9 | filename=Wesnoth_1.19.9.dmg |<br /> hash=e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855}}<br /> <br /> ==== Source code ====<br /> * [https://github.com/wesnoth/wesnoth/blob/master/INSTALL.md Compiling Wesnoth] - How to compile the source code<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.10 | filename=wesnoth-1.19.10.tar.bz2 |<br /> hash=c435d76d35bb336ad64ac80040c8b9e046571f80b51794f16a41b99b6b99e78f}}<br /> * {{DownloadItem | label={{{1|Current Version}}} | group=wesnoth |<br /> version=1.19.9 | filename=wesnoth-1.19.9.tar.bz2 |<br /> hash=db0349490324ebd7a6f4484bbc9614dc6b046fff084e36682fcf13de9f2db3b8}}</div>

Pentarctagon