Shadowmaster’s Blog - Wesnoth

Wesnoth add-on tests and sanity checking

nospam@example.com (shadowmaster) — Fri, 27 Jan 2012 00:19:00 +0000

Maintaining Wesnoth add-ons of the size of Invasion from the Unknown and After the Storm isn’t a small task by any means. Over the years, I have had to rely on user feedback to detect critical problems in a release, because testing becomes cumbersome and tedious as the scenario count increases.

My usual release procedure simply involves—at least since I acquired the habit of testing before releasing—running the game, starting each episode of the campaign with the medium difficulty level and making sure the WML preprocessor and parser don’t throw any warnings or errors. Before Wesnoth 1.9.x, the preprocessor didn’t abort when encountering a missing macro or file during a brace substitution, so I had to pay close attention to stderr to ensure nothing is wrong.

The WML preprocessor in Wesnoth 1.10 became more strict, aborting on the aforementioned situations. It was also exposed for command-line usage (for testing or debugging) through the -p or --preprocess switch, also explained in detail under PreprocessorRef in the wiki.

At first I thought that wasn’t very useful beyond diagnosing complicated preprocessor issues, but today I realized I can also do this:

This can be easily accomplished with a simple shell script (here embedded in the AtS Makefile). The only major shortcoming is that it doesn’t cover every possible problem because it’s merely running the WML preprocessor, which doesn’t consume and produce WML — all it sees is plain text mixed with some preprocessor directives. The task of reading actual WML (which is potentially found in the preprocessor’s output) is left to the WML parser proper, which creates internal objects in memory corresponding to the internal representation of WML handled by Wesnoth (config class objects).

UPDATE: After investigating the issue further with timotei (who exposed this functionality through --preprocess in the first place), it turns out the preprocessor output with --preprocess is indeed parsed — the real problem is that the preprocessor and parser use different logging facilities, and the former doesn’t even throw errors directly, so a preprocessor-only failure will make the game exit successfully (exit status of zero), while a parser error (potentially induced by a previous preprocessor error) causes a more appropriate non-zero exit status. This and other jarring inconsistencies make add-on test automation rather difficult, to say the least, so things have been simplified in the Makefile as a result.

It would be nice to be able to run the parser unit on the --preprocess output to detect syntax issues like missing end tags or unterminated string literals in the future, as part of a fully automated test suite. For now, it seems I’ll have to stick to my primitive and inelegant manual method before making new AtS releases, plus the unbelievably clumsy wmllint.

With great code comes great responsibility

nospam@example.com (shadowmaster) — Thu, 26 Jan 2012 06:46:00 +0000

I think I rarely discuss the more subjective/emotional aspects of working with the ~~crazy~~ folks at the Battle for Wesnoth Project, so this might be a good opportunity to do so given we are currently on the threshold of the first release in the new stable series, 1.10.

Since a while after joining the project, I’ve been wanting to make deeper changes to the add-ons server software (campaignd, by legacy). Some of those desired changes would benefit me directly as a user-made add-ons maintainer myself (previously Invasion from the Unknown, now After the Storm); other changes simply seem very convenient to have, such as some kind of authentication support and the ability to ban people without dirty system admin hacks.

Yesterday, I unveiled aspects of my not-so-modest proposal to replace campaignd with new code. You can find the pastebin link within my post to the developers mailing list.

Even though I have some of the basic ideas and I’m still collecting previous information (such as Mordante’s proposal), I am terribly hesitant to proceed with the larger project because it will take time and dedication I cannot really promise at this point. But why?

Part of my worries stem from previous experience working on one-man projects. After the Storm is no small example — started in 2008, finished in early 2012 after many long breaks, and still ongoing. I don’t consider myself to be the most adequate person to work on large tasks alone, because of motivational issues. If I feel no-one is really using or approving of my work, I’ll quickly feel frustrated and seek new projects with different goals to distract myself for any amount of time. (In AtS’ case, the most significant one was Frogatto’s level design, which is partly why I ended up trading helping with Frogatto for finishing AtS.)

campaignd (or its potential replacement, umcd) is a particularly dangerous target for me because of the inherently minuscule audience to which I’ll have to cater: the Wesnoth.org system administrators. But not only is this audience composed of approximately four people (including myself), but it’s also a very exigent one at that.

The client-side audience is larger, but just as exigent, if not even more. You can’t really just throw half-baked changes at them and call it a day—and that wouldn’t be polite, in either case—and since these things have to be done within the project’s development cycle to ensure excellent compatibility and proper migration paths, I don’t really have a choice of schedule — it simply has to be completely done before the next stable series if it is to be done at all.

It could be said it all boils down to a personal sense of competence. I’m pretty sure I’m not the most competent people for this task, but the people who are don’t have the time to do it either, so unless someone comes forward, we’ll be stuck with the same stagnating piece of old crap forever. That isn’t to say there haven’t been any candidates before — I have previously mentioned Ilor was working on an add-ons server replacement, but RL ultimately claimed its bill and the branch in SVN is currently abandoned.

Taking over this project would also get me stuck forever with it, unable to move on to more interesting things, especially if the worst case scenario presents itself before the end of the development cycle. I most certainly don’t want to be permanently required to answer every single question or implement every single approved idea for the server software. I’m pretty sure I can still be more useful doing UI usability assurance work or making more Wesnoth campaigns not-for-mainline. I know from other development areas that this “only competent authority” concept appears quite often, to the point of actually frustrating the targeted people.

For this reason, I really doubt I’ll actually undertake the server replacement, and just concentrate on the very specific points presented in my mailing list post. For better or for worse, people will have to bear with less significant changes until someone more capable and more willing appears.

After the Storm 0.7.0: Mission Complete!

nospam@example.com (shadowmaster) — Wed, 18 Jan 2012 02:17:00 +0000

After the Storm’s development began in 2008, some time after the completion of Invasion from the Unknown. Since then, the campaign’s development was repeatedly and severely hindered by multiple planning issues, partially caused by (borderline pathological) perfectionism on my part; plus many other personal problems.

During most of 2011, development was unofficially halted, with a half-baked E1S9.2 lingering around in the Wesnoth-UMC-Dev SVN trunk for months. Version 0.4.0 was released near the end of September, and from that point onwards, I decided to not stop working on the campaign ever again, until it reached completion.

That day, sadly, arrived sooner than I expected. Version 0.7.0 is here, presenting a complete Episode II with 12 scenarios, adding E2S8 through E2S12 to the line-up found in version 0.6.1.

AtS was always planned to have only two episodes, so as previously said I consider it to be 100% complete in terms of scenario count right now. The third episode (After the Storm: Final) is still in the planning stage and it will most likely be developed in parallel with the balancing, clean-ups and touch-ups leading to version 1.0.0, making it a target for version 2.0.0 instead.

Right now, AtS is in urgent need of portrait art for the new characters introduced throughout E1 and E2, at least two new unit baseframes for use in E1S9.2 and E2S11, plus a third baseframe for E3. While portrait art isn’t a version 1.0.0 target per se, I would really welcome any help at any time, as long as the art style stays consistent with Invasion from the Unknown. It’s very likely the missing baseframes will be provided by myself in the meantime.

Later, I’ll publish a more complete to-do list with the tasks remaining to be done for version 1.0.0, and I’ll try to make a more exhaustive art to-do list as well.

The changelog for this version follows:

Version 0.7.0:
--------------
* Graphics:
  * New or updated unit graphics: Dusk Faerie, Shaxthal Worm, Shaxthal
    Rayblade, Shaxthal Assault Drone, Shaxthal Protector Drone, Shaxthal War
    Drone, Shaxthal Runner Drone.
  * New or updated terrain graphics: Dark Hive Floor (transitions).

* Scenarios:
  * E1S5 - Bay of Tirigaz:
    * Rewrote shipwreck generator code so the message strings can actually
      be translated.
  * E1S8 - Fear:
    * Updated to use a Wesnoth 1.9.10 terrain.
  * E2S1 - By the Moonlight:
    * Updated to use a Wesnoth 1.9.10 terrain.
  * E2S2 - The Heart Forest:
    * Updated to use a Wesnoth 1.9.10 terrain.
  * E2S4 - Shifting Allegiances:
    * Fixed a local variable leak.
  * E2S6 - The Voyage Home:
    * Updated to use a Wesnoth 1.9.10 terrain.
  * E2S7 - Proximus:
    * Added a hint regarding the enemy leader's chance-to-hit override to
      objectives.
    * Fixed animation glitches.
  * E2S8 - And then there was Chaos:
    * New scenario.
  * E2S9 - New Hive:
    * New scenario.
  * E2S10 - The Betrayal:
    * New scenario.
  * E2S11 - A Final Confrontation:
    * New scenario.
  * E2S12 - Fate:
    * New cutscene scenario.

* Units:
  * New unit: Shaxthal Worm (replaces the Shaxthal Wyrm).
  * Balancing:
    * Reduced Nightshade Fire's ranged arcane attack strength from 12-3 to 10-3.
    * Reduced Nightshade Fire's ranged cold attack strength from 13-2 to 11-2.
    * Reduced Night Nymph's ranged arcane attack strength from 9-3 to 8-3.
    * Increased Errant Soul's ranged attack strength from 2-1 to 2-2.
    * Reduced Chaos Headhunter's ranged attack strength from 6-3 to 5-3.
    * Reduced Chaos Marauder's axe attack strength from 10-2 to 8-2.
    * Reduced Chaos Marauder's ranged attack strength from 7-3 to 6-3.
    * Reduced Chaos Soulhunter's axe attack strength from 13-2 to 12-2.
    * Reduced Chaos Soulhunter's ranged attack strength from 10-3 to 9-3.
  * Revised Shaxthal unit descriptions.
  * Shaxthal Runner Drones can no longer advance to Assault Drones.
  * Added a custom teleport animation for Nightshade Fire.
  * Added unit type descriptions for Night Nymph and Nightshade Fire.
  * Removed conflicting markup from the Sylvan Warden unit type description.

Just like the previous release, AtS 0.7.0 requires Wesnoth 1.9.10 or later. The presence of the Rotten Bridge terrain in several scenarios (mentioned in the changelog) really enforces this requirement in this opportunity.

So... yeah, the campaign is complete now. Go forth and play.

Wow

nospam@example.com (shadowmaster) — Mon, 16 Jan 2012 03:26:00 +0000

commit 9f6bd04ec405d3987a513ae490fcfef7fad6a034
Author: shikadilord <shikadilord@87cc232e-6748-0410-ac04-a3fa75566414>
Date:   Mon Jan 16 03:22:28 2012 +0000

    AtS E2S12: completed epilogue scenario
    
    This makes After the Storm 100% complete in terms of scenario count.
    
    git-svn-id: https://wesnoth-umc-dev.svn.sourceforge.net/svnroot/wesnoth-umc-dev/trunk/After_the_Storm@12917 87cc232e-6748-0410-ac04-a3fa75566414

I never thought this day would come.

About After the Storm 0.7.0...

nospam@example.com (shadowmaster) — Tue, 10 Jan 2012 00:00:01 +0000

Before anyone asks, yes, I have been working on AtS 0.7.0 all this time since the last release (0.6.1). It will include the last five scenarios of Episode II, that is, E2S8, E2S9, E2S10, E2S11 and E2S12.

Determining what the colors stand for is left as a proposed exercise for the reader.

Wesnoth 1.10 Release Candidate 1, oh my!

nospam@example.com (shadowmaster) — Sun, 08 Jan 2012 19:01:00 +0000

Hi! I’m shadowmaster. You might remember me from such type of campaigns as Invasion from the Unknown, After the Storm and Flesh and Steel (tentative name). As some of you may have heard, Wesnoth 1.10 RC 1 has been tagged in the mainline Subversion repository today, marking the start of the final stretch before the final (but by no means definitive) release of Wesnoth 1.10, the new stable series for this year.

If you are interested in the changelogs, they can be found at the following two locations:

Players changelog (shorter, always incomplete)
Full changelog (longer, harder to read, less incomplete)

In general, after a development (odd Y number in X.Y.Z) release is tagged in SVN, 24 hours must pass before it is announced, in case the primary packagers (Pandora, Windows, Mac OS X and Debian) detect critical bugs that could require immediate fixing, and to give them time to catch up since not all of them have a lot of time in their hands or enough resources — at one point, a packager was constantly running out of hard disk space thanks to Wesnoth’s sheer volume.

If you are tech-savvy enough to be able to determine which package is the one that corresponds to your platform—or you just prefer to compile from source—you can skip the wait for the announcement and head directly to the SF.net project files and locate your download. For example, these are the Wesnoth 1.10 RC 1 files; at first there’s only the source code tarball, but more files will appear as the primary packagers finish their work. Of course, during the first few hours, not all SF.net mirrors will be able to provide the files. Again, Wesnoth is very large and takes a while to transfer over the net.

(Wesnoth 1.10 RC 1 internally calls itself 1.9.14. This is intentional.)

With the first Release Candidate for 1.10 tagged and later announced, all commits in SVN trunk from now on will be only fixes for bugs reported in the bug tracker following our instructions, and translation updates, until 1.10.0 is ready. If too many major and complicated bugs come up, 1.10 RC 2 will be released before 1.10, but that seems unlikely right now since the release manager has a plan.

I have an announcement to make in the forums tomorrow that is strongly related to Wesnoth 1.10 and may upset the Crazy MP People a bit since I’ll be ~~encouraging~~ forcing them to test 1.10 RC 1 like the Crazy MP People they are. We shall see.

Wesnoth 1.10 RC 1 released, and some rationale behind the accounts purge

nospam@example.com (shadowmaster) — Mon, 09 Jan 2012 20:23:12 +0000

Wesnoth 1.10 RC 1 was released. Go test it, kids. You really must help us.

Besides that, I said in my previous post that I’d be releasing a separate announcement for the Crazy MP People. I wasn’t joking.

It might seem weird to perform such a purge of old forum accounts, and it might even confuse some MP users. A few times I’ve had to provide support to players who, despite having gone through the process of registering a new account—requiring them to visit the forums, no less—they had not fully realized that the forum and MP servers share the same user accounts database!

The truth is, the purge has become—in part—a marketing ploy I devised in order to have people try the last 1.9.x version before 1.10 becomes the current stable. If this angers you because you have been avoiding the new series like the plague, then think again. Give 1.10 an opportunity, because 1.8 is going the way of the dodo. 1.10 is much better, has better features and terrains, and even if you dislike some of the changes (i.e. the feral trait), I’m sure you will eventually find it worth of your time once you grow past the They Changed it, now it Sucks/Ruined FOREVER stage.

Regardless of that, the plan of purging unused accounts came to me much earlier while dealing with a major flaw in the wesnothd (the MP server software) forum user handler code. It seemed worth it to try to keep the database tidy by removing old, entirely unused cruft from it, and unconfirmed, 0-post accounts that have never been on the MP server since the introduction of forum accounts integration count as overly unused cruft.

A purge like this isn’t a new thing either. The previous forum administrator performed a larger purge of unused accounts right when the aforementioned integration was introduced, but it was never announced or discussed anywhere.

Purge.

2011 Wrap-up

nospam@example.com (shadowmaster) — Sat, 31 Dec 2011 20:52:00 +0000

At long last, 2011 is coming to an end. In a few hours, we’ll have to dump our old calendars to replace them with new ones bearing the number 2012 in a big font size. Then the people who believe 2012 will be the end of life on Earth will begin to panic as we approach December again. Those nutcases.

This was a relatively calm and monotone year in what pertains to my personal life, so I’m not going to delve into details in this opportunity. However, I made some resolutions last New Year and it might be worth it to review them and check why I didn’t accomplish all of my goals.

Learning Japanese: I got severely sidetracked after a while. I may still try again in the future, just because.
Losing weight: I may have gained ~~some~~ a lot of weight during the course of the year. Oops. I did, however, stop drinking coffee, because my stomach started to reject (read: try to vomit) it after a while for some reason.
Wesnoth RCX: Still halted. Frankly, there doesn’t seem to be enough interest amongst the Wesnoth community nowadays for this kind of tool, and for my own purposes Wesnoth-TC serves well as it is.
Relearning C♯: Also sidetracked. It doesn’t seem worth it, in hindsight.
Learning Lua: Accomplished according to certain definitions. I haven’t really learned more about the language than necessary, but I have indeed committed some Lua code to mainline Wesnoth, and several tasks of varying difficulty are accomplished with custom Lua-backed WML tags in After the Storm and Invasion from the Unknown as of this writing.
Rei 2 IRC Bot: Stalled, due to lack of interest. There are also seem to be a few Irssi-specific problems with Perl 5.14, which is in the operating system I’m using at the moment, Debian wheezy.
Website: Accomplished. In fact, in a few hours I’ll deploy a few minor changes to the code to optimize the blog template processing a bit.

One particular resolution deserves separate analysis, though:

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.

I didn’t resort to unlawful methods to accomplish this goal as I originally feared, but it still happened! Granted, rather late.

During September and October I had a rather unexpected creativity and productivity spurt which culminated with the release of AtS version 0.5.0 with Episode I: Fear complete with 13 scenarios. More recently in December, we reached version 0.6.1 with 7 complete scenarios for Episode II: Fate. As of this writing, E2S8 and E2S9 are also complete in SVN trunk in Wesnoth-UMC-Dev, although it’s been suggested that the latter could use some spicing up. E2S10 is a work in progress since yesterday, and part of E2S12 was written already back in October, just not committed.

Thus, it could be said that after many difficulties, After the Storm broke out of Development Hell. Whether I’ll consider Episode III: Final (expected to be shorter, around 6 scenarios) part of the required line-up for version 1.0.0 is a matter I haven’t settled yet.

Once After the Storm is finished, I plan to take a rather long break from campaign development. That isn’t to say I’m out of ideas, since there is one character I want to explore in further detail in her own campaign. However, I may have my Wesnoth time taken up by mainline work after 1.10 is released depending on the situation then, since there’s a rather large technology gap in Wesnoth that needs to be solved.

Other than that, I haven’t really decided on any resolutions for 2012, so I’ll leave you with the one resolution of the moment:

...
screen #0:
  dimensions:    1280x800 pixels (338x211 millimeters)
  resolution:    96x96 dots per inch
...

(This information is utterly wrong. xdpyinfo reported the same screen dimensions on bluecore last year in spite of its screen being glaringly larger than reicore’s by a few milimeters.)

After the Storm 0.6.1

nospam@example.com (shadowmaster) — Sat, 24 Dec 2011 03:39:00 +0000

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.

Version 0.6.1:
--------------
* Increased minimum Wesnoth version requirement from 1.9.7 to 1.9.10.

* Graphics:
  * New or updated unit graphics: Sylvan Warden (chained).

* Scenarios:
  * Various prose grammar fixes.
  * E1S3 - Civil War in the North:
    * Removed deprecated flower terrain.
  * E1S5 - Bay of Tirigaz:
    * Removed deprecated flower terrain.
  * E1S6.2 - Elves of a Different Land:
    * Fixed a dialog line wrapped in double parentheses.
  * E1S9.1 - The Triad (part 1):
    * Don't set Elynia's initial status to slowed.
    * Fixed animation glitches.
  * E1S9.3 - The Triad (part 3):
    * Fixed animation glitches.
  * E2S2 - The Heart Forest:
    * Increased turn limit.
    * Reduced initial gold amounts for enemy sides.
    * Set initial gold amount for the player.
  * E2S3.2 - Revelations:
    * Corrected unit facings.
  * E2S4 - Shifting Allegiances:
    * New scenario.
  * E2S5 - The Eastern Front:
    * New scenario.
  * E2S5 C - The Eastern Front cutscene:
    * New scenario.
  * E2S6 - The Voyage Home:
    * New scenario.
  * E2S7 - Proximus:
    * New scenario.

* Units:
  * Increased Dryad's HP from 43 to 46.
  * Increased Forest Spirit's HP from 37 to 40.
  * Simplified Sylvan Warden's animations WML, making her less of a resource
    hog.
  * Removed Kri'tan.

Have fun, and happy holidays!

WML is like XML, all right...

nospam@example.com (shadowmaster) — Tue, 13 Dec 2011 22:39:00 +0000

Since people keep saying WML is like XML, I decided to provide an example of what a standard WML snippet would look like if it had to be translated to XML.

WML:

[event]
    name=last breath
    [filter]
        id=shadowm
    [/filter]
    [message]
        speaker=shadowm
        message= _ "NO!"
    [/message]
[/event]

XML:

<event name="last breath">
    <filter id="shadowm" />
    <message speaker="shadowm" message:gettext="NO!" />
</event>

My knowledge of XML doesn’t go far enough, but I don’t think I’ve ever heard of translatable strings being an integral part of the syntax, hence the funky-looking XML attribute name for event.message.message above.

This example only covers the basic WML syntax (i.e. no preprocessor directives, +nodes or embedded Lua) on purpose.

Miscellaneous Wesnoth loading tricks on Linux

nospam@example.com (shadowmaster) — Sun, 11 Dec 2011 01:03:00 +0000

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:

shadowm@reicore:~$ ls -l bin/wesnoth*
lrwxrwxrwx 1 shadowm shadowm  33 Dec 10 21:09 bin/wesnoth -> /home/shadowm/src/wesnoth/wesnoth
lrwxrwxrwx 1 shadowm shadowm  37 Dec 10 21:10 bin/wesnoth-1.8 -> /home/shadowm/src/wesnoth-1.8/wesnoth
lrwxrwxrwx 1 shadowm shadowm  40 Dec 10 21:10 bin/wesnoth-1.9.12 -> /home/shadowm/src/wesnoth-1.9.12/wesnoth

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

nospam@example.com (shadowmaster) — Fri, 09 Dec 2011 07:03:01 +0000

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.

The changelog for this version follows:

Version 0.6.0:
--------------
* Increased minimum Wesnoth version requirement from 1.9.5 to 1.9.7.

* Scenarios:
  * Reworked character recall logic.
  * Episode 2 (Fate):
    * Scenarios 1 and 2 completed.
    * Scenario 3 completed, consisting of two cutscenes.

* Units:
  * Reduced Sprite's required XP to advance from 70 to 40.
  * Reduced Fire Faerie's required XP to advance from 100 to 70.

Regarding the version requirement increase, it’s not so much because of changes in WML syntax but rather because of a new terrain added in 1.9.7 that’s used in E2S2.

GUI2: Editor Settings, Starting Positions and Uninstall Add-ons

nospam@example.com (shadowmaster) — Fri, 28 Oct 2011 09:03:00 +0000

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.

(Note to self: rephrase the MDI option label again since “allow having” doesn’t sound proper at all.)

→

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.

After the Storm 0.5.0

nospam@example.com (shadowmaster) — Sun, 16 Oct 2011 05:41:00 +0000

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.

Until I rediscovered the fun in video games with VVVVVV, Minecraft and Portal. Then, magic ensued.

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:

Version 0.5.0:
--------------
* Scenarios:
  * 09 - The Triad (part 3):
    * Fixed problems with the final cutscene on Wesnoth 1.9.8 and earlier.
  * 11 - Return to Wesmere (part 2):
    * New scenario.
  * Completed episode I.
* Units:
  * Removed Skirmisher ability from Elynia.
  * Spawners have a small chance of deactivating themselves after spawning a
    unit.

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

Have a lot of fun!

Wesnoth.org DNS issues

nospam@example.com (shadowmaster) — Sat, 01 Oct 2011 19:50:00 +0000

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.

Add the following line to it and save:

65.18.193.12 wesnoth.org www.wesnoth.org forums.wesnoth.org wiki.wesnoth.org add-ons.wesnoth.org server.wesnoth.org coc.wesnoth.org replays.wesnoth.org bugs.wesnoth.org

Done!

An alternative is just issuing the following command as administrator. Notice that it uses >> instead of the usual > in order to append rather than replace the file!

# echo "65.18.193.12 wesnoth.org www.wesnoth.org forums.wesnoth.org wiki.wesnoth.org add-ons.wesnoth.org server.wesnoth.org coc.wesnoth.org replays.wesnoth.org bugs.wesnoth.org" >> /etc/hosts

Windows

Login with an account with administrator access.
Edit or create the file C:\WINDOWS\System32\Drivers\etc\hosts with a plain text editor such as Notepad (replace C:\WINDOWS with the correct installation path of your OS if necessary.

Add the following line to it and save:

65.18.193.12 wesnoth.org www.wesnoth.org forums.wesnoth.org wiki.wesnoth.org add-ons.wesnoth.org server.wesnoth.org coc.wesnoth.org replays.wesnoth.org bugs.wesnoth.org

Done!

Other

Unfortunately, I have no idea about Mac OS X since I’ve never had an Apple computer. If anyone knows more than I do, feel free to post a comment explaining the steps.

After the Storm 0.4.2

nospam@example.com (shadowmaster) — Thu, 29 Sep 2011 20:49:00 +0000

In good RERO tradition, After the Storm 0.4.2 is now available in the Wesnoth 1.9.x add-ons server addressing a few bugs reported today.

Unless something major arises again, 0.4.3 will feature the eleventh scenario in Episode I, whose map I have already finished.

The changelog for this version follows:

Version 0.4.2:
--------------
* Scenarios:
  * Removed player income in scenario 6 and 7 cutscenes.
  * 06 - Quenoth Isle/Elves of a Different Land:
    * Fixed gold carryover for scenario 07.
  * 07 - The Search for the Past:
    * Remove poison/slowed/ambush status from units at the end to avoid recall
      issues in later scenarios.
  * 07 - Resolutions:
    * Fixed gold carryover for scenario 08.
  * 09 - The Triad (part 1):
    * Fixed undead and faerie units in the recall list being killed in turn 2.

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 0.4.1a

nospam@example.com (shadowmaster) — Wed, 28 Sep 2011 07:15:00 +0000

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.

Behold the changelog:

Version 0.4.1:
--------------
* Scenarios:
  * Added custom flag styles for various AI sides.
  * Minor wording changes, some of them contributed by tr0ll.
  * 10 - Tears:
    * New scenario.
* Units:
  * Renamed Chaos Lore to Chaos Lorekeeper.

As for the “a” suffix in the version number, it’s because I originally tagged version 0.4.1 in SVN and then realized the scenario count in the campaign description still read 9/13 instead of 10/13.

After the Storm 0.4.0

nospam@example.com (shadowmaster) — Sun, 25 Sep 2011 04:03:00 +0000

What should have occurred last March or April occurred now, instead.

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!

The Double-posting Dilemma

nospam@example.com (shadowmaster) — Sun, 04 Sep 2011 18:39:42 +0000

When I prepared the final draft of the October 2010 revision of the Wesnoth.org Forums Posting Guidelines, I deliberately skipped clarifying a specific point regarding posting rate conducts, more specifically, point 1f, in order to see what the community would make out of it.

That’s not to say I didn’t alter it in any way whatsoever since the previous revision, which was basically a left-over of Turuk’s administration:

Before:

Think and Read.
Read the entire thread before you post. And when you post, explain your reasons. Nonsense may be deleted without warning, especially in a working topic. Posting the same thing after it has been deleted will get you a warning. Doing it again will get you a ban.

No Spamming.
Post a single idea/question/comment in only one forum. Do not double post, edit your previous post if you have something new to add but no one has posted yet.

After:

No spamming — think and read
Post a single idea/question/comment in only one forum. Do not double post, and instead edit your previous post if you have something new to add and no one has posted yet. Technical support requests may be bumped after a while in case they have been forgotten and sink past the first forum view page. Read the entire thread before replying to it. Nonsense may be deleted without warning, especially in a working topic.

I introduced the support requests bit with the intention of giving users in the support forums (Technical Support, Release Announcements, Compiling & Installation; WML Workshop, Coder’s Corner, Lua Labs, Scenario & Campaign Development) special protection as bumping topics in there is usually a legitimate and reasonable course of action. But in reality, there are other cases where bumping by means of double-posting should be allowed. Those are not described or explained in the Guidelines because I felt that elaborating on a specific point would derail the whole post.

One of those cases applies to campaign development topics, where the OP may post the announcement for a new version of the campaign and only a few hours later find himself or herself in need of another announcement because of a quick update fixing some important bug.

Another case, more technical than practical, is the maximum number of attachments per post, which exists to discourage and limit senseless spamming of unwanted content by automated and non-automated agents, and encourage use of compressed containers like tarballs, zip files and rar archives to keep our overall disk usage relatively low. Users exceeding the attachment limit will need to continue posting their content in consecutive posts.

Generally speaking, users reporting double/multiple posting according to section 5 of the Guidelines have enough common sense to understand that sometimes exceptions need to be granted and that this is one of the reasons we don’t call them the “Forum Rules”. Rent-a-modders occasionally lack this common sense, however, and they make their intentions evident through this mechanism. I imagine one can never be too anvilicious while reminding them what this entails.

The Rise of Wesnoth for Android

nospam@example.com (shadowmaster) — Thu, 01 Sep 2011 08:22:00 +0000

Apparently, Battle for Wesnoth is already out in the Android Market! There’s no official announcement about it right now, but I got these tasty links (posted in Twitter as @WesnothOrg as well) a few minutes ago from the maintainer, cjhopman in the forums and IRC!

This really makes me want to get an Android-based smartphone now! If only such a thing could fit in my budget…

The Fall of Wesnoth for iOS

nospam@example.com (shadowmaster) — Thu, 18 Aug 2011 21:07:09 +0000

July 2009 — work on the first iPhone port of the Battle for Wesnoth is announced in the official forums by Kyle Poole.

August 2011 — the iPhone and iPad ports of the Battle for Wesnoth have stagnated for half a year and support requests in the dedicated topics (iPhone, iPad) in the official forums are not being answered by Kyle, who last logged in on May 25th 2011, having posted for the last time on December 19th of the previous year, some time after announcing the release of a Palm Pre port. The SVN repository doesn’t display recent activity either. Meanwhile, Apple’s money-making platform marches on.

The truth is, after teasing the user base for a while with announcements of a forthcoming Android port, and invisible “progress”, Kyle seems to have moved on to “better” projects.

Case in point: Shadow Era.

The last thing I saw from him in his blog was the announcement of this new game from his company and frankly stopped paying attention afterwards since according to Dave he stated he’d be coming back to Wesnoth “soon”. That was back in May this year. His site is now suspiciously blank.

This lack of communication on his part while apparently having more success with his new release leads me to think he’s possibly not coming back to Wesnoth and we may have to start telling people in the forums to send their inquiries to his personal email address instead — which isn’t too hard to find in the web as Gambit discovered, mind you.

But what’s the legacy of this apparently abandoned port?

Continue reading "The Fall of Wesnoth for iOS"

Heaps and heaps of Ideas

nospam@example.com (shadowmaster) — Tue, 09 Aug 2011 09:03:00 +0000

The Ideas section in the Battle for Wesnoth forums is in very bad shape right now, and despite the efforts of my trusty moderators, the root of the problem lies far beyond our ability to lock topics.

I won’t mention any names for obvious reasons, but a major behind-the-scenes administrative role in the Battle for Wesnoth Project (hint: it’s not Noy, it’s not Dave, it’s not me) once described several board sections including the aforementioned as “a place where all the noise can go to so that it does not hinder us too much”. This is not just one individual’s opinion and it shows; even when I was a user back in 2006 I always felt Ideas tended to be left aside by the development team.

Yeah, I know:

Q: Why doesn’t Wesnoth have my favorite feature?
Because we are building this game for ourselves, to suit our own preferences. We’re not building the game for you, in large part because this is our hobby, not our job; whether you like it or not is immaterial to us. You may wonder, then, what the point is of soliciting ideas, as we do on the forum. We, the developers, have certainly come up with many good ideas on our own, but our players often do as well, and generally ones we don’t think of ourselves. If a player comes up with an idea we like, we might implement it. Not because they asked for it, but because of its own merits as an addition to our game. […]

Of course, the extent to which a bunch of key developers can come up with ideas when they don’t even regularly play the game proper is debatable. The other side of the coin shows that users don’t really come up with good ideas most of the time. Most Ideas topics fall into one of the following categories:

Frequently Proposed Ideas (FPIs) — which go in the opposite direction of Wesnoth’s development
Good ideas that can’t be immediately implemented (BWH, from “been suggested before, we think it’s a good idea, hope to add it eventually”)
User interface ideas (usually overlaps with BWH)
Add-on and multiplayer server ideas (ditto)

FPIs can be easily handled by moderators following a few simple guidelines and the bulk of locked threads in Ideas correspond to these. The problem is that BWH entries are not correctly classified anywhere — not even Feature Requests in the Gna.org bug tracker are properly monitored and occasionally completely ridiculous entries get added there; others are forgotten and implemented by other people on their own without referencing the existing open issue(s), and there’s also a swamp of outdated issues that may no longer apply to trunk.

BWHs are also quite sad to handle because, let’s accept it, most game players have no coding skills and won’t mess with the source to contribute C++ or Lua code back to the game, no matter how prominently advertised the open source nature of Wesnoth might be. The Forum Moderators are deliberately picked up from the non-technical bunch so they don’t get overloaded with responsibilities, something that’s happened before and has resulted in a degradation of the forums’ service quality.

User interface ideas are an even worse terrain because Wesnoth’s GUI development has been largely stuck since 2008 with Mordante/SkeletonCrew’s new internal toolkit, GUI2. Pretty much no groundbreaking changes can be done until GUI2 is mature enough to support all the old features. It’s not very hard to create a campaign scenario with an absurdly long Objectives entry and watch the ensuing rendering mess — that’s just one example of how GUI2 is still inferior to the less flexible old toolkit in some ways.

GUI is also a tough matter because it’s easy for a single user or Wesnoth developer to propose an interface for some task, implement it, and later find out that most of the other users or developers don’t “get it” — this is an issue inherent to user interface design, of course.

Add-on and multiplayer server ideas are very hard to implement because they tend to require not just changes to the server and client code to suit our needs, but they also often involve new GUI elements, resulting in an overlap with both the GUI category, which in turn overlaps with BWH.

Gambit and I tried for a while to make people use topic icons in Ideas to mark BWH entries and the rare issues that get finally solved in trunk. This doesn’t work very well because other developers either don’t watch Ideas thanks to the predominance of posts in any of the categories described above, or don’t watch the forums at all.

I usually try to be optimistic about things, but I really feel like we core developers are alienating our own user base with this apparent lack of interest for communication. Don’t even get me started on the “new lobby” fiasco in version 1.8.0.

Wesnoth-UMC-Dev: A Retrospective

nospam@example.com (shadowmaster) — Tue, 05 Jul 2011 07:35:00 +0000

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.

Continue reading "Wesnoth-UMC-Dev: A Retrospective"

Wesnoth-UMC-Dev: r10000

nospam@example.com (shadowmaster) — Mon, 04 Jul 2011 23:42:00 +0000

The Coordinated Wesnoth User Made Content Development Project, better known as Wesnoth-UMC-Dev, has today reached SVN revision 10,000.

Here’s the official announcement.

I’ll soon post details about the project’s history here.

Campaign unit names

nospam@example.com (shadowmaster) — Sun, 03 Jul 2011 23:27:00 +0000

While searching for examples of translated generic unit names from data/core/macros/names.cfg in Wesnoth (much to my disappointment, the Japanese translation uses the source strings verbatim for this), I discovered an oddly familiar name amongst the female Elvish names for the markovian generator.

Anylindë.

Back in 2007/2008, I was pretty much forced by Syntax_Error/Blarumyrran to change the name of one of the main characters in Invasion from the Unknown. Why? Because her name was Analia — never mind that female human units named “Bra” occur quite often in the game thanks to the RNG’s influence over the name generation algorithm.

So I consulted ESR, who came up with Anlindë as a possible replacement. I never noticed before that it was just one letter away from being a generic unit name. Then again, Galas and Elynia were my own design choice and they are, indeed, part of the name generator sources — I had gotten so frustrated at the design phase that I took a random generic name for Galas and the first feminine-sounding name starting with ‘E’ for Elynia.

Furthermore, I also took Analia from names.cfg and it’s still there. No overzealous purists have complained so far.

Would IftU have been a better campaign if I had used custom names for these three characters? Maybe, by a marginal difference. On the other hand, the one time a recruited elf with the name Elynia appeared during gameplay (that one Sprite I got in IftU doesn’t count), I protected her until ~~the end~~ the second-to-last scenario of HttT — by then she was a veteran Elvish Shyde.

GUI2: New Folder, File Chooser dialogs

nospam@example.com (shadowmaster) — Wed, 29 Jun 2011 11:03:00 +0000

Since I’ve not felt particularly inspired to finish the last two parts of my review of the Under the Burning Suns campaign’s post-quartex (1.3.x - 1.9.x) development history, I suppose I may as well bother my loyal readers with yet another useless report on GUI2 dialog conversions in Wesnoth trunk.

Okay. I lied. The screenshot above does not come from Wesnoth trunk, but from its fork in a private branch in my local git-svn repository. The component in question is evidently the File Chooser dialog, which is used in the map editor for locating files to open or save, and in the Preferences dialog (and more rarely in the MP menu) for finding the wesnothd or wesnothd.exe MP server binary used to host LAN games.

I figured that converting the File Chooser to GUI2 will help stomp a few bugs with files whose names look like the obsolete, so-called “WML markup”, and generally make it easier for people to improve it. Once I have reimplemented the current functionality I may look into adding some kind of bookmarks system, or at the very least shortcuts for jumping to directories that are commonly used by both mainline developers and UMC authors.

All this rewriting may also introduce new bugs, of course; hence I’ve not pushed these changes to trunk, even though they are already guarded by the --new-widgets command line switch. I have not pushed them to a public SVN branch either because local Git branches make it much easier to rebase commits against trunk as time goes on.

In the process I found myself in need of converting the New Folder dialog to GUI2 for consistency. Given the sheer size of the C++ code added in the process, I am pretty sure this won’t inconvenience anybody for now — hence I pushed this changeset directly to trunk instead.

(And yes, it should be “New Directory”. I am going to hate myself for the rest of my life for keeping the legacy “user-friendly” terminology that was already in place.)

A Matter of Personal Preferences

nospam@example.com (shadowmaster) — Sun, 19 Jun 2011 04:40:00 +0000

Now that Battle for Wesnoth 1.9.6 has been tagged, we can once again focus on the future!

I’m not exactly the resident usability expert in the Wesnoth development team (multiple people have claimed that title under dubious circumstances before) but I believe I can recognize a design issue when it’s in front of me.

The issue in question is the game’s Preferences dialog. Over time it has accumulated needless cruft in the form of options that no-one should ever need to use, which are nevertheless offered to the player under the Advanced Preferences section. Funnily enough, the programmatic design of this area lends itself to random developers and patch contributors senselessly throwing crap into it; this is the only piece of user-visible configuration that can be defined almost entirely in WML, requiring only a couple of accessor functions in the C++ side for whatever module needs to query or set those options at runtime. In the “best” case, just a single getter suffices.

Of course, Preferences is built upon the previous Wesnothian GUI toolkit jokingly referred to as “GUI1”. Despite what some people may say, it’s far from ideal to work with hardcoded widget locations and an inflexible rendering scheme. As new options have been added to the game, developers have preferred to do things the lazy way and abuse Advanced, leading to arguably essential entries getting clobbered in middle of the rubble.

Naturally, I tried to tell people about this problem. But since it’s been nearly a week and I’ve not gotten reactions of any kind, I decided to start chopping trees.

→

The main thing here is that the Enable scroll tracking of unit actions and Reverse Time Graphics options were moved to Advanced, and in their stead I brought Show Unit Standing Animations and Animate Map, and messed around with some spacing.

With Wesnoth 1.9/1.10 boasting a plethora of standing unit animations and animated terrains, a performance drop is to be expected on low-end machines — or even high-end as well, depending on what other processes are running in the background and local factors such as map size, amount of visible units and possible targets during AI turns. Increasing the visibility of performance impacting options makes a lot of sense if it will result in less complaints.

→

If one looks hard enough, it’s always possible to find other details to nitpick. A little patch went into 1.9.7 to add some indentation and change font sizes for slider labels in Preferences that were associated to checkboxes, but I preferred to leave the follow-up for 1.9.8 — the Sound tab sliders had some overly verbose labels that truly only served to give translators three extra strings to manage.

That said, Preferences still glitches at the bottom on the minimum resolution of 800x480 pixels. The effect can be seen here on the Close button itself. I don’t think I’m able or particularly interested to tame this beast, however, so fixing it may have to wait for the GUI2 redo of the dialog. Meanwhile, OpenPandora users will have to do with this minor inconvenience.

• • •

I should note that my original plan was to completely scrap the Reverse Time Graphics option. After doing some research, I discovered that ESR did it once, and that it got reverted the next day by alink. The rationale? I’m not sure, but the IRC logs are quite entertaining.

Wesnoth: the Spanish Translation

nospam@example.com (shadowmaster) — Mon, 30 May 2011 03:05:00 +0000

It seems that after Roberto Romero abandoned the maintenance of the Wesnoth Spanish Translation team in 2007, it’s all gone downhill.

(Fun fact: it was under his leadership that I contributed my first translations for mainline Wesnoth — my first involvement with a FOSS project ever.)

Some time after he left the team (apparently without previous notice to Ivanovic or Torangan), the translation was taken over by a significantly less competent group that did a very lousy job (read: no quality control) before abandoning it again. Around the end of 2008, I took it over and quickly, with the help of an Argentinian guy who joined me later, brought it to completion in time for the first release of the 1.6 series.

In the process I realized how hard it really is to maintain a complete translation of a large game like Wesnoth.

Due to a series of RL complications, I had to abandon the Spanish translation shortly after Wesnoth 1.6 was released (March 2009). The translation was not taken over by anyone in time for Wesnoth 1.8 (April 2010). Much later in November, though, a new fellow became maintainer and got some work done along with other new collaborators.

Things were starting to look unusually bright because, for the first time in years there was more than one active translator. However, this world full of rainbows and pink unicorns did not last, and it ultimately fell into oblivion following the departure of this last maintainer from the community. No-one took over the team afterwards, and now the Spanish translation is in its natural state once again. The last update in mainline trunk took place in January 2011.

You can have a look at the current situation in gettext.wesnoth.org, our translations statistics website.

It seems that Battle for Wesnoth just doesn’t manage to appeal to many Spanish-speaking people from the FOSS users community to attract new individuals with the knowledge, patience and time required to resurrect an abandoned translation, and the sense of leadership required to coordinate work and keep certain quality standards to attract and, most importantly, keep new translators.

Of course, Wesnoth is a huge undertaking of its own with over one dozen of thousands of strings in mainline and its distinctive approach to storytelling — I know for sure I do not want to work on translating campaigns again, at least, not alone. Still, there are people far more capable than I am for this kind of work, and I do believe our game could really use more publicity among Spanish and Latinamerican players and their contacts.

All the technical fluff relevant for starting to work on an existing or new translation can be found in the wiki, after all.

Long Live the Wesnoth.org Favicon!

nospam@example.com (shadowmaster) — Thu, 26 May 2011 07:21:00 +0000

Today, May 26th, a few minutes past 06:00 AM UTC, after 6 or 7 years of history, the Wesnoth.org favicon has finally been replaced by command of the Art Director on the live website and in SVN trunk, revision 49655, meaning this change is also effective in mainline starting with version 1.9.7 (not yet released).

The differences between both versions are far from subtle, as you can see to the right.

I for one mourn the loss of this significant piece of history that reflects an older, more cartoony art style that was slowly abandoned towards Wesnoth 1.0 and beyond. Until now, this icon also accompanied the owned village counter in the game’s top bar, and served as an indicator overlay for moves affecting village ownership since version 1.4 onwards. Finally, it served for a long time as the village terrain category icon in the Map Editor.

In case anyone requires the old icon for the sake of nostalgia, it’ll be preserved here for your own use under the conditions of the GNU General Public License version 2.

PNG format (468 bytes)

Spamming trends: Electronic cigarettes

nospam@example.com (shadowmaster) — Sun, 15 May 2011 00:00:00 +0000

Since the popularity of DVD rippers appears to be waning as of lately, the Wesnoth.org forums may or may not be about to become prey of a new spam fad. This time it’s “Perfect” Electronic cigarettes.

Thanks to our sophisticated CycholkaSoft Anti-bot Registration™ technology (patent pending), the little critters still need some human assistance to make it to our domain. If I had to guess, their purpose is to have their account settings prepared by a middle-man who enters their credentials into a database so the bot(s) can later log into the board(s) and perform automated posts. Otherwise, it makes no sense that they create a spammy signature to not start posting immediately.

(Notice that the default phpBB 3.0 configuration disallows guests and crawlers to see users’ profiles, which is the only way signatures from non-posting accounts can be seen by anyone.)

Wesnoth Evolution: 0.1

nospam@example.com (shadowmaster) — Mon, 12 Apr 2010 17:00:47 +0000

Battle for Wesnoth has been around for some years already and its ever increasing content and artwork quality has attracted many code developers, sprite and portrait artists and musicians over time. I started playing Wesnoth on version 0.9.6 which was distributed with the SUSE Linux 10.0 operating system; I later switched to version 1.0.2 and closely followed the 1.1 release cycle.

Now that version 1.8 has been released and approx. 7 years have passed since the very first release, I felt curiosity to see exactly what has changed and what hasn't changed since the very first Wesnoth version published by David White (a.k.a. Sirp) that isn't even available in the downloads page at SourceForge.net. Yep, that's right, this is a review of Wesnoth 0.1 against current versions of Wesnoth such as 1.8 and 1.6, or even intermediate modern versions such as 1.0.

For historical reference I'm using both an actual Wesnoth 0.1 build for Windows I prepared using the Mingw32 cross-compiler environment for Linux (running on WINE), and the Battle for Wesnoth Project's SVN trunk changelog, which starts at version 0.2.1. The project's combined CVS-SVN history, on the other hand, starts on September 15th 2003, 15 days before the first CVS release tag, version 0.4.8. The first version announced since the beginning of the Wesnoth forums (which predate Wesnoth.org itself) is 0.3.7.

Continue reading "Wesnoth Evolution: 0.1"

Wesnoth 1.8.6 confirmed

nospam@example.com (shadowmaster) — Tue, 03 May 2011 01:11:00 +0000

For those of us who were wondering whether the Battle for Wesnoth team would release another revision of the latest stable branch, today we have definitive confirmation that version 1.8.6 will, indeed, come to life very soon, as the release manager has just informed us (plus a minor correction) in the developers’ mailing list:

Currently I consider tagging 1.8.6 maybe on Wednesday next week. Please ping me ASAP if you got anything I should be waiting for (and obviously tell me what it is). Yes, I think that 1.8.6 will really be the last 1.8.6 release.

It should be pointed out that the necessity of another stable release was decided back in February during FOSDEM, after evaluating the current status of 1.10’s development.

An incomplete list of changes can be found in /branches/1.8/changelog from the SVN repository. Some noteworthy code changes as of this writing include:

Fixed transparent portraits not supporting image modifications
ANL: Awarded correct amount of research to units. (Fix for bug #17406, patch by kernigh.)
Remove useless debug output introduced in r42226
Fix loadscreen progressbar "bleeding" on the old MP lobby when running with -s switch
Fix for bug #17573: wesnoth unusable with certain combinations of glibc and sdl due to changes in memcopy
Rework MP chat log as a GUI2 dialog with colored display of messages
Fixed a gcc 4.6 compilation error

So long, Wesnoth.org forums

nospam@example.com (shadowmaster) — Fri, 01 Apr 2011 00:43:00 +0000

It’s official now. As someone with a keen eye for forum changes already noticed, Gambit is replacing me as the Wesnoth.org forum admin, effective now.

There are various circumstances that led to this decision, including my traveling to France tomorrow, and Gambit’s competence and great ability to bear with high work load (much better than mine anyway).

I am sure that this change won’t disrupt regular activity in any way whatsoever.

I’ll follow up with some notes on the forum’s history later.

Happy April Fools, people!

Spamming trends: DVD rippers

nospam@example.com (shadowmaster) — Wed, 30 Mar 2011 06:50:00 +0000

Last year it was SEO spam.

This year it might be DVD rippers.

During the last couple of weeks, the Wesnoth.org forums have been constantly hit with a “new” kind of spam involving DVD ripping software, which may also involve some kind of scam as the linked site contains a Buy button, amongst other things. I’m not touching it further; not even with my 5 mt. pole.

You read me right. It’s not new in the literal sense of the word, since I have seen this shit hitting us before, albeit at a much slower rate. If I recall correctly, I have banned no less than 6 accounts in less than two weeks because of the current trend.

Whoever invented it clearly targets a low-IQ demographic, with retarded statements such as the following:

Many DVD users want to enjoy their favorite DVDs on their portable devices

Nobody whom I know would, in their sane minds, watch a friggin’ movie on a device with such low resolution and display size. We’re mainly talking of Apple’s iShit devices, of course. And I’m not going to get into how “illegal” or not it is to break those lovely DRM restrictions.

Since I’m in a lazy mood today, I’ll leave the research of the purpose of this shady “marketing campaign” to my readers and loyal fans.

Project Y: The Battle for Irdya (brainstorming)

nospam@example.com (shadowmaster) — Mon, 07 Mar 2011 04:38:00 +0000

I accidentally stumbled upon this Wesnoth.org forum post this night while searching for suspicious (read: spammy) activity — which gave me the following idea:

<shadowmaster> http://forums.wesnoth.org/viewtopic.php?p=481052#p481052
<shadowmaster> "Inferno8 and I have agreed that we want more publicity and exposure for the campaign, including promotion and review on indie gaming websites. [...]"
<shadowmaster> Espreon:
<shadowmaster> AI0867:
<shadowmaster> I have an awesome idea
<shadowmaster> let's take UtBS, IftU and AtS (and optionally TSL) out of Wesnoth-UMC-Dev
<shadowmaster> let's go big
<shadowmaster> let's create a separate OSS project for them
<shadowmaster> game engine included
<shadowmaster> let's strip Wesnoth of all the shit we don't need and build a better engine
<shadowmaster> for Project Y.
 * Espreon chuckles
<shadowmaster> DEAL? [Y/N]
<shadowmaster> We could even take Aethaeryn 's Thunderstone with us
<shadowmaster> think of it
<shadowmaster> "Project Y: Thunderstonecraft"
<Espreon> Someday Ignacio, someday. We don't have enough minions at the moment.
<shadowmaster> The Battle for Irdya!
    -- ##shadowm, 2011-03-07

I think this is a possibility I never considered before, and a fabulous idea which I should steal, in good old Shadowmaster tradition.

If you want to make this possible, join the IRC channel ##shadowm on chat.freenode.net with your favorite IRC client, or use one of the links below!

In case you can’t tell, this is a joke.

Wesnoth-TC 1.5.0

nospam@example.com (shadowmaster) — Tue, 30 Mar 2010 14:59:34 +0000

After being in Development Hell for...I forgot how many months, Wesnoth-TC, the advanced Team-Colorizer version 1.5.0 is finished and released.

This version introduces a few changes in the output files' naming scheme, and adds support for palette switches a la ~PAL() image function from Wesnoth's engine (which I implemented, by the way). The old Makefile is gone and there's a normal autotools build system in place, which seems to work well on Linux systems, as well as Mac OS X and even Mingw32-based cross compiling environments!

Thanks to this improvement and a small help from loonycyborg, Wesnoth-TC also has a experimental “official” Win32 build this time, which I have successfully tested on Windows XP SP3, and Debian Squeeze using WINE. It was cross-compiled using the Mingw32 environment packages from Debian. There are no important functionality differences between the Win32 build and normal Unix-based builds. It remains a command-line application as it's supposed to be.

Download

Source code: wesnoth-tc-1.5.0.tar.bz2 (149.7 KiB)
(SHA1: 030b4584a52e41f9706f7e59fdd5a9896485ed83)
Windows (Win32) binary: wesnoth-tc-1.5.0-win32.zip (373.3 KiB)
(SHA1: 311adf05b3855bf74eb782fe020992e61aac80eb)

In an ideal world, the availability of a CLI Win32 binary would raise interest on this tool and someone would volunteer for working with me on a GUI front-end. That's very unlikely to happen in the real world, so I'm researching Qt4 and messing around with some ideas for a cross-platform front-end based on penguin's Mac OS X applet.

Instructions

Both distributions come with a README file, and the source code distro includes a INSTALL file with detailed instructions on configuring, compiling and installing wesnoth-tc. The Win32 binary distribution doesn't require any installation besides unpacking it into an appropriate directory — which you may optionally add to PATH.

EDIT: some people may have problems compiling under certain platforms or configurations because the configure script in this version enables strict mode by default, treating compiler warnings as errors. To solve this, pass the --disable-strict option to configure. Git master already solves this problem, plus a particular warning reported on Ubuntu 9.10.

Behind the scenes

As I mentioned before, I tried using gd for PNG manipulation but ultimately discovered that its limitations weren't nice for wesnoth-tc's particular case. I rewrote the PNG reading and writing code again afterwards, using the SDL_image library as a model instead.

The Win32 build doesn't have support for libpng exception handling (via longjmp/setjmp) because the compiler complains about it for some reason:

warning: variable ‘height’ might be clobbered by ‘longjmp’ or ‘vfork’

This shouldn't be a big deal since libpng won't complain unless someone feeds a corrupted or invalid PNG file to it. (EDIT: figured out the cause with some help, but haven't fixed it in Git master yet.) The other functionality change is the lack of support for checking file access permissions considering effective user and group ids, etc.

Supposedly, this release should work properly on PowerPC and other big-endian platforms. However, I don't have such a machine and therefore can't test.

Preparing for yet another year

nospam@example.com (shadowmaster) — Tue, 30 Nov 2010 02:11:00 +0000

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"

After the Storm: What Could (Not) Have Been

nospam@example.com (shadowmaster) — Sat, 29 Jan 2011 08:02:00 +0000

Over time I’ve grown particularly fond of my habit of not deleting files regardless of their uselessness — this has saved my butt in several occasions. On this subject, I recently came across of a backup of some assorted IftU/AtS-related files in my homedir on bluecore, and one file named The_Start_of_The_Search.txt caught my attention.

I shortly remembered that a certain individual whose username I will not disclose dropped me a message on the forums in January 2008 with a proposal for scenario 1 of IftU’s then-unnamed sequel.

The verbatim contents of the text file follow.

I lLiked a Lot Your Campaing, here is an contribution for your sequel (accept it Please) :

After many years of wandering Galas, The Lady Of Ligth and Mal-Keshar runned into the Aragwaith Country seeing wath happened to the elves they tried to spoke with them so they reconciliate but it was useless, so they stayed a few nigths on the place of the Forest elves, and they started to deliberaate once again the Mal-Keshar idea of a few years of destroying Uria, since they rescued some of the prisioner of the Jail, the drake Spke:

Drake (I cannot Remember his name): Long Ago my Ancestors destroyed the gate to hell, but seeing that still are demons on Earth, i think that the gate wasnt destroyed at all, but was closed by our fire Breath, if im rigth i can guide you there to see the gate, if you want to enter onto the hell...

Galas: Yes that sounds like a plan but how we can get there? and more important since the power of the union was destroyed how we can destroy Uria?.

Mal-Keshar: ... ... ..., when i was a human mage aprentice i overheard some Silver Mages something about of the Clearnus Book, a book that is cursed by the knowledge that it posses since it have the greatest and darkest secrets of the magic, and my master said the same thing of it..., so i asume if we can found it maybe we can know if the union is really gone, or if its a major power than it.

Lady Of Ligth: Yes.., i have heard of that book, but he last one that had it was an Lich, fore being more specific an Horrible Lich, more powerfull than Keshar himself, and Horror Lich, but i heard that he was Buried onto an a Mountain (asuming that this is the Final from the Dark Hordes since i read the Ending idea i hope that the Authors dont have problem with this) but

Mal-Keshar: Aye its true that is such an Lich but, the last ive heard of him was that he wasnt exterminated, in fact he was just buried under the Rocks triying to escape to take revenge once again.

Lady Of Ligth: But the Problem is how we are gonna to free the Lich, and two how we are gonna to vanish him, since it more powerfull than Keshar and My Powers arent Completly Awoke at his point.

Galas: So we have to call to the Union, not the one of Ligth and dark but one from Almost all the races of this World, Excluding, Both Demons and Kahagarathi, and now that i remeber, wasnt a Civilization that was more superior on magic than Elves?.

Mal-Keshar: You refer the one of the Library?.

Galas: Yes, know that they said that they Knew that they opened some kinda of PPortal, if they are Survivors, and lets have hope that, well they havent lost their knowlredge, we can try to convince them to join them to our side, and try to open the Portal that our drake Friend Mentioned Before.

Mal-Keshar: Yes that wouldnt be such an a bad Idea.

Lady Of Ligth: Agree..., wait! there is...

Elvish Messenger: Red Alert, Red Alert, an a Shaxtal Group is aproaching.

Galas: The Shaxtal are now animals, they cant kill anything now.

Messenger: I Know, but these are lead by a Loyalist.

Galas: Well we have no choice but figth.

Well this is all for the First Scenario.

Admittedly, if I invested as much effort as this guy storyboarding AtS scenarios, I’d have finished the campaign and its (currently untitled) sequel by the end of 2009.

Wesnoth forums status III

nospam@example.com (shadowmaster) — Wed, 19 Jan 2011 17:56:00 +0000

Due to recent abuse of the Tor anonymization network detected on Wesnoth.org’s forum board, I have decided to permanently block access through this service.

This is rather unfortunate, since I have found myself in need of using Tor before, as an alternative to broken ISP ←→ Wesnoth.org’s upstream network routes; however, it seems to be the most sensible solution to help fight vandalism. I won’t hesitate to extend these measures to the rest of Wesnoth.org if further issues arise.

Users’ accessing the forums via Tor or any other blocked hosts, service providers and proxies will see the following error message:

Wesnoth forums status II

nospam@example.com (shadowmaster) — Tue, 18 Jan 2011 05:18:00 +0000

As those who have read the Wesnoth.org Website forum should know, there’s currently an ongoing brute-force attack targeted at the Wesnoth.org community board attempting to log into multiple users, developers, artists and administrators’ accounts.

Although the situation is mostly under control at the moment, it’s always a good idea to remind people to choose safe, non-guessable passwords for their online accounts, and to make sure they aren’t shared amongst services.

I have been setting up filters to deny access to the board to multiple suspicious addresses and subnets. If you see a 403 Forbidden message when trying to access the forums, follow the instructions on the error page to contact us so we can sort it out.

I don’t currently have further information available on the attack that I can freely disclose, although I personally suspect it’s an attempt to disrupt regular user activity by forcing people to fill in the maximum log-in attempts CAPTCHA in the User Control Panel page.

Wesnoth-UMC-Dev and Version Control Systems: Part 2

nospam@example.com (shadowmaster) — Sun, 09 Jan 2011 22:29:00 +0000

Since my last post on the matter, I have had the opportunity to experiment with Mercurial and Git much more for my own projects in order to investigate options for the Wesnoth-UMC-Dev Project. A random forumer recently raised a stealth complaint against our usage of SVN, and he seems to prefer Mercurial (I can’t blame him for it, since SVN sucks at every conceivable level), but I don’t think it is the solution for our usage scenario.

To get it out of the way, I do use Mercurial to manage the Spanish translation for the Atheme IRC Services suite, and more recently, Hakone and Poison Ivy are hosted at Bitbucket (which is pretty cool, especially since it has out of the box support for CIA bot notifications).

The problem, as all Wesnoth-UMC-Dev related issues are, centers around the learning curve for non-tech-savvy newbies.

Mercurial uses a very strange user-level commit representation that involves a revision number and a hash, like 136:5c70e078efce (Hakone tip as of this writing). The only component in this commit specification that matters to most commands is the hash — the commit number is just there for decoration.

This is particularly jarring when history becomes non-linear.

changeset:   136:5c70e078efce
tag:         tip
user:        Ignacio R. Morelle <shadowm@xxxxxxx.xxx>
date:        Sun Jan 09 03:37:37 2011 -0300
summary:     application: Normalize capitalization of "Wesnoth-UMC-Dev"

changeset:   150:5c70e078efce
parent:      148:537ad43f161b
user:        Ignacio R. Morelle <shadowm@xxxxxxx.xxx>
date:        Sun Jan 09 03:37:37 2011 -0300
summary:     application: Normalize capitalization of "Wesnoth-UMC-Dev"

These two commits are, as far as the content (diff) is concerned, identical. The only difference is that one resides within my local repository on my hard disk on a clean tree that doesn’t have any merges; the other is on the live Wesnoth-UMC-Dev website and has several merges resulting from the lack of the rebase extension in the Hg version we are using.

What’s wrong, you may ask? Those who are used to DVCSes won’t see anything of interest here. Those who are used to CVS or SVN will notice that the “revision numbers” in here differ for the same commit. Why is this? Because of the multiple merges down the history in the website’s repository. This is an arguably ridiculous case of non-linearity that could have been solved with the aforementioned plug-in if it were available on the system version we are running. However, it’s not too far from what would happen in an actual project with multiple contributors with direct commit access.

So, just like in Git, the ultimate solution for commit management is using hash specs. And that scares newbies because hexadecimal numbers are 1337 |-|/\XX0|3 stuff or something.

But unlike Git, the solution to our problem requires manual activation (~/.hgrc), and isn’t built into older Mercurial versions.

[extensions]
hgext.rebase =

Does this make sense to you? Good, because it doesn’t to me. Maybe it’s a cool way to demonstrate how extensible your VCS can be, but for me this is just ludicrous.

Git, on the other hand, is as bloated as a Swiss Army Knife, and you might not even need most of what it ships with — which is good, because not all of us are Linux kernel developers. Fortunately, the authors are not evil enough to try to lure unsuspecting clueless users with fake revision numbers.

(Incidentally, Mercurial is implemented in Python. And I hate Python, as you know. Coincidence? I think not.)

Resolutions!

nospam@example.com (shadowmaster) — Sat, 01 Jan 2011 06:30:00 +0000

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.

So long, autotools

nospam@example.com (shadowmaster) — Mon, 27 Dec 2010 18:54:00 +0000

Today I’ve found out that silene, one of the Wesnoth developers, has taken the decision to withdraw support for autotools (a.k.a. autoconf+automake, or configure + Make) without previous warning or discussion with the rest of the development team and distribution packagers.

Author: silene <silene@xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx>
Date:   Mon Dec 27 11:10:54 2010 +0000

    Discontinued support for building with autotools.
    Since r48086, wesnoth no longer builds (due to duplicate strings), and it would be a lot of work to fix the build system, so better drop it.
    
    git-svn-id: svn+ssh://svn.gna.org/svn/wesnoth/trunk@48092 xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

This came completely out of the blue, as you can see. I can’t really say whether I agree with this decision or not, however, in an ideal world it would not have been done without previous discussion in the developers mailing list at the very least.

Although I’ve spoken in the past against SCons (blah), it is my preferred build system nowadays thanks to its ease of use, simple management of multiple build configurations and loonycyborg’s hard work on improving our build scripts.

This is just one of the many upcoming changes in Wesnoth 1.9.4, but one substantial enough to require some previous preparation for those who are used to the good old configure script. Hopefully this will not be a too disruptive change for our users, but in case you feel profoundly affected by the decision, now you know who to complain to.

New Wesnoth Forums changes for a new week

nospam@example.com (shadowmaster) — Mon, 20 Dec 2010 02:38:00 +0000

To begin this holidays week, I have introduced a few minor changes to the Wesnoth forums which should hopefully increase organization and ease of communication amongst us.

First, there’s now a separate Miscellaneous forum dedicated to those silly Forum Games, which is not indexed, doesn’t account for post counts, and doesn’t have an associated Atom feed unlike the rest of the board. Its topics are not listed in the Active topics view either.

Second, we now have new profile fields that can be optionally filled-in by users wanting to share with the community a bit more of information about themselves. These are the gender, languages and IRC nickname items. They are all displayed in the regular individual profile view, as well as in your User Control Panel, and may be modified visiting User Control Panel → Profile → Edit Profile.

(Wesnoth.org being an international community, it makes sense to allow people to tell us what languages they speak so we may be able to give them assistance in their natural language whenever applicable, or to help us choose new moderators.)

The Wesnoth umcmg Branch

nospam@example.com (shadowmaster) — Sun, 19 Dec 2010 19:31:00 +0000

Not too long ago, I forked a branch from Wesnoth’s trunk and started committing stuff to it in the mainline repository, thanks to the awesome power of Git branching through the git-svn bridge. My main goal is to experiment with improvements to the add-ons download interface, trying to address some of our users’ most common complaints, while not touching trunk directly to allow Ilor — who’s in charge of the WIP new add-ons server/client implementation — to easily merge his changes with trunk and the other way around until I can get confirmation from him about the mergeability of my own work.

Right now there’s very little done in my umcmg branch, but today I’ve come up with some patches that should be trivial to mix into trunk.

Pictured to the right is the new Add-on Description dialog (taddon_description), intended to finish my quick-and-dirty hack from September 2009, which made it to trunk nearly at the same time as a string freeze entered in effect, making it impossible for me to polish this feature for 1.8.

At the left you can see something potentially less interesting, a work-in-progress Download progress viewer (taddon_download_progress) that is written using mordante’s GUI2 toolkit instead of the old GUI1. This is hardly usable right now, and in fact, crashes the game, proving yet again that I’m not really fit for messing with the network layer of our dear game.

It’s really tempting to just run over the Download/Update dialogs with a steamroller, but mordante’s got his own plans for that and the GUI2 listbox widget, which will unconditionally become a basic building block of the hypothetical, unified add-ons manager dialog, plus there’s also Ilor’s work on the new server/client; therefore I can only wait for now until these matters are settled and try to have something ready for 1.10 as a last resort if neither of the aforementioned solutions are available by the time we hit another string/feature-freeze period.

Wesnoth forums status

nospam@example.com (shadowmaster) — Thu, 16 Dec 2010 17:49:00 +0000

Today, around 15:00 UTC, the Wesnoth.org board was disabled by none other than me, in order to perform some maintenance work in the forum files. With this, the forums were upgraded from phpBB 3.0.7-PL1 to phpBB 3.0.8 and one mod was updated to a newer version still awaiting validation from the phpBB mods team.

Additionally, I added a new server-side redirection rule to convert old http://www.wesnoth.org/forum/ and http://wesnoth.org/forum/ links to use the current forums vhostname, forums.wesnoth.org. This should solve issues with inconsistent links lingering around and polluting people’s bookmarks and web pages with different forum paths — of course, this is not automatic and existing references need to be manually updated to reflect any required changes, but at least now /forum has got a well deserved final rest.

There isn’t really any other exciting news to share with you, although I do expect an undefined amount of users to have login problems the next time they visit the forums. This should not be a permanent issue, however, but if it turns out to be I have a solution (a.k.a. “plan B”) prepared for the occasion.

Wesnoth RCX 0.1.4

nospam@example.com (shadowmaster) — Fri, 10 Dec 2010 04:21:53 +0000

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!

Codename Morning Star 0.1.0 released!

nospam@example.com (shadowmaster) — Sat, 16 Oct 2010 02:44:31 +0000

UPDATE: the bugs in 0.1.0 were so annoying I uploaded a fixed version 0.1.0.1 shortly afterwards. Enjoy!

At last, the first working version of codename “Morning Star” is available — this is the new Qt4 GUI for team-colorization and palette switching for Wesnoth sprites.

After a day or so of working on it, distributed amongst 4 days, version 0.1.0 is now ready for downloading from this very site for testing purposes, although it should be usable for production from now on as well. Just don’t blame me if it eats your precious input.

Version 0.1.0.1 (Gzip tarball, 24 KiB)
SHA1 checksum: 132d326d265b61ae7441a599f7dc10537c13bc8e

In all seriousness though, I want this application to become usable by the general audience after reaching version 1.0. Artists are naturally the intended target audience, although users who just want to recolor Wesnoth sprites to use as their forum avatar may also find a use in this tool. However, to achieve this, I need your feedback. Please try Morning Star out, report bugs, suggest features (within the scope of the project’s goal), and if you think you can help with anything else, tell me!

Don’t forget that Morning Star is also in need of a definitive name!

Compiling the sources

Since I’ve got no packagers to help at the moment, the only way to install for now is from source. Since I’ve been working only with Qt Creator so far, there’s no specific build recipe other than the project file (morningstar.pro), which you are expected to use to generate a Makefile using QMake.

To do this, just make sure you have Qt4’s development files and QMake installed (package qt4-qmake on Debian and Ubuntu), and type the command as follows:

$ qmake morningstar.pro

Note: If you have Qt3’s version of QMake installed, you may have to explicitly use qmake-qt4 instead to avoid confusing the generator and messing up the sources.

Once QMake generates the Makefile, just issue make and wait for compilation to finish. The binary morningstar will appear in the source dir, and you can now run it from there — no installation is required.

Git repository

There’s also a Git repository hosted at Gitorious.org, from which you can download the latest source code, follow the history, and switch releases according to tags.

Morningstar in Wesnoth-TC

Git clone (git):

git clone git://gitorious.org/wesnoth-tc/morningstar.git

Git clone (HTTP):

git clone http://git.gitorious.org/wesnoth-tc/morningstar.git

Known issues at the time of release

Note: most of these issues have been fixed in version 0.1.0.1, uploaded around an hour after 0.1.0 for your convenience.

Closing the Open dialog without selecting anything once an image is already loaded produces a bogus error message.
The Open dialog doesn’t track the last visited directory path as it should, so it’ll always revert to the My Pictures location.
Dragging the selection in the color ranges listbox doesn’t update the preview as it should.
Image previews are not centered, and are not scrollable either.
The main window may be resized but the contents won’t adapt to the new size.

UPDATE (2010-12-06): migrated files to SourceForge.net

Wesnoth RCX (codename “Morning Star”) 0.1.1

nospam@example.com (shadowmaster) — Wed, 20 Oct 2010 21:55:20 +0000

A new revision of codename “Morning Star” is available, this time with a preliminary production name — meet Wesnoth RCX 0.1.1.

Version 0.1.1 (Gzip tarball, 32 KiB)
SHA1 checksum: bdb9c31e6e43ca1bf985e1e4d390d96dbab19e1a

The main changes in this version include fixing the glitches with dragging the selection in the color ranges list view, making the window resizable again (this time the contents adjust to its size), and a few minor revisions here and there.

Compiling the sources

To do this, just make sure you have Qt4’s development files and QMake installed (package qt4-qmake on Debian and Ubuntu), and type the command as follows:

$ qmake morningstar.pro

Note: If you have Qt3’s version of QMake installed, you may have to explicitly use qmake-qt4 instead to avoid confusing the generator and messing up the sources.

Git repository

There’s also a Git repository hosted at Gitorious.org, from which you can download the latest source code, follow the history, and switch releases according to tags.

Morningstar in Wesnoth-TC

Git clone (git):

git clone git://gitorious.org/wesnoth-tc/morningstar.git

Git clone (HTTP):

git clone http://git.gitorious.org/wesnoth-tc/morningstar.git

Feedback

UPDATE (2010-12-06): migrated files to SourceForge.net

Wesnoth RCX (codename “Morning Star”) 0.1.2

nospam@example.com (shadowmaster) — Sun, 24 Oct 2010 23:50:00 +0000

The source code for a new revision release of Wesnoth RCX is now available.

Version 0.1.2 (Gzip tarball, 60 KiB)
SHA1 checksum: 060e45725711a4f4dca284af1ceec2a144042fe4

The main changes in this version include adding support for dropping files into the application’s window or shortcut, and allowing to open more compatible file formats: Windows Bitmap (BMP), and depending on Qt4’s configuration, Photoshop PSD and GIMP XCF — note that output is still solely in the PNG format for simplicity and it’ll remain so.

I sort of promised support for dragging images from RCX, but that won’t be possible yet because it’s not as trivial as drop support and I’m too lazy at the moment. I also made a few minor revisions in the UI, but you probably don’t care about that or any of this until I can offer Windows and Mac OS X binaries — unfortunately, we’re not quite there yet because I need your help for that. It’s not magic. I can’t make it work without an adequate development environment for each platform and, as you should know at this point, I don’t own any Mac machines.

The instructions for using the source code don’t follow this time. I know what you think , so it’s up to you to read the included INSTALL file in the distribution archive.

Feedback

UPDATE (2010-12-06): migrated files to SourceForge.net