A little more than two weeks after the release of version 0.6.0, After the Storm 0.6.1 is out! And just in time for Christmas Eve in Chile, too.

The last couple of weeks have been particularly productive, as I’ve continued to work on AtS Episode II with the help of my loyal assistants vultraz and Espreon, who have been a valuable help providing early feedback, play-testing, and proofreading. In order to keep people busy for a while, this release includes scenarios 4 through 7, and one cutscene-only scenario, adding up to five new scenarios in this version.

Version 0.6.1 was scheduled for this date immediately after 0.6.0’s release, but it was only intended to contain the finished scenario 4, which landed on SVN trunk on December 15th. Since I was left with plenty of time before the original deadline, I decided to continue working on as many scenarios as possible. E2S7 landed on the 22nd, 22:01 UTC. I would have continued working on E2S8 immediately, but since it requires one new unit baseframe, I decided to postpone it and aim for introducing all the final four scenarios in version 0.7.0 when it’s done (most likely by early to mid-January 2012).

For this version, I decided to increase the Wesnoth version requirement from 1.9.7 to 1.9.10, which was already recommended in the campaign description. While there’s no WML code or maps enforcing the version requirement yet, I’ll simply ignore bug reports against AtS 0.6.1 on 1.9.9 and earlier versions since the engine behavior changed a lot between 1.9.8 and 1.9.10 in some areas — it’s simply impossible to keep supporting old development versions now that mainline is releasing 1.9.10 and later as betas for the upcoming stable 1.10. Besides, as a mainline developer I must also encourage people to test the game and report bugs before 1.10!

Should this inconvenience you, I may be able to provide support on a case-by-case basis given a good reason to do so. My general recommendation if your Internet service isn’t good enough to download the bi-weekly Wesnoth 1.10 betas is to just download the latest one and keep it around until 1.10 final is released. By the looks of things, odds are this won’t happen until January.

The changelog for this version of the campaign is unusually long, even though I deliberately omitted some specific additions in the art department — six new baseframes, all made by myself and awaiting revisions in the near future — and unit WML. Since those are tied to the new scenarios, I decided to not spoil it in the changelog.

People using development versions or SVN trunk might find it excessively cumbersome to install Wesnoth’s binaries and data files whenever a new version is released (or commit made, for trunk). Since long ago (probably 1.3.x) Wesnoth supports overriding the data directory by providing its path as the last command line argument and, since 1.9.0, it’s also possible to use to use the --data-dir switch to avoid ambiguity with other switches taking path arguments.

Since version 1.5.4 (more specifically, r28934), Wesnoth will also try to locate a usable data directory by itself, by trying to locate data/_main.cfg in the parent dir of the executable file, which is resolved in Linux by making use of the /proc/self/exe symbolic link.

Until today, it had not occurred to me that this makes it possible to link to the Wesnoth binary from any directory, not just one containing the aforementioned WML file. The /proc/self/exe link points towards the final target if the process image is a symbolic link, so you can have a layout like this work as desired provided ~/bin is in PATH:

The Wesnoth 1.8 binary in this case is compiled with the scons prefsdir option set to .wesnoth-1.8 so conflicts with the development versions can’t occur — those use the custom .wesnoth-1.9 dir instead. Nowadays things seem to be a little more complicated in that regard, as seemingly the game will opt for an XDG layout if there’s no compiled-in preferences dir path on non-Mac, non-Windows builds. According to the EditingWesnoth article on the wiki, 1.8 builds default to .wesnoth1.8. Why the default doesn’t include a hyphen is beyond me.

With things set up like this, I can start Wesnoth from any directory without having to provide my own command line arguments. Of course, you could say this is a rather archaic approach as it’s also possible to create desktop/panel shortcuts instead, depending on the desktop environment. Since I spend more time looking at a terminal emulator with my hands on the keyboard than staring at the wallpaper and desktop icons with the mouse in hand, my own approach turns out to be more efficient for my purposes.

Finally, there’s an even less known feature introduced in r31261 (before 1.5.7) that also makes it possible to omit the --editor or -e switch to start the map editor if the game executable file contains “editor” in its name. This was added as a replacement for the old wesnoth_editor binary that provided the map editor before it was replaced with the built-in version (“editor2”) as part of GSoC 2008.

After the Storm 0.6.0 has just been released, despite the original deadline I set for myself just a few days ago being Christmas Eve. As a consequence, that day will be the deadline for AtS version 0.6.1 instead, which should include a working scenario E2S4 (i.e. fourth scenario of the second episode). Of course, if a major bug arises in the meantime, that tentative version number will have to change.

Apparently, I work faster when I feel the need to deliver within a specific time frame. In this case, the need stems from fear of public humiliation. Probably.

VVVVVV is a fun retro platformer which features gravity flipping instead of jumping, and some ridiculously hard rooms (the hardest ones are usually optional). It was part of the Humble Indie Bundle #3 earlier this year.

For a good while I've been trying to get the optional trinket in “Doing Things The Hard Way”, and apparently I got the hang of it at last. This is the first time I succeed in this little side-quest after something around 1000 attempts. Two (unexpectedly) failed attempts are also featured in this footage:

Sadly, for technical reasons I couldn’t record any sound, hence I decided to keep it unlisted in my account. The chiptune music and sound effects are, in my not-so-humble opinion, an essential aspect of the game and they may well be the only reason I accepted the challenge and completed all the main levels (back in August, granted, but there is replay value).

After completing the first episode of After the Storm, a short vacation was a logical option so I could return to work later with fresh ideas and more energy. By ‘vacation’ I don’t mean a traditional Wesbreak as most people do, though — quite the contrary, in fact.

For a long time I’ve been bothered by the haphazard-looking design of the Editor Settings dialog. This (already GUI2) dialog’s main focus is a bunch of lighting options intended for map or terrain authors to test what their creations look like under different Time of Day lighting presents, or even custom lighting, which is also useful for campaign designers trying to come up with an atmospheric feel within Wesnoth’s rendering engine limitations.

→

I don’t claim to be a UI design expert — I’m fairly certain I’m not — but I feel my vision of the dialog is better than the original author’s, and for this reason I recently committed to trunk these changes along with a couple of fixes for related long-standing bugs that were definitely not introduced by me. I think. I hope.

I am not keen on having Title Case on checkboxes, either, but for some reason the wiki says it’s what we should use, so I’m going to stick to that for 1.10 as it’s already used in most places anyway. I hope we can clear that up during the 1.11.x development cycle since even GNOME’s Human Interface Guidelines recommend sentence case for such elements.

The item selection menu triggered by the Starting Position tool in the editor was a generic GUI1 dialog, until now. I decided to tackle this conversion task and add a feature in the process: existing starting locations are shown in the second column of the player list, in the form of map coordinates. This is not too helpful since we already had keyboard shortcuts to reach starting locations in the map editor (1-9 number keys), but in my opinion looks nice. The giant help tip in the dialog description had to go though, but don’t worry, for the tooltip on the editor palette already provided the exact same information in a more consistent fashion with regard to the other editing tools.

→

And finally, something more useful for the large majority of the userbase: removing multiple add-ons at once without having to return to the Uninstall Add-ons menu. I have not committed this to trunk yet, though, and I’m not even sure I’ll be able to merge it before the feature freeze in preparation for the final lap towards 1.10 comes into effect.

As I previously reported, reicore’s hard disk might be dying. This is not surprising in the least, since I have been hearing loud noises from the drive during high activity since a long while — playing vanilla Minecraft is apparently the most straining task for it for some reason. Considering reicore didn’t present any such issues at the beginning, it’s possible the person who gave her to me when bluecore croaked did something bad to her while I wasn’t looking. He’s unlikely to confirm such a thing, though.

A short drive self-test last night revealed that one of the bad blocks is currently part of the very root filesystem. Since I started to consistently hit a bad block while logging into KDE, I decided to run e2fsck -c on all partitions from a Grml live CD system (also Debian-based).

(Yes, I just realized I inadvertently left the swap partition out of the emergency check procedure. I just ran badblocks on it in read-only mode and it appears to be clean.)

Scanning a 466 GiB hard disk for bad sectors isn’t a quick task, but it took just as long as it did with the 1.18 GiB disk on my first computer back in 1998 — about two hours and some minutes — and here are the good news: there are only two damaged sectors, both of them within the root filesystem, and only one file was lost: /usr/lib/libQtDesigner.so.4.7.3, provided by the libqt4-designer package in Debian wheezy.

Why the dynamic linker felt it necessary to access this file while launching Akregator and KMail during the login process is beyond me, but it’s good that nothing was lost, as I promptly reinstalled the package. Either way, I had a fresh pre-upgrade backup in my external 2 TiB hard disk drive ready just in case.

I’ll certainly have to get used to making backups more often than my previous, sloppy biweeklyn-weekly schedule. Thanks goodness for rsnapshot!

The last time I tried to switch from Debian stable to testing I was hit by a disease known as X.org Server 1.10, and more specifically, fd.o bug #31017, which made my KDE experience less than worthwhile, to say the last. The solution I devised was not particularly productive either.

However, X.org Server 1.11.1 hit Testing a while ago, and it’s what I am using right now — I successfully switched to “wheezy” again, today, and this time it would seem a massive rollback won’t be required, since the aforementioned bug is finally fixed.

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.

Wesnoth.org appears to have DNS issues at the moment, resulting in the site’s address being impossible to resolve to a numeric address (IP) for most people. We are doing everything that’s possible at the moment to restore it.

UPDATE: Apparently, it’s been solved already. However, the new records could still take some time for some people to have an effect due to DNS caching.

UPDATE 2: My own evidence indicates that it’s not solved yet.

UPDATE 3 (Oct. 3rd): It’s solved now. Some DNS servers could still claim wesnoth.org doesn’t exist, so just give them a few more hours.

If you trust me (since I’m the forum administrator and all), you can follow these simple instructions to fix your access to Wesnoth.org’s services in the meantime. If you don’t feel comfortable editing system files or don’t have admin access, you can try connecting directly to Wesnoth.org’s current IP, 65.18.193.12, but this will not work correctly with the wiki and forums which use the wiki. and forums. subdomains.

Do note that what I describe should be considered a temporary workaround. If Wesnoth.org’s IP changes in the future, you’ll need to remove any hosts file entries you added.

Linux, BSD derivatives

Note: make sure to backup your /etc/hosts file first in case you accidentally delete its previous contents, which could cause some applications to behave incorrectly.

Edit the file /etc/hosts with a plain text editor such as gnome-editor, Kwrite/Kate, vi/vim, Emacs, and such.

UPDATE: version 0.4.3 is on its way to the server due to a severe case of savegame corruption as a consequence of my half-assed fix for the poisoned recalls issues. Since I seem to be producing new releases faster than I can announce them, I’ll only be posting about major releases (such as the future 0.5.0) in here. For now, use the forum topic and the add-ons server to keep track of updates.

After the Storm version 0.4.1a is now available in the Wesnoth 1.9.x add-ons server. This version adds the tenth scenario to the first episode.

The current plan is to have 0.5.0 out with the first episode finished before December. I am not going to make any promises this time since I didn’t have much luck with the original schedule that required 0.4.0 to be released in April of this year.

After a record break of 6 months I got back to work on scenario 9 of After the Storm and completed it, in a fairly different fashion than I originally planed. Still, it’s another step towards completion of Episode I. Version 0.4.0 is available for download now in the 1.9.x add-ons server and SourceForge.net.

I think I have avoided to spread many spoilers about AtS’ plot since day zero; there were, of course, some early storyboards circulating around the forums and IRC at the beginning, but as I’ve been saying for quite a while, they are no longer canon and I am departing from the original plan on purpose.

I am fully aware that some people will not like my choices in 0.4.0, and they may even seem blasphemous, but the truth is I scattered enough foreshadowing everywhere to prepare them for the time being. What are these choices I speak of, anyway? Too bad, you’ll have to play the campaign to find out!