On the morning of the 20th of January, my desktop decided to die for no obvious reason at all.

Unlike the Windows 10-based laptop that got bricked only about a couple of weeks before, Nanacore simply decided to get stuck in an eternal reboot loop switching back and forth between the updated BIOS (read: UEFI) and the backup BIOS (UEFI) images. The backup BIOS wouldn’t proceed any further than the POST splash screen because of a known compatibility issue with NVIDIA’s more recent cards (GeForce 9XX and above I believe), which is the very reason why I had to update the main BIOS last year when I replaced my old potato card. I spent about two hours removing the GPU, storage devices, and memory modules trying to rule out any potentially faulty peripherals, to no avail. Once the GPU was out of the way, the backup BIOS (UEFI) would attempt to display an error message explaining why it had kicked in, but the attempt would make it immediately crash and reboot — hence I decided “eternal” was an appropriate qualifier for the situation. I reconnected everything that there was to reconnect other than the main motherboard power plug, which was more or less glued to it. I figured trying to pry it off with more force would risk breaking the board, and it looked completely fine to me anyway. There weren’t any burn marks, bent or popped capacitors, or any other visible signs of physical damage whatsoever.

So that’s one chapter of my computing life that has now come to an abrupt and tragic end at the beginning of what’s already proving to be a quite difficult year for me, for reasons I will not discuss here.

R.I.P. Nanacore (October 25th 2012–January 20th 2017)

Suffice to say, I had to spend approximately one week with Reicore, who... isn’t really in the best shape anymore, with some keys falling off, heat issues, and insufficient processing power for pretty much any software or website written in the past 5 years. At least I was pleasantly surprised by the fact that its old Intel GM45 graphics processor can somehow drive two 1920x1080 screens without dying — one on HDMI and the other on VGA, though, because the laptop doesn’t have any other display connectors.

Fortunately, I got someone to help me cover the full costs of purchasing a new desktop, and I was also able to keep my old GPU and disk drives. This latter point leads me to suspect that it wasn’t the PSU failing (thankfully) but rather the motherboard and/or CPU dying from old age. Seeing as how this has been an extremely hot summer so far, and I had been dealing with computer cooling issues all throughout the second half of 2016 because I couldn’t make up my mind about purchasing a new case and CPU+motherboard combo, it was all a foregone conclusion. There is a lesson to be learned from this debacle, I am fairly sure.

hanacorehttps://t.co/AgU2dfFAVK pic.twitter.com/CkwKorfWXN

— Iris Morelle (@shikadiqueen) January 28, 2017

I had been contemplating building Hanacore (“flower”, following the Japanese-based naming convention I adopted for Reicore onwards) around October last year, but I postponed making a decision until Q2 2017. The reason for this is that I expected Intel’s Kaby Lake desktop processors to begin shipping worldwide around that time, based on what little I could remember from the Ivy Bridge release cycle. However, it turns out that Intel released them on January 3rd instead, so by the time Nana died, a few Intel Core i7-7700Ks were already in stock here at local retailers in Chile. Yep, only the super-expensive unlocked CPUs. For whatever reason, retailers here don’t seem to ever have the locked counterparts in stock for very long anymore, starting with the Haswell line-up. But whatever, it’s not my money I was about to spend, so I thought I might as well take a YOLO approach for once. The alternative would’ve been to spend months tweeting at less than 20 frames per second. Or spend my own money on a laptop that wouldn’t satisfy all my requirements.

In particular, ever since I switched to a dual-screen setup at the start of December last year, I don’t think I could ever go back to working on a single screen. Most laptops these days seem to have but a single HDMI port. Not to mention that mobile GPUs are obviously inferior to desktops — watching my hard-earned GTX 1060 gathering dirt on a shelf for months would have been devastating for my morale.

Anyway, long story short, I picked my new desktop from the store on the 28th, it’s been working well so far, and it’s great and this time I picked all components other than the CPU cooler by myself.

The motherboard is an MSI Z170A Gaming M7 — a Skylake chipset, which means it required a firmware update (done during assembly at the store) to be able to drive the Kaby Lake CPU. There weren’t any Kaby Lake motherboards available with onboard sound controllers that were known to work correctly on Linux, unfortunately, and from a quick glance at Wikipedia I couldn’t really find any relevant differences between the Z170 and Z270 other than increased PCI Express bandwidth for use by M.2 SSDs (which I don’t have) and Intel’s proprietary alternative (which I don’t intend to have either). But most importantly, I wanted to avoid the sound controller fiasco I had with Nana where its CA0132 controller never had proper Linux drivers published by Creative — only a very locked-down version for a Chromebook laptop with pin and DSP effect configurations that wouldn’t work correctly with anything else. With that out of the way, I am now able to use any speakers and headphones I want without worrying about them not being recognized or not getting amplified. I’m really looking forward to replacing my 10 years old speakers.

Other than a couple of isolated USB-related incidents that I couldn’t properly attribute to anything (and an apparent compatibility issue between a 3G modem driver and NVIDIA’s stack of all things) I’ve not had any problems with Debian stretch and Linux 4.9 thus far. I also managed to reinstall Windows 10 clean a couple of nights ago. The old 2 TB HDD now holds local backups which I intend to generate in a more frequent, automated basis (compared to my more-or-less bi-weekly external backups); the new 3 TB HDD holds my Linux home dir and Windows install, and the old SSD continues to hold the root filesystem and games and some parts of my user profile (~/.config, ~/.local, and ~/.wine).

By the way, I didn’t even need to reinstall anything at all with Debian — I just configured it to use a stock 4.9 kernel instead of the custom configuration I used for Nana. On the Windows side of things, there were some complications because of a thing I did two days before Nana died that rendered it unbootable, but once I got it sorted out, it would strangely boot just fine. I still decided to do a clean install just to safely purge all of Nana’s system-specific drivers (chipset, network, etc.) and start fresh with a larger partition on the new 3 TB drive — around 400 GB instead of 96 GB.

Things have been running so smoothly thus far, in fact, that the CPU averages 35 °C while idle in summer, whereas Nana would average around 46 °C (38 °C in winter). The case and cooler fans produce far less noise than Nana’s too, even under heavy workloads. That said, the comparison might be a little unfair — Nana’s CPU was cooled by a stock fan, and Hana’s is handled by an all-in-one water cooler. Note that I haven’t tried overclocking yet, and in all likelihood, never will.

So yeah. New hardware. Cool.

Oh, and Derpycore from the table above is the bricked Windows 10 (originally 8) laptop I alluded to at the beginning of this post. It was a Sony Vaio that belonged to someone else (who wasn’t using it) which I borrowed last year when I needed a mobile computing device, since Reicore hasn’t been fit for that purpose for about 4 years with its decayed battery and broken and glitchy keyboard and touchpad. After months of semi-regular use for Windows-specific tasks for which a VM wouldn’t suffice, one day last month it just decided to never power up again. No beeping, no blinking LEDs, nada. Kind of like Nanacore afterwards, it died in its sleep after a whole session without issues, the sole difference being that Derpy wouldn’t even try to wake up ever again. Just silent icy death. I figure that’s what i get for not giving it a more adequate name. I should probably make sure to give my next laptop a regal-sounding name so it will last me forever.

EDIT:

Blackcore died last year due to a capacitor malfunction when I was inspecting it for donating it to somebody else. Probably. I am not really sure what happened there, but after several attempts I at least managed to boot it up long enough to clone its (old-style PATA) hard disk and grab what little of value I could find in it. Afterwards it would power up with its fans at full speed and never reach POST. That makes three computer deaths in under 12 months.

Finally, Unnamed Desktop #1 was last spotted outside my house circa August last year in a really poor state, accumulating rust and moss, so I’m fairly positive it’s now legally dead. I feel its loss more than Nanacore, strangely enough. It’s probably because it was my first proper computer ever. Does it count as a fourth death? I’m not sure.

This is, well, super important, and follow this link quickly before it’s too late HURRY—

Nearly 11 years ago, I was checking out some of the free and open-source games included with the openSUSE distribution when I came across a fantasy turn-based strategy game called Wesnoth. I vaguely remember taking a quick look at it and dismissing it for some reason. It wasn’t until an OS update later the same year that I would actually give version 0.9.5 a proper try. Immediately upon doing so, I was enthralled by the game’s sheer quality and its surprisingly accessible gameplay.

During the first quarter of 2006, I started toying around with WML and the map editor, and put together three or four semi-playable campaigns rife with awful prose and flat characters just for fun. At the time, the possibility of publishing my content online for others to play it didn’t even cross my mind — and frankly, it’s for the best that it didn’t. Much later that year, though, I decided to join the forums and actively interact with the community. The next year I started to seriously think about giving back to this community, as a way of saying “thank you” to the countless people — developers, artists, musicians, translators, and players — who invested their time and energy into this project.

It would be a big understatement to say that joining the Wesnoth development team became a turning point for me, personally. But that is far from the only experience that changed my perception of open-source software and people in general. Looking back on it, making a campaign comprising 30-odd scenarios, all to give a rejected Elvish Shyde replacement sprite a practical purpose, was an incredibly ambitious idea and I probably wouldn’t have attempted anything like that a year later, and certainly not now. But it’s a thing I did, and a lot of people seemed to like the result despite the generous borrowing of elements from other campaigns — mostly mainline — so I decided to keep maintaining it, and even started to work on a sequel after a while.

That epic-length campaign was originally codenamed “Armageddon”, but for production purposes I went with a longer, albeit less sophisticated name: “Invasion from the Unknown”. I asked around for better name ideas, but nobody answered that call, so the name stuck. Its sequel was codenamed and later properly titled “After the Storm”.

IftU changed a lot during its early days. Scenarios were moved around, renamed, rewritten, and characters introduced or redesigned as I saw fit. In particular, working on AtS throughout 2008 and 2009 and preparing for a prospective addition of IftU to mainline brought in more profound changes to the story line, partly to accommodate some future plot points better. But I also began to view this campaign in a critical light. Various changes in my life helped exacerbate my negative opinion of IftU, and this eventually spilled over to AtS as well, resulting in approximately two years of creative block.

Finally, at some point mid-2011, I snapped out of that mindset and decided to embrace some of IftU’s less favorable qualities and complete AtS and its sequel — which eventually became AtS episode III — but I also decided to improve and rework what I could as soon as I had the chance. After releasing the completed AtS 0.9.0 in Q1 2013, my work on codename “Reconstruction” began. I was finally free to do as I wished with IftU, and make the campaign that I tried to make in 2007, except without the broken grammar, malapropisms, awkward dialogue structure, close-to-nonexistent characterization, and unmaintainable program code. What could possibly go wrong? Well, for starters, everything.

It’s pretty clear to anyone who’s been following Wesnoth up close that things aren’t what they used to be back in 2007. Interests and demographics have changed, and IftU and AtS have been hit hard by these trends. People these days are more interested in complete products than in actively participating in the development process. There is an overabundance of long campaigns and very little time to play them. Wesnoth’s audience overall is also shrinking and engaging less with content creators, which further compounds the problem and isn’t a huge motivation in general. And even though I wasn’t alone on it, maintaining core Wesnoth — especially during my tenure as Release Manager during 2015 — sucked up pretty much all of my time and energy, leaving me barely able to spend perhaps a couple of days a month on Reconstruction. But after coming across a person who actually valued IftU and AtS for what they are, I managed to focus again and eventually start releasing the Reconstruction release candidates throughout late Q4 2015. All that was supposed to culminate in a 2.0.0 release on December 24th, but a lot of unexpected things happened during December so I had to hold that plan off for a while. And now we’re here.

I’d like to think that my 2007 self (and especially my 2006 self) would have played the Reconstruction version of IftU right after finishing UtBS, and thoroughly enjoyed every single minute of it — even if he didn’t really have the experience needed to discern bad prose from acceptable prose, or code, for that matter. Maybe it’s not the best campaign ever, and maybe it fills a niche that no longer exists, but it’s a thing I made and I think that’s important in some intangible fashion. I created, therefore, I am. I don’t know.

Version 2.0.0 is by no means intended to be the final update to IftU, and I have a few ideas brewing for version 2.1.0 already. It probably won’t happen until AtS 0.10.0 is out, however, and that’s going to take me at least another month due to recent incidents beyond my control that have been keeping me from working on it. Yep, it keeps happening.

Version 2.0.0:
--------------
* Scenarios:
  * S21 - Innuendo:
    * Minor balancing changes.
  * 22A - Face of the Enemy:
    * Lift shroud prior to highlighting the exit gate during the boss fight.

* Units:
  * New unit type descriptions
    * Shaxthal Assault Drone, Minor Imp, Imp, Blood Imp, Gutwrencher Imp,
      Armageddon Imp, Skeleton Rider (taken from Liberty), Bone Knight.

I’d like to thank vultraz, nemaara, and pydsigner/pyndragon for their invaluable input, assistance, and moral support throughout Reconstruction’s development (especially the second half); Espreon, AI0867, and Alarantalara for maintaining the previous incarnation of IftU on my behalf while I was fully preoccupied with AtS development; Kitty, Loonycyborg, Mica, Mist, and Mythological, for helping with IftU during the Wesnoth 1.3.x and 1.5.x times; and my beloved companion who stuck beside me all these years and helped me through rough times and put up with me until his departure in February this year. This release is dedicated to all of you, and to the Wesnoth community as a whole.

Good luck, have fun, and trust your heart.

Version 1.99.2 (a.k.a. 2.0 Release Candidate 3) is out now!

The complete changelog for this version follows:

Version 1.99.2 (codename Reconstruction RC 3):
----------------------------------------------
* Scenarios:
  * Fixed boss AI engine breaking when AtS is not installed.
  * Changed the savegame prefix for both episodes to "IftU", dropping the
    episode number since it's effectively meaningless in practice.
  * S7 - Goliath:
    * Removed all healing glyphs.
  * S14 - Bye and Behold:
    * Added a bare-bones attack animation to the Explosive Arrows item
      (issue #17).

Version 1.99.1 (a.k.a. 2.0 Release Candidate 2) is out now!

This is a bug fix-only release which primarily addresses some of the bugs reported after RC 1 was published, so I don’t have much to say about it.

The complete changelog for this version follows:

Version 1.99.1 (codename Reconstruction RC 2):
----------------------------------------------
* Scenarios:
  * Removed redundant "(Bonus)" annotation for some objectives in S9, S11, and
    S16.
  * S2 - A Real Confrontation:
    * Fixed pre-captured elven villages not being counted for the scenario
      defeat condition.
  * S3 - Memories from the Depths:
    * Fixed Mal Keshar not speaking one of his lines.
  * S20 - The Heart:
    * Fixed alternate victory by defeating all enemy leaders never triggering
      without using cheats.
  * S21 - Innuendo:
    * Increased turn limit.
  * S23A - Into the Lair:
    * Added a somewhat more elaborate initial sound transition.
  * S23B - Until Death:
    * Fixed an oversight so that player recruits no longer require upkeep.

* Terrains:
  * Ported gate fix from AtS 0.9.1 meant to solve clipping issues for gates
    adjacent to (convex) stone wall corners.

* Units:
  * Door units now clear terrain beneath them on 'last breath' rather than
    'die' events, in order to ensure shroud is correctly cleared before
    scenario-specific event handlers are run.
  * Replaced Chaos Crossbowman and Arbalestier's sword attack with an axe to
    match the sprites.

Today, December 1st, IftU 1.99.0 (a.k.a. 2.0 RC 1) and AtS 0.9.16 have been released.

There is nothing noteworthy about AtS 0.9.16 whatsoever, but IftU 1.99.0 constitutes the first public codename Reconstruction release after several years of work. That is, not counting this year’s April 1st release (which apparently everyone simply assumed to be a hoax instead of actually downloading it from the trunk add-ons server).

I’m cutting this post short since — as should be painfully evident — I don’t really feel motivated to update this blog nowadays. Still, the announcement over at the Wesnoth forums has some more details about this first IftU 1.99.x/2.0 RC series release that are worth checking out if you are planning on installing or updating to this new version.

Version 0.9.14 is out.

Still nothing new at all.

The complete changelog for this version follows:

Version 0.9.14:
---------------
* General:
  * A work-in-progress version was uploaded to the add-ons server as 0.9.13 by
    mistake. In order to avoid confusion and ensure automated upgrades work
    correctly, the final release number is 0.9.14.

* Graphics:
  * New or updated terrain graphics: Dark Hive, Dark Hive Surface, Dark Hive
    Depths.
  * New attack icon for Elynia's staff.
  * New or improved unit animations: Elynia (E1/E2 defense, ranged attack).

* Language and i18n:
  * New translations: Japanese.

* Scenarios:
  * E3S7A - Dark Fire:
    * Fixed the Potion of Life being able to be picked up multiple times.

* Terrains:
  * Added Wall Moss terrain overlay.
  * Removed custom campfire terrain (phased out in 0.9.12).
  * Removed custom trash/remains terrains (phased out in 0.9.12).

* Units:
  * Added a new unit type for Mal Hekuba.
  * Added a new unit type for the E2S11 boss.

Version 0.9.11 is out.

Version 0.9.11:
---------------
* General:
  * Work around bug in Wesnoth 1.11.17 that could cause units to be deleted
    from the game by units moving during cutscenes.

Version 0.9.10 is out.

Due to circumstances, it has been quite a while, and honestly I lost track of what this release was supposed to have besides a thing that requires another thing from another campaign that has not been completed or released yet. So let’s talk about what AtS 0.9.10 actually has.

Firstly, the minimum Wesnoth version requirement now is 1.11.11.

That’s right. Previous versions (including 1.10.x) are no longer supported. Ever since I moved to 1.11.x following the release of AtS 0.9.0, maintaining support for previous versions (including buggy development releases) required a series of unwieldy kludges that made the code uglier and harder to maintain and were, for the most part, untested beyond the classic “does it compile?” test. With all those bits gone, it will be easier to improve and optimize some aspects of the campaign, as well as work on the thing that requires the other thing I alluded to above.

For now, the first one such aspect I have worked on is converting several units to the 1.11.x animation WML syntax. Although some other people seem to prefer the new syntax over everything, I have chosen a more pragmatic approach for this campaign, so the set of units that I’ve converted in this release is rather limited. Hopefully more will follow soon, but I’m certain that there are a few for which the change hurts code readability. Plus, since most of my units are headbutters, the code size gains are marginal in the average case.

Finally, somebody reported to me of an issue with the player’s recall list and gold being discarded during certain key scenario transitions. It turns out this resulted from a change in Wesnoth 1.11.13 purportedly intended as a bug fix for MP campaigns. I was aware of the change and its implications at the time 1.11.13 was released, but I wrongly assumed AtS would not be impacted because I failed to take a tiny detail into account. Exactly three months later, I realized the sheer gravity of my mistake — but fortunately, it seems nobody else played AtS on 1.11.13+ in the meantime. (Thanks to RainerT for the report. This would have gone unnoticed for who knows how many more years months otherwise.)

As you can see, there is not a lot to talk about in this release other than the version requirement change. Since it’ll be a while before Wesnoth 1.12.0 is released, and AtS remains largely the same as it was the last time I posted in this topic, I believe stable version purists won’t be missing out on anything for now — at least not until the thing is done.

Also due to circumstances, this release is largely untested, so I would not be surprised if I accidentally broke a thing or two since 0.9.9.

The complete changelog for this version follows:

Version 0.9.10:
---------------
* General:
  * Raised minimum game version requirement to 1.11.11. All existing
    compatibility code for previous versions has been removed.

* Graphics:
  * New or updated unit graphics: Sprite, Fire Faerie, Forest Spirit, Dryad,
    Demon Shapeshifter.

* Scenarios:
  * Added an option to certain scenarios to ensure Wesnoth does not discard
    the player's gold and recall list under certain circumstances due to a
    behavior change in version 1.11.13 and later. Affected scenarios:
    * E1S9.3 - The Triad, part 3
    * E1S11 - Return to Wesmere, part 2
    * E2S0 - Transience
    * E2S11 - A Final Confrontation
    * E3S0 - Opening (Within)
    * E3S6 - Divergence
    * E3S8B - Destiny, part 1
    * E3S11 - After the Storm

* Units:
  * Balancing changes:
    * Changed Leech's alignment from 'lawful' to 'neutral'.
    * Decreased Leech's HP from 62 to 42.
    * Decreased Leech's melee damage from 11-2 to 9-2.
    * Decreased Leech's unit level from 3 to 1.
  * Converted to the simplified 1.12 animation syntax:
    * Dusk Faerie, Night Nymph, Nightshade Fire
    * Sylvan Warden
    * Sprite, Fire Faerie, Dryad, Forest Spirit
    * Elvish Wayfarer
    * Faerie Avatar
    * Demoness Hellbent Tide
    * Verlissh Control Spire

* User interface:
  * Cutscene themes now use the 1.11.10 [theme] id attribute on 1.11.10 and
    later.

Those who have followed me these last five years or so are probably aware that I designed and coded this site’s layout on my own in an effort to learn the basics of Web design. Thus, shadowm.rewound.net has been redesigned no less than eight times since its inception.

Dorset6, the last iteration prior to this day, was first deployed on May 11th, 2011. Since then, it has only received minor incremental updates addressing bugs and minor practical concerns that cropped up later, since I found the overall design to be pleasing to the eyes — at least until I got a new screen where the lighter blue colors turn out to be purpler than intended, oops!

The last maintenance update to Dorset6 was Delta 24, deployed on April 26 2014.

The underlying template engine, Poison Ivy, has not seen any architectural changes all these years since it was first deployed in 2010. In the meantime, however, I have learned more about API design from my experience with various other projects. It can be very disheartening to look back on past practices and realize you were doing things completely wrong in production software!

During this time I have also heard all the hype surrounding HTML5 and CSS3, and got to experience the results firsthand as large websites started making use of the new technologies. On top of that, support for Internet Explorer 6 is finally dying off, and Windows XP just reached its definitive end of life last month; software and Web developers everywhere rejoice as they no longer have to give support to grossly obsolete products from the early 2000s.

I have actually made use of CSS3 and forward features in shadowm.rewound.net since Dorset6, but right after deployment I decided to aim for leveraging more of their potential in the next iteration, Dorset 7. I promptly begun throwing around style and layout ideas. However...

Continue reading “Iris”

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.

When more than one add-on fails to load, though, the results can be even messier.

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!

― ##shadowm, 2014-02-04