After some weeks of inactivity, I have finally completed the first arc (not the first episode, though) of After the Storm in the Wesnoth-UMC-Dev SVN repository, comprising 7 scenarios out of planned 11; this means that a 0.3.0 release is coming soon. It was about time!

With this new arc completed, I have introduced new background story elements that could be considered controversial if any mainline purist is actually paying attention to the campaign — that's okay, I never intended IftU or any sequels to be mainlined. I still struggle to keep everything as fuzzy as possible to give a certain degree of flexibility to any content authors who decide to take what is said in IftU and AtS as “canon”. It's harder than it sounds, particularly because it must still be clear enough to allow the plot to progress; so I cannot just throw a bunch of nonsense into the campaign and say “hey, look at this, this is our vague excuse for this pathetic plotline!”.

Now that the characters have a decidedly vague excuse for the plot of the next arc, I face a problem that I knew I'd have to handle sooner or later: artwork.

I am not a good pixel artist, but I don't have any loyal slav- pixel artist that could help me either. And even if I could get one, I'm not completely sure I could describe the concepts I have in mind in plain words to tell them what unit sprites I require. There's also the spoileriffic factor; there's a reason that I removed the original (clumsy) storyboard from the SVN repository and departed from the original plans, most notably by removing a main character and introducing two new sidekicks instead. So, it's up to me to create any pixel art needed to make the campaign work; baseframes are enough for this purpose, although I still wish IftU and AtS' original units had animations.

At least I don't need to write a game engine from scratch too, thanks to Wesnoth's scripting flexibility.

It's year 2010, and, despite the promises, there are no flying cars, no jetpacks, people still die, there's no interplanetary travel, no apocalyptic event triggered by humans made Antarctica disappear on 2000, and most importantly, we are still awaiting the day we can have our own robot pals.

But here's IRC to solve that! No, really! What do you mean, it's not awesome!?

Okay, obscure references aside, the Wesnoth-UMC-Dev started as a fairly casual repository set up by me and Eric S. Raymond for managing a few add-ons that were, at that time (March 2008) candidates for being mainlined at some point of the future: Invasion from the Unknown, Legend of Wesmere and Delfador's Memoirs. Guess which of them has not made it to Wesnoth's mainline project yet.

The way we worked before was fairly different to what we do nowadays. Some time before AI0867 joined me in this quest, I decided to open the “UMC Sandbox” for projects not intended/expected to be merged into mainline. This had some unexpected success by the end of the year and we got a fair amount of add-ons to manage. As I write this, I'm wondering what the hell we are hosting anymore — I lost track!

At the beginning we also had a wiki page at Wesnoth.org with the list of projects and authors. AI0867 and I tried to keep it up to date at all times, but we inevitably forgot its existence after a while. The fact that Wesnoth.org crashed around July 2008 and stayed dead for nearly one month, and was resurrected from 2 months-old backups didn't help. When I remembered the page, I decided to wipe the rusty listings out; the only thing that survived was the admin list, which is now happily hosted by AI0867 on our project's website.

But it'd benefit everyone if we didn't need to look at SVN directory listings or history to check what add-ons we host, or who are in charge of them. To solve this problem, two new services are born: the Statistics service (umcstat, codename “Listra”) and the Registry system (umcreg, codename “Thoria”). I've been asked about their purposes and goals a few times lately, mainly because umcreg is finally reaching completion, so here it is; a thorough description of our new pals.

It took me much less time than I expected to put the new layout of the Wesnoth-UMC-Dev website together. Observe.

Okay, that's basically because most of the design was already made long time ago, in the form of the site's earlier incarnation, codenamed “Soradoc”, which looked rather busy and useless with the sidebar and other design elements. The new design, “Kalari”, removes the sidebar, clears the site banner a bit, and blends the site with Wesnoth.org as far as appearance is concerned. It's not the same design, but it's similar — that should be a good thing considering the purpose of Wesnoth-UMC-Dev.

That site also had a Blosxom-based blog, but I removed it since nobody was making actual use of the space.

The greatest thing about all this is that most of the PHP, “Poison Ivy” was finished in 1 night, while the rest took me just a few additional hours. Now that Poison Ivy is completed, I can reuse its code for the next incarnation of this very website and blog.

It's all for teaching some web design and programming basics to myself, really.

(No, not that one.)

There are many content management systems out but all of them seem to require some sort of database server and occasionally sacrifice flexibility in favor of ease of use.

This is why neither this site or Wesnoth-UMC-Dev's use one of those nifty software packages although they still use PHP. The latter website uses a bunch of ugly code codenamed “Soradoc” which has the actual XHTML layout embedded on it; the CSS stylesheet is also codenamed Soradoc and it's derived from “Glamdrol”, the Wesnoth.org wiki skin by Ettin; and “Dorset”, which is Soradoc's immediate ancestor, used on this very personal website — which in turn uses PHP code derived from the current incarnation of “Soradoc”.

Enter codename “Poison Ivy”, which is basically the same thing as Soradoc/Dorset, except written from scratch, much cleaner and more flexible; in particular, the XHTML layout and the site configuration are no longer part of the engine's source code which will allow me to share that among both websites more easily. It also introduces seamless support for document compression, which may be useful for my personal website.

Ivy is mostly finished, but I'm now busy reworking the Wesnoth-UMC-Dev site's design under a secret project, codename “Kalari”. Maybe once I'm finished with that, my next web project will be bringing umcreg (codename “Thoria”) to life.

(Okay, it's not a secret anymore. Dammit.)

At this point, I should know better than tempting fate in a blog post:

[...] Some days before Xmas, my creativity returned from its long, chaotic journey and my Wesnoth add-on, After the Storm (sequel to Invasion from the Unknown has seen steady progress and two new releases were published in less than two weeks. Keep in mind that this add-on had not seen any public releases for almost a year. [...]

Two days afterwards, my creativity disappeared like a drop of water in the sea, again — which means that After the Storm has seen relatively no progress since then. I hope I get better next week, because this work needs to be completed as soon as it's possible.

Finally, it's January! The New Year celebrations are mostly over and fading away, and people all around the world are going back to regular business and everything should be back to normal in a few days.

I used to be fond of the Christmas and New Year celebrations as a child as I could spend time with my family and eat delicious food. That is not the case anymore, because, even if I still live with my parents, there's no longer a sense of family here and we only want to throw sharp stuff at each other. There's not much enthusiasm by the end of the year anymore, and phrases such as “Merry Christmas” and “Happy New Year” (in Spanish, though) are truly unheard of in this house. Recent disagreements amongst us indicate that this is not going to be a good year for anyone. To add insult to injury, one of our cats died in a rather tragic and violent fashion on December 22th — it's a tradition here that one or more pets must always die in December. While we have many of them, the first ones to die are those whom we are most attached to.

To mark the actual start of 2010 (as far as the Gregorian calendar is involved, of course), there was a black-out on the area about 6 minutes 7 seconds past midnight, which left us with no Internet or tap water until around 1:50 AM. What a great way to start the first day of the year.

(In case there's doubt — I assure you, I'm not making any of this up.)

But there's still some hope at the moment. Some days before Xmas, my creativity returned from its long, chaotic journey and my Wesnoth add-on, After the Storm (sequel to Invasion from the Unknown has seen steady progress and two new releases were published in less than two weeks. Keep in mind that this add-on had not seen any public releases for almost a year.

After the last released version of AtS (0.2.1) including 5 of 12 planned scenarios in Episode I, there has been more progress in the Wesnoth-UMC-Dev repository. Just yesterday, I finished the two-part cutscene that is the sixth scenario of Episode I, one of the most important points of the plot's development, in which two forest elves finally make contact with the desert/Quenoth elves.

I won't be able to release AtS 0.2.2 or 0.3.0 until scenario 7 and the next cutscene (appropriately named “Resolutions”) are finished, since I'd be teasing the players otherwise. However, those who are really interested on it can always check AtS out from the repository's trunk into their <wesnoth preferences dir>/data/add-ons dir and play using the latest development version of Wesnoth:

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

It's really exciting to work with several plot elements from quartex's Under the Burning Suns in new, creative manners — kind of like Fanfic production taken to a new level using the power of the GNU General Public License (version 2 or later!). Nevertheless, I am fairly sure he deliberately left much details unresolved in the original campaign, and that he'd fry us (Espreon, AI0867 and me) alive if he found out what we are doing with his story.

One week before Xmas, the Wesnoth.org forums saw another upgrade on which Turuk and I worked hard and quickly to improve forum usability by not only upgrading the codebase to phpBB 3.0.6, but also tweaking the templates, adding modifications and a couple of new forum styles to take advantage of the new features implemented by the phpBB devs in this iteration of their software. The main points were highlighted in this forum post (originally a Global Announcement).

This year should also bring us a new stable series (1.8) of the Battle for Wesnoth game itself. There are currently some problems delaying the first Release Candidate and getting us flooded with generic beta releases, but the developers in charge of them will (hopefully!) find a solution so we can get 1.8 released and trunk “thawed” soon, to work on new features and allow new code contributors to join the project. As for me, I can't wait for the new stable series — development series players seem to be scarce and the new versions of IftU and AtS are receiving little feedback on the forums because of this! I suppose Multiplayer content authors are similarly eager to get more fresh meat to play their add-ons.

I also recently talked about how I can finally suspend my laptop to RAM using Linux, and run some basic OpenGL-based software without crashing or destroying anything. That's something I didn't expect to be able to do in the near future, so the Mesa, libdrm and X.org radeon driver developers have my thanks for improving the Linux experience of those unfortunate enough to own onboard ATI graphics controllers!

In summary, as usual, a new year brings good and bad news. I guess it's up to us to take what's good and fix what's wrong. So, anyway (although I guess it's pretty much unnecessary at this point): happy New Year and have fun!

(The Abridged version: let's get this party started already and kill some spambots! GAAAA!)

In my endless quest to make all the features of this ATI RS780-based HP laptop work completely with Debian GNU/Linux, I have come to great lengths. In summary, I have:

• Learned to use X.org modules from their upstream repositories and keep them always up-to-date, commit by commit;
• Patched the ACPI DSDT to gain thermal zone readings on Linux;
• Blown up the X server with ATI's crappy proprietary driver, fglrx;
• Nuked shared libraries in /usr/lib after attempting to use an RC Linux kernel version from mainline; and
• Upgraded Debian Lenny (stable) to Debian Squeeze (current testing distribution) and acquired superpowers involving the manipulation of time learned to use Tux-On-Ice.

Other people would have given up very quickly and sticked with Windows Vista, but no, here I am, spending time researching the problems in detail and running fsck after every forced reboot and reporting back to my Lair.

Fortunately, now I can see the light at the end of this very convoluted dark... tunnel thingy, and I have finally found the solution for one of the problems I have long sought to solve: the lack of accelerated 3D rendering.

While checking the Wesnoth.org forums ensuring that everything is working properly, I occasionally find spambots who have managed to make it past our hacky anti-bot registration measures, probably with help from humans. Most of these spambots go into a hit-and-run attack leaving one spammy post in some random place of the forums — sometimes in existing threads, sometimes starting new threads themselves.

Two nights ago (November 30th, 4:45 AM), some guy came into our Off-topic section asking this:

Post subject: Linux

How long does it take to become a Linux Administrator? Also is 1 year of linux study enough to get a job as System linux administrator? What exactly do I need to learn to achieve that goal?

It was his first post, and there were no signature or links whatsoever. He joined the forums two days before that (November 28th, 8:08 AM). You may note that the message above is not in proper English, but there are many underage or foreign users in the board. Nonetheless, some regulars and I replied to this guy's message in good faith.

On the next day, December 1st 8:36 AM, “he” edits his message adding spammy links after a fake signature separator similar to the phpBB 3 subsilver2 template's, except a bit longer. The post spent approximately 14 hours as search-engine bait because no other Wesnoth developers noticed the cheat (or read the Off-Topic forum, I guess) and I was away for the whole day until I went in and found this surprise after a third look at the thread.

Fascinating.

In one occasion I had one of these drones join the forums and make their first spam post after 6 weeks (and shortly get kicked out of the house by my Mighty Foot™). I guess it must have been collecting posts and feeding them to a learning engine in order to enhance future spam posts by fitting them into the board's context for the time being. Not that its own attempt at posting succeeded.

The problem is that they sometimes do manage to produce reasonable posts — as long as you use a very flexible definition of “reasonable”, which is more or less required around the Wesnoth.org forums these days especially since there are real people who join the board and never post anything constructive or interesting and roam just the Off-Topic forum asking weird, unimportant questions and answering other weird, unimportant questions with bogus, misleading or uninformed answers or opinions (no, not pointing at anyone in particular here). On the other hand, it's still possible that those weird guys or gals will eventually drop their masks and reveal their true identities as spambots. Or maybe someone else will remove it for them.

libpng is a the reference implementation of the PNG file format, which has become quite popular during the last decade thanks to the benefits of lossless compression coupled with multiple storage formats — including indexed pixmaps, RGB pixmaps with optional alpha channel, or 256 grayscale colors, adding Adam7 interlacing as an option to allow displaying incomplete drafts of images before reading all the pixmap data in the stream. It also allows for some metadata such as text comments and internal timestamps, or even unknown chunks of (meta)data, allowing it to become a container format of sorts, most infamously abused by Mozilla Firefox to implement animated PNGs through a slightly modified version of the library — because lossless RGB pixmaps with alpha transparency are so cool compared to indexed pixmaps with binary opacity...

As cool as this sounds, libpng by itself is a trap for the unexperienced and/or impatient programmer, of which I fall into the latter category.

The API allows for many different applications, resulting in a convoluted interface and some poor or missing documentation for it. Reading the manual and examples included with it does not help a lot; when skimming through the header one can find some undocumented interfaces. It's a hell of flexibility that makes me feel lost in middle of a big forest without a map.

I foolishly wrote Wesnoth-TC without knowing any of this beforehand, and ended up creating a monster known as version 1.0, which is a mess of quickly crafted ugly code that breaks under big-endian platforms and leaves huge memory leaks when running on anything. I could have used a different library but I didn't have more documentation than libpng's at the time. Now that I'm preparing to release Wesnoth-TC 1.5.0 and have learned to keep away from this library, I'm turning my attention to wrapper libraries that should be hopefully much easier to work with if I just want to read and write ARGB streams from/to PNG files.

But Wesnoth-TC 1.5.0 will still use libpng, although I'll rewrite the code that uses it. Why? Because this time, It's Personal.

Preparing the release of a fixed demo revision for my Wesnoth add-on After the Storm, which is the immediate sequel to Invasion from the Unknown, I ran into a rather nasty bug in one of the scripts I made for easy creation of .tar.bz2 packages for the Wesnoth-UMC-Dev Project, build-external-archive.sh.

The script in question is one of my earliest experiments with bash scripting, and as such suffers from the quirks of a novice programmer trying to get work done fast. It's some sort of crapload of hacks that just ‘‘works’’, somehow. I have an odd habit of tempting fate and using my earliest programming experiments in production environments — and this includes Shikadibot and Soradoc, which is the PHP-based layout code generator used both here and at the Wesnoth-UMC-Dev website.

The only reasons for not killing it are the following features offered to the selected few who know how to use it:

• It reliably produces a .tar.bz2 archive for add-on distributions on regular websites — including SF.net — provided a few simple arguments.
• It roughly* conforms to the Wesnoth .ign file syntax, although it doesn't provide the same defaults as the game engine.
• It knows how to cleanly handle SVN check-outs.
• There's built-in, automatic support for XDelta patch generation, provided the xdelta tool is installed and in PATH.
• Provides MD5 and SHA1 digests of produced packages and writes them to .MD5 and .SHA1 files for distribution.
• No suitable replacement has been provided yet.

* Espreon pointed out on the #wesnoth-umc-dev channel at chat.freenode.net, that build-external-archive.sh may match .ign patterns only in the add-on's root directory, and not in its subdirectories. This, of course, a bug.

build-external-archive.sh has got a few inoffensive bugs in the past, perhaps the greatest of which was a set of dependencies upon Linux distribution-specific conventions (why, hello there, openSUSE!). However, yesterday I hit the nastiest, yet unseen bug.

Since I usually use actual SVN tag check-outs for creating the packages, or get someone else to do it for me, I had not checked the interactions of this script with an input directory that is actually a symbolic link pointing to a directory containing files or paths matched by a _server.ign file. This tool needs to copy the input directory to a separate temporary directory in order to physically remove the files (actually copies) that match the aforementioned .ign patterns, and then proceed to run tar to wrap the modified temp directory into a nifty bzip2 tarball.

And how was it copying the input directory to /tmp when the input is not a SVN check-out? Without going into much detail, it is similar to this:

cp -a ${input_directory} /tmp/${output_file.fakeroot}.dir/${addon_name}

The -a switch to GNU coreutils' cp is equivalent to -dpR, which roughly means ‘‘be recursive, preserve timestamps, access masks and never dereference symlinks and preserve them!’’ So you can start to imagine why this would become a huge problem when the $input_directory is a symlink.

Such a small overlooked mistake ended up destroying the git-svn tree contained within my add-on's directory, which was indeed specified as a symlink in ~/.wesnoth-1.7/data/add-ons/After_the_Storm pointing to ~/src/wesnoth-umc-dev/git/trunk/After_the_Storm. The symlink itself was copied to the temporary directory and the removal of unwanted files took place on the original location instead of a temporary tree. This gave me that disturbing feeling of having a bucket with cold water dropped on my head whenever I accidentally remove files I wasn't supposed to remove. Thankfully, I had committed all my changes to the upstream SVN repository and only had to regenerate a git-svn tree to continue working after making the release using a fallback SVN check-out.

The correct pseudo-code, forcing symlinks to be dereferenced and timestamps, file modes and ownerships to be preserved, is actually:

cp -LRp ${input_directory} /tmp/${output_file.fakeroot}.dir/${addon_name}

As you can see, it's perfectly easy to screw up your own files with a technically small mistake in a command line. However, in this case some idiot (me!) didn't read the manual correctly and didn't notice that the -a switch had additional effects, and that's a big logical mistake. Fortunately, only Espreon, AI0867 and I rely on this script, as far as I know.

This tool is going to be eventually replaced by umcdist (codenamed Blackwater), which is written in manageable Perl, provides the same functionality plus archive signing with OpenPGP, and would be done in a few days if I actually concentrated on it — don't take me wrong, it exists and there's code written for it, but it still needs to be completed. Whereas build-external-archive.sh is a deliberately undocumented IftU-specific tool that was later inherited by the wesnoth-umc-dev project, umcdist is targeted to the project as a whole, it will have proper online and built-in documentation and it'll be readable by more than one person to allow easier bug-fixing and maintenance.

I was tired this afternoon after some work and decided to quickly hack something useless.

The result? There's now a little script that displays a random fortune cookie from a copy of the database kept in the Battle for Wesnoth project's mainline repository.

• Wesnoth fortune cookies (undecorated XHTML version here).

(And if you still don't get it...)

(... or why I am not a good father, explained in a ridiculously long article.)

As explained in detail in the recently overhauled projects section, Invasion from the Unknown and After the Storm are two campaigns I am maintaining as external add-ons for the Battle for Wesnoth Project with the power of the Wesnoth-UMC-Dev repository. Both are sequels to the mainline Under the Burning Suns campaign, and, in a way, to Descent into Darkness and the infamous The Dark Hordes as well.