Nanacore

Six machines. Six plus one equals seven. My current laptop is named Reicore, where rei れい is a possible reading of zero in Japanese.

It was only fitting that the seventh machine—a desktop—would be Nanacore (nana なな) then.

NameYearCPURAMHard diskGraphicsOS
Reicore2010Intel Pentium T4300
2.1 GHz dual core
4 GiB500 GBIntel GM45Debian testing (Wheezy)
Nanacore2012Intel Core i7
(Ivy Bridge)
3.5 GHz HT quad core
16 GiB2 TBNVIDIA GeForce GT610Debian testing (Wheezy), Windows 7 (???)

Quite notably, everything is working fine with the latest Debian wheezy packages (although I compiled my own newer kernel later anyway) except for the onboard sound controller.

00:1b.0 Audio device: Intel Corporation 7 Series/C210 Series Chipset Family High Definition Audio Controller (rev 04)

The Intel HDA codec for these controllers is apparently not quite ready yet; as a result, the mixer sliders are slightly broken in that there is no master channel, the speaker channel has no actual volume slider, changing the PCM channel’s volume causes some slight noise, and I suspect some features are missing as well. Despite this, the driver works for basic usage given some precautions with the KDE sound system to choose the correct (PCM) channel for audio instead of the sliderless (speaker) channel. I would not mind to spend some additional time researching the situation later, but I really need to get back to work on non-audio stuff (a.k.a. AtS) right now, so that will have to wait.

Incidentally, the Debian KDE desktop task includes PulseAudio now (I believe this wasn’t the case with Squeeze). Rather unsurprisingly, PA continues to be a considerable annoyance for my usage (e.g. lockup during KDE login, 1% extra CPU usage during playback from any application), so I ditched it after a day or two for plain ALSA. I don’t really have a need for the extra layer of indirection since PA uses ALSA anyway and my sound needs are very basic — basically, just playing sound from media players, games, and application notifications.

For graphics I’m using a decidedly inexpensive NVIDIA graphics card for the sake of having an NVIDIA graphics card and parting ways with Mesa for a good while. And while I had intended from the get-go to install the proprietary drivers, a forced and thankfully short Nouveau intermission confirmed that Nouveau indeed eats kittens. And that’s really all there is to say on the matter.

Both the machine and Debian wheezy can do UEFI, but I quickly stumbled upon a couple of issues:

  • Using the EFI version of GRUB means the only way to get a working text console on Linux is to use a framebuffer console driver such as efifb. This is not supported by NVIDIA and the driver complains quite loudly about it.
  • The machine appears to enumerate my (USB) 3G modem’s built-in storage as the first and second hard disks when it is connected, breaking GRUB’s expectations about the location of the disk from which it will boot, which becomes the third (SATA) hard disk in such a situation. The PC BIOS version of GRUB only gets to see the real hard disk drive.

Since this is my first time dealing with an UEFI-based system yet, I don’t really know whether the second point is a bug in GRUB, or the platform itself. Regardless, the first point pretty much convinced me to not spend any further time on that and just go back to the BIOS flavor of GRUB. This doesn’t seem to have done anything for my broken Windows 7 installation, which I probably don’t really need.

I have been working on transferring my configuration and files from Reicore since this Monday, approximately, and I think I’m nearly ready to get back to business now.

(I actually wanted to post this on the 7th but I got sidetracked by the system migration and testing.)

My short inventory and history of personal computing devices

First there was an old (1997) Windows 95 OSR 2 box boasting a P55C Intel Pentium processor with an staggering clock frequency of 166 MHz; 16 MiB of RAM (later expanded to 32), a 1.2 GB* hard disk; it had an onboard S3 Trio64V+ with 1 MiB of video RAM.

* Hard-disk manufacturer ‘gigabytes’.

Then, there was another OEM machine (2002), running Windows XP on a 1.3 GHz Intel Celeron (“Celeron-S”) including 256 MiB of RAM and a 40 GB hard disk; before it was decommissioned for good, it ran both Windows XP SP2 and openSUSE 10.0; it was the first machine on which I ever installed Linux (SUSE Linux 9.3), and my original introduction to Wesnoth (0.9.5 from openSUSE 10.0) happened there; the onboard Intel 810E IGP became the victim of various Linux graphics-related shenanigans. (This was the last computer I ever owned that included a 3.5" floppy disk drive; unfortunately, it was broken and it took me a year and various casualties to figure this out.)

Later during 2006, Blackcore appeared: another OEM machine running Windows XP SP2, equipped with a 2.6 GHz Intel Pentium 4 (Prescott) with Hyper-Threading; 1 GiB of RAM, a 160 GB hard disk, and an IGP from the biggest piece of shit chipset manufacturer otherwise known as VIA. This was my first named computer, a practice which has truly paid off to this day. It currently runs the same original installation of Windows XP upgraded to SP3; it has run various Linux distributions and versions and I’ve not stuck with any of them simply because VIA is the biggest piece of shit chipset manufacturer.

Following the color-themed naming scheme, Greycore became the first laptop I ever owned around mid 2007; an Acer Aspire 5050 including an AMD Turion 64 MK-36, an amount of RAM I don’t remember anymore, 80 GiB hard disk drive, and Windows Vista. It first ran openSUSE 10.2 and openSUSE 10.3 besides Windows for a long time, until I got fed up with an incident involving a security update utterly ruining my system with terrible timing. It took a while before I finally decided to switch to another distribution instead of keeping the same old 10.3 installation around, but it was worth it — Debian Lenny (testing at the time, Q3 2008) was my choice and I have stuck with Debian ever since.

Greycore was decommissioned once Bluecore took over; an HP Pavilion dv5-1132la running Windows Vista SP1. It was a much better deal than Greycore in the long term, as I acquired it on Christmas Eve 2008 and it lasted until January 2011 with mild wearing symptoms until it finally kicked the bucket (it got better later); Greycore did not last more than a year before it got utterly wrecked.

Bluecore started with 2 GiB of RAM and ended up with 4 GiB as Wesnoth began to demand significantly more memory for compiling. The 2 GHz dual core AMD Athlon 64 performed very well at the beginning, but our favorite open source game’s development largely outpaced it. The 250 GB hard disk served me well despite running into low space situations in various opportunities as I began to experiment with the processor’s hardware-assisted virtualization capabilities. This overheating beast (51 °C - 64 °C idle, 65 °C - 92 °C under load) has only run Debian as its native operating system besides Windows — first Lenny (testing, later stable), then Squeeze (testing), and very recently, Wheezy (testing). The ATI Radeon HD 3200 was an infinite source of frustration when it came to OpenGL on Linux until very late 2009.

Its untimely and infuriatingly IGP-driven demise resulted in Reicore taking over; first temporarily, and then permanently as its 2.1 GHz dual core Intel Pentium T4300 and Intel GM45 graphics processor ended up proving far more worthwhile than Bluecore’s AMD-based configuration. Reicore (an HP Pavilion dv4-1624la) was purchased for someone else at first, and ran Windows 7 until she became mine, and then I proceeded to wipe it out to make room for Debian — first Squeeze (stable), and now Wheezy (testing). I have never run out of space with its 500 GB hard disk, and even today my /home partition has a little more than 50% of free space. It helps that the processor’s lack of virtualization capabilities has not been very encouraging in the virtual machine department, I guess.

NameYearDecom.CPURAMHDDGraphicsOS
1997Intel Pentium
(P55C)
166 MHz
32 MiB1.2 GBS3 Trio64V+Windows 95 OSR 2.0
20022006Intel Celeron
(‘Celeron-S’)
1.3 GHz
256 MiB40 GBIntel 810EopenSUSE 10.0, Windows XP SP2
Blackcore2006Intel Pentium 4
(Prescott)
2.6 GHz HT
1 GiB160 GBVIA POSWindows XP SP3, Debian GNU/Linux 6.0 (Squeeze)
Greycore20072008AMD Turion 64 MK-38
2 GHz
??? GiB80 GBATI Radeon Xpress 1100Debian GNU/Linux 5.0 (Lenny), Windows Vista
Bluecore2008AMD Athlon 64 X2 QL-62
2 GHz dual core
4 GiB250 GBATI Radeon HD 3200Debian testing 2012-10-22 (Wheezy), Windows Vista SP1
Reicore2010Intel Pentium T4300
2.1 GHz dual core
4 GiB500 GBIntel GM45Debian testing (Wheezy)

Wesnoth-TC 1.5.1, and the future

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

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.

Wesnoth-TC and Wesnoth RCX moved to Github

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/irydacea/wesnoth-tc.git
    Git transport: git://github.com/irydacea/wesnoth-tc.git
  • Wesnoth RCX (codename Morning Star):
    HTTP transport: https://github.com/irydacea/morningstar.git
    Git transport: git://github.com/irydacea/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.

Unswitching browsers

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 certain bug 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 two seemingly 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:

  1. Backup your profile or the whole .mozilla directory (on Linux/X11, no idea about other platforms);
  2. Go to the about:support page, and choose the Reset Firefox option;
  3. 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.

After the Storm 0.8.1

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

Chromium: day two

A couple of things:

  • I cannot press Escape on a loaded page to stop all playing GIF animations.
  • There isn’t an obvious way to search page contents backwards with the keyboard as in Firefox (it is Shift+F3 there).

What the hell?

Switching web browsers

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.

Continue reading

After the Storm Episode III: General status update

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.

After the Storm 0.8.0

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.

The changelog for this version follows:

Version 0.8.0:
--------------
* Scenarios:
* Mal Hekuba now wears purple TC as he did in IftU.
* E3S0 - Opening (Within):
* New scenario.
* E3S1 - Beyond her Smile (A Light in the Darkness):
* New scenario.
* E3S2 - Return to Raelthyn (Reckoning):
* New scenario.
* E3S3 - Amidst the Ruins of Glamdrol (A Path to Follow):
* New scenario.
* Units:
* Balancing:
* Increased Chaos Hound's recruit cost from 18 to 20.
* Increased Shaxthal Razorbird's recruit cost from 18 to 19.
* Decreased Shaxthal Runner Drone's ranged attack strength from 8-3 to 7-3.
* Fixed invisible Chaos Longbowman and Heavy Longbowman units due to missing
graphics.
* Fixed Elvish Trapper and Elvish Prowler disappearing during animations.
* Fixed NPC bird code deleting the previous on-map unit when moving a
bird to an occupied hex (i.e. worms in E2S9).
* Removed Kri'tan.