Since I have tested and developed this campaign primarily on Wesnoth 1.11.x since the 0.9.0 release, this version promotes support for Wesnoth 1.11.8 to official status. Because most of the campaign makes use of 1.11.x-specific features (both from me and other mainline developers) when available, it is quite possible that I will entirely drop support for Wesnoth 1.10.x in a future release even before the first Wesnoth 1.12 beta arrives. I still intend to make sure certain additions and changes for episodes II and III land before the last AtS version supporting 1.10.x, if time permits.

This 0.9.9 release primarily deals with prose corrections and improvements, and various other ‘cosmetic’ changes. There are also various fixes for some instances of dysfunctional AI recruitment on Wesnoth 1.11.7 and 1.11.8 resulting from the recruitment_save_gold aspect being enabled by default in those versions (but not 1.11.9 and later).

There isn’t much in terms of new graphics since the prose and code changes (plus some mainline stuff) have kept me far too busy to do much more than some doodles. On the other hand, this release contains various animation fixes and improvements to the Aragwaithi units ported from Era of Chaos. There are also a handful of balancing changes affecting both Aragwaith and non-Aragwaith units.

Also featuring in this release are a number of WML optimizations intended to reduce campaign load times — especially on 1.10.x, which has a slightly slower tokenizer implementation than 1.11.x. Since the affected bits of code have been completely rewritten in Lua, it is possible that I accidentally introduced new bugs in the process that I may have missed during my playthrough, extensive as it was.

There is also a new secret feature that is not mentioned in the changelog. What is it, you ask? Well, if I told you, that would ruin the surprise. Think of it as a Christmas present!

Finally, from this release onwards, After the Storm is no longer part of the Wesnoth-UMC-Dev Project, and will be hosted on GitHub instead. Ever since development of the campaign started, Wesnoth-UMC-Dev provided SVN repository hosting for both After the Storm and Invasion from the Unknown, but over time that has proved to be an inefficient solution due to technical and organizational concerns. Although the conversion process was not easy in the least, I believe that this move will make things easier for me in the long-term, since I had been using git-svn to work on IftU and AtS since late 2008 anyway.

Release tarballs will continue to be hosted by Wesnoth-UMC-Dev for the time being, until I decide to phase them out entirely in favor of GitHub’s Releases page. If anyone is using them because they cannot normally download AtS or AtS_Music from the wesnoth.org add-ons server, I’d appreciate it if you let me know so I can make a more informed decision in the future (or point you to add-ons.wesnoth.org, that works too). For the time being, the tarball compression format has changed from Bzip2 (.tar.bz2) to xz (.tar.xz).

⁂

Special thanks to vultraz and 8680 for their proofreading assistance, without which this release would be about 1% less awesome. Also thanks to the current and past Wesnoth-UMC-Dev admins, AI/AI0867 and Espreon, for their continued support all these years — IftU and AtS simply wouldn’t be the same without Wesnoth-UMC-Dev.

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

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.

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.

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:

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:

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

[...] 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.

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:

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 @ShikadiQueen or join my personal channel ##shadowm in the freenode IRC network.

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.

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.