Just today I completed an initial, working implementation of an XML feeds reader in the Rei 2 IRC Bot framework. This implementation was pushed into master and I later tagged Rei 2 version 0.2.8, which will be eventually deployed on the shikadibot production instance, once this new shiny feature has seen enough testing and appears to be stable enough.

Thus my nearly 12 hours long coding spree culminates.

There were various design issues I faced when developing the feeds reader functionality. I already came across inefficiencies inherent to the legacy single-threaded model for SVN bot functionality found in Shikadibot 0314 and reimplemented in Rei 2; it’s not directly feasible to listen and respond to interactive events from an IRC connection socket while waiting for a reply that might never arrive from a SVN server. In the feeds reader case, more complications arise from the need to download and parse multiple documents from different remote servers in quick succession.

Rei 2 is still bound to the Irssi IRC client, and will remain so for a good while until the new S² state tracker is completed. The current situation is by no means bad as it allows me to concentrate my efforts on the bot’s outermost functionality layer, but the dependence on a non-native (i.e. C as opposed to Perl) backend places several constraints on what can be done in Rei 2.

Instead of resorting to threads — a possibility that I still don’t dare test with Irssi+Perl — I ideated a convoluted mechanism taking advantage of child processes and a simple caching strategy. Rei 2 forks its own helper daemon (rei2-feeds-worker.pl) when loaded (not necessarily always at Irssi’s startup!). This assistant simply fetches all XML feeds in the background every once in a while, and saves them to disk at a special location in the configuration dir — no more, no less. Meanwhile, Rei 2 sets up timed events to trap into the feeds processor and quickly work with what’s in the local on-disk cache.

Theoretically, this model could be extended to other Rei 2 modules, the SVN bot code being a particularly attractive candidate. It could be possible to either fork more unique helpers in the background, or somehow merge them all into another modular application. Either way, I’m not strongly interested on messing with the design right now other than researching more optimal mechanisms to monitor cache activity — inotify comes to mind.

• • •

For testing purposes, Rei2 on freenode already tracks the Wesnoth-UMC-Dev frontpage aggregator feed in #wesnoth-umc-dev and the Wesnoth.org’ Off-Topic forum posts feed in #wesnoth-offtopic. There’s also a duplicate feed of this very blog competing against one of my earliest private-use modules which has been reporting blog posts and Twitter updates in ##shadowm nearly since Rei 2’s inception. I’m meant to port the latter two to the new model soon-ish.

To celebrate this rather important milestone, I’ve updated the Rei 2 IRC Bot project page in this site as well with some new information.

As I resolved to do last New Year, I’ve been progressing with After the Storm slowly at irregular intervals of time. During these last three days I’ve given it a bit of thought in regards to the future development plans and the road to 1.0.

I have settled for the following milestones:

• 0.3.0 — Ep. I, first act completed (scenarios 1 to 5)
• 0.4.0 — Ep. I, second act completed (scenarios 6 to 9)
• 0.5.0 — Ep. I, third act completed (scenarios 10 and 11)
• 1.0.0 — Ep. II completed

Right now AtS is about to hit the last set of changes needed for the 0.4.0 release. The first part of the ninth scenario is already finished in SVN trunk, and the second part is a work in progress. There are two art issues pending, but I plan to proceed with placeholders for now if it’s needed to have a release before the end of April.

Don’t throw your shoes at me! I didn’t come to continue the overly long “display resolution” gag!

I have been thinking about some stuff to do during this year for a while, actually. It’s really hard to decide because I’m a person who runs into all sort of trouble while trying to get projects accomplished (including procrastination).

One thing I’m already doing is learning some Japanese, for no particular reason at all — although you’ve got to admit that having multiple languages in your curriculum is worth a bunch of coolness points. Espreon is helping me along the way with his own recently gained knowledge. It seems quite fun to learn a language in a non-Latin alphabet, if not a tad overwhelming at times, especially with kanji.

It’d be a good idea to lose some weight this year, too. My addiction to sugary stuff isn’t quite compatible with my heart condition! (Nor is coffee, but… meh.)

Then there’s Wesnoth. I intend to finish the Second Act™ of After the Storm Episode I as soon as I may, even through the means of placeholders — I’m willing to do anything to rescue AtS out of Development Hell before the end of 2011.

Wesnoth RCX’s development is halted right now due to lack of interest on my part to invest energy on writing the rest of the new functionality (i.e. definition of custom ranges and palettes), but I know that once I touch Qt Creator’s awesome interface I can’t stop working for a while — so I may eventually get some inspiration to redesign the main window, which should inevitably lead me to tinker around with the rest of the code.

C# was the first “major” programming language I learned, not counting Visual Basic. I have some fond memories of my first experiments with C#, but after I embarked upon learning and using C++ I kind of forgot about it. I have been considering the possibility of writing an IRC client of sorts using C# just for kicks, and to not forget this language in case I ever need it again. Why IRC? Because clients for this protocol are simple and challenging to implement, both at the same time!

I’ve already started to learn a bit of Lua for my work on the aforementioned Wesnoth campaign — in fact, there’s already some released code within it written in this language, particularly in scenario 5! I have plans to rewrite parts of Invasion from the Unknown in Lua to clean it up a little, thus paving the road for future maintenance work by me or other people (don’t forget that IftU is still abandoned!).

Another software project I intend to tackle in the short term is Rei 2. Sure, she’s doing well and her main command handlers are many and useful enough for channels such as ##shadowm and #wesnoth-umc-dev, but her dependence on Irssi’s core might well be a curse for one of our use cases: Shikadibot (the Second), which runs on a resource-limited VPS where every drop of RAM has got gold value. I’m already brainstorming a possible abstraction layer (codenamed “API 3”) which could allow the Irssi core to be swappable with a custom, native IRC client core (codenamed “Anya”). There’s really not much in the current Irssi-based implementation of the internal interfaces (“API 2”) that make a dependency switch unfeasible.

Finally, I’m not going to stop producing useless updates for my website! Dorset5 0001 is already a reality, although there’s still much I want to do before replacing the current layout. This time I have placed an emphasis on readability and elegance that I don’t think the previous revisions have lived up to so far.

• • •

All in all, I always have so many ideas floating in my mind that I rarely carry to realization, so this can’t be considered a definitive list. There are other possibilities I’m contemplating for the long term regarding my personal life, but that’s a much more volatile subject to discuss so I’m avoiding it for now.

A new feature release of Wesnoth RCX is now available!

• Source code: wesnoth-rcx-0.1.4.tar.gz (Gzip tarball, 64.2 KiB)
  SHA1 checksum: 8ca7f6354827c56aba4526f2f504d8db34f7acf0
• Windows package: wesnoth-rcx-0.1.4-win32.zip (Zip archive, 5.2 MiB)
  SHA1 checksum: 3832ddb798110f2e890aecc37519097e1e18e2b6
• Mac OS X binary: wesnoth-rcx-0.1.4.app.zip (Bundle, 14.9 MiB)
  SHA1 checksum: 60a5724d35b0bf64d02b4553ff9c1543d5964344
  This binary is kindly provided by Alarantalara from the forums.

The only major change in this version is the addition of zoom support in the user interface, so you can take a look at your team-colored pixel art at 100%, 200%, 400% and 800%, or even at 50%. No more levels are supported at the moment, and will probably never be unless you submit a patch — this is really just supposed to be a help tool, so if you need more exotic zoom levels use a real graphics manipulation tool such as Adobe Photoshop or the GIMP. And don’t forget you can also drag and drop images now!

There’s also a brand-new grayed-out menu for you to observe and admire. Only observe — don’t touch it.

As with the last time, the instructions for building the source are in the included INSTALL file in the distribution archive. This file is not present in the Win32 distribution for obvious reasons.

Don’t hesitate to comment on RCX’s development, usability, bugs, or suggest new features! The only way things can get fixed or improved is that you make sure I am aware of what needs to be changed. If you think you can help with something else, please tell me!

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

It’s a tradition of mine to assign random codenames to my projects when they are early in development, usually because I haven’t decided on a definitive production name at the time, or in other cases, just for fun. Here’s a rather complete list of the names I have used for this purpose and why, for the curious.

• Web shadow: the original layout for this very site, which got later replaced by Dorset.
• Dorset: this is probably the first project of mine with a formal codename convention, using the name of a Far North location from the Battle for Wesnoth — as a bonus it’s also a real-world location. It has now become more of a production name.
• Soradoc: yet another Wesnothian location, this corresponds to the first layout for the Wesnoth-UMC-Dev website.
• Kalari: a location relevant to the plot of one of my campaigns, After the Storm; this is the current Wesnoth-UMC-Dev website layout as of 2010, soon to be replaced. Since Wesnoth-UMC-Dev was originally built around the prequel Invasion from the Unknown it was just logical to choose a name from my own canon as a codename for the second website layout.
• Hakone: initially mentioned by me in ##shadowm as a joke, this became the production name for the Wesnoth-UMC-Dev 2011 website layout. This name corresponds to an actual location in Japan (箱根町), which is also the area where Tokyo-3 was built in the Neon Genesis Evangelion series.
• Scrappy: the build-external-archive.sh tool from Wesnoth-UMC-Dev. Useless, annoying, and ultimately dangerous. It has truly become our personal Scrappy, hence the name.
• Blackmore: the Wesnoth-UMC-Dev Duke Nukem Forever — I mean Distribution Package Tool, potentially going to use umcdist as production name. Blackmore is a city in the Green Isle from the Battle for Wesnoth, The Rise of Wesnoth.
• Thoria: umcreg, the Wesnoth-UMC-Dev Registry Service, which is in charge of abstracting user and add-on management for us administrators.
• Listra: codenamed after the Wesnothian river, umcstat has this assigned after its relationship with the umcreg service.
• Everlore: yet another Wesnothian river, also related to the Arkan-Thoria and umcreg — this is the current codename for the Atom feed front-end to umcreg.
• Rei II: named after the character from Neon Genesis Evangelion, this is Rei 2 IRC Bot, which spent around a year in planning as a C framework until I decided to ease the task and reuse Irssi’s core, turning Rei2 into a small-ish Perl module and libraries for writing simple IRC bots for this fantastic IRC client.
• Elynia: better known as Shikadibot 0314, our old utility bot that used to linger in the #wesnoth-umc-dev channel until we replaced its core with Rei2’s.
• Asuka: again, a character from Neon Genesis Evangelion, it is the PHP code powering the little Wesnoth Fortunes database I serve on this site.
• Poison Ivy: codenamed after the plant of the same name, this is the PHP engine that generates most pages on this and Wesnoth-UMC-Dev’s website. It has now stuck as part of the production name, “Poison Ivy PHP Engine”.
• Morning Star: the temporary production name used for Wesnoth RCX at the beginning.
• Naia: an abandoned branch that intended to generalize the framework used by umcreg in order to port umcstat’s prototype to use it.

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.

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.

Continue reading “Preparing for yet another year”

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.

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.

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.