WML is the primary source code language for all add-on and mainline content for Wesnoth. Creators like me write large amounts of WML to instill life into their user-made projects. Our wiki has a rich reference section for the various dialects of WML understood by the game in different contexts. Tools like wmllint exist to make sanity-checking and porting tasks easier for the few people who can tolerate its obtuseness us. There is a whole forum section in Wesnoth.org dedicated to assisting people with their WML endeavors.

With so many resources available, you’d think WML is the most fun thing to work with, right?

1. The problem

One of the most annoying aspects of add-on development is that whenever something goes horribly wrong with the WML document’s well-formedness, you may get a barrage of file paths thrown at you in a superdense text-wall format, particularly so if the error site has been subject to file or macro substitutions, which is the case with pretty much every add-on that has more files than its top-level _main.cfg. Trying to find the relevant portions of the substitution trace to debug the issue can be frustrating at best.

The report is displayed on the screen by calling a generic GUI function that creates a new instance of a generic message dialog with the specified contents, which are also printed in stderr. Since the only formatting option available for the dialog is to rearrange the text with a combination of whitespace and newlines, the same thing winds up in stderr in the same format:

20140216 10:50:12 error config: error reading usermade add-on '/home/shadowm/.wesnoth-1.11/data/add-ons/After_the_Storm/_main.cfg'
20140216 10:50:12 error general: The following add-on had errors and could not be loaded:
/home/shadowm/.wesnoth-1.11/data/add-ons/After_the_Storm/_main.cfg
ERROR DETAILS:
Found invalid closing tag [/unit] for tag [side] (opened at ~add-ons/After_the_Storm/episode3/scenarios/13_Epilogue.cfg:98 included from ~add-ons/After_the_Storm/base-loader.cfg:20 included from ~add-ons/After_the_Storm/_main.cfg:174 included from ~add-ons/After_the_Storm/base-loader.cfg:108 included from ~add-ons/After_the_Storm/_main.cfg:174 included from ~add-ons/After_the_Storm/episode3/scenarios/13_Epilogue.cfg:101 included from ~add-ons/After_the_Storm/base-loader.cfg:20 included from ~add-ons/After_the_Storm/_main.cfg:174 included from ~add-ons/After_the_Storm/base-loader.cfg:108 included from ~add-ons/After_the_Storm/_main.cfg:174), value ']' at ~add-ons/After_the_Storm/episode3/scenarios/13_Epilogue.cfg:94 included from ~add-ons/After_the_Storm/base-loader.cfg:20 included from ~add-ons/After_the_Storm/_main.cfg:174 included from ~add-ons/After_the_Storm/base-loader.cfg:108 included from ~add-ons/After_the_Storm/_main.cfg:174 included from ~add-ons/After_the_Storm/episode3/scenarios/13_Epilogue.cfg:112 included from ~add-ons/After_the_Storm/base-loader.cfg:20 included from ~add-ons/After_the_Storm/_main.cfg:174 included from ~add-ons/After_the_Storm/base-loader.cfg:108 included from ~add-ons/After_the_Storm/_main.cfg:174

This issue affects mainline and UMC developers alike, and yet, it has gone unsolved for a whole decade of development, even while other usability issues have been and continue to be addressed. Perhaps the very fact that the problem has existed for so long has silently perpetuated a misguided notion of impossibility — because, surely, if fixing the relevant code was that easy, somebody would have already done it? Or maybe, just maybe, everyone is afraid of altering code that lies deep within the core of Wesnoth’s WML processing pipeline; because it is an indisputable truth that the WML preprocessor and parser aren’t the most accessible modules for inexperienced contributors, and changing functionality that constitutes the circulatory system of the game engine is obviously a risky thing to do.

But wait! Wouldn’t it be possible to just sort of... make the error report presentation nicer without meddling too much with the implementation details?

2. The solution

While the basic proposal sounds simple and the results of my two-day-long coding effort made it into Wesnoth 1.11.10 (a.k.a. 1.12 beta 1), it turns out that there are many more factors to take into account, and in the end I did have to mess with parser and preprocessor implementation details to a greater degree than I feel comfortable with.

Against what one would expect, there is only one exception object class in existence for parser errors, and it is extremely generic. Callers have no way to tell what just happened when WML parsing has failed, other than asking the exception object for an error message... which is both stored and delivered in plain string form. The error type, the error site, and the WML preprocessor substitutions that led to it; these are all provided to the caller in an atomic string that may contain portions translated to the user’s language beforehand. This means that we (the parser’s callers) can’t reliably scan the error message to choose the format in which we are going to present the error to the user. All we can do is grab that big-ass message string and throw it into a dialog.

The dialog used to display the report in versions up to and including 1.11.9 is part of the GUI2 framework, but the particular dialog class in use is a plain generic message box. Naturally, it is not optimized for presenting WML error messages to the user — or displaying overlong strings in general, really. It is for this reason that the first part of this little project of mine consisted of designing a new dialog class (gui2::twml_error) for presenting this information to the player in a more useful fashion.

3. The dialog

Because the Wesnoth config manager will try to load all add-ons at once, the first thing that the dialog needs to do is to display a list of add-ons that caused a parser or preprocessor error when attempting to load them. The 1.11.9 approach is to hastily concatenate a newline-delimited list of paths to the files Wesnoth attempted to load, which are nearly always the _main.cfg files. This can be quite misleading in most cases, and newbies might try to look for the faulty code in the listed _main.cfg since it is the very first thing displayed in the error message.

gui2::twml_error instead displays the user-friendly name (1) of the add-on that was stored in a special file (_info.cfg) when it was first downloaded from the server — failing that, it makes its best guess by replacing underscores in the directory name with blanks. If multiple add-ons failed to load, they are shown in a nice bullet list.

Where there used to be more plain dialog text, there is now a pretty scrollable box with the report contents (2). The report itself contains the list of errors found when loading the affected add-ons, but it is no longer all thrown at your face at once — the error log for each add-on is followed by an additional empty line, so telling them apart should be far easier than before. Finally, right above the report there is a button (3) to copy it to clipboard so players don’t need to take a screenshot of the whole thing to give to the add-on maintainer(s).

To be perfectly honest, the only reason that copy-to-clipboard button even exists is that I find error message screenshots irritatingly cumbersome to work with at both ends. It doesn’t help that I’m usually on slow Internet connections where downloading a screenshot of a Wesnoth instance surrounded by some fancy window decoration and taskbar and (occasionally) desktop wallpaper can be excruciatingly painful. Furthermore, as a forum administrator who has to keep an eye on how people use attachments, this preposterous waste of disk space can be quite annoying.

⁂

But replacing the error report dialog and the presentation of reports as a whole is not enough to improve the WML coder’s experience. gui2::twml_error would still display the text wall-like errors if it were asked to do so by the config manager. Even though I hinted at the essentials above, the muddy implementation details screened by gui2::twml_error would still fill up a whole blog post on their own. Thus, I am going to leave that story for another time.

04:51:30 <shadowm> aeth: I like to think of PHP as a recreational drug.
04:52:03 <shadowm> Everything is easy and cool until the effects pass.
04:52:16 <shadowm> Then you realize you are making your life more miserable by relying on it.
04:52:26 <shadowm> But you keep coming back!
04:52:51 <shadowm> Kids, remember, just say NO to PHP!

Since I have tested and developed this campaign primarily on Wesnoth 1.11.x since the 0.9.0 release, this version promotes support for Wesnoth 1.11.8 to official status. Because most of the campaign makes use of 1.11.x-specific features (both from me and other mainline developers) when available, it is quite possible that I will entirely drop support for Wesnoth 1.10.x in a future release even before the first Wesnoth 1.12 beta arrives. I still intend to make sure certain additions and changes for episodes II and III land before the last AtS version supporting 1.10.x, if time permits.

This 0.9.9 release primarily deals with prose corrections and improvements, and various other ‘cosmetic’ changes. There are also various fixes for some instances of dysfunctional AI recruitment on Wesnoth 1.11.7 and 1.11.8 resulting from the recruitment_save_gold aspect being enabled by default in those versions (but not 1.11.9 and later).

There isn’t much in terms of new graphics since the prose and code changes (plus some mainline stuff) have kept me far too busy to do much more than some doodles. On the other hand, this release contains various animation fixes and improvements to the Aragwaithi units ported from Era of Chaos. There are also a handful of balancing changes affecting both Aragwaith and non-Aragwaith units.

Also featuring in this release are a number of WML optimizations intended to reduce campaign load times — especially on 1.10.x, which has a slightly slower tokenizer implementation than 1.11.x. Since the affected bits of code have been completely rewritten in Lua, it is possible that I accidentally introduced new bugs in the process that I may have missed during my playthrough, extensive as it was.

There is also a new secret feature that is not mentioned in the changelog. What is it, you ask? Well, if I told you, that would ruin the surprise. Think of it as a Christmas present!

Finally, from this release onwards, After the Storm is no longer part of the Wesnoth-UMC-Dev Project, and will be hosted on GitHub instead. Ever since development of the campaign started, Wesnoth-UMC-Dev provided SVN repository hosting for both After the Storm and Invasion from the Unknown, but over time that has proved to be an inefficient solution due to technical and organizational concerns. Although the conversion process was not easy in the least, I believe that this move will make things easier for me in the long-term, since I had been using git-svn to work on IftU and AtS since late 2008 anyway.

Release tarballs will continue to be hosted by Wesnoth-UMC-Dev for the time being, until I decide to phase them out entirely in favor of GitHub’s Releases page. If anyone is using them because they cannot normally download AtS or AtS_Music from the wesnoth.org add-ons server, I’d appreciate it if you let me know so I can make a more informed decision in the future (or point you to add-ons.wesnoth.org, that works too). For the time being, the tarball compression format has changed from Bzip2 (.tar.bz2) to xz (.tar.xz).

⁂

Special thanks to vultraz and 8680 for their proofreading assistance, without which this release would be about 1% less awesome. Also thanks to the current and past Wesnoth-UMC-Dev admins, AI/AI0867 and Espreon, for their continued support all these years — IftU and AtS simply wouldn’t be the same without Wesnoth-UMC-Dev.

I posted a rather extensive report of the results of the asheviere.wesnoth.org → baldras.wesnoth.org migration to the developers’ ML because Ivanovic wanted me to post updates to the ML for some weird reason. I am fairly sure the people who are actually subscribed to it skip them entirely.

Because I care about transparency and stuff, I pointed out an important thing there:

[…] the migration process went smoothly and now the wiki is running MediaWiki 1.21.2 instead of 1.16.1. Look up 1.16.1's release date and the branch's EOL date and you'll understand why I've been saying "not really optimal" and "deplorable" when referring to the wiki.

(Only after sending the mail I realized that I wrote MW 1.16.1 instead of 1.15.1. The version that was running on wesnoth.org is indeed 1.15.1, not 1.16.1.)

I don’t really have anything to add here, but I am providing a verbatim copy of the email after the break anyway, only because it’s a wall of text and I like those.

As announced in the Wesnoth.org forums, today (although it’s still yesterday for me) we are moving most of Wesnoth.org’s facilities to a new host, to continue the migration process that started with the previous move of add-ons.wesnoth.org, devdocs.wesnoth.org, and files.wesnoth.org.

What you probably wouldn’t guess from the announcement is how complicated the underlying machinery actually is. I did not want to clog up the post with additional details because that is often confusing for most people, but here is a list of services that will be directly affected by this whole operation:

... and many, many others, including hyphen/number variations of the above.

Because we are seriously understaffed, I have literally spent months copying things over, testing, upgrading, rebuilding, and even redoing some steps several times in some cases. However, only during the last month I have been working non-stop on stuff, realizing the deplorable operating conditions of a couple of our services, one of which I cannot fix on my own.

Today’s migration doubles as a full OS upgrade accompanied by an extensive internal network architecture change, as well as an upgrade of the forums and wiki applications. Upgrading the forums has never been a big deal for me, but everything else is uncharted territory. Given these complications, I have spent most of the aforementioned amount of time learning and testing things that shouldn’t really be my business in an ideal world, MediaWiki included. It’s not a particularly rewarding task (aside from the learning experience), but it must be done for the sake of all... especially that of our finances department.

I’m awfully anxious about all this. I’m going to make sure to have a cup of tea handy when the time comes.

For very long, there have been only two (2) campaigns in the Wesnoth add-ons server that follow the “shadowmcanon” established by Invasion from the Unknown and After the Storm; the campaigns in question are Invasion from the Unknown, and After the Storm. Yes. That’s it. The only other campaign whose author has consulted plot matters with me and followed the shadowmcanon correctly (as opposed to blindly extrapolating from IftU and AtS and making grossly wrong assumptions about things that are left unspecified or presented in a deliberately vague fashion) is The Silver Lands, but it was abandoned far too early during its development cycle.

But the status quo has just changed with the release of version 0.5.0 of Shadows of Deception (NX-RPG), a campaign by vultraz for Wesnoth 1.11.6 and later. So far, six scenarios out of the first set of 12 have been done; the goal is two episodes.

Of note is the fact that vultraz has been a member of my After the Storm internal playtesting and prose reviewing team for a couple of years.

Per the description found in the campaign’s forum thread, Shadows of Deception (SoD for short) is “a half-RPG, half regular style Wesnoth campaign, incorporating several custom gameplay elements as well as your typical battle scenarios”. What does half-RPG mean? Damn if I know — I don't even know what a full RPG would be. Having playtested SoD prior to the release myself, though, I can say that the campaign places a fair amount of emphasis on the story while experimenting with some unusual gameplay mechanics.

The story

The protagonists of this campaign are the elvish enchantress Niryone, and her apprentice Elynia. If you have played IftU or AtS, you are definitely familiarized with Elynia’s game-breaking abilities and power. You will not find any of that here. SoD is a distant prequel that takes place during her apprenticeship days circa 1081 YW, back when she was far even more useless younger and entirely ignorant of the sequence of events that would lead to Wesnoth’s political reorganization and changes echoing throughout all of the Great Continent. Thus, the real protagonist for most of SoD Episode I is her adoptive mother and mentor Niryone, whose existence was repeatedly alluded to throughout AtS.

The story is derived from Late History: Irdya before the Fall in the wiki (full of SPOILERS, in case it isn’t obvious), which I originally wrote back in 2008 (and revised some months ago) along with the rest of Future History in order to provide additional backstory for some IftU characters (e.g. Elynia, Argan) and events (e.g. the Fall). But what I wrote back then was not quite the story narrated by SoD; my text was essentially limited to an overall outline enumerating major events and characters in the broader context of Irdya. All characters and events in SoD are written according to vultraz’s own interpretation of the outline, with some input from 8680, Zerovirus, and me. In that regard, for characters other than Elynia’s younger self, I have only provided very rough characterization guidelines without going into details that could constrain the creative process too much. Elynia’s interpretation is purely vultraz’s, and so far I’d say he has nailed her character.

Without going into too much detail about the plot, I think that it features some unique ideas that I haven’t seen used a lot in any mainline campaigns — or IftU and AtS, for that matter. The great thing about the campaign is that it stands on its own as a product, and you don’t need to play any other campaigns to understand what’s going on. Of course, knowing some mainline lore always helps when it comes to identifying locations such as Wesnoth and Elensefar, but in the worst case you’ve got a massive map of the “mainline region” of the Great Continent in the game’s titlescreen.

The gameplay

To elaborate upon my previous statement about SoD’s design, resources throughout the campaign are rather limited, thus you won’t be building a massive army like those seen in Northern Rebirth or classic IftU — unless your intention is to repeatedly run into inconvenient negative budget situations. Au contraire, your focus should be on managing as few units as possible and utilizing the spells mechanic with your two leads. Disappointingly, this first release of the campaign only implements one (1) spell for Niryone, and a secret spell hidden somewhere decidedly secret. Your starting spell, however, should be quite useful to get your units out of sticky situations; in fact, it can be so useful, it borders on being a game-breaking mechanic, an issue which should hopefully be corrected in upcoming releases along with the overall lack of spells. On the plus side, this is better connected to the story than your typical Wesnoth UMC gameplay gimmick, as illustrated soon enough during the first few scenarios. The same can be said for the inventory mechanic; it is not particularly useful due to the current items shortage, but it does come into play for advancing the storyline at one point so far.

Perhaps more important than how often these features are used throughout the campaign in its current state, is the fact that the author has clearly put a lot of thought and effort into them. Both make use of custom Lua-based GUI2 dialogs, a Wesnoth engine feature that is very poorly documented and quite sadly underrated, even by the GUI2 developer himself. The UI design done for the sake of these two gameplay aspects alone makes the campaign fit seamlessly within Wesnoth’s framework, a courageous feat to behold and respect given GUI2’s status as an undermaintained and eternally moving target. That said, much like AtS’ (very sparse) usage of the GUI2 Lua bindings, it is quite probable that this kind of thing will break for users on display resolutions lower than the minimum supported by mainline, which is 800x480 absolute (not Retina) pixels. For now this isn’t a problem, since there are no unofficial ports of 1.11.x to mobile devices, and maybe by the point Wesnoth 1.12 is out everyone will be on devices with 8K full-HD or whatever. Yes, that’s a hyperbolic statement about 1.12’s unending development cycle, in case you could not tell.

Visuals, units, et cetera

Map design in SoD is generally good, portraying lush detailed environments from the Great Continent as it was during the mainline epoch, as opposed to the ruined wastelands seen so often in IftU or AtS. However, they are interspersed with underground scenarios, which may be somewhat of a letdown for those who dread dungeon crawling-style gameplay in the style of the aforementioned campaigns. To make up for it, SoD also features varied recruits and new enemy units to break the constant destroy-all-undead-and-kill-all-orcs cliché seen in so many, many other campaigns.

The art for the two protagonists was provided by some random nobody, who I have heard was basically forced by vultraz to make sprites within exceedingly restrictive schedules to the point that he or she had to sacrifice quality for the sake of getting a releasable product in time. I have also heard that this situation has become kind of a chronic issue for that person.

Some of the new unit art that features in later scenarios was provided by everyone’s favorite prolific pixel artist, Zerovirus. I am fairly sure Zerovirus fans will be able to spot his art as soon as it begins appearing on the game map, but it’s important to note that some of the art was actually created or edited by vultraz as well.

Other than these few points, there is not much else to talk about regarding SoD’s art development. Much like AtS, which was started and finished with a budget of exactly $0.00, portrait art for original characters is completely absent in this campaign. Nothing that can be helped in the short term, given that the author doesn’t work with portrait artists at this time, and seriously, good portrait artists generally don’t have much time to spare and would only be willing to contribute under commission, reasonably so.

To conclude

Shadows of Deception is a bold attempt by vultraz to develop a product that can join the shadowmcanon (IftU and AtS) while working as its own campaign without requiring the player to be familiarized with the rest. It is an early work in progress with only six scenarios complete out of 12 for the first episode, but it already shows a huge amount of dedication on part of the author in all areas that make up a good Wesnoth campaign: art, story, map design, you name it. Some of the new gameplay aspects introduced aren’t used as much as they should probably be to make them enticing to newcomers, but this situation may change as time passes and player feedback is provided. Because, you are obviously going to provide the author with that precious feedback while the add-on is being developed, right?

I think it is a promising campaign. I for one am eagerly looking forward to playing the rest, assuming it doesn’t get abandoned like the aforementioned case of TSL. That would make me sad. And nobody wants to see a sad shadowm.

As far as I know, no more fixes are required, which is good, for I do not expect any more AtS releases for a while.

I do not expect any more AtS releases for a while.

LIES LIES LIES LIES LIES LIES LIES LIES

NEVER doing this again.

The complete changelog for this version follows:

Version 0.9.7:
--------------
* Scenarios:
* E3S10 - Blood:
* Fixed an oversight in the implementation of the [hidden_unit] WML action
that could cause an event to destroy the player units forever by
clobbering them with enemy units at the start of the second stage.
* Units:
* Removed compatibility code introduced in version 0.9.4 to handle the
'fairy'->'faerie' race id transition done in that same release. Saved games
from 0.9.3 and older versions may not be used from now on.

Some people in the audience might have heard of a certain revamp taking place a little while ago in the multiplayer Era of Chaos add-on. In fact, this effort was originally started by artisticdude for AtS; he did the basic Demon units (Demon, Demon Grunt, Demon Warrior, Demon Zephyr), which received some touch-ups from me, and then I proceeded to redraw their cousins from scratch in record time. The differences compared to the old baseframes might seem jarring at first, but I can confirm that the original oversized sprites used in IftU and AtS all these years were merely an oversight and not something I actually did on purpose.

This release mostly revolves around graphic updates for the aforementioned unit type groups, compatibility fixes and improvements for the upcoming Wesnoth 1.11.6 (whenever it’s ready), and a catastrophic bug in Episode III scenario 6 (Divergence). Additionally, a unit type was renamed, breaking non-start-of-scenario saved games for the only scenario in which it appears; some unit type descriptions for the in-game help were rewritten, expanded upon, or added for the first time (“FIXME” never counted as a description), and a few unimportant inconsistencies were solved. Not listed in the changelog are a few minor dialogue additions to the last segment of Episode III scenario 10 (Blood).

For those who can afford the 7.32 MiB download, I strongly advise upgrading now instead of continuing to use older versions. Aside from the aforementioned renaming and the scenario it affects, nothing will break. Also note that this is the last version that will accept old saved games from version 0.9.3 and earlier. The faerie race renaming support code will be gone in version 0.9.7.

Well, the cat’s out of the bag already. Not that I really intended to keep the plan under wraps for very long in the first place—perhaps I should have done that—but I already implied, and then confirmed that this is a thing that is taking place.

Invasion from the Unknown is being rewritten.

Those who have stuck around for long enough may know that IftU’s prose has been revised before by ESR (up to scenario 6 or maybe 9, my memory’s hazy on this one) and later by SouthernOracle (entire campaign). None of these efforts went deeper than the language layer, and even then there is still a lot left to be desired in that department. I have also repeatedly redesigned and rewritten scenario 4 (“Over the Sands”) from scratch over the years.

During the production of After the Storm I realized and learned many things about my past and current work. A sizable amount of AtS’ development consisted of deciding exactly how much of IftU works and how much does not, either in execution or essence. Even after I gave up on perfectionism for AtS, I could not help but think that making such an absurdly ambitious sequel to such a very, very poorly done campaign was an absolutely preposterous waste of time. And I still think that is the case, and there is nothing I can really do to remedy the situation for people who have already played IftU and who will always remember it as the chaotic mess of half-baked ideas and shallow characters it currently is.

But I believe I can do better for future players.

The thought of ‘remaking’ IftU had been in my mind for years, but I always knew I would never find the right person with the interest in taking up such a colossal and largely unrewarding task while ensuring the end result would be just as I envisioned it. But… I also thought I would never see After the Storm complete with its two planned episodes and the—originally intended to be a separate sequel—final episode wrapping it up for good. AtS’ completion—regardless of how bad or good the results are—gives me a certain confidence that I am able to see a project through, even if that may involve a few a lot of unexpected turns along the way.

While the few people who actually like the ‘classic’ IftU might be inclined to assume the campaign’s overall tone will change for the worse (AtSification, anyone?), I don’t intend that to be the case and that would actually break AtS itself as the experiment in style it is intended to be. I do intend to add some of the characterization that is entirely missing in the current product, but not to the point of boring anyone to death with it — well, anyone who would play Excruciatingly Frequent and Extensive Walls of Text: The Campaign anyway. At the same time, some backstory elements and plot will be revised to allow some things to make more sense than they do at the moment. Scenario 4 will be rewritten from scratch once again in an effort to make it less tedious and more coherent. One or two scenarios may be axed in order to help with balancing and pacing issues currently resulting from the campaign’s length. Mal Keshar will be replaced with a talking animal and Anlindë will be spared from scenario 13!

At the same time, the terrible codebase is being replaced with some more polished WML and Lua from AtS, and rewritten to take advantage of features that have only appeared in Wesnoth 1.9.x and 1.11.x — bear in mind that IftU was written in 2007 (Wesnoth 1.3.x) and most code has only been ported to run on newer versions within restrictive time constraints, without much regard for style or robustness.

All in all, I believe that this will allow me to keep some ideas fresh in my mind while continuing to exercise some skills for the benefit of both IftU and AtS. How long is this going to take? Less than AtS, certainlyhopefully, but far more than it took me to complete IftU in the first place. My workflow requires me to go through the scenario sequence in an orderly, linear fashion, and I am only at scenario 7 after commencing this endeavor only about two months ago; and of course, my time is constrained by some sprite artwork that needs to be done or redone for both campaigns.

⁂

Now, the question nobody asked and nobody with a fully-functional brain should ever care about: How is this affecting the development of a sequel to After the Storm?

Simply put, it isn’t.

To be more specific, I do not intend to start working on a sequel to AtS right away given the poor/nil reception it has had as of this writing. And even if it were my intention to work on it in the immediate future, there would be tons of work to be done for it that currently fall far beyond my skills in terms of game design and artwork. I really want to avoid repeating the same mistake I did with AtS and tie this sequel to a previous iteration of limited scope and impact. Instead, I want it to be able to stand on its own and attract people who have never/will never play IftU or AtS; and I have a few ideas to achieve that, but nothing concrete or affordable as of yet. Will it ever see the light of day? Only time will tell.

The main change for this release is the fix for a bug causing one of the elvish leaders in E1S3 to disappear forever at the beginning of a dialog event with Galas. In spite of the magnitude of the bug, this didn’t seem enough to warrant having a 0.9.5 release instead of 0.9.4.1, so I decided to go back and revise some art (including a minor palette tweak that didn’t land in 0.9.4 because insert generic reason here) and make tiny cosmetic code changes in a couple of scenarios.