Wesnoth 1.13.1

Get help with compiling or installing the game, and discuss announcements of new official releases.

Moderator: Forum Moderators

Locked
User avatar
Iris
Site Administrator
Posts: 6797
Joined: November 14th, 2006, 5:54 pm
Location: Chile
Contact:

Wesnoth 1.13.1

Post by Iris »

Wesnoth 1.13.1 is out!

Screenshot Screenshot Screenshot Screenshot

This second release in the 1.13.x development series primarily delivers bug fixes over 1.13.0, as well as a few content creation-oriented features. It also contains the same fixes and improvements found in version 1.12.4, including its security fixes — thus, we urge add-on creators using version 1.13.0 to upgrade immediately.

As this is a development version, we would like to remind everyone how the testing and feedback process works for these:
  • 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 version 1.13.2, 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.
Read on for more details about the most notable fixes and additions in this release:
The following known bugs from version 1.13.0 caused by the SP/MP unification project have been fixed in this release:
  • Default XP modifier for multiplayer games being used in single-player campaigns (bug #23509 [Gna.org]).
  • Random gender assigned to leaders in single-player campaigns even where not requested via WML (bug #23496 [Gna.org]).
  • Random initial time of day schedule applied to scenarios even where not requested via WML (bug #23462 [Gna.org]).
  • Shroud forcefully applied to scenarios during transition (bug #23461 [Gna.org]).
  • Non-standard side colors being unsupported by the game setup code, resulting in RGB #000000 being used instead (bug #23629 [Gna.org]).
  • It is now easier to create multiplayer campaigns because most multiplayer-oriented features like eras and player-defined scenario settings are now disabled by default for campaigns (use force_lock_settings=no to re-enable).
  • [modification] can also be used in single-player mode by default.
  • [modification] now must specify a type=mp/hybrid/sp attribute. [modification] inside an #ifdef MULTIPLAYER block must have type=mp specified.
  • [options] is now recognized in [campaign].
  • The difficulty selection dialog now shows on which difficulty levels a campaign was completed (pull request #403 by abacabadabacaba).
  • [modification] items are displayed at the bottom of the campaigns list.
  • The Advanced Settings button has been removed.
  • [set_menu_item] now has a synced=yes/no attribute, which defaults to yes. If synced=no is specified, the menu item will also be available when it’s not the player’s turn and the results of any actions it executes will not be sent to other clients (which means that you must not change the game state from an unsynced menu item’s commands block).
  • [object] now supports duration=turn end.
  • [label] now supports Standard Location Filters when used in an event handler.
  • [role] is now implemented in Lua (fixes bug #23630 [Gna.org]).
  • New function, wesnoth.get_viewing_side
  • New function, wesnoth.remove_dialog_item
  • ~BW() converts an image to black and white.
  • ~SWAP() swaps the RGBA channels of the image.
  • ~CROP() now supports negative x and y coordinates.
  • ~NEG() can now take 0, 1, or 3 arguments, allowing solarization effects.
Debug commands (e.g. :unit, :shroud, :fog, the Create Unit menu option, and others) are now synchronized between clients in multiplayer mode and in replays, so that they do not cause OOS errors or corrupt replays anymore. Of course, there are now visual notifications for when these are used during a networked game.
This release forces a specific font rendering configuration for Apple OS X and X11-based platforms (e.g., most Linux distributions and BSD derivatives with a graphical user interface), disabling subpixel hinting and using grayscale antialiasing only; this is intended as a work-around for color glitches resulting from incorrect applications of subpixel hinting in the majority of Wesnoth’s user interface components (see bug #20337 [Gna.org]).
The Gamestate Inspector and Lua Console dialogs, as well as the error report dialog used for alerting the user of errors during the WML loading stage, now use a fixed-width font (DejaVu Sans Mono) for displaying debug information. Note that this currently does not work on Apple OS X due to bugs #23560 [Gna.org] and #23628 [Gna.org].
Reading Wesnoth’s stderr output is highly valuable to content creators, especially when debugging WML and Lua code. However, Windows as a platform is not designed to make it easy for anyone to read the console output of a GUI application marked as such. As a result, GUI applications using SDL 1.2 like Wesnoth have their console output redirected to files (stdout.txt and stderr.txt) in the executable’s location.

Wesnoth 1.13.1 introduces a command-line switch, --wconsole, that instructs it to spawn a real Windows console of its own during startup and redirect all output there instead of to stdout.txt and stderr.txt. Due to idiosyncrasies of process handling in Windows’ built-in command prompt shell, it is recommended to use the bundled cwesnoth.cmd wrapper instead, which will additionally pass all its command-line arguments to Wesnoth like so:

Code: Select all

cwesnoth --log-debug=wml --debug
This wrapper also disables the SDL mechanism that creates the log files during initialization, so that existing log files are left intact rather than truncated and subsequently deleted on exit.

The official Windows installer for Wesnoth also creates an additional Start Menu shortcut that enables console mode.

Do note that none of this is required on other platforms such as Linux and Apple OS X, where it is possible to run Wesnoth from a terminal emulator and get its stderr output directly using the operating system’s own facilities.
  • Added generic portraits for the Walking Corpse and Soulless by doofus-01.
  • Fixed HP/XP bars of allied units being drawn over shroud with some side configurations (bug #23460 [Gna.org]).
  • Fixed an unbounded memory read in the MP map selection screen that could result in segmentation faults or abnormal behavior (bug #23606 [Gna.org]).
  • Fixed a segmentation fault caused by the [move_units_fake] WML action.
  • Fixed minimap button glitches in replay mode (bug #23201 [Gna.org], pull request #400 by Randypk).
  • It is no longer possible to undo moves before the last (manual) shroud update (bug #23600 [Gna.org]).
  • It is now possible to use WML to disable/enable quick 4 MP leaders in the Default era and the time over advantage dialog by setting a WML variable.
  • CMake builds now default to non-strict compilation.
  • 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.
  • Shroud can’t be placed on hexes where units on allied teams have vision (bug #23458 [Gna.org]).
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.
  • 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.
  • 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.
[/list]
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 the current stable 1.12.x series instead. However, if you want to help us test what will eventually become the next stable 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. Content authors 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.


Contributors

This release includes contributions from abacabadabacaba and Randypk, submitted via pull request on GitHub.

Do you want to help shape the future of Wesnoth? You are always free to join us in the #wesnoth-dev IRC channel on irc.freenode.net to ask for help with getting started!


Downloads
A package for Microsoft Windows is already available:
UPDATE 2015-07-09: A package for Apple OS X is now available.
Apple OS X 10.10 (412.3 MB)
All known Linux packagers 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 for other platforms may be found on the Download page in the wiki as they become available.
The multiplayer server for 1.13.x is up and running. This server can only be used to play with other players running the latest development version.

The add-ons server for 1.13.x is already running. It was started for 1.13.0 and it serves all development releases from this series.
If you encounter any problems involving add-ons not working as expected, please notify the content’s author or maintainer.

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!
Author of the unofficial UtBS sequels Invasion from the Unknown and After the Storm.
User avatar
StandYourGround
Posts: 256
Joined: May 13th, 2009, 2:16 am
Location: On a blue ball spinning through space at incomprehensible speed

Re: Wesnoth 1.13.1

Post by StandYourGround »

Built from homebrew, running a certain beta of a not-yet-released Mac OS X... Runs great, possibly even faster than 1.12. However, the graphics leave something to be desired:
expand to see screenshot:
I should note that 1.12 does not exhibit any of these graphical issues at all.
I will now resume lurking silently.
User avatar
Pentarctagon
Project Manager
Posts: 5527
Joined: March 22nd, 2009, 10:50 pm
Location: Earth (occasionally)

Re: Wesnoth 1.13.1

Post by Pentarctagon »

On Windows 7, using the new [set_menu_item] synced=no key causes the menu to not open if there is only 1 side. There are no errors in the stderr.txt.
99 little bugs in the code, 99 little bugs
take one down, patch it around
-2,147,483,648 little bugs in the code
gfgtdf
Developer
Posts: 1432
Joined: February 10th, 2013, 2:25 pm

Re: Wesnoth 1.13.1

Post by gfgtdf »

Pentarctagon wrote:On Windows 7, using the new [set_menu_item] synced=no key causes the menu to not open if there is only 1 side. There are no errors in the stderr.txt.
You mean only one human side or just only one side in total?

I just looked at the code again and it its possible that synced=no keys are not accessible to other sides that the currenty playing side via right click menu, (but they are via hotkeys)
Scenario with Robots SP scenario (1.11/1.12), allows you to build your units with components, PYR No preperation turn 1.12 mp-mod that allows you to select your units immideately after the game begins.
User avatar
Pentarctagon
Project Manager
Posts: 5527
Joined: March 22nd, 2009, 10:50 pm
Location: Earth (occasionally)

Re: Wesnoth 1.13.1

Post by Pentarctagon »

I had tried with only 1 side total, but the menu also does not open when there is only 1 human side whether by the right-click menu or with a hotkey even on my turn.

Also to clarify: when I say it does not open, I mean the icon in the right-click menu is there but clicking it does nothing.
99 little bugs in the code, 99 little bugs
take one down, patch it around
-2,147,483,648 little bugs in the code
gfgtdf
Developer
Posts: 1432
Joined: February 10th, 2013, 2:25 pm

Re: Wesnoth 1.13.1

Post by gfgtdf »

ok idebugged tis issue and it seems liek the frong event is fired. menu items than an id 'item_id' should usually fire the event with the name 'menu_item item_id' for due toa bug unsyced menu items foire the event this teh name 'item_id'. Will be fixed in next version
Scenario with Robots SP scenario (1.11/1.12), allows you to build your units with components, PYR No preperation turn 1.12 mp-mod that allows you to select your units immideately after the game begins.
User avatar
Pentarctagon
Project Manager
Posts: 5527
Joined: March 22nd, 2009, 10:50 pm
Location: Earth (occasionally)

Re: Wesnoth 1.13.1

Post by Pentarctagon »

Sweet. And thanks for implementing this, if it works like I think it works then it'll be a very nice solution to a problem I've been avoiding for a while.
99 little bugs in the code, 99 little bugs
take one down, patch it around
-2,147,483,648 little bugs in the code
User avatar
ancestral
Inactive Developer
Posts: 1108
Joined: August 1st, 2006, 5:29 am
Location: Motion City

Re: Wesnoth 1.13.1

Post by ancestral »

The package for OS X is ready. At this time, it is a 10.10 Yosemite-only binary.

If you are running a different version of OS X, you can make this download work by building your own version of pango, and replacing the pango folder in the application. (You can build pango with homebrew by typing the command brew install pango --without-x11 and then copying /usr/local/Cellar/pango/1.36.8_1/lib/pango/1.8.0 into Wesnoth.app/Contents/Resources/pango/ .)

Please note that starting with 1.13, Wesnoth is no longer officially supported on PowerPC processors.
Wesnoth BestiaryPREVIEW IT HERE )
Unit tree and stat browser
CanvasPREVIEW IT HERE )
Exp. map viewer
User avatar
Inky
Forum Moderator
Posts: 527
Joined: September 22nd, 2014, 1:02 am
Location: USA

Re: Wesnoth 1.13.1

Post by Inky »

Hello,
I took a quick look through Legend of Wesmere using debug; it seems that LoW in 1.13 is missing all the changes that were made in 1.12?
e.g. Units and labels being out of place (scenario 3 is a particular example), Scenario 14 human alliance is the older version, etc.

Also, when starting a scenario which begins a new chapter (e.g. scenario 9) in single player, a dialogue about making lobby game will appear asking you to configure the sides; if you press ok it works as normal and if you press cancel the campaign just quits.
gfgtdf
Developer
Posts: 1432
Joined: February 10th, 2013, 2:25 pm

Re: Wesnoth 1.13.1

Post by gfgtdf »

Inky wrote:Hello,
I took a quick look through Legend of Wesmere using debug; it seems that LoW in 1.13 is missing all the changes that were made in 1.12?
e.g. Units and labels being out of place (scenario 3 is a particular example), Scenario 14 human alliance is the older version, etc.
This is fixed in 1.13.2 which will be released soon.
Inky wrote: Also, when starting a scenario which begins a new chapter (e.g. scenario 9) in single player, a dialogue about making lobby game will appear asking you to configure the sides; if you press ok it works as normal and if you press cancel the campaign just quits.
I am not 100% sure but i guess this is also already fixed in wesnoth 1.13.2 If not please provicde more information: Did you start the game in debug mode(or did you activate the debug mode ingame with :debug) ? Did you modify the sceanriofiles of LoW campaign?
Scenario with Robots SP scenario (1.11/1.12), allows you to build your units with components, PYR No preperation turn 1.12 mp-mod that allows you to select your units immideately after the game begins.
Locked