Shadowmaster’s Blog - Projects

After the Storm 0.9.1

nospam@example.com (shadowmaster) — Tue, 02 Apr 2013 02:19:00 +0000

Version 0.9.1 is out!

Since the campaign is complete, any future—and hopefully infrequent—releases from now on will consist mostly of bug fixes, balancing changes, art updates, and very minor features. On this particular occasion, I played the campaign end-to-end on Wesnoth 1.11.2 to make sure various 1.11.x-specific issues were solved as early as possible in order to make the eventual transition to 1.12 as smooth as possible. I will try to make sure future releases of the campaign are well-tested against future Wesnoth development versions as well. (Future, future, future.)

Because of a very annoying player side data loss bug (#20373) affecting various E3 scenarios, I decided to drop support for Wesnoth 1.11.1, thus only Wesnoth 1.10.x and 1.11.2 are supported for this release! I will simply ignore any future reports on technical issues occurring on 1.11.1.

Aside from the aforementioned, some other noteworthy changes in this release include making E3S13 an optional/bonus cutscene as it was originally intended to be, adding very simple AMLAs for two main characters throughout E2 and E3, updating the Aragwaithi units to match bumbadadabum’s and vultraz’s changes to the faction from the Era of Chaos add-on (as of version 1.1.0), as well as an amount of minor prose fixes and improvements from vultraz, 8680, and me.

The complete changelog for this version follows:

Version 0.9.1:
--------------
* General:
  * Added workaround code for a problem with the [lock_view] implementation and
    its interaction with unit movement via [move_unit_fake]/[move_unit] on
    Wesnoth 1.11.x.
  * Made it so sequences using [animate_attack] do not display a floating label
    when dealing 1 HP damage since most of the time this is a consequence of
    dealing 100% HP on the target with kill=no, or other reasons along the same
    line.

* Graphics:
  * New or updated unit graphics: Elynia, Ivyel, Argan.

* Scenarios:
  * Fixed several instances (E1S7, etc.) of sighted events taking place
    prematurely on Wesnoth 1.11.x.
  * Fixed several instances of loyal units auto-recall code causing warnings on
    Wesnoth 1.11.x.
  * Minor prose fixes, tweaks, and enhancements throughout the entire campaign.
  * E1S7 - The Search for the Past:
    * Glyphs needed to end the scenario are now marked with a blinking tile
      outline (requires halos to be enabled in Display preferences).
    * Minor cutscene improvements.
    * Reworked message glyphs' code so their messages can be triggered as many
      times as the player wants (NOTE: the last glyph triggered will still
      unconditionally trigger the end of the scenario).
  * E1S9.1 - The Triad, part 1:
    * Minor gameplay improvements.
    * Removed duplicate character line during the initial sequence.
  * E1S9.2 - The Triad, part 2:
    * Reworked some code for increased robustness.
  * E1S9.3 - The Triad, part 3:
    * Reworked some code for increased robustness.
  * E1S10 - Tears:
    * Fixed gold carryover from E1S8 (Fear) being reduced to its 40% (for an
      effective carryover of 16%) when calculating the initial player gold
      supply for this scenario.
    * Reduced minimum starting gold to compensate for the bug fix above.
  * E1S11.1 - Return to Wesmere, part 1:
    * Fixed "retrieving member of non-existent WML container" warnings at the
      start of the scenario.
  * E1S11.2 - Return to Wesmere, part 2:
    * Fixed spurious "retrieving member of non-existent WML container" warning
      at the end of the scenario.
  * E2S1 - By the Moonlight:
    * Minor balancing changes.
  * E2S4 - Shifting Allegiances:
    * Minor map balancing tweaks.
    * Reduced turn limit from 34/33/32 to 28/27/26.
    * Other minor balancing changes.
  * E2S7 - Proximus:
    * Fixed minor fog refresh issues during the initial cutscene.
  * E2S8 - And then there was Chaos:
    * Minor balancing changes to increase difficulty.
  * E2S9 - New Hive:
    * Minor balancing changes.
  * E3S3 - Amidst the Ruins of Glamdrol:
    * Apply the default AMLA to Kyara and Horo a predefined amount of times on
      prestart according to the difficulty level.
    * Made it so neither the player nor Nar-hamoth can land a hit on each other.
  * E3S4 - Outpost of Hell:
    * Fix specific units being unintentionally visible during a white screen
      sequence.
    * Fixed "trying to remove non-existent menu item" warning at the end of
      the scenario on Wesnoth 1.11.x under certain conditions.
    * Make sure side 2 units also get their demolition ability and overlay
      removed at the end.
  * E3S5 - Pass of Sorrows:
    * Make the teleportation/exposition event in the middle of the scenario
      work as intended.
  * E3S7B - Dark Sea:
    * Make the northwestern Shaxthal and eastern undead sides less prone to
      stealing player villages.
  * E3S9 - Dark Depths:
    * Minor boss fight improvements.
    * Minor cutscene improvements.
  * E3S10 - Blood:
    * Made the foreshadowing moon combination have a x4 multiplier effect
      instead of x5 on all difficulty levels, not just Hard.
  * E3S13 - Epilogue:
    * Fixed some cutscene-only female units not having their gender specified
      in WML or translatable strings.
    * This scenario is now only accessible after recovering an object hidden in
      a previous scenario.

* Terrains:
  * Experimental fix for the long-standing gate clipping issue when adjacent to
    stone wall corners.

* Units:
  * Added sidebar icon for units affected by the 'stun' weapon special.
  * Added sidebar icon for units affected by the movement range bind spell.
  * Applied changes from bumbadadabum's "The Aragwaithi" add-on, versions 1.0.6
    through 1.0.9, and "Era of Chaos" version 1.1.0:
    * Archer HP increased from 26 to 28.
    * Granted the new 'precision' weapon special to the Greatbow's ranged
      attack.
    * Increased Guard's blade resistance from 10% to 20%.
    * Increased Guard's XP from 64 to 74.
    * Decreased Guard's cost from 28 to 27.
    * Decreased Pikeman's cost from 38 to 28.
    * Increased Shield Guard's cost from 37 to 45.
    * Increased Shield Guard's blade and pierce resistances from 10% to 20%.
    * Granted the 'marksman' weapon special to the Swordsmaster.
    * Renamed the Aragwaith Witch's image files (may break saved games from
      E3S2).
    * Various animation fixes and updates.
  * Balancing:
    * Increased Elynia's (E3) mystic fire attack strength from 5-4 to 5-5.
    * Increased Elynia's (post-Divergence) ensnare attack strength from 9-3 to
      9-4.
    * Increased Forest Spirit's movement points from 5 to 6.
    * Decreased Fallen Faerie's HP from 49 to 43.
    * Decreased Fallen Faerie's wail attack strength from 12-3 to 11-3.
  * Gave Anya and Elynia special AMLAs for E2 and E3.
  * Fixed wrong description for Galas' bolas attack AMLA (stated magical as the
    weapon special, it is actually slows).

After the Storm 0.9.0

nospam@example.com (shadowmaster) — Tue, 05 Mar 2013 04:16:00 +0000

After years and years of development, drama, script rewrites, field research, technological advancements, ~~budget cuts~~, and temporal shenanigans, today, March 5th 2013, I can say for sure that After the Storm is complete with the release of the most important milestone yet: version 0.9.0, with all three episodes completed with 13 scenarios each.

A few caveats for people upgrading from the previous release:

This release adds the final Epilogue scenario for Episode III, which will become a bonus feature in 0.9.1. If you had previously finished AtS Episode III using versions 0.8.90 or 0.8.90.1, you will have a start-of-scenario save for the Epilogue scenario which you can use after upgrading to this version.
As usual, for the most stable experience I advise using Wesnoth 1.10.x — preferably 1.10.5 or a newer version when it becomes available. All episodes of this campaign were primarily developed and tested on 1.10.x, and there are subtle behavioral differences in the game engine between 1.10.x and 1.11.x that may break some sequences or cause other unintended side-effects.
Various issues reported by playtesters on Wesnoth 1.11.1 were fixed. Most notably, it implements a workaround measure for mainline bug #20373, which is relevant for Episode III scenarios starting from Dark Sea. People who experienced player information loss (recall and recruit lists, gold reserves) after Dark Sea on 1.11.1 will need to replay that scenario from the start-of-scenario save (NOT the Turn 1 save!) in order for Wesnoth to install the code in charge of solving that issue in later scenarios. This code will not work on Wesnoth 1.11.2 — you will need to finish Episode III on 1.11.1 before switching to 1.11.2 (whenever it is released, anyway).

This... has been a really long journey, to say the least, and I pretty much lost all hope of ever finishing this campaign at various points over past years. Development started in 2008 and quickly stagnated for various reasons:

Perceived lack/loss of interest from the audience
Excessive perfectionism on my part
Various IRL struggles, including health and personal matters
Constant conflicts of interest amongst the few people who were actually interested in IftU and AtS’ development
Mainline development tasks taking up my spare time
Wesnoth.org forums moderation and administration taking up my spare time

To say that I was overjoyed when the Big Merge took place just a couple of weeks ago would be a big understatement. This campaign became for me more than just another Wesnoth campaign as time passed — it became a part of me I thought I had left behind when IftU was first completed, a testament to my chronic failure to drive my own projects to completion.

Development Hell

After the Storm changed a lot since it was originally conceived in 2008. The original draft was both over-pretentious and subpar, and it was not what I wanted to create after IftU. I wanted to create something better than IftU, but I locked myself in a trap by relying on source material that was already broken by design. Making a better sequel became my obsession, and that obsession led to AtS’ stagnation during the development of Episode I.

But some time mid-2011, I finally saw that trying to achieve perfection was a flawed goal in its own right. What I should have been aiming for all along was to make something fun, something from which I could learn, something I would enjoy to play and create. It was that realization that finally led me to complete Episode I, and the rest was a blaze; a blaze that culminates with this release, today.

The result

The final product is neither perfect nor it aims to be such. I do not think this campaign is for everyone, seeing as how the gameplay and plot are very tightly knit together, and the overall scenario count goes up to 39 without taking cutscenes, segmented scenarios, and bifurcation into account; however, unlike IftU, every episode is a separate campaign in its own right, and I believe that makes the overall experience more enjoyable and less chaotic, balancing-wise.

When I first wrote IftU, my grasp of the English language was as poor as my handle of storytelling in general was, to say the least. This also applies to AtS Episode I up to scenario 9, part 2 — which became the turning point for the campaign’s development when I finally chose to renounce perfectionism and embrace the fun in creation. But I digress. AtS’ prose is all my own output with minor amendments from my playtesters and proofreaders, and an experiment in style wherein I take breaks from mainline conventions on purpose, in a subtle and calculated manner. Attentive players may be able to point out those inflection points from just paying attention at the characters and their interactions — characters whose flaws and mistakes are not as detached from reality as the game’s fantasy setting or the subtext-based delivery may suggest.

The three-episodes structure was mostly an afterthought. AtS episode III became an amalgamation of a previous planned AtS sequel and an aborted IftU prequel. But this structure fits the narrative better than the original plan. Episode I establishes the setting and motivations for the protagonists, and provides more hints about the overarching plot than IftU did; Episode II gradually develops further on the characters’ inner struggles while providing entertaining gameplay and dropping even more hints about the grand scheme; and finally, on Episode III things go off the rails in pretty much every way possible—including gameplay—and the plot reaches its final resolution within the scope originally intended for AtS.

Reception and expectations

Some people will be unable to find or interpret the hints and may see the finale as an out-of-the-blue succession of events, all because I avoided indulging in long and heavy exposition sequences that leave nothing to the player’s imagination and reading skills. I am perfectly aware that this is an inevitability, because it is absolutely impossible to please everyone, as I have learned from my experience with activities otherwise wholly orthogonal to the storytelling field. I think some UMC authors should really keep this in mind whenever they feel tempted to abandon their efforts just because a vocal segment of their players doesn’t like their output.

Other people will not like AtS because “it’s not like IftU”. Perfectionism aside, it is impossible for it to be like IftU after all that I have learned in the meantime about storytelling, life, people, and myself. The circumstances under which IftU was created were entirely unique and I would have to trade many things which I have gained or lost since then in order to create another IftU — and I would not be pleased by the result in the end.

I think AtS works just fine as an IftU sequel, and a sequel does not have to fully embrace the spirit of the original to be such. It’s not like AtS isn’t littered with callbacks to IftU in direct and meta levels anyway. There are a lot of things in it to enjoy, and a lot of things to hate — and both are part of the plan!

But in the end, all that matters to me is that I like the finished product, had fun making it, and learned lots of things along the road.

What’s next?

For those who might think that AtS’ finale is a definitive conclusion to the involved characters’ respective arcs: no, it is not — but I allotted a specific amount of time and scenarios for telling their origin stories, and the campaign had to end at some point. Is there enough material for sequels? Hell, yes, but I don’t see myself making another Wesnoth campaign given all the technical and non-technical limitations imposed by the platform. The three ultimate protagonists have a whole journey ahead of them (as well as more characters to meet), and I would like to explore that in some other medium in the future. For fellow Wesnoth UMC authors, though, there is plenty of material left to work with if you pay attention to every single minor detail.

Of course, I am open to questions about everything you may want to know about the campaign, be it via forum PM, or posts in the campaign’s development topic. But I would appreciate it if people didn’t post topics for every single thing in Writers’ Forum — when that happens, odds are I will just ignore those topics in their entirety and not take the effort seriously. As a matter of principle, if you want to ask a campaign author about their work, you ask them directly through their official communication channels instead of walking to the closest park holding a massive sign in your hand.

With AtS 0.9.0 released, all I have left to do is to take care of fine-tuning scenario and unit balance, fixing any remaining prose issues (especially those annoying unit type descriptions for the in-game help system), dealing with missing/placeholder/subpar pixel art, and somehow find a portrait artist willing to work under my specific terms. The latter part will probably take ages, so don’t hold your breath waiting for AtS 1.0.0.

Finally...

I will be forever grateful to the people (and pets) who helped me along this arduous and extended quest, even those who did so unwittingly — if you are reading this, odds are that you know who you are.

To conclude this post, the changelog for this version follows:

Version 0.9.0:
--------------
* General:
  * Milestone: all scenarios completed.

* Scenarios:
  * Deployed code to work around a side-switching issue affecting Wesnoth
    1.11.1 during post-Divergence (E3S6) scenarios. The corresponding
    mainline bug is #20373 and it is fixed on 1.11.2.
  * Fixed various "wesnoth.get_side is deprecated, use wesnoth.sides instead"
    warnings on 1.11.x.
  * Minor story text grammar, style, and punctuation amendments.
  * E1S6 - Quenoth Isle (Elves of a Different Land):
    * Minor prose tweaks.
  * E1S7 - The Search for the Past:
    * Minor prose tweaks.
  * E1S12 - The Queen:
    * Minor prose tweak.
  * E1S13 - Death and Rebirth:
    * Fixed minor prose issue ("take risky choices" -> "make risky choices").
  * E2S2 - The Heart Forest:
    * Minor prose tweak.
  * E2S11 - A Final Confrontation:
    * Minor cutscene improvements near the end.
  * E2S12 - Fate:
    * Minor cutscene improvements.
  * E3S8C - Breakdown:
    * Don't allow summoning Fire Guardians until the player enters the
      underground river passage.
    * Fix objectives display inconsistencies throughout the scenario.
    * Minor cutscene improvements.
  * E3S8D - Destiny, part 2:
    * Fixed Anya's movements not being undoable.
  * E3S9: Dark Depths:
    * Fixed minor cutscene glitches.
  * E3S10 - Blood:
    * Add a context menu item displaying a list of available attack
      combinations and their effects.
  * E3S13 - Epilogue:
    * New scenario.

* Units:
  * Balancing:
    * Decreased Demon Slashing Gale's melee attack from 11-3 to 10-3.
    * Decreased Demon Slashing Gale's ranged attack from 10-5 to 9-4.
  * Fixed Chaos Arbalestier ranged attack animation failing to trigger.
  * Fixed Shaxthal Turret not getting the biomechanical trait.
  * Fix multiple "Descriptions should no longer include the name as the first
    line" warnings on 1.11.1 and later.
  * Fix unit types with missing faction prefixes in their names:
    * Arbalestier -> Chaos Arbalestier
    * Cataphract -> Chaos Cataphract
    * Crossbowman -> Chaos Crossbowman
    * Heavy Longbowman -> Chaos Heavy Longbowman
  * Hide private variations for regular unit types from the help system on
    1.11.x.
  * Killed Kri'tan.

The full changelog—for versions 0.3.0 through 0.9.0—can be found here.

After the Storm: Three commits I never thought would happen

nospam@example.com (shadowmaster) — Fri, 01 Mar 2013 12:37:00 +0000

------------------------------------------------------------------------
r17326 | shikadilord | 2013-03-01 09:11:52 -0300 (Fri, 01 Mar 2013) | 2 lines

AtS E3S13: enable completed scenario in production

------------------------------------------------------------------------
r17327 | shikadilord | 2013-03-01 09:12:35 -0300 (Fri, 01 Mar 2013) | 4 lines

AtS: remove END_OF_PLAYABLE_SCENARIOS macro

AtS is complete. This macro no longer serves any purpose.

------------------------------------------------------------------------
r17328 | shikadilord | 2013-03-01 09:12:57 -0300 (Fri, 01 Mar 2013) | 4 lines

AtS: remove ROCKS_FALL_EVERYONE_DIES macro

AtS is complete. This macro no longer serves any purpose.

*sheds a single tear*

After the Storm 0.8.90 (a.k.a. “0.9.0 minus one”)

nospam@example.com (shadowmaster) — Sat, 23 Feb 2013 05:10:00 +0000

Version 0.8.90 (a.k.a. “0.9.0 minus one”) is out!

Episode III (Final) is now complete in this version, sans the final Epilogue scenario (which will eventually become a bonus feature) that is not part of the scenario count for various reasons that will become evident once 0.9.0 is released.

Some important caveats:

All scenarios after E3S6 (Divergence) were developed and tested on Wesnoth 1.10.x only, so if you are playing on 1.11.1 and you experience any issues, please report them on the forum topic.
Some code in later scenarios seems to be somewhat CPU intensive, performing significantly worse on my dual-core 2.1 GHz laptop than on my quad-core + HT 3.4 GHz desktop.
If you will play the last scenarios of Episode III with music, you must make sure you have upgraded the AtS Music add-on to version 0.2.0 first! This version was published on the add-ons server in advance a few days ago to give people time to upgrade in preparation for version 0.8.90 of the campaign proper.
Official support for Wesnoth versions 1.9.10 through 1.9.14 has been dropped in this version. In theory, Wesnoth 1.9.14 should work just fine, but there are several minor bugs that were addressed later during the 1.10.x stable series that may affect this campaign.

Special thanks go to vultraz for playtesting this beast starting from E3S6 in less than a day (around 14 hours with breaks), and the other two playtesters (you know who you are!) who reported some glaring issues with E3S6 and E3S7A.1, which were addressed after the Big Merge and before the packaging of this release.

I will save the longer announcement (including plans for the future) for later, when the final Epilogue is done and 0.9.0 is released.

The changelog for this version follows:

Version 0.8.90 a.k.a. "0.9.0 minus one":
----------------------------------------
* General:
  * Dropped remaining compatibility code for Wesnoth 1.9.14 and earlier.

* Scenarios:
  * E1S11.2 - Return to Wesmere, part 2:
    * Removed compatibility code for Wesnoth 1.9.5 through 1.9.8.
  * Completed Episode III (sans Epilogue).

* Units:
  * Balancing:
    * Increased Elynia's resistance to impact damage from -10% to 0%.
    * Decreased Demon Shapeshifter's ranged attack from 8-2 to 7-2.

After the Storm: Not so fast

nospam@example.com (shadowmaster) — Fri, 22 Feb 2013 10:16:00 +0000

Everyone who follows me on Twitter can stop reading here.

Continue reading "After the Storm: Not so fast"

After the Storm: Big Merge done, 0.8.90 on the horizon

nospam@example.com (shadowmaster) — Tue, 19 Feb 2013 04:48:00 +0000

The first After the Storm commit to Wesnoth-UMC-Dev’s trunk happened on May 17th, year 2008.

Today, February 19th 2013, after years and years of development, with various real life and non-real life issues getting in the way and dooming the campaign to Development Hell until version 0.4.0 with a completed Episode I finally happened on October 16th 2011, I can say for certain that...

After the Storm is finally complete.

With the Big Merge done and all the Episode III post-Divergence content (sans the Epilogue scenario) finally landed in Wesnoth-UMC-Dev trunk, the next step is releasing AtS version 0.8.90 to the public.

r17177 | AtS: bump version from 0.8.5+svn to 0.8.90-svn in the changelog after the Big Merge
r17176 | AtS: [Big Merge] workaround issues with the test suite and macros from data/core/units.cfg
r17175 | AtS E3: [Big Merge] land post-Divergence maps and scenarios
r17174 | AtS E3: [Big Merge] land post-Divergence ancillary macros, story text, character macros, and death handlers
r17173 | AtS: [Big Merge] land post-Divergence units WML, baseframes, halos, and animations
r17172 | AtS: [Big Merge] merge macros used for post-Convergence content
r17171 | AtS: [Big Merge] remove conditional loading of finale-stage scenarios and units
r17170 | AtS: bump version from 0.8.5+svn to 0.8.90-svn before the Big Merge
r17169 | AtS E3S6: enable scenario in regular gameplay

There will be a delay between this and the actual public 0.8.90 release while my primary playtester (vultraz) does the playtesting thing with the scenarios. Some balancing changes before 0.8.90 may also be necessary.

In the meantime, people can check out After the Storm from Wesnoth-UMC-Dev trunk using the Subversion client of their choice, and provide me with feedback via forum PM (in particular, about any possible bugs or balance issues that might plague some specific scenarios), or private messaging on IRC — I am on irc.freenode.net, channel ##shadowm most of the time, but I would rather avoid people dropping spoilers in the presence of my aforementioned playtester, who also hangs around there.

UPDATE: Since I haven’t gotten around to publish version 0.2.0 of the AtS Music add-on, you will also need to obtain the latest version from SVN separately, since it introduces a few music tracks used in the new AtS Episode III scenarios. Of course, this is only necessary if you want/need to have in-game background music.

UPDATE 2: AtS Music version 0.2.0 is now in the 1.10 and 1.11.x add-ons servers. The previous version was 12.3 MiB in size, whereas the new version is 22.7 MiB. I actually had to do some re-encoding to bring it down from 33.1 MiB, but there shouldn’t be any noticeable compression artifact build-up — or at least, I cannot perceive any with my headphones on.

svn co https://wesnoth-umc-dev.svn.sourceforge.net/svnroot/wesnoth-umc-dev/trunk/After_the_Storm
svn co https://wesnoth-umc-dev.svn.sourceforge.net/svnroot/wesnoth-umc-dev/trunk/AtS_Music

You can also grab tarballs of the latest trunk snapshots through SourceForge.net’s SVN web interface:

/trunk/After_the_Storm file listing (tarball link at the bottom)
/trunk/AtS_Music file listing (tarball link at the bottom)

This last alternative is probably not the best, though, since you will not be able to track future updates. Subversion makes it far easier to update every time a changeset is committed, without having to download the whole thing every time.

I am not going to provide any further instructions for installing using either of these methods, so I’m leaving this to people who actually know their way around Subversion tools or manually installing add-on content. I am not going to post any spoilers either; in particular, I am not going to reveal the Epilogue sequence until version 0.9.0.

Special thanks go to Espreon, Gambit, and vultraz for making all of this possible in their own ways. I will probably explain the deal with AtS’ troubled development in a new post in the near future (probably after 0.8.90 is properly published).

Thanks to all those who waited this long for this to happen. For those who are eager to playtest this and don’t know their way around the aforementioned things, I can only promise that the wait for 0.8.90 will be much shorter. A couple of weeks, tops.

Finally, the usual disclaimer applies: this campaign is not for everyone.

Late After the Storm development roadmap

nospam@example.com (shadowmaster) — Sat, 16 Feb 2013 05:55:00 +0000

It is February 16th already, and it has been a long while since my last update on AtS’ development on this blog, unless we count the January 1st teaser.

Well, here is another teaser in the form of a more concrete roadmap for AtS 0.9.0’s development:

Continue reading "Late After the Storm development roadmap"

On After the Storm 0.9.0’s ETA

nospam@example.com (shadowmaster) — Tue, 04 Dec 2012 20:05:00 +0000

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.

irker-svnpoller: Subversion poller and mail filter application for irker

nospam@example.com (shadowmaster) — Tue, 02 Oct 2012 23:54:00 +0000

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:

shikadilord/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.

Wesnoth RCX 0.2.1

nospam@example.com (shadowmaster) — Tue, 21 Aug 2012 01:59:00 +0000

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!

Wesnoth RCX 0.2.0

nospam@example.com (shadowmaster) — Mon, 06 Aug 2012 03:14:00 +0000

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, and the future

nospam@example.com (shadowmaster) — Tue, 31 Jul 2012 04:58:00 +0000

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.