Wesnoth 1.9.0

[ivanovic]

This is the first release of the 1.9.x development branch. As with normal development releases, it may include many more bugs than stable releases from the 1.8.x series — additionally, 1.8 content is not compatible with 1.9.x due to the many changes in the game engine and WML syntax between both branches. Don't be disappointed if the game crashes every now and then — "normal" players (those who want 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.9.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 new stable 1.8 branch we added myriads of new things. The huge amount of new terrains and terrain graphics is just the tip of the iceberg. To get an idea about the changed graphics, have a look at the wiki page with screenshots.

There are already some known issues, but let me provide you with a list of great new things first — many of them done as part of Google's Summer of Code program. The known issues come afterwards...

Important changes and new features

[b]New campaign[/b]

A new campaign has entered mainline after being hosted by the Wesnoth-UMC-Dev Project for a few months. It is Dead Water, an intermediate level merfolk campaign with 13 scenarios.

[b]Terrain[/b]

There are many changes and improvements to terrain since 1.8.x. Many of these changes are ongoing, so some terrains are half-baked, but overall the appearance should be much improved.

Highlights

• New animated water and new land-to-water transitions.
  --Note animated water is processor hungry. If Wesnoth is laggy try turning of "animated map" in the "advanced preferences."
• There is a new advanced preferences option, "local time of day light" to activate this area-specific color shift. This will (for instance) only apply the Time of Day color shifting to the non-cave part of properly constructed maps that mix cave and outdoors. (note that it may use more memory in heavier cases like big caves.)
• Cave terrains are no longer extra dark, so they don't clash so much with other terrains. The darkness in underground maps is now supplied by a "time of day" color shift.
• The base terrain beneath land villages can now be changed.
• The color of most terrains have been shifted, so that terrains look like they belong together.
• Many new terrain variants have been added.

Important changes for map conversion

• Cacti and desert decorations: these are now *not* automatically part of Dd (desert). Mapmakers can now apply the embellishment "Desert Plants" (^Edp) over any base terrain, to get the density and placement of cacti that they want.
• Flowers are are now an embellishment overlay (^Efm) "Embellishment, Flowers, Mixed". It can now be mixed with other base terrains. "Ggf" is depreciated. It still exists, but will eventually be removed. For a better appearance, convert to "Gg^Efm", or another base with "^Efm".
• "Desert Road" (Rd) used to be a rather dark and ambiguous dirt terrain. It's now much lighter as is appropriate for very dry dirt, but might have been used elsewhere as a dark terrain — which it no longer is. If you wanted a dark terrain, switch to "Rb" or another terrain type.
• "Rocky Path" (Rp) was intended as an overgrown forest path, but didn't make this very clear and seems to be often used for plain grey cobbles. It is now really overgrown. If that's not what you want, use Rrc or another flat terrain.

New cave variants
There is a new cave floor and 3 new cave walls. Currently these are not very distinct, due to time constraints. The following is what they will look like in a later release:

• Hewn Cave Wall (Xuc) A wall roughly hewn from natural stone
• Earthy Cave Floor (Uue) Soil and Stones mixed together. Maybe some roots.
• Earthy Cave Wall (Xue) Soil and Stones mixed together. Maybe some roots.
• Earthy Hewn Cave Wall (Xuec) Wooden Beam support the walls, as in a mine.

Warning
The stone walls with pillars and bricks (Xos, Xol) are attractive, but built in a way that makes them extremely difficult to mesh with other terrains. These will likely be remade for a future development release, so custom terrains or scenery items will likely no longer work quite right with them.

[b]Network[/b]

The entire network module has been rewritten using Boost's asio library as part of a GSoC 2010 project by Guillermo Biset (billynux.)

The work was divided into two parts:

• Writing a library to help develop asynchronous sever and client network applications.
• Rewriting the Wesnoth network implementation to use this library.

ANA
ANA (which stands for Asynchronous Network API) is an API and library to help developers code their own server and client applications without having to deal with the many details of network programming.

ANA is implemented with Boost's Asynchronous Input/Output Library (asio) and features a natural asynchronous (i.e. non blocking) model of computation. One important feature that must be taken into account is the fact that the flow of control is reversed from synchronous implementation of network applications.
In our particular case, old implementations for users of network features would constantly poll the network implementation questioning whether some event had occurred. Now, it is the network module (the ANA library) that will invoke a given handler to let the user know of an event.
You can find out more about what ANA is and what it's good for if you compile the LaTeX document contained in doc/ana/ and you can check out the API and implementation details in the doxygen generated documentation (e.g. run "doxygen Doxyfile" in src/ana/.)

Network implementation
The new network implementation uses the ANA library, and the old network API (network.hpp) is mapped to a network manager that is the handler for the events generated by ANA. Even though from the user's perspective control flow still remains the same, some simplicity and overall performance has been achieved.

New Network Implementation Proposal
A new network API was proposed in network_async.hpp, however it was judged that rewriting the existent network user's code to accommodate this new API must be a thoroughly thought through endeavor and was thus postponed to better wrap up the GSoC project.

[b]Planning system/Whiteboard[/b]

A brand new move planning system codenamed "Whiteboard" has been developed as a Google Summer of Code 2010 project by Gabriel Morin (gabba). Its purpose is to visually test out several possible move (/attack/recruit/recall) combinations, check out the possible enemy moves for each one, and then execute the planned moves of your choice with the press of a key. Out-of-turn planning is also supported, so you can finally fine-tune your recruits and recalls or lay out some basic moves while waiting for your turn.

This planning system is also destined to replace eventually Delay Shroud Updates, which is giving headaches to C++ coders and WML developers alike. Therefore DSU has been disabled in this release so the whiteboard's worth as a replacement can be determined. Your testing and feedback in this area is particularly needed and appreciated.

Commands
To turn the planning system on and off, use the shift+p hotkey (configurable), the checkbox in the right-click or Actions menu, or finally type the :wb command. There is an option in Preferences to enable the whiteboard on game start. You can also hold the Tab key as an instant toggle: it allows planning a move when the whiteboard is off, and making a regular move when the whiteboard is on.

Once you have some planned actions defined, readily identifiable by the numbers (and arrows, for moves), you can execute or delete them, or move them up/down the action queue. Numbering matters, since if you're not hovering the mouse over a particular unit or action, the "execute" or "delete" command will target action #1. The current shortcut keys use keys that were free, and are subject to change, but they are currently:

• Execute: y
• Delete: h
• Reorder action up/down: PgUp/PgDown

Limitations

• Out-of-turn planning doesn't reliably work while units are moving. Concretely it works fine for multiplayer games, not so well against the AI since it plays fast.
• Disabling enemy moves tracking might help with out-of-turn planning.
• The planning system hasn't been tested against the whole range of possible WML events, some of them might still cause crashes. However succesful tests included the tutorial, the "test" scenario, Dark Forecast, the first scenario of Legend of Wesmere.
• The sidebar shows unit information only when hovering over the future destination of a unit (for instance, if it has two moves defined, over the second move's ghosted unit), and not over the unit itself, which is not very intuitive.
• There's no interaction between the whiteboard and the game clock, therefore you won't get any time credit for planned moves until they are executed.

Short-term developments
Those are the features planned for the near future:

• Cumulative Battle Statistics and Chance to Kill calculations for multiple attackers.
• A "consider dead" action that allows you to pretend a unit is dead for a moment, and see the effect on pathfinding and Zone of Control.
• Depending on feedback, an "execute all" command allowing you to quickly execute several trivial moves in quick succession.

Long-term developments
The whiteboard has been developed from the start with a networked aspect in mind, eventually allowing your allies to see your planned actions, as well as other interesting features such as suggesting moves and placing label-like symbols on the map. However there is still a lot of work left to get there.

Your testing is needed
Please report bugs on http://bugs.wesnoth.org and assign them to the Item Group "Whiteboard". For general feedback, head over to the Planning System/Whiteboard Feedback Thread in the Multiplayer Development forum.

When reporting bugs, please run wesnoth with the --log-debug=whiteboard command line option, reproduce your bug, and attach the resulting log to your bug report.

[b]Persistant variables in WML[/b]

A new WML feature is now available in Wesnoth - WML variables can now be stored in a persistent way, allowing scenarios to read and write persistent WML variables, both in singleplayer (from local machine) and in multiplayer (from other players across the network). This allows WML authors to store/access persistent data 'in context' of a specific campaign/add-on/group of addons/ group of games, allowing things like 'achievements' or 'massive multiplayer campaigns' to be implemented.

Documentation of this feature is provided at PersistenceWML.

Support for this feature was coded by Jody Northup (Upthorn), during Google Summer of Code 2010.

[b]Wesnoth User made content Eclipse Plugin[/b]

During Google Summer of Code 2010, Timotei Dolean (timotei) has developed the Wesnoth UMC Plugin.

The plugin is something like a WML IDE. Basically it offers you some features that greatly help anybody who makes User made Content in WML:

• It has wizards for new campaign, scenario, faction, era and every other WML tag you can think of. You just complete the needed values and it generates nicely indented WML code.
• It has frontends for launching WML tools (like wmllint, wmlscope, wmlindent on files/directories), the Wesnoth game client, and the Map Editor.
• It has a specialized WML editor, that has syntax highlighting, tag folding and outline, autocompletion, macro "explorer" and so on.
• It has a "upload add-on" feature that uploads the specified project to the addons server.

For details and information on how to install it go to: http://eclipse.wesnoth.org.

[b]Location of userdata[/b]

On X11 systems, Battle for Wesnoth now respects the XDG base directory specification when storing files into the home directory. In particular, unless some custom configuration from the user or the desktop environment is in use, config files will be found in ~/.config/wesnoth, save files and add-ons will be found in ~/.local/share/wesnoth/<version>, and cache files will be found in ~/.cache/wesnoth.

[b]New and changed dependencies[/b]

Lua is no longer an external dependency. It is now included in the src/ directory so that it can be compiled with the same C++ compiler as the engine.

The implementation of the new network module requires:

• Boost.Thread
• Boost.System
• Boost.Asio

All of these libraries should be available as part of Boost 1.35.0 and later, so the Boost version requirement was bumped to >= 1.35.0.

Of course there is also the full changelog listing (almost) all the changes since 1.8. A changelog for the most visible changes for users is the players changelog.

Known Issues (to be fixed in the next release)

• It is currently not possible to connect to the official multiplayer server using Join official server (this currently leads to the game crashing). Instead you have to click on Join server and enter server.wesnoth.org:14997 in there. Reported as bug #16502 [Gna.org]
• Uploading add-ons via the in-game interface causes the game crash. As workaround, use the python tool wesnoth_addon_manager from data/tools/. Reported as bug #16474 [Gna.org].

Downloads

Source code:
http://sourceforge.net/projects/wesnoth ... 2/download (304.0 MB) md5sum
Here is the XDelta for the sources:
http://sourceforge.net/projects/wesnoth ... a/download (1.8.4 to 1.9.0, 36.6 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 MacOSX 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 downloads 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 files through SourceForge.net to help us save bandwidth. Please get the files from SourceForge.net if possible.

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

A new add-ons server for 1.9.x is already running. It was started during the development of 1.9.0. If you encounter any problems with content from the add-ons server 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 post bugs first! Instructions for bug reporting can be found at ReportingBugs. 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...

Bug reports in the forums tend to get forgotten. You will get better results by following the guidelines and report them in the bugtracker.

[ivanovic]

Before someone asks if there will also be a package for the OpenPandora since I created packages for 1.8.3 and 1.8.4 (you can find them on the download page in the wiki.)

It does not look good for this one since the memory usage was increased (at least for a short time while creating caches). We (as the development team) will have a look at this and evaluate if it is possible to reduce the memory usage there, but this won't be backported to 1.9.0 and we have no idea so far when this will be ready. So for the moment Pandora users will have to stay with 1.8.x as well as other users with "not much RAM at all" (the Pandora only has 256MB and no swap).

[Captain_Wrathbow]

Yeehah!! 1.9.0, incredible.
I can't wait to see all the new terrains and other changes.
Downloading now...

[mnewton1]

At the end of the post you ended a wiki tag with [/url] This makes the rest of the post a link to the wiki.

[Zerovirus]

1.9 is incredible, and I just downloaded. Terrain changes are great. Nobody's on the server though, which is to be expected as it's new and the normal server logon is broken. I doubt most of the MP players frequent the forums.

[Captain_Wrathbow]

ARCANE COW!!!!

Wow.
I really just don't know what else to say. Wow.
Wow.
The new terrain is awesome, and I can't wait to see what's next. I can't imagine it getting any better, but I'm sure I'll be proven wrong.
Congrats, this release is unbelievable. I love it.

Thanks for making an incredible game!

[Pentarctagon]

the terrain looks great , though there seems to be a problem with creating the cache. I'll be editing an addon in preparation for 1.9.1 and being able to upload them to the server, and then I'll reload and start getting runtime errors unless i remove the add-ons, reload, put them back, and then it works fine.

[boru]

Of course there is also the full changelog listing (almost) all the changes since 1.8. A changelog for the most visible changes for users is the players changelog.

No mention of the extensive work on saurian animations in either changelog.

The saurians look great, they don't stand still for a second.

Some of the new wolf sound effects are great, but two of the "death" ones sound like a kid in a chocolate bar commercial.

Some minor performance issues with animated water during scrolls in windowed mode. In fullscreen they are fine. I don't think it's enough to file a bug report, might just be my setup here.

[Schierke]

Amazing changes, but having 512 RAM and using MS Windows XP i find 1.9 to be very laggy overall even when i never had any lag problems with BfW before.

Is this something that can be solved in any way or is just a matter of upgrading to something better than this ancient PC?

[zookeeper]

Amazing changes, but having 512 RAM and using MS Windows XP i find 1.9 to be very laggy overall even when i never had any lag problems with BfW before.

Is this something that can be solved in any way or is just a matter of upgrading to something better than this ancient PC?

Well, turn off "animate map" in the advanced preferences first. The animated water is a performance hog.

[Pentarctagon]

even upgrading would have only helped so much, I have a 2.66GHz duo core + 8GB RAM and its still lagging a bit. I looked at task manager while on Cynsaun Battlefield and at times it was using up ~40% of the cpu, and that was when it was just sitting there.
its actually kind of funny to watch the cpu jump up and down when I minimze wesnoth

[Iris]

At the end of the post you ended a wiki tag with [/url] This makes the rest of the post a link to the wiki.

Are you sure? I can't find that.

[Golden_Soldier]

awesome!!!!! the terrain is amazing!!!!!

I cant wait til you add the mud glob and ghast when are those expected to be added

[Iris]

[acronym=It's Ready When It's Ready]IIRWIIR[/acronym]. It all depends on the artists' progress and the approval of the Art Director(s) in charge.

[Golbeeze]

1.9 looks amazing, great job!

Is the "WML Engine" section in the full change log a complete list of alterations to WML usage? If not, is there a list somewhere else? I want to prepare some of my works for the new version and I'm not sure where to find the altered WML (if any).