Post by Iris » December 16th, 2015, 4:29 am

Wesnoth 1.13.2 is out!

Download and install, making sure to keep the latest stable release around in case the game breaks and you find yourself unable to get your daily fix of Wesnoth.

Playtest the game, try out some of the API additions for content creators, and write down your observations in a notebook or similar.

If you encounter issues, don’t panic; instead, grab some bug spray and protective gear, and head directly to our instructions for reporting bugs. Most importantly, keep in mind that we can’t know about any bugs you encounter unless you report them to us!

Near the end of the release notes below you will find a list of the most important bugs known at the time of release. Some items are due to be fixed in the next release, but for others we depend on contributed patches from volunteer coders like you! (If you are a coder, that is.)

Check our bug tracker for a full list of bugs and feature requests, including other bugs found after the release was published.

General

New game version dialog and paths display » There is a new button on the bottom left corner of the title screen that opens a new dialog displaying version and build information about the game. This displays the game and OS version (Windows and OS X only), optional features enabled by packagers, and library versions. The first dialog page additionally contains all information that was previously found in Preferences → General → Paths in 1.12.x. For Windows users, it’s possible to access the current session’s log file from this page as well.



The dialog includes a button to copy its contents as a report that could be, for example, pasted into Technical Support posts or bug reports to help players gather information for developers more with a single click. We intend to further refine this feature and make more use of it as Wesnoth becomes more reliant on hardware features in future releases.

Windows: New user files location » Short version:



The installer no longer provides a choice between storing user files in the installation dir and Documents\My Games\WesnothX.Y , forcing the latter instead (which no longer requires a command-line switch to be added to the game shortcut).



Long “you want to read this with a cup of tea” version:



Up to Windows XP, mostly owing to the lack of user and process access control facilities on the mainstream Windows 9x series, applications would freely write user data into their installation paths without restriction. NT-based versions of Windows (including Windows XP) still supported this when running processes as accounts with administrator privileges, albeit at the risk of breaking things horribly in a proper multi-user environment. However, since Windows Vista, this practice is no longer recommended (and rightly so). Because there are too many applications that rely on the aforementioned broken scheme, Vista introduces User Access Control Virtualization to support legacy applications, by redirecting their writes to restricted paths to a user-dependent Virtual Store location.



Until now, the official Wesnoth installer has included the option to store user files either in the user’s Documents folder, or in the installation dir; the latter option forces Wesnoth to rely on UAC Virtualization if Wesnoth has been installed system-wide and then is run with normal user privileges. This has resulted in confusing documentation and countless forum threads on the matter of finding the actual location of Wesnoth’s user files on disk, mostly due to people choosing the install dir option without a real need to do so .



From this version onwards, the installer no longer provides the option to store user files in the installation dir, and the game itself defaults to using the Documents folder (more specifically, Documents\My Games\WesnothX.Y where X.Y represents the major and minor version numbers, such as 1.13 ) unless specifically instructed to do otherwise with the --config-dir option in the command line. Additionally, --config-dir paths can be either absolute, relative to Documents\My Games (to support the previous installer approach to storing files in Documents), or relative to the process current working dir (usually the install dir) if either . or .. are provided as the first path component; this latter option is provided so that people can still install and run Wesnoth from removable media if they wish.



See also bug



Command-line changes short version:



(For people who need to customize the game’s command-line for any reason.)



Before 1.13.2: Default: use <cwd>\userdata

With --config-dir <path> : use <Home dir>\Documents\My Games\<path> (installer adds --config-dir WesnothX.Y ) if path does not begin with a drive spec use absolute <path> otherwise

: After 1.13.2: Default: use <Home dir>\Documents\My Games\WesnothX.Y

With --config-dir <path> : use <cwd>\<path> if path begins with . or .. use <Home dir>\Documents\My Games\<path> (installer adds --config-dir WesnothX.Y ) if path does not begin with a drive spec; use absolute <path> otherwise

: The installer no longer provides a choice between storing user files in the installation dir and, forcing the latter instead (which no longer requires a command-line switch to be added to the game shortcut).Up to Windows XP, mostly owing to the lack of user and process access control facilities on the mainstream Windows 9x series, applications would freely write user data into their installation paths without restriction. NT-based versions of Windows (including Windows XP) still supported this when running processes as accounts with administrator privileges, albeit at the risk of breaking things horribly in a proper multi-user environment. However, since Windows Vista, this practice is no longer recommended (and rightly so). Because there are too many applications that rely on the aforementioned broken scheme, Vista introduces User Access Control Virtualization to support legacy applications, by redirecting their writes to restricted paths to a user-dependent Virtual Store location.Until now, the official Wesnoth installer has included the option to store user files either in the user’s Documents folder, or in the installation dir; the latter option forces Wesnoth to rely on UAC Virtualization if Wesnoth has been installed system-wide and then is run with normal user privileges. This has resulted in confusing documentation and countless forum threads on the matter of finding the actual location of Wesnoth’s user files on disk, mostly due to people choosing the install dir optionFrom this version onwards, the installer no longer provides the option to store user files in the installation dir, and the game itself defaults to using the Documents folder (more specifically,whererepresents the major and minor version numbers, such as) unless specifically instructed to do otherwise with theoption in the command line. Additionally,paths can be either absolute, relative to(to support the previous installer approach to storing files in Documents), or relative to the process current working dir (usually the install dir) if either . or .. are provided as the first path component; this latter option is provided so that people can still install and run Wesnoth from removable media if they wish.See also bug #23753 [Gna.org] (For people who need to customize the game’s command-line for any reason.)

Windows: New log files location » stdout.txt / stderr.txt in the installation path. Instead, a single combined log file is written to <user data dir>\logs\wesnoth-<TIMESTAMP>-<PID>.log containing all stdout and stderr output. Up to 8 older log files are kept around, the rest being automatically deleted at game startup. Note that if an early startup failure occurs, the log file will be found at %TEMP%\wesnoth-<TIMESTAMP>-<PID>.log instead.



Since this replaces SDL 1.2’s buggy built-in stdout/stderr redirection code with a Unicode-aware alternative, this also fixes bug NOTE: this only applies to the 1.13.2a installer uploaded on 2015-12-12 before this announcement was published. Players building from source or using the original unpatched 1.13.2 installer will experience a more severe variation of From this release onwards, Wesnoth no longer writes its stdout/stderr logs toin the installation path. Instead, a single combined log file is written tocontaining all stdoutstderr output. Up to 8 older log files are kept around, the rest being automatically deleted at game startup. Note that if an early startup failure occurs, the log file will be found atinstead.Since this replaces SDL 1.2’s buggy built-in stdout/stderr redirection code with a Unicode-aware alternative, this also fixes bug #22897 [Gna.org] . (this only applies to theinstaller uploaded onbefore this announcement was published. Players building from source or using the original unpatched 1.13.2 installer will experience a more severe variation of #22897 [Gna.org] which causes the game to quit with an error at startup on affected systems.)

For Players

In-game chat tab-completion improvements and disconnect notifications »



Additionally, the lobby joins display option in Preferences → Multiplayer (Do not show/Friends only/Show all) now controls the display of lobby disconnects as well (pull request Chat tab-completion while in-game now allows tab-completing nicks from the friends list and incoming whispers from the lobby for convenience (pull requests #529 and #542 by neverEnough).Additionally, the lobby joins display option in Preferences → Multiplayer (Do not show/Friends only/Show all) now controls the display of lobby disconnects as well (pull request #548 by neverEnough).

Replay turns during multiplayer games » It is now possible to load an autosave in a networked multiplayer game: when an autosave is loaded the local gamestate will be reset to the gamestate at that point. Then the game will be replayed (using the replay UI) until the current gamestate. When the current gamestate is reached the replay UI is removed and the game continues normally.



Do note that using this feature will cause OOS if side controllers changed during the game.

Fixed OOS errors on random maps » Some people experienced OOS errors on random maps due to sides being placed in different castles in the beginning of the game. This has now been fixed.

Mainline campaign fixes » Delfador’s Memoirs: Added defeat condition for death of the last undead veteran in “Showdown in the Northern Swamp” (bug #23668 [Gna.org]).

Eastern Invasion: Fixed scenario events not working right on easy difficulty in “Captured”.

The South Guard: Deoran is now the grandson of the Haldiel in HttT instead.

Under the Burning Suns: Gave Garak a new ability called Teaching (at the start of every turn, his experience points are transferred to adjacent units on the same side).

Tutorial: Fixed transition to second scenario.

For Content Creators

WML/Lua compatibility changes and deprecations » The WML preprocessor now issues warnings to stderr when redefining macros without undefining them first with #undef .

. [advance] was changed to [advancement] in modifications; as a result, AMLA definition macros (such as {AMLA_DEFAULT} ) can now be used to create units that have already taken certain advancements.

was changed to in modifications; as a result, AMLA definition macros (such as ) can now be used to create units that have already taken certain advancements. {FOREACH} and {NEXT} now use [for] tags; this is only important for users who used one of these tags without the other, such as a custom loop macro closed by {NEXT} .

and now use tags; this is only important for users who used one of these tags without the other, such as a custom loop macro closed by . The interface of wesnoth.synchronize_choice for choices from multiple sides (which was introduced in wesnoth 1.13.0) has changed.

for choices from multiple sides (which was introduced in wesnoth 1.13.0) has changed. wesnoth.get_unit([i]underlying_id[/i]) was removed; this was pretty useless since there was no reliable way to obtain the underlying id (as opposed to the regular text id) and non-engine code should never use underlying ids anyway.

was removed; this was pretty useless since there was no reliable way to obtain the underlying id (as opposed to the regular text id) and non-engine code should never use underlying ids anyway. Changed wesnoth.put_unit so that the unit is passed as the first parameter; the original order is still supported, but is deprecated. In addition, calling wesnoth.put_unit without a unit (i.e., with just a location) is deprecated in favor of a new wesnoth.erase_unit function.

so that the unit is passed as the first parameter; the original order is still supported, but is deprecated. In addition, calling without a unit (i.e., with just a location) is deprecated in favor of a new function. [side] share_view=yes/no , share_maps=yes/no were replaced with share_vision=all/shroud/none .

, were replaced with . The menu item syntax (e.g. &image.png=Peasant=Easy ) in campaign difficulty and in [message][option] is now deprecated

Tools ported to Python 3 » All WML maintenance tools shipped with Wesnoth ( wmllint / wmllint-1.4 , wmlindent , wmlscope , GUI.pyw ) and the add-ons client script ( wesnoth_addon_manager ) have all been ported to Python 3, thus requiring Python 3.2 to run from this release onwards.

Default values for WML variables » In variable substitution it is now possible to specify default values for example name="$player_name?Klaus|" will evaluate to name="Klaus" in case the variable player_name is not set.

New [tt]$other_unit[/tt] variable in Standard Unit Filters » A new $other_unit variable is accessible in some unit filters. This can be used in [filter_adjacent] and similar contexts to create filters that are relative to the main unit. The backstab and leadership abilities have been rewritten to take advantage of this feature, which allows leadership to be implemented by a single macro, {ABILITY_LEADERSHIP} . Although the old {ABILITY_LEADERSHIP_LEVEL_3} etc macros are still available, they merely point to the new one. As a result, anyone who used a leadership level not matching the unit’s level (for example, level 4 leadership on a level 3 unit) will find that this no longer works as expected.

New looping and flow control tags » [continue] , [break] , and [return] . The {FOREACH} and {REPEAT} macros have been altered to make use of these new loops, which fixes an issue whereby the {REPEAT} macro would not work correctly if nested in itself. A number of new WML tags have been added for different types of loops as well as loop flow control. The new looping tags are [for] [foreach] , and [repeat] , while the flow control tags are, and. Theandmacros have been altered to make use of these new loops, which fixes an issue whereby themacro would not work correctly if nested in itself.

Custom [tt][effect][/tt]s » It is now possible to create custom effects with the wesnoth.effects Lua table.

New [tt][resource][/tt] tag for modifications » [event] and [lua] blocks; this is similar to MP [modification] s, except that [resource]s are not displayed to the player. A new [resource] tag was introduced which can containandblocks; this is similar to MPs, except that [resource]s are not displayed to the player.

Known Bugs

Newly introduced in 1.13.x » General bugs:

The MP server has trouble with Local player types in campaigns (bug #21965 [Gna.org]). We have decided to postpone dealing with this. In the meantime, you might try assigning such sides to the host, or running multiple instances of Wesnoth.

Replaying turns during MP games with the new feature causes OOS in multiplayer games if side controllers changed during the game.

The game can crash when planning recruits in Planning Mode.

[event] in [unit] , [unit_type] or [side] does not work as expected.

in , or does not work as expected. Using [set_menu_item] to change an existing menu items fails in some cases.

Carried over from 1.12.x » General bugs:

It’s not possible to clear some default hotkeys with the Clear Hotkey option (bug #21983 [Gna.org]).

Attempting to assign hotkeys including both the Ctrl and Alt modifiers does not work (bug #22219 [Gna.org]). Bugs specific to Microsoft Windows:

ClearType font rendering is disabled as it causes glitches (bug #21648 [Gna.org]).

This is likely caused by outdated libraries in the packaging process.

This is likely caused by outdated libraries in the packaging process. Consecutive line breaks (paragraph breaks) are not rendered as expected (bug #21649 [Gna.org]).

This is likely caused by outdated libraries in the packaging process. There is no built-in workaround available yet. Bugs specific to Apple OS X:



The following issues affecting Wesnoth on Apple OS X are known and they are pending fixes. Many of them require significant re-engineering that can only be done in 1.13.x development releases later, or cannot be properly addressed due to a lack of experienced OS X coders in our team. Thus, unless someone can contribute patches to address them, it is unlikely that these bugs will be fixed.

Color cursors are forcibly disabled on this platform due to severe performance issues (bug #18112 [Gna.org]).

The default variable-width font is used instead of a monospace font even where a monospace font is required (bug #23628 [Gna.org]).

Helvetica is used as the default variable-width font instead of DejaVu Sans (bug #23560 [Gna.org]).

Fullscreen mode does not fill the entire screen when maximum resolution is selected in Preferences → Display, and user interface elements are scaled and distorted.

System commands do not work while Wesnoth is running in fullscreen mode (bug #21943 [Gna.org]).

The mouse cursor is not mapped correctly to the game screen contents on Retina displays due to problems with detected vs. real screen resolution mismatches (bug #20332 [Gna.org]).

A workaround is in place making Wesnoth default to 800x600 on OS X regardless of the incorrectly-detected maximum resolution.

A workaround is in place making Wesnoth default to 800x600 on OS X regardless of the incorrectly-detected maximum resolution. Trackpad tap clicking is sometimes not recognized (forum post).

Unofficial builds with OpenMP support enabled randomly freeze (bug #18144 [Gna.org]).

Consecutive line breaks (paragraph breaks) are not rendered as expected (bug #21649 [Gna.org]).

This is likely caused by outdated libraries in the packaging process. There is no built-in workaround available yet. The following issues affecting Wesnoth on Apple OS X are known and they are pending fixes. Many of them require significant re-engineering that can only be done in 1.13.x development releases later, or cannot be properly addressed due to a lack of experienced OS X coders in our team. Thus, unless someone can contribute patches to address them, it is unlikely that these bugs will be fixed.

New Contributors and Developers

irc.freenode.net

Downloads

Players on Apple OS X 10.11 should check this post before downloading.

⁂

It has been an eventful six months since the previous development release, and as the year is coming to a close, we thought you would appreciate another slew of features and fixes right in time for the holidays! This time, our development team has worked hard on various WML and Lua API additions for content creators, as well as a couple of long overdue changes to the user experience on Windows. But in case you prefer shiny and visible improvements instead, we also have some graphic updates to unveil, a few redone sound effects, and a brand new logo for the game by Sgt. Groovy ! And naturally, this release includes all applicable fixes from stable version 1.12.5 , as well as its additions to the Map Editor and Gamestate Inspector.Behind the scenes, this is slated to be the last release using the dated SDL 1.2 libraries. 1.13.3 and later will be built using SDL 2.0 instead, which will hopefully allow us to fix a plethora of long-standing bugs on Apple OS X and (to a lesser extent) other platforms, as well as look into hardware-accelerated graphics support and all kinds of new graphics features in the future. Obviously, it’s going to be a quite bumpy ride from that point onwards, but we believe it will be worth it!As this is a development version, we would like to remind everyone how the testing and feedback process works for these:Read on for more details about the most notable fixes and additions in this release:As is to be expected with development releases, there may be many, many more changes in addition to the aforementioned, including WML and Lua API additions for user-made content creators, translation updates, and fixes for recent and long-standing issues. Most of these items are listed in the full changelog . If that seems too overwhelming, you might be glad to know we also provide an alternative players changelog including only those changes deemed to be relevant to the average player.Do not be disappointed if the game crashes every now and then! Development versions are not the best for those in need of a stable gaming experience, who should stick to thestable 1.12.x series instead. However, if you want to help us test what will eventually become thestable 1.14.x series, you definitely should check out this release and report to us any problems you find so they can be fixed in a timely fashion.are also especially encouraged to port and test their content under new development versions to detect any problems with their add-ons or Wesnoth in advance.This release includes contributions from the following people who submitted their pull requests to GitHub: Aginor Celtic_Minstrel , chisquare130, halfspiral, iKevinY, JohnAnthony, jstitch, legoktm, midzer, niegenug/ neverEnough , PBechon, pquentin, rjaguar3, Ryckes, techtonik, Wedge009 . Additionally, Aginor and Celtic_Minstrel are now members of the development team.Do you want to help shape the future of Wesnoth? You are always welcome to join us in the IRC channel onto ask for help with getting started!A package foris already available:A package foris now available.All knownpackagers have been contacted, and binaries for your distribution may have already been created. Information about where to get the respective binaries or how to install them can be found on the Linux binaries page in the wiki.Downloads formay be found on the Download page in the wiki as they become available.The multiplayer server for 1.13.x is up and running.The add-ons server for 1.13.x is already running. It was started for 1.13.0 and it servesdevelopment releases from this series.If you find any bugs, do not hesitate to report them, but please read the instructions on how to report bugs first! As bug reports in the forums tend to be forgotten, you will get better results using our bug tracker . We require your help for finding and fixing issues, no matter how obvious, trivial or complicated they seem!Have fun!