Wesnoth 1.11.0

[ivanovic]

Wesnoth 1.11.0 is out!

This is the first release of the 1.11.x development branch. As with normal development releases, it may include many more bugs than stable releases from the 1.10.x series — additionally, 1.10 content might not be compatible with 1.11.x due to many changes in the game engine and WML syntax between both branches.

Don’t be disappointed if the game crashes every now and then — regular players wanting a stable gaming experience should not use this release, and stick to the stable branch instead. However, if you want to test the future of Wesnoth and help us find bugs early, you are welcome to check out 1.11.0. We require your help for finding and fixing issues. If you find a bug, please do not assume that it is so obvious that we already know about it. Report it and make sure that we are aware of it.

Since the release of the stable 1.10 branch we added myriads of new things. For instance, the editor was significantly improved to increase usability. Thanks to Google Summer of Code this release also features some nice enhancements regarding the AI; the whiteboard saw some significant improvements as well. A little below you will find a list of some of the most noteworthy changes, though sadly many are missing there. And of course, all bugfixes and improvements implemented in later 1.10.x releases are also part of this version.

As usual, there is the full changelog listing (almost) all changes since 1.10. There’s also an alternative players changelog including only notable, user-visible changes.

Important changes and new features

Add-ons manager dialog

The old Get Add-ons and Update Add-ons dialogs have been merged for this release into a single Add-ons Manager view with some new features and changes.

• It’s now possible to filter the list further choosing the Options button on the top-right corner. At this time, the additional options offered allow displaying only add-ons of specific types (e.g. campaigns, map-packs, eras) and installation status. In particular, you can choose to display only Upgradable add-ons to get an equivalent view to the previous Update Add-ons dialog.
• Add-on installation status is now displayed beneath each list entry in color.
• Old and new add-on versions are listed in the Version column when applicable.
• Add-ons are no longer sorted by original upload time in descending order by default. Instead, add-ons are sorted by name. An option to sort them by upload time may be implemented in the future depending on the perceived impact of this change.
• The dependency installation prompt now resolves all possible dependencies recursively and lists them together.
• Add-on filter options are remembered while installing individual add-ons until the user chooses to return to the titlescreen.
• Text formatting markup (any of *, `, ~, {, ^, }, |, @, #, <, & at the start of a name) cannot be abused to color add-on names in the Add-ons Manager anymore. Additionally, new add-on server instances will reject add-ons with such names.
• Column extents have been tweaked in an attempt to suit ‘average’ cases (based on the 1.10 add-ons server contents) better.
• A Help button has been added along with a dedicated section in the Help.

Under the Burning Suns

The campaign Under the Burning Suns has had extensive code changes. While most of them should not be visible, there are several changes that affect difficulty.

• In scenario 2, if healers are preventing dehydration in units, they are now unable to also heal them. This makes the elves unhealable during daytime, except in oases.
• The first tunnel collapse in scenario 6b, “In the Domain of the Dwarves”, no longer kills both guards.
• The AI behavior for the messenger in scenario 8, “Out of the Frying Pan”, has been much improved.
• The chest at the end of the cave in scenario 8 now grants more gold on easy difficulties than hard and the amount will always take you to positive gold.
• There are scattered small changes that make the hardest difficulty slightly harder.

Players are encouraged to try these scenarios and comment on the difficulty changes.

Lua updated to 5.2

Lua interpreter was updated to 5.2
The Lua interpreter was updated to version 5.2. Some of the changes in this version break old code; other changes will still work with old code due to compatibility mode, which will be disabled after several minor releases. See the full Lua 5.2 incompatibilities list for more details and information about updating old code.

Removed deprecated terrains

The old grassland flowers terrain (Ggf) has been removed in favor of ^Efm, introduced during the 1.9 development series. Maps containing the old terrain will no longer load.

CMake: compiler flags, installation changes, and Clang

• The code to determine compiler flags has been rewritten and now has better support for compiler-specific enabling of targets. Therefore it is recommended to regenerate your CMake build.
• Default manual page installation directory now conforms to FHS.
• The Clang compiler now also defaults to strict compilation when building with CMake. Additionally, the default flags have changed to match the ones used for GCC. This has only be tested with Clang 3.1; please file bug reports if it breaks older versions of Clang.

Known Issues (might be fixed in the next release(s))

There are no known issues at the moment.

Downloads

Source code:
http://sourceforge.net/projects/wesnoth/files/wesnoth/wesnoth-1.11.0/wesnoth-1.11.0.tar.bz2/download (334.1 MB) md5sum
Here is the XDelta for the sources:
http://sourceforge.net/projects/wesnoth/files/wesnoth/wesnoth-1.11.0/wesnoth-1.10.4.tar-wesnoth-1.11.0.tar.xdelta/download (1.10.4 to 1.11.0, 19.4 MB)
Check http://forums.wesnoth.org/viewtopic.php?t=7034 for information on using XDelta.

The Windows package is already available. You can find it on the download page.

The Mac OS X package is already available. You can find it on the download page.

The OpenPandora package is already available. You can find it on the download page.

Many of the Linux packages have already been created, and all known packagers have been contacted. Information about where to get the respective binaries or how to get them to work can be found in the Linux binaries page in the wiki. Download links for other supported systems will be available at the download page once the packages are created and published.

As a fallback you can also get the sources from http://files.wesnoth.org/ — but you should first try to get the files through SourceForge.net to help us save bandwidth. Please get the files from SourceForge.net if possible.

The multiplayer server for 1.11.0 is up and running. This server can only be used to play with other users of 1.11.0. If you do encounter problems, please report them.

The add-ons server for 1.11.x is already running. It was started with the release of 1.11.0 and it serves content for all 1.11.x versions. If you encounter any problems with add-ons not working as expected, please notify the content’s author — most of them should be here in the Scenario & Campaign Development forum.

If you find any bugs, don’t hesitate to report them, but please read the instructions on how to report bugs first! As bug reports in the forums tend not to be forgotten, you will get better results using the official bug tracker. Again, we require your help for finding and fixing issues, no matter how trivial or complicated they are!

Enjoy!

PS: Within the next seven days anyone asking when the binary for xyz will be ready will be banned and the post will be deleted. Such questions just distract the developers and packagers and don’t do any good, so better not ask them...

[shadowmaster]

It's good to hear that 1.11 is released. Best of luck, devs!

[Lord-Knightmare]

Finally! I have awaited an eternity for this version.
Can't wait to try out the new features...

[cKomuHKa]

still can't play: viewtopic.php?f=4&t=37066

[Radh]

Very excited to play this! Congratulations on getting it out, guys!

[Jozrael]

Hurrah! Congrats all!

[Raychu]

Worth of waiting.

[PawelS]

From the players changelog:

* New tropical frost images.

I like oxymorons, but this seems to be a mistake

[tr0ll]

From the players changelog:

* New tropical frost images.

I like oxymorons, but this seems to be a mistake

on the contrary it sounds like a manifestation of evil can't wait to try a campaign which uses that!

btw 1.11.0 is working great for me (linux)! not many add-ons yet but i expect they will come as developers have time and as this cycle passes the alpha stage.

[Krake]

The scepter of fire campaign seem to end after gathering minerals scenario.

[doofus-01]

Hi,

Is it a known issue that the [set_variable] ... rand=... WML doesn't produce random variables anymore?
For example
[set_variable]
name=whatever
rand=1..15
[/set_variable]
will produce, reliably, as the parent event is triggered multiple times in the scenario, values of 10->1->12->4. Or something like that. Point is, the sequence may be random, but it is a set sequence for that scenario. When the variable is set, it is not random, it is just the next number in the sequence.

This did not happen in 1.10.0 (I don't know about other 1.10.x). Seems like a big bug, if it is a bug with RNG, but I did not see anything in the bug-tracker. Maybe I missed it, or it is just a problem with my system (openSUSE 11.3, BfW installed w/ default scons options).

Thanks.

[JaMiT]

Is it a known issue that the [set_variable] ... rand=... WML doesn't produce random variables anymore?

It is working fine for me. Ran a campaign multiple times, and got a different random sequence each time. (Also tried loading a save mid-sequence, and the tail of the sequence changed.) Maybe post your event in the WML workshop so someone can figure out what is going on (or post in tech support if you believe this to be a problem on your system, rather than a WML problem)?

[doofus-01]

Thanks for taking a look. I have no error messages, so I have no idea how to ask for help in those other forums. And it doesn't sound like you really tested what I was asking, I may not have been clear. Please try the attached test campaign.

Test_Campaign.tgz

(1.77 KiB) Downloaded 292 times

You will randomly be taken to a random (and short) scenario when the spearman moves. In the random scenario, you take one move and will be sent back to the first scenario, where the process repeats.

If it is working, like such things used to work in 1.10.0, the random scenarios will have different maps and names (or if you want to use :inspect, the variable tc_scenario should have a random value with every moveto).

If it is not working for you, like it is not working for me, you will always be taken to the same "random" scenario (and tc_scenario will have the same sequence as you move on the first map). Starting the campaign over yields a different sequence, but that is not helpful.
EDIT: I have filed a bug report: http://gna.org/bugs/index.php?20266

[Anonymissimus]

Are you really sure that it hasn't already been that way ?
I recall that when reloading a start-of-scenario save, and then calling set_variable's rand=, this leads to always the same sequence, since the random seed is stored with that savegame. It can only be changed if some other call to the same random generator happens...generating traits on a recruited unit I think, for example.
Changing something in that area is dangerous, as it can easily lead to OOS bugs in multiplayer, and fixing this perhaps "unfixes" another problem whose fix is causing it....

However, here's the main point of my post: add-on authors aren't forced to use set_variable's rand= for randomization, there's also lua's math.random, look at the tag random_number from the wesnoth lua pack on how to do it. The disadvantage is (IIRC) that that method doesn't work previously to the turn 1 event, but it doesn't suffer from this seeding effect.

[doofus-01]

Are you really sure that it hasn't already been that way ?

Absolutely,100% sure, at least up to 1.10.0.

I recall that when reloading a start-of-scenario save, and then calling set_variable's rand=, this leads to always the same sequence, since the random seed is stored with that savegame. It can only be changed if some other call to the same random generator happens...generating traits on a recruited unit I think, for example.
Changing something in that area is dangerous, as it can easily lead to OOS bugs in multiplayer, and fixing this perhaps "unfixes" another problem whose fix is causing it....

Does this really have anything to do with loading a saved game? Maybe it does, but that's not obvious to me. (Or maybe I am still not being clear enough? Try that test campaign without reloading, just play the repetitive scenarios.) From the player's perspective, whatever the truth in the code, this has nothing to do with loading a save-game.

However, here's the main point of my post: add-on authors aren't forced to use set_variable's rand= for randomization, there's also lua's math.random, look at the tag random_number from the wesnoth lua pack on how to do it. The disadvantage is (IIRC) that that method doesn't work previously to the turn 1 event, but it doesn't suffer from this seeding effect.

I guess I will have to try that, thanks.
EDIT:Using that LUA function does indeed restore the functionality that was removed some time after 1.10.0. This is the same test campaign, with the random behaviour restored, for those of you who read this but did not want to re-install BfW 1.10.0: