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.
After a record break of 6 months I got back to work on scenario 9 of After the Storm and completed it, in a fairly different fashion than I originally planed. Still, it’s another step towards completion of Episode I. Version 0.4.0 is available for download now in the 1.9.x add-ons server and SourceForge.net.
I think I have avoided to spread many spoilers about AtS’ plot since day zero; there were, of course, some early storyboards circulating around the forums and IRC at the beginning, but as I’ve been saying for quite a while, they are no longer canon and I am departing from the original plan on purpose.
I am fully aware that some people will not like my choices in 0.4.0, and they may even seem blasphemous, but the truth is I scattered enough foreshadowing everywhere to prepare them for the time being. What are these choices I speak of, anyway? Too bad, you’ll have to play the campaign to find out!
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.
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.
Bluecore is now officially dead, and only a miracle could bring it back to a usable state. During the next week I’ll be taking it to technical support, so the current condition will hopefully be temporary.
Some days ago, I came up with a joke in ##shadowm regarding a hypothetical “Reicore” laptop, which would have some awesome NVIDIA GPU and a quad-core processor. This is most likely not going to happen, yet I have reused the computer name on my new, temporary laptop, which used to belong to my father and was, in fact, bought exclusively for his use during 2010.
1. Describing Reicore
Reicore is a fairly decent HP Pavilion dv4-1624la with 4 GiB of RAM (like Bluecore after an upgrade), 500 GB hard disk (as opposed to 250 GB) and an Intel Pentium T4300 dual core processor, which supports the AMD64/Intel64 instruction set — in fact, it came with Windows 7 Home Premium x64 preinstalled. Since its CPU is optimized for mobile usage, it doesn’t have some newer-generation assets like the Intel VT-x technology, which is essential for full-fledged hardware virtualization with KVM or VirtualBox. This is a major loss for me, since I doubt I’ll be able to achieve the same performance with Windows XP SP3 on a VM on Bluecore here.
(My Windows XP SP3 VM had been used for production purposes twice, during the development of Wesnoth RCX 0.1.x.)
This laptop has an integrated graphics controller from Intel’s Mobile 4 line-up as well, which is nonetheless decent enough for running software like Frogatto along with a composited window manager, in this case Kwin from KDE SC 4.4.
The LED-based display panel leaves much to desire though, as I can clearly see the LED grid beneath the screen when it’s active, no matter what colors are being visualized.
2. Choosing and preparing a Linux distribution for installing
The operating system I chose to install was Debian GNU/Linux 6.0 a.k.a. Squeeze, using a DVD snapshot of the Testing distribution from December 2010, which I later upgraded to current Stable. I had downloaded that snapshot of the amd64 builds along with a 32-bit x86 one I used on Blackcore for the sake of having a backup Linux system. The amd64 DVD image had seen no use until the night after Bluecore’s death, during which I rescued it from my awesome external 2 TB hard disk, as part of the last backup tree made from Bluecore’s Linux installation.
This decision makes Reicore the fourth machine on which I have installed Debian. Funnily enough, in all four cases I have not had a Stable snapshot handy, and have had to use Testing instead.
The actual preparation of the physical disc for installing Debian involved a lengthy and complicated operation involving Blackcore, Greycore, the backup hard disk (“multi”) and a 16 GiB USB pendrive (“UTIL_Q”).
Greycore has been running Debian Lenny (oldstable) since the last time I used it around the first week of January 2009, and thus has no Ext4 support.
The Squeeze DVD image was stored both on Bluecore (inaccessible) and the backup HDD, the latter consisting of a single Ext4 partition.
Blackcore runs Windows XP SP2 and Debian Squeeze, so it does have Ext4 support. The DVD drive, however, turned out to be defective and cannot burn DVDs.
Greycore, despite being in a miserable state, still has a functional Linux system and a DVD drive.
After juggling a 4.4 GiB ISO 9660 image around between the external hard disk, the USB pendrive and Greycore, I was ready to install a Linux OS on Reicore, deliberately wiping out Windows 7 in the process for a change.
3. Installing Debian
Installing Debian on Reicore turned out to be a quite satisfying experience compared to those I had on Bluecore (testing Lenny 2008-11) and Blackcore (testing Squeeze 2010-12). Unlike the initially Lenny-based laptop’s case, there were no hardware compatibility issues against the installer kernel; and unlike the desktop machine’s case, there is full availability of highly functional, free drivers for Reicore’s hardware in the first DVD of the distribution, without the need of installing optional firmware packages.
After finishing Debian’s installation I was greeted by a shiny Intel graphics driver with KMS and 3D graphics support, and a clean KDE SC 4.4 desktop. From this state I upgraded to the current Stable distribution.
4. Restoring from backups
Due to my painfully lazy nature, I didn’t make daily backup snapshots of Bluecore while it was still working. In my defense, I could say that transferring nearly 220 GiB of data through USB 2.0 is a royal pain in the ass!
shadowm@reicore:~$ stat /media/multi/bu/daily.0/ | fgrep Modify
Modify: 2011-01-19 18:51:34.000000000 -0300
The real losses since then aren’t very important, since all my projects are hosted in distributed repositories using Mercurial or Git, as I foresaw the possibility of theft or damage to the laptop. The only tree with local modifications that I didn’t push upstream in time is “rei2-rei2”, corresponding to a series of Rei 2 IRC bot scripts used by the official Rei2 instance administrating the ##shadowm IRC channel on freenode.
Other losses include configuration changes, local IMAP caches, unimportant downloads and various VM state changes, including a Windows Vista VM I set up around one week ago.
The configuration changes aren’t that important either, since although I have a full snapshot with all my configuration from Bluecore at that time, I decided to start fresh on purpose. This has unveiled some performance issues I initially attributed to Debian Squeeze’s architecture — they might have been in fact caused by the carry-over of configuration from the days of Lenny as a testing distribution on Bluecore. A rough estimate indicates that Bluecore would take around 2 minutes to boot into the KDE login screen, while Reicore takes around 30 seconds.
Last night, after shutting down bluecore and leaving it alone for hours, the BIOS boot stage failed and I had to turn it off and try again. Today that’s not the case, and bluecore won’t boot.
I do not understand why is this, or what could be the cause, since in both opportunities the laptop went through a successful hibernation cycle from Linux. There doesn’t seem to be any relation to the AC adapter or battery status, since I tried turning it on with different power source combinations. The GPU and display screen don’t come up, and the keyboard doesn’t work — the only visible indication of (in)activity is the two blinking Caps Lock and Num Lock LEDs, which I saw before when Linux wouldn’t resume from suspend-to-RAM properly back in the 2.6.26 days, two years ago.
This means that my files, configuration and software are currently inaccessible and unusable, save for a ~2 weeks old complete system backup on my 2 TiB external hard disk, which I could use with the machine I’m using right now, blackcore. There are various problems with this desktop computer, however, that make it barely usable with Linux. In particular, GL applications crash X.org thanks to VIA’s nearly nonexistent IGP support, and there’s nearly no means of 2D acceleration.
The current plan is to take bluecore to the technical support people. Hopefully they’ll prove their worth in money this time.
I have been thinking about some stuff to do during this year for a while, actually. It’s really hard to decide because I’m a person who runs into all sort of trouble while trying to get projects accomplished (including procrastination).
One thing I’m already doing is learning some Japanese, for no particular reason at all — although you’ve got to admit that having multiple languages in your curriculum is worth a bunch of coolness points. 😛 Espreon is helping me along the way with his own recently gained knowledge. It seems quite fun to learn a language in a non-Latin alphabet, if not a tad overwhelming at times, especially with kanji.
It’d be a good idea to lose some weight this year, too. My addiction to sugary stuff isn’t quite compatible with my heart condition! (Nor is coffee, but… meh.)
Then there’s Wesnoth. I intend to finish the Second Act™ of After the Storm Episode I as soon as I may, even through the means of placeholders — I’m willing to do anything to rescue AtS out of Development Hell before the end of 2011.
Wesnoth RCX’s development is halted right now due to lack of interest on my part to invest energy on writing the rest of the new functionality (i.e. definition of custom ranges and palettes), but I know that once I touch Qt Creator’s awesome interface I can’t stop working for a while — so I may eventually get some inspiration to redesign the main window, which should inevitably lead me to tinker around with the rest of the code.
C# was the first “major” programming language I learned, not counting Visual Basic. I have some fond memories of my first experiments with C#, but after I embarked upon learning and using C++ I kind of forgot about it. I have been considering the possibility of writing an IRC client of sorts using C# just for kicks, and to not forget this language in case I ever need it again. Why IRC? Because clients for this protocol are simple and challenging to implement, both at the same time!
I’ve already started to learn a bit of Lua for my work on the aforementioned Wesnoth campaign — in fact, there’s already some released code within it written in this language, particularly in scenario 5! I have plans to rewrite parts of Invasion from the Unknown in Lua to clean it up a little, thus paving the road for future maintenance work by me or other people (don’t forget that IftU is still abandoned!).
Another software project I intend to tackle in the short term is Rei 2. Sure, she’s doing well and her main command handlers are many and useful enough for channels such as ##shadowm and #wesnoth-umc-dev, but her dependence on Irssi’s core might well be a curse for one of our use cases: Shikadibot (the Second), which runs on a resource-limited VPS where every drop of RAM has got gold value. I’m already brainstorming a possible abstraction layer (codenamed “API 3”) which could allow the Irssi core to be swappable with a custom, native IRC client core (codenamed “Anya”). There’s really not much in the current Irssi-based implementation of the internal interfaces (“API 2”) that make a dependency switch unfeasible.
Finally, I’m not going to stop producing useless updates for my website! Dorset5 0001 is already a reality, although there’s still much I want to do before replacing the current layout. This time I have placed an emphasis on readability and elegance that I don’t think the previous revisions have lived up to so far.
• • •
All in all, I always have so many ideas floating in my mind that I rarely carry to realization, so this can’t be considered a definitive list. There are other possibilities I’m contemplating for the long term regarding my personal life, but that’s a much more volatile subject to discuss so I’m avoiding it for now.
After so much work, codename “Hakone”, the new website layout and software powering the Wesnoth-UMC-Dev website is finished, bringing with it a series of changes to begin to renew the project for the upcoming new year.
Ancient, old, and new
The Wesnoth-UMC-Dev website has gone through three revisions counting “Hakone” — “Soradoc” and “Kalari” being its predecessors.
My emphasis during the construction of codename “Hakone” was placed on functionality, standards compliance at the web interface level, and a soft, elegant and modern look, all of which I think have been accomplished. Through the integration of technologies such as XML feeds using SimplePie, and the minimalistic yet extensible blog engine provided by Blosxom along with our homegrown Poison Ivy PHP engine, we have achieved our ultimate objective of establishing our own network identity as an independent, parallel project to Battle for Wesnoth.
We have also added an embedded IRC client using freenode’s neat webchat gateway, available from within the Contact section. This should pave the way for further coordination between developers and repository administrators using our official discussion and support channel.
In this opportunity I’ve also opted for standardizing the spelling of our short project name to “Wesnoth-UMC-Dev”, as opposed to the earlier “wesnoth-umc-dev” and “Wesnoth UMC Dev[elopment]”.
There are bugs that remain to be fixed though, which are related to the feeds handling within the various site components — but nothing that is going to matter for the moment due to our rather restricted audience.
So there goes another bit to add to my web design stories, an experience from which I’ve learned a lot of valuable information for my work on “Dorset5”.
