Back in September, I said:

I did some math thing. It seems that if I keep working on AtS 0.9.0 at constant speed it will be finished around March 2013. #Wesnoth

The plan has not changed.

Just as irker’s adoption rate is increasing, I have just completed work on a very simple application for Subversion repositories — two applications, in fact.

irker-svnpoller is a very simple script that polls a single commit log (not data) from a Subversion repository and delivers notifications to any number of channels using an irkerd running on the same host. It mimics the CIA bots’ formatting, much like nenolod’s irker CIA proxy, from which I borrowed a small amount of code.

irker-svnpoller → irkerd

But exactly how is this supposed to be useful to anyone, you may be wondering right now? Well, irker-svnpoller is not really intended to be used stand-alone. A timed poller script that tracks the last notified revision could come in handy, but people could get impatient waiting for their commits to appear in their IRC channels minutes later. I am well familiarized with the defects, quirks, and virtues of my primary audience—the Battle for Wesnoth and Wesnoth-UMC-Dev projects—and this approach would simply not scale well over time.

Enter the first companion script, svnmail-filter. It reads email message headers from stdin to determine a commit’s revision number and the pertinent repository to probe using irker-svnpoller. Configuration is mostly done through a ruleset file using the JSON format.

Of course, svnmail-filter is not that useful on its own either. The idea is that procmail or some other MDA should pipe incoming email headers through svnmail-filter — and preferably, only those from legitimate sources, such as subscribed commit mailing lists. This is actually simpler than it sounds, and it is more or less inspired by CIA.vc’s perpetually broken mail-based SVN poller.

MDA → svnmail-filter → irker-svnpoller → irkerd

Since no service in the pipeline other than irkerd runs persistently in the background, this should be significantly more fault-resilient than CIA.vc’s approach, which apparently required a poller service to listen and act upon local requests. The downside is that the host running irker-svnpoller may need to create many short-lived SVN repository connections for individual commits in a chain. In Wesnoth’s case, SVN commit chains are rare enough, but their size often goes around a dozen individual commits or so. Regardless, this shouldn’t be terribly concerning for a production server with a decent low-latency uplink, and the overhead on the repository provider should be rather small compared to pushing massive commit diffs across the network.

Right now, the Wesnoth and Wesnoth-UMC-Dev projects are using this service as a stopgap measure until their respective providers—Gna.org and SourceForge.net—allow installing a hook that can either talk directly to an irkerd server, or to an instance of the aforementioned CIA proxy using the CIA XML-RPC method.

I am not all that keen on other people using a piece of software I developed and tested within less than three days without any prior experience working with Python. There are also various problems inherent to any application depending upon Subversion and its incompetent network transport layer.

Nonetheless, I published a Git repository on GitHub including a small amount of documentation to get started:

• shikadiqueen/irker-svnpoller on GitHub

I am open to possible improvements coming from people intending to use this on production servers. In particular, if someone out there works with a commit mailing list where revision numbers can’t be found in mail subjects it would be necessary to adapt svnmail-filter a little to handle that case. Perhaps it might even be possible to skip the irker-svnpoller step for mailing lists where the notification message structure is constant and well documented.

A new release of Wesnoth RCX is now available for download!

Downloads

• Source code: wesnoth-rcx-0.2.1.tar.bz2 (Bzip2 tarball, 106.8 KiB)
  SHA1 checksum: ed114fb2776254a89491c0c014efb6da500693e0
• Windows: wesnoth-rcx-0.2.1-win32.zip (Zip archive, 4.9 MiB)
  SHA1 checksum: e6ed82f6a914d52a799527637562bfb4f5baa61b
• Mac OS X: wesnoth-rcx-0.2.1.dmg (Application image, 16.7 MiB)
  SHA1 checksum: 221c0006ce8beed5d81f4a9637629a12d4fe0730
  Contributed by Alarantalara.

New in this version

Shortly after 0.2.0 was released, it was brought to my attention that it wouldn’t compile against Qt versions older than 4.8.0, even though the documentation says it should work with version 4.6.0 and later. I quickly amended that and published a patch (found amongst the 0.2.0 downloads in the previous announcement) addressing those issues. That patch is obviously no longer necessary, since the compatibility changes are integrated in 0.2.1 and later. Furthermore, I now have easy access to a build environment using 4.6 to ensure such a situation does not occur again.

A well known issue at the time 0.2.0 was released was some rather excessive memory usage when zooming in, especially for large pictures. 0.2.1 solves this by using a more conservative approach for zooming; in a particular case this decreases memory usage from around 1.1 GiB to just around 50 MiB.

Wesnoth RCX now remembers the main window size and the preview background color each time. Additionally, it’s now possible to apply TC to a whole color palette in the Palette Editor dialog, using the new Recolor option.

Finally, a few minor interaction issues were fixed in this release, including the Add from List option (Palette Editor) being available and non-functional when no palettes are selected.

Feedback

Bugs and feature requests should preferably be posted to the issues tracker at Github so I don’t have a chance to forget about them.

Of course, as usual you can provide other kinds of feedback through the Wesnoth.org forum topic and this announcement post. It would be nice to hear from you if you use this software, regardless of whether you liked it or not — any feedback is appreciated here.

•••

Go test and create, and have lots of fun!

The new major feature release of Wesnoth RCX is now available for download!

Downloads

• Source code: wesnoth-rcx-0.2.0.tar.bz2 (Bzip2 tarball, 103.3 KiB)
  SHA1 checksum: 158f0f8e98aeb852e6265aa8cae83a3f01454f38
• Windows: wesnoth-rcx-0.2.0-win32.zip (Zip archive, 5.0 MiB)
  SHA1 checksum: 14d2fb244ff1f45968d9104b55013f43a95f451a
• Mac OS X: wesnoth-rcx-0.2.0.dmg (Application disk image, 17.4 MiB)
  SHA1 checksum: 2d8221a6002d37cc352cfa2a67938afd7b9596e3
  Provided by Alarantalara.
• Patch: qt-4.6-4.7-compatibility.patch (Source code patch, 6.5 KiB)
  SHA1 checksum: e9e800c98bdb79c234d536277bfb5d3ea9014a89
  You only need to apply this patch if you are building version 0.2.0 from source using Qt 4.6.x or 4.7.x. Run qmake -v in the console to see the Qt version in use.

The project page on this very site has been updated accordingly, and split from the main Wesnoth-TC page.

New in this version

One year and nearly eight months have passed since the last release, version 0.1.4. There was very little activity for most of the time until July this very year, although the primary release goals had already been long established.

The new built-in palette and color range editors allow creating and modifying these items for the game’s recoloring engine with ease, as well as generating WML definitions for your use in add-on production and testing. Various user interface improvements and additions, such as a Recent Files section and a Reload action, allow for a smoother workflow. The redesigned main window now supports scrolling large and zoomed-in images, as well as dragging any of the previews to other applications accepting graphic drops, such as the GIMP.

This version also sees the addition of menu options to change the preview background color, cleaner file output notifications, an enhanced Windows build process with embedded version and icon attributes, and a simple make install target for Linux/X11 users building from source. The included documentation has been improved in this release as well.

Known issues

Some of the known issues with this release are mentioned in the BUGS file included in the source code tarball; other issues have been fixed after the release, in the master branch in the public Git repository.

• The unmodified 0.2.0 source code distribution will not build using Qt 4.6 or 4.7 without the patch provided in the Downloads section above. This issue was—rather unfortunately—discovered after the release was tagged. The fix has been committed to Git already.
• Zooming in requires extremely large amounts of CPU time and memory, especially for images larger than 72x72 pixels at zoom levels greater than 200%. It’s advised that you avoid zooming in unless you have at least 2 GiB of RAM available.
• Zooming does not preserve the current viewport, indiscriminately recentering it instead.
• The preview background color choice is not persistent across re-runs. This has been solved in Git already.
• The dialog shown by the Add from List option in the Palette Editor may have the help text cut off depending on your display and font configuration.
• Dragging previews is not always possible on Linux/X11, depending on the Qt 4 style engine in use. A workaround has been implemented for the Oxygen style (KDE workspace default), but other styles that allow dragging windows from empty areas may ‘steal’ Wesnoth RCX’s events.
• Dragging previews to Windows Paint does not currently work, presumably because the application expects to get access to a file on disk. Since Wesnoth RCX does not store the recolored image on disk until the user requests it, this problem might be impossible to fix.
• The Windows build might occasionally crash during the initial file open dialog, apparently whenever a directory takes too long to display. This does not seem to happen later during execution.
• The Windows build might display occasional minor glitches with mouse-over decorations on buttons and radio/checkboxes when running on Windows XP with styles supporting them (e.g the default Luna style).
• The Add from List button in the Palette Editor remains enabled at times when it cannot do anything useful (e.g. when there are no palettes to select and edit). This has been solved in Git already.

Feedback

With the move to Github came a few goodies; in particular, there is now an official tracker for bugs and feature requests for those who desire a better, supported alternative to the Wesnoth.org forum topic and these blog announcements.

As usual, you can also provide other kinds of feedback through those two aforementioned channels. It would be nice to hear from you if you use this software, regardless of whether you liked it or not — any feedback is appreciated here.

Finally

One problem in terms of development and testing is that I do not currently own a Mac machine, nor do I really intend to. This means I have to rely on certain assumptions and avoid doing anything too crazy that is not guaranteed to work on all platforms or—in particular—widget style engines. So far this appears to have worked fine, thanks to Qt’s cross-platform design.

The Windows (Win32) build has been tested much better in that regard, since my current development machine also functions as a decent VirtualBox VM host. I have gone to rather great lengths this time to improve the build by adding some embedded information to blend better with the environment, and including the Qt library in the wesnoth-rcx.exe executable itself, thus removing the need for two DLLs in the distribution.

Testing on Windows and Mac OS X feels really important to me, given my target audience; most artists seem to prefer these mostly hassle-free operating systems, and I fully respect that choice. My goal is to reach as many artists as possible with a useful and powerful tool that does not get in the way of the creative process, unlike the Wesnoth game proper, so it’s important to ensure a minimum quality level for each release that is consistent across the three main supported platforms.

I have done a lot of work coding and testing this release on Linux (Debian wheezy), Windows XP, and Windows 7, and I hope there aren’t any showstoppers left in this version. However, as you can see above, there is still quite a lot left to do in terms of polishing. Depending on feedback, a new 0.2.1 release might be published in the upcoming weeks. However, many of the remaining bugs require more meticulous inspection and extensive design changes; those will not happen until 0.3.0.

In the meantime, go test and create, and have lots of fun!

UPDATE 2012-08-15: the Mac OS X binary is up now.

Wesnoth-TC 1.5.1 has just been released... or maybe not. It has actually been tagged for more than 24 hours already.

This version is really just a bug-fix release, which is why it’s not 1.6.0. In fact, it only really addresses some build-time issues that have cropped up over the last couple of years.

Downloads

• Source code: wesnoth-tc-1.5.1.tar.bz2 (156.2 KiB)
  SHA1 checksum: f9be5147991719b114046e0573d46ca39479ce69
• Windows (Win32) binary: wesnoth-tc-1.5.1-win32.zip (383.6 KiB)
  SHA1 checksum: b74f26ea3743917433be4f3ca0c0be1a5647b40b

Instructions

Both distributions come with a README file, and the source code distribution also includes an INSTALL file with detailed instructions for configuring, compiling and installing Wesnoth-TC. The Windows binary distribution doesn't require any installation besides unpacking it into an appropriate directory — which you may optionally add to PATH.

The past, and the future

Long ago, this came into existence. At the time, I needed a quick way to preview my own team-colored unit sprites without going through the hassle of starting/restarting Wesnoth (or its internal cache), loading a saved game, and creating units in debug-mode. That was my initial motivation for writing Wesnoth-TC, and since it was tailored to my specific needs, it was born as a console application. I later decided to publish and extend it, hoping that someone else would provide a good full-featured user interface for it.

Actual artists prefer using graphical user interface applications on Windows and Mac OS X, and with good reason. That’s the software interaction paradigm that suits visual types better for obvious reasons, and that’s why I took it upon myself to write a larger GUI front-end for Wesnoth-TC that could be built and run on the three major platforms from a single code-base.

That front-end quickly became an adaptation of the original back-end code. And thus Wesnoth RCX became an entirely separate project sharing little more than a bit of history with Wesnoth-TC. And most importantly, Wesnoth RCX became the first GUI (Qt 4) application I have ever written.

Over time, my needs and personal preferences have changed. Wesnoth-TC now feels largely inferior to RCX merely because of the lack of a native front-end for it. RCX has also recently gained visual palette and color range editing capabilities, which renders Wesnoth-TC’s definition file system somewhat obsolete. Furthermore, RCX has continued to compile and run correctly over time regardless of the Qt 4 version currently installed, whereas Wesnoth-TC has broken in a few occasions with newer development environments.

Wesnoth-TC truly feels like a relic now, one I don’t really want to continue developing at this time when I feel RCX is more fun to improve and work with. I had plans to eventually integrate a full-fledged implementation of the Wesnoth Image Path Functions mechanism, but that seems over-ambitious right now.

So, yeah, Wesnoth RCX is the future. Stay tuned for version 0.2.0, coming soon with more features and improvements.

I have just finished moving Wesnoth-TC and Wesnoth RCX to Github — in my humble uneducated non-expert opinion, a much nicer place to be than Gitorious, which still lacks native CIA.vc support after all these years. Instead, Github supports CIA.vc and a large amount of alternatives which I’ll probably never use.

The project page on this website has been updated accordingly. If you were tracking the repositories at Gitorious, you will not be able to get further updates unless you update your configuration to point to the new locations:

• Wesnoth-TC:
  HTTP transport:

  https://github.com/shikadiqueen/wesnoth-tc.git

  Git transport:

  git://github.com/shikadiqueen/wesnoth-tc.git

• Wesnoth RCX (codename Morning Star):
  HTTP transport:

  https://github.com/shikadiqueen/morningstar.git

  Git transport:

  git://github.com/shikadiqueen/morningstar.git

Updating client repositories is actually far easier than it sounds:

$ git remote set-url origin <new URL>

Afterwards, you should be able to fetch/pull as usual.

This switch actually began some time ago when I was considering resuming Wesnoth RCX’s development (which stagnated ‘some’ time ago too). It took a while, but I finally seem to be back on track, all thanks to my currently unannounced self-imposed campaign development break — a break that should allow me to get back to business soon enough, with the renewed energy and coder momentum I will seriously need in order to pull *it* off.

Wesnoth RCX 0.2.0 will probably be released before the end of this week, as soon as I make sure everything works as intended, which will be less trivial this time due to the new shiny features it packs. There’s also a couple of Windows-specific oddities that I want to tackle before releasing.

Oh, and in the meantime there will be an update regarding Wesnoth-TC’s future.

Version 0.8.1 is out, right on schedule!

Just like the last time, this version will definitely not be exempt of flaws. You will most likely stumble upon dreadful bugs along the way, and I will need your help to fix them — make sure to report them in the campaign’s forum topic as usual!

Special thanks go to bumbadadabum for kindly providing a patch to integrate the changes to the Aragwaithi faction from his multiplayer add-on (The Aragwaithi in the 1.10 add-ons server) into AtS. 0.8.0 users shouldn’t have any game-breaking problems playing with their old units from saved games of E3S3 (Amidst the Ruins of Glamdrol), although some animations may not display correctly. If in doubt, restart from the start-of-scenario save for E3S3.

Also note that due to an internal change, if you load the start-of-scenario save for E3S4 (Outpost of Hell) from version 0.8.0, you will see the loadscreen twice. This is normal and intended, and only affects old saved games for that scenario.

This release is a turning point for various reasons I had already explained a while ago. The good thing is that once scenarios stop landing in SVN, I no longer need to worry about release schedules and pacing. I can now start pushing bug-fix releases as necessary, without affecting the development of the campaign finale.

It is also a turning point in other senses that attentive players will most certainly realize on their own. But in case someone feels disappointed by certain developments: I left enough clues scattered everywhere before, and everything is going according to plan. The bottom line is: if you don’t like the story and you can’t ignore it, don’t play the campaign. And just to be clear, it has never been my intention—at least since I resumed its development in 2011—for it to be eligible for mainline or anything like that.

The changelog for this version follows:

Version 0.8.1:
--------------
* Graphics:
  * New or updated unit graphics: most Aragwaith units (wayfarer).

* Scenarios:
  * E2S3.1 - Unrest in Raelthyn:
    * Updated to use Aragwaith units.
  * E2S8 - And then there was Chaos:
    * Fixed elves who are initially Loyal getting a duplicate
      trait when switching allegiances.
  * E3S2.1 - Return to Raelthyn:
    * Minor map balancing changes.
  * E3S4 - Outpost of Hell (Gateway):
    * New scenario.
  * E3S5 - Pass of Sorrows (Gathering Storm):
    * New scenario.

* Sound effects:
  * Added hit and death sounds for Doors.
  * Added additional explosion/thunder sounds.
  * Added magic glyph sounds.

* Units:
  * Balancing:
    * Removed marksman special from the Demolisher Drone's ranged attack.
    * Increased Sprite's impact resistance from -20% to 0%.
    * Increased Fire Faerie's impact resistance from -20% to 0%.
    * Increased Dryad's impact resistance from -10% to 0%.
    * Increased Aragwaith Seer's HP from 39 to 44.
    * Increased Aragwaith Seer's melee attack from 7-2 to 8-2.
    * Increased Aragwaith Seer's ranged attack from 8-3 to 10-3.
    * Decreased Shaxthal Razorbird's melee attack from 10-1 to 8-1.
    * Decreased Shaxthal Thunderbird's melee attack from 13-1 to 10-1.
  * Gave Doors a unit icon for the sidebar and the attack dialog.
  * Updated Aragwaith units to match the faction from bumbadadabum's
    "The Aragwaithi" add-on. This has resulted in the following changes:
    * Protection only affects allied L1 and L0 units instead of any allied
      lower level unit
    * Ancient Banner abilities: +leadership, -protection, -steadfast
    * Ancient banner resistances: impact 10% -> 20%
    * Ancient banner stats: HP 55 -> 58, MP 4 -> 5
    * Ancient banner attacks: sword renamed to scythe
    * Archer attacks: melee 6-3 -> 4-3
    * Captain abilities: +leadership, -protection, -steadfast
    * Captain resistances: blade 20% -> 10%, fire 10% -> 0%, cold 10% -> 0%,
      pierce 20% -> 10%
    * Captain stats: HP 43 -> 55, MP 4 -> 5
    * Captain attacks: spear renamed to glaive, 17-2 -> 18-2; sword renamed to
      glaive, 9-4 -> 10-4
    * Eagle Master stats: HP 48 -> 45, MP 7 -> 9
    * Eagle Master attacks: blade 9-3 -> 10-3, impact 15-2 -> 16-2
    * Eagle Rider defense: mountain 60% -> 50%
    * Eagle Rider stats: HP 36 -> 34, MP 7 -> 9, cost 21 -> 23
    * Eagle Rider attacks: impact 10-2 -> 12-2
    * Flagbearer abilities: +leadership, -protection, -steadfast
    * Flagbearer resistances: blade 20% -> 10%, fire 10% -> 0%, cold 10% -> 0%,
      pierce 20% -> 0%, impact 10% -> 0%
    * Flagbearer stats: HP 34 -> 45, MP 4 -> 5
    * Flagbearer attacks: spear renamed to glaive, sword renamed to glaive
    * Greatbow stats: HP 43 -> 46, MP 5 -> 6
    * Greatbow attacks: melee 13-3 -> 10-3
    * Guard abilities: +steadfast
    * Guard resistances: pierce 20% -> 10%, impact 20% -> 10%, blade 30% -> 10%
    * Guard stats: HP 40 -> 54, XP 78 -> 64, cost 27 -> 28
    * Guard attacks: melee 12-3 -> 11-3
    * Guardian resistances: fire 10% -> 0%, cold 10% -> 0%
    * Guardian stats: HP 51 -> 62
    * Lancer now has a female variation
    * Lancer stats: HP 40 -> 48, cost 38 -> 34
    * Longswordsman stats: HP 38 -> 46, MP 5 -> 6, XP 78 -> 88, cost 24 -> 27
    * Pikeman resistances: blade 20% -> 10%, impact 10% -> 0%, fire 10% -> 0%,
      cold 10% -> 0%
    * Pikeman stats: HP 44 -> 50, XP 94 -> 70
    * Pikeman attacks: melee 17-2 -> 16-2
    * Scout now has a female variation
    * Scout stats: HP 31 -> 36, XP 36 -> 40
    * Scout attacks: melee 10-2 -> 11-2
    * Shield Guard abilities: +protection, +steadfast
    * Shield Guard resistances: pierce 30% -> 10%, impact 30% -> 10%, blade
      40% -> 10%
    * Shield Guard stats: HP 54 -> 66
    * Shield Guard attacks: melee 16-3 -> 15-3
    * Silver Shield now has a female variation
    * Silver Shield stats: HP 54 -> 62, MP 8 -> 9, cost 38 -> 48
    * Silver Shield attacks: melee 13-4 -> 12-4
    * Slayer stats: HP 45 -> 53, MP 5 -> 6, cost 46 -> 62
    * Slayer attacks: melee 12-4 -> 11-4
    * Sorcerer renamed to Sorceress, no longer has a male variation
    * Spearman resistances: blade 20% -> 0%, pierce 20% -> 10%, impact 10% ->
      0%, fire 10% -> 0%, cold 10% -> 0%
    * Spearman stats: HP 30 -> 34, XP 38 -> 43
    * Spearman attacks: 11-2 -> 12-2
    * Strongbow stats: HP 35 -> 38, MP 5 -> 6, XP 80 -> 85, cost 31 -> 38
    * Strongbow attacks: melee 9-3 -> 7-3, ranged 8-4 -> 9-4
    * Swordsmaster id changed, breaking old saved games with the unit
    * Swordsmaster stats: MP 5 -> 6
    * Swordsman resistances: blade 10% -> 0%
    * Swordsman stats: HP 28 -> 32, XP 32 -> 39, cost 13 -> 14
    * Warlock renamed to Witch, no longer has a male variation
    * Witch stats: XP 44 -> 54, cost 18 -> 22
    * Witch attacks: staff renamed to kick, 6-2 -> 7-1
    * Wizard no longer has a male variation
    * Wizard attacks: melee 10-2 -> 7-2, ranged 11-3 -> 10-3

Since the first three scenarios of After the Storm: Final are already out (0.8.0), I can now talk about my plans for the campaign to ensure we are all on the same page later.

This episode’s final scenario count is preliminarily advertised as twelve in the campaign menu entry, but the number may change as I see fit. More importantly, the final seven scenarios will be published as an atomic batch instead of separately. In fact, it’s very likely they will not enter the SVN repository until they all are finished.

For now, two more scenarios are expected to land in SVN trunk during the upcoming months; Outpost of Hell (E3S4) and Pass of Sorrows (tentative name for E3S5). Anyone who has been paying attention to the story and dialog sequences found in E3 so far will be able to predict the events taking place in E3S4 and E3S5. However, these scenarios (E3S4 in particular) require new units for gameplay and story reasons, and—since I am the only dedicated ‘artist’ working in the campaign—this part may take some time.

The campaign’s overall structure has resulted in decidedly slow storytelling and I don’t regret this design; basically, if you don’t like this, this campaign is not for you. However, things are going to get far more complicated after E3S5 as we approach the conclusion. Getting the finale right—in regards to code, prose, and art together, but especially art—may require a greater amount of energy than anything done before for AtS; hence, once E3S5 is out you may rest assured that unless a miracle occurs, the rest will take a large amount of time to be properly finished and released as After the Storm version 0.9.0.

Writing the finale is not a big deal per se since I’ve always known where the characters are going. The problem is making sure it’s worthwhile to play and read. I’ve always been flexible to plot changes in that regard since I resumed work on E1 last year; after all, this is a game, not a novel. The execution of the plot is also a touchy subject since the matter of the campaign doesn’t really fit neatly in a turn-based strategy game, and compromises must be made.

As usual, art is an ever-present issue as well. The finale requires more new units, props, and terrain graphics. When it comes to unit art, I have always been able to manage by reusing previous assets, making minor modifications and calling it ‘new’; but terrains and props are uncharted lands for me, which is why I fear art will take up most of the production time for the finale. And this is all not taking portraits into account; ideally at this point all major characters from this campaign—as opposed to those introduced in IftU—would have their own portraits, but that just hasn’t happened yet and is unlikely to happen in the near future.

In any case, this has been a very interesting journey. I hope it comes to an end soon and Final can be completed before the end of the year, but I’d not be surprised if it takes longer than that.

Version 0.8.0 is finally out, 16 days after the original deadline. Oh well. At least it didn’t take half a year like the last time I failed to meet a release schedule.

This version will most certainly not be exempt of flaws. It introduces the first three playable scenarios of Episode III (Final), plus two cutscenes; the playable scenarios haven’t been tested very thoroughly by my dedicated QA team or myself, and thus might be full of balancing issues, especially on difficulty levels other than Normal.

I guess I might as well take this opportunity to mention that Normal is, in fact, the only difficulty level I actually test.

There’s also a few bug fixes in this version, but nothing too important other than a voodoo fix for crashes affecting Mac OS X users at the end of Episode II (previously described in the forums). Somehow, I managed to forget to mention this item in the changelog this time; I feel this isn’t the only thing I forgot to do before releasing. Ah well, it probably isn’t my fault seeing as how I have to take care of so many things (cough art cough) for this campaign.

UPDATE: The immediate implication of this fix is that you will need to run Fate (the final cutscene scenario of Episode II, not the whole episode) again if you want Anya’s and Durvan’s stats to carry over to Episode III.

The changelog for this version follows:

Version 0.8.0:
--------------
* Scenarios:
  * Mal Hekuba now wears purple TC as he did in IftU.
  * E3S0 - Opening (Within):
    * New scenario.
  * E3S1 - Beyond her Smile (A Light in the Darkness):
    * New scenario.
  * E3S2 - Return to Raelthyn (Reckoning):
    * New scenario.
  * E3S3 - Amidst the Ruins of Glamdrol (A Path to Follow):
    * New scenario.

* Units:
  * Balancing:
    * Increased Chaos Hound's recruit cost from 18 to 20.
    * Increased Shaxthal Razorbird's recruit cost from 18 to 19.
    * Decreased Shaxthal Runner Drone's ranged attack strength from 8-3 to 7-3.
  * Fixed invisible Chaos Longbowman and Heavy Longbowman units due to missing
    graphics.
  * Fixed Elvish Trapper and Elvish Prowler disappearing during animations.
  * Fixed NPC bird code deleting the previous on-map unit when moving a
    bird to an occupied hex (i.e. worms in E2S9).
  * Removed Kri'tan.

I’ll start by admitting that there was a severe schedule slip again, induced by both personal and technical difficulties. After the Storm: Final scenario 3—which was supposed to be the last scenario introduced by the 0.8.0 update—was only completed a couple of nights ago, despite scenario 2 being completed well before the last week of April.

That said, E3S0 through E3S3 are complete in SVN trunk as of this writing. The problem is that I might still delay 0.8.0 for a while so I can deal with two pending artwork issues (for E3S0 and E3S2, respectively) and perhaps do some additional balancing.

In the meantime, Mac OS X users need to be aware of a certain crash issue affecting the last release currently available, 0.7.4.

I might delay 0.8.0 even more in order to include E3S4 in it. That scenario, however, requires more new artwork that the previous ones combined, and—since I’m not an artist—I can’t guarantee an output rate that would allow for a prompt release this month. I advise patience for the time being.

That is, assuming anyone still cares about this thing!

It’s only been a week since version 0.7.3 of After the Storm came out. As I said some time ago, I’m not announcing minor releases in my blog anymore since they can get on occasion a little too noisy for my taste. However, today’s release, version 0.7.4, is special in a few ways.

I expect this to be the last release of the 0.7.x series unless something major comes up later. The next release should be version 0.8.0, scheduled for May 1st assuming everything goes the way I planned in the meantime. 0.8.0 will contain the first three scenarios of After the Storm: Final (otherwise known as Episode III).

It’s perfectly evident at this point that it won’t be possible to achieve the version 1.0 goals very soon, which is why I decided to go ahead with the development of the third and final episode of the campaign immediately and turn it into a 1.0 target as well.

However, the importance of version 0.7.4 goes a little further than this minor change of plans.

In order to allow a faster release cycle and quick deployment of critical bug fixes, I have split the add-on in two packages. The first, original package contains all resources except music files, which are now provided by a separate add-on creatively titled After the Storm Music in the Wesnoth 1.10 add-ons server. Since neither the server nor the 1.10 client appear to have a problem with it, both add-ons are mutually dependent; this should minimize the chances of people installing the music package without the campaign.

This design will allow faster uploads at my end, and faster downloads at the players’ end (when not using Xdelta, anyway). I expect the 0.8.x release cycle to be fairly long and lively, assuming artwork and plot development go as expected. Given the nature of the music add-on, odds are it won’t see a lot of updates in the future; at the very least, it won’t be updated as often as the approx. 4.6 MiB campaign proper. People who don’t play with music or sounds enabled, or who simply cannot afford the separate 12.3 MiB download are not required to install the add-on, although the campaign menu entries will include a small warning accordingly.

Current users of 0.7.3 and previous versions will be asked to install the music add-on when upgrading or installing After the Storm for the first time.

Because of the aforementioned splitting and some other internal changes, I decided to fast-track this update instead of holding it until 0.8.0. The more testers, the better.

The changelog for this version follows:

Version 0.7.4:
--------------
* Graphics:
  * New or updated unit graphics: Shaxthal Warlord Nar-Hamoth

* Music:
  * All current music tracks have been moved to a separate add-on,
    imaginatively titled "AtS Music". This add-on is now an optional dependency
    for those who can't afford downloading it or don't play with music enabled.
    When absent, the AtS campaign menu entries for each episode will include a
    notice stating so.

* Scenarios:
  * E2S5 - The Eastern Front:
    * Added a time-over dialog sequence.
    * Added an additional dialog sequence focusing on a specific
      player character.
  * E2S6 - The Voyage Home:
    * Added a time-over dialog sequence.
  * E2S7 - Proximus:
    * Added a time-over dialog sequence.
  * E2S8 - And then there was Chaos:
    * Fixed elves not getting the Loyal trait.
  * E2S9 - New Hive:
    * Fixed Shaxthal Worms changing colors when moving.
    * Reduced starting gold.
  * E2S10 - The Betrayal:
    * Fixed multiple "invalid WML array index" warnings at the start.
    * Reduced starting gold.
  * E2S11 - A Final Confrontation:
    * Made the glyph guardians a little more competent.
  * Healing glyphs no longer render affected units unable to attack on the
    same turn.

* Units:
  * Balancing:
    * Increased arcane damage resistance for most Shaxthal units from -50% to
      -20%.
    * Decreased Demon Zephyr's movement cost on deep water terrains from 2 to 1.
    * Decreased Demon Zephyr's movement cost on unwalkable terrains from 3 to 1.
  * Reimplemented NPC bird behavior code in Lua.
  * Renamed "Shaxthal Warlord" unit type to "Shaxthal Warlord Narhamoth";
    this breaks old saved games of E1S9.1 (The Triad, part 1) during turns.

Maintaining Wesnoth add-ons of the size of Invasion from the Unknown and After the Storm isn’t a small task by any means. Over the years, I have had to rely on user feedback to detect critical problems in a release, because testing becomes cumbersome and tedious as the scenario count increases.

My usual release procedure simply involves—at least since I acquired the habit of testing before releasing—running the game, starting each episode of the campaign with the medium difficulty level and making sure the WML preprocessor and parser don’t throw any warnings or errors. Before Wesnoth 1.9.x, the preprocessor didn’t abort when encountering a missing macro or file during a brace substitution, so I had to pay close attention to stderr to ensure nothing is wrong.

The WML preprocessor in Wesnoth 1.10 became more strict, aborting on the aforementioned situations. It was also exposed for command-line usage (for testing or debugging) through the -p or --preprocess switch, also explained in detail under PreprocessorRef in the wiki.

At first I thought that wasn’t very useful beyond diagnosing complicated preprocessor issues, but today I realized I can also do this:

This can be easily accomplished with a simple shell script (here embedded in the AtS Makefile). The only major shortcoming is that it doesn’t cover every possible problem because it’s merely running the WML preprocessor, which doesn’t consume and produce WML — all it sees is plain text mixed with some preprocessor directives. The task of reading actual WML (which is potentially found in the preprocessor’s output) is left to the WML parser proper, which creates internal objects in memory corresponding to the internal representation of WML handled by Wesnoth (config class objects).

UPDATE: After investigating the issue further with timotei (who exposed this functionality through --preprocess in the first place), it turns out the preprocessor output with --preprocess is indeed parsed — the real problem is that the preprocessor and parser use different logging facilities, and the former doesn’t even throw errors directly, so a preprocessor-only failure will make the game exit successfully (exit status of zero), while a parser error (potentially induced by a previous preprocessor error) causes a more appropriate non-zero exit status. This and other jarring inconsistencies make add-on test automation rather difficult, to say the least, so things have been simplified in the Makefile as a result.

It would be nice to be able to run the parser unit on the --preprocess output to detect syntax issues like missing end tags or unterminated string literals in the future, as part of a fully automated test suite. For now, it seems I’ll have to stick to my primitive and inelegant manual method before making new AtS releases, plus the unbelievably clumsy wmllint.