Some time ago, I rewrote most of the PreprocessorRef article in the Wesnoth.org wiki to make syntax and examples clearer, but it seems I missed something.
The << and >> ASCII angular quotes are actually part of the general WML preprocessor syntax, not the [lua] tag in particular. They were introduced for version 1.7.0 in r34037 and r34038 as quotes denoting a verbatim (i.e. not preprocessed) string. The committer’s intention was obviously to allow for more convenient inlining of Lua code in WML document, but that is not the only possible use for this feature.
I had worked this whole time under the impression that the [lua] tag was somehow magical and special to the WML preprocessor, when in reality, it is not. The only thing that is special about it is that most people use the << foobar >> syntax in order to avoid clashes with tokens that the WML preprocessor recognizes as directives, such as curly braces {} (the file/macro substitution directive), but that is merely a convention, not a requirement — unless you do have such conflicting tokens within your string literal, of course.
Incidentally, I only figured this out when deploying a special AI engine for certain AtS E3 scenarios a few days ago:
In this snippet, the _TARGET_LIST argument needs to be substituted with a valid Lua table. However, for that one would have to use curly braces like this:
{AI_BOSS_TARGETING_ENGINE {"Hero 1","Hero 2"}}
That will not work, of course, since the preprocessor will see that as an attempt to include a file or macro named "Hero 1","Hero 2". The correct syntax is:
{AI_BOSS_TARGETING_ENGINE <<{"Hero 1","Hero 2"}>>
Now I just need to get around to documenting this thing some day, and figure out how it interacts with translatable strings and textdomains.
Episode III (Final) is now complete in this version, sans the final Epilogue scenario (which will eventually become a bonus feature) that is not part of the scenario count for various reasons that will become evident once 0.9.0 is released.
Some important caveats:
All scenarios after E3S6 (Divergence) were developed and tested on Wesnoth 1.10.x only, so if you are playing on 1.11.1 and you experience any issues, please report them on the forum topic.
Some code in later scenarios seems to be somewhat CPU intensive, performing significantly worse on my dual-core 2.1 GHz laptop than on my quad-core + HT 3.4 GHz desktop.
If you will play the last scenarios of Episode III with music, you must make sure you have upgraded the AtS Music add-on to version 0.2.0 first! This version was published on the add-ons server in advance a few days ago to give people time to upgrade in preparation for version 0.8.90 of the campaign proper
Official support for Wesnoth versions 1.9.10 through 1.9.14 has been dropped in this version. In theory, Wesnoth 1.9.14 should work just fine, but there are several minor bugs that were addressed later during the 1.10.x stable series that may affect this campaign.
Special thanks go to vultraz for playtesting this beast starting from E3S6 in less than a day (around 14 hours with breaks), and the other two playtesters (you know who you are!) who reported some glaring issues with E3S6 and E3S7A.1, which were addressed after the Big Merge and before the packaging of this release.
I will save the longer announcement (including plans for the future) for later, when the final Epilogue is done and 0.9.0 is released.
The changelog for this version follows:
Version 0.8.90 a.k.a. "0.9.0 minus one":
----------------------------------------
* General:
* Dropped remaining compatibility code for Wesnoth 1.9.14 and earlier.
* Scenarios:
* E1S11.2 - Return to Wesmere, part 2:
* Removed compatibility code for Wesnoth 1.9.5 through 1.9.8.
* Completed Episode III (sans Epilogue).
* Units:
* Balancing:
* Increased Elynia's resistance to impact damage from -10% to 0%.
* Decreased Demon Shapeshifter's ranged attack from 8-2 to 7-2.
This very specific issue is why After the Storm 0.8.90 isn’t published yet. vultraz completed his playtesting within less than 24 hours after the Big Merge, and various critical fixes have already landed in trunk.
The first After the Storm commit to Wesnoth-UMC-Dev’s trunk happened on May 17th, year 2008.
Today, February 19th 2013, after years and years of development, with various real life and non-real life issues getting in the way and dooming the campaign to Development Hell until version 0.4.0 with a completed Episode I finally happened on October 16th 2011, I can say for certain that...
After the Storm is finally complete.
With the Big Merge done and all the Episode III post-Divergence content (sans the Epilogue scenario) finally landed in Wesnoth-UMC-Dev trunk, the next step is releasing AtS version 0.8.90 to the public.
r17177 | AtS: bump version from 0.8.5+svn to 0.8.90-svn in the changelog after the Big Merge
r17176 | AtS: [Big Merge] workaround issues with the test suite and macros from data/core/units.cfg
r17175 | AtS E3: [Big Merge] land post-Divergence maps and scenarios
r17174 | AtS E3: [Big Merge] land post-Divergence ancillary macros, story text, character macros, and death handlers
r17173 | AtS: [Big Merge] land post-Divergence units WML, baseframes, halos, and animations
r17172 | AtS: [Big Merge] merge macros used for post-Convergence content
r17171 | AtS: [Big Merge] remove conditional loading of finale-stage scenarios and units
r17170 | AtS: bump version from 0.8.5+svn to 0.8.90-svn before the Big Merge
r17169 | AtS E3S6: enable scenario in regular gameplay
There will be a delay between this and the actual public 0.8.90 release while my primary playtester (vultraz) does the playtesting thing with the scenarios. Some balancing changes before 0.8.90 may also be necessary.
In the meantime, people can check out After the Storm from Wesnoth-UMC-Dev trunk using the Subversion client of their choice, and provide me with feedback via forum PM (in particular, about any possible bugs or balance issues that might plague some specific scenarios), or private messaging on IRC — I am on irc.freenode.net, channel ##shadowm most of the time, but I would rather avoid people dropping spoilers in the presence of my aforementioned playtester, who also hangs around there.
UPDATE: Since I haven’t gotten around to publish version 0.2.0 of the AtS Music add-on, you will also need to obtain the latest version from SVN separately, since it introduces a few music tracks used in the new AtS Episode III scenarios. Of course, this is only necessary if you want/need to have in-game background music.
UPDATE 2: AtS Music version 0.2.0 is now in the 1.10 and 1.11.x add-ons servers. The previous version was 12.3 MiB in size, whereas the new version is 22.7 MiB. I actually had to do some re-encoding to bring it down from 33.1 MiB, but there shouldn’t be any noticeable compression artifact build-up — or at least, I cannot perceive any with my headphones on.
svn co https://wesnoth-umc-dev.svn.sourceforge.net/svnroot/wesnoth-umc-dev/trunk/After_the_Storm
svn co https://wesnoth-umc-dev.svn.sourceforge.net/svnroot/wesnoth-umc-dev/trunk/AtS_Music
You can also grab tarballs of the latest trunk snapshots through SourceForge.net’s SVN web interface:
This last alternative is probably not the best, though, since you will not be able to track future updates. Subversion makes it far easier to update every time a changeset is committed, without having to download the whole thing every time.
I am not going to provide any further instructions for installing using either of these methods, so I’m leaving this to people who actually know their way around Subversion tools or manually installing add-on content. I am not going to post any spoilers either; in particular, I am not going to reveal the Epilogue sequence until version 0.9.0.
Special thanks go to Espreon, Gambit, and vultraz for making all of this possible in their own ways. I will probably explain the deal with AtS’ troubled development in a new post in the near future (probably after 0.8.90 is properly published).
Thanks to all those who waited this long for this to happen. For those who are eager to playtest this and don’t know their way around the aforementioned things, I can only promise that the wait for 0.8.90 will be much shorter. A couple of weeks, tops.
Finally, the usual disclaimer applies: this campaign is not for everyone.
Well, here is another teaser in the form of a more concrete roadmap for AtS 0.9.0’s development:
Development diverged around the release of version 0.8.3 resulting in only bug-fixes and minor features landing in Wesnoth-UMC.-Dev trunk, which is where AtS’ releases come from. During all this time, I have been (mostly) silently working on the final set of scenarios (E3S7A onwards) in a separate ‘branch’ of sorts, with occasional code and other assets landing in trunk to ease the upcoming Big Merge work that will take place “soon”.
And by “soon”, this time I really mean it.
This development model may have given some people the impression that I stopped working on AtS altogether, but this was never the case. IftU and AtS have historically been solo projects, and I have dedicated a lot of time to programming, creating original artwork, and writing prose for both campaigns. AtS has been a more demanding energy sink because of the different standards compared to IftU, and Episode III has been even more demanding than Episode II was in every possible sense.
However, it is finally starting to pay off as I’m about to complete the last scenario of the sequence referred to in the chart above as Finale C, which is pretty much the end of the After the Storm proper. Once that is done, I will go back to some of the previous unreleased scenarios to deal with various rough edges in programming, balancing, and prose, and then perform the Big Merge on trunk, leading to the 0.8.90 release (also known as 0.9.0 Release Candidate 1). Whether this release will be public or just limited to whoever expresses interest in playtesting it is something I have yet to decide.
Since at this point all the artwork for Finale C is done and most of the programming components in place, I expect the Big Merge to take place around the end of the month. No promises on when 0.8.90 will be announced, though, nor to whom it will be announced.
After that I’m facing the challenge of writing the combined epilogue for both campaigns, which is a whole different can of worms because of some architectural restrictions in Wesnoth’s design that I need to overcome, somehow. While I am already know how the epilogue flows in advance, making it not look like shit could well be an unprecedented feat.
Once the epilogue is done, After the Storm 0.9.0 will be released. Theoretically, this should not take too long, but we shall see.
To recap, I am literally one scenario away from the epilogue, and this campaign is definitely not abandoned.
Also, if there are any campaign authors out there making assumptions about the AtS E3 plot progression, you should probably be prepared to either revise them or stick to your own alternate-universe continuity theories or whatever floats your boat.
Because of a situation with the Debian Iceweasel maintainers’ packages for the current release (18) on Testing (wheezy), I decided I could as well take this opportunity to try to install upstream Firefox in the cleanest fashion possible.
I have actually run upstream Firefox on Debian GNU/Linux (even Nightly, or Minefield back when it was called that) in the past on multiple occasions, facing various awkward desktop integration issues along the way. Additionally, the Firefox binaries had to reside deep within my home directory, which seemed a little tacky. But I just found out that this does not necessarily have to be the case.
While searching for information about installing the original-brand Firefox on Debian, I came across this forum topic and quickly worked out my way from the instructions presented there. I think I’m missing the OP’s context for the switch (Iceweasel 3.5 on squeeze maybe?), but that is not terribly important now, three years after the fact.
There are alternative guides floating around which advise adding foreign distribution repositories to your APT sources. Needless to say, this is a really bad idea unless you are very sure of what you are doing. (Hint: You are not.)
Many of the following instructions are pretty much the same as in the forum post, just adapted to account for some minor changes over time, as well as some personal preferences. I also find my version of this guide much more palatable in presentational terms. Additionally, I am particularly adamant about not changing anything in /usr for this procedure, preferring /usr/local instead in order to avoid package conflicts in the future.
Note: the physical dimensions might be wrong, as usual. The above yields a diagonal of ∼590 mm, whereas the monitor’s specifications state it should be 584 mm, or 23″ (584.2 mm).
