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”.

The Wesnoth-UMC-Dev Project website is now running with the Hakone layout system, but the blog section is currently not operational due to administrative issues I hope to have solved within the next 24 hours.

Although I had originally set the completion deadline for codename “Hakone” to March 2011, after one week and two days of development it’s close enough to final for an early deployment, hopefully before the end of the year.

    

This is the fifth website layout I’ve designed, now joining the list along with “Dorset0”, Dorset, Soradoc and Kalari — but Hakone is somewhat unusual in that its CSS was written from scratch rather than being based on a previous template, while less than 40% of the basic HTML structure was inherited from Kalari.

Hakone is also the first site layout in which I reset margins and padding attributes for all HTML elements and specify them manually instead of allowing the web browser to use its internal defaults. This technique appears to work much better across browsers than my previous selective overrides. Consequently, Hakone looks very good and usable on IE 6 and 7, despite the usage of CSS 2/2.1 and 3 features in some places.

To get an idea of how much Hakone has changed since its first incarnation, take a look at this ’shot:

Besides the renewed appearance for 2011, Hakone is also intended to bring some functionality improvements and administrative changes around the place. For starters, the front page will pull feeds from a local blog which will be deployed using Blosxom for simplicity, in which we’ll dump any important updates we deem appropriate to share. Interestingly, we used to have a blog at the Wesnoth-UMC-Dev website at the beginning, but the lack of interest from the other admins doomed it to death.

I also intend to add XML feeds support to the Registry Service frontend in order to announce newly added users and projects. I don’t know yet how that’ll be achieved, though — but bet on an update here as soon as I have a plan for it.

By adding more documentation to the Wesnoth-UMC-Dev 2011 website we should also be able to drop most of the contents of the official forum thread, which is currently unmaintained and redundant.

Finally, with all these changes we hope to attract more add-on authors and maintainers to our project. Despite a few administrative issues, we have already hosted large and popular add-ons such as Ageless Era, and campaigns which are currently part of Wesnoth’s mainline, including Legend of Wesmere and Delfador’s Memoirs. We don’t know yet where the community will take us next year, but I expect some amazing work to come out of the repository soon.

The Wesnoth-UMC-Dev Project has been around for quite a while now and it’s helped in the preparation of three user-made add-ons for entering Wesnoth’s mainline repository. As time passes more content finds its place into our facilities and more people learn to take advantage of Subversion. There’s still more to come, as ESR and Fabian Müller (fabi/fendrin) are working on a new drake campaign for mainline titled Wings of Victory.

We are currently in need of more people interested in helping around with repository maintenance and application processing tasks, though. Espreon, AI and I do our best to handle new registrations and keep everything tidy and clean, but we also have projects of our own!

As part of a series of changes I hope to have ready before March 2011 — just in time for our 3rd anniversary — the development of a new website “skin” codenamed Hakone, has started today.

I already have most of the CSS rules working, but this template is not leaving the early development stage soon, for I still want to try new and crazy ideas on it before the final deployment phase. In particular, I want to reorganize the site structure at the same time to make it more accessible to our target audience while providing as much documentation as we can. You can have a taste of the preliminary plan clicking on the screenshot above.

Due to my unusual workflow, things are likely to be dropped, replaced and added as I deem necessary or convenient. I’m going to make use of Twitter to post major updates as I go during the next few months.

Finally, I’ve also been making steady progress on improving Rei 2 IRC Bot’s power and cleanness, and for a couple of weeks Shikadibot has been running with her core instead of Shikadibot 0314’s (R.I.P.). Nonetheless, #wesnoth-umc-dev’s bot is unlikely to change much in terms of features, as she doesn’t run with all of Rei 2’s modules for the sake of resource saving.

Being just two years old, the Wesnoth-UMC-Dev fulfills its mission again and beetlenaut's Dead Water has just entered mainline (about 45 minutes ago)!

Since its inception on March 14th 2008, Wesnoth-UMC-Dev has hosted and served as a staging area for the following mainline campaigns:

• Legend of Wesmere (entered mainline on October 7th 2008, 02:28 UTC)
• Delfador's Memoirs (entered mainline on April 10th 2009, 02:08 UTC)
• Dead Water (entered mainline on April 6th 2010, 17:02 UTC)

My own software projects tend to be very much like pets to me. I take care of them, carry them with me anywhere if it's possible, I feel horribly sad when something bad happens to them and, even when I go mad at them for something, in a few hours we are together like a neat happy family again.

Invasion from the Unknown has been the Wesnoth add-on project of mine since around September 10th 2007 and it has evolved throughout time and endured 3 mainline development cycles introducing drastic game engine changes, receiving little automated help from the likes of wmllint. Instead, it has been kept on shape by me and a few people who have helped with the huge maintenance burden that this epic-length campaign is.

Inspired by what ESR has to say regarding migration from SVN to the Git version control system in practice, I decided to start “considering” actual options for abandoning that unsafe, annoying and apparently not very scalable centralized version control system known as SVN in one of the only remaining projects where SVN is still used and I'm involved as a developer. In this case, I'm the founder of this project, good old Wesnoth-UMC-Dev.

More specifically, I've decided to take a realistic look at the options as they present themselves — and since Git is a hot topic on both the mainline Wesnoth Project and Wesnoth-UMC-Dev, exploring our possibilities with it sounds like a good way to begin yet another “mayhem” series in this blog (oh boy, I need to categorize those).

Note that I'd normally have posted this in the wesnoth-umc-dev blog if it still existed — it wasn't being used by anyone and the information it contained has been moved and expanded upon in other web pages of our site. Blame AI0867 for that.