Patch:qt-4.6-4.7-compatibility.patch (Source code patch, 6.5 KiB)SHA1 checksum: e9e800c98bdb79c234d536277bfb5d3ea9014a89You only need to apply this patch if you are building version 0.2.0 from source using Qt 4.6.x or 4.7.x. Run qmake -v in the console to see the Qt version in use.

New in this version

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.

Known issues

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.

The unmodified 0.2.0 source code distribution will not build using Qt 4.6 or 4.7 without the patch provided in the Downloads section above. This issue was—rather unfortunately—discovered after the release was tagged. The fix has been committed to Git already.

Zooming in requires extremely large amounts of CPU time and memory, especially for images larger than 72x72 pixels at zoom levels greater than 200%. It’s advised that you avoid zooming in unless you have at least 2 GiB of RAM available.

Zooming does not preserve the current viewport, indiscriminately recentering it instead.

The preview background color choice is not persistent across re-runs. This has been solved in Git already.

The dialog shown by the Add from List option in the Palette Editor may have the help text cut off depending on your display and font configuration.

Dragging previews is not always possible on Linux/X11, depending on the Qt 4 style engine in use. A workaround has been implemented for the Oxygen style (KDE workspace default), but other styles that allow dragging windows from empty areas may ‘steal’ Wesnoth RCX’s events.

Dragging previews to Windows Paint does not currently work, presumably because the application expects to get access to a file on disk. Since Wesnoth RCX does not store the recolored image on disk until the user requests it, this problem might be impossible to fix.

The Windows build might occasionally crash during the initial file open dialog, apparently whenever a directory takes too long to display. This does not seem to happen later during execution.

The Windows build might display occasional minor glitches with mouse-over decorations on buttons and radio/checkboxes when running on Windows XP with styles supporting them (e.g the default Luna style).

The Add from List button in the Palette Editor remains enabled at times when it cannot do anything useful (e.g. when there are no palettes to select and edit). This has been solved in Git already.

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.

Finally

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.

Instructions

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

The past, and the future

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:

Wesnoth-TC:
HTTP transport:

https://github.com/shikadiqueen/wesnoth-tc.git

Git transport:

git://github.com/shikadiqueen/wesnoth-tc.git

Wesnoth RCX (codename Morning Star):
HTTP transport:

https://github.com/shikadiqueen/morningstar.git

Git transport:

git://github.com/shikadiqueen/morningstar.git

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.

If one takes any XUL (e.g. Firefox, Thunderbird) application and tests it against Gtk+ theme engines or color schemes other than the Ubuntu defaults*, various design shortcomings become evident, including things such as the developers’ inability to choose a toolbar icon set for Linux/X11 that doesn’t become uncomfortably unreadable against bright backgrounds.

I have to apologize for not doing the research on the icon part of this particular statement. It turns out this isn’t Firefox’s fault; it is just using the platform icons as it’s supposed to do on Linux/X11 since version 3.0 or so. So where do these icons come from? Let’s take a look at chrome://browser/skin/browser.css:

Since I use the Oxygen style in KDE for Qt 4 applications, I have set Oxygen Gtk for Gtk+ 2 and Gtk+ 3 applications, so those applications will use the Oxygen icon theme as well. But checking /usr/share/icons/oxygen/16x16/actions/, there are no files named gtk-*.png like Firefox wants. So it must obviously be using icons from the GNOME theme instead.

Bingo.

Mozilla’s decision to have Firefox use native icons on X11 seems questionable to me, since it breaks cross-platform consistency and tends to look like crap (compare Firefox on Windows, even on XP). But the actual bug here is quite clearly not theirs. The icons in question come from the gnome-icon-theme (3.4.0-2 installed) in Debian, and according to its copyright file:

One would think these people know better than this since there are other popular Linux distributions out there using bright color schemes by default, such as Fedora. The good thing about colorful icons is that they are generally designed to stand out regardless of the background color; it’s quite hard to achieve the same effect with monochrome designs.

I could not bear using Chromium for a week as I originally intended. All right, I admit I always intended to go back to Firefox, but the whole exercise didn’t go as planned for various reasons.

The thing is, I have always used Firefox since version 1.0 or so and it has basically become part of my personal life — it’s impossible for me to stay mad at it for too long after all we have been through together.

Nothing of this renders the points I previously raised here any less valid, but I have coped with those annoyances for a good while already — let’s not get too demanding in the usability department here, otherwise I may as well invest a zillion dollars in Apple products right now.

Besides, Chromium insists on taking up preposterous amounts of CPU time in the background every once in a while, even after getting rid of a certainbug with the Linux kernel and leap seconds. Despite all its inefficiencies, I have never seen Firefox indulge in such erratic (and potentially harmful for laptops) behavior like that while idle. I already did my best to diagnose the issue, but I never had that much interest in using Chromium as my primary web browser in the long term anyway. After all, I am a KDE user, which means I like options — the Chromium design philosophy is more or less the antithesis of that, and it shows.

There’s also these twoseemingly minor annoyances, and this — which makes more sense if you take this (from about 10:58 hours earlier) into consideration.

Not to mention that there’s no Chromium add-on providing a Bookmarks menu that looks nice, probably due to the previously mentioned design limitations. It’s also somehow more natural for me to have the Home button at the right end of the toolbar, but this might just be Firefox inculcating habits.

Going back to Firefox, it does seem like resetting its configuration and clearing all of my old web history before March 2012 improved overall performance. In case someone else wants to try resetting their own configuration:

Backup your profile or the whole .mozilla directory (on Linux/X11, no idea about other platforms);

Go to the about:support page, and choose the Reset Firefox option;

Follow the instructions on the screen to create a new profile preserving your browsing history, bookmarks, cookies, and saved passwords.

When done, you will be left with an additional copy of your old profile that might or might not still work — I didn’t check this. You can start Firefox with the -P switch to see the previous profile, and possibly delete it after you are done making sure all the information you need is present in the new one. You will lose all your installed add-ons, their configuration, and your browser preferences; this is pretty much the whole point of the procedure.

I for one had accumulated heaps and heaps of unused or obsolete configuration entries (both from add-ons and old Firefox versions) carried over since late 2008. That can’t possibly be healthy, especially considering that I have tried many, many add-ons and hidden configuration options over the years, and used pretty much all versions since Firefox 3.0.

It’s probably more important to keep the web history under control, though. Older versions of Firefox—if I recall correctly—had a user-visible option in Preferences to limit history to a given amount of time, but that doesn’t seem to be the case as of Firefox 13 and it’s all or nothing. Of course, it’s also possible that the current defaults do limit history and there simply isn’t a way to change that limit anymore; so if I ever changed it with a previous version, it would have become inaccessible to me later short of using about:config.

These two images are not the same, at least if you are using the default Firefox configuration on Linux/X11 with gfx.color_management.mode set to 2 (only tagged) instead of 0 (all disabled). It turns out I disabled that setting entirely at some point—for some reason—and later forgot about it.

To be more specific, the image to the right is the intended rendering. This is what the side-by-side comparison above should look like with the defaults.

It also seems I have been leaving behind a trail of PNG files in the web that contain bogus ICC information that causes Firefox—again, with the default configuration—to render them differently than I actually intended when exporting them in the GIMP. In the case of my avatar, it’s not a big deal since it’s just Xykon from the Order of the Stick serving as my terrifying spokesman spokeslich. However, if my memory serves me right I have seen this being an actual issue with my whole website layout in my default-configured virtual machines — and I always dismissed that color disparity as being caused by VirtualBox instead of Firefox.

Thankfully, the website CSS currently makes more use of browser gradients to prevent the faulty (?) graphics being used in practice. The spritesheet that contains the post category icon (used in the front page) is evidently affected, though.

But to what degree is it Firefox’s fault? Unfortunately, I understand jack shit about color profiles and I don’t seem to have a tool handy to tell me what the technical differences between both images are. I suspect I did something wrong in the GIMP at some point, or perhaps the problem was created by my application of a certain PNG optimization script. Does the wrongly rendered version of my avatar actually have color profile information in it?

What I do understand is that color profile information in PNG files has bitten my ass several times over the years, and not just with Firefox, but also with Wesnoth (via SDL_image).

If anyone there thinks they have a definitive answer to this conundrum, please share.

EDIT: Yes, I reuploaded my avatar to the Wesnoth.org forums and my Twitter profile during the last couple of days in order to fix this issue. It was just matter of opening importing the current versions in the GIMP and then saving exporting the unaltered contents to new files. I will probably try the optimization procedure on the fixed versions later.

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.

For more than a year I have been actively avoiding the web browser that all the cool kids use these days. I’m obviously talking of Google Chrome.

For all its excellent performance and ease of use, I kept being bothered by its insistence on breaking the mold and looking like a completely different thing running on my Linux system, instead of behaving like an application blending with its environment. I think it was this big annoyance that kept me from adopting it as my regular web browser for all this time. But compared to Mozilla Firefox, I think there’s just no matter of dispute anymore. Chromium/Google Chrome keeps getting better, and Firefox is stuck in the noughties, much like an evolutionary dead end in the history of fail web browsers.

The fact is, there are perfectly plausible explanations for the blending issue. It was only last night that I decided to do some research, and the first thing I found while looking around in the Chromium issue tracker was #10949, “Use GTK widget renderering in web content”. Various valid points are raised by the developers amidst some background noise — courtesy of random users. And truth to be told, it works. If one takes any XUL (e.g. Firefox, Thunderbird) application and tests it against Gtk+ theme engines or color schemes other than the Ubuntu defaults*, various design shortcomings become evident, including things such as the developers’ inability to choose a toolbar icon set for Linux/X11 that doesn’t become uncomfortably unreadable against bright backgrounds.

There are many other subtle quirks in Firefox as of late that make it glaringly obvious that it is unable to keep up with my own evolving requirements. Just to provide a few examples:

The whole browser often freezes for milliseconds (up to one second) when performing certain operations in the background such as opening a new tab. (Chrome appears to use and abuse IPC on Linux to avoid this at all costs.)

Scrolling motion often feels jerky, with occasional momentary rendering artifacts such as large blank chunks that are just displeasing or even painful to the eye. (In this regard, Chrome > Opera > Firefox here.)

Awesome Bar suggestions may take long to appear in some cases due to my extensive browser history, which is pretty much the only way those suggestions can be useful in the first place (I currently have no idea whether Chrome is different in this respect). The main problem with this is that there is no obvious indication as to how much time I should wait for suggestions to come up before giving up.

I can’t keep my tabs open and start a Private Browsing session on a new window. (Chrome allows “incognito” windows separate from normal browsing sessions.)

Firefox Sync is somewhat cumbersome by design, and yet it refuses to work most of the time for unknown reasons.

As far as I am concerned, there’s a certain threshold beyond which an application starts to become a nuisance rather than the facility any modern application should strive to be. Those days when everything was a chore are long gone; I want a web browser that’s fast, efficient, effective, and does not get in my way. Google Chrome/Chromium is rather daring—perhaps a little too much—in these terms, as you can see by yourself under “Content not chrome” in their User Experience page, but their approach appears to be effective if the browser marketshare trends are anything to go by.

•••

In conclusion, I have decided to give Chromium a more extensive test run for the rest of this week. Yes, Chromium (version 20 from sid), because I tend to feel the Debian packagers know their OS better, and the built-in Flash in the current stable Google Chrome appears to have problems with my machine and/or configuration.

Thankfully, importing my Firefox bookmarks, saved forms and other cruft took just a few clicks**. I will probably have to adapt to the different user interface design (already had to move some bookmarks around for easy access), but it might as well be a minor one-time hassle if it all works out well.

* (Seriously, “every Linux operating system is Ubuntu” would become a trope if Linux ever achieved
mainstream popularity.)
** (I decided against importing my web history, which goes back as far as June 8th 2011.)

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? Rocketscience, 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

Since the first three scenarios of After the Storm: Final are already out (0.8.0), I can now talk about my plans for the campaign to ensure we are all on the same page later.

This episode’s final scenario count is preliminarily advertised as twelve in the campaign menu entry, but the number may change as I see fit. More importantly, the final seven scenarios will be published as an atomic batch instead of separately. In fact, it’s very likely they will not enter the SVN repository until they all are finished.

For now, two more scenarios are expected to land in SVN trunk during the upcoming months; Outpost of Hell (E3S4) and Pass of Sorrows (tentative name for E3S5). Anyone who has been paying attention to the story and dialog sequences found in E3 so far will be able to predict the events taking place in E3S4 and E3S5. However, these scenarios (E3S4 in particular) require new units for gameplay and story reasons, and—since I am the only dedicated ‘artist’ working in the campaign—this part may take some time.

The campaign’s overall structure has resulted in decidedly slow storytelling and I don’t regret this design; basically, if you don’t like this, this campaign is not for you. However, things are going to get far more complicated after E3S5 as we approach the conclusion. Getting the finale right—in regards to code, prose, and art together, but especially art—may require a greater amount of energy than anything done before for AtS; hence, once E3S5 is out you may rest assured that unless a miracle occurs, the rest will take a large amount of time to be properly finished and released as After the Storm version 0.9.0.

Writing the finale is not a big deal per se since I’ve always known where the characters are going. The problem is making sure it’s worthwhile to play and read. I’ve always been flexible to plot changes in that regard since I resumed work on E1 last year; after all, this is a game, not a novel. The execution of the plot is also a touchy subject since the matter of the campaign doesn’t really fit neatly in a turn-based strategy game, and compromises must be made.

As usual, art is an ever-present issue as well. The finale requires more new units, props, and terrain graphics. When it comes to unit art, I have always been able to manage by reusing previous assets, making minor modifications and calling it ‘new’; but terrains and props are uncharted lands for me, which is why I fear art will take up most of the production time for the finale. And this is all not taking portraits into account; ideally at this point all major characters from this campaign—as opposed to those introduced in IftU—would have their own portraits, but that just hasn’t happened yet and is unlikely to happen in the near future.

In any case, this has been a very interesting journey. I hope it comes to an end soon and Final can be completed before the end of the year, but I’d not be surprised if it takes longer than that.

Version 0.8.0 is finally out, 16 days after the original deadline. Oh well. At least it didn’t take half a year like the last time I failed to meet a release schedule.

This version will most certainly not be exempt of flaws. It introduces the first three playable scenarios of Episode III (Final), plus two cutscenes; the playable scenarios haven’t been tested very thoroughly by my dedicated QA team or myself, and thus might be full of balancing issues, especially on difficulty levels other than Normal.

I guess I might as well take this opportunity to mention that Normal is, in fact, the only difficulty level I actually test.

There’s also a few bug fixes in this version, but nothing too important other than a voodoo fix for crashes affecting Mac OS X users at the end of Episode II (previously described in the forums). Somehow, I managed to forget to mention this item in the changelog this time; I feel this isn’t the only thing I forgot to do before releasing. Ah well, it probably isn’t my fault seeing as how I have to take care of so many things (cough art cough) for this campaign.

UPDATE: The immediate implication of this fix is that you will need to run Fate (the final cutscene scenario of Episode II, not the whole episode) again if you want Anya’s and Durvan’s stats to carry over to Episode III.