Back in September, I said:
I did some math thing. It seems that if I keep working on AtS 0.9.0 at constant speed it will be finished around March 2013. #Wesnoth
The plan has not changed.
Just wanted to note that I am ceasing my online Wesnoth and IRC related activities for an indeterminate amount of time while I tend to some matters of greater priority. In case you are wondering, yes, everything is fine, but I do need a break.
You can still message me through Twitter, email (preferably!), or private message through the Wesnoth forums (which result in email notifications) if something absolutely important crops up in the meantime other than the forums being down. I have provided the other Wesnoth.org administrators with instructions in case I’m needed for something specific, and for other issues you can always PM the Forum Moderators or Administrators groups or email the forums support address, which is displayed whenever things go completely wrong.
And of course, I may continue to post about non-Wesnoth things here as I see fit.
From a recent topic in Wesnoth.org’s Game Development forum:
[...] this is also quite close to advertisement, but you don't have the traits of a spammer.
This is one of my major qualms about the current organization of the Wesnoth.org forums. The non-indicative Game Development section was indeed created for that specific purpose of serving as a venue for advertising other games and potentially recruiting contributors. The definition of spam for this section is sketchy at best, but common sense suggests that the following forms of promotion would be off-limits:
If advertising in GD in general was considered spam, then the forum would be nearly or entirely empty. The question is, why do we provide this marketing channel in the first place? It seems to me like the primary goal is promoting open-source game development, but the forum description implies that this is not a strict requirement for posting there. I am not terribly comfortable with the idea that it should be our mission to do this seeing as how there are larger and better organized communities for this kind of thing, but I can see how some people might prefer to have means to preach to the world at large without having to maintain a blog or register accounts on other boards.
Quite lazy, if you ask me.
But all this is fine by me as long as I’m not forced to read every single topic that crops up in there.
Just as irker’s adoption rate is increasing, I have just completed work on a very simple application for Subversion repositories — two applications, in fact.
irker-svnpoller is a very simple script that polls a single commit log (not data) from a Subversion repository and delivers notifications to any number of channels using an irkerd running on the same host. It mimics the CIA bots’ formatting, much like nenolod’s irker CIA proxy, from which I borrowed a small amount of code.
irker-svnpoller → irkerd
But exactly how is this supposed to be useful to anyone, you may be wondering right now? Well, irker-svnpoller is not really intended to be used stand-alone. A timed poller script that tracks the last notified revision could come in handy, but people could get impatient waiting for their commits to appear in their IRC channels minutes later. I am well familiarized with the defects, quirks, and virtues of my primary audience—the Battle for Wesnoth and Wesnoth-UMC-Dev projects—, and this approach would simply not scale well over time.
Enter the first companion script, svnmail-filter. It reads email message headers from stdin to determine a commit’s revision number and the pertinent repository to probe using irker-svnpoller. Configuration is mostly done through a ruleset file using the JSON format.
Of course, svnmail-filter is not that useful on its own either. The idea is that procmail or some other MDA should pipe incoming email headers through svnmail-filter — and preferably, only those from legitimate sources, such as subscribed commit mailing lists. This is actually simpler than it sounds, and it is more or less inspired by CIA.vc’s perpetually broken mail-based SVN poller.
MDA → svnmail-filter → irker-svnpoller → irkerd
Since no service in the pipeline other than irkerd runs persistently in the background, this should be significantly more fault-resilient than CIA.vc’s approach, which apparently required a poller service to listen and act upon local requests. The downside is that the host running irker-svnpoller may need to create many short-lived SVN repository connections for individual commits in a chain. In Wesnoth’s case, SVN commit chains are rare enough, but their size often goes around a dozen individual commits or so. Regardless, this shouldn’t be terribly concerning for a production server with a decent low-latency uplink, and the overhead on the repository provider should be rather small compared to pushing massive commit diffs across the network.
Right now, the Wesnoth and Wesnoth-UMC-Dev projects are using this service as a stopgap measure until their respective providers—Gna.org and SourceForge.net—allow installing a hook that can either talk directly to an irkerd server, or to an instance of the aforementioned CIA proxy using the CIA XML-RPC method.
I am not all that keen on other people using a piece of software I developed and tested within less than three days without any prior experience working with Python. There are also various problems inherent to any application depending upon Subversion and its incompetent network transport layer.
Nonetheless, I published a Git repository on GitHub including a small amount of documentation to get started:
I am open to possible improvements coming from people intending to use this on production servers. In particular, if someone out there works with a commit mailing list where revision numbers can’t be found in mail subjects it would be necessary to adapt svnmail-filter a little to handle that case. Perhaps it might even be possible to skip the irker-svnpoller step for mailing lists where the notification message structure is constant and well documented.
Following CIA.vc’s untimely demise, ESR and a small ad hoc group of coders and testers including nenolod (from Atheme) and our very own AI0867 (who has led Wesnoth-UMC-Dev in my absence) finally completed the work required to get irker 1.0 out. irker itself has been a work in progress for a while since the last CIA outage in August.
It’s advertised as a CIA.vc replacement, but in reality it is something far less ambitious in scope: a write-only IRC bot that serves its own message bus. From its own README:
irkerd is a specialized IRC client that runs as a daemon, allowing other programs to ship IRC notifications by sending JSON objects to a listening socket.
It is meant to be used by hook scripts in version-control repositories, allowing them to send commit notifications to project IRC channels. A hook script, irkerhook.py, supporting git and Subversion is included in the dustribution (sic); see the install.txt file for installation instructions.
The author’s intention is for existing code forges to adopt this service, and perhaps optionally run it on their own facilities alongside their VCSes, allowing repository admins to opt in for using hooks that deliver notifications to those internal irker instances. irker’s pipeline is extremely flexible and can be summed up as follows:
Repository hook → irker instance → IRC server
CIA.vc’s pipeline is not entirely clear to me and I did not have the opportunity to inspect it from inside, unlike ESR. However, there’s enough evidence suggesting that it was more or less like the following:
Repository hook → CIA.vc XML-RPC or mail provider → CIA.vc database manager → IRC front-end → IRC server
Note that there was also a web front-end, which was integral to CIA’s mission as it was the only way to define projects and bots. A commit notification occurred for a given project; say, Wesnoth-UMC-Dev. The IRC portion of the pipeline made sure that all relevant bots (each one associated to a single channel from the model standpoint) would report the same commit. A less relevant Web front-end in the pipeline took care of adding the commit to the project page (including statistics and an XML feed).
The IRC portion was flexible enough to accommodate the simplest use case (notifying a single project’s commits in a single channel), and more elaborate yet still reasonable use cases (notifying commits from multiple projects in a single channel) without much hassle, all done by tweaking the bots’ configuration in the web-based configuration front-end. Even more advanced use cases were possible by choosing the Advanced Filtering option in the same front-end. This allowed me to have a bot in ##shadowm on freenode report commits as follows:
I should emphasize that this required no changes to hooks in each repository. Hooks delivered just a minimal set of information, including the commit hash or number, the commit message, affected path, affected branch (when applicable), affected module (when applicable), the author name, and the project name. Everything else was done on CIA’s side, including deciding which channels should get notified of individual commits.
irker does not do this.
irker’s perceived elegance stems from its very basic and versatile design. Essentially, it serves as a mechanism for a repository hook to interact with IRC without having to establish a short-lived connection to a server for every individual commit or commit batch — an approach that GitHub currently allows via a separate, seldom used IRC service hook. irker is not novel in design by any means, and the hype around it is only justified by the fact that nobody bothered to create and advertise any other service that could properly replace CIA.vc before and be inherently extensible maintainable over time.
irker’s extensibility and maintainability stems from the fact that a good portion of the work is done by the repository hooks, and irker is near completely stateless — the obvious opposite of CIA.vc’s architecture.
Unfortunately, this renders advanced use cases such as the above ##shadowm CIA ruleset completely incompatible with the irker pipeline.
[...] the original designer fell in love with the idea of data-mining and filtering the notification stream. It is quite visible on the CIA site how much of the code is concerned with automatically massaging the commit stream into pretty reports. I’m told there is a complicated and clever feature involving XML rewrite rules that allows one to filter commit reports from any number of projects by the file subtrees they touch, then aggregate the result into a synthetic notification channel distinct from any of the ones those projects declared themselves.
(He somehow got this part slightly wrong. Incidentally, it was me who brought it up in #cia around August 25th in the first place. The projects’ own notification channels were as synthetic as any others from CIA.vc’s point of view. That is to say, not at all. Additionally, they weren’t XML rewrite rules, but rather commit matching rules.)
His opinion is, naturally...
Bletch! Bloat, feature creep, and overkill!
Yes, I admit that it is overkill, but it was a nice thing from our point of view as users of the system. There’s a line between using a service, and administrating it.
On the plus side, seeing as how irker aims to become an actual standard for IRC feeds of any sort (not just for VCSes), it is good that it only implements the most basic functionality by itself. This should later allow us to come up with ingenious applications such as nenolod’s CIA proxy for irker (delivers CIA.vc XML-RPC requests in a format suitable for irker). Some people have even proposing building new services using irker’s protocol, adding an authentication layer on top and integrating it to IRC networks as a hosted service!
But replicating the end-user functionality a few people like me enjoyed will invariably take some additional effort. ESR suggests:
Filtering? Aggregation? As previously noted, they don’t need to be in the transmission path. One or more IRC bots could be watching #commits, generating reports visible on the web, and aggregating synthetic feeds. The only agreement needed to make this happen is minimal regularity in the commit message formats that the hooks ship to IRC, which is really no more onerous than the current requirement to gin up an XML-RPC blob in a documented format.
Of course, if the #commits channel on freenode ever regains its former glory, this would require a bot to listen to and filter possibly thousands of messages per minute, all coming from multiple clients. I don’t think I am fit to become the pioneer who’ll conquer this new land.
Furthermore, since the task of formatting messages for individual commits is exclusive to individual hooks, we may end up with a highly fragmented and inconsistent ecosystem. For example, as things stand right now, no-one is required to include #commits on freenode as a destination for commit notifications, and I imagine very few people will bother to do so in the future.
All in all, it was our own incompetence that allowed CIA.vc to die prematurely despite the multiple calls for replacing it, and the obviously deplorable service conditions. We can’t really complain now.
I normally don’t comment or report on other sites’ status in here since this is my personal blog, but this situation actually impacts Wesnoth, Wesnoth-UMC-Dev, and me directly; especially me, considering I went to ridiculous lengths the other day to solve a related issue on GitHub.
The point is literally the title of this post: CIA.vc is dead.
You know, CIA.vc; that amazing service which provided real-time VCS commit notifications on various IRC networks and that everyone took for granted. This is by no means the first time it bites the dust, but in this opportunity it’s suspected that nobody really bothered to make backups.
nenolod (who was merely hosting the instance running CIA.vc) explained the situation in freenode’s #cia channel about an hour ago.
Assuming the other people who had admin access don’t have their own recent backups, CIA.vc’s future looks particularly bleak right now. Here’s hoping that a dedicated team of competent coders with access to a suitable server for hosting will quickly build a better replacement within the next few days. (Ha, ha, ha. Right.)
A new release of Wesnoth RCX is now available for download!
Shortly after 0.2.0 was released, it was brought to my attention that it wouldn’t compile against Qt versions older than 4.8.0, even though the documentation says it should work with version 4.6.0 and later. I quickly amended that and published a patch (found amongst the 0.2.0 downloads in the previous announcement) addressing those issues. That patch is obviously no longer necessary, since the compatibility changes are integrated in 0.2.1 and later. Furthermore, I now have easy access to a build environment using 4.6 to ensure such a situation does not occur again.
A well known issue at the time 0.2.0 was released was some rather excessive memory usage when zooming in, especially for large pictures. 0.2.1 solves this by using a more conservative approach for zooming; in a particular case this decreases memory usage from around 1.1 GiB to just around 50 MiB.
Wesnoth RCX now remembers the main window size and the preview background color each time. Additionally, it’s now possible to apply TC to a whole color palette in the Palette Editor dialog, using the new Recolor option.
Finally, a few minor interaction issues were fixed in this release, including the Add from List option (Palette Editor) being available and non-functional when no palettes are selected.
Of course, as usual you can provide other kinds of feedback through the Wesnoth.org forum topic and this announcement post. It would be nice to hear from you if you use this software, regardless of whether you liked it or not — any feedback is appreciated here.
Go test and create, and have lots of fun!
The new major feature release of Wesnoth RCX is now available for download!
One year and nearly eight months have passed since the last release, version 0.1.4. There was very little activity for most of the time until July this very year, although the primary release goals had already been long established.
The new built-in palette and color range editors allow creating and modifying these items for the game’s recoloring engine with ease, as well as generating WML definitions for your use in add-on production and testing. Various user interface improvements and additions, such as a Recent Files section and a Reload action, allow for a smoother workflow. The redesigned main window now supports scrolling large and zoomed-in images, as well as dragging any of the previews to other applications accepting graphic drops, such as the GIMP.
This version also sees the addition of menu options to change the preview background color, cleaner file output notifications, an enhanced Windows build process with embedded version and icon attributes, and a simple
make install target for Linux/X11 users building from source. The included documentation has been improved in this release as well.
Some of the known issues with this release are mentioned in the
BUGS file included in the source code tarball; other issues have been fixed after the release, in the
master branch in the public Git repository.
With the move to Github came a few goodies; in particular, there is now an official tracker for bugs and feature requests for those who desire a better, supported alternative to the Wesnoth.org forum topic and these blog announcements.
As usual, you can also provide other kinds of feedback through those two aforementioned channels. It would be nice to hear from you if you use this software, regardless of whether you liked it or not — any feedback is appreciated here.
One problem in terms of development and testing is that I do not currently own a Mac machine, nor do I really intend to. This means I have to rely on certain assumptions and avoid doing anything too crazy that is not guaranteed to work on all platforms or—in particular—widget style engines. So far this appears to have worked fine, thanks to Qt’s cross-platform design.
The Windows (Win32) build has been tested much better in that regard, since my current development machine also functions as a decent VirtualBox VM host. I have gone to rather great lengths this time to improve the build by adding some embedded information to blend better with the environment, and including the Qt library in the
wesnoth-rcx.exe executable itself, thus removing the need for two DLLs in the distribution.
Testing on Windows and Mac OS X feels really important to me, given my target audience; most artists seem to prefer these mostly hassle-free operating systems, and I fully respect that choice. My goal is to reach as many artists as possible with a useful and powerful tool that does not get in the way of the creative process, unlike the Wesnoth game proper, so it’s important to ensure a minimum quality level for each release that is consistent across the three main supported platforms.
I have done a lot of work coding and testing this release on Linux (Debian wheezy), Windows XP, and Windows 7, and I hope there aren’t any showstoppers left in this version. However, as you can see above, there is still quite a lot left to do in terms of polishing. Depending on feedback, a new 0.2.1 release might be published in the upcoming weeks. However, many of the remaining bugs require more meticulous inspection and extensive design changes; those will not happen until 0.3.0.
In the meantime, go test and create, and have lots of fun!
UPDATE 2012-08-15: the Mac OS X binary is up now.
Wesnoth-TC 1.5.1 has just been released... or maybe not. It has actually been tagged for more than 24 hours already.
This version is really just a bug-fix release, which is why it’s not 1.6.0. In fact, it only really addresses some build-time issues that have cropped up over the last couple of years.
Both distributions come with a
README file, and the source code distribution also includes an
INSTALL file with detailed instructions for configuring, compiling and installing Wesnoth-TC. The Windows binary distribution doesn't require any installation besides unpacking it into an appropriate directory — which you may optionally add to
Long ago, this came into existence. At the time, I needed a quick way to preview my own team-colored unit sprites without going through the hassle of starting/restarting Wesnoth (or its internal cache), loading a saved game, and creating units in debug-mode. That was my initial motivation for writing Wesnoth-TC, and since it was tailored to my specific needs, it was born as a console application. I later decided to publish and extend it, hoping that someone else would provide a good full-featured user interface for it.
Actual artists prefer using graphical user interface applications on Windows and Mac OS X, and with good reason. That’s the software interaction paradigm that suits visual types better for obvious reasons, and that’s why I took it upon myself to write a larger GUI front-end for Wesnoth-TC that could be built and run on the three major platforms from a single code-base.
That front-end quickly became an adaptation of the original back-end code. And thus Wesnoth RCX became an entirely separate project sharing little more than a bit of history with Wesnoth-TC. And most importantly, Wesnoth RCX became the first GUI (Qt 4) application I have ever written.
Over time, my needs and personal preferences have changed. Wesnoth-TC now feels largely inferior to RCX merely because of the lack of a native front-end for it. RCX has also recently gained visual palette and color range editing capabilities, which renders Wesnoth-TC’s definition file system somewhat obsolete. Furthermore, RCX has continued to compile and run correctly over time regardless of the Qt 4 version currently installed, whereas Wesnoth-TC has broken in a few occasions with newer development environments.
Wesnoth-TC truly feels like a relic now, one I don’t really want to continue developing at this time when I feel RCX is more fun to improve and work with. I had plans to eventually integrate a full-fledged implementation of the Wesnoth Image Path Functions mechanism, but that seems over-ambitious right now.
So, yeah, Wesnoth RCX is the future. Stay tuned for version 0.2.0, coming soon with more features and improvements.
I have just finished moving Wesnoth-TC and Wesnoth RCX to Github — in my humble uneducated non-expert opinion, a much nicer place to be than Gitorious, which still lacks native CIA.vc support after all these years. Instead, Github supports CIA.vc and a large amount of alternatives which I’ll probably never use.
The project page on this website has been updated accordingly. If you were tracking the repositories at Gitorious, you will not be able to get further updates unless you update your configuration to point to the new locations:
Updating client repositories is actually far easier than it sounds:
$ git remote set-url origin <new URL>
Afterwards, you should be able to fetch/pull as usual.
This switch actually began some time ago when I was considering resuming Wesnoth RCX’s development (which stagnated ‘some’ time ago too). It took a while, but I finally seem to be back on track, all thanks to my currently unannounced self-imposed campaign development break — a break that should allow me to get back to business soon enough, with the renewed energy and coder momentum I will seriously need in order to pull *it* off.
Wesnoth RCX 0.2.0 will probably be released before the end of this week, as soon as I make sure everything works as intended, which will be less trivial this time due to the new shiny features it packs. There’s also a couple of Windows-specific oddities that I want to tackle before releasing.
Oh, and in the meantime there will be an update regarding Wesnoth-TC’s future.
Version 0.8.1 is out, right on schedule!
Just like the last time, this version will definitely not be exempt of flaws. You will most likely stumble upon dreadful bugs along the way, and I will need your help to fix them — make sure to report them in the campaign’s forum topic as usual!
Special thanks go to bumbadadabum for kindly providing a patch to integrate the changes to the Aragwaithi faction from his multiplayer add-on (The Aragwaithi in the 1.10 add-ons server) into AtS. 0.8.0 users shouldn’t have any game-breaking problems playing with their old units from saved games of E3S3 (Amidst the Ruins of Glamdrol), although some animations may not display correctly. If in doubt, restart from the start-of-scenario save for E3S3.
Also note that due to an internal change, if you load the start-of-scenario save for E3S4 (Outpost of Hell) from version 0.8.0, you will see the loadscreen twice. This is normal and intended, and only affects old saved games for that scenario.
This release is a turning point for various reasons I had already explained a while ago. The good thing is that once scenarios stop landing in SVN, I no longer need to worry about release schedules and pacing. I can now start pushing bug-fix releases as necessary, without affecting the development of the campaign finale.
It is also a turning point in other senses that attentive players will most certainly realize on their own. But in case someone feels disappointed by certain developments: I left enough clues scattered everywhere before, and everything is going according to plan. The bottom line is: if you don’t like the story and you can’t ignore it, don’t play the campaign. And just to be clear, it has never been my intention—at least since I resumed its development in 2011—for it to be eligible for mainline or anything like that.
The changelog for this version follows:
Version 0.8.1: -------------- * Graphics: * New or updated unit graphics: most Aragwaith units (wayfarer). * Scenarios: * E2S3.1 - Unrest in Raelthyn: * Updated to use Aragwaith units. * E2S8 - And then there was Chaos: * Fixed elves who are initially Loyal getting a duplicate trait when switching allegiances. * E3S2.1 - Return to Raelthyn: * Minor map balancing changes. * E3S4 - Outpost of Hell (Gateway): * New scenario. * E3S5 - Pass of Sorrows (Gathering Storm): * New scenario. * Sound effects: * Added hit and death sounds for Doors. * Added additional explosion/thunder sounds. * Added magic glyph sounds. * Units: * Balancing: * Removed marksman special from the Demolisher Drone's ranged attack. * Increased Sprite's impact resistance from -20% to 0%. * Increased Fire Faerie's impact resistance from -20% to 0%. * Increased Dryad's impact resistance from -10% to 0%. * Increased Aragwaith Seer's HP from 39 to 44. * Increased Aragwaith Seer's melee attack from 7-2 to 8-2. * Increased Aragwaith Seer's ranged attack from 8-3 to 10-3. * Decreased Shaxthal Razorbird's melee attack from 10-1 to 8-1. * Decreased Shaxthal Thunderbird's melee attack from 13-1 to 10-1. * Gave Doors a unit icon for the sidebar and the attack dialog. * Updated Aragwaith units to match the faction from bumbadadabum's "The Aragwaithi" add-on. This has resulted in the following changes: * Protection only affects allied L1 and L0 units instead of any allied lower level unit * Ancient Banner abilities: +leadership, -protection, -steadfast * Ancient banner resistances: impact 10% -> 20% * Ancient banner stats: HP 55 -> 58, MP 4 -> 5 * Ancient banner attacks: sword renamed to scythe * Archer attacks: melee 6-3 -> 4-3 * Captain abilities: +leadership, -protection, -steadfast * Captain resistances: blade 20% -> 10%, fire 10% -> 0%, cold 10% -> 0%, pierce 20% -> 10% * Captain stats: HP 43 -> 55, MP 4 -> 5 * Captain attacks: spear renamed to glaive, 17-2 -> 18-2; sword renamed to glaive, 9-4 -> 10-4 * Eagle Master stats: HP 48 -> 45, MP 7 -> 9 * Eagle Master attacks: blade 9-3 -> 10-3, impact 15-2 -> 16-2 * Eagle Rider defense: mountain 60% -> 50% * Eagle Rider stats: HP 36 -> 34, MP 7 -> 9, cost 21 -> 23 * Eagle Rider attacks: impact 10-2 -> 12-2 * Flagbearer abilities: +leadership, -protection, -steadfast * Flagbearer resistances: blade 20% -> 10%, fire 10% -> 0%, cold 10% -> 0%, pierce 20% -> 0%, impact 10% -> 0% * Flagbearer stats: HP 34 -> 45, MP 4 -> 5 * Flagbearer attacks: spear renamed to glaive, sword renamed to glaive * Greatbow stats: HP 43 -> 46, MP 5 -> 6 * Greatbow attacks: melee 13-3 -> 10-3 * Guard abilities: +steadfast * Guard resistances: pierce 20% -> 10%, impact 20% -> 10%, blade 30% -> 10% * Guard stats: HP 40 -> 54, XP 78 -> 64, cost 27 -> 28 * Guard attacks: melee 12-3 -> 11-3 * Guardian resistances: fire 10% -> 0%, cold 10% -> 0% * Guardian stats: HP 51 -> 62 * Lancer now has a female variation * Lancer stats: HP 40 -> 48, cost 38 -> 34 * Longswordsman stats: HP 38 -> 46, MP 5 -> 6, XP 78 -> 88, cost 24 -> 27 * Pikeman resistances: blade 20% -> 10%, impact 10% -> 0%, fire 10% -> 0%, cold 10% -> 0% * Pikeman stats: HP 44 -> 50, XP 94 -> 70 * Pikeman attacks: melee 17-2 -> 16-2 * Scout now has a female variation * Scout stats: HP 31 -> 36, XP 36 -> 40 * Scout attacks: melee 10-2 -> 11-2 * Shield Guard abilities: +protection, +steadfast * Shield Guard resistances: pierce 30% -> 10%, impact 30% -> 10%, blade 40% -> 10% * Shield Guard stats: HP 54 -> 66 * Shield Guard attacks: melee 16-3 -> 15-3 * Silver Shield now has a female variation * Silver Shield stats: HP 54 -> 62, MP 8 -> 9, cost 38 -> 48 * Silver Shield attacks: melee 13-4 -> 12-4 * Slayer stats: HP 45 -> 53, MP 5 -> 6, cost 46 -> 62 * Slayer attacks: melee 12-4 -> 11-4 * Sorcerer renamed to Sorceress, no longer has a male variation * Spearman resistances: blade 20% -> 0%, pierce 20% -> 10%, impact 10% -> 0%, fire 10% -> 0%, cold 10% -> 0% * Spearman stats: HP 30 -> 34, XP 38 -> 43 * Spearman attacks: 11-2 -> 12-2 * Strongbow stats: HP 35 -> 38, MP 5 -> 6, XP 80 -> 85, cost 31 -> 38 * Strongbow attacks: melee 9-3 -> 7-3, ranged 8-4 -> 9-4 * Swordsmaster id changed, breaking old saved games with the unit * Swordsmaster stats: MP 5 -> 6 * Swordsman resistances: blade 10% -> 0% * Swordsman stats: HP 28 -> 32, XP 32 -> 39, cost 13 -> 14 * Warlock renamed to Witch, no longer has a male variation * Witch stats: XP 44 -> 54, cost 18 -> 22 * Witch attacks: staff renamed to kick, 6-2 -> 7-1 * Wizard no longer has a male variation * Wizard attacks: melee 10-2 -> 7-2, ranged 11-3 -> 10-3
Back in January, I posted my initial plans for Wesnoth 1.12 in the developers’ mailing list to gather some feedback and hopefully motivate other developers to do the same with theirs. Guess what, that didn’t work, so here I am back at home cooking up code and user interface changes in solitude. In fact, it’s all almost ready for 1.11.0.
1.11.0 is getting closer, but it’s still a little too far; this is mainly because the map format and editor changes in trunk have not been finalized yet and loose ends abound. Thankfully, I am not the one responsible for that mess. My mess is much prettier, practical, and necessary; and it is this mess that my post is all about.
Anyone who has used add-ons in Wesnoth 1.8 and 1.10 should be able to recognize this window; previously called the “Get Add-ons” dialog, now called the “Add-ons Manager”. It remained largely unchanged during 1.9.x because I spent two years dealing with more pressing matters, so the differences seen in this screenshot should be quite obvious. But this didn’t come to be possible in a couple of days, no; in order to enable these improvements to happen I had to refactor an amount of ugly and inefficient code I had previously moved around during 1.5.x, and then add a few back-end features here and there. That button on the top right corner? Rocket science, I tell you.
Most of my mainline commits since March have revolved around this area, starting with the refactoring that allowed me to implement the basics for actual add-on status tracking in the engine; that is, now it’s much easier to tell whether an add-on is installed, upgradable, or outdated on the server, without duplicating massive amounts of code. There is also a degree of separation between the add-ons manager UI layer and the client-server interaction code that might allow even better features to crop up in the future, such as upgrading add-ons from the MP lobby when deemed convenient by the user and/or the game.
But for now, I’ll focus on the add-ons management UI goodness that has already landed in trunk over the last couple of months.
Perhaps the most obvious change at first glance is that add-on list rows come with a status line indicating whether a particular entry is installed or not, amongst other things. For those skimming the add-ons server list, the color formatting should aid in quickly identifying entries of interest.
A less obvious change is that add-ons are not initially sorted by upload time anymore. This makes the age-old tradition of rushing uploads to a newly started server absolutely irrelevant from now on, since add-ons will be first sorted by title instead. Incidentally, for this purpose I was originally going to use identifiers (directory names), but then I found out there are quite a lot of people who upload add-ons with mismatched ids and titles.
Now we can also filter the add-ons list according to the kind of content we are looking for, in addition to the previous keywords-based mechanism. The additional options allow for displaying only add-ons with a specific installation status and belonging to specific categories. I am sure I don’t need to remind add-on authors about doing this properly since the basics of add-on classification have been around since 1.5.1 (mid-2008).
Installed add-ons are displayed with additional information when applicable, such as whether they can be upgraded or not, and what the installed version is relative to the version on the add-ons server.
The Upgradable add-ons view behaves identically to the old Update Add-ons dialog, which has been merged into the main Add-ons Manager in order to reduce code duplication.
The Description button still allows for displaying more information about the currently selected add-on, including its description and available translations. Don’t mind the gap at the start of the description in the screenshot, though; that’s the maintainer’s own doing.
Finally, we get a nice warning if we attempt to install add-ons from the server which we have already installed and contain
.pbl files or version control (e.g. Subversion, Git) metadata. This is only relevant for add-on authors, maintainers, and contributors who might accidentally lose their changes otherwise.
Not pictured in any of these screenshots is the addition of a whole new Help section dedicated to explaining the various add-on types, how they are played, and how they are managed. You can see the accompanying Help button in the Add-ons Manager dialog, though.
All this shouldn’t be news for those who regularly follow me on IRC (either
#wesnoth-dev or my personal channel on freenode) or Twitter, although I may have neglected the latter crowd in order to make this proper post sound a little more impressive. Frankly, I can’t accurately describe how awesome these improvements are by myself; thus, I encourage people to try them out when they get a chance, either by building and testing current trunk—with all the implications—or eagerly awaiting the upcoming 1.11.0 release, and the beginning of this long road to 1.12