The idea of continuing and developing the Invasion from the Unknown storyline further was in my mind from the beginning, and I apparently started to work on a sequel on May 2008, if the Wesnoth-UMC-Dev registry is anything to go by.
After the Storm’s development has been repeatedly impacted and put at risk by various “real life” issues.
Earlier this year, I decided to go back to work on the campaign after a long hiatus — so long I don’t remember how long anymore — but my attempt ultimately failed anyway. I promised a delivery, but the delivery did not happen.
Until I rediscovered the fun in video games. Then, magic ensued.
I said I would try to finish the first episode of the campaign before December. I am glad to say that mission has just been accomplished. After the Storm 0.5.0 is out in the Wesnoth 1.9.x add-ons server, with the first episode (that’s 13 scenarios) complete!
For those who’d rather read a terse piece of text with no emotive speech in it, the changelog for this version follows:
Version 0.5.0:
--------------
* Scenarios:
* 09 - The Triad (part 3):
* Fixed problems with the final cutscene on Wesnoth 1.9.8 and earlier.
* 11 - Return to Wesmere (part 2):
* New scenario.
* Completed episode I.
* Units:
* Removed Skirmisher ability from Elynia.
* Spawners have a small chance of deactivating themselves after spawning a
unit.
I have tried to make sure AtS remains playable on Wesnoth 1.9.8, but my primary development target is still 1.9.9 and support for 1.9.5, 1.9.6 and 1.9.7 is mainly theoretical at the moment. If you encounter any “Invalid WML errors” or such, and you are using Wesnoth 1.9.7 or earlier, try with Wesnoth 1.9.8 or 1.9.9 instead if you can, and give me some feedback in the forum thread so I can address any such issues as soon as I may.
I take this opportunity to remind you that you can also find and follow me on Twitter as @irydacea or join my personal channel ##shadowm in the freenode IRC network.
When I prepared the final draft of the October 2010 revision of the Wesnoth.org Forums Posting Guidelines, I deliberately skipped clarifying a specific point regarding posting rate conducts, more specifically, point 1f, in order to see what the community would make out of it.
That’s not to say I didn’t alter it in any way whatsoever since the previous revision, which was basically a left-over of Turuk’s administration:
Before:
Think and Read.
Read the entire thread before you post. And when you post, explain your reasons. Nonsense may be deleted without warning, especially in a working topic. Posting the same thing after it has been deleted will get you a warning. Doing it again will get you a ban.
No Spamming.
Post a single idea/question/comment in only one forum. Do not double post, edit your previous post if you have something new to add but no one has posted yet.
After:
No spamming — think and read
Post a single idea/question/comment in only one forum. Do not double post, and instead edit your previous post if you have something new to add and no one has posted yet. Technical support requests may be bumped after a while in case they have been forgotten and sink past the first forum view page. Read the entire thread before replying to it. Nonsense may be deleted without warning, especially in a working topic.
I introduced the support requests bit with the intention of giving users in the support forums (Technical Support, Release Announcements, Compiling & Installation; WML Workshop, Coder’s Corner, Lua Labs, Scenario & Campaign Development) special protection as bumping topics in there is usually a legitimate and reasonable course of action. But in reality, there are other cases where bumping by means of double-posting should be allowed. Those are not described or explained in the Guidelines because I felt that elaborating on a specific point would derail the whole post.
One of those cases applies to campaign development topics, where the OP may post the announcement for a new version of the campaign and only a few hours later find himself or herself in need of another announcement because of a quick update fixing some important bug.
Another case, more technical than practical, is the maximum number of attachments per post, which exists to discourage and limit senseless spamming of unwanted content by automated and non-automated agents, and encourage use of compressed containers like tarballs, zip files and rar archives to keep our overall disk usage relatively low. Users exceeding the attachment limit will need to continue posting their content in consecutive posts.
Generally speaking, users reporting double/multiple posting according to section 5 of the Guidelines have enough common sense to understandhat sometimes exceptions need to be granted and that this is one of the reasons we don’t call them the “Forum Rules”. Rent-a-modders occasionally lack this common sense, however, and they make their intentions evident through this mechanism. I imagine one can never be too anvilicious while reminding them what this entails.
Thanks to a Wesnoth user (you know who you are!) who bought an order of the Humble Indie Bundle #3 for me last Tuesday, I finally had the chance to try the popular in-development Minecraft, thanks to the included trial that lasts until this Sunday 14th.
Today, after Wesnoth-UMC-Dev reached its most important milestone, I have decided to step down from the project administrator position to leave the decision making and user support tasks to Espreon and AI0867, who have done an undeniably good job in my absence the last year while I was busy working on other projects.
This does not mean that I’m completely breaking my ties with this exciting platform for add-on development which ESR and I founded. I’ll continue to take care of infrastructure matters such as the website design, content and coding, the Registry tools and miscellaneous utilities whenever I have time; I’m not going to abandon After the Storm either, since I continue to be a user of the project either way.
I mentioned that I’d be following up the official r10000 announcement with the history of the Wesnoth-UMC-Dev Project. Most of the content below is taken from an interview I recently had with BfWEthnographer which eventually touched this subject.
The Coordinated Wesnoth User Made Content Development Project, better known as Wesnoth-UMC-Dev, has today reached SVN revision 10,000. Here’s the official announcement.
I’ll soon post details about the project’s history here.
While searching for examples of translated generic unit names from data/core/macros/names.cfg in Wesnoth (much to my disappointment, the Japanese translation uses the source strings verbatim for this), I discovered an oddly familiar name amongst the female Elvish names for the markovian generator.
Anylindë.
Back in 2007/2008, I was pretty much forced by Syntax_Error to change the name of one of the main characters in Invasion from the Unknown. Why? Because her name was Analia — never mind that female human units named “Bra” occur quite often in the game thanks to the RNG’s influence over the name generation algorithm.
So I consulted ESR, who came up with Anlindë as a possible replacement. I never noticed before that it was just one letter away from being a generic unit name. Then again, Galas and Elynia were my own design choice and they are, indeed, part of the name generator sources — I had gotten so frustrated at the design phase that I took a random generic name for Galas and the first feminine-sounding name starting with ‘E’ for Elynia.
Furthermore, I also took Analia from names.cfg and it’s still there. No overzealous purists have complained so far.
Would IftU have been a better campaign if I had used custom names for these three characters? Maybe, by a marginal difference. On the other hand, the one time a recruited elf with the name Elynia appeared during gameplay (that one Sprite I got in IftU doesn’t count), I protected her until the end the second-to-last scenario of HttT — by then she was a veteran Elvish Shyde.
Today, May 26th, a few minutes past 06:00 AM UTC, after 6 or 7 years of history, the Wesnoth.org favicon has finally been replaced by command of the Art Director on the live website and in SVN trunk, revision 49655, meaning this change is also effective in mainline starting with version 1.9.7 (not yet released).
The differences between both versions are far from subtle, as you can see to the right.
I for one mourn the loss of this significant piece of history that reflects an older, more cartoony art style that was slowly abandoned towards Wesnoth 1.0 and beyond. Until now, this icon also accompanied the owned village counter in the game’s top bar, and served as an indicator overlay for moves affecting village ownership since version 1.4 onwards. Finally, it served for a long time as the village terrain category icon in the Map Editor.
In case anyone requires the old icon for the sake of nostalgia, it’ll be preserved here for your own use under the conditions of the GNU General Public License version 2.
Whatever rules Mozilla Firefox follows to determine the user’s default email client don’t seem to work properly on Debian, at least not when GNOME is not the desktop environment originally installed. For whatever reason, what Firefox tries to do with mailto links and the Send Link context menu option is to open the Evolution mail client, which is not installed with the KDE or LXDE desktop environments.
Fixing this is supposed to be trivial, and it is, but the relevant option is hidden in the worst possible place in Preferences.
Chromium/Google Chrome does not have a user-accessible setting for this, but somehow still appears to get the right idea from the desktop environment.
If you are running Google Chrome 11 or Firefox 4 or later and you know how to find your way through a Unix console OS, here’s something you might want to check out: it’s a Javascript PC emulator running a custom (patched) build of the Linux kernel 2.6.20. Directly. On. Your browser. With Javascript.
Sooner than expected, I was notified that Bluecore had been repaired and was awaiting to be retrieved in the support center. Thanks to my never-ending laziness, however, the retrieval did not take place until yesterday.
The verdict was that the screen had to be replaced.
A big problem with this is that I still see the same gray stains beneath the screen’s outer layer that were there back in February the last time I used Bluecore, around the top left corner of the panel, which brings up the question, what did they mean by “screen”?
Whoever did the repairs or testing managed to boot and properly shutdown Linux several times, so my logs indicate that the first successful boot (resuming from hibernation) took place around 15:30 UTC-04:00 (+DST) on April 28th. I’m glad that they figured out how to turn it off from the KDE display manager instead of resorting to wild button pushing.
Since the repairs were effected under an “extended warranty” plan from the store at which Bluecore was purchased, the only mission of the tech support people was to make Bluecore boot again, so everything else (fan, keyboard, etc.) is still in the same crappy conditions, except for the touchpad buttons — oddly enough, the right button is no longer hyper-sensitive to touch and works correctly.
I’d love to know exactly how a screen replacement fixed the laptop or whether it is really possible and valid to replace all display components bar the outer transparent material layers with the aforementioned stains.
