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.

Everyone who follows me on Twitter can stop reading here.

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.

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.

Following CIA.vc’s untimely demise, ESR and a small ad hoc group of coders and testers including nenolod (from Atheme) and our very own AI0867 (who has led Wesnoth-UMC-Dev in my absence) finally completed the work required to get irker 1.0 out. irker itself has been a work in progress for a while since the last CIA outage in August.

It’s advertised as a CIA.vc replacement, but in reality it is something far less ambitious in scope: a write-only IRC bot that serves its own message bus. From its own README:

irkerd is a specialized IRC client that runs as a daemon, allowing other programs to ship IRC notifications by sending JSON objects to a listening socket.

It is meant to be used by hook scripts in version-control repositories, allowing them to send commit notifications to project IRC channels. A hook script, irkerhook.py, supporting git and Subversion is included in the dustribution (sic); see the install.txt file for installation instructions.

The author’s intention is for existing code forges to adopt this service, and perhaps optionally run it on their own facilities alongside their VCSes, allowing repository admins to opt in for using hooks that deliver notifications to those internal irker instances. irker’s pipeline is extremely flexible and can be summed up as follows:

Repository hook → irker instance → IRC server

CIA.vc’s pipeline is not entirely clear to me and I did not have the opportunity to inspect it from inside, unlike ESR. However, there’s enough evidence suggesting that it was more or less like the following:

Repository hook → CIA.vc XML-RPC or mail provider → CIA.vc database manager → IRC front-end → IRC server

Note that there was also a web front-end, which was integral to CIA’s mission as it was the only way to define projects and bots. A commit notification occurred for a given project; say, Wesnoth-UMC-Dev. The IRC portion of the pipeline made sure that all relevant bots (each one associated to a single channel from the model standpoint) would report the same commit. A less relevant Web front-end in the pipeline took care of adding the commit to the project page (including statistics and an XML feed).

The IRC portion was flexible enough to accommodate the simplest use case (notifying a single project’s commits in a single channel), and more elaborate yet still reasonable use cases (notifying commits from multiple projects in a single channel) without much hassle, all done by tweaking the bots’ configuration in the web-based configuration front-end. Even more advanced use cases were possible by choosing the Advanced Filtering option in the same front-end. This allowed me to have a bot in ##shadowm on freenode report commits as follows:

• Commits from wesnoth-umc-dev (already reported in #wesnoth-umc-dev) with paths matching */After_the_Storm/* and */Invasion_from_the_Unknown/*, regardless of author
• Commits from my own CIA-registered projects (morningstar, weldyn, dorset, etc.) regardless of author
• Commits from any other CIA-registered project (such as Wesnoth or Frogatto) with an author matching my real name or any of my preferred screen names (fun fact: never got any false positives since I set it up a couple of years ago)

I should emphasize that this required no changes to hooks in each repository. Hooks delivered just a minimal set of information, including the commit hash or number, the commit message, affected path, affected branch (when applicable), affected module (when applicable), the author name, and the project name. Everything else was done on CIA’s side, including deciding which channels should get notified of individual commits.

irker does not do this.

irker’s perceived elegance stems from its very basic and versatile design. Essentially, it serves as a mechanism for a repository hook to interact with IRC without having to establish a short-lived connection to a server for every individual commit or commit batch — an approach that GitHub currently allows via a separate, seldom used IRC service hook. irker is not novel in design by any means, and the hype around it is only justified by the fact that nobody bothered to create and advertise any other service that could properly replace CIA.vc before and be inherently extensible maintainable over time.

irker’s extensibility and maintainability stems from the fact that a good portion of the work is done by the repository hooks, and irker is near completely stateless — the obvious opposite of CIA.vc’s architecture.

Unfortunately, this renders advanced use cases such as the above ##shadowm CIA ruleset completely incompatible with the irker pipeline.

From ESR’s post on CIA.vc’s design and its shortcomings:

[...] the original designer fell in love with the idea of data-mining and filtering the notification stream. It is quite visible on the CIA site how much of the code is concerned with automatically massaging the commit stream into pretty reports. I’m told there is a complicated and clever feature involving XML rewrite rules that allows one to filter commit reports from any number of projects by the file subtrees they touch, then aggregate the result into a synthetic notification channel distinct from any of the ones those projects declared themselves.

(He somehow got this part slightly wrong. Incidentally, it was me who brought it up in #cia around August 25th in the first place. The projects’ own notification channels were as synthetic as any others from CIA.vc’s point of view. That is to say, not at all. Additionally, they weren’t XML rewrite rules, but rather commit matching rules.)

His opinion is, naturally...

Bletch! Bloat, feature creep, and overkill!

Yes, I admit that it is overkill, but it was a nice thing from our point of view as users of the system. There’s a line between using a service, and administrating it.

On the plus side, seeing as how irker aims to become an actual standard for IRC feeds of any sort (not just for VCSes), it is good that it only implements the most basic functionality by itself. This should later allow us to come up with ingenious applications such as nenolod’s CIA proxy for irker (delivers CIA.vc XML-RPC requests in a format suitable for irker). Some people have even proposing building new services using irker’s protocol, adding an authentication layer on top and integrating it to IRC networks as a hosted service!

But replicating the end-user functionality a few people like me enjoyed will invariably take some additional effort. ESR suggests:

Filtering? Aggregation? As previously noted, they don’t need to be in the transmission path. One or more IRC bots could be watching #commits, generating reports visible on the web, and aggregating synthetic feeds. The only agreement needed to make this happen is minimal regularity in the commit message formats that the hooks ship to IRC, which is really no more onerous than the current requirement to gin up an XML-RPC blob in a documented format.

Of course, if the #commits channel on freenode ever regains its former glory, this would require a bot to listen to and filter possibly thousands of messages per minute, all coming from multiple clients. I don’t think I am fit to become the pioneer who’ll conquer this new land.

Furthermore, since the task of formatting messages for individual commits is exclusive to individual hooks, we may end up with a highly fragmented and inconsistent ecosystem. For example, as things stand right now, no-one is required to include #commits on freenode as a destination for commit notifications, and I imagine very few people will bother to do so in the future.

All in all, it was our own incompetence that allowed CIA.vc to die prematurely despite the multiple calls for replacing it, and the obviously deplorable service conditions. We can’t really complain now.

I normally don’t comment or report on other sites’ status in here since this is my personal blog, but this situation actually impacts Wesnoth, Wesnoth-UMC-Dev, and me directly; especially me, considering I went to ridiculous lengths the other day to solve a related issue on GitHub.

The point is literally the title of this post: CIA.vc is dead.

You know, CIA.vc; that amazing service which provided real-time VCS commit notifications on various IRC networks and that everyone took for granted. This is by no means the first time it bites the dust, but in this opportunity it’s suspected that nobody really bothered to make backups.

nenolod (who was merely hosting the instance running CIA.vc) explained the situation in freenode’s #cia channel about an hour ago.

Assuming the other people who had admin access don’t have their own recent backups, CIA.vc’s future looks particularly bleak right now. Here’s hoping that a dedicated team of competent coders with access to a suitable server for hosting will quickly build a better replacement within the next few days. (Ha, ha, ha. Right.)

The idea of continuing and developing the Invasion from the Unknown storyline further was in my mind from the beginning, and I apparently started to work on a sequel on May 2008, if the Wesnoth-UMC-Dev Registry is anything to go by.

After the Storm’s development has been repeatedly impacted and put at risk by various “real life” issues.

Earlier this year, I decided to go back to work on the campaign after a long hiatus — so long I don’t remember how long anymore — but my attempt ultimately failed anyway. I promised a delivery, but the delivery did not happen.

Until I rediscovered the fun in video games with VVVVVV, Minecraft and Portal. Then, magic ensued.

I said I would try to finish the first episode of the campaign before December. I am glad to say that mission has just been accomplished. After the Storm 0.5.0 is out in the Wesnoth 1.9.x add-ons server, with the first episode (that’s 13 scenarios) complete!

For those who’d rather read a terse piece of text with no emotive speech in it, the changelog for this version follows:

Version 0.5.0:
--------------
* Scenarios:
  * 09 - The Triad (part 3):
    * Fixed problems with the final cutscene on Wesnoth 1.9.8 and earlier.
  * 11 - Return to Wesmere (part 2):
    * New scenario.
  * Completed episode I.
* Units:
  * Removed Skirmisher ability from Elynia.
  * Spawners have a small chance of deactivating themselves after spawning a
    unit.

I have tried to make sure AtS remains playable on Wesnoth 1.9.8, but my primary development target is still 1.9.9 and support for 1.9.5, 1.9.6 and 1.9.7 is mainly theoretical at the moment. If you encounter any “Invalid WML errors” or such, and you are using Wesnoth 1.9.7 or earlier, try with Wesnoth 1.9.8 or 1.9.9 instead if you can, and give me some feedback in the forum thread so I can address any such issues as soon as I may.

I take this opportunity to remind you that you can also find and follow me on Twitter as @ShikadiLord or join my personal channel ##shadowm in the freenode IRC network.

Have a lot of fun!

Today, after the Wesnoth-UMC-Dev reached its most important milestone, I have decided to step down from the project administrator position to leave the decision making and user support tasks to Espreon and AI0867, who have done an undeniably good job in my absence the last year while I was busy working on other projects.

This does not mean that I’m completely breaking my ties with this exciting platform for add-on development which ESR and I founded. I’ll continue to take care of infrastructure matters such as the website design, content and coding, the Registry tools and miscellaneous utilities whenever I have time; I’m not going to abandon After the Storm either, since I continue to be a user of the project either way.

I mentioned that I’d be following up the official r10000 announcement with the history of the Wesnoth-UMC-Dev Project. Most of the content below is taken from an interview I recently had with BfWEthnographer which eventually touched this subject.

The Coordinated Wesnoth User Made Content Development Project, better known as Wesnoth-UMC-Dev, has today reached SVN revision 10,000.

Here’s the official announcement.

I’ll soon post details about the project’s history here.

I accidentally stumbled upon this Wesnoth.org forum post this night while searching for suspicious (read: spammy) activity — which gave me the following idea:

<shadowmaster> http://forums.wesnoth.org/viewtopic.php?p=481052#p481052
<shadowmaster> "Inferno8 and I have agreed that we want more publicity and exposure for the campaign, including promotion and review on indie gaming websites. [...]"
<shadowmaster> Espreon:
<shadowmaster> AI0867:
<shadowmaster> I have an awesome idea
<shadowmaster> let's take UtBS, IftU and AtS (and optionally TSL) out of Wesnoth-UMC-Dev
<shadowmaster> let's go big
<shadowmaster> let's create a separate OSS project for them
<shadowmaster> game engine included
<shadowmaster> let's strip Wesnoth of all the shit we don't need and build a better engine
<shadowmaster> for Project Y.
 * Espreon chuckles
<shadowmaster> DEAL? [Y/N]
<shadowmaster> We could even take Aethaeryn 's Thunderstone with us
<shadowmaster> think of it
<shadowmaster> "Project Y: Thunderstonecraft"
<Espreon> Someday Ignacio, someday. We don't have enough minions at the moment.
<shadowmaster> The Battle for Irdya!
    -- ##shadowm, 2011-03-07

I think this is a possibility I never considered before, and a fabulous idea which I should steal, in good old Shadowmaster tradition.

If you want to make this possible, join the IRC channel ##shadowm on chat.freenode.net with your favorite IRC client, or use one of the links below!

• IRC client link
• freenode webchat link

In case you can’t tell, this is a joke.

Since my last post on the matter, I have had the opportunity to experiment with Mercurial and Git much more for my own projects in order to investigate options for the Wesnoth-UMC-Dev Project. A random forumer recently raised a stealth complaint against our usage of SVN, and he seems to prefer Mercurial (I can’t blame him for it, since SVN sucks at every conceivable level), but I don’t think it is the solution for our usage scenario.

To get it out of the way, I do use Mercurial to manage the Spanish translation for the Atheme IRC Services suite, and more recently, Hakone and Poison Ivy are hosted at Bitbucket (which is pretty cool, especially since it has out of the box support for CIA bot notifications).

The problem, as all Wesnoth-UMC-Dev related issues are, centers around the learning curve for non-tech-savvy newbies.

Mercurial uses a very strange user-level commit representation that involves a revision number and a hash, like 136:5c70e078efce (Hakone tip as of this writing). The only component in this commit specification that matters to most commands is the hash — the commit number is just there for decoration.

This is particularly jarring when history becomes non-linear.

changeset:   136:5c70e078efce
tag:         tip
user:        Ignacio R. Morelle <shadowm@xxxxxxx.xxx>
date:        Sun Jan 09 03:37:37 2011 -0300
summary:     application: Normalize capitalization of "Wesnoth-UMC-Dev"

changeset:   150:5c70e078efce
parent:      148:537ad43f161b
user:        Ignacio R. Morelle <shadowm@xxxxxxx.xxx>
date:        Sun Jan 09 03:37:37 2011 -0300
summary:     application: Normalize capitalization of "Wesnoth-UMC-Dev"

These two commits are, as far as the content (diff) is concerned, identical. The only difference is that one resides within my local repository on my hard disk on a clean tree that doesn’t have any merges; the other is on the live Wesnoth-UMC-Dev website and has several merges resulting from the lack of the rebase extension in the Hg version we are using.

What’s wrong, you may ask? Those who are used to DVCSes won’t see anything of interest here. Those who are used to CVS or SVN will notice that the “revision numbers” in here differ for the same commit. Why is this? Because of the multiple merges down the history in the website’s repository. This is an arguably ridiculous case of non-linearity that could have been solved with the aforementioned plug-in if it were available on the system version we are running. However, it’s not too far from what would happen in an actual project with multiple contributors with direct commit access.

So, just like in Git, the ultimate solution for commit management is using hash specs. And that scares newbies because hexadecimal numbers are 1337 |-|/\XX0|3 stuff or something.

But unlike Git, the solution to our problem requires manual activation (~/.hgrc), and isn’t built into older Mercurial versions.

[extensions]
hgext.rebase =

Does this make sense to you? Good, because it doesn’t to me. Maybe it’s a cool way to demonstrate how extensible your VCS can be, but for me this is just ludicrous.

Git, on the other hand, is as bloated as a Swiss Army Knife, and you might not even need most of what it ships with — which is good, because not all of us are Linux kernel developers. Fortunately, the authors are not evil enough to try to lure unsuspecting clueless users with fake revision numbers.

(Incidentally, Mercurial is implemented in Python. And I hate Python, as you know. Coincidence? I think not.)

After so much work, codename “Hakone”, the new website layout and software powering the Wesnoth-UMC-Dev website is finished, bringing with it a series of changes to begin to renew the project for the upcoming new year.

Ancient, old, and new

The Wesnoth-UMC-Dev website has gone through three revisions counting “Hakone” — “Soradoc” and “Kalari” being its predecessors.

My emphasis during the construction of codename “Hakone” was placed on functionality, standards compliance at the web interface level, and a soft, elegant and modern look, all of which I think have been accomplished. Through the integration of technologies such as XML feeds using SimplePie, and the minimalistic yet extensible blog engine provided by Blosxom along with our homegrown Poison Ivy PHP engine, we have achieved our ultimate objective of establishing our own network identity as an independent, parallel project to Battle for Wesnoth.

We have also added an embedded IRC client using freenode’s neat webchat gateway, available from within the Contact section. This should pave the way for further coordination between developers and repository administrators using our official discussion and support channel.

In this opportunity I’ve also opted for standardizing the spelling of our short project name to “Wesnoth-UMC-Dev”, as opposed to the earlier “wesnoth-umc-dev” and “Wesnoth UMC Dev[elopment]”.

There are bugs that remain to be fixed though, which are related to the feeds handling within the various site components — but nothing that is going to matter for the moment due to our rather restricted audience.

So there goes another bit to add to my web design stories, an experience from which I’ve learned a lot of valuable information for my work on “Dorset5”.