It’s almost over. Time flies even faster as we get closer to the end of 2010, and apparently there’s a lot to summarize despite we’re not in the finish line yet!

This has been a particularly difficult year for me in a more personal sense, and I’ve faced some trials I won’t speak about and then some, but I’ve also learned new things in the road — things that may be of greater use to me in the future. There’s really a lot that could be said about this year but I’ll restrict it to computer stuff to avoid boring the audience too much bore the audience as much as possible.

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.

Due to general laziness, it took me a long while to research how to make my EPSON Stylus TX105 multifunctional inkjet printer work natively on Linux. I got one of the steps done, arguably only because it was relatively easy to do on a Debian system without messing things up too much — I got the printer piece working on May 2009 with Debian GNU/Linux 5 “Lenny.” Ever since then, I’ve stuck with Windows Vista for scanning and Linux for printing.

This is not the case anymore, now that I’ve learned better. This is one of the many ridiculous things one may need to do when stuck with old hardware that doesn’t work on Linux out-of-the-box. In comparison, I recently installed a Brother HL-2140 laser printer by just plugging the USB cable and waiting for KDE to tell me that the device was configured and ready. Amazing.

So, without further ado, here’s my personal recipe for making the TX105 work natively on Debian GNU/Linux 6 “Squeeze.”

Despite Mordante/SkeletonCrew’s absence from the #wesnoth-dev IRC channel for a while, I’ve still been making progress on converting more parts of the Wesnoth game interface to the GUI2 toolkit. As I mentioned before, completing the transition to GUI2 is an important step towards the next major milestone that is Wesnoth 2.0, and there’s still a lot of work to be done in this area.

Yesterday I pushed a set of commits that convert the Campaign Difficulty selection dialog to GUI2, as part of the changes for Wesnoth 1.9.3. Although It was rather simple to implement, I had to refactor out from the in-game character dialog ([message]) window some code to parse the legacy GUI1 menu items markup, which is now possible to combine with Pango to achieve funky effects in the difficulty menu like what After the Storm already managed with GUI1, and more.

As a result, both the campaigns menu and the difficulty menu consistently use the same toolkit now and there’s even less remaining to be done to discontinue the usage of legacy widgets:

• The whole gamemap view and the surrounding UI still use GUI1 elements, as do context and main menus in the game.
• Every dialog with unit previews (debug-create, unit list, recruit, recall, load game, level-up) still needs to be converted to GUI2. There are experimental versions of the Load/save game and Debug-create dialogs in development since a while ago and they can be previewed with the --new-widgets command-line option.
• The whole help system and the Credits screen accessible from the main menu still need to be converted.
• Story screens don’t use GUI2 yet but they do use Pango for rendering text on the title and body regions.
• The game preferences, hotkey configuration/input and network progress dialogs still use GUI1.
• The add-ons manager (install/update) dialog needs to be remade in GUI2 as soon as possible in order to address the many usability complaints found in the Ideas forum.
• The End-of-game and loading screens still use what I like to call “GUI0”, a widget-less presentation format that uses the legacy SDL_ttf-based text rendering code.
• The game status and statistics windows.
• The multiplayer game setup and waiting screens also need to be converted to GUI2, although an experimental/WIP version of the former is already available.
• Floating text labels in the game still need to be converted to use Pango instead of SDL_ttf.

Despite the possibly incomplete but long list above, we are much closer to having a consistent game UI that can be later updated and polished as necessary without the involvement of ugly and hard to maintain hacks. Eleazar and West already have some cool ideas which would be nice to implement in the near future.

I just finished upgrading the X.org server on my laptop from Debian Squeeze/Sid’s version (1.7.x) to 1.9.2 from the Experimental repository. It was quite a task since my initial command pulled some incorrect dependencies and then forgot some.

sudo apt-get install -t experimental xorg xserver-xorg

This installed the ATI Catalyst and NVIDIA drivers along with pretty much every video and input driver for some reason, which I had to manually remove later — this even though I had disabled Recommends. Since my laptop runs with custom builds of Mesa, the Radeon DDX and the DRM library, I had to rebuild those by hand as usual, but that wasn’t enough to make my system usable again because I forgot to upgrade xserver-xorg-dev, of all things. So, rinse and repeat, and voilà…after several attempts, my X server works again!

sudo apt-get install -t experimental xserver-xorg-dev

Of course, all this calls for the question: why am I using Debian Sid+experimental instead of sticking to a different, more “updated” distribution?

The fact is, I feel comfortable with Debian even though my installation isn’t a normal one anymore because I have foreign stuff I require for testing purposes, X.org included. I can manage myself very well no matter what happens, as you can see above — the little exercise I mentioned lasted for less than 20 minutes because I know how the system works so I can fix it if it breaks — I’m definitely not recommending random people to do whatever I do in any case. But after trying Sabayon GNU/Linux on my desktop box (Blackcore), I know for sure I don’t want to replace Debian with it. I am also certain that openSUSE is not what I want anymore, and this has a lot to do with the package management architecture employed.

It should also be noted that the only reason I’m using stuff from Experimental right now is that Squeeze is frozen, so basically no new upstream versions are entering Sid until Squeeze becomes the new stable. I’m not running away of any bugs — rather, I’m searching for more bugs to face and I’m not afraid of them.

Now I go back to bug-hunting on the Radeon DDX!

Just a few hours ago I reorganized the site’s front-page in order to make it more readable and visually cleaner. As a side-effect, users of Internet Explorer 6 got lucky and should not be seeing glitches there anymore, at least at large window sizes.

But that’s not what I came to report. Just a few minutes ago I deployed version 0.1.0 of codename “Asuka”, the new fortunes database viewer running on a little hidden page in this site.

• Wesnoth fortunes database

I know. It’s utterly useless, but I still had fun writing it, even if it’s neither the cleanest nor the fastest piece of PHP ever made.

Frequent visitors of the Scenario & Campaign Development Forum at Wesnoth.org’s board may have noticed that there’s a release announcement for After the Storm version 0.3, which is available at the official 1.9.x add-ons server and at SourceForge.net thanks to the Wesnoth-UMC-Dev Project.

I’m certain at this point that I can’t promise regular updates, but I’m trying to resurrect this project after a long period of inactivity that unfortunately followed the ceasing of development on its predecessor Invasion from the Unknown.

The truth is, I have been busy with all sorts of stuff this year — as a result, AtS has had to endure some parental abandonment. Although things aren’t becoming much easier for me in the following weeks, I hope to be able to finish episode I by next February, if not earlier.

As for IftU, I may resurrect it for 1.9.x if my time and creativity allows. Some convenient conversions of WML code to Lua are already done in SVN trunk, and at least the first scenario works, but more testing is required. In any case it’s unlikely to see the sunlight again until some more drastic (non-technical) changes I have planned become possible.

A few days ago I got bored and decided to give the Wesnoth GUI2 transition, as described in this post a bit of help. In consequence, all of the following dialogs in Wesnoth trunk, after the release of version 1.9.2, have been converted to GUI2 and should be able to display languages such as English (Shavian alphabet) correctly.

• Every confirmation dialog in the game with exception of the add-ons dependencies resolution window (revisions 47443, 47445, 47446, 47447, 47448, 47450, 47451, 47509.)
• The gamemap labels editor dialog (revision 47482.)
• Four list-type dialogs:
  • Selection of the next scenario with the :cl debug command (r47463)
  • Display resolution list in Preferences (r47469)
  • Theme selection in Preferences (r47472)
  • List of installed add-ons for removal (r47467)

This should be considered yet another step forward for GUI2 and the Pango-based text rendering in trunk, bringing us a tad closer to the much awaited… Wesnoth 1.10 release.

Long ago, Jetrel from the Battle for Wesnoth Project contacted me regarding possible extensions to the image path functors module of the game engine.

One of those extensions, which I implemented just in time for Wesnoth 1.6, and later gave it a separate syntax of its own was palette-switching using the same secondary algorithm used by the game’s color range-based team-coloring code. The ~PAL() functor, originally implemented as an extension to ~RC(), was thus born.

Wesnoth RCX 0.2 is not out yet due to some heavy refactoring that’s in progress, but a major feature that it’s going to sport in this opportunity is the ability to define custom color ranges and palettes.

The aforementioned extension to the game engine, which I shortly merged into the command-line based Wesnoth-TC tool, was originated by a possibility Jetrel discussed with me on IRC, namely randomizing individual units’ hair colors (and other compatible traits) on recruit. This sure doesn’t sound like a major task from the C++ side, and in fact the only thing missing right now is a transparent mechanism for defining these variations in [unit_type] nodes. However, it involves heavy revisions in the art department, to clear any traces of paintbrush strokes and sprites using excessive shades of a single color.

The goal: defining strict palette sets for recoloring. Above: Jetrel’s WIP revised baseframes for some of the elves.

Since trying artwork transforms like this in the game can easily become a tedious task (and not just because of the WML coding), Wesnoth RCX is soon going to step forward and provide artists with the ability to try out their own color ranges and palette sets and tweak them as required until achieving the wanted result. I hope that Wesnoth RCX will not just become the artists’ favorite tool, but more like an essential item for the mainline art development workflow.

Another couple of features are also going to feature in 0.2: zooming (suggested by artisticdude in the forums), and compete drag-n-drop support, so users can drag the transformed image into their favorite image editing application for further tinkering. I’m sure Mac users will especially like this new addition.

Some may recall that during my review of Wesnoth 0.1 I found a mysterious package inside the 0.1 distribution named strategy-source.tar. On closer inspection, the contents turned out to predate the sources of the first version of Wesnoth released to the general public by at least four days. However, I didn’t try to compile or run the mysterious application in that opportunity.

We are now going to take a route back in time to codename “Strategy”, which is a prototype version of the same engine powering Wesnoth 0.1. For readability purposes, we’re going to dub it Wesnoth-00 and proceed with the review.

In this article, I use a Win32 build running on Wine (1.3.6), with a single patch applied on it to not make the game go 1024x768 fullscreen. The data files are those belonging to Wesnoth 0.1, since the prototype archive only contained the source code.