https://wiki.wesnoth.org/api.php?action=feedcontributions&user=Loonycyborg&feedformat=atomThe Battle for Wesnoth Wiki - User contributions [en]2024-03-28T19:19:12ZUser contributionsMediaWiki 1.31.16https://wiki.wesnoth.org/index.php?title=MultiplayerServerWML&diff=68408MultiplayerServerWML2021-08-11T12:16:42Z<p>Loonycyborg: /* The handshake */</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 "socket number"). 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. 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. "1.0*,1.2*,1.4*,1.7*,1.8*")<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_reminder''': If "yes" the client requests the server to send a password reminder for the provided username.<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''': "yes" if the user is a moderator, "no" otherwise.<br />
** or '''[error]'''<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 "yes" 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 />
**** '''turn''': The current turn/max turn.<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''': "yes" if the player is in the lobby; "no" 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 />
<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 />
== Room commands ==<br />
Note: the room commands are in general and are subject to change. Room commands are not implemented on 1.13+ servers.<br />
* '''[room_join]'''<br />
** '''room''': The room name to join<br />
** '''player''': (filled by server in response message sent to all room members) the player that joins the room<br />
** '''[members]''': member list sent to the player that joined<br />
*** '''[member]''': (repeated) members<br />
**** '''name''': This member's name<br />
* '''[room_part]'''<br />
** '''room''': The room name to part (leave). Leaving the lobby is not allowed.<br />
** '''player''': (filled by server in response message sent to all room members) the player that leaves the room<br />
* '''[room_query]''': specific room-related queries.<br />
** '''[rooms]''': List rooms created on the server, or<br />
** '''[names]''': List members of a given room<br />
*** '''room''': The room name (if applicable)<br />
** '''[persist]''': Check or set room persistance<br />
*** '''value''': (optional) set room persistance to this value (yes/no)<br />
* '''[room_query_response]''': contains specific response to a room_query.<br />
** '''message''': optional text message response<br />
** '''room''': room name (if applicable)<br />
** '''[rooms]''': room list<br />
*** '''[room]''': (repeated) rooms<br />
**** '''name''': This room's name<br />
** '''[members]''': member list<br />
*** '''[member]''': (repeated) members<br />
**** '''name''': This member's name<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 "game")/quitting([observer] - joining the lobby "game") a game<br />
** '''name''': Username of the player/observer.<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 />
<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 />
<br />
== In-game communication ==<br />
<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''': "termination" <br />
** '''condition''': the termination reason<br />
<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: "human" or "human_ai"<br />
** '''own_side''': "yes"<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. ("ai", "network")<br />
<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 />
* '''[turn]'''<br />
** '''[command]''': (repeated) can contain all the tags you can find in a 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 />
== Administrative commands ==<br />
* '''[query]'''<br />
** '''type''': The type of query. See [[ServerAdministration]] for details.<br />
<br />
== See also ==<br />
[[Category:WML Reference]]<br />
[[Category:Server Documentation]]</div>Loonycyborghttps://wiki.wesnoth.org/index.php?title=MultiplayerServerWML&diff=68407MultiplayerServerWML2021-08-11T12:06:09Z<p>Loonycyborg: /* The login procedure */</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 "socket number"). 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/master/src/server/common/server_base.hpp#L66 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. 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. "1.0*,1.2*,1.4*,1.7*,1.8*")<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_reminder''': If "yes" the client requests the server to send a password reminder for the provided username.<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''': "yes" if the user is a moderator, "no" otherwise.<br />
** or '''[error]'''<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 "yes" 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 />
**** '''turn''': The current turn/max turn.<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''': "yes" if the player is in the lobby; "no" 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 />
<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 />
== Room commands ==<br />
Note: the room commands are in general and are subject to change. Room commands are not implemented on 1.13+ servers.<br />
* '''[room_join]'''<br />
** '''room''': The room name to join<br />
** '''player''': (filled by server in response message sent to all room members) the player that joins the room<br />
** '''[members]''': member list sent to the player that joined<br />
*** '''[member]''': (repeated) members<br />
**** '''name''': This member's name<br />
* '''[room_part]'''<br />
** '''room''': The room name to part (leave). Leaving the lobby is not allowed.<br />
** '''player''': (filled by server in response message sent to all room members) the player that leaves the room<br />
* '''[room_query]''': specific room-related queries.<br />
** '''[rooms]''': List rooms created on the server, or<br />
** '''[names]''': List members of a given room<br />
*** '''room''': The room name (if applicable)<br />
** '''[persist]''': Check or set room persistance<br />
*** '''value''': (optional) set room persistance to this value (yes/no)<br />
* '''[room_query_response]''': contains specific response to a room_query.<br />
** '''message''': optional text message response<br />
** '''room''': room name (if applicable)<br />
** '''[rooms]''': room list<br />
*** '''[room]''': (repeated) rooms<br />
**** '''name''': This room's name<br />
** '''[members]''': member list<br />
*** '''[member]''': (repeated) members<br />
**** '''name''': This member's name<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 "game")/quitting([observer] - joining the lobby "game") a game<br />
** '''name''': Username of the player/observer.<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 />
<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 />
<br />
== In-game communication ==<br />
<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''': "termination" <br />
** '''condition''': the termination reason<br />
<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: "human" or "human_ai"<br />
** '''own_side''': "yes"<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. ("ai", "network")<br />
<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 />
* '''[turn]'''<br />
** '''[command]''': (repeated) can contain all the tags you can find in a 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 />
== Administrative commands ==<br />
* '''[query]'''<br />
** '''type''': The type of query. See [[ServerAdministration]] for details.<br />
<br />
== See also ==<br />
[[Category:WML Reference]]<br />
[[Category:Server Documentation]]</div>Loonycyborghttps://wiki.wesnoth.org/index.php?title=MultiplayerServerWML&diff=68406MultiplayerServerWML2021-08-11T11:58:56Z<p>Loonycyborg: </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 "socket number"). 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/master/src/server/common/server_base.hpp#L66 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. 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. "1.0*,1.2*,1.4*,1.7*,1.8*")<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_reminder''': If "yes" the client requests the server to send a password reminder for the provided username.<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).<br />
<br />
* server response<br />
** '''[join_lobby]'''<br />
*** '''is_moderator''': "yes" if the user is a moderator, "no" otherwise.<br />
** or '''[error]'''<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 "yes" 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 />
**** '''turn''': The current turn/max turn.<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''': "yes" if the player is in the lobby; "no" 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 />
<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 />
== Room commands ==<br />
Note: the room commands are in general and are subject to change. Room commands are not implemented on 1.13+ servers.<br />
* '''[room_join]'''<br />
** '''room''': The room name to join<br />
** '''player''': (filled by server in response message sent to all room members) the player that joins the room<br />
** '''[members]''': member list sent to the player that joined<br />
*** '''[member]''': (repeated) members<br />
**** '''name''': This member's name<br />
* '''[room_part]'''<br />
** '''room''': The room name to part (leave). Leaving the lobby is not allowed.<br />
** '''player''': (filled by server in response message sent to all room members) the player that leaves the room<br />
* '''[room_query]''': specific room-related queries.<br />
** '''[rooms]''': List rooms created on the server, or<br />
** '''[names]''': List members of a given room<br />
*** '''room''': The room name (if applicable)<br />
** '''[persist]''': Check or set room persistance<br />
*** '''value''': (optional) set room persistance to this value (yes/no)<br />
* '''[room_query_response]''': contains specific response to a room_query.<br />
** '''message''': optional text message response<br />
** '''room''': room name (if applicable)<br />
** '''[rooms]''': room list<br />
*** '''[room]''': (repeated) rooms<br />
**** '''name''': This room's name<br />
** '''[members]''': member list<br />
*** '''[member]''': (repeated) members<br />
**** '''name''': This member's name<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 "game")/quitting([observer] - joining the lobby "game") a game<br />
** '''name''': Username of the player/observer.<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 />
<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 />
<br />
== In-game communication ==<br />
<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''': "termination" <br />
** '''condition''': the termination reason<br />
<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: "human" or "human_ai"<br />
** '''own_side''': "yes"<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. ("ai", "network")<br />
<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 />
* '''[turn]'''<br />
** '''[command]''': (repeated) can contain all the tags you can find in a 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 />
== Administrative commands ==<br />
* '''[query]'''<br />
** '''type''': The type of query. See [[ServerAdministration]] for details.<br />
<br />
== See also ==<br />
[[Category:WML Reference]]<br />
[[Category:Server Documentation]]</div>Loonycyborghttps://wiki.wesnoth.org/index.php?title=ReleasingWesnoth&diff=65346ReleasingWesnoth2020-02-14T18:08:00Z<p>Loonycyborg: </p>
<hr />
<div>== todo steps to add ==<br />
<br />
Mac package: details in projectfiles/Xcode/README.md<br />
<br />
Windows package: ?<br />
<br />
Android package: (third party, but still, details?)<br />
<br />
iOS package: ?<br />
<br />
For us:<br />
<br />
* forum post in News<br />
* forum post in Announcements<br />
* Updating the download page on the wiki<br />
* Updating the front page<br />
* rebuild the front page (<code>git pull</code> and <code>make</code> after SSHing to www.wesnoth.org)<br />
* Announcing the release on Discord<br />
* Announcing the release on Steam.<br />
** This included making a new header graphic if it's a stable release.<br />
* Announcing the release on Twitter with a link to the forum post<br />
<br />
== Version numbering ==<br />
<br />
We use the even/odd minor number convention. A.B.C where B is even means stable and B is odd means unstable/development version.<br />
<br />
1.15.x are development versions for 1.16.0.<br />
<br />
A development version should be called "beta 1" when no further API changes are expected, nor string changes. At that point, translators and add-on authors can start working on 1.15.x without worrying that the rug be swept under their feet.<br />
<br />
A development version should be called "release candidate 1" when all blockers have been fixed.<br />
<br />
During the beta/RC/stable stages, no API changes (e.g., Lua/WML interfaces or semantics) should be made , nor large-scale or destabilizing internal changes, nor build dependencies changed. That's true from "1.15.x (1.16 beta 1)" and for the rest of the 1.16.x releases too. Such changes should be made in 1.17.x for 1.18.<br />
<br />
== Tools ==<br />
<br />
Tools needed for releasing:<br />
* Normal tools to build everything from Wesnoth and to fetch the repository head (cmake based assumed for this page!)<br />
* <code>po4a</code> (to be able to update the manpages and manual)<br />
* <code>docbook-xml-dtd</code> (to generate the manual HTML files)<br />
* <code>xdelta</code> 1.x (to create the Xdelta files)<br />
* <code>rsync</code> for upload of tarballs<br />
<br />
Tools for other processes:<br />
* <code>optipng</code> (only for needed to run <code>utils/wesnoth-optipng</code>, not for normal releases)<br />
* <code>imagemagick</code> (tool <code>convert</code>, only for needed to run <code>utils/wesnoth-optipng</code>, not for normal releases)<br />
* <code>advancecomp</code> (tool <code>advdef</code>, only for needed to run <code>utils/wesnoth-optipng</code>, not for normal releases)<br />
<br />
== General maintenance ==<br />
<br />
Not strictly release associated though the pot-update part should be done right before every release.<br />
<br />
* Run <code>utils/wesnoth-optipng</code> from the main directory of the checkout every now and then (read: <b>very</b> rarely, because it enlarges the Git repository for <i>very</i> negligible reductions in distribution size), requires the packages optipng, imagemagick and advancecomp<br />
* Run a <code>pot-update</code> regularly, once shortly before the release and before each string-freeze (including string-freezes in preparation for stable releases). This involves the following steps as of 1.13.3:<br />
<br />
# target "pot-update" regenerates pot files and updates po files according to them<br />
# target "update-po4a" reruns po4a for man pages and manual<br />
# target "manual" regenerates manual<br />
scons pot-update update-po4a manual<br />
<br />
# Make sure that no new files were created in doc/, if new manpages/manuals were created, add them<br />
git status doc/<br />
<br />
# Commit the bunch of updated po files and manpages/manuals<br />
git commit doc/ po/<br />
<br />
(the following commands should be run but are usually forgotten...)<br />
* Run <code>make lint</code> inside <code>data/tools</code> (runs <code>wmllint</code> with appropriate options), fix warnings or prod campaign and content maintainers as needed<br />
* Run <code>make reindent</code> from <code>data/tools</code> to reindent all mainline WML according to our conventions (probably don't want to do this too often as it may inconvenience coders)<br />
* Have a look at the pages from the category [[:Category:Review_on_Release|Review on Release]]<br />
* If it's a 1.foo.0 release, start a new campaignd instance on add-ons.wesnoth.org and update the port numbers as in https://github.com/wesnoth/wesnoth/commit/211f14176ce57509003ca4542d388c526157093c<br />
* Announce to developers the string freeze start date (deadline for string changes) and the release cutoff date (deadline for commits)<br />
<br />
== Release tasks ==<br />
<br />
=== Preparation steps ===<br />
* Merge the fixes on [[SpellingMistakes]]<br />
* Review issues in the relevant labels (probably these? [https://github.com/wesnoth/wesnoth/labels/Blocker Blocker], [https://github.com/wesnoth/wesnoth/labels/Regression Regression], [https://github.com/wesnoth/wesnoth/labels/Urgent Urgent], and either [https://github.com/wesnoth/wesnoth/labels/Fwdport Fwdport] or [https://github.com/wesnoth/wesnoth/labels/Backport Backport] depending on what branch you're releasing) and milestones (for example, [https://github.com/wesnoth/wesnoth/milestone/9 1.15.2] and [https://github.com/wesnoth/wesnoth/milestone/13 1.16.0], if a development release; just [https://github.com/wesnoth/wesnoth/milestone/17 1.14.9], if a stable release).<br />
** For 1.15.3, review the [https://github.com/wesnoth/wesnoth/milestone/20 pre-1.16.0 string freeze] issues<br />
* Review the list of issues for the ''previous'' patch release (1.15.1 or 1.14.8), make sure it's empty.<br />
* Make sure to run and commit a pot-update (see above), and update to the latest revision of the branch if needed. At this point you should warn people to stop pushing commits to the branch you'll be using for the release so as to avoid last-minute work sync issues or new unexpected bugs.<br />
* Check <code>changelog</code> and <code>players_changelog</code> for completeness and correctness, line wrap to 80 columns.<br />
* Bump the version numbers in <code>src/wesconfig.h</code>, <code>Doxyfile</code>, <code>changelog</code>, <code>players_changelog</code>, and <code>projectfiles/Xcode/Info.plist</code> and commit. Note that as of version 1.13.2 there are additional <code>RC_VERSION_*</code> macros in <code>src/wesconfig.h</code> needed by Windows builds. Since unlike <code>VERSION</code> these aren't freeform values, they should represent the next release version whenever <code>VERSION</code> represents an in-dev version (e.g. if <code>VERSION</code> is <code>1.13.2+dev</code>, the <code>RC_VERSION_*</code> macros should have the values for <code>1.13.3</code> instead).<br />
<br />
=== Generating the files ===<br />
<br />
# Update the git checkout, just to be sure that you have the<br />
# latest version<br />
<br />
git pull --rebase<br />
<br />
# Export the git checkout into a release tar archive (substitute<br />
# $VERSION with the release version number and $BRANCH with the<br />
# source branch). This will automatically exclude unwanted<br />
# directories from the archive following export-ignore rules in<br />
# .gitattributes<br />
<br />
git archive --format=tar --prefix="wesnoth-$VERSION/" $BRANCH > "wesnoth-$VERSION.tar"<br />
<br />
# Create the xdelta patch for the archives (this assumes that the<br />
# uncompressed $OLDVERSION tar archive is present!)<br />
<br />
xdelta delta wesnoth-$OLDVERSION.tar wesnoth-$VERSION.tar wesnoth-$OLDVERSION.tar-wesnoth-$VERSION.tar.xdelta<br />
<br />
# Compress the tarball<br />
<br />
bzip2 wesnoth-$VERSION.tar<br />
<br />
# Create the SHA256 sum for the tarball<br />
<br />
sha256sum wesnoth-$VERSION.tar.bz2 > wesnoth-$VERSION.tar.bz2.sha256<br />
<br />
== File upload ==<br />
<br />
The following files should be ready for upload now:<br />
<br />
* <code>wesnoth-$VERSION.tar.bz2</code><br />
* <code>wesnoth-$VERSION.tar.bz2.sha256</code><br />
* <code>wesnoth-$OLDVERSION.tar-wesnoth-$VERSION.tar.xdelta</code><br />
<br />
You must upload these files to SourceForge.net and to <code>files.wesnoth.org/releases/</code> (as backup). Since the tarballs are very large it's recommended to use rsync via SSH instead of web uploads to guarantee their integrity. After uploading to wesnoth.org it might save time to rsync to SF.net from there.<br />
<br />
For uploading to wesnoth.org, you will need to ask the site administrators for help with setting up your SSH configuration, as well as determining the destination path for the files.<br />
<br />
# Upload to files.wesnoth.org (path for reference purposes only,<br />
# does not reflect actual server set-up).<br />
<br />
rsync -avP -e ssh <FILES> <USERNAME>@wesnoth.org:WWW/html/files/<br />
<br />
# Upload to SF.net:<br />
#<br />
# * STREAM: replace with 'wesnoth' for development releases and<br />
# 'wesnoth-X.Y' for a stable release of the X.Y series.<br />
# * RELEASENAME: replace with the release name, e.g.<br />
# 'wesnoth-X.Y.Z'.<br />
<br />
rsync -avP -e ssh <FILES> <USERNAME>,wesnoth@frs.sourceforge.net:/home/frs/project/w/we/wesnoth/<STREAM>/<RELEASENAME><br />
<br />
== Build the release for testing ==<br />
<br />
You can build the release for testing while the upload is in progress. Before installing the test build make sure that no old leftover files are there, and also remove the old preferences or (preferably) use the <code>utils/wesnoth-defaults</code> script found in the repository to use a throwaway preferences dir.<br />
<br />
# Depending on whether you already compressed the tarball or not<br />
tar -xvf wesnoth-$VERSION.tar<br />
tar -xvf wesnoth-$VERSION.tar.bz2<br />
<br />
cd wesnoth-$VERSION && mkdir build && cd build<br />
<br />
# CMake command to create a test build with suffix -X.Y.Z to be<br />
# installed to /opt/wesnoth-X.Y.Z instead of /usr/local<br />
cmake .. \<br />
-DCMAKE_INSTALL_PREFIX=/opt/wesnoth-X.Y.Z \<br />
-DENABLE_SERVER=TRUE \<br />
-DENABLE_CAMPAIGN_SERVER=TRUE \<br />
-DPREFERENCES_DIR=.wesnoth-X.Y.Z \<br />
-DBINARY_SUFFIX=-X.Y.Z \<br />
-DENABLE_NOTIFICATIONS=TRUE \<br />
-DENABLE_STRICT_COMPILATION=TRUE<br />
<br />
# Build<br />
make -j<N><br />
<br />
# install<br />
sudo make install<br />
<br />
Now cd somewhere else and run the installed copy of the game (e.g. <code>/opt/wesnoth-X.Y.Z/bin/wesnoth</code>). Running right from the sources is '''not''' enough to be sure that everything works as expected.<br />
<br />
== Test the build ==<br />
This at least includes the following:<br />
<br />
* Start the editor, check if creating a map is possible<br />
* Start the game and try to connect to the official multiplayer server and to the add-on server<br />
* Start the server, connect to it using the game to see if you can enter the lobby<br />
* Check if in the game each campaign does start<br />
* Check if you can start the in-game help and the credits<br />
* Check if it is possible to create a local game<br />
* Play at least one game/scenario (or droid your side to let the AI play), this can either be a normal campaign scenario or a multiplayer game<br />
<br />
If all of those points are working as expected, go on, if not, fix the problems and restart from the very beginning.<br />
<br />
== Tagging and extra release related steps ==<br />
<br />
If everything works as expected, tag your release. Just use the version number (e.g. <code>1.13.2</code> or <code>1.14.0</code>) for the tag, no need to add <code>wesnoth-</code> in front:<br />
<br />
git tag -a -m "Wesnoth $VERSION" $VERSION HEAD && git push $VERSION<br />
<br />
Update [http://www.wesnoth.org/macro-reference.html macro-reference.html]:<br />
<br />
cd data/tools/<br />
make macro-reference.html<br />
scp macro-reference.html wesnoth@wesnoth.org:WWW/html/macro-reference.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 <PATH TO GAME EXECUTABLE> > about.wiki<br />
<br />
== Alternative post-tag package creation method ==<br />
<br />
This method requires tagging release before generating tarballs and doing uploads. It involves running a single script but this script needs to be modified each time to update versions. It also requires existing tarball of previous release against which to create xdelta.<br />
<br />
#!/bin/sh -xe<br />
VERSION=1.15.2<br />
OLDVERSION=1.15.1<br />
git checkout $VERSION<br />
git archive --format=tar --prefix="wesnoth-$VERSION/" $VERSION > "wesnoth-$VERSION.tar"<br />
bunzip2 wesnoth-$OLDVERSION.tar.bz2<br />
xdelta delta wesnoth-$OLDVERSION.tar wesnoth-$VERSION.tar wesnoth-$OLDVERSION.tar-wesnoth-$VERSION.tar.xdelta || true<br />
bzip2 wesnoth-$VERSION.tar<br />
sha256sum wesnoth-$VERSION.tar.bz2 > wesnoth-$VERSION.tar.bz2.sha256<br />
scp -P 10222 wesnoth-$VERSION.tar.bz2 wesnoth-$OLDVERSION.tar-wesnoth-$VERSION.tar.xdelta loonycyborg@wesnoth.org:/srv/www/html/files/<br />
scp -P 10222 wesnoth-$VERSION.tar.bz2.sha256 YOUR_WESNOTH_ORG_USERNAME@wesnoth.org:/srv/www/html/files/releases/<br />
rsync -avP -e ssh wesnoth-$VERSION.tar.bz2 wesnoth-$VERSION.tar.bz2.sha256 wesnoth-$OLDVERSION.tar-wesnoth-$VERSION.tar.xdelta YOUR_SF_USERNAME,wesnoth@frs.sourceforge.net:/home/frs/project/w/we/wesnoth/wesnoth/wesnoth-$VERSION/<br />
<br />
== Notify packagers ==<br />
<br />
Once all steps above are done and the upload to sourceforge is finished, you still need to notify the packagers. The announcement should include the important changes for packagers (especially path, dependencies, and other build-time changes), as well as the SHA256 checksum of the tarball attached.<br />
<br />
For the current list of packagers, check <code>/scratch/packagers-list</code> on the files.wesnoth.org filesystem.<br />
<br />
'''NOTE:''' Make sure that our "tier 1" packagers (currently Windows and OS X) whose content is hosted by us on SF.net upload the SHA256 sums of their files to files.wesnoth.org/releases/ as well!<br />
<br />
'''TODO:''' Upload not just the sha256 files but also the actual files, as a backup in case sf.net is down etc<br />
<br />
=== Example messages ===<br />
<br />
==== Development version ====<br />
Subject: Wesnoth X.Y.Z is out!<br />
<br />
Hello,<br />
<br />
Wesnoth X.Y.Z, a new feature release in the X.Y.x development series, is out <br />
now.<br />
<br />
The sources are already available on SourceForge.net, and files.wesnoth.org <br />
(for backup or in case you don't trust the authenticity of the files on <br />
SF.net). We will announce the release within the next 72 hours. In the <br />
meantime you can create and upload your packages.<br />
<br />
Nothing has changed for packagers in terms of dependencies or install <br />
locations in this release.<br />
<br />
Thank you for your contribution to Wesnoth!<br />
<br />
==== Stable version ====<br />
Subject: Wesnoth X.Y.Z is out!<br />
<br />
Hello,<br />
<br />
Wesnoth X.Y.Z, a new maintenance release in the X.Y.x stable series, is out <br />
now.<br />
<br />
The sources are already available on SourceForge.net, and files.wesnoth.org <br />
(for backup or in case you don't trust the authenticity of the files on <br />
SF.net). We will announce the release within the next 72 hours. In the <br />
meantime you can create and upload your packages.<br />
<br />
As this is a stable maintenance release, nothing has changed for packagers in<br />
terms of dependencies or install locations.<br />
<br />
Thank you for your contribution to Wesnoth!<br />
<br />
== Cleanup and post release steps ==<br />
<br />
Bump the version numbers in the files mentioned above in the release preparation steps and commit your changes. Consider deleting the test build, tarball, xdelta, etc. from your filesystem as needed.<br />
<br />
Contact shadowm or Soliton to update the MP servers' configuration to allow users of the new release or rebuild the servers as needed (only required for development releases).<br />
<br />
== The real announcement ==<br />
<br />
Prepare the real announcement forum post for the day it is to be posted. To do so copy the last announcement from the release thread into the hidden forum (edit, then copy & paste). Edit the new copy to match the new release as needed, and leave it there for fixes and comments until the time for the real announcement comes. Make sure to use the items from <code>RELEASE_NOTES</code> (which you will purge after the final announcement is published).<br />
<br />
You should also prepare the front page/News forum post in advance.<br />
<br />
Wait until the announcement conditions are met (waited at least 24 hours and OS X and Windows builds are ready OR 72 hours passed).<br />
<br />
When ready to make the announcement public, do the following:<br />
<br />
* Update [[Download]] in the wiki (currently takes the relevant contents from [[Template:StableDownload]] and [[Template:DevDownload]]).<br />
* Post the contents of the new announcement post to the Release forum section as a new 'Announcement' topic.<br />
* Set the previous announcement to a 'Normal' topic and lock it.<br />
* Post the new News forum post to the News forum section.<br />
* Update the wesnoth.org front page (yes, this has to be done by hand, I know, it sucks ― shadowm):<br />
** Change versions, sizes, and links in the overview section to point to the latest version.<br />
** Update the front page news section with an HTML version of the News forum post.<br />
** If the front page news section is getting too large, remove some of the oldest posts.<br />
* Copy the new news to [[Older_News]].<br />
* Update topics on IRC and post to social media (Twitter, etc.) as applicable.<br />
* Clean up <code>RELEASE_NOTES</code> in the repository so it only contains the template for the next release.<br />
<br />
[[Category:Development]]</div>Loonycyborghttps://wiki.wesnoth.org/index.php?title=EditingWesnoth&diff=65034EditingWesnoth2019-11-02T11:34:12Z<p>Loonycyborg: /* Linux */</p>
<hr />
<div>{{Translations}}<br />
<!-- single enters on this page are intentional --><br />
<br />
In order to create custom content for Wesnoth, you need to know where the game's resources are and where to put your own. This page will explain how to find both the <b>data</b> (core game resources) and <b>userdata</b> (custom content) directories, as well as an explanation as to working with each one.<br />
<br />
<div class="thumb tright"><div><br />
[http://www.wesnoth.org/images/sshots/wesnoth-1.11.7-1.jpg http://www.wesnoth.org/images/sshots/wesnoth-1.11.7-1-175.jpg]<br />
<div class="thumbcaption">Game paths</div></div><br />
</div><br />
<br />
The simplest way to find your game and userdata directories is to go to <b>Preferences → General → Paths</b> (shown on the right). From here you can copy respective the paths to your clipboard or open them in your platform's file manager. If you want more detailed explanations on the specific locations for your specific system, you can read the <i>How to get there</i> sections below.<br />
<br />
== The game data directory ==<br />
<br />
Wherever you installed the game, you will find these folders, among others: <b>data, music, sounds, images</b>. The rest are unimportant unless you're a developer looking to tweak stuff about the game itself. Besides <b>data</b>, they contain resources used by the game, not by campaigns.<br />
<br />
Inside the <i>data</i> folder you will find , among others, these folders: <b>campaigns, multiplayer, core</b>. These contain the mainline campaigns, the multiplayer maps and scenarios, and all the resources used in add-ons. You may examine the contents of the former for reference on how the campaigns and maps included in mainline are coded. In <b>core</b>, you will find another set of <b>music, sounds, images</b> directories. Look in here to find resources for creating your UMC content.<br />
<br />
<b>NOTE: These folders are NOT the place to put your own resources when creating an add-on. You should keep them in your add-on's folder the userdata directory, as detailed below.</b><br />
<br />
In this wiki, the terms <i>"game data"</i>, <i>wesnoth/data</i>, or <i>./data</i> refer to the wesnoth/data directory. The terms <i>"core folder"</i> or <i>core</i> refer to the wesnoth/data/core directory.<br />
<br />
=== How to get there ===<br />
<br />
==== Windows====<br />
<br />
* <b>On 32-bit computers:</b> C:\Program Files\Battle for Wesnoth <version>\data<br />
* <b>On 64-bit computers:</b> C:\Program Files (x86)\Battle for Wesnoth <version>\data<br />
<br />
<b>Note:</b> C refers to the partition or drive where Windows is installed. If your copy of Windows is not on C, or Wesnoth is installed in a different location, the path may not match those given above. If you don't remember where you installed the game, right click on the game's shortcut, open Properties, and click on the <b>"Find target"</b> button.<br />
<br />
====Mac OS X ====<br />
<br />
* Control+click on the application icon. Select <b>"Show Package Contents"</b>, then navigate to <b>"Contents"</b> → <b>"Resources"</b>.<br />
<br />
==== Linux ====<br />
<br />
* <b>Custom builds:</b> /usr/local/share/wesnoth<br />
* <b>Debian/Ubuntu packages, or emerge (Gentoo)</b>: /usr/share/games/wesnoth<br />
* <b>Red Hat Linux-based distributions in general (openSUSE, Fedora):</b> /usr/share/wesnoth<br />
* <b>Arch Linux:</b> /usr/share/wesnoth<br />
* <b>Mandriva:</b> /usr/share/games/wesnoth<br />
* <b>Slackware Linux:</b> /usr/local/share/wesnoth<br />
<br />
In a terminal, the command <code>wesnoth --path</code> shows the game data directory.<br />
<br />
====BSD====<br />
<br />
* <b>OpenBSD package:</b> /usr/local/share/wesnoth<br />
<br />
The command <code>wesnoth --path</code> also works.<br />
<br />
== The user data directory ==<br />
<br />
The user data directory in particular is the most important to a content creator. Inside are your preferences file, custom maps, saved games, the WML cache and data files corresponding to user-created content. In this wiki, <i>"user data"</i> and <i>userdata/</i> refer to this directory.<br />
<br />
The game looks at the following paths for the respective content:<br />
<br />
* <b><i>userdata</i>/data/add-ons</b> - add-ons you have installed via the built-in add-on manager or are designing yourself<br />
* <b><i>userdata</i>/editor</b> - scenario and map files created via the in-game editor<br />
* <b><i>userdata</i>/saves</b> - the directory containing all your savegame files<br />
* <b><i>userdata</i>/cache</b> - the auto-generated game cache files<br />
* <b><i>userdata</i>/preferences</b> - plaintext file containing all your saved user preferences<br />
<br />
''Note: This may not be totally accurate for all systems, for my Linux system the preferences file is stored in ~/.config/wesnoth''<br />
<br />
The add-ons directory is particularly useful. <b>In order to work with custom scenarios or campaigns, you <i>will need</i> to have your own add-on set up here.</b> Instructions on how to do so can be found in [[AddonStructure]]. Several pages on this wiki will assume you have done so and refer to relative paths in such.<br />
<br />
=== How to get there ===<br />
<br />
==== Windows ====<br />
<br />
* <b>Windows 2000/XP:</b> My Documents\My Games\Wesnoth<version><br />
* <b>Windows Vista/7/8/10:</b> Documents\My Games\Wesnoth<version><br />
<br />
<b>Note:</b> The above only applies if you did not select "Store userdata in the install location" when installing the game. If you did, keep in mind that on Windows Vista and later writes to the userdata directory in the install location may be silently redirected to the "Virtual Store", typically <code>C:\Users\yourname>\AppData\Local\VirtualStore\Program Files\Battle for Wesnoth <version></code>. Virtual Store is hidden by default; it can be accessed by by typing <i>"shell:local appdata"</i> in Explorer's address bar.<br />
<br />
==== Mac OS X ====<br />
<br />
* ~/Library/Application Support/Wesnoth_<version><br />
<br />
<b>Note:</b> As of OS X 10.7, the Library folder is hidden by default. You can press the Option key and choose Go to access it, or choose Go > Go to Folder… and type in the path there.<br />
<br />
==== Linux ====<br />
* ~/.local/share/wesnoth/<version><br />
* <b>If installed via flatpak:</b> ~/.var/app/org.wesnoth.Wesnoth/data/wesnoth/<version><br />
<br />
In a terminal, the command <code>wesnoth --config-path</code> shows the user data directory.<br />
<br />
==== BSD ====<br />
* Same place as Linux.<br />
<br />
== See Also ==<br />
<br />
* [[Create]]<br />
<br />
[[Category:Create]]</div>Loonycyborghttps://wiki.wesnoth.org/index.php?title=CodingStandards&diff=60164CodingStandards2019-01-24T21:17:30Z<p>Loonycyborg: /* C++ version */</p>
<hr />
<div>Wesnoth uses C++ that is portable to C++ compilers targeting various commonly used platforms.<br />
<br />
== C++ version ==<br />
<br />
Wesnoth uses C++ conforming to C++11 in stable branch and C++14 in master branch.<br />
<br />
== Formatting ==<br />
<br />
When working on C++ for Wesnoth, indent your code with a tab character. After fully indenting, if you still need to line up the text with a specific character on the line above, you may further align it using space characters.<br />
<br />
You may use long lines.<br />
<br />
Don't use a space after control flow keywords (if/for/...).<br />
<br />
== Evil things to avoid ==<br />
<br />
=== Avoid implicit conversions ===<br />
<br />
Make all constructors which only take one argument that is of a different type to the class <tt>explicit</tt>.<br />
<br />
Do not use <tt>operator T()</tt> (where <tt>T</tt> is a type) to allow an implicit conversion to a different type. For example:<br />
<br />
t_string(const std::string&);<br />
<br />
This can cause many situations where a temporary t_string is implicitly created and then gets destroyed unexpectedly (reference [https://gna.org/bugs/index.php?20360 bug #20360]).<br />
<br />
=== Do not declare class data members as non-private ===<br />
<br />
It's okay to have a ''struct'' with only public members, if that's what you want.<br />
<br />
However, once something is a ''class'' with private data members, do not add public (or even protected) data members to the class. Doing this breaks encapsulation and can cause all kinds of confusing and evil things to happen.<br />
<br />
=== Destructors must not throw exceptions ===<br />
<br />
Do not allow exceptions to propogate from a destructor. Doing that is always bad in C++. Any code which does it should be treated as a bug and fixed. Doing this is a very easy way to cause memory leaks and crashes.<br />
<br />
It's okay to have exceptions thrown inside a destructor, just as long as you catch() them inside the destructor too and don't allow them to propagate out.<br />
<br />
In C++11, any destructor which throws an exception causes the program to be immediately terminated (except in special cases).<br />
<br />
You can read more about the issue here: http://c2.com/cgi/wiki?BewareOfExceptionsInTheDestructor<br />
<br />
== Naming ==<br />
<br />
=== End non-public class data members with an underscore ===<br />
<br />
All non-public data members of classes should have their names terminated with an underscore, to show that they are a class member. This makes for more readable code, once one is familiar with the convention.<br />
<br />
== Idioms ==<br />
<br />
=== Use references when a value may not be NULL ===<br />
<br />
If a value passed to a function can never be <tt>NULL</tt>, use a reference instead of a pointer. For example:<br />
<br />
void my_function(T& obj);<br />
<br />
rather than<br />
<br />
void my_function(T* obj);<br />
<br />
This more clearly shows prospective users of the function that <tt>obj</tt> may never be <tt>NULL</tt>, without them having to consult documentation or the implementation of the function.<br />
<br />
=== Use the const keyword ===<br />
<br />
The <tt>const</tt> keyword in C++ allows interfaces to more clearly specify how they treat objects. <br />
Always use <tt>const</tt> when you are not going to modify an object. For example:<br />
<br />
void my_function(const T& obj);<br />
<br />
This shows to the caller that <tt>obj</tt> will not be modified. If <tt>my_function()</tt> may modify <tt>obj</tt>, then use the following instead:<br />
<br />
void my_function(T& obj);<br />
<br />
Likewise, if a variable is not changed after initialization, make it <tt>const</tt>, and mark member functions as <tt>const</tt> if they do not modify their object.<br />
<br />
=== Know the behavior of const references when types differ ===<br />
<br />
If you assign something to a <tt>const</tt> reference of a different type, if necessary (if the type is different but there is a conversion) the compiler will create a temporary and guarantee it lasts for the lifetime of the reference. So<br />
<br />
char c = 0;<br />
const int& i = c;<br />
c = 5;<br />
<br />
will result in c == 5 and i == 0, which may not be what you expect.<br />
<br />
=== Write exception-safe code ===<br />
<br />
Wesnoth code should be exception-safe, even if you do not use exceptions directly. That is, you should be able to assume that an exception is thrown almost anywhere from within the code, with well-defined results (i.e. no resource leaks).<br />
<br />
Code that uses a pattern like the following is bad:<br />
<br />
{<br />
SDL_Surface* image = IMG_Load("image.bmp");<br />
...some code, which uses 'image'...<br />
SDL_FreeSurface(image);<br />
}<br />
<br />
The code may throw an exception, and <tt>image</tt> will never be freed. Instead, use wrapper objects which free the object in their destructor.<br />
<br />
For <tt>SDL_Surface</tt> objects, the <tt>surface</tt> type is used throughout the Wesnoth source code to achieve this purpose. So you could rewrite the above code as follows:<br />
<br />
{<br />
surface image(IMG_Load("image.bmp"));<br />
...some code, which uses 'image'...<br />
} ''the image is automatically freed here when 'image' is destroyed<br />
<br />
Instead of allocating memory directly using <tt>new[]</tt> or <tt>malloc()</tt>, use language-provided containers, such as vector.<br />
<br />
Similarly, avoid writing <tt>delete</tt> explicitly in your code. Oftentimes using a smart pointer or similar instead will improve the readability of your code, by making it obvious that you are managing memory correctly even if an exception is thrown. If you were deleting a pointer which is a member variable of an object, using a smart pointer instead may simplify your code by eliminating the need to write an explicit destructor in some cases.<br />
<br />
For more information, you can read about the (important) RAII idiom: http://c2.com/cgi/wiki?ResourceAcquisitionIsInitialization<br />
<br />
=== Do not use sprintf ===<br />
<br />
The <tt>sprintf()</tt> function does not check whether or not it is writing past the end of the space allocated. This is a security problem if someone other than the person running the game can cause <tt>sprintf()</tt> to write very long strings. In Wesnoth, this untrusted data could come potentially from other players in a multiplayer game, or from downloaded add-ons. Instead you should use <tt>snprintf()</tt> with the second argument being the <tt>sizeof</tt> of the buffer that will hold the result.<br />
<br />
== Standard C++ to avoid ==<br />
<br />
=== Do not use 0 or NULL when you mean nullptr ===<br />
<br />
Several Wesnoth developers, including Dave, find the number 0 to be very ambiguous when used in a non-numeric context. In keeping with the precedent that has already been established in the Wesnoth source code, you should avoid using literal zero for initializing and/or comparing null pointers.<br />
<br />
=== Do not use standard io functions ===<br />
This implies the std::fstream class and fopen. These functions do not support utf8 in windows which is our standard encoding for filepaths. Use our custom filesystem functions (filesystem.hpp) instead.<br />
<br />
== C legacy to be avoided ==<br />
<br />
=== Use std::array instead of C-style Arrays ===<br />
<br />
C-style arrays are very efficient, but their interface is ugly. Use <tt>std::array</tt> instead.<br />
<br />
=== Do not use C-style or function-style casts ===<br />
<br />
The following code,<br />
<br />
if(i->second.side() == (size_t)player_number_) {<br />
<br />
is considered bad practice in C++ since a C-style cast is overpowered -- if types change around it could end up casting away constness, or performing an implementation-defined data reinterpretation (basically a C-style cast is a compiler-generated combination of <tt>static_cast</tt>, <tt>reinterpret_cast</tt>, and <tt>const_cast</tt>).<br />
<br />
This syntax,<br />
<br />
if(i->second.side() == size_t(player_number_)) {<br />
<br />
is also a cast, and [http://stackoverflow.com/a/32224 semantically identical] to the C-style cast. It should also be avoided.<br />
<br />
Good programming style is to use the least powerful tool available that does what you want. For example:<br />
<br />
if(i->second.side() == static_cast<size_t>(player_number_)) {<br />
<br />
Alternatively, a constructor call may be used for non-built-in types.<br />
<br />
''Note: there may be some obscure cases where a C-style cast is desirable, such as converting a pointer to an integer type of unspecified size.''<br />
<br />
=== Do not use #define for constants ===<br />
<br />
<tt><nowiki>#</nowiki>define foo X</tt> is not a typesafe approach to define constants. Instead, you can something like the following (in an anonymous namespace) to achieve the same goal in a typesafe fashion.<br />
<br />
namespace {<br />
const T foo = X;<br />
}<br />
<br />
== Documentation ==<br />
<br />
=== Document config preconditions and postconditions ===<br />
<br />
In the Wesnoth code you will commonly encounter a data container type known as <tt>config</tt>, which contains hierarchical string data (such as WML contents or game settings). The tagged ''children'' of the <tt>config</tt> object and their string ''attributes'' are arranged in an ordered and mapped format, internally implemented using the C++ STL.<br />
<br />
Because <tt>config</tt> data is utilized in so many ways and places, it can be difficult to track across the scope of the entire program. Thus, you should document all public functions that take/return <tt>config</tt> objects, specifying content expectations and updating any related entries in the [[ReferenceWML]] wiki pages. In particular, if your function requires a <tt>config</tt> parameter, specify where/how the <tt>config</tt> object should be created. This will be a great help to any future coders who need to call or modify your function.<br />
<br />
=== Doxygen ===<br />
<br />
See [[Doxygen]] for tips on how to comment the code, so that Doxygen can nicely document it.<br />
<br />
== See also ==<br />
<br />
* [[HackingWesnoth]]<br />
<br />
[[Category:Development]]</div>Loonycyborghttps://wiki.wesnoth.org/index.php?title=MultiplayerServerWML&diff=60028MultiplayerServerWML2018-11-14T10:07:34Z<p>Loonycyborg: /* The handshake */</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 "socket number"). 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. 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. 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 />
<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. "1.0*,1.2*,1.4*,1.7*,1.8*")<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_reminder''': If "yes" the client requests the server to send a password reminder for the provided username.<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).<br />
<br />
* server response<br />
** '''[join_lobby]''' or<br />
** '''[error]'''<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 "yes" 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 />
**** '''turn''': The current turn/max turn.<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''': "yes" if the player is in the lobby; "no" 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 />
<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 />
== Room commands ==<br />
Note: the room commands are in general and are subject to change. Room commands are not implemented on 1.13+ servers.<br />
* '''[room_join]'''<br />
** '''room''': The room name to join<br />
** '''player''': (filled by server in response message sent to all room members) the player that joins the room<br />
** '''[members]''': member list sent to the player that joined<br />
*** '''[member]''': (repeated) members<br />
**** '''name''': This member's name<br />
* '''[room_part]'''<br />
** '''room''': The room name to part (leave). Leaving the lobby is not allowed.<br />
** '''player''': (filled by server in response message sent to all room members) the player that leaves the room<br />
* '''[room_query]''': specific room-related queries.<br />
** '''[rooms]''': List rooms created on the server, or<br />
** '''[names]''': List members of a given room<br />
*** '''room''': The room name (if applicable)<br />
** '''[persist]''': Check or set room persistance<br />
*** '''value''': (optional) set room persistance to this value (yes/no)<br />
* '''[room_query_response]''': contains specific response to a room_query.<br />
** '''message''': optional text message response<br />
** '''room''': room name (if applicable)<br />
** '''[rooms]''': room list<br />
*** '''[room]''': (repeated) rooms<br />
**** '''name''': This room's name<br />
** '''[members]''': member list<br />
*** '''[member]''': (repeated) members<br />
**** '''name''': This member's name<br />
<br />
== Nickname registration related commands (lobby and in-game) ==<br />
<br />
* '''[nickserv]'''<br />
** '''[register]'''<br />
*** '''password''': The password for the nickname.<br />
*** '''mail''': The email address for the nickname.<br />
** '''[drop]''': Drop this username.<br />
** '''[set]''': Set a detail (e.g. email address) for this nickname.<br />
*** '''detail''': The detail, e.g. "mail".<br />
*** '''value''': The new value for this detail, e.g. "user@edomain"<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 "game")/quitting([observer] - joining the lobby "game") a game<br />
** '''name''': Username of the player/observer.<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 />
<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 />
<br />
== In-game communication ==<br />
<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''': "termination" <br />
** '''condition''': the termination reason<br />
<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: "human" or "human_ai"<br />
** '''own_side''': "yes"<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. ("ai", "network")<br />
<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 />
* '''[turn]'''<br />
** '''[command]''': (repeated) can contain all the tags you can find in a 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 />
== Administrative commands ==<br />
* '''[query]'''<br />
** '''type''': The type of query. See [[ServerAdministration]] for details.<br />
<br />
== See also ==<br />
[[MultiplayerServerBots]]<br />
<br />
[[Category:WML Reference]]</div>Loonycyborghttps://wiki.wesnoth.org/index.php?title=ReleasingWesnoth&diff=58273ReleasingWesnoth2017-03-18T22:59:22Z<p>Loonycyborg: /* General maintenance */</p>
<hr />
<div>== Tools ==<br />
<br />
Tools needed for releasing:<br />
* Normal tools to build everything from Wesnoth and to fetch the repository head (cmake based assumed for this page!)<br />
* <code>po4a</code> (to be able to update the manpages and manual)<br />
* <code>docbook-xml-dtd</code> (to generate the manual HTML files)<br />
* <code>xdelta</code> 1.x (to create the Xdelta files)<br />
* <code>rsync</code> for upload of tarballs<br />
<br />
Tools for other processes:<br />
* <code>optipng</code> (only for needed to run <code>utils/wesnoth-optipng</code>, not for normal releases)<br />
* <code>imagemagick</code> (tool <code>convert</code>, only for needed to run <code>utils/wesnoth-optipng</code>, not for normal releases)<br />
* <code>advancecomp</code> (tool <code>advdef</code>, only for needed to run <code>utils/wesnoth-optipng</code>, not for normal releases)<br />
<br />
== General maintenance ==<br />
<br />
Not strictly release associated though the pot-update part should be done right before every release.<br />
<br />
* Run <code>utils/wesnoth-optipng</code> from the main directory of the checkout every now and then (read: <b>very</b> rarely, because it enlarges the Git repository for <i>very</i> negligible reductions in distribution size), requires the packages optipng, imagemagick and advancecomp<br />
* Run a <code>pot-update</code> regularly, once shortly before the release and before each string-freeze (including string-freezes in preparation for stable releases). This involves the following steps as of 1.13.3:<br />
<br />
# target "pot-update" regenerates pot files and updates po files according to them<br />
# target "update-po4a" reruns po4a for man pages and manual<br />
# target "manual" regenerates manual<br />
scons pot-update update-po4a manual<br />
<br />
# Make sure that no new files were created in doc/, if new manpages/manuals were created, add them<br />
git status doc/<br />
<br />
# Commit the bunch of updated po files and manpages/manuals<br />
git commit doc/ po/<br />
<br />
(the following commands should be run but are usually forgotten...)<br />
* Run <code>make lint</code> inside <code>data/tools</code> (runs <code>wmllint</code> with appropriate options), fix warnings or prod campaign and content maintainers as needed<br />
* Run <code>make reindent</code> from <code>data/tools</code> to reindent all mainline WML according to our conventions (probably don't want to do this too often as it may inconvenience coders)<br />
* Have a look at the pages from the category [[:Category:Review_on_Release|Review on Release]]<br />
<br />
== Release tasks ==<br />
<br />
=== Preparation steps ===<br />
* Make sure to run and commit a pot-update (see above), and update to the latest revision of the branch if needed. At this point you should warn people to stop pushing commits to the branch you'll be using for the release so as to avoid last-minute work sync issues or new unexpected bugs.<br />
* Check <code>changelog</code> and <code>players_changelog</code> for completeness and correctness, line wrap to 80 columns.<br />
* Bump the version numbers in <code>src/wesconfig.h</code>, <code>Doxyfile</code>, <code>changelog</code>, <code>players_changelog</code>, and <code>projectfiles/Xcode/Info.plist</code> and commit. Note that as of version 1.13.2 there are additional <code>RC_VERSION_*</code> macros in <code>src/wesconfig.h</code> needed by Windows builds. Since unlike <code>VERSION</code> these aren't freeform values, they should represent the next release version whenever <code>VERSION</code> represents an in-dev version (e.g. if <code>VERSION</code> is <code>1.13.2+dev</code>, the <code>RC_VERSION_*</code> macros should have the values for <code>1.13.3</code> instead).<br />
<br />
=== Generating the files ===<br />
<br />
# Update the git checkout, just to be sure that you have the<br />
# latest version<br />
<br />
git pull --rebase<br />
<br />
# Export the git checkout into a release tar archive (substitute<br />
# $VERSION with the release version number and $BRANCH with the<br />
# source branch). This will automatically exclude unwanted<br />
# directories from the archive following export-ignore rules in<br />
# .gitattributes<br />
<br />
git archive --format=tar --prefix="wesnoth-$VERSION/" $BRANCH > "wesnoth-$VERSION.tar"<br />
<br />
# Create the xdelta patch for the archives (this assumes that the<br />
# uncompressed $OLDVERSION tar archive is present!)<br />
<br />
xdelta delta wesnoth-$OLDVERSION.tar wesnoth-$VERSION.tar wesnoth-$OLDVERSION.tar-wesnoth-$VERSION.tar.xdelta<br />
<br />
# Compress the tarball<br />
<br />
bzip2 wesnoth-$VERSION.tar<br />
<br />
# Create the SHA256 sum for the tarball<br />
<br />
sha256sum wesnoth-$VERSION.tar.bz2 > wesnoth-$VERSION.tar.bz2.sha256<br />
<br />
== File upload ==<br />
<br />
The following files should be ready for upload now:<br />
<br />
* <code>wesnoth-$VERSION.tar.bz2</code><br />
* <code>wesnoth-$VERSION.tar.bz2.sha256</code><br />
* <code>wesnoth-$OLDVERSION.tar-wesnoth-$VERSION.tar.xdelta</code><br />
<br />
You must upload these files to SourceForge.net and to <code>files.wesnoth.org/releases/</code> (as backup). Since the tarballs are very large it's recommended to use rsync via SSH instead of web uploads to guarantee their integrity. After uploading to wesnoth.org it might save time to rsync to SF.net from there.<br />
<br />
For uploading to wesnoth.org, you will need to ask the site administrators for help with setting up your SSH configuration, as well as determining the destination path for the files.<br />
<br />
# Upload to files.wesnoth.org (path for reference purposes only,<br />
# does not reflect actual server set-up).<br />
<br />
rsync -avP -e ssh <FILES> <USERNAME>@wesnoth.org:WWW/html/files/<br />
<br />
# Upload to SF.net:<br />
#<br />
# * STREAM: replace with 'wesnoth' for development releases and<br />
# 'wesnoth-X.Y' for a stable release of the X.Y series.<br />
# * RELEASENAME: replace with the release name, e.g.<br />
# 'wesnoth-X.Y.Z'.<br />
<br />
rsync -avP -e ssh <FILES> <USERNAME>,wesnoth@frs.sourceforge.net:/home/frs/project/w/we/wesnoth/<STREAM>/<RELEASENAME><br />
<br />
== Build the release for testing ==<br />
<br />
You can build the release for testing while the upload is in progress. Before installing the test build make sure that no old leftover files are there, and also remove the old preferences or (preferably) use the <code>utils/wesnoth-defaults</code> script found in the repository to use a throwaway preferences dir.<br />
<br />
# Depending on whether you already compressed the tarball or not<br />
tar -xvf wesnoth-$VERSION.tar<br />
tar -xvf wesnoth-$VERSION.tar.bz2<br />
<br />
cd wesnoth-$VERSION && mkdir build && cd build<br />
<br />
# CMake command to create a test build with suffix -X.Y.Z to be<br />
# installed to /opt/wesnoth-X.Y.Z instead of /usr/local<br />
cmake .. \<br />
-DCMAKE_INSTALL_PREFIX=/opt/wesnoth-X.Y.Z \<br />
-DENABLE_SERVER=TRUE \<br />
-DENABLE_CAMPAIGN_SERVER=TRUE \<br />
-DPREFERENCES_DIR=.wesnoth-X.Y.Z \<br />
-DBINARY_SUFFIX=-X.Y.Z \<br />
-DENABLE_NOTIFICATIONS=TRUE \<br />
-DENABLE_STRICT_COMPILATION=TRUE<br />
<br />
# Build<br />
make -j<N><br />
<br />
# install<br />
sudo make install<br />
<br />
Now cd somewhere else and run the installed copy of the game (e.g. <code>/opt/wesnoth-X.Y.Z/bin/wesnoth</code>). Running right from the sources is '''not''' enough to be sure that everything works as expected.<br />
<br />
== Test the build ==<br />
This at least includes the following:<br />
<br />
* Start the editor, check if creating a map is possible<br />
* Start the game and try to connect to the official multiplayer server and to the add-on server<br />
* Start the server, connect to it using the game to see if you can enter the lobby<br />
* Check if in the game each campaign does start<br />
* Check if you can start the in-game help and the credits<br />
* Check if it is possible to create a local game<br />
* Play at least one game/scenario (or droid your side to let the AI play), this can either be a normal campaign scenario or a multiplayer game<br />
<br />
If all of those points are working as expected, go on, if not, fix the problems and restart from the very beginning.<br />
<br />
== Tagging and extra release related steps ==<br />
<br />
If everything works as expected, tag your release. Just use the version number (e.g. <code>1.13.2</code> or <code>1.14.0</code>) for the tag, no need to add <code>wesnoth-</code> in front:<br />
<br />
git tag -a -m "Wesnoth $VERSION" $VERSION HEAD && git push $VERSION<br />
<br />
Update [http://www.wesnoth.org/macro-reference.html macro-reference.html]:<br />
<br />
cd data/tools/<br />
make macro-reference.html<br />
scp macro-reference.html wesnoth@wesnoth.org:WWW/html/macro-reference.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 <PATH TO GAME EXECUTABLE> > about.wiki<br />
<br />
== Notify packagers ==<br />
<br />
Once all steps above are done and the upload to sourceforge is finished, you still need to notify the packagers. The announcement should include the important changes for packagers (especially path, dependencies, and other build-time changes), as well as the SHA256 checksum of the tarball attached.<br />
<br />
For the current list of packagers, check <code>/scratch/packagers-list</code> on the files.wesnoth.org filesystem.<br />
<br />
'''NOTE:''' Make sure that our "tier 1" packagers (currently Windows and OS X) whose content is hosted by us on SF.net upload the SHA256 sums of their files to files.wesnoth.org/releases/ as well!<br />
<br />
=== Example messages ===<br />
<br />
==== Development version ====<br />
Subject: Wesnoth X.Y.Z is out!<br />
<br />
Hello,<br />
<br />
Wesnoth X.Y.Z, a new feature release in the X.Y.x development series, is out <br />
now.<br />
<br />
The sources are already available on SourceForge.net, and files.wesnoth.org <br />
(for backup or in case you don't trust the authenticity of the files on <br />
SF.net). We will announce the release within the next 72 hours. In the <br />
meantime you can create and upload your packages.<br />
<br />
Nothing has changed for packagers in terms of dependencies or install <br />
locations in this release.<br />
<br />
Thank you for your contribution to Wesnoth!<br />
<br />
==== Stable version ====<br />
Subject: Wesnoth X.Y.Z is out!<br />
<br />
Hello,<br />
<br />
Wesnoth X.Y.Z, a new maintenance release in the X.Y.x stable series, is out <br />
now.<br />
<br />
The sources are already available on SourceForge.net, and files.wesnoth.org <br />
(for backup or in case you don't trust the authenticity of the files on <br />
SF.net). We will announce the release within the next 72 hours. In the <br />
meantime you can create and upload your packages.<br />
<br />
As this is a stable maintenance release, nothing has changed for packagers in<br />
terms of dependencies or install locations.<br />
<br />
Thank you for your contribution to Wesnoth!<br />
<br />
== Cleanup and post release steps ==<br />
<br />
Bump the version numbers in the files mentioned above in the release preparation steps and commit your changes. Consider deleting the test build, tarball, xdelta, etc. from your filesystem as needed.<br />
<br />
Contact shadowm or Soliton to update the MP servers' configuration to allow users of the new release or rebuild the servers as needed (only required for development releases).<br />
<br />
== The real announcement ==<br />
<br />
Prepare the real announcement forum post for the day it is to be posted. To do so copy the last announcement from the release thread into the hidden forum (edit, then copy & paste). Edit the new copy to match the new release as needed, and leave it there for fixes and comments until the time for the real announcement comes. Make sure to use the items from <code>RELEASE_NOTES</code> (which you will purge after the final announcement is published).<br />
<br />
You should also prepare the front page/News forum post in advance.<br />
<br />
Wait until the announcement conditions are met (waited at least 24 hours and OS X and Windows builds are ready OR 72 hours passed).<br />
<br />
When ready to make the announcement public, do the following:<br />
<br />
* Update [[Download]] in the wiki (currently takes the relevant contents from [[Template:StableDownload]] and [[Template:DevDownload]]).<br />
* Post the contents of the new announcement post to the Release forum section as a new 'Announcement' topic.<br />
* Set the previous announcement to a 'Normal' topic and lock it.<br />
* Post the new News forum post to the News forum section.<br />
* Update the wesnoth.org front page (yes, this has to be done by hand, I know, it sucks ― shadowm):<br />
** Change versions, sizes, and links in the overview section to point to the latest version.<br />
** Update the front page news section with an HTML version of the News forum post.<br />
** If the front page news section is getting too large, remove some of the oldest posts.<br />
* Copy the new news to [[Older_News]].<br />
* Update topics on IRC and post to social media (Twitter, etc.) as applicable.<br />
* Clean up <code>RELEASE_NOTES</code> in the repository so it only contains the template for the next release.<br />
<br />
[[Category:Development]]</div>Loonycyborghttps://wiki.wesnoth.org/index.php?title=NotSoEasyCoding&diff=56631NotSoEasyCoding2015-08-02T00:54:38Z<p>Loonycyborg: /* Porting the server and client to Asio */</p>
<hr />
<div>This page lists projects which are considered a good idea by the developers but which have nobody working on them so far. If you think you've got the required skill for a task go on, implement it and you've got a high chance that it'll be accepted. The remaining barrier will only be that it's done well. :-)<br />
<br />
If you are such a person, you should feel free to edit this page.<br />
<br />
If you're not, you should post a feature request and discuss your idea on the forum or IRC. A coder with better knowledge of the code might give you the green light to add your feature here.<br />
<br />
Anybody should feel free to add "clues" to any tasks, that is entry points, traps to avoid, person to contact to discuss and so on.<br />
<br />
If you plan to work on a feature, write your name at the bottom of the feature, with the date. Note that if you spend too long at working on a feature we'll "free" it back (that is if you're not working on it. If you have problems implementing it, just tell us....)<br />
<br />
__TOC__<br />
<br />
== Game engine ==<br />
<br />
=== SDL 2 + OpenGL port ===<br />
<br />
Wesnoth currently depends on the unmaintained SDL 1.2.x code base and the 1.2.x-based versions of its companion libraries (SDL_image, SDL_mixer, SDL_net, SDL_ttf). This means Wesnoth can't benefit from features added in newer versions of SDL such as built-in support for Android and iOS, improved cross-platform Unicode support, built-in clipboard support, and any bug fixes made since SDL 1.2.15.<br />
<br />
The problem with porting Wesnoth to SDL 2.0 as explained by lipkab (who attempted the task as part of GSoC 2014) is that SDL 2.0's software rendering API lacks some things Wesnoth needs such as a specific alpha blending mode (TODO: link to conversations here).<br />
<br />
Furthermore, while software rendering is all good and nice, Wesnoth's approach does not scale well as display resolutions increase and the need for supporting high DPI configurations is factored in. One can easily see that our zoom functionality is clunky and inefficient. Having support for OpenGL and shaders would also enable us to implement fancier graphical gimmicks such as particle effects and atmospheric lighting. The downside of adding OpenGL to the mix is that we'd need people with a specific skillset to help us maintain the graphics engine in the long term, as hardware and driver-specific quirks are inevitable. Some users are also concerned about changing Wesnoth's hardware requirements so that they would be unable to play using old or unsupported hardware/OS configurations.<br />
<br />
For hardware rendering to be effective, in particular, Wesnoth would necessitate a complete rewrite of the graphics rendering code (the display and game_display classes), the image cache manager (used to abstract the process of loading images from disk and applying image path functions), and potentially GUI2's canvas code. All three would have to limit the amount of textures they allocate to the absolute minimum, using larger textures instead. For example, the image cache could be reimplemented to load images from an internal spritesheet generated during the game loading process. (WML/Lua support for spritesheets would be nice would defining an API for it would only distract from the actual task at hand.)<br />
<br />
The greatest difficulty in handling this task probably lies in writing a new optimized rendering engine and updating all code that relies on the old display/game_display API and semantics accordingly. The GUI2 framework code is presently unmaintained and it would take some time for somebody to study and change the current implementation. Finally, as we don't have a graphics engine maintainer at this time, this task involves an implicit long-term commitment to the project that extends beyond Wesnoth 1.14.x (or whichever series will see this project completed).<br />
<br />
=== Make a "replay actions since my last turn" button ===<br />
<br />
It would be very convenient if there an ability to replay everything your opponents just did at the start of your turn, since sometimes things go out of vision or are confusing. <br />
<br />
The feature would be like a "replay since my last turn" menu option or button -- most likely, the best approach to implement it is to store a copy of the game_state object in playcontroller.cpp or even in resources, and to refactor the backlog object so that we can hold a "bookmark", i.e. a pointer, to the last position in the replay that we might look to jump back to. The replay process would work by swapping out for the old gamestate, then replaying through the actions since the bookmark until we get back up to speed. The difficult part would be making sure that scenarios with scripted WML events don't break when we do this. For debugging purposes, it might be good to check that at this point we have the same gamestate we did before we clicked the button. The bookmark should only be advanced when we end our turn, and there might be perhaps need to be multiple bookmarks, one for each side, to handle what happens when a side disconnects or is reassigned.<br />
<br />
It would be especially helpful for MP play to have this, where special tactics with ambush units are quite common. Part of the design criteria of wesnoth is that it should be a high-level, thoughtful turn based strategy game, but you should be able to play asynchronously and not necessarily give attention to the game until your turn bell rings if you don't want to. Having ambush units and no ability to replay their movements during the opponents turn harms that goal.<br />
<br />
For MP play, it will require special attention to make sure that events like "synchronize_choice" are handled correctly so as not to cause out of sync errors, and also that the timer is handled correctly.<br />
<br />
Feature request: https://gna.org/bugs/?15334<br />
<br />
=== Improve WML error reporting ===<br />
<br />
There are many programming bugs that give very unclear or cryptic error messages when using WML. Here are some examples:<br />
<br />
* <strike>When calling a macro with the wrong number of arguments, Wesnoth tells the number it expected, and the number it got, and at which line number it was instantiated. However, it would be helpful if it would also tell the line number of the definition of the macro. This might be helpful if someone is redefining macros.</strike><br />
<br />
* For places where a standard unit filter is expected, if one is not found, the game should point out a problem. For places where such a filter is expected but [filter] child should not appear, if one does it should report an error and a line number. Many users have a hard time with this kind of thing.<br />
<br />
* When doing scenario transitions in a campaign, if the side definitions don't matchup exactly the game tends to give unintelligible error messages. For instance, if one is transitioning and there is an AI side which does not have a leader (but it has a starting location in the map) it must have "no_leader = yes" in its [side] tag, or else when the team_builder objects enter stage two, the game will try to create a unit with an empty type, and the constructor of class unit will fail giving the error message "game::game_error tried to create unit with empty type". This really needs to be much better. For instance, giving a line number of a problem, or suggesting that no_leader should be used. (Note that, it is often possible to debug problems like this by turning on --log-debug=team_construction at commandline but I doubt that there are any users that know about this, you would only learn from reading the C++... without such debug info, fixing things like this can literally take hours.) For that matter it's some question why the team_builder doesn't just stop trying to build a unit when it sees it doesn't have enough info...<br />
<br />
* Recursive macros break the game, and not by stack overflow but by exhausting the heap (which usually takes forever on modern OSes and results in memory thrashing <i>before</i> resource starvation). It would be nice if we could catch this and report an error.<br />
<br />
Many WML users are students or beginners to programming, so any improvements to WML error reporting are a big help for their learning process -- many veterans would appreciate the extra help as well. In part we need fixits here and there, but more broadly we need a smarter system that can figure out what's really wrong when things go wrong, and give helpful suggestions.<br />
<br />
=== Map label "groups" which can be selectively turned on and off by the user ===<br />
<br />
It would be nice if the user could have more control over how map labels are displayed, for instance to be able to check on / off labels made by certain players, and for custom scenarios, to be able to make custom classes which the use can turn on or off. This might be helpful for custom scenarios esp. which might have some technical info they want to show, but which it might be messy to display all of the time. The hard part of this is that there should ideally be a gui to work with the map labels, although maybe this need could be worked around or simplified somehow.<br />
<br />
=== Add a new damage stats calculation mode to support scenarios with extremely high stats ===<br />
<br />
Most players use the damage calculation window constantly when they play so that they can see what to expect from various attacks. The way the game is currently set up, when a unit is selected, as soon as another unit is moused over the stats for an attack will be calculated, whether or not the user actually brings up the window.<br />
<br />
The probabilities for the various outcomes are calculated by explicitly calculating the distribution of attacker and defender hp / slowed status after each swing by either party, one swing at a time. Thus at the end we get exact probabilities of the possible outcomes.<br />
<br />
However, this comes at a cost -- the running time of the calculation can in the worst case be something like O( attacker_hp * defender_hp * total_number_of_strikes). In default era wesnoth (and in much of UMC) this is fine because units don't get extremely high hp values. However in some UMC units do get extremely high hp, and many will also have specials like drain and berzerk, and may have many different weapons as well. At some point these scenarios become unplayable even on a machine of moderate specs because mousing over any unit causes > 10 seconds of lag during which the game becomes unresponsive, trying to calculate attack outcomes.<br />
<br />
In these cases, it would be better to give an "inexact" damage prediction, based on just simulating a few thousand attacks and plotting the results. Since it's a monte carlo algorithm rather than an exact algorithm, there will be some error, but if it makes the game playable then it's clearly an improvement, and anyways for "extreme stats" battles with high strikes and damage, the outcome is in a sense less random anyways because the outcomes with inordinate amounts of hits and misses are more and more rare (law of large numbers), so the error shouldn't actually be terribly significant.<br />
<br />
If there were an advanced preference that caused the predictions to use such an algorithm instead of the current one, so that the user could turn it on if they start to get problems, it would eliminate a significant headache for some UMC.<br />
<br />
<br />
== Multiplayer/replay features ==<br />
<br />
=== Gold graph ===<br />
<br />
Make a graph feature, presumably in a dialog, that helps depict the history of a Wesnoth match for the benefit of spectators of a live game or replay. For example it could display army value, army + bank value, number of villages tagged, luck swings... This would also be particularly helpful for AI tweaking development, by helping coders identify the AI's weaknesses and strengths in the context of a particular scenario.<br />
<br />
A possible nice feature for this purpose would be to allow the user to click on the graph at key points which would trigger the "back to turn" mechanism to jump back in the replay, or automatically play the replay forwards from the beginning to that point... etc.<br />
<br />
Related email on dev-talk: https://mail.gna.org/public/wesnoth-dev/2014-02/msg00089.html<br />
<br />
=== Automatically link up to wesnothd server on a local network ===<br />
<br />
The feature request was to use ZeroConf technology, if available, to publish info of a running wesnothd instance to other machines on a local network. Then when they are searching to connect to an unofficial server, they won't have to learn the IP address.<br />
<br />
The extra code should be guarded with preprocessor flags so that ZeroConf does not become a mandatory build dependency of Wesnoth.<br />
<br />
https://gna.org/bugs/?13703<br />
<br />
=== Stock MP chat messages for language-independent communication ===<br />
<br />
Wesnoth has seen a large acceptance by international communities, and many players don't speak English. It would be nice we could have a set of messages that could be chatted, but which will be translated by our translators and displayed always in the current locale on each client, to make it easier to communicate in mp games / on the mp server.<br />
<br />
The easy part is adding the messages. They would ideally be stored in a WML file in the core data dir so they can be easily modified and translated like all other mainline WML. The hard part is devising the interaction mechanism so that a player can easily make use of these stock messages in the MP lobby or in game.<br />
<br />
<br />
== GUI2 framework ==<br />
<br />
As of 1.13.1+dev, GUI2's core and framework (including widgets and their APIs) are completely unmaintained. A prospective maintainer would have to be able to understand pretty advanced C++ making abundant use of template-based abstractions (most notably, the event handling code is almost completely implemented this way), multiple inheritance, and polymorphism. There is also some missing functionality (such as combo boxes and modeless dialogs) that the author did not get to implement, as well as work-in-progress functionality (new listbox and tooltip implementations, not enabled by default).<br />
<br />
=== Multi-line textbox, single-line textbox improvements ===<br />
<br />
GUI2 has a single-line textbox widget which works well for most purposes but falls short in a few niche cases. In particular, it's not possible to make it read-only without entirely disabling the user's ability to interact with the contents, which is inconvenient in places like the Game Paths dialog (or the About dialog in version 1.13.2 and later).<br />
<br />
The widget also does not support multi-line contents. For this reason, GUI2 dialogs that present multi-line (read-only) text to the user make use of the scroll_label+clipboard button convention introduced by shadowm in 1.12.x (see the Chat Log, Gamestate Inspector, and WML load error dialogs for examples). This has the obvious limitations of not allowing the user to select specific portions of the contents, and not supporting editing.<br />
<br />
=== Generic tab_container widget ===<br />
<br />
After 1.13.1 was released, shadowm discovered a trick to implement tabbed dialogs in GUI2, involving a general widget bug fix to make children consider their parents' visibility when processing events, and an addition to the stacked_widget API enabling users to hide all but a single active layer.<br />
<br />
The About dialog introduced in version 1.13.2 will use a horizontal listbox in combination with a stacked_widget, but ideally we should be able to reuse this pattern in more places without having to clutter up dialog implementations with the requisite code to synchronize the listbox and the stacked_widget's states. This hypothetical tab_container widget would combine the listbox and the stacked_widget to implement tabs in a cleaner fashion without having to expose the implementation details to individual dialog instances.<br />
<br />
By all means, this should be an EasyCoding task, but GUI2's unusual code layout and API design conventions (compared to the rest of Wesnoth) ''may'' make it harder than it's supposed to be.<br />
<br />
If you want to work on this, you should poke shadowm to make sure you don't duplicate efforts as he is working on a GUI2 port of the Preferences dialog and may take up this task after a while if no-one has done so first.<br />
<br />
=== GUI2 combo box and menu ===<br />
<br />
GUI2 most notably lacks a combo box widget (e.g., used in the GUI1 MP side setup screen) and menu display (either for the game's menu bar or context menus). It is not known at this time how much work would have to be done in GUI2's core and framework to allow implementing these widgets -- in particular considering how GUI2 widgets are never used without a parent dialog, which menus might not necessarily have, at least with the current gameplay UI implementation.<br />
<br />
GUI2 menu FR: https://gna.org/bugs/?22820<br />
<br />
GUI2 combo box FR: https://gna.org/bugs/?23652<br />
<br />
=== GUI2 themable in-game UI ===<br />
<br />
The "themable" in-game UI refers to the gameplay UI including the sidebar, menu/status bar, and map view. Most of it is not implemented using proper GUI1 widgets at all, except for the various interactive buttons, menus (which are floating GUI1 listboxes), and the command and chat input boxes (floating GUI1 textboxes).<br />
<br />
Moving the theme UI to GUI2 would probably require finishing up theme support in GUI2 (which is largely incomplete), and may benefit from a rendering engine redesign as is also required for porting the game to SDL 2; in particular so that the GUI aspects are more clearly separated from the game board rendering aspect.<br />
<br />
'''Note:''' This task is here solely for the sake of completeness, and only somebody very well versed in the intricacies of Wesnoth's game rendering code and GUI2 should '''ever''' try to take it up. (And even then, I would not want to be anywhere near that person when they inevitably break down and fling one or more tables around upon realizing the sheer complexity of the task. -- shadowm)<br />
<br />
== Add-ons server and client ==<br />
<br />
=== Passphrase hashing ===<br />
<br />
The add-ons server (campaignd) uses a very dumb authentication scheme for uploading add-ons where an author sets a passphrase (or gets a random passphrase assigned by the game) the first time they upload to the server, and subsequent uploads of the same add-on are only allowed if the passphrase matches. The passphrase is stored in clear text form both client and server-side, which has [http://forums.wesnoth.org/viewtopic.php?f=62&t=42663 various implications].<br />
<br />
Ideally, the server would store all passphrases in a hashed form.<br />
<br />
=== Port redirection ===<br />
<br />
Wesnoth's MP server (wesnothd) uses a single port (15000) for servicing most requests and redirects clients to different ports according to the game client's version number. This allows the server administrators to reassign ports freely without having to modify the game client.<br />
<br />
The add-ons server (campaignd) and client instead have a hardcoded default port number for a Wesnoth version series. For example, 1.12.x is hardcoded to default to 15006. This becomes a maintainability issue as add-on servers get decommissioned and their port numbers can't be reused for fear of misdirecting obsolete client versions to the wrong instance with incompatible add-ons.<br />
<br />
=== Incremental upgrades and uploads ===<br />
<br />
Right now, whenever a new add-on version is published, players must download (or conversely, upload) the whole contents, even if the differences between both versions amount to a single line change. This is not a problem with small add-ons, but there is a substantial number of large (> 10 MiB) add-ons on the server. Large downloads and uploads are inconvenient for players on slow or metered connections, and also increase the server's traffic requirements.<br />
<br />
Ideally, for each add-on it attempts to upgrade or upload, the add-ons client should be able to send the server its local list of files with hashes, so that the server can identify which files need to be transmitted to/by the client, all archived on the fly like normal add-on downloads/uploads. The obvious downside is that the server would need to calculate an add-on's file hashes on demand, increasing CPU usage when servicing upgrades or uploads; this could be avoided by generating its file hashes when servicing uploads instead.<br />
<br />
See also: https://gna.org/bugs/?19972 (for uploads only; there should be one for downloads too but I couldn't find it -- shadowm)<br />
<br />
=== Porting the server to Asio ===<br />
<br />
Although the client uses Boost.Asio for communications, the server continues to use SDL_net instead. This means, amongst other things, that we are limited to IPv4 and an unmaintained codebase full of hacks waiting to break apart in the future (Wesnoth's SDL_net code does, amongst other things, tamper with what are supposed to be opaque data structures maintained by SDL_net).<br />
<br />
There was an attempt to build a new add-ons server (umcd) using Asio as part of GSoC, but it ultimately failed and the developers are no longer involved with the project. The umcd codebase status as of this writing is unknown.<br />
<br />
== Multiplayer server and client ==<br />
<br />
=== Porting the server and client to Asio ===<br />
<br />
As with campaignd above, it would be nice to move the multiplayer server and client to Asio so that we could drop the SDL_net dependency and obtain IPv6 support. There's a [https://github.com/wesnoth/wesnoth/tree/asio_wesnothd branch] to port the server to Asio. Be sure to coordinate any porting to Asio with loonycyborg as he's main contributor to the branch and did Asio porting of addon client.<br />
<br />
=== Improve server WML processing ===<br />
<br />
The server uses its own custom WML implementation separate from the main engine's to store and process WML objects for games -- see [[WesnothdDesign#simple_wml]]. This is intended to improve performance and reduce wesnothd's memory footprint with large numbers of games and complex scenarios. However, the simple_wml code sometimes messes up WML attribute translatability, resulting in MP scenarios/campaigns being untranslated for non-hosts in networked MP (http://gna.org/bugs/?22989). Fixing this is not easy due to the aforementioned performance requirements.<br />
<br />
== Data structures ==<br />
<br />
=== Make the Lua state persistent ===<br />
<br />
Wesnoth is designed to make all data files as simple and human-readable as possible, including savefiles. WML is designed so that it is always very easy to write the entire WML state as plaintext and reload it correctly. There are many benefits of this, but especially <br />
<br />
* It makes it easy for beginners / students to read the files and see what's going on<br />
* It makes it easy for us to debug problems without needing special tools to read the savefiles<br />
* It makes it easy to edit save files to work around any possible bugs. Users have even reported opening savefiles from version 1.10 in microsoft word (!) to correct minor bugs in mp and resaving them, as a policy for tournament games.<br />
<br />
This was unfortunately somewhat lost when we added lua. If you use lua in your scenarios, things become more complicated because we can't save the lua state at all. If you rely on lua variables to save information, then when your scenario is saved and reloaded those variables will get wiped. The wesnoth engine provides places for lua to hook into "onsave" and "onload" so that the scenario developer can write their own serialization routines, but this is just punting the problem to scenario developers.<br />
<br />
We also provide the "preload" event type specifically to work around the issue -- unlike all other events, preload is called exactly once for every time the scenario is loaded. The purpose is to give another way that lua users can initialize a table of lua functions used by their addon and guarantee that this happens before the functions are called. But to non-lua users this event is basically unsafe for normal use otherwise -- if there is a preload event which e.g. increments a WML variable, then the WML state now depends on how many times the scenario is saved or reloaded. In a normal scenario, save / reload events should be invisible, and normally if this isn't the case it indicates a bug similar to an OOS.<br />
<br />
A nice solution to this would be if we properly serialized the lua state alongside the WML in a savefile. The most suitable solution is probably this library: https://github.com/fnuecke/eris<br />
It would require significant additional work as well to find a good way to serialize the C functions that we expose to lua, and the userdata like units held by lua.<br />
<br />
More info here: http://lua-users.org/wiki/PlutoLibrary<br />
<br />
<br />
[[Category:Development]]<br />
[[Category:Future]]</div>Loonycyborghttps://wiki.wesnoth.org/index.php?title=NotSoEasyCoding&diff=56628NotSoEasyCoding2015-07-31T22:54:02Z<p>Loonycyborg: /* Porting the server and client to Asio */</p>
<hr />
<div>This page lists projects which are considered a good idea by the developers but which have nobody working on them so far. If you think you've got the required skill for a task go on, implement it and you've got a high chance that it'll be accepted. The remaining barrier will only be that it's done well. :-)<br />
<br />
If you are such a person, you should feel free to edit this page.<br />
<br />
If you're not, you should post a feature request and discuss your idea on the forum or IRC. A coder with better knowledge of the code might give you the green light to add your feature here.<br />
<br />
Anybody should feel free to add "clues" to any tasks, that is entry points, traps to avoid, person to contact to discuss and so on.<br />
<br />
If you plan to work on a feature, write your name at the bottom of the feature, with the date. Note that if you spend too long at working on a feature we'll "free" it back (that is if you're not working on it. If you have problems implementing it, just tell us....)<br />
<br />
__TOC__<br />
<br />
== Game engine ==<br />
<br />
=== SDL 2 + OpenGL port ===<br />
<br />
Wesnoth currently depends on the unmaintained SDL 1.2.x code base and the 1.2.x-based versions of its companion libraries (SDL_image, SDL_mixer, SDL_net, SDL_ttf). This means Wesnoth can't benefit from features added in newer versions of SDL such as built-in support for Android and iOS, improved cross-platform Unicode support, built-in clipboard support, and any bug fixes made since SDL 1.2.15.<br />
<br />
The problem with porting Wesnoth to SDL 2.0 as explained by lipkab (who attempted the task as part of GSoC 2014) is that SDL 2.0's software rendering API lacks some things Wesnoth needs such as a specific alpha blending mode (TODO: link to conversations here).<br />
<br />
Furthermore, while software rendering is all good and nice, Wesnoth's approach does not scale well as display resolutions increase and the need for supporting high DPI configurations is factored in. One can easily see that our zoom functionality is clunky and inefficient. Having support for OpenGL and shaders would also enable us to implement fancier graphical gimmicks such as particle effects and atmospheric lighting. The downside of adding OpenGL to the mix is that we'd need people with a specific skillset to help us maintain the graphics engine in the long term, as hardware and driver-specific quirks are inevitable. Some users are also concerned about changing Wesnoth's hardware requirements so that they would be unable to play using old or unsupported hardware/OS configurations.<br />
<br />
For hardware rendering to be effective, in particular, Wesnoth would necessitate a complete rewrite of the graphics rendering code (the display and game_display classes), the image cache manager (used to abstract the process of loading images from disk and applying image path functions), and potentially GUI2's canvas code. All three would have to limit the amount of textures they allocate to the absolute minimum, using larger textures instead. For example, the image cache could be reimplemented to load images from an internal spritesheet generated during the game loading process. (WML/Lua support for spritesheets would be nice would defining an API for it would only distract from the actual task at hand.)<br />
<br />
The greatest difficulty in handling this task probably lies in writing a new optimized rendering engine and updating all code that relies on the old display/game_display API and semantics accordingly. The GUI2 framework code is presently unmaintained and it would take some time for somebody to study and change the current implementation. Finally, as we don't have a graphics engine maintainer at this time, this task involves an implicit long-term commitment to the project that extends beyond Wesnoth 1.14.x (or whichever series will see this project completed).<br />
<br />
=== Make a "replay actions since my last turn" button ===<br />
<br />
It would be very convenient if there an ability to replay everything your opponents just did at the start of your turn, since sometimes things go out of vision or are confusing. <br />
<br />
The feature would be like a "replay since my last turn" menu option or button -- most likely, the best approach to implement it is to store a copy of the game_state object in playcontroller.cpp or even in resources, and to refactor the backlog object so that we can hold a "bookmark", i.e. a pointer, to the last position in the replay that we might look to jump back to. The replay process would work by swapping out for the old gamestate, then replaying through the actions since the bookmark until we get back up to speed. The difficult part would be making sure that scenarios with scripted WML events don't break when we do this. For debugging purposes, it might be good to check that at this point we have the same gamestate we did before we clicked the button. The bookmark should only be advanced when we end our turn, and there might be perhaps need to be multiple bookmarks, one for each side, to handle what happens when a side disconnects or is reassigned.<br />
<br />
It would be especially helpful for MP play to have this, where special tactics with ambush units are quite common. Part of the design criteria of wesnoth is that it should be a high-level, thoughtful turn based strategy game, but you should be able to play asynchronously and not necessarily give attention to the game until your turn bell rings if you don't want to. Having ambush units and no ability to replay their movements during the opponents turn harms that goal.<br />
<br />
For MP play, it will require special attention to make sure that events like "synchronize_choice" are handled correctly so as not to cause out of sync errors, and also that the timer is handled correctly.<br />
<br />
Feature request: https://gna.org/bugs/?15334<br />
<br />
=== Improve WML error reporting ===<br />
<br />
There are many programming bugs that give very unclear or cryptic error messages when using WML. Here are some examples:<br />
<br />
* <strike>When calling a macro with the wrong number of arguments, Wesnoth tells the number it expected, and the number it got, and at which line number it was instantiated. However, it would be helpful if it would also tell the line number of the definition of the macro. This might be helpful if someone is redefining macros.</strike><br />
<br />
* For places where a standard unit filter is expected, if one is not found, the game should point out a problem. For places where such a filter is expected but [filter] child should not appear, if one does it should report an error and a line number. Many users have a hard time with this kind of thing.<br />
<br />
* When doing scenario transitions in a campaign, if the side definitions don't matchup exactly the game tends to give unintelligible error messages. For instance, if one is transitioning and there is an AI side which does not have a leader (but it has a starting location in the map) it must have "no_leader = yes" in its [side] tag, or else when the team_builder objects enter stage two, the game will try to create a unit with an empty type, and the constructor of class unit will fail giving the error message "game::game_error tried to create unit with empty type". This really needs to be much better. For instance, giving a line number of a problem, or suggesting that no_leader should be used. (Note that, it is often possible to debug problems like this by turning on --log-debug=team_construction at commandline but I doubt that there are any users that know about this, you would only learn from reading the C++... without such debug info, fixing things like this can literally take hours.) For that matter it's some question why the team_builder doesn't just stop trying to build a unit when it sees it doesn't have enough info...<br />
<br />
* Recursive macros break the game, and not by stack overflow but by exhausting the heap (which usually takes forever on modern OSes and results in memory thrashing <i>before</i> resource starvation). It would be nice if we could catch this and report an error.<br />
<br />
Many WML users are students or beginners to programming, so any improvements to WML error reporting are a big help for their learning process -- many veterans would appreciate the extra help as well. In part we need fixits here and there, but more broadly we need a smarter system that can figure out what's really wrong when things go wrong, and give helpful suggestions.<br />
<br />
=== Map label "groups" which can be selectively turned on and off by the user ===<br />
<br />
It would be nice if the user could have more control over how map labels are displayed, for instance to be able to check on / off labels made by certain players, and for custom scenarios, to be able to make custom classes which the use can turn on or off. This might be helpful for custom scenarios esp. which might have some technical info they want to show, but which it might be messy to display all of the time. The hard part of this is that there should ideally be a gui to work with the map labels, although maybe this need could be worked around or simplified somehow.<br />
<br />
=== Add a new damage stats calculation mode to support scenarios with extremely high stats ===<br />
<br />
Most players use the damage calculation window constantly when they play so that they can see what to expect from various attacks. The way the game is currently set up, when a unit is selected, as soon as another unit is moused over the stats for an attack will be calculated, whether or not the user actually brings up the window.<br />
<br />
The probabilities for the various outcomes are calculated by explicitly calculating the distribution of attacker and defender hp / slowed status after each swing by either party, one swing at a time. Thus at the end we get exact probabilities of the possible outcomes.<br />
<br />
However, this comes at a cost -- the running time of the calculation can in the worst case be something like O( attacker_hp * defender_hp * total_number_of_strikes). In default era wesnoth (and in much of UMC) this is fine because units don't get extremely high hp values. However in some UMC units do get extremely high hp, and many will also have specials like drain and berzerk, and may have many different weapons as well. At some point these scenarios become unplayable even on a machine of moderate specs because mousing over any unit causes > 10 seconds of lag during which the game becomes unresponsive, trying to calculate attack outcomes.<br />
<br />
In these cases, it would be better to give an "inexact" damage prediction, based on just simulating a few thousand attacks and plotting the results. Since it's a monte carlo algorithm rather than an exact algorithm, there will be some error, but if it makes the game playable then it's clearly an improvement, and anyways for "extreme stats" battles with high strikes and damage, the outcome is in a sense less random anyways because the outcomes with inordinate amounts of hits and misses are more and more rare (law of large numbers), so the error shouldn't actually be terribly significant.<br />
<br />
If there were an advanced preference that caused the predictions to use such an algorithm instead of the current one, so that the user could turn it on if they start to get problems, it would eliminate a significant headache for some UMC.<br />
<br />
<br />
== Multiplayer/replay features ==<br />
<br />
=== Gold graph ===<br />
<br />
Make a graph feature, presumably in a dialog, that helps depict the history of a Wesnoth match for the benefit of spectators of a live game or replay. For example it could display army value, army + bank value, number of villages tagged, luck swings... This would also be particularly helpful for AI tweaking development, by helping coders identify the AI's weaknesses and strengths in the context of a particular scenario.<br />
<br />
A possible nice feature for this purpose would be to allow the user to click on the graph at key points which would trigger the "back to turn" mechanism to jump back in the replay, or automatically play the replay forwards from the beginning to that point... etc.<br />
<br />
Related email on dev-talk: https://mail.gna.org/public/wesnoth-dev/2014-02/msg00089.html<br />
<br />
=== Automatically link up to wesnothd server on a local network ===<br />
<br />
The feature request was to use ZeroConf technology, if available, to publish info of a running wesnothd instance to other machines on a local network. Then when they are searching to connect to an unofficial server, they won't have to learn the IP address.<br />
<br />
The extra code should be guarded with preprocessor flags so that ZeroConf does not become a mandatory build dependency of Wesnoth.<br />
<br />
https://gna.org/bugs/?13703<br />
<br />
=== Stock MP chat messages for language-independent communication ===<br />
<br />
Wesnoth has seen a large acceptance by international communities, and many players don't speak English. It would be nice we could have a set of messages that could be chatted, but which will be translated by our translators and displayed always in the current locale on each client, to make it easier to communicate in mp games / on the mp server.<br />
<br />
The easy part is adding the messages. They would ideally be stored in a WML file in the core data dir so they can be easily modified and translated like all other mainline WML. The hard part is devising the interaction mechanism so that a player can easily make use of these stock messages in the MP lobby or in game.<br />
<br />
<br />
== GUI2 framework ==<br />
<br />
As of 1.13.1+dev, GUI2's core and framework (including widgets and their APIs) are completely unmaintained. A prospective maintainer would have to be able to understand pretty advanced C++ making abundant use of template-based abstractions (most notably, the event handling code is almost completely implemented this way), multiple inheritance, and polymorphism. There is also some missing functionality (such as combo boxes and modeless dialogs) that the author did not get to implement, as well as work-in-progress functionality (new listbox and tooltip implementations, not enabled by default).<br />
<br />
=== Multi-line textbox, single-line textbox improvements ===<br />
<br />
GUI2 has a single-line textbox widget which works well for most purposes but falls short in a few niche cases. In particular, it's not possible to make it read-only without entirely disabling the user's ability to interact with the contents, which is inconvenient in places like the Game Paths dialog (or the About dialog in version 1.13.2 and later).<br />
<br />
The widget also does not support multi-line contents. For this reason, GUI2 dialogs that present multi-line (read-only) text to the user make use of the scroll_label+clipboard button convention introduced by shadowm in 1.12.x (see the Chat Log, Gamestate Inspector, and WML load error dialogs for examples). This has the obvious limitations of not allowing the user to select specific portions of the contents, and not supporting editing.<br />
<br />
=== Generic tab_container widget ===<br />
<br />
After 1.13.1 was released, shadowm discovered a trick to implement tabbed dialogs in GUI2, involving a general widget bug fix to make children consider their parents' visibility when processing events, and an addition to the stacked_widget API enabling users to hide all but a single active layer.<br />
<br />
The About dialog introduced in version 1.13.2 will use a horizontal listbox in combination with a stacked_widget, but ideally we should be able to reuse this pattern in more places without having to clutter up dialog implementations with the requisite code to synchronize the listbox and the stacked_widget's states. This hypothetical tab_container widget would combine the listbox and the stacked_widget to implement tabs in a cleaner fashion without having to expose the implementation details to individual dialog instances.<br />
<br />
By all means, this should be an EasyCoding task, but GUI2's unusual code layout and API design conventions (compared to the rest of Wesnoth) ''may'' make it harder than it's supposed to be.<br />
<br />
If you want to work on this, you should poke shadowm to make sure you don't duplicate efforts as he is working on a GUI2 port of the Preferences dialog and may take up this task after a while if no-one has done so first.<br />
<br />
=== GUI2 combo box and menu ===<br />
<br />
GUI2 most notably lacks a combo box widget (e.g., used in the GUI1 MP side setup screen) and menu display (either for the game's menu bar or context menus). It is not known at this time how much work would have to be done in GUI2's core and framework to allow implementing these widgets -- in particular considering how GUI2 widgets are never used without a parent dialog, which menus might not necessarily have, at least with the current gameplay UI implementation.<br />
<br />
GUI2 menu FR: https://gna.org/bugs/?22820<br />
<br />
GUI2 combo box FR: https://gna.org/bugs/?23652<br />
<br />
=== GUI2 themable in-game UI ===<br />
<br />
The "themable" in-game UI refers to the gameplay UI including the sidebar, menu/status bar, and map view. Most of it is not implemented using proper GUI1 widgets at all, except for the various interactive buttons, menus (which are floating GUI1 listboxes), and the command and chat input boxes (floating GUI1 textboxes).<br />
<br />
Moving the theme UI to GUI2 would probably require finishing up theme support in GUI2 (which is largely incomplete), and may benefit from a rendering engine redesign as is also required for porting the game to SDL 2; in particular so that the GUI aspects are more clearly separated from the game board rendering aspect.<br />
<br />
'''Note:''' This task is here solely for the sake of completeness, and only somebody very well versed in the intricacies of Wesnoth's game rendering code and GUI2 should '''ever''' try to take it up. (And even then, I would not want to be anywhere near that person when they inevitably break down and fling one or more tables around upon realizing the sheer complexity of the task. -- shadowm)<br />
<br />
== Add-ons server and client ==<br />
<br />
=== Passphrase hashing ===<br />
<br />
The add-ons server (campaignd) uses a very dumb authentication scheme for uploading add-ons where an author sets a passphrase (or gets a random passphrase assigned by the game) the first time they upload to the server, and subsequent uploads of the same add-on are only allowed if the passphrase matches. The passphrase is stored in clear text form both client and server-side, which has [http://forums.wesnoth.org/viewtopic.php?f=62&t=42663 various implications].<br />
<br />
Ideally, the server would store all passphrases in a hashed form.<br />
<br />
=== Port redirection ===<br />
<br />
Wesnoth's MP server (wesnothd) uses a single port (15000) for servicing most requests and redirects clients to different ports according to the game client's version number. This allows the server administrators to reassign ports freely without having to modify the game client.<br />
<br />
The add-ons server (campaignd) and client instead have a hardcoded default port number for a Wesnoth version series. For example, 1.12.x is hardcoded to default to 15006. This becomes a maintainability issue as add-on servers get decommissioned and their port numbers can't be reused for fear of misdirecting obsolete client versions to the wrong instance with incompatible add-ons.<br />
<br />
=== Incremental upgrades and uploads ===<br />
<br />
Right now, whenever a new add-on version is published, players must download (or conversely, upload) the whole contents, even if the differences between both versions amount to a single line change. This is not a problem with small add-ons, but there is a substantial number of large (> 10 MiB) add-ons on the server. Large downloads and uploads are inconvenient for players on slow or metered connections, and also increase the server's traffic requirements.<br />
<br />
Ideally, for each add-on it attempts to upgrade or upload, the add-ons client should be able to send the server its local list of files with hashes, so that the server can identify which files need to be transmitted to/by the client, all archived on the fly like normal add-on downloads/uploads. The obvious downside is that the server would need to calculate an add-on's file hashes on demand, increasing CPU usage when servicing upgrades or uploads; this could be avoided by generating its file hashes when servicing uploads instead.<br />
<br />
See also: https://gna.org/bugs/?19972 (for uploads only; there should be one for downloads too but I couldn't find it -- shadowm)<br />
<br />
=== Porting the server to Asio ===<br />
<br />
Although the client uses Boost.Asio for communications, the server continues to use SDL_net instead. This means, amongst other things, that we are limited to IPv4 and an unmaintained codebase full of hacks waiting to break apart in the future (Wesnoth's SDL_net code does, amongst other things, tamper with what are supposed to be opaque data structures maintained by SDL_net).<br />
<br />
There was an attempt to build a new add-ons server (umcd) using Asio as part of GSoC, but it ultimately failed and the developers are no longer involved with the project. The umcd codebase status as of this writing is unknown.<br />
<br />
== Multiplayer server and client ==<br />
<br />
=== Porting the server and client to Asio ===<br />
<br />
As with campaignd above, it would be nice to move the multiplayer server and client to Asio so that we could drop the SDL_net dependency and obtain IPv6 support. There's a [https://github.com/wesnoth/wesnoth/tree/asio_wesnothd branch] to port the server to Asio.<br />
<br />
=== Improve server WML processing ===<br />
<br />
The server uses its own custom WML implementation separate from the main engine's to store and process WML objects for games -- see [[WesnothdDesign#simple_wml]]. This is intended to improve performance and reduce wesnothd's memory footprint with large numbers of games and complex scenarios. However, the simple_wml code sometimes messes up WML attribute translatability, resulting in MP scenarios/campaigns being untranslated for non-hosts in networked MP (http://gna.org/bugs/?22989). Fixing this is not easy due to the aforementioned performance requirements.<br />
<br />
== Data structures ==<br />
<br />
=== Make the Lua state persistent ===<br />
<br />
Wesnoth is designed to make all data files as simple and human-readable as possible, including savefiles. WML is designed so that it is always very easy to write the entire WML state as plaintext and reload it correctly. There are many benefits of this, but especially <br />
<br />
* It makes it easy for beginners / students to read the files and see what's going on<br />
* It makes it easy for us to debug problems without needing special tools to read the savefiles<br />
* It makes it easy to edit save files to work around any possible bugs. Users have even reported opening savefiles from version 1.10 in microsoft word (!) to correct minor bugs in mp and resaving them, as a policy for tournament games.<br />
<br />
This was unfortunately somewhat lost when we added lua. If you use lua in your scenarios, things become more complicated because we can't save the lua state at all. If you rely on lua variables to save information, then when your scenario is saved and reloaded those variables will get wiped. The wesnoth engine provides places for lua to hook into "onsave" and "onload" so that the scenario developer can write their own serialization routines, but this is just punting the problem to scenario developers.<br />
<br />
We also provide the "preload" event type specifically to work around the issue -- unlike all other events, preload is called exactly once for every time the scenario is loaded. The purpose is to give another way that lua users can initialize a table of lua functions used by their addon and guarantee that this happens before the functions are called. But to non-lua users this event is basically unsafe for normal use otherwise -- if there is a preload event which e.g. increments a WML variable, then the WML state now depends on how many times the scenario is saved or reloaded. In a normal scenario, save / reload events should be invisible, and normally if this isn't the case it indicates a bug similar to an OOS.<br />
<br />
A nice solution to this would be if we properly serialized the lua state alongside the WML in a savefile. The most suitable solution is probably this library: https://github.com/fnuecke/eris<br />
It would require significant additional work as well to find a good way to serialize the C functions that we expose to lua, and the userdata like units held by lua.<br />
<br />
More info here: http://lua-users.org/wiki/PlutoLibrary<br />
<br />
<br />
[[Category:Development]]<br />
[[Category:Future]]</div>Loonycyborghttps://wiki.wesnoth.org/index.php?title=Download&diff=49292Download2013-03-24T16:23:12Z<p>Loonycyborg: /* MS Windows */</p>
<hr />
<div>{{Download/Translations}}<br />
Welcome to the Battle for Wesnoth downloads page. The BFW project team only officially releases the source code. Binary packages are only provided by community volunteers and hosted here. Torrents are also unofficial.<br />
<br />
If the latest binaries are not currently available for your OS, please check back in a few days to see if they have been placed here. Packagers have been informed of the release, please be patient. In the meantime, read the [[FAQ#A_new_version_is_out.2C_but_where_is_the_download_for_.5BWindows.2C_Mac_OS.2C_etc..5D.3F|FAQ]].<br />
<br />
__NOTOC__<br />
Jump to: [[Download#Stable_.281.10_branch.29|Stable Branch]] | [[Download#Stable_.28older_versions.29|Stable Branch (older versions)]] | [[Download#Development_.281.11_branch.29|Development Branch]]<br />
<br />
== Stable (1.10 branch) ==<br />
The stable files are meant to be used as a stable and rather balanced version of the game. Each version of the 1.10 branch is compatible to each other.<br />
<br />
Version 1.10.6 is the latest stable version. This version is recommended for most players since the 1.10 online multiplayer community is very large and user-made campaign server has a robust content selection. <br />
<br />
==== Source code ====<br />
* [http://sourceforge.net/projects/wesnoth/files/wesnoth-1.10/wesnoth-1.10.6/wesnoth-1.10.6.tar.bz2/download Current Version] (1.10.6, 330.1 MB)<br />
* [http://sourceforge.net/projects/wesnoth/files/wesnoth-1.10/wesnoth-1.10.5/wesnoth-1.10.5.tar.bz2/download Previous Version] (1.10.5, 327.7 MB)<br />
<br />
* [[CompilingWesnoth|Compiling Guide]] - how to compile the source code<br />
<br />
==== MS Windows ====<br />
* [http://sourceforge.net/projects/wesnoth/files/wesnoth-1.10/wesnoth-1.10.6/wesnoth-1.10.6-win32.exe/download Current Version] (1.10.6, 302.7 MB)<br />
* [http://sourceforge.net/projects/wesnoth/files/wesnoth-1.10/wesnoth-1.10.5/wesnoth-1.10.5-win32.exe/download Previous Version] (1.10.5, 301.2 MB)<br />
<br />
==== Mac OS X (10.5+) ====<br />
* [http://sourceforge.net/projects/wesnoth/files/wesnoth-1.10/wesnoth-1.10.6/Wesnoth_1.10.6.dmg/download Current Version] (1.10.6 332.0 MB)<br />
* [http://sourceforge.net/projects/wesnoth/files/wesnoth-1.10/wesnoth-1.10.5/Wesnoth_1.10.5.dmg/download Previous Version] (1.10.5 328.8 MB)<br />
<br />
==== GNU/Linux ====<br />
* There are binaries for many different GNU/Linux Distributions. Not all are always up to date with the current release. Please have a look at the [[WesnothBinariesLinux|Linux binary page]] for more information about the binaries for your Distribution.<br />
<br />
==== OpenPandora ====<br />
* [http://sourceforge.net/projects/wesnoth/files/wesnoth-1.10/wesnoth-1.10.6/wesnoth-1.10.6-1.pnd/download Current Version] (1.10.6-1, 323.2 MB)<br />
* [http://sourceforge.net/projects/wesnoth/files/wesnoth-1.10/wesnoth-1.10.5/wesnoth-1.10.5-1.pnd/download Previous Version] (1.10.5-1, 320.5 MB)<br />
<br />
==== Miscellaneous ====<br />
* [http://sourceforge.net/projects/wesnoth/files/wesnoth-1.10/wesnoth-1.10.6/wesnoth-1.10.6.tar.bz2.md5/download md5sum for current source code]<br />
* [http://www.wesnoth.org/wiki/Download_Xdeltas#Stable_Version_1.10.x Xdelta for the source code]<br />
* [http://sourceforge.net/projects/wesnoth/files/ SourceForge page for current and all previous versions]<br />
<br />
== Stable (older versions) ==<br />
Several operating systems do not offer a binary of the latest stable release. Here is a list of the latest known (stable version) binaries for various systems. For those older versions there often is no (official) multiplayer or addon server available anymore.<br />
<br />
==== AmigaOS4 ====<br />
* [http://www.amigasoft.net/pages/games/download/Wesnoth186.lha.lzh Older Version] (1.8.6, 300MB)<br />
<br />
==== (Open)Solaris ====<br />
* [http://sourceforge.net/projects/wesnoth/files/wesnoth-1.4/wesnoth-1.4.5/wesnoth-solaris-i386-1.4.5.pkg.bz2/download Older Version] (1.4.5, 145.6 MB), not compatible with 1.6.x<br />
<br />
==== OS/2 & eComStation ====<br />
* [http://download.smedley.info/wesnoth-1.4.5-os2-20080828.zip Older Version] (1.4.5, 160 MB), not compatible with 1.6.x<br />
<br />
==== RISC OS ====<br />
*[http://www.riscos.info/packages/arm/Games/wesnoth_1.4.5-1.zip Older version] (1.4.5-1, 140MB), not compatible with 1.6.x<br />
<br />
==== Syllable ====<br />
* [http://downloads.syllable.org/Syllable/i586/applications/contributed/Battle-for-Wesnoth/Battle-for-Wesnoth-1.2.6.application Older Version] (1.2.6, 60.8 MB), not compatible with 1.6.x<br />
<br />
== Development (1.11 branch) ==<br />
Version 1.11.x is the latest development version, boasting updated graphics and new exciting features. However, there may be occasional bugs or performance problems in the development versions since heavy changes are taking place all the time. For balanced and stable gaming, it is recommended you use the latest version of the 1.10.x branch. This version is recommended for coders and campaign developers, as well as those who want to preview the future of Wesnoth. People familiar with version control systems and compiling can follow the latest development by checking [[WesnothRepository]].<br />
<br />
==== Source code ====<br />
* [http://sourceforge.net/projects/wesnoth/files/wesnoth/wesnoth-1.11.2/wesnoth-1.11.2.tar.bz2/download Current Version] (1.11.2, 352,4 MB)<br />
* [http://sourceforge.net/projects/wesnoth/files/wesnoth/wesnoth-1.11.1/wesnoth-1.11.1.tar.bz2/download Previous Version] (1.11.1, 338.8 MB)<br />
<br />
* [[CompilingWesnoth|Compiling Guide]] - how to compile the source code<br />
<br />
==== MS Windows ====<br />
* [http://sourceforge.net/projects/wesnoth/files/wesnoth/wesnoth-1.11.2/wesnoth-1.11.2-win32.exe/download Current Version] (1.11.2, 321.7 MB))<br />
* [http://sourceforge.net/projects/wesnoth/files/wesnoth/wesnoth-1.11.1/wesnoth-1.11.1-win32.exe/download Previous Version] (1.11.1, 312.0 MB))<br />
<br />
==== Mac OS X (10.5+) ====<br />
* 1.11.2 is not available as Mac OSX binary (yet)<br />
* [http://sourceforge.net/projects/wesnoth/files/wesnoth/wesnoth-1.11.1/Wesnoth_1.11.1a.dmg/download Previous Version] (1.11.1 338.9 MB)<br />
<br />
==== GNU/Linux ====<br />
* There are binaries for many different GNU/Linux Distributions. Not all are always up to date with the current release. Please have a look at the [[WesnothBinariesLinux|Linux binary page]] for more information about the binaries for your Distribution.<br />
<br />
==== OpenPandora ====<br />
* [http://sourceforge.net/projects/wesnoth/files/wesnoth/wesnoth-1.11.2/wesnoth-1.11.2-1.pnd/download Current Version] (1.11.2-1, 340.9 MB)<br />
* [http://sourceforge.net/projects/wesnoth/files/wesnoth/wesnoth-1.11.1/wesnoth-1.11.1-1.pnd/download Previous Version] (1.11.1-1, 330.3 MB)<br />
<br />
==== Miscellaneous ====<br />
* [http://sourceforge.net/projects/wesnoth/files/wesnoth/wesnoth-1.11.2/wesnoth-1.11.2.tar.bz2.md5/download md5sum for current source code]<br />
* [http://wiki.wesnoth.org/Download_Xdeltas#Development_Version_1.11.x Xdelta for the source code]<br />
* [http://sourceforge.net/projects/wesnoth/files/ SourceForge page for current and all previous versions]<br />
* [http://sourceforge.net/projects/wesnoth/files/unofficial/Mac%20Compile%20Stuff/wesnoth_compile_mac_1.9.zip/download MacCompileStuff for 1.9]<br />
<br />
== License ==<br />
''Main article: [[Wesnoth:Copyrights]]<br />
<br />
This program is free software; you can redistribute it and/or modify it under the terms of the [http://www.fsf.org/copyleft/gpl.html GNU General Public License version 2], as published by the [http://www.fsf.org Free Software Foundation].<br />
This program is distributed in the hope that it will be useful, but without any warranty; without even the implied warranty of merchantability or fitness for a particular purpose. See the GNU General Public License for more details.<br />
<br />
== UMC Editor ==<br />
This is available with Wesnoth 1.9.x and greater (including Wesnoth 1.10.x).<br />
Details and installation steps can be found at: http://eclipse.wesnoth.org<br />
<br />
== See also ==<br />
* [http://changelog.wesnoth.org Changelog]<br />
* [[WesnothBinaries| More binaries]]<br />
* [[WesnothRepository]] - bleeding edge version from the repository<br />
<br />
[[Category:Building and Installing]]</div>Loonycyborghttps://wiki.wesnoth.org/index.php?title=EditingWesnoth&diff=38717EditingWesnoth2010-10-17T22:29:35Z<p>Loonycyborg: /* Linux */</p>
<hr />
<div><!-- single enters on this page are intentional --><br />
<br />
== Game and User Directories ==<br />
<br />
Wherever you install the game, there will be a game data directory that contains, of course, the game's data. This directory should have the following subdirectories: data, music, sounds, and images. There are several others, but these are the important ones. In this wiki, the terms "game data", wesnoth/data, or ./data refers to the wesnoth/data directory. You normally should not modify these files, but you can if you want to modify a unit or something.<br />
<br />
The user data directory holds your preferences file, custom maps, saved games, the WML cache and data files corresponding to user-created content. In this wiki, "user data" and ''userdata''/ refer to this dir.<br />
<br />
The paths to the game data and user data dirs vary according to the operating system and packager. <br />
<br />
=== Where is my '''game''' data directory? ===<br />
<br />
====Windows====<br />
<br />
* ''X:\Program Files\Battle for Wesnoth <version>\data'', where X: corresponds to the drive where Windows is installed (normally C:).<br />
* The path may be different if you originally chose to install the game in a different location. In such case, look for the data folder in the folder where you installed the game.<br />
<br />
====Mac OS X====<br />
<br />
* SourceForge.net bundle: Control+click on the application icon. Select "Show Package Contents." Select "Contents", then "Resources".<br />
* Custom builds: ''/usr/local/share/wesnoth''<br />
<br />
====Linux====<br />
<br />
* Custom builds: ''/usr/local/share/wesnoth''<br />
* Debian/Ubuntu packages, or emerge (Gentoo): ''/usr/share/games/wesnoth''<br />
* Red Hat Linux-based distributions in general (openSUSE, Fedora): ''/usr/share/wesnoth''<br />
* Mandriva: ''/usr/share/games/wesnoth''<br />
* Slackware Linux: ''/usr/local/share/wesnoth''<br />
* Alternatively, you can try one of commands <code>slocate wesnoth</code> or <code>find / -name '*wesnoth*'</code> (as yourself, not as superuser) if you are using a different distribution or the locations mentioned above don't exist.<br />
<br />
=== Where is my '''user''' data directory? ===<br />
<br />
====Windows====<br />
<br />
* Windows 2000/XP (1.8 and later): ''My Documents\My Games\Wesnoth1.8''<br />
* Windows Vista/7 (1.8 and later): ''Documents\My Games\Wesnoth1.8''<br />
* General (before 1.8): ''X:\Program Files\Wesnoth <version>\userdata'', where X: corresponds to the drive where Windows is installed (normally C:).<br />
<br />
''Note: If you don't remember where you installed the game, right click on the game's shortcut, open properties, and click on the "Find target" button, then search for the "data" folder.''<br />
<br />
====Mac OS X====<br />
<br />
* SourceForge.net bundle: ''~/Library/Application Support/Wesnoth_1.x/'' (1.8 and later), or ''~/Library/Preferences/Wesnoth'' (older versions).<br />
* Custom builds: same as Linux - see below for details.<br />
<br />
====Linux====<br />
<br />
* Wesnoth 1.8 and later: ''~/.wesnoth<version>'' (e.g. ''~/.wesnoth1.8'')<br />
* Older versions: ''~/.wesnoth''.<br />
* It's also possible to check the beginning of Wesnoth's stderr output in a terminal emulator to see the path Wesnoth uses to access its configuration.<br />
<br />
== Game data ==<br />
<br />
The major directories you need to know about are wesnoth/data, wesnoth/data/core/units, wesnoth/data/campaigns, wesnoth/data/multiplayer, wesnoth/images and wesnoth/data/core/images<br />
<br />
Become familiar with what is in ./data/campaigns and ./data/multiplayer/scenarios. These have the officially distributed campaigns and multiplayer maps. If you ever want to examine or edit one of the scenario configuration files, this is where you would go. For example, a common question is how a new player can give himself more turns or gold in scenario X. This is where you would go to do that.<br />
<br />
Two very important directories are ./data/core/units/ and ./images. You have the ability to drop new units or images in these directories and have the game recognize them. When specifying an image for something, you do so relative to ./images.<br />
<br />
== User data ==<br />
<br />
The user data directory can do a lot of things. The game looks here for several things:<br />
* ''userdata''/data/add-ons - campaign configuration files and subdirectories<br />
* ''userdata''/editor/maps - multiplayer standalone maps (map data only)<br />
<br />
The ''userdata''/data/add-ons directory is particularly useful. A single configuration file here can selectively point to an entire subdirectory tree of units, images, sounds, scenarios, and macros. This allows you to wall off parts. Content included in the userdata units or images directories will be available globally whether you want it or not.<br />
<br />
For example, assume you have a campaign called MyCampaign. This is what the ''userdata''/data/add-ons directory might look like:<br />
* ''userdata''/data/add-ons/MyCampaign/ - your campaign's directory<br />
* ''userdata''/data/add-ons/MyCampaign/_main.cfg - a text file containing your instructions for the game about how to load the campaign<br />
** ''userdata''/data/add-ons/MyCampaign/scenarios<br />
** ''userdata''/data/add-ons/MyCampaign/units<br />
** ''userdata''/data/add-ons/MyCampaign/images<br />
** ''userdata''/data/add-ons/MyCampaign/music<br />
** ''userdata''/data/add-ons/MyCampaign/sounds<br />
** ''userdata''/data/add-ons/MyCampaign/utils<br />
<br />
== See Also ==<br />
<br />
* [[Create]]<br />
<br />
<div style="border:1px solid #5599FF; margin-top: 10px; margin-bottom: 5px; padding: 5px;"><br />
- [[EditingWesnoth|English]] - [[Editer Wesnoth vf|Français]] -<br />
</div><br />
[[Category:Create]]</div>Loonycyborghttps://wiki.wesnoth.org/index.php?title=PreprocessorRef&diff=30757PreprocessorRef2009-06-20T13:18:47Z<p>Loonycyborg: /* The WML preprocessor */</p>
<hr />
<div>{{WML Tags}}<br />
== The WML preprocessor ==<br />
<br />
Wesnoth loads just one configuration file directly: '''data/_main.cfg'''.<br />
However the WML preprocessor allows game.cfg to load in more files.<br />
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<br />
be parsed for macros, and after macro expansion will be parsed for macros<br />
again, and so on. As a result, you should not write a recursive macro,<br />
because it will cause errors<br />
(but, alas, not necessarily error messages).<br />
<br />
The following directives are used to create and use ''macros'',<br />
i.e. shortcuts which reduce repetition of information.<br />
See [[UtilWML]], [[UsefulWMLFragments]] for examples and [http://www.wesnoth.org/macro-reference.xhtml the macro reference] for the predefined core macros.<br />
* '''#define ''symbol'' [''parameters''] ''newline'' ''substitution'' #enddef''' all subsequent occurences of '''{''symbol'' [''arguments'']}''' (see below) will be replaced by ''substitution'' with all occurences of any parameter {''parameter''} within ''substitution'' replaced by the parameter's corresponding value in ''arguments''. For example, the UNIT macro used below would be defined:<br />
<br />
#define UNIT TYPE X Y## the ordering is important here;<br />
## since WML does not distinguish<br />
## data into different types, only<br />
## 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 "repetition of information",<br />
## since it is no longer necessary to specify<br />
## each created unit as an enemy.<br />
[/unit]<br />
#enddef<br />
(See [[SingleUnitWML]] for information on creating units using WML.)<br />
* '''{''symbol'' [''arguments'']}''' if ''symbol'' is defined, the preprocessor will replace this instruction by the expression ''symbol'' is defined as, using ''arguments'' as parameters. You can create multiple word arguments by using parentheses to restrain the argument. For example, while '''{UNIT Wolf Rider 18 24}''' will attempt to create a "Wolf" at (Rider,18), causing Wesnoth to crash, the macro '''{UNIT (Wolf Rider) 18 24}''' will create a "Wolf Rider" at (18,24) as it should. ('''UNIT''' is defined above). See the ''#define'' preprocessor instruction above for information on defining symbols, including symbols with arguments. Several symbols are defined in the normal game code; for reference they are listed in [[UtilWML]].<br />
<br />
Unlike the other preprocessor directives, #ifdef and #ifndef are not<br />
mere conveniences.<br />
They are necessary to distinguish between different modes of play.<br />
* '''#ifdef ''symbol'' ''substitution-if-stored'' [#else ''substitution-if-not-stored''] #endif''' If ''symbol'' has been stored, the whole block will be replaced by ''substitution-if-stored''. If not, it will be replaced by ''substitution-if-not-stored'' if it is available. ''symbol'' can take the following values:<br />
** a campaign difficulty level. Usually '''EASY''', '''NORMAL''', or '''HARD''', it is decided by the key ''difficulties'' (see [[CampaignWML]]).<br />
** a campaign ID. Each campaign stores a preprocessor ID. See ''define'', [[CampaignWML]].<br />
** '''MULTIPLAYER''' is stored when the player is playing or setting up a multiplayer game (i.e. a game with '''scenario_type=multiplayer''').<br />
** '''TUTORIAL''' is stored when the player is playing the tutorial.<br />
** '''APPLE''' is stored if the computer Wesnoth is being run on is an Apple. (this one is only available to the configuration of the game)<br />
** '''PYTHON''' is stored if Python support is built in and available. Use this to for example show a warning when starting a campaign that uses Python AI's, if Python isn't available.<br />
* '''#ifndef''' behaves exactly like '''#ifdef''', except that it inverts the test sense; guarded text is included only if ''symbol'' has not been stored.<br />
''#undef'' can be useful too if ''#ifdef'' is not enough.<br />
* '''#undef ''symbol'' ''' erases ''symbol''<br />
<br />
These directives expand a file by including other files, ''filename'' may not contain '..' or the directive will be skipped:<br />
* '''{''filename''}''' if ''filename'' isn't a predefined symbol (see above), Wesnoth will assume it's a path to a file in the main '''data/''' subdirectory of Wesnoth and include the file it points to here "as is". Forward slashes('''/''') should be used to separate directories from their elements, even if your platform uses a different symbol such as colon (''':''') or backslash ('''\'''). <br />
* '''{~''filename''}''' similar to above, but the preprocessor assumes that the filename is relative to '''data/''' subdirectory of the user data directory. The ''user data directory'' varies depending on platform. See [[EditingWesnoth#Where_is_my_user_data_directory.3F|Where_is_my_user_data_directory?]]<br />
<br />
* '''{@''filename''}''' is a convenient way to make Wesnoth look for a file by that name in both the main and the user data directory. It is equivalent to writing '''{''filename''}{~''filename''}'''.<br />
* '''{./''filename''}''' is similar to the '''{''filename''}''' directive, but is assumed to be relative to the directory which contains the file in which this appears. For example, if used in game.cfg, it is equivalent to '''{''filename''}'''.<br />
* If ''filename'' points to a directory, the preprocessor will include all files in the directory ''filename'', non-recursively and in alphabetical order. Starting in 1.3.3, some files in such directories are handled specially. <br />
<br />
If there is a file named ''dir/_main.cfg'' in a directory referenced as '''{''dir''}''', only that ''_main.cfg'' file is processed; it may include other files in itself, of course . This feature is useful for creating WML directories that are self-contained WML packages with their own initializations (like campaigns). This can replace the older convention of having a ''dir.cfg'' at the same level as ''dir'' which does '''{''dir''}''' somewhere in itself.<br />
<br />
If there are files named ''dir/*/_main.cfg'' in a directory referenced as '''{''dir''}''', where * is any subdirectories ''dir'', then they all are processed (except if there is also a file named ''dir/_main.cfg''). This means that if you have a layout like this:<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 />
Then '''{dir}''' will process (in alphabetical order): dir/a/_main.cfg, dir/b/main.cfg, dir/other.cfg.<br />
<br />
If there is a file named ''dir/_final.cfg'' in a directory referenced as '''{''dir''}''' (and no ''main.cfg'', so that all files in the directory are processed normally) the ''_final.cfg'' is guaranteed to be processed ''after'' all other files in the directory.<br />
<br />
If there is a file named ''dir/_initial.cfg'' in a directory referenced as '''{''dir''}''' (and no ''main.cfg'', so that all files in the directory are processed normally) the ''_initial.cfg'' is guaranteed to be processed ''before'' all other files in the directory.<br />
<br />
<br />
<br />
Note that the parser was changed various times, so don't expect older Wesnoth version to behave exactly the same.<br />
<br />
== See Also ==<br />
* [[SyntaxWML]]<br />
* [[ReferenceWML]]<br />
<br />
<br />
[[Category: WML Reference]]</div>Loonycyborghttps://wiki.wesnoth.org/index.php?title=PreprocessorRef&diff=30756PreprocessorRef2009-06-20T13:08:27Z<p>Loonycyborg: /* The WML preprocessor */</p>
<hr />
<div>{{WML Tags}}<br />
== The WML preprocessor ==<br />
<br />
Wesnoth loads just one configuration file directly: '''data/_main.cfg'''.<br />
However the WML preprocessor allows game.cfg to load in more files.<br />
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<br />
be parsed for macros, and after macro expansion will be parsed for macros<br />
again, and so on. As a result, you should not write a recursive macro,<br />
because it will cause errors<br />
(but, alas, not necessarily error messages).<br />
<br />
The following directives are used to create and use ''macros'',<br />
i.e. shortcuts which reduce repetition of information.<br />
See [[UtilWML]], [[UsefulWMLFragments]] for examples and [http://www.wesnoth.org/macro-reference.xhtml the macro reference] for the predefined core macros.<br />
* '''#define ''symbol'' [''parameters''] ''newline'' ''substitution'' #enddef''' all subsequent occurences of '''{''symbol'' [''arguments'']}''' (see below) will be replaced by ''substitution'' with all occurences of any parameter {''parameter''} within ''substitution'' replaced by the parameter's corresponding value in ''arguments''. For example, the UNIT macro used below would be defined:<br />
<br />
#define UNIT TYPE X Y## the ordering is important here;<br />
## since WML does not distinguish<br />
## data into different types, only<br />
## 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 "repetition of information",<br />
## since it is no longer necessary to specify<br />
## each created unit as an enemy.<br />
[/unit]<br />
#enddef<br />
(See [[SingleUnitWML]] for information on creating units using WML.)<br />
* '''{''symbol'' [''arguments'']}''' if ''symbol'' is defined, the preprocessor will replace this instruction by the expression ''symbol'' is defined as, using ''arguments'' as parameters. You can create multiple word arguments by using parentheses to restrain the argument. For example, while '''{UNIT Wolf Rider 18 24}''' will attempt to create a "Wolf" at (Rider,18), causing Wesnoth to crash, the macro '''{UNIT (Wolf Rider) 18 24}''' will create a "Wolf Rider" at (18,24) as it should. ('''UNIT''' is defined above). See the ''#define'' preprocessor instruction above for information on defining symbols, including symbols with arguments. Several symbols are defined in the normal game code; for reference they are listed in [[UtilWML]].<br />
<br />
Unlike the other preprocessor directives, #ifdef and #ifndef are not<br />
mere conveniences.<br />
They are necessary to distinguish between different modes of play.<br />
* '''#ifdef ''symbol'' ''substitution-if-stored'' [#else ''substitution-if-not-stored''] #endif''' If ''symbol'' has been stored, the whole block will be replaced by ''substitution-if-stored''. If not, it will be replaced by ''substitution-if-not-stored'' if it is available. ''symbol'' can take the following values:<br />
** a campaign difficulty level. Usually '''EASY''', '''NORMAL''', or '''HARD''', it is decided by the key ''difficulties'' (see [[CampaignWML]]).<br />
** a campaign ID. Each campaign stores a preprocessor ID. See ''define'', [[CampaignWML]].<br />
** '''MULTIPLAYER''' is stored when the player is playing or setting up a multiplayer game (i.e. a game with '''scenario_type=multiplayer''').<br />
** '''TUTORIAL''' is stored when the player is playing the tutorial.<br />
** '''APPLE''' is stored if the computer Wesnoth is being run on is an Apple. (this one is only available to the configuration of the game)<br />
** '''PYTHON''' is stored if Python support is built in and available. Use this to for example show a warning when starting a campaign that uses Python AI's, if Python isn't available.<br />
* '''#ifndef''' behaves exactly like '''#ifdef''', except that it inverts the test sense; guarded text is included only if ''symbol'' has not been stored.<br />
''#undef'' can be useful too if ''#ifdef'' is not enough.<br />
* '''#undef ''symbol'' ''' erases ''symbol''<br />
<br />
These directives expand a file by including other files, ''filename'' may not contain '..' or the directive will be skipped:<br />
* '''{''filename''}''' if ''filename'' isn't a predefined symbol (see above), Wesnoth will assume it's a path to a file in the main '''data/''' subdirectory of Wesnoth and include the file it points to here "as is". Forward slashes('''/''') should be used to separate directories from their elements, even if your platform uses a different symbol such as colon (''':''') or backslash ('''\'''). <br />
* '''{~''filename''}''' similar to above, but the preprocessor assumes that the filename is relative to the user data directory. The ''user data directory'' varies depending on platform. See [[EditingWesnoth#Where_is_my_user_data_directory.3F|Where_is_my_user_data_directory?]]<br />
<br />
* '''{@''filename''}''' is a convenient way to make Wesnoth look for a file by that name in both the main and the user data directory. It is equivalent to writing '''{''filename''}{~''filename''}'''.<br />
* '''{./''filename''}''' is similar to the '''{''filename''}''' directive, but is assumed to be relative to the directory which contains the file in which this appears. For example, if used in game.cfg, it is equivalent to '''{''filename''}'''.<br />
* If ''filename'' points to a directory, the preprocessor will include all files in the directory ''filename'', non-recursively and in alphabetical order. Starting in 1.3.3, some files in such directories are handled specially. <br />
<br />
If there is a file named ''dir/_main.cfg'' in a directory referenced as '''{''dir''}''', only that ''_main.cfg'' file is processed; it may include other files in itself, of course . This feature is useful for creating WML directories that are self-contained WML packages with their own initializations (like campaigns). This can replace the older convention of having a ''dir.cfg'' at the same level as ''dir'' which does '''{''dir''}''' somewhere in itself.<br />
<br />
If there are files named ''dir/*/_main.cfg'' in a directory referenced as '''{''dir''}''', where * is any subdirectories ''dir'', then they all are processed (except if there is also a file named ''dir/_main.cfg''). This means that if you have a layout like this:<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 />
Then '''{dir}''' will process (in alphabetical order): dir/a/_main.cfg, dir/b/main.cfg, dir/other.cfg.<br />
<br />
If there is a file named ''dir/_final.cfg'' in a directory referenced as '''{''dir''}''' (and no ''main.cfg'', so that all files in the directory are processed normally) the ''_final.cfg'' is guaranteed to be processed ''after'' all other files in the directory.<br />
<br />
If there is a file named ''dir/_initial.cfg'' in a directory referenced as '''{''dir''}''' (and no ''main.cfg'', so that all files in the directory are processed normally) the ''_initial.cfg'' is guaranteed to be processed ''before'' all other files in the directory.<br />
<br />
<br />
<br />
Note that the parser was changed various times, so don't expect older Wesnoth version to behave exactly the same.<br />
<br />
== See Also ==<br />
* [[SyntaxWML]]<br />
* [[ReferenceWML]]<br />
<br />
<br />
[[Category: WML Reference]]</div>Loonycyborghttps://wiki.wesnoth.org/index.php?title=EditingWesnoth&diff=30755EditingWesnoth2009-06-20T12:47:21Z<p>Loonycyborg: /* Windows */</p>
<hr />
<div><!-- single enters on this page are intentional --><br />
<br />
== Game and User Directories ==<br />
<br />
Wherever you install the game, there will be a game data directory that contains, of course, the game's data. This directory should have the following subdirectories: data, music, sounds, and images. There are several others, but these are the important ones. In this wiki, the terms "game data", wesnoth/data, or ./data refers to the wesnoth/data directory. You normally do not need to modify these files, but you can if you want to modify a unit or something.<br />
<br />
The user data directory allows you to add custom content without modifying the game's own files. Each OS puts its user data directory in a different place. In this wiki, "user data", ''userdata''/''subdirectory'', or (occasionally) ~wesnoth/ refer to this directory.<br />
<br />
=== Where is my '''game''' data directory? ===<br />
<br />
====Windows====<br />
Usually C:\Program Files\Wesnoth\data but it will be different if you installed the game in a different location: look for the data folder in the folder where you installed the game.<br />
<br />
====Mac OS X====<br />
Downloaded from sourceforge: command-click on the application icon. Select "Show Package Contents." Select "Contents" then "Resources. <br />
If you did not download from sourceforge what do you do? <br />
Command line build: /usr/local/share/wesnoth<br />
<br />
====Linux====<br />
/usr/local/share/wesnoth <br><br />
From apt-get (Debian and Ubuntu) or emerge (Gentoo): /usr/share/games/wesnoth <br><br />
SUSE 10.0 (pre-installed): /usr/share/wesnoth<br><br />
Fedora 5 (Installed from yum repository RPM): /usr/share/wesnoth<br><br />
Mandriva 2006.0: /usr/share/games/wesnoth<br><br />
Slackware 12 (Installed from .tgz package at LinuxPackages.net): /usr/local/share/wesnoth<br><br />
If you don't find it, or if you use another distribution, try <code>find / -iname '*wesnoth*'</code>. (as yourself, not as superuser)<br />
<br />
=== Where is my '''user''' data directory? ===<br />
<br />
====Windows====<br />
c:\Program Files\Wesnoth\userdata<br />
<br />
or c:\Users\USERNAME\AppData\Local\VirtualStore\Program Files\Wesnoth\userdata<br />
on Vista, which has virtual folders. The AppData folder is hidden.<br />
Or if you don`t remember where you installed it right click on the game`s shortcut open properties and click on the `Find target` button,then search for the `data` folder.<br />
<br />
Starting from Wesnoth 1.6 it can be in MyDocuments\My Games\Wesnoth1.6 on Windows XP or Documents\My Games\Wesnoth1.6 on Vista.<br />
<br />
====Mac OS X====<br />
Downloaded from sourceforge: ~/Library/Preferences/Wesnoth <br><br />
Command line build: ~/.wesnoth <br><br />
For Wesnoth 1.7.x : ~/Library/Application Support/Wesnoth_1.x/<br />
<br />
====Linux====<br />
~/.wesnoth<br />
<br />
== Game data ==<br />
<br />
The major directories you need to know about are wesnoth/data, wesnoth/data/core/units, wesnoth/data/campaigns, wesnoth/data/multiplayer, wesnoth/images and wesnoth/data/core/images<br />
<br />
Become familiar with what is in ./data/campaigns and ./data/multiplayer/scenarios. These have the officially distributed campaigns and multiplayer maps. If you ever want to examine or edit one of the scenario configuration files, this is where you would go. For example, a common question is how a new player can give himself more turns or gold in scenario X. This is where you would go to do that.<br />
<br />
Two very important directories are ./data/core/units/ and ./images. You have the ability to drop new units or images in these directories and have the game recognize them. When specifying an image for something, you do so relative to ./images.<br />
<br />
== User Data ==<br />
The user data directory can do a lot of things. The game looks here for several things:<br />
* ''userdata''/data/campaigns - campaign configuration files and subdirectories<br />
* ''userdata''/editor/maps - multiplayer standalone maps (map data only)<br />
<br />
The ''userdata''/data/campaigns directory is particularly useful. A single configuration file here can selectively point to an entire subdirectory tree of units, images, sounds, scenarios, and macros. This allows you to wall off parts. Content included in the userdata units or images directories will be available globally whether you want it or not.<br />
<br />
For example, assume you have a campaign called MyCampaign. This is what the ''userdata''/data/campaigns directory might look like:<br />
* ''userdata''/data/campaigns/MyCampaign/ - your campaign's directory<br />
* ''userdata''/data/campaigns/MyCampaign/_main.cfg - a text file containing your instructions for the game about how to load the campaign<br />
** ''userdata''/data/campaigns/MyCampaign/scenarios<br />
** ''userdata''/data/campaigns/MyCampaign/units<br />
** ''userdata''/data/campaigns/MyCampaign/images<br />
** ''userdata''/data/campaigns/MyCampaign/music<br />
** ''userdata''/data/campaigns/MyCampaign/sounds<br />
** ''userdata''/data/campaigns/MyCampaign/utils<br />
<br />
== See Also ==<br />
<br />
* [[Create]]<br />
<br />
<div style="border:1px solid #5599FF; margin-top: 10px; margin-bottom: 5px; padding: 5px;"><br />
- [[EditingWesnoth|English]] - [[Editer Wesnoth vf|Français]] -<br />
</div><br />
[[Category:Create]]</div>Loonycyborghttps://wiki.wesnoth.org/index.php?title=ScenarioWML&diff=30627ScenarioWML2009-05-28T16:05:45Z<p>Loonycyborg: /* The [scenario] tag */</p>
<hr />
<div>{{WML Tags}}<br />
== the toplevel tags [multiplayer], [test], [tutorial], [scenario] ==<br />
<br />
The top level tags '''[multiplayer]''', '''[test]''', '''[tutorial]''' and '''[scenario]''' are all formatted the same way.<br />
The difference between these tags is the way that the scenarios they describe are accessed.<br />
<br />
The keys '''id''' and '''next_scenario''' affect how scenarios can be accessed.<br />
Whenever a scenario is won, the scenario with id=''next_scenario'' of the same tag type will be played.<br />
Units from the first scenario will be available for recall in the second.<br />
<br />
Some scenarios can be played without playing other scenarios first<br />
(in this case there is nothing on the recall list).<br />
These scenarios are called ''initial scenario''s.<br />
<br />
A list of initial scenarios, and how to access them:<br />
<br />
* All '''[multiplayer]''' scenarios are initial scenarios listed in the multiplayer scenario selector screen (accessed by the "multiplayer" button).<br />
<br />
* The '''[test]''' scenario with the attribute '''id=test''' is an initial scenario. This test scenario can be accessed by running the game in test mode. (note: this is NOT the same as debug mode. It can be accessed using -t or --test)<br />
<br />
* The '''[tutorial]''' scenario with the attribute '''id=tutorial''' is an initial scenario. The tutorial is accessed by clicking on the "tutorial" button.<br />
<br />
* Any '''[scenario]''' scenario with an id listed in the value of ''first_scenario'' in a campaign tag (see [[CampaignWML]]) is an initial scenario accessed by selecting that campaign after clicking on the "campaign" button.<br />
<br />
== The [scenario] tag ==<br />
<br />
The following keys and tags are recognized in '''[scenario]''' tags:<br />
<br />
* '''id''': A unique identifier for this scenario. All scenarios must have an id.<br />
<br />
* '''next_scenario''': The id of the scenario to load when the current one is won. This can be changed dynamically, to build non-linear campaigns.<br />
<br />
* '''description''': (translatable) only for multiplayer maps. Will show up as a tooltip when mousing over the minimap in the multiplayer setup screen.<br />
<br />
* '''name''': (translatable) is shown in several places in the level, including the intro screen. It is also the default name for saves on the level.<br />
<br />
* '''map_data''': inputs valid Wesnoth map data. See [[BuildingMaps]] for a description of the Wesnoth map syntax.<br />
<br />
* '''turns''': sets an event on turn ''turns'' causing the player to lose. Use ''-1'' to have no turn limit. See also [[EventWML]]<br />
<br />
* '''turn_at''': the turn to start on (default=1)<br />
<br />
* '''random_start_time''': controls random starting time of day. Possible values are yes and no or list of possible start times; starting from 1 to number of times. for example ''random_start_time=2,3,5,6'' (default=no)<br />
<br />
* '''music''': the music file relative to ''./music/'' to play during the scenario<br />
<br />
* '''[music]''': specifies the music tracks to play during this scenario, see [[MusicListWML]].<br />
<br />
* '''defeat_music''': specifies a comma-separated list of music tracks which may be chosen to play on defeat. If not provided, the default in [[GameConfigWML]] is used instead. May be overridden by [[DirectActionsWML|endlevel]] clauses.<br />
<br />
* '''victory_music''': specifies a comma-separated list of music tracks which may be chosen to play on victory. If not provided, the default in [[GameConfigWML]] is used instead. May be overridden by [[DirectActionsWML|endlevel]] clauses.<br />
<br />
* '''theme''': the UI theme that should be used when playing this scenario. See [[Using_custom_themes_in_campaigns]]<br />
<br />
* '''victory_when_enemies_defeated''': when this is set to '''yes''' (default), the player wins once all non-allied units with '''canrecruit=yes''' (aka leaders) are killed. (Currently this only controls the win condition for when all enemies are defeated; it does not prevent the player from losing if he has no leader.) When this value is true the following keys can be used:<br />
** '''carryover_percentage''': by default 80% of the gold is carried over to the next scenario, with this key the amount can be changed.<br />
** '''carryover_add''': if true the gold will be added to the starting gold the next scenario, if false the next scenario will start with the amount of the current scenario (after taxes) or the minimum in the next scenario. Default is false.<br />
<br />
* '''disallow_recall''': when this is set to 'no'(default), the player is allowed to recall units from previous scenarios.<br />
<br />
* '''experience_modifier''': the percentage that required XP to level up (for all units in the scenario) is multiplied by. Default 100. Note that when used in a campaign, weird things (like units being above the required XP to level up) can happen if this value is different for different scenarios.<br />
<br />
* '''[story]''': describes the intro screen. See [[IntroWML]]<br />
<br />
* '''[label]''': sets a label<br />
** '''x''', '''y''': location to set label<br />
** '''text''': the label<br />
<br />
* '''[time]''', '''[illuminated_time]''': how a day should progress. See [[TimeWML]]<br />
<br />
* '''[time_area]''': how a day should progress in a given area. Everywhere not specified in a [time_area] tag is affected by the [time] and [illuminated_time] tags in the [scenario] tag<br />
** takes x and y coordinates.<br />
** '''[time]''', '''[illuminated_time]''': how a day should progress in those locations. See [[TimeWML]]<br />
** time areas can be used in events, assigned identifiers, and removed at discretion. They also accept complete Standard Location Filters. See [[DirectActionsWML]].<br />
<br />
* '''[side]''': describes one player. See [[SideWML]]<br />
<br />
* '''[event]''': describes an event that may be triggered at a certain point of the scenario. See [[EventWML]]<br />
<br />
* '''map_generation''': another way to generate a map. The map will be generated randomly<br />
** '''default''': the default random map generator<br />
<br />
* '''[generator]''' if this is present, the map and scenario will be generated randomly. See [[MapGeneratorWML]]<br />
<br />
the following key is additionally recognized in '''[multiplayer]''' scenarios:<br />
* '''allow_new_game''': (default=yes) allow/prevent the scenario to be listed in the game creation interface. This is intended for extra scenarios in multiplayer campaigns<br />
<br />
== See Also ==<br />
<br />
* [[EventWML]]<br />
* [[ReferenceWML]]<br />
<br />
<br />
[[Category: WML Reference]]</div>Loonycyborghttps://wiki.wesnoth.org/index.php?title=ScenarioWML&diff=30626ScenarioWML2009-05-28T16:02:14Z<p>Loonycyborg: /* The [scenario] tag */</p>
<hr />
<div>{{WML Tags}}<br />
== the toplevel tags [multiplayer], [test], [tutorial], [scenario] ==<br />
<br />
The top level tags '''[multiplayer]''', '''[test]''', '''[tutorial]''' and '''[scenario]''' are all formatted the same way.<br />
The difference between these tags is the way that the scenarios they describe are accessed.<br />
<br />
The keys '''id''' and '''next_scenario''' affect how scenarios can be accessed.<br />
Whenever a scenario is won, the scenario with id=''next_scenario'' of the same tag type will be played.<br />
Units from the first scenario will be available for recall in the second.<br />
<br />
Some scenarios can be played without playing other scenarios first<br />
(in this case there is nothing on the recall list).<br />
These scenarios are called ''initial scenario''s.<br />
<br />
A list of initial scenarios, and how to access them:<br />
<br />
* All '''[multiplayer]''' scenarios are initial scenarios listed in the multiplayer scenario selector screen (accessed by the "multiplayer" button).<br />
<br />
* The '''[test]''' scenario with the attribute '''id=test''' is an initial scenario. This test scenario can be accessed by running the game in test mode. (note: this is NOT the same as debug mode. It can be accessed using -t or --test)<br />
<br />
* The '''[tutorial]''' scenario with the attribute '''id=tutorial''' is an initial scenario. The tutorial is accessed by clicking on the "tutorial" button.<br />
<br />
* Any '''[scenario]''' scenario with an id listed in the value of ''first_scenario'' in a campaign tag (see [[CampaignWML]]) is an initial scenario accessed by selecting that campaign after clicking on the "campaign" button.<br />
<br />
== The [scenario] tag ==<br />
<br />
The following keys and tags are recognized in '''[scenario]''' tags:<br />
<br />
* '''id''': A unique identifier for this scenario. All scenarios should have an id.<br />
<br />
* '''next_scenario''': The id of the scenario to load when the current one is won. This can be changed dynamically, to build non-linear campaigns.<br />
<br />
* '''description''': (translatable) only for multiplayer maps. Will show up as a tooltip when mousing over the minimap in the multiplayer setup screen.<br />
<br />
* '''name''': (translatable) is shown in several places in the level, including the intro screen. It is also the default name for saves on the level.<br />
<br />
* '''map_data''': inputs valid Wesnoth map data. See [[BuildingMaps]] for a description of the Wesnoth map syntax.<br />
<br />
* '''turns''': sets an event on turn ''turns'' causing the player to lose. Use ''-1'' to have no turn limit. See also [[EventWML]]<br />
<br />
* '''turn_at''': the turn to start on (default=1)<br />
<br />
* '''random_start_time''': controls random starting time of day. Possible values are yes and no or list of possible start times; starting from 1 to number of times. for example ''random_start_time=2,3,5,6'' (default=no)<br />
<br />
* '''music''': the music file relative to ''./music/'' to play during the scenario<br />
<br />
* '''[music]''': specifies the music tracks to play during this scenario, see [[MusicListWML]].<br />
<br />
* '''defeat_music''': specifies a comma-separated list of music tracks which may be chosen to play on defeat. If not provided, the default in [[GameConfigWML]] is used instead. May be overridden by [[DirectActionsWML|endlevel]] clauses.<br />
<br />
* '''victory_music''': specifies a comma-separated list of music tracks which may be chosen to play on victory. If not provided, the default in [[GameConfigWML]] is used instead. May be overridden by [[DirectActionsWML|endlevel]] clauses.<br />
<br />
* '''theme''': the UI theme that should be used when playing this scenario. See [[Using_custom_themes_in_campaigns]]<br />
<br />
* '''victory_when_enemies_defeated''': when this is set to '''yes''' (default), the player wins once all non-allied units with '''canrecruit=yes''' (aka leaders) are killed. (Currently this only controls the win condition for when all enemies are defeated; it does not prevent the player from losing if he has no leader.) When this value is true the following keys can be used:<br />
** '''carryover_percentage''': by default 80% of the gold is carried over to the next scenario, with this key the amount can be changed.<br />
** '''carryover_add''': if true the gold will be added to the starting gold the next scenario, if false the next scenario will start with the amount of the current scenario (after taxes) or the minimum in the next scenario. Default is false.<br />
<br />
* '''disallow_recall''': when this is set to 'no'(default), the player is allowed to recall units from previous scenarios.<br />
<br />
* '''experience_modifier''': the percentage that required XP to level up (for all units in the scenario) is multiplied by. Default 100. Note that when used in a campaign, weird things (like units being above the required XP to level up) can happen if this value is different for different scenarios.<br />
<br />
* '''[story]''': describes the intro screen. See [[IntroWML]]<br />
<br />
* '''[label]''': sets a label<br />
** '''x''', '''y''': location to set label<br />
** '''text''': the label<br />
<br />
* '''[time]''', '''[illuminated_time]''': how a day should progress. See [[TimeWML]]<br />
<br />
* '''[time_area]''': how a day should progress in a given area. Everywhere not specified in a [time_area] tag is affected by the [time] and [illuminated_time] tags in the [scenario] tag<br />
** takes x and y coordinates.<br />
** '''[time]''', '''[illuminated_time]''': how a day should progress in those locations. See [[TimeWML]]<br />
** time areas can be used in events, assigned identifiers, and removed at discretion. They also accept complete Standard Location Filters. See [[DirectActionsWML]].<br />
<br />
* '''[side]''': describes one player. See [[SideWML]]<br />
<br />
* '''[event]''': describes an event that may be triggered at a certain point of the scenario. See [[EventWML]]<br />
<br />
* '''map_generation''': another way to generate a map. The map will be generated randomly<br />
** '''default''': the default random map generator<br />
<br />
* '''[generator]''' if this is present, the map and scenario will be generated randomly. See [[MapGeneratorWML]]<br />
<br />
the following key is additionally recognized in '''[multiplayer]''' scenarios:<br />
* '''allow_new_game''': (default=yes) allow/prevent the scenario to be listed in the game creation interface. This is intended for extra scenarios in multiplayer campaigns<br />
<br />
== See Also ==<br />
<br />
* [[EventWML]]<br />
* [[ReferenceWML]]<br />
<br />
<br />
[[Category: WML Reference]]</div>Loonycyborghttps://wiki.wesnoth.org/index.php?title=SoC_People_to_bug_on_IRC&diff=28849SoC People to bug on IRC2009-03-19T19:44:20Z<p>Loonycyborg: /* People to bug on IRC */</p>
<hr />
<div>== People to bug on IRC ==<br />
We have prepared a list of people with their "area of competence". This is to give you an idea on which areas those people can be of help for you. Of course you should always just ask in the IRC chan, but those are the most likely ones to answer questions in the respective area. And here is the list:<br />
<br />
=== boucman ===<br />
As our "patch monkey" he accustomed to critiquing patches of every kind. Beside this, he knows many areas of the game due to working on applying patches. He is particularly used to answering question from new coders, and doesn't mind explaining trivial stuff. He was the one who started the "two patches, you're in" policy and the ReferenceWML part of the project.<br />
<br />
=== Daniel Franke (dfranke) ===<br />
Daniel is the devteam's most recent addition, and has been primarily concerned with security auditing. Bug him <i>privately</i> if you think you've found a security issue.<br />
<br />
=== Dave alias Sirp ===<br />
Sirp started Wesnoth and is our lead developer. He is currently our C++ expert and is also the one that is working on the new Formula AI. Any questions regarding the formula AI should be directed to him.<br />
<br />
=== Elias Pscherning (elias) ===<br />
He wrote the original version of campgen and as such will know a lot about what is needed to to make such an editor work correctly. The work on a scenario editor might be based upon campgen and as such his knowledge will be really helpful.<br />
<br />
=== Eric S. Raymond (ESR) ===<br />
ESR is our project toolsmith; he has written several tools that semi-automate various aspects of WML maintenance. While most of our developers/designers concentrate on either the C++ core or WML but not both, he has a balanced understanding of both levels and may be helpful in helping students develop a grasp of the overall architecture. Finally, he did the last overhaul of the Wesnoth UI and understands UI design principles; he is well-equipped to guide students working in that area.<br />
<br />
=== ilor ===<br />
2008 GSoC student, worked on and maintains the new map editor in Wesnoth 1.5/1.6. Has some fairly recent experience with getting "in" the Wesnoth codebase.<br />
<br />
=== Karol Nowak (grzywacz) ===<br />
Two years he participated at GSoC as a student, so he will understand the situation of GSoC students. Beside this he is our top expert on Wesnoth for embedded devices as he worked on the gp2x support.<br />
<br />
=== loonycyborg ===<br />
Maintainer of Wesnoth's SCons build system and windows packager. Might also help out with other buildsystems.<br />
<br />
=== Mordante ===<br />
Many of the possible projects involve the code for which he is an area expert. Also, many of the possible projects currently listed on the ideas page require GUI parts to work. Mordante is currently busy rewriting the old gui engine, he will be our expert there as well as already being our area expert for the terrain engine.<br />
<br />
=== Nils Kneuper (Ivanovic) ===<br />
He is doing nothing special, he just does some "administrative work" like packaging fresh tarballs when it is time for them and works on setting up any kind of deadlines and timetables related to releasing. He has administrative powers in most areas, no matter if website, forum or IRC. Beside this he uploads translation updates, tries to communicate with the translation teams when it is required and translates a little bit himself every now and then. But in general he is not a real expert in anything, just has a look at things that come up and redirects people to the correct contacts.<br />
<br />
=== Noy ===<br />
Noy is an oddity among developers; he's got no coding skills whatsoever and possesses a limited understanding of computers, which is illustrated by his difficulty operating a Mac. Instead, Noy makes his contribution in gameplay and multiplayer design, drawing upon his background in social sciences research, military strategy and playing games online, to understand the effects of development on the playing community behavior. Along with Soliton, Noy is a useful conduit to discuss any issues in this area; just don't ask him about revising the level of randomness in the game.<br />
<br />
=== Noyga ===<br />
Another versatile developer, on the C++ side he doesn't concentrate on a particular area, did some tweaks to improve translations in some languages (like enabling the female forms for names in various place) but know quite well the C++ side of units, abilities and WML. On the WML side he's an expert.<br />
<br />
=== Sapient ===<br />
This developer started working on the GUI and widgets, but recently he focused more on improving the internal mechanics of the WML engine such as variable look-ups and filtering. Sapient is not very active anymore but he does come one IRC in the evenings (U.S.A.). He has touched-up many areas of the code in small ways over time, thus he has a good general knowledge of the C++ code and also has worked a little on some python maintenance scripts. He keeps an eye on the quality of incoming C++... especially if you plan on making any changes to GUI or WML, Sapient will be reviewing it closely and with a critical eye.<br />
<br />
=== Shadow Master/ShikadiLord ===<br />
He joined the development team very recently, but has enough knowledge to help newcomers with trivial questions about the code and/or the C++ language. His primary focuses are the various WML handlers, such as game events code. His knowledge of the WML language itself is also enough to answer most questions and solve most problems, but only if they are not related to multiplayer games. He also has some basic knowledge of the autotools machinery we use to configure Wesnoth for foreign computers.<br />
<br />
=== Soliton ===<br />
He knows our MP server setup best. Beside this he has already done a lot of work on the MP server himself. So he probably has most knowledge about it and, being one of our MP-developers, might provide important help from the perspective of the MP player community and what is needed there.<br />
<br />
=== YogiHH or Piotr Cychowski (cycholka) ===<br />
Since they are the two developers who know most about building under Windows, they will probably be really helpful. Either if the student comes from the Windows side, or to help test resulting work to make sure that it does work on Windows and, for the case that it does not, to show them where problems are.<br />
<br />
=== zookeeper or Mythological or Rhuvaen ===<br />
As our leading WML experts those are to be contacted when it comes to anything related WML problems since they know this stuff best. They do maintain most of the campaigns and improve them whenever they have a good idea for changes.<br />
<br />
=== See also ===<br />
[[SummerOfCodeIdeas|Summer of Code Ideas]] - The root where all information regarding SoC is (or better should be) linked from.<br />
<br />
[[Category:Summer of Code]]</div>Loonycyborghttps://wiki.wesnoth.org/index.php?title=WesnothBinariesLinux&diff=28106WesnothBinariesLinux2009-01-27T12:58:48Z<p>Loonycyborg: /* Gentoo */</p>
<hr />
<div>= GNU/Linux =<br />
Not all Distributions are always at the state of the current release. If you want to be sure to have the current version, please get the sources and compile it yourself.<br />
<br />
=== Arch Linux ===<br />
* For the official pkg from [extra]: <code>pacman -S wesnoth</code> <br />
* dibblethewrecker also provides regular SVN snapshots. Please see [ http://dtw.jiwe.org/content.php?article.9 here] for details of how to access the repo. As development of wesnoth continues this repo is likely to follow the unstable branch.<br />
<br />
=== Ark Linux ===<br />
* Ark Linux includes an official wesnoth package, currently at version 1.3.19 Simply use the package installation tool to install the wesnoth package, or run <code>apt-get update; apt-get install wesnoth</code> (or <code>apt-get -t dockyard-devel install wesnoth</code> if you wish to run the current development version of wesnoth with all other packages from the stable tree)<br />
* Users of other similar distributions can download the packages at [http://arklinux.osuosl.org/dockyard-devel the Ark Linux file server]. They are likely to run on any rpm based distribution that uses a recent version of gcc (>= 4.0) and glibc (>= 2.4).<br />
<br />
=== Debian ===<br />
* <code>aptitude install wesnoth</code><br/>(use <code>wesnoth-all</code> if you want to pull in all the campaigns and the editor, too)<br />
* [http://packages.debian.org/wesnoth Official packages] including the development releases in the experimental branch<br />
* [http://backports.org/ backports.org] offers the stable wesnoth releases for Debian stable, [http://backports.org/dokuwiki/doku.php?id=instructions instructions for how to use backports.org] are available on its site, you might want to [http://www.backports.org/debian/README.mirrors.html choose a mirror] instead of using the main site, though<br />
<br />
====Compiling====<br />
<br />
If you want to play with the SVN version directly you may have to compile it yourself. See [http://www.wesnoth.org/wiki/CompilingWesnoth Compiling Wesnoth].<br />
<br />
'''To install the dependencies:'''<br />
<br />
You can use a neat trick: Use the Build-Dependencies of the Debian package. This can be acomplished with adding a line like the following to your <code>/etc/apt/sources.list</code>:<br/><br />
<code>deb-src http://ftp.debian.org/debian/ main</code><br/><br />
It is mostly just a copy of your usual entry for your mirror with a substitution of the initial <code>deb</code> for <code>deb-src</code>. '''Do NOT delete your deb line!'''<br />
<br />
If you have your <code>deb-src</code> entry there, just do an <code>aptitude update</code> followed by an <code>aptitude build-dep wesnoth</code>. That will pull in all you need. As of 1.4 stable wesnoth, the dependencies also include all of the "Boost" libraries, you if your deb-src line is pointing to Debian stable/etch you need to also <code>aptitude install libboost-iostreams-dev libboost-test-dev</code>.<br />
<br />
'''To compile it:'''<br/><br />
If you have already installed an older version of wesnoth, uninstall it by:<br />
<br />
<code>aptitude purge wesnoth</code><br />
<br />
Note that this will not remove downloaded data or savegames which are stored in your home directory in the folder <code>.wesnoth</code>. From this point on you can simply follow the advices from the [http://www.wesnoth.org/wiki/CompilingWesnoth Compiling Wesnoth] page, no need to duplicate that informations in here. :)<br />
<br />
=== Ubuntu ===<br />
<br />
====Intrepid==== <br />
<br />
8.10's universe repository includes version 1.4.5<br />
<br />
You can install via System->Administration->Synaptic, via Applications->Add/Remove or aptitude/apt-get.<br />
<br />
====Hardy====<br />
<br />
8.04's universe repository includes version 1.4<br />
<br />
See the [http://ubuntuguide.org/wiki/Ubuntu:Gutsy#How_to_add_extra_repositories Ubuntu Starter Guide]'s section on adding the universe repositories.<br />
Install via System->Administration->Synaptic, via Applications->Add/Remove or aptitude/apt-get.<br />
<br />
Updated versions can be found in [http://www.getdeb.net/app.php?name=The+Battle+for+Wesnoth GetDeb.net]<br />
<br />
====Gutsy==== <br />
7.10's universe repository includes version 1.2.6.<br />
<br />
See the [http://ubuntuguide.org/wiki/Ubuntu:Gutsy#How_to_add_extra_repositories Ubuntu Starter Guide]'s section on adding the universe repositories.<br />
Install via System->Administration->Synaptic, via Applications->Add/Remove or aptitude/apt-get.<br />
<br />
Updated versions can be found in [http://www.getdeb.net/app.php?name=The+Battle+for+Wesnoth GetDeb.net]<br />
<br />
====Dapper====<br />
<br />
6.06's universe repository includes version 1.0.2.<br />
<br />
This is the (really old) stable release of the 1.0.x series. As this is not the latest version, Dapper users will need to do one of the following to obtain the latest version:<br />
*Upgrade to a later version of Ubuntu, or<br />
*Use an unofficial repository, or<br />
*Build from the source per Debian above, or<br />
*Use the generic binary for GNU/Linux found on the [[Download]] page.<br />
Of these options, the final one is most likely the easiest at this time, while building from source is the most reliable.<br />
<br />
====Compiling====<br />
If you choose to build the source you should add the datadir flag to ''configure'' to ensure your installation puts the data in the same place as the official installation path:<br />
<br />
cd /usr/src<br />
tar -xvzf wesnoth-1.x.x.tar.gz<br />
cd wesnoth-1.x.x<br />
./configure --datadir=/usr/share/games ...<br />
make<br />
sudo make install<br />
<br />
==== Internationalization support ====<br />
<br />
To enable operation in your favorite language, look in the file /usr/share/i18n/SUPPORTED for a line with an ISO language code matching what you want. Append that line to /var/lib/locales/supported.d/local, then run dpkg-reconfigure locales as root. Your Wesnoth language selector should now work.<br />
<br />
=== Fedora ===<br />
Battle for Wesnoth is included in [http://fedoraproject.org/ Fedora]. The current version of Battle for Wesnoth is available for ppc, i386, and x86_64 architectures. If you have problems with these packages, or other questions, please contact the Fedora maintainer [mailto:limb_AT_jcomserv.net Jon Ciesla].<br />
<br />
To install simply run:<br />
* <code>yum install wesnoth wesnoth-tools wesnoth-server</code><br />
<br />
=== Gentoo ===<br />
For the stable release just type:<br />
* <code>emerge wesnoth</code><br />
<br />
For the development release you will have to fetch an overlay, eg from this site:<br />
http://www.dorf.wh.uni-dortmund.de/priv/markus/wesnoth-dev.tbz<br />
extract it to your local overlay-directory and then type<br />
<code>emerge wesnoth-dev</code><br />
The ebuild will be updated whenever the person creating the ebuild finds the time to do so.<br />
<br />
Or if you're too impatient to wait and willing to take the risk of things blowing up, download<br />
and extract the overlay, make a copy of the highest available ebuild version, but change the version number to<br />
that of Wesnoth version you want (for instance, wesnoth-dev-1.3.2.ebuild might become <br />
wesnoth-dev-1.3.8.ebuild ), run <br />
<code>ebuild [new ebuild file] digest</code><br />
and then try to emerge. It may or may not work, depending on exactly how extensive the changes in the Wesnoth<br />
source are--going from 1.3.2 to 1.3.8 this way worked for me.<br />
There's an ebuild for 1.5.8 on Gentoo Bugzilla: http://bugs.gentoo.org/show_bug.cgi?id=256513<br />
<br />
For building from svn tree download the portage overlay from:<br />
http://www.dorf.wh.uni-dortmund.de/priv/markus/wesnoth-svn.tbz<br />
extract it to your local overlay-directory and then type<br />
<code>emerge wesnoth-svn</code><br />
<br />
wesnoth-dev are the official development releases<br />
while wesnoth-svn will build straight from SVN-source tree to keep you up to date with the lastest changes and all the errors ;-)<br />
updating wesnoth-svn will not work ! you have to reemerge it each time you want to update !<br />
<br />
=== KateOS ===<br />
Currently Battle for Wesnoth v1.4 is available in offcial KateOS repo (testing for now)<br />
[http://www.kateos.org/download/packages/testing3/]<br />
<br />
=== klik ===<br />
The most easy way to testdrive BfW is provided via [http://klik.atekon.de/ klik]. klik enables clients to create distribution-independent binaries which require no "installation" (the base system remains untouched); its created "AppDir" bundles run even from USB stick or CD RW. klik support is pre-enabled on Knoppix and Kanotix Live CDs. Other distros need to install a small klik client (less than 20 kByte download, less than 20 seconds effort). See the [http://klik.atekon.de/wiki/index.php/User%27s_FAQ klik FAQ] for details. A [http://wesnoth.klik.atekon.de/ BfW-specific klik website] has links to help with the package. Once the klik client is installed, look at this:<br />
* [http://wesnoth.klik.atekon.de/ Wesnoth-1.0] ancient stable Version: to "klik" it, type ''klik://wesnoth'' into your Browser<br />
* [http://wesnoth-latest.klik.atekon.de/ Wesnoth-1.1.1] ancient Development-Version: to "klik" it, type ''klik://wesnoth-latest'' into your Browser<br />
<br />
=== Mandrake (cooker) ===<br />
* <code>urpmi wesnoth</code><br />
* Binary: ftp://ftp.free.fr/pub/Distributions_Linux/Mandrakelinux/devel/cooker/i586/media/contrib/<br />
* Source: ftp://ftp.free.fr/pub/Distributions_Linux/Mandrakelinux/devel/cooker/contrib/SRPMS/<br />
<br />
=== Pardus ===<br />
* Run Package Manager, click Games section, select Wesnoth and click install.<br />
* If you prefer to install Wesnoth from command line type <code>pisi it wesnoth</code>.<br />
<br />
=== Slackware ===<br />
* Packages of Battle for Wesnoth for Slackware-current can be downloaded from [http://www.develia.org/tarballs.php?p=hobby develia.org]<br />
<br />
=== [[SuSE]] / [http://www.opensuse.org OpenSUSE] ===<br />
<br />
These are builds of The Battle For Wesnoth for several SUSE Linux distributions, made for both i386 and x86_64 architecture. On SUSE Linux 10.1 and above, as well as on SLED, just use the zen-updater and add these directories to your available services (as ZYPP). On 10.0 and older, you can use YaST to add the installation sources. <br />
<br />
If you have problems with these packages, or other questions, please contact [http://en.opensuse.org/User:Hhetter123 Holger Hetterich].<br />
<br />
<br />
* OpenSUSE 11 [http://software.opensuse.org/search?baseproject=openSUSE%3A11.0&p=1&q=wesnoth One-Click-Install]<br />
* OpenSUSE 10.3 [http://software.opensuse.org/search?p=1&baseproject=openSUSE%3A10.3&q=wesnoth One-Click-Install]<br />
* SUSE Linux 10.1 http://software.opensuse.org/download/games:/strategy:/turn-based/SUSE_Linux_10.1/<br />
* OpenSUSE Linux 10.2 http://software.opensuse.org/download/games:/strategy:/turn-based/openSUSE_10.2/<br />
* OpenSUSE Factory [http://software.opensuse.org/search?baseproject=openSUSE%3AFactory&p=1&q=wesnoth One-Click-Install]<br />
* SLED 10 (SUSE Linux Enterprise Desktop) requires an additional installation source including common required packages SLED is missing. First add http://software.opensuse.org/download/SUSE:/SLE-10:/SDK:/Extra/SLE_10/ , then add http://software.opensuse.org/download/games:/strategy:/turn-based/SLED10_SDK_Extras/ to your installation sources.<br />
<br />
=== Xandros Linux ===<br />
<br />
*This disto for wesnoth-1.1.1 works well with Xandros 3<br />
<br />
* A distribution-independent binary (made with [http://oblisk.codu.org/ OBLISK]) for any somewhat modern GNU/Linux on i386 is available: <br />
** http://prdownloads.sourceforge.net/suparun/wesnoth-1.1.1-x86-Opkg.tar.gz?download<br />
<br />
*Here is a disto for version .7 that works with Xandros<br />
** http://support.xandros.com/downloads/desktop_2.0/user_contrib/boylinux/binary-i386/wesnoth_0.7-1_i386.deb<br />
<br />
*Xandros 3 has the distro for wesnoth .9 available through Xandros Networks<br />
<br />
=== Yoper Linux ===<br />
All versions built for Yoper 2.2.0-6, although they should install on 2.1.<br />
Please let kernowyon know via the Yoper forums if you get any problems<br />
Latest 1.0.2 version<br />
* http://yoperstuff.kernowyon.org.uk/rpms/wesnoth-1.0.2-1.i686.rpm<br />
1.0.1 version<br />
* http://yoperstuff.kernowyon.org.uk/rpms/wesnoth-1.0-1.i686.rpm<br />
Earlier version<br />
*http://yoperstuff.kernowyon.org.uk/rpms/wesnoth-0.9.7-1.i686.rpm<br />
<br />
=== Binaries for all distributions ===<br />
* A distribution-independent binary (made with [http://oblisk.codu.org/ OBLISK]) for any somewhat modern GNU/Linux on i386 is available: <br />
** [http://prdownloads.sourceforge.net/suparun/wesnoth-1.1.1-x86-Opkg.tar.gz?download wesnoth-1.1.1-x86-Opkg.tar.gz]<br />
** [http://prdownloads.sourceforge.net/suparun/wesnoth-1.0.1-x86-Opkg.tar.gz?download wesnoth-1.0.1-x86-Opkg.tar.gz] <br />
** This is NOT a static binary distribution, it resolves dependencies at runtime.<br />
* Wesnoth 0.8.8 static binary (by Yann): http://prdownloads.sourceforge.net/wesnoth/wesnoth-i386-static?download (needs the [http://prdownloads.sourceforge.net/wesnoth/wesnoth-0.8.tar.gz?download source tarball] for the data - run it with the path to the unpacked data as argument)<br />
<br />
=== Other ===<br />
* [http://rpmfind.net/linux/rpm2html/search.php?query=wesnoth Search RPMs]<br />
<br />
= See Also =<br />
* [[CompilingWesnoth]]<br />
* [[Download]]<br />
<br />
[[Category:Building and Installing]]</div>Loonycyborghttps://wiki.wesnoth.org/index.php?title=RussianTranslation&diff=28008RussianTranslation2009-01-17T16:36:24Z<p>Loonycyborg: </p>
<hr />
<div>Координатор перевода (Translation maintainer):<br />
* Victor Sergienko (singalen) mailto:singalenАТgmailDОTcom<br />
<br />
Текущие переводчики (Current translators):<br />
<br />
* Victor Zabavin (vicza) mailto:viczaATzmailDOTru<br />
* Azamat H. Hackimov ([[User:Winterheart|Winterheart]]) mailto:azamatDOThackimovATgmailDOTcom<br />
* Ilya Kasnacheev (Ilyak) mailto:ilya.kasnacheev@gmail.com<br />
* Kotov Ilya ([[User:Maddiez|Maddiez]]) mailto:kotov_ilyaATmailDOTru<br />
* Anthony Kolesov ([[User:Kaagle|Kaagle]]) mailto:anthony.kolesovATgmailDOTcom<br />
* Sergey Popov (loonycyborg) mailto:loonycyborgATgmailDOTcom<br />
<br />
Благодарим за помощь (Inactive translators):<br />
<br />
* Alexandr Menovchicov (VaM) mailto:vamATkypiDOTru (first maintainer)<br />
* Denis Revin (Dut_Norshi) mailto:denis.revin@gmail.com<br />
<br />
<br />
== Текущее состояние переводов (версия 1.4) ==<br />
<br />
{|border=1<br />
! Название<br />
! Файл<br />
! Состояние<br />
! Последнее изменение<br />
! Поддерживает<br />
|-<br />
|Интерфейс || wesnoth || переведён, поддерживается || 27.04.2008 || vicza<br />
|-<br />
|Интерфейс || wesnoth-lib || переведён, поддерживается || 14.03.2008 || vicza<br />
|-<br />
|Редактор || wesnoth-editor || ''переведен, нуждается в проверке'' || ? || свободен<br />
|-<br />
|Отряды || wesnoth-units || переведён, требует доработки || 27.04.2008 || vicza<br />
|-<br />
|Сетевая || wesnoth-multiplayer|| ''переведён (не полностью)'' || 14.03.2008 || свободен<br />
|-<br />
|Обучение || wesnoth-tutorial || переведён, поддерживается || 10.03.2008 || vicza<br />
|-<br />
|Наследник трона || wesnoth-httt || переведён, поддерживается || 13.04.2008 || vicza<br />
|-<br />
|Падение в темноту || wesnoth-did || переведён, поддерживается || 16.04.2008 || kaagle<br />
|-<br />
|Вторжение с востока || wesnoth-ei || нуждается в правке || ? || свободен<br />
|-<br />
|Огненный скипетр || wesnoth-sof || переводится ок. 50% || ? || kaagle<br />
|-<br />
|Зарождение Веснота || wesnoth-trow || переводится || ? || cheer<br />
|-<br />
|Легенда о двух братьях || wesnoth-tb || переведено || 13.04.2008 || свободен<br />
|-<br />
|Южная гвардия || wesnoth-tsg || переведён || 12.08.2008 || el-shep<br />
|-<br />
|Под палящими светилами || wesnoth-utbs || переведено ок. 50% || ? || el-shep <br />
|-<br />
|Оркский набег || wesnoth-aoi || переведён, поддерживается || 27.04.2008 || vicza<br />
|-<br />
|Свобода || wesnoth-l || переведён || 27.04.2008 || vicza<br />
|-<br />
|Северное возрождение || wesnoth-nr || не переведено || - || свободен<br />
|-<br />
|Сын Чёрного Глаза || wesnoth-sotbe || переведено ок. 50% || ? || ?<br />
|-<br />
|Молот Турсагана || wesnoth-thot || переведено, поддерживается || 13.04.2008 || cheer<br />
|-<br />
|Руководство || wesnoth-manual || переведено || 05.04.2008 || свободен<br />
|-<br />
|Страницы man || wesnoth-manpages || переведено ок. 50% || ? || ?<br />
|}<br />
<br />
== Текущее состояние переводов (версия 1.5) ==<br />
<br />
{|border=1<br />
! Название<br />
! Файл<br />
! Состояние<br />
! Последнее изменение<br />
! Поддерживает<br />
|-<br />
|Интерфейс || wesnoth || переведено 80% || 27.04.2008 || ?<br />
|-<br />
|Интерфейс || wesnoth-lib || переведено 63% || 14.03.2008 || ?<br />
|-<br />
|Страницы man || wesnoth-manpages || переведено 41% || ? || ?<br />
|-<br />
|Руководство || wesnoth-manual || переведено 87% || 05.04.2008 || свободен<br />
|-<br />
|Редактор || wesnoth-editor || переведено 32% || ? || свободен<br />
|-<br />
|Отряды || wesnoth-units || переведено 94%, требует переработки || 27.04.2008 || ?<br />
|-<br />
|Сетевая || wesnoth-multiplayer|| переведено 81% || 14.03.2008 || ?<br />
|-<br />
|Обучение || wesnoth-tutorial || переведено, требует правки || 10.03.2008 || ?<br />
|-<br />
|Оркский набег || wesnoth-aoi || переводится || 27.04.2008 || teddy<br />
|-<br />
|Падение в темноту || wesnoth-did || переведено 94% || 16.04.2008 || ?<br />
|-<br />
|Вторжение с востока || wesnoth-ei || переведено 76% || ? || свободен<br />
|-<br />
|Наследник трона || wesnoth-httt || переведено 94% || 13.04.2008 || ?<br />
|-<br />
|Свобода || wesnoth-l || переведено 95% || 27.04.2008 || ?<br />
|-<br />
|Легенда Весмира || wesnoth-low || переведено || 16.01.2009 || teddy<br />
|-<br />
|Северное возрождение || wesnoth-nr || не переведено || - || свободен<br />
|-<br />
|Сын Чёрного Глаза || wesnoth-sotbe || переведено 32% || ? || ?<br />
|-<br />
|Огненный скипетр || wesnoth-sof || переведено 95% || ? || ?<br />
|-<br />
|Легенда о двух братьях || wesnoth-tb || переведено 62% || 13.04.2008 || ?<br />
|-<br />
|Молот Турсагана || wesnoth-thot || переведено 67% || 13.04.2008 || ?<br />
|-<br />
|Зарождение Веснота || wesnoth-trow || переведено 88% || ? || ?<br />
|-<br />
|Южная гвардия || wesnoth-tsg || переведено 89% || 12.08.2008 || ?<br />
|-<br />
|Под палящими светилами || wesnoth-utbs || переведено 47% || ? || ? <br />
|}<br />
<br />
'''Примечания'''.<br />
# Дата последнего изменения -- это дата, когда файл был отправлен разработчикам. Обычно довольно быстро он появляется на SVN. В составе же игры он появится, естественно, лишь с выходом новой подверсии. Если вы не хотите ждать, вы всегда можете скачать последний .po файл с SVN, скомпилировать на его основе .mo (например, с помощью редактора Poedit) и поместить его у себя в директорию \po\ru\LC_MESSAGES.<br />
# Если какой-то файл свободен, нуждается в правке/переводе и вы хотели бы над ним поработать, весьма желательно, чтобы вы добавили своё имя в соотв. колонку. Чтобы не получилось, что два человека будут работать над одним файлом. Для работы следует брать последнюю версию файла из SVN. Аналогично, если вы не хотите/не можете больше поддерживать файл, желательно убрать своё имя из таблицы, чтобы люди видели, что файл свободен.<br />
<br />
== См. также ==<br />
<br />
* [[RussianTranslationDictionary|Словарь имён и названий]]<br />
* [[RussianListOfUnits|Словарь родов войск]]<br />
* [[RussianGlossary|Глоссарий русского перевода]]<br />
* [[GettextForTranslators|Как работать с po-файлами (англ.)]]<br />
* [[CampaignBurningSuns:RussianTranslation]]<br />
* [[CampaignANewOrder:RussianTranslation]]<br />
* [http://www.wesnoth.org/forum/viewtopic.php?t=964 Ветка в форуме, посвященная русскому переводу]<br />
* [http://gettext.wesnoth.org/index.lang.php?lang=ru&version=trunk Статистика перевода для русского языка]<br />
<br />
[[Category:Translations]]</div>Loonycyborghttps://wiki.wesnoth.org/index.php?title=RussianTranslation&diff=28007RussianTranslation2009-01-17T16:35:12Z<p>Loonycyborg: </p>
<hr />
<div>Координатор перевода:<br />
* Victor Sergienko (singalen) mailto:singalenАТgmailDОTcom<br />
<br />
Текущие переводчики (Current translators):<br />
<br />
* Victor Zabavin (vicza) mailto:viczaATzmailDOTru<br />
* Azamat H. Hackimov ([[User:Winterheart|Winterheart]]) mailto:azamatDOThackimovATgmailDOTcom<br />
* Ilya Kasnacheev (Ilyak) mailto:ilya.kasnacheev@gmail.com<br />
* Kotov Ilya ([[User:Maddiez|Maddiez]]) mailto:kotov_ilyaATmailDOTru<br />
* Anthony Kolesov ([[User:Kaagle|Kaagle]]) mailto:anthony.kolesovATgmailDOTcom<br />
* Sergey Popov (loonycyborg) mailto:loonycyborgATgmailDOTcom<br />
<br />
Благодарим за помощь (Inactive translators):<br />
<br />
* Alexandr Menovchicov (VaM) mailto:vamATkypiDOTru (first maintainer)<br />
* Denis Revin (Dut_Norshi) mailto:denis.revin@gmail.com<br />
<br />
<br />
== Текущее состояние переводов (версия 1.4) ==<br />
<br />
{|border=1<br />
! Название<br />
! Файл<br />
! Состояние<br />
! Последнее изменение<br />
! Поддерживает<br />
|-<br />
|Интерфейс || wesnoth || переведён, поддерживается || 27.04.2008 || vicza<br />
|-<br />
|Интерфейс || wesnoth-lib || переведён, поддерживается || 14.03.2008 || vicza<br />
|-<br />
|Редактор || wesnoth-editor || ''переведен, нуждается в проверке'' || ? || свободен<br />
|-<br />
|Отряды || wesnoth-units || переведён, требует доработки || 27.04.2008 || vicza<br />
|-<br />
|Сетевая || wesnoth-multiplayer|| ''переведён (не полностью)'' || 14.03.2008 || свободен<br />
|-<br />
|Обучение || wesnoth-tutorial || переведён, поддерживается || 10.03.2008 || vicza<br />
|-<br />
|Наследник трона || wesnoth-httt || переведён, поддерживается || 13.04.2008 || vicza<br />
|-<br />
|Падение в темноту || wesnoth-did || переведён, поддерживается || 16.04.2008 || kaagle<br />
|-<br />
|Вторжение с востока || wesnoth-ei || нуждается в правке || ? || свободен<br />
|-<br />
|Огненный скипетр || wesnoth-sof || переводится ок. 50% || ? || kaagle<br />
|-<br />
|Зарождение Веснота || wesnoth-trow || переводится || ? || cheer<br />
|-<br />
|Легенда о двух братьях || wesnoth-tb || переведено || 13.04.2008 || свободен<br />
|-<br />
|Южная гвардия || wesnoth-tsg || переведён || 12.08.2008 || el-shep<br />
|-<br />
|Под палящими светилами || wesnoth-utbs || переведено ок. 50% || ? || el-shep <br />
|-<br />
|Оркский набег || wesnoth-aoi || переведён, поддерживается || 27.04.2008 || vicza<br />
|-<br />
|Свобода || wesnoth-l || переведён || 27.04.2008 || vicza<br />
|-<br />
|Северное возрождение || wesnoth-nr || не переведено || - || свободен<br />
|-<br />
|Сын Чёрного Глаза || wesnoth-sotbe || переведено ок. 50% || ? || ?<br />
|-<br />
|Молот Турсагана || wesnoth-thot || переведено, поддерживается || 13.04.2008 || cheer<br />
|-<br />
|Руководство || wesnoth-manual || переведено || 05.04.2008 || свободен<br />
|-<br />
|Страницы man || wesnoth-manpages || переведено ок. 50% || ? || ?<br />
|}<br />
<br />
== Текущее состояние переводов (версия 1.5) ==<br />
<br />
{|border=1<br />
! Название<br />
! Файл<br />
! Состояние<br />
! Последнее изменение<br />
! Поддерживает<br />
|-<br />
|Интерфейс || wesnoth || переведено 80% || 27.04.2008 || ?<br />
|-<br />
|Интерфейс || wesnoth-lib || переведено 63% || 14.03.2008 || ?<br />
|-<br />
|Страницы man || wesnoth-manpages || переведено 41% || ? || ?<br />
|-<br />
|Руководство || wesnoth-manual || переведено 87% || 05.04.2008 || свободен<br />
|-<br />
|Редактор || wesnoth-editor || переведено 32% || ? || свободен<br />
|-<br />
|Отряды || wesnoth-units || переведено 94%, требует переработки || 27.04.2008 || ?<br />
|-<br />
|Сетевая || wesnoth-multiplayer|| переведено 81% || 14.03.2008 || ?<br />
|-<br />
|Обучение || wesnoth-tutorial || переведено, требует правки || 10.03.2008 || ?<br />
|-<br />
|Оркский набег || wesnoth-aoi || переводится || 27.04.2008 || teddy<br />
|-<br />
|Падение в темноту || wesnoth-did || переведено 94% || 16.04.2008 || ?<br />
|-<br />
|Вторжение с востока || wesnoth-ei || переведено 76% || ? || свободен<br />
|-<br />
|Наследник трона || wesnoth-httt || переведено 94% || 13.04.2008 || ?<br />
|-<br />
|Свобода || wesnoth-l || переведено 95% || 27.04.2008 || ?<br />
|-<br />
|Легенда Весмира || wesnoth-low || переведено || 16.01.2009 || teddy<br />
|-<br />
|Северное возрождение || wesnoth-nr || не переведено || - || свободен<br />
|-<br />
|Сын Чёрного Глаза || wesnoth-sotbe || переведено 32% || ? || ?<br />
|-<br />
|Огненный скипетр || wesnoth-sof || переведено 95% || ? || ?<br />
|-<br />
|Легенда о двух братьях || wesnoth-tb || переведено 62% || 13.04.2008 || ?<br />
|-<br />
|Молот Турсагана || wesnoth-thot || переведено 67% || 13.04.2008 || ?<br />
|-<br />
|Зарождение Веснота || wesnoth-trow || переведено 88% || ? || ?<br />
|-<br />
|Южная гвардия || wesnoth-tsg || переведено 89% || 12.08.2008 || ?<br />
|-<br />
|Под палящими светилами || wesnoth-utbs || переведено 47% || ? || ? <br />
|}<br />
<br />
'''Примечания'''.<br />
# Дата последнего изменения -- это дата, когда файл был отправлен разработчикам. Обычно довольно быстро он появляется на SVN. В составе же игры он появится, естественно, лишь с выходом новой подверсии. Если вы не хотите ждать, вы всегда можете скачать последний .po файл с SVN, скомпилировать на его основе .mo (например, с помощью редактора Poedit) и поместить его у себя в директорию \po\ru\LC_MESSAGES.<br />
# Если какой-то файл свободен, нуждается в правке/переводе и вы хотели бы над ним поработать, весьма желательно, чтобы вы добавили своё имя в соотв. колонку. Чтобы не получилось, что два человека будут работать над одним файлом. Для работы следует брать последнюю версию файла из SVN. Аналогично, если вы не хотите/не можете больше поддерживать файл, желательно убрать своё имя из таблицы, чтобы люди видели, что файл свободен.<br />
<br />
== См. также ==<br />
<br />
* [[RussianTranslationDictionary|Словарь имён и названий]]<br />
* [[RussianListOfUnits|Словарь родов войск]]<br />
* [[RussianGlossary|Глоссарий русского перевода]]<br />
* [[GettextForTranslators|Как работать с po-файлами (англ.)]]<br />
* [[CampaignBurningSuns:RussianTranslation]]<br />
* [[CampaignANewOrder:RussianTranslation]]<br />
* [http://www.wesnoth.org/forum/viewtopic.php?t=964 Ветка в форуме, посвященная русскому переводу]<br />
* [http://gettext.wesnoth.org/index.lang.php?lang=ru&version=trunk Статистика перевода для русского языка]<br />
<br />
[[Category:Translations]]</div>Loonycyborghttps://wiki.wesnoth.org/index.php?title=RussianTranslation&diff=27935RussianTranslation2009-01-12T18:43:34Z<p>Loonycyborg: </p>
<hr />
<div>Текущие переводчики (Current translators):<br />
<br />
* Victor Zabavin (vicza) mailto:viczaATzmailDOTru<br />
* Azamat H. Hackimov ([[User:Winterheart|Winterheart]]) mailto:azamatDOThackimovATgmailDOTcom<br />
* Ilya Kasnacheev (Ilyak) mailto:ilya.kasnacheev@gmail.com<br />
* Kotov Ilya ([[User:Maddiez|Maddiez]]) mailto:kotov_ilyaATmailDOTru<br />
* Anthony Kolesov ([[User:Kaagle|Kaagle]]) mailto:anthony.kolesovATgmailDOTcom<br />
* Sergey Popov (loonycyborg) mailto:loonycyborgATgmailDOTcom<br />
<br />
Благодарим за помощь (Inactive translators):<br />
<br />
* Alexandr Menovchicov (VaM) mailto:vamATkypiDOTru (first maintainer)<br />
* Denis Revin (Dut_Norshi) mailto:denis.revin@gmail.com<br />
<br />
<br />
== Текущее состояние переводов (версия 1.4) ==<br />
<br />
{|border=1<br />
! Название<br />
! Файл<br />
! Состояние<br />
! Последнее изменение<br />
! Поддерживает<br />
|-<br />
|Интерфейс || wesnoth || переведён, поддерживается || 27.04.2008 || vicza<br />
|-<br />
|Интерфейс || wesnoth-lib || переведён, поддерживается || 14.03.2008 || vicza<br />
|-<br />
|Редактор || wesnoth-editor || ''переведен, нуждается в проверке'' || ? || свободен<br />
|-<br />
|Отряды || wesnoth-units || переведён, требует доработки || 27.04.2008 || vicza<br />
|-<br />
|Сетевая || wesnoth-multiplayer|| ''переведён (не полностью)'' || 14.03.2008 || свободен<br />
|-<br />
|Обучение || wesnoth-tutorial || переведён, поддерживается || 10.03.2008 || vicza<br />
|-<br />
|Наследник трона || wesnoth-httt || переведён, поддерживается || 13.04.2008 || vicza<br />
|-<br />
|Падение в темноту || wesnoth-did || переведён, поддерживается || 16.04.2008 || kaagle<br />
|-<br />
|Вторжение с востока || wesnoth-ei || нуждается в правке || ? || свободен<br />
|-<br />
|Огненный скипетр || wesnoth-sof || переводится ок. 50% || ? || kaagle<br />
|-<br />
|Зарождение Веснота || wesnoth-trow || переводится || ? || cheer<br />
|-<br />
|Легенда о двух братьях || wesnoth-tb || переведено || 13.04.2008 || свободен<br />
|-<br />
|Южная гвардия || wesnoth-tsg || переведён || 12.08.2008 || el-shep<br />
|-<br />
|Под палящими светилами || wesnoth-utbs || переведено ок. 50% || ? || el-shep <br />
|-<br />
|Оркский набег || wesnoth-aoi || переведён, поддерживается || 27.04.2008 || vicza<br />
|-<br />
|Свобода || wesnoth-l || переведён || 27.04.2008 || vicza<br />
|-<br />
|Северное возрождение || wesnoth-nr || не переведено || - || свободен<br />
|-<br />
|Сын Чёрного Глаза || wesnoth-sotbe || переведено ок. 50% || ? || ?<br />
|-<br />
|Молот Турсагана || wesnoth-thot || переведено, поддерживается || 13.04.2008 || cheer<br />
|-<br />
|Руководство || wesnoth-manual || переведено || 05.04.2008 || свободен<br />
|-<br />
|Страницы man || wesnoth-manpages || переведено ок. 50% || ? || ?<br />
|}<br />
<br />
'''Примечания'''.<br />
# Дата последнего изменения -- это дата, когда файл был отправлен разработчикам. Обычно довольно быстро он появляется на SVN. В составе же игры он появится, естественно, лишь с выходом новой подверсии. Если вы не хотите ждать, вы всегда можете скачать последний .po файл с SVN, скомпилировать на его основе .mo (например, с помощью редактора Poedit) и поместить его у себя в директорию \po\ru\LC_MESSAGES.<br />
# Если какой-то файл свободен, нуждается в правке/переводе и вы хотели бы над ним поработать, весьма желательно, чтобы вы добавили своё имя в соотв. колонку. Чтобы не получилось, что два человека будут работать над одним файлом. Для работы следует брать последнюю версию файла из SVN. Аналогично, если вы не хотите/не можете больше поддерживать файл, желательно убрать своё имя из таблицы, чтобы люди видели, что файл свободен.<br />
<br />
== См. также ==<br />
<br />
* [[RussianTranslationDictionary|Словарь имён и названий]]<br />
* [[RussianListOfUnits|Словарь отрядов]]<br />
* [[GettextForTranslators|Как работать с po-файлами (англ.)]]<br />
* [[CampaignBurningSuns:RussianTranslation]]<br />
* [[CampaignANewOrder:RussianTranslation]]<br />
* [http://www.wesnoth.org/forum/viewtopic.php?t=964 Ветка в форуме, посвященная русскому переводу]<br />
* [http://gettext.wesnoth.org/index.lang.php?lang=ru&version=trunk Статистика перевода для русского языка]<br />
<br />
[[Category:Translations]]</div>Loonycyborghttps://wiki.wesnoth.org/index.php?title=Download&diff=26737Download2008-09-17T17:34:35Z<p>Loonycyborg: /* MS Windows */</p>
<hr />
<div>Welcome to the Battle for Wesnoth downloads page. The BFW project team only officially releases the source code. Binary packages are only provided by community volunteers and hosted here. Torrents are also unofficial.<br />
<br />
If the latest binaries are not currently available for your OS, please check back in a few days to see if they have been placed here. Packagers have been informed of the release, please be patient. In the meantime, read the [[FAQ#A_new_version_is_out.2C_but_where_is_the_download_for_.5BWindows.2C_Mac_OS.2C_etc..5D.3F|FAQ]].<br />
<br />
__NOTOC__<br />
Jump to: [[Download#Stable_.281.4_branch.29|Stable Branch]] | [[Download#Development_.281.5_branch.29|Development Branch]]<br />
<br />
== Stable (1.4 branch) ==<br />
<br />
The stable files are meant to be used as a stable and rather balanced version of the game. Each version of the 1.4 branch is compatible to each other. This will not happen in the development branch.<br />
<br />
Version 1.4 is the latest stable version, updated with several important bugfixes. This version is recommended for most players since the 1.4 online multiplayer community is very large and user-made campaign server has a robust content selection.<br />
<br />
==== Source code ====<br />
* [http://downloads.sourceforge.net/wesnoth/wesnoth-1.4.5.tar.bz2?download Current Version] (1.4.5, 146.9 MB)<br />
* [http://downloads.sourceforge.net/wesnoth/wesnoth-1.4.4.tar.bz2?download Previous Version] (1.4.4, 145.4 MB)<br />
* [[CompilingWesnoth|Compiling Guide]] - how to compile the source code<br />
<br />
==== MS Windows ====<br />
* [http://downloads.sourceforge.net/wesnoth/wesnoth-1.4.5-r3-windows.exe?download Current version] (1.4.5, 135.4 MB)<br />
* [http://downloads.sourceforge.net/wesnoth/wesnoth-1.4.4-win32.exe?download Previous version] (1.4.4, 132.8 MB)<br />
<br />
==== Mac OS X ====<br />
* [http://downloads.sourceforge.net/wesnoth/Battle_for_Wesnoth_1.4.5_UB.dmg?download Current Version (Full)] (1.4.5, Universal, 173.2 MB)<br />
* [http://downloads.sourceforge.net/wesnoth/Battle_for_Wesnoth_1.4.4b_UB.dmg?download Previous Version (Full)] (1.4.4b, Universal, 172.2 MB)<br />
<br />
==== GNU/Linux ====<br />
* There are binaries for many different GNU/Linux Distributions. Not all are always up to date with the current release. Please have a look at the [[WesnothBinariesLinux|Linux binary page]] for more information about the binaries for your Distribution.<br />
<br />
==== (Open)Solaris ====<br />
* [http://downloads.sourceforge.net/wesnoth/wesnoth-solaris-i386-1.4.5.pkg.bz2?download Current Version] (1.4.4, 145.6 MB)<br />
* [http://downloads.sourceforge.net/wesnoth/wesnoth-1.4.4.solaris.i386.pkg.bz2?download Previous Version] (1.4.4, 129.1 MB)<br />
<br />
==== OS/2 & eComStation ====<br />
* The current version (1.4.5) is not available yet.<br />
* [http://download.smedley.info/wesnoth-1.4.2-os2-20080515.zip Older version] (1.4.2, 200 MB)<br />
<br />
==== Miscellaneous ====<br />
* [http://downloads.sourceforge.net/wesnoth/wesnoth-1.4.4.tar.bz2.md5?download md5sum for current source code]<br />
* [http://www.wesnoth.org/wiki/Download_Xdeltas#Source_code Xdelta for the source code]<br />
* [http://sourceforge.net/project/showfiles.php?group_id=89495 SourceForge page for current and all previous versions]<br />
<br />
== Development (1.5 branch) ==<br />
<br />
Version 1.5.x is the latest development version, boasting updated graphics and new exciting features. However, there may be occasional bugs or performance problems in the development versions since heavy changes are taking place all the time. For balanced and stable gaming, it is recommended you use the latest version of the 1.4.x branch. This version is recommended for coders and campaign developers that want to use all of the latest possibilities, as well as those who want to preview the future of Wesnoth.<br />
<br />
==== Source code ====<br />
* [http://downloads.sourceforge.net/wesnoth/wesnoth-1.5.4.tar.bz2?download Current Version] (1.5.4, 157.4 MB)<br />
* [http://downloads.sourceforge.net/wesnoth/wesnoth-1.5.3.tar.bz2?download Previous Version] (1.5.3, 149.6 MB)<br />
<br />
* [[CompilingWesnoth|Compiling Guide]] - how to compile the source code<br />
<br />
==== MS Windows ====<br />
* [http://downloads.sourceforge.net/wesnoth/wesnoth-1.5.4-win32.exe?download Current Version] (1.5.4, 145.8 MB)<br />
* [http://downloads.sourceforge.net/wesnoth/wesnoth-1.5.3-windows.exe?download Previous Version] (1.5.3, 156.9 MB)<br />
<br />
==== Mac OS X ====<br />
* The current version (1.5.4) is not available yet.<br />
* [http://downloads.sourceforge.net/wesnoth/Battle_for_Wesnoth_1.5.3_UB.dmg?download Previous Version] (1.5.3, Universal, 175.4 MB).<br />
<br />
==== GNU/Linux ====<br />
* There are binaries for many different GNU/Linux Distributions. Not all are always up to date with the current release. Please have a look at the [[WesnothBinariesLinux|Linux binary page]] for more information about the binaries for your Distribution.<br />
<br />
==== (Open)Solaris ====<br />
* The current version (1.5.4) is not available yet.<br />
* [http://downloads.sourceforge.net/wesnoth/wesnoth-1.5.1.solaris.i386.pkg.bz2?download Older Version] (1.5.1, 130.4 MB)<br />
<br />
==== AmigaOS4 ====<br />
* The current version (1.5.4) is not available yet.<br />
* [http://os4depot.net/index.php?function=showfile&file=game/strategy/wesnoth-devel.lha Older Version] (1.3.12, 105.0 MB)<br />
<br />
==== OS/2 & eComStation ====<br />
* The current version (1.5.4) is not available yet.<br />
* [http://download.smedley.info/wesnoth-1.1.8-os2.zip Older Version] (1.1.8, 66 MB)<br />
<br />
==== Syllable ====<br />
* The current version (1.5.4) is not available yet.<br />
* [http://www.syllable-software.info/download.php?view.32 Older Version] (1.3.8, 82.2 MB)<br />
<br />
==== Miscellaneous ====<br />
* [http://downloads.sourceforge.net/wesnoth/wesnoth-1.5.3.tar.bz2.md5?download md5sum for current source code]<br />
* [http://www.wesnoth.org/wiki/Download_Xdeltas#Source_code Xdelta for the source code]<br />
* [http://sourceforge.net/project/showfiles.php?group_id=89495 SourceForge page for current and all previous versions]<br />
* [http://downloads.sourceforge.net/wesnoth/Mac_Compile_Stuff_1.5.3.tar.bz2? MacCompileStuff for 1.5.3]<br />
<br />
== License ==<br />
''Main article: [[Wesnoth:Copyrights]]<br />
<br />
This program is free software; you can redistribute it and/or modify it under the terms of the [http://www.fsf.org/copyleft/gpl.html GNU General Public License version 2], as published by the [http://www.fsf.org/ Free Software Foundation].<br />
This program is distributed in the hope that it will be useful, but without any warranty; without even the implied warranty of merchantability or fitness for a particular purpose. See the GNU General Public License for more details.<br />
<br />
== See also ==<br />
* [http://changelog.wesnoth.org Changelog]<br />
* [http://www.diggygames.com Free Games]<br />
* [[WesnothBinaries| More binaries]]<br />
* [[WesnothSVN]] - bleeding edge version from SVN<br />
<br />
[[Category:Building and Installing]]</div>Loonycyborghttps://wiki.wesnoth.org/index.php?title=Download&diff=26691Download2008-09-11T20:23:08Z<p>Loonycyborg: /* MS Windows */</p>
<hr />
<div>Welcome to the Battle for Wesnoth downloads page. The BFW project team only officially releases the source code. Binary packages are only provided by community volunteers and hosted here. Torrents are also unofficial.<br />
<br />
If the latest binaries are not currently available for your OS, please check back in a few days to see if they have been placed here. Packagers have been informed of the release, please be patient. In the meantime, read the [[FAQ#A_new_version_is_out.2C_but_where_is_the_download_for_.5BWindows.2C_Mac_OS.2C_etc..5D.3F|FAQ]].<br />
<br />
__NOTOC__<br />
Jump to: [[Download#Stable_.281.4_branch.29|Stable Branch]] | [[Download#Development_.281.5_branch.29|Development Branch]]<br />
<br />
== Stable (1.4 branch) ==<br />
<br />
The stable files are meant to be used as a stable and rather balanced version of the game. Each version of the 1.4 branch is compatible to each other. This will not happen in the development branch.<br />
<br />
Version 1.4 is the latest stable version, updated with several important bugfixes. This version is recommended for most players since the 1.4 online multiplayer community is very large and user-made campaign server has a robust content selection.<br />
<br />
==== Source code ====<br />
* [http://downloads.sourceforge.net/wesnoth/wesnoth-1.4.5.tar.bz2?download Current Version] (1.4.5, 146.9 MB)<br />
* [http://downloads.sourceforge.net/wesnoth/wesnoth-1.4.4.tar.bz2?download Previous Version] (1.4.4, 145.4 MB)<br />
* [[CompilingWesnoth|Compiling Guide]] - how to compile the source code<br />
<br />
==== MS Windows ====<br />
* [http://downloads.sourceforge.net/wesnoth/wesnoth-1.4.5-r1-windows.exe?download Current version] (1.4.5, 145.7 MB)<br />
* [http://downloads.sourceforge.net/wesnoth/wesnoth-1.4.4-win32.exe?download Previous version] (1.4.4, 132.8 MB)<br />
<br />
==== Mac OS X ====<br />
* [http://downloads.sourceforge.net/wesnoth/Battle_for_Wesnoth_1.4.5_UB.dmg?download Current Version (Full)] (1.4.5, Universal, 173.2 MB)<br />
* [http://downloads.sourceforge.net/wesnoth/Battle_for_Wesnoth_1.4.4b_UB.dmg?download Previous Version (Full)] (1.4.4b, Universal, 172.2 MB)<br />
<br />
==== GNU/Linux ====<br />
* There are binaries for many different GNU/Linux Distributions. Not all are always up to date with the current release. Please have a look at the [[WesnothBinariesLinux|Linux binary page]] for more information about the binaries for your Distribution.<br />
<br />
==== (Open)Solaris ====<br />
* [http://downloads.sourceforge.net/wesnoth/wesnoth-solaris-i386-1.4.5.pkg.bz2?download Current Version] (1.4.4, 145.6 MB)<br />
* [http://downloads.sourceforge.net/wesnoth/wesnoth-1.4.4.solaris.i386.pkg.bz2?download Previous Version] (1.4.4, 129.1 MB)<br />
<br />
==== OS/2 & eComStation ====<br />
* The current version (1.4.5) is not available yet.<br />
* [http://download.smedley.info/wesnoth-1.4.2-os2-20080515.zip Older version] (1.4.2, 200 MB)<br />
<br />
==== Miscellaneous ====<br />
* [http://downloads.sourceforge.net/wesnoth/wesnoth-1.4.4.tar.bz2.md5?download md5sum for current source code]<br />
* [http://www.wesnoth.org/wiki/Download_Xdeltas#Source_code Xdelta for the source code]<br />
* [http://sourceforge.net/project/showfiles.php?group_id=89495 SourceForge page for current and all previous versions]<br />
<br />
== Development (1.5 branch) ==<br />
<br />
Version 1.5.x is the latest development version, boasting updated graphics and new exciting features. However, there may be occasional bugs or performance problems in the development versions since heavy changes are taking place all the time. For balanced and stable gaming, it is recommended you use the latest version of the 1.4.x branch. This version is recommended for coders and campaign developers that want to use all of the latest possibilities, as well as those who want to preview the future of Wesnoth.<br />
<br />
==== Source code ====<br />
* [http://downloads.sourceforge.net/wesnoth/wesnoth-1.5.4.tar.bz2?download Current Version] (1.5.4, 157.4 MB)<br />
* [http://downloads.sourceforge.net/wesnoth/wesnoth-1.5.3.tar.bz2?download Previous Version] (1.5.3, 149.6 MB)<br />
<br />
* [[CompilingWesnoth|Compiling Guide]] - how to compile the source code<br />
<br />
==== MS Windows ====<br />
* [http://downloads.sourceforge.net/wesnoth/wesnoth-1.5.4-win32.exe?download Current Version] (1.5.4, 145.8 MB)<br />
* [http://downloads.sourceforge.net/wesnoth/wesnoth-1.5.3-windows.exe?download Previous Version] (1.5.3, 156.9 MB)<br />
<br />
==== Mac OS X ====<br />
* The current version (1.5.4) is not available yet.<br />
* [http://downloads.sourceforge.net/wesnoth/Battle_for_Wesnoth_1.5.3_UB.dmg?download Previous Version] (1.5.3, Universal, 175.4 MB).<br />
<br />
==== GNU/Linux ====<br />
* There are binaries for many different GNU/Linux Distributions. Not all are always up to date with the current release. Please have a look at the [[WesnothBinariesLinux|Linux binary page]] for more information about the binaries for your Distribution.<br />
<br />
==== (Open)Solaris ====<br />
* The current version (1.5.4) is not available yet.<br />
* [http://downloads.sourceforge.net/wesnoth/wesnoth-1.5.1.solaris.i386.pkg.bz2?download Older Version] (1.5.1, 130.4 MB)<br />
<br />
==== AmigaOS4 ====<br />
* The current version (1.5.4) is not available yet.<br />
* [http://os4depot.net/index.php?function=showfile&file=game/strategy/wesnoth-devel.lha Older Version] (1.3.12, 105.0 MB)<br />
<br />
==== OS/2 & eComStation ====<br />
* The current version (1.5.4) is not available yet.<br />
* [http://download.smedley.info/wesnoth-1.1.8-os2.zip Older Version] (1.1.8, 66 MB)<br />
<br />
==== Syllable ====<br />
* The current version (1.5.4) is not available yet.<br />
* [http://www.syllable-software.info/download.php?view.32 Older Version] (1.3.8, 82.2 MB)<br />
<br />
==== Miscellaneous ====<br />
* [http://downloads.sourceforge.net/wesnoth/wesnoth-1.5.3.tar.bz2.md5?download md5sum for current source code]<br />
* [http://www.wesnoth.org/wiki/Download_Xdeltas#Source_code Xdelta for the source code]<br />
* [http://sourceforge.net/project/showfiles.php?group_id=89495 SourceForge page for current and all previous versions]<br />
* [http://downloads.sourceforge.net/wesnoth/Mac_Compile_Stuff_1.5.3.tar.bz2? MacCompileStuff for 1.5.3]<br />
<br />
== License ==<br />
''Main article: [[Wesnoth:Copyrights]]<br />
<br />
This program is free software; you can redistribute it and/or modify it under the terms of the [http://www.fsf.org/copyleft/gpl.html GNU General Public License version 2], as published by the [http://www.fsf.org/ Free Software Foundation].<br />
This program is distributed in the hope that it will be useful, but without any warranty; without even the implied warranty of merchantability or fitness for a particular purpose. See the GNU General Public License for more details.<br />
<br />
== See also ==<br />
* [http://changelog.wesnoth.org Changelog]<br />
* [[WesnothBinaries| More binaries]]<br />
* [[WesnothSVN]] - bleeding edge version from SVN<br />
<br />
[[Category:Building and Installing]]</div>Loonycyborghttps://wiki.wesnoth.org/index.php?title=Download&diff=26677Download2008-09-10T14:35:36Z<p>Loonycyborg: /* MS Windows */</p>
<hr />
<div>Welcome to the Battle for Wesnoth downloads page. The BFW project team only officially releases the source code. Binary packages are only provided by community volunteers and hosted here. Torrents are also unofficial.<br />
<br />
If the latest binaries are not currently available for your OS, please check back in a few days to see if they have been placed here. Packagers have been informed of the release, please be patient. In the meantime, read the [[FAQ#A_new_version_is_out.2C_but_where_is_the_download_for_.5BWindows.2C_Mac_OS.2C_etc..5D.3F|FAQ]].<br />
<br />
__NOTOC__<br />
Jump to: [[Download#Stable_.281.4_branch.29|Stable Branch]] | [[Download#Development_.281.5_branch.29|Development Branch]]<br />
<br />
== Stable (1.4 branch) ==<br />
<br />
The stable files are meant to be used as a stable and rather balanced version of the game. Each version of the 1.4 branch is compatible to each other. This will not happen in the development branch.<br />
<br />
Version 1.4 is the latest stable version, updated with several important bugfixes. This version is recommended for most players since the 1.4 online multiplayer community is very large and user-made campaign server has a robust content selection.<br />
<br />
==== Source code ====<br />
* [http://downloads.sourceforge.net/wesnoth/wesnoth-1.4.5.tar.bz2?download Current Version] (1.4.5, 146.9 MB)<br />
* [http://downloads.sourceforge.net/wesnoth/wesnoth-1.4.4.tar.bz2?download Previous Version] (1.4.4, 145.4 MB)<br />
* [[CompilingWesnoth|Compiling Guide]] - how to compile the source code<br />
<br />
==== MS Windows ====<br />
* [http://downloads.sourceforge.net/wesnoth/wesnoth-1.4.5-r1-windows.exe?download Current version] (1.4.5, 145.7 MB)<br />
* [http://downloads.sourceforge.net/wesnoth/wesnoth-1.4.4-win32.exe?download Previous version] (1.4.4, 132.8 MB)<br />
<br />
==== Mac OS X ====<br />
* [http://downloads.sourceforge.net/wesnoth/Battle_for_Wesnoth_1.4.5_UB.dmg?download Current Version (Full)] (1.4.5, Universal, 173.2 MB)<br />
* [http://downloads.sourceforge.net/wesnoth/Battle_for_Wesnoth_1.4.4b_UB.dmg?download Previous Version (Full)] (1.4.4b, Universal, 172.2 MB)<br />
<br />
==== GNU/Linux ====<br />
* There are binaries for many different GNU/Linux Distributions. Not all are always up to date with the current release. Please have a look at the [[WesnothBinariesLinux|Linux binary page]] for more information about the binaries for your Distribution.<br />
<br />
==== (Open)Solaris ====<br />
* [http://downloads.sourceforge.net/wesnoth/wesnoth-solaris-i386-1.4.5.pkg.bz2?download Current Version] (1.4.4, 145.6 MB)<br />
* [http://downloads.sourceforge.net/wesnoth/wesnoth-1.4.4.solaris.i386.pkg.bz2?download Previous Version] (1.4.4, 129.1 MB)<br />
<br />
==== OS/2 & eComStation ====<br />
* The current version (1.4.5) is not available yet.<br />
* [http://download.smedley.info/wesnoth-1.4.2-os2-20080515.zip Older version] (1.4.2, 200 MB)<br />
<br />
==== Miscellaneous ====<br />
* [http://downloads.sourceforge.net/wesnoth/wesnoth-1.4.4.tar.bz2.md5?download md5sum for current source code]<br />
* [http://www.wesnoth.org/wiki/Download_Xdeltas#Source_code Xdelta for the source code]<br />
* [http://sourceforge.net/project/showfiles.php?group_id=89495 SourceForge page for current and all previous versions]<br />
<br />
== Development (1.5 branch) ==<br />
<br />
Version 1.5.x is the latest development version, boasting updated graphics and new exciting features. However, there may be occasional bugs or performance problems in the development versions since heavy changes are taking place all the time. For balanced and stable gaming, it is recommended you use the latest version of the 1.4.x branch. This version is recommended for coders and campaign developers that want to use all of the latest possibilities, as well as those who want to preview the future of Wesnoth.<br />
<br />
==== Source code ====<br />
* [http://downloads.sourceforge.net/wesnoth/wesnoth-1.5.3.tar.bz2?download Current Version] (1.5.3, 149.6 MB)<br />
* [http://downloads.sourceforge.net/wesnoth/wesnoth-1.5.2.tar.bz2?download Previous Version] (1.5.2, 148.7 MB)<br />
<br />
* [[CompilingWesnoth|Compiling Guide]] - how to compile the source code<br />
<br />
==== MS Windows ====<br />
* [http://downloads.sourceforge.net/wesnoth/wesnoth-1.5.3-windows.exe?download Current Version] (1.5.3, 156.9 MB)<br />
* [http://downloads.sourceforge.net/wesnoth/wesnoth-1.5.2-win32.exe?download Previous Version] (1.5.2, 136.0 MB)<br />
<br />
==== Mac OS X ====<br />
* [http://downloads.sourceforge.net/wesnoth/Battle_for_Wesnoth_1.5.3_UB.dmg?download Current Version] (1.5.3, Universal, 175.4 MB).<br />
* [http://downloads.sourceforge.net/wesnoth/Battle_for_Wesnoth_1.5.2b_UB.dmg?download Previous Version] (1.5.2, Universal, 179.3 MB)<br />
<br />
==== GNU/Linux ====<br />
* There are binaries for many different GNU/Linux Distributions. Not all are always up to date with the current release. Please have a look at the [[WesnothBinariesLinux|Linux binary page]] for more information about the binaries for your Distribution.<br />
<br />
==== (Open)Solaris ====<br />
* The current version (1.5.3) is not available yet.<br />
* [http://downloads.sourceforge.net/wesnoth/wesnoth-1.5.1.solaris.i386.pkg.bz2?download Older Version] (1.5.1, 130.4 MB)<br />
<br />
==== AmigaOS4 ====<br />
* The current version (1.5.3) is not available yet.<br />
* [http://os4depot.net/index.php?function=showfile&file=game/strategy/wesnoth-devel.lha Older Version] (1.3.12, 105.0 MB)<br />
<br />
==== OS/2 & eComStation ====<br />
* The current version (1.5.3) is not available yet.<br />
* [http://download.smedley.info/wesnoth-1.1.8-os2.zip Older Version] (1.1.8, 66 MB)<br />
<br />
==== Syllable ====<br />
* The current version (1.5.3) is not available yet.<br />
* [http://www.syllable-software.info/download.php?view.32 Older Version] (1.3.8, 82.2 MB)<br />
<br />
==== Miscellaneous ====<br />
* [http://downloads.sourceforge.net/wesnoth/wesnoth-1.5.3.tar.bz2.md5?download md5sum for current source code]<br />
* [http://www.wesnoth.org/wiki/Download_Xdeltas#Source_code Xdelta for the source code]<br />
* [http://sourceforge.net/project/showfiles.php?group_id=89495 SourceForge page for current and all previous versions]<br />
* [http://downloads.sourceforge.net/wesnoth/Mac_Compile_Stuff_1.5.3.tar.bz2? MacCompileStuff for 1.5.3]<br />
<br />
== License ==<br />
''Main article: [[Wesnoth:Copyrights]]<br />
<br />
This program is free software; you can redistribute it and/or modify it under the terms of the [http://www.fsf.org/copyleft/gpl.html GNU General Public License version 2], as published by the [http://www.fsf.org/ Free Software Foundation].<br />
This program is distributed in the hope that it will be useful, but without any warranty; without even the implied warranty of merchantability or fitness for a particular purpose. See the GNU General Public License for more details.<br />
<br />
== See also ==<br />
* [http://changelog.wesnoth.org Changelog]<br />
* [[WesnothBinaries| More binaries]]<br />
* [[WesnothSVN]] - bleeding edge version from SVN<br />
<br />
[[Category:Building and Installing]]</div>Loonycyborghttps://wiki.wesnoth.org/index.php?title=Download&diff=26650Download2008-09-09T16:46:08Z<p>Loonycyborg: /* MS Windows */</p>
<hr />
<div>Welcome to the Battle for Wesnoth downloads page. The BFW project team only officially releases the source code. Binary packages are only provided by community volunteers and hosted here. Torrents are also unofficial.<br />
<br />
If the latest binaries are not currently available for your OS, please check back in a few days to see if they have been placed here. Packagers have been informed of the release, please be patient. In the meantime, read the [[FAQ#A_new_version_is_out.2C_but_where_is_the_download_for_.5BWindows.2C_Mac_OS.2C_etc..5D.3F|FAQ]].<br />
<br />
__NOTOC__<br />
Jump to: [[Download#Stable_.281.4_branch.29|Stable Branch]] | [[Download#Development_.281.5_branch.29|Development Branch]]<br />
<br />
== Stable (1.4 branch) ==<br />
<br />
The stable files are meant to be used as a stable and rather balanced version of the game. Each version of the 1.4 branch is compatible to each other. This will not happen in the development branch.<br />
<br />
Version 1.4 is the latest stable version, updated with several important bugfixes. This version is recommended for most players since the 1.4 online multiplayer community is very large and user-made campaign server has a robust content selection.<br />
<br />
==== Source code ====<br />
* [http://downloads.sourceforge.net/wesnoth/wesnoth-1.4.5.tar.bz2?download Current Version] (1.4.5, 146.9 MB)<br />
* [http://downloads.sourceforge.net/wesnoth/wesnoth-1.4.4.tar.bz2?download Previous Version] (1.4.4, 145.4 MB)<br />
* [[CompilingWesnoth|Compiling Guide]] - how to compile the source code<br />
<br />
==== MS Windows ====<br />
* [http://downloads.sourceforge.net/wesnoth/wesnoth-1.4.5-windows.exe?download Current version] (1.4.5, 145.6 MB)<br />
* [http://downloads.sourceforge.net/wesnoth/wesnoth-1.4.4-win32.exe?download Previous version] (1.4.4, 132.8 MB)<br />
<br />
==== Mac OS X ====<br />
* [http://downloads.sourceforge.net/wesnoth/Battle_for_Wesnoth_1.4.5_UB.dmg?download Current Version (Full)] (1.4.5, Universal, 173.2 MB)<br />
* [http://downloads.sourceforge.net/wesnoth/Battle_for_Wesnoth_1.4.4b_UB.dmg?download Previous Version (Full)] (1.4.4b, Universal, 172.2 MB)<br />
<br />
==== GNU/Linux ====<br />
* There are binaries for many different GNU/Linux Distributions. Not all are always up to date with the current release. Please have a look at the [[WesnothBinariesLinux|Linux binary page]] for more information about the binaries for your Distribution.<br />
<br />
==== (Open)Solaris ====<br />
* [http://downloads.sourceforge.net/wesnoth/wesnoth-solaris-i386-1.4.5.pkg.bz2?download Current Version] (1.4.4, 145.6 MB)<br />
* [http://downloads.sourceforge.net/wesnoth/wesnoth-1.4.4.solaris.i386.pkg.bz2?download Previous Version] (1.4.4, 129.1 MB)<br />
<br />
==== OS/2 & eComStation ====<br />
* The current version (1.4.5) is not available yet.<br />
* [http://download.smedley.info/wesnoth-1.4.2-os2-20080515.zip Older version] (1.4.2, 200 MB)<br />
<br />
==== Miscellaneous ====<br />
* [http://downloads.sourceforge.net/wesnoth/wesnoth-1.4.4.tar.bz2.md5?download md5sum for current source code]<br />
* [http://www.wesnoth.org/wiki/Download_Xdeltas#Source_code Xdelta for the source code]<br />
* [http://sourceforge.net/project/showfiles.php?group_id=89495 SourceForge page for current and all previous versions]<br />
<br />
== Development (1.5 branch) ==<br />
<br />
Version 1.5.x is the latest development version, boasting updated graphics and new exciting features. However, there may be occasional bugs or performance problems in the development versions since heavy changes are taking place all the time. For balanced and stable gaming, it is recommended you use the latest version of the 1.4.x branch. This version is recommended for coders and campaign developers that want to use all of the latest possibilities, as well as those who want to preview the future of Wesnoth.<br />
<br />
==== Source code ====<br />
* [http://downloads.sourceforge.net/wesnoth/wesnoth-1.5.3.tar.bz2?download Current Version] (1.5.3, 149.6 MB)<br />
* [http://downloads.sourceforge.net/wesnoth/wesnoth-1.5.2.tar.bz2?download Previous Version] (1.5.2, 148.7 MB)<br />
<br />
* [[CompilingWesnoth|Compiling Guide]] - how to compile the source code<br />
<br />
==== MS Windows ====<br />
* [http://downloads.sourceforge.net/wesnoth/wesnoth-1.5.3-windows.exe?download Current Version] (1.5.3, 156.9 MB)<br />
* [http://downloads.sourceforge.net/wesnoth/wesnoth-1.5.2-win32.exe?download Previous Version] (1.5.2, 136.0 MB)<br />
<br />
==== Mac OS X ====<br />
* [http://downloads.sourceforge.net/wesnoth/Battle_for_Wesnoth_1.5.3_UB.dmg?download Current Version] (1.5.3, Universal, 175.4 MB).<br />
* [http://downloads.sourceforge.net/wesnoth/Battle_for_Wesnoth_1.5.2b_UB.dmg?download Previous Version] (1.5.2, Universal, 179.3 MB)<br />
<br />
==== GNU/Linux ====<br />
* There are binaries for many different GNU/Linux Distributions. Not all are always up to date with the current release. Please have a look at the [[WesnothBinariesLinux|Linux binary page]] for more information about the binaries for your Distribution.<br />
<br />
==== (Open)Solaris ====<br />
* The current version (1.5.3) is not available yet.<br />
* [http://downloads.sourceforge.net/wesnoth/wesnoth-1.5.1.solaris.i386.pkg.bz2?download Older Version] (1.5.1, 130.4 MB)<br />
<br />
==== AmigaOS4 ====<br />
* The current version (1.5.3) is not available yet.<br />
* [http://os4depot.net/index.php?function=showfile&file=game/strategy/wesnoth-devel.lha Older Version] (1.3.12, 105.0 MB)<br />
<br />
==== OS/2 & eComStation ====<br />
* The current version (1.5.3) is not available yet.<br />
* [http://download.smedley.info/wesnoth-1.1.8-os2.zip Older Version] (1.1.8, 66 MB)<br />
<br />
==== Syllable ====<br />
* The current version (1.5.3) is not available yet.<br />
* [http://www.syllable-software.info/download.php?view.32 Older Version] (1.3.8, 82.2 MB)<br />
<br />
==== Miscellaneous ====<br />
* [http://downloads.sourceforge.net/wesnoth/wesnoth-1.5.3.tar.bz2.md5?download md5sum for current source code]<br />
* [http://www.wesnoth.org/wiki/Download_Xdeltas#Source_code Xdelta for the source code]<br />
* [http://sourceforge.net/project/showfiles.php?group_id=89495 SourceForge page for current and all previous versions]<br />
* [http://downloads.sourceforge.net/wesnoth/Mac_Compile_Stuff_1.5.3.tar.bz2? MacCompileStuff for 1.5.3]<br />
<br />
== License ==<br />
''Main article: [[Wesnoth:Copyrights]]<br />
<br />
This program is free software; you can redistribute it and/or modify it under the terms of the [http://www.fsf.org/copyleft/gpl.html GNU General Public License version 2], as published by the [http://www.fsf.org/ Free Software Foundation].<br />
This program is distributed in the hope that it will be useful, but without any warranty; without even the implied warranty of merchantability or fitness for a particular purpose. See the GNU General Public License for more details.<br />
<br />
== See also ==<br />
* [http://changelog.wesnoth.org Changelog]<br />
* [[WesnothBinaries| More binaries]]<br />
* [[WesnothSVN]] - bleeding edge version from SVN<br />
<br />
[[Category:Building and Installing]]</div>Loonycyborghttps://wiki.wesnoth.org/index.php?title=Download&diff=26573Download2008-09-01T22:07:57Z<p>Loonycyborg: /* MS Windows */</p>
<hr />
<div>Welcome to the Battle for Wesnoth downloads page. The BFW project team only officially releases the source code. Binary packages are only provided by community volunteers and hosted here. Torrents are also unofficial.<br />
<br />
If the latest binaries are not currently available for your OS, please check back in a few days to see if they have been placed here. Packagers have been informed of the release, please be patient. In the meantime, read the [[FAQ#A_new_version_is_out.2C_but_where_is_the_download_for_.5BWindows.2C_Mac_OS.2C_etc..5D.3F|FAQ]].<br />
<br />
__NOTOC__<br />
Jump to: [[Download#Stable_.281.4_branch.29|Stable Branch]] | [[Download#Development_.281.5_branch.29|Development Branch]]<br />
<br />
== Stable (1.4 branch) ==<br />
<br />
The stable files are meant to be used as a stable and rather balanced version of the game. Each version of the 1.4 branch is compatible to each other. This will not happen in the development branch.<br />
<br />
Version 1.4 is the latest stable version, updated with several important bugfixes. This version is recommended for most players since the 1.4 online multiplayer community is very large and user-made campaign server has a robust content selection.<br />
<br />
==== Source code ====<br />
* [http://downloads.sourceforge.net/wesnoth/wesnoth-1.4.4.tar.bz2?download Current Version] (1.4.4, 145.4 MB)<br />
* [http://downloads.sourceforge.net/wesnoth/wesnoth-1.4.3.tar.bz2?download Previous Version] (1.4.3, 144.6 MB)<br />
* [[CompilingWesnoth|Compiling Guide]] - how to compile the source code<br />
<br />
==== MS Windows ====<br />
* [http://downloads.sourceforge.net/wesnoth/wesnoth-1.4.4-win32.exe?download Current version] (1.4.4, 132.8 MB)<br />
* [http://downloads.sourceforge.net/wesnoth/BfW_setup.exe?download Previous version] (1.4.3, 132.3 MB)<br />
<br />
==== Mac OS X ====<br />
* [http://downloads.sourceforge.net/wesnoth/Battle_for_Wesnoth_1.4.4b_UB.dmg?download Current Version (Full)] (1.4.4b, Universal, 172.2 MB)<br />
* [http://downloads.sourceforge.net/wesnoth/Wesnoth_MacOSX_1.4.3.dmg?download Previous Version (Full)] (1.4.3, Universal, 159.5 MB)<br />
* [http://downloads.sourceforge.net/wesnoth/Wesnoth_MacOSX_1.4.3_lite.dmg?download Previous Version (Lite)] (1.4.3, Universal, 73.5 MB)<br />
<br />
==== GNU/Linux ====<br />
* There are binaries for many different GNU/Linux Distributions. Not all are always up to date with the current release. Please have a look at the [[WesnothBinariesLinux|Linux binary page]] for more information about the binaries for your Distribution.<br />
<br />
==== (Open)Solaris ====<br />
* [http://downloads.sourceforge.net/wesnoth/wesnoth-1.4.4.solaris.i386.pkg.bz2?download Current Version] (1.4.4, 129.1 MB)<br />
* [http://downloads.sourceforge.net/wesnoth/wesnoth-1.4.3.solaris.i386.pkg.bz2?download Previous Version] (1.4.3, 128.9 MB)<br />
<br />
==== OS/2 & eComStation ====<br />
* The current version (1.4.4) is not available yet.<br />
* [http://download.smedley.info/wesnoth-1.4.2-os2-20080515.zip Older version] (1.4.2, 200 MB)<br />
<br />
==== Miscellaneous ====<br />
* [http://downloads.sourceforge.net/wesnoth/wesnoth-1.4.4.tar.bz2.md5?download md5sum for current source code]<br />
* [http://www.wesnoth.org/wiki/Download_Xdeltas#Source_code Xdelta for the source code]<br />
* [http://sourceforge.net/project/showfiles.php?group_id=89495 SourceForge page for current and all previous versions]<br />
<br />
== Development (1.5 branch) ==<br />
<br />
Version 1.5.x is the latest development version, boasting updated graphics and new exciting features. However, there may be occasional bugs or performance problems in the development versions since heavy changes are taking place all the time. For balanced and stable gaming, it is recommended you use the latest version of the 1.4.x branch. This version is recommended for coders and campaign developers that want to use all of the latest possibilities, as well as those who want to preview the future of Wesnoth.<br />
<br />
==== Source code ====<br />
* [http://downloads.sourceforge.net/wesnoth/wesnoth-1.5.3.tar.bz2?download Current Version] (1.5.3, 149.6 MB)<br />
* [http://downloads.sourceforge.net/wesnoth/wesnoth-1.5.2.tar.bz2?download Previous Version] (1.5.2, 148.7 MB)<br />
<br />
* [[CompilingWesnoth|Compiling Guide]] - how to compile the source code<br />
<br />
==== MS Windows ====<br />
* [http://downloads.sourceforge.net/wesnoth/wesnoth-1.5.3-windows.exe?download Current Version] (1.5.3, 156.9 MB)<br />
* [http://downloads.sourceforge.net/wesnoth/wesnoth-1.5.2-win32.exe?download Previous Version] (1.5.2, 136.0 MB)<br />
<br />
==== Mac OS X ====<br />
* [http://downloads.sourceforge.net/wesnoth/Battle_for_Wesnoth_1.5.3_UB.dmg?download Current Version] (1.5.3, Universal, 175.4 MB).<br />
* [http://downloads.sourceforge.net/wesnoth/Battle_for_Wesnoth_1.5.2b_UB.dmg?download Previous Version] (1.5.2, Universal, 179.3 MB)<br />
<br />
==== GNU/Linux ====<br />
* There are binaries for many different GNU/Linux Distributions. Not all are always up to date with the current release. Please have a look at the [[WesnothBinariesLinux|Linux binary page]] for more information about the binaries for your Distribution.<br />
<br />
==== (Open)Solaris ====<br />
* The current version (1.5.3) is not available yet.<br />
* [http://downloads.sourceforge.net/wesnoth/wesnoth-1.5.1.solaris.i386.pkg.bz2?download Older Version] (1.5.1, 130.4 MB)<br />
<br />
==== AmigaOS4 ====<br />
* The current version (1.5.3) is not available yet.<br />
* [http://os4depot.net/index.php?function=showfile&file=game/strategy/wesnoth-devel.lha Older Version] (1.3.12, 105.0 MB)<br />
<br />
==== OS/2 & eComStation ====<br />
* The current version (1.5.3) is not available yet.<br />
* [http://download.smedley.info/wesnoth-1.1.8-os2.zip Older Version] (1.1.8, 66 MB)<br />
<br />
==== Syllable ====<br />
* The current version (1.5.3) is not available yet.<br />
* [http://www.syllable-software.info/download.php?view.32 Older Version] (1.3.8, 82.2 MB)<br />
<br />
==== Miscellaneous ====<br />
* [http://downloads.sourceforge.net/wesnoth/wesnoth-1.5.3.tar.bz2.md5?download md5sum for current source code]<br />
* [http://www.wesnoth.org/wiki/Download_Xdeltas#Source_code Xdelta for the source code]<br />
* [http://sourceforge.net/project/showfiles.php?group_id=89495 SourceForge page for current and all previous versions]<br />
* [http://downloads.sourceforge.net/wesnoth/Mac_Compile_Stuff_1.5.3.tar.bz2? MacCompileStuff for 1.5.3]<br />
<br />
== License ==<br />
''Main article: [[Wesnoth:Copyrights]]<br />
<br />
This program is free software; you can redistribute it and/or modify it under the terms of the [http://www.fsf.org/copyleft/gpl.html GNU General Public License version 2], as published by the [http://www.fsf.org/ Free Software Foundation].<br />
This program is distributed in the hope that it will be useful, but without any warranty; without even the implied warranty of merchantability or fitness for a particular purpose. See the GNU General Public License for more details.<br />
<br />
== See also ==<br />
* [http://changelog.wesnoth.org Changelog]<br />
* [[WesnothBinaries| More binaries]]<br />
* [[WesnothSVN]] - bleeding edge version from SVN<br />
<br />
[[Category:Building and Installing]]</div>Loonycyborghttps://wiki.wesnoth.org/index.php?title=StartingPoints&diff=26390StartingPoints2008-08-11T07:18:25Z<p>Loonycyborg: /* Developer information */</p>
<hr />
<div>__NOTOC__<br />
<br />
What would you like to learn about Wesnoth in this wiki? [[Play]] it, [[create]] with it, [[support]] for it, [[project]] resources about it, [[credits]] of it.<br />
<br />
This is a page with starting points to exploring this wiki about The Battle for Wesnoth. In addition to the wiki, there's also a [http://www.wesnoth.org homepage], a [http://www.wesnoth.org/forum forum], and a [http://gna.org/projects/wesnoth/ Gna project page].<br />
<br />
* [[Special:Categories|List of all page categories in this wiki]]<br />
* [[Special:Allpages|List of all pages in this wiki]]<br />
<br />
== Getting the Game ==<br />
==== Downloading ====<br />
* [[Download]] - get the most recent source-files and many binaries<br />
** [[WesnothBinaries]] - precompiled for GNU/Linux, BeOS, PDAs, ...<br />
** [[WesnothBinariesLinux]] - precompiled for many GNU/Linux distributions<br />
<br />
==== Compiling ====<br />
* [[CompilingWesnoth]] - on Unix, Mac, Windows, GNU/Linux, PDAs, ...<br />
* [[UsingSourceinstall]] - using GNU Source Installer to automate installation and upgrades from source (Unix-likes only)<br />
* [[DebuggingWesnoth]] - on GNU/Linux and Unix-like systems<br />
* [[WesnothOnLinuxPDAs]] - on the Qtopia/OPIE and thepdaXrom/Zaurus C series<br />
<br />
== Playing the Game ([[Play]]) ==<br />
<br />
==== For New Players ====<br />
* [[GettingStarted]] - read me first!<br />
* [[WesnothManual]] - the rules<br />
* [[MainlineCampaigns]] - walkthroughs for the game-supplied campaigns<br />
<br />
==== For Not-So-New Players ====<br />
* [[AdvancedTactics]] - beating the AI and other people<br />
* [[MultiplayerServers]] - where to play against other people online<br />
* [[Replays]] - archive of replays new and old<br />
* [[How to play...]] - learn more about various faction vs faction strategies<br />
<br />
==== Reference ====<br />
* [[HotKeysSystem]] - keyboard shortcuts<br />
* [[CommandMode]] - commands you can use in-game<br />
* [[ServerAdministration]] - commands that authenticated users can use to administer the server<br />
* [http://units.wesnoth.org/ Units] - Units advancement trees and stats<br />
** [http://units.wesnoth.org/1.4/ Stable version]<br />
** [http://units.wesnoth.org/trunk Trunk version]<br />
* [[Races]] - [[Drakes (race)|Drakes]], [[Dwarves]], [[Elves]], [[Humans]], [[Orcs]], [[Undead (race)|Undead]], etc.<br />
** [[Factions]] - all major factions, mainline and user-made<br />
* [[Wesnoth_Acronyms_and_Slang|Wesnoth Acronyms and Slang]] - common wesnothian acronyms and slang explained<br />
<br />
== Tweaking the Game ([[Create]]) ==<br />
==== Scenarios & Campaigns ====<br />
* [[UserScenarios]] - user-written scenarios, campaigns and game modifications<br />
* [[UMCSandbox]] - where you can do collaborative UMC development<br />
* [[BuildingCampaigns]] - how to make your own single player campaigns<br />
* [[MultiplayerCampaigns]] - how to make your own multiplayer campaigns<br />
* [[BuildingScenarios]] - how to make your own scenarios<br />
* [[BuildingUnits]] - how to make your own units<br />
* [[UnitAnalysis]] - tool to analyze units<br />
<br />
==== References ====<br />
* [[ReferenceWML]] and [[AlphabeticalWML]] - all about Wesnoth Markup Language<br />
* [[ReferencePythonAPI]] - upcoming Python interface for AI<br />
==== Tools & Utilities ====<br />
* [[ExternalUtilities]] - scripts to help create scenarios, campaigns, and graphics<br />
* [[WesnothMapEditor]] - summary of controls<br />
* [[CustomizingStartup]] - some tweaks for optimizing the game's startup&performance<br />
<br />
==== Art related ====<br />
* [[Create_Art#Art_Tutorials|Art Tutorials]] - help in creating art<br />
* [[GraphicLibrary]] - unit and terrain images posted on the forums<br />
* [[Tiles_Status]] - terrain tiles: proposed and in progress.<br />
<br />
== Improving the Game ==<br />
* [[ReportingBugs]] - use Gna!<br />
* [http://www.wesnoth.org/wiki/ReportingBugs#Guidelines_for_suggesting_features Guidelines for suggesting features] - To submit a feature request, use http://bugs.wesnoth.org<br />
==== Developer information ====<br />
* [[DeveloperResources]] - useful links<br />
* [http://changelog.wesnoth.org Changelog] - the most recent changes made to the game<br />
* [[WesnothSVN]] - accessing the source code<br />
* [[HackingWesnoth]] - guide for programmers<br />
* [[CodingStandards]] - for programmers<br />
* [[DeveloperGuide]] - for those who received SVN commit rights<br />
* [http://www.wesnoth.org/units/trunk/animations.html Missing unit animations] - what's available and what's missing<br />
* [[WritingYourOwnAI]] - write a C++ plugin<br />
* [[FormulaAI]] - Guide to the experimental formula AI branch<br />
* [[ThemeSystem]] - customizing the screen layout for the game and the editor<br />
* [[ReleasingWesnoth]] - steps to follow to release a new version<br />
* [[WesnothPackagersGuide]] - guidelines for packaging Wesnoth for different platforms<br />
* [[EasyCoding]] - Bugs and features that are easy to implement for new coders<br />
* [[NotSoEasyCoding]] - Bugs and features which are doable but lacking someone working on them<br />
* [[WesnothGL]] - Guide to programming the Wesnoth OpenGL branch<br />
* [[WesnothdDesign]] - Guide to the design of wesnothd, the multiplayer server.<br />
<br />
==== Game translations ====<br />
* [[GettextForTranslators]] - how to translate Wesnoth under [[GetText]]<br />
* [[WesnothTranslations]] - completely unknown stats...<br />
* [[WesCamp]] - a project for translating user-made campaigns<br />
<br />
== About the Game ==<br />
* [[WesnothPhilosophy]] - Dave on Wesnoth<br />
* [[History of Wesnoth]] - the Ages of Wesnoth<br />
* [[Geography of Wesnoth]] - description of Wesnoth and surrounding lands<br />
* [[WesnothFigures]] - notable figures of valorous and infamous deeds in Wesnoth<br />
* [[WesnothReviews]] - third party reviews of Wesnoth<br />
* [irc://irc.wesnoth.org/wesnoth #wesnoth] - our IRC channel<br />
* [[Donate]] or [http://cafepress.com/wesnoth buy Wesnoth merchandise].<br />
* [[Trailer]] - the Wesnoth trailer<br />
<br />
== Other ==<br />
* [[UsefulLinks]]<br />
* [http://wesnoth.slack.it/?WesnothPlayerMap Map of Wesnoth player locations] - add yourself to the map!<br />
* [http://en.wikipedia.org/wiki/Battle_for_Wesnoth Wikipedia entry for Wesnoth]<br />
* [[WikiHaiku]]<br />
<br />
== About this Wiki ==<br />
* [[Help:Editing|Editing]] - learn how to edit pages<br />
* [[Sandbox]] - experiment with the wiki<br />
* [[WikiMigration]] - we were looking for a replacement for our old wiki (and ended up using Mediawiki)<br />
* [http://www.wesnoth.org/forum/viewtopic.php?t=19462 Obsolete] - help in updating the wiki for v1.4<br />
<br />
[[Category:Wesnoth Wiki]]</div>Loonycyborg