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.
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).
Just wanted to note that I am pausing my online Wesnoth and IRC related activities for an indeterminate amount of time while I tend to some matters of greater priority. In case you are wondering, yes, everything is fine, but I do need a break.
You can still message me through Twitter, email (preferably!), or private message through the Wesnoth forums (which result in email notifications) if something absolutely important crops up in the meantime other than the forums being down. I have provided the other Wesnoth.org administrators with instructions in case I’m needed for something specific, and for other issues you can always PM the Forum Moderators or Administrators groups or email the forums support address, which is displayed whenever things go completely wrong.
And of course, I may continue to post about non-Wesnoth things here as I see fit.
UPDATE 2012-11-30: The problem described in this post no longer applies since yesterday 2012-11-29, as the ia32-libs* multiarch transitionals have finally landed in Testing. Installing libgl1-nvidia-glx:i386 after previously installing the rest of the NVIDIA stack from Experimental appears to work flawlessly.
Quite notably, everything is working fine with the latest Debian wheezy packages (although I compiled my own newer kernel later anyway) except for the onboard sound controller.
Ah! But not so fast! I had forgotten that Debian wheezy’s half-baked multiarch support has serious implications for 32-bit OpenGL-based software on the amd64 platform (a.k.a. x86_64 for everyone else), regardless of whether one is using a proprietary (e.g. NVIDIA) or free (Mesa) stack. In Reicore’s (Mesa) case, this meant that I had to stick to the version from ia32-libs in Testing, which is Mesa 7.7.1 — contrast with the native version, which is 8.0.4.
In Nanacore’s case, the implications span even more packages. The description of the libgl1-nvidia-glx-ia32 package in Testing (amd64 arch) says:
This is an empty transitional package to aid switching to multiarch.
Run the following commands to install the multiarch library:
dpkg --add-architecture i386 ; apt-get update
apt-get install libgl1-nvidia-glx:i386
And, surprise, surprise. That doesn’t work in Testing because of bug #686033 — fortunately for me, apt-get was wiser in blocking the operation due to some perceived conflicts.
In an attempt to solve this, I pulled the NVIDIA driver packages from Unstable and then tried to install libgl1-nvidia-glx:i386 again to no avail — it requires me to upgrade ia32-libs from the version in Testing to the one in Unstable, which is really a multiarch transition metapackage. After watching multiarch in Debian wheezy become such a major disappointment over time, I decided to do something different with libgl1-nvidia-glx:i386.
I decided to install it by hand.
The procedure was a little convoluted and involved a lot of symbolic links, and I’m not completely sure whether what I did works because I don’t have Wine installed right now and I don’t really want to install Debian’s packages because—again—they use multiarch support to pull nearly 92 MiB worth of redundant crap:
0 upgraded, 70 newly installed, 0 to remove and 0 not upgraded.
Need to get 91.9 MB of archives.
After this operation, 265 MB of additional disk space will be used.
Do you want to continue [Y/n]?
Not to mention that by pulling Mesa it might as well break my little patchwork setup with NVIDIA’s 32-bit libGL here. This is not something I’m too keen on trying out while stuck on shitty 3.5G mobile broadband.
I intend to revisit and unravel this conundrum at a later point and try to understand and document my libGL installation solution but, again, I have bigger fish to fry.
It was only fitting that the seventh machine—a desktop—would be Nanacore (nana なな) then.
Name
Year
CPU
RAM
Hard disk
Graphics
OS
Reicore
2010
Intel Pentium T4300 2.1 GHz dual core
4 GiB
500 GB
Intel GM45
Debian testing (Wheezy)
Nanacore
2012
Intel Core i7 (Ivy Bridge) 3.5 GHz HT quad core
16 GiB
2 TB
NVIDIA GeForce GT610
Debian testing (Wheezy), Windows 7 (???)
Quite notably, everything is working fine with the latest Debian wheezy packages (although I compiled my own newer kernel later anyway) except for the onboard sound controller.
00:1b.0 Audio device: Intel Corporation 7 Series/C210 Series Chipset Family High Definition Audio Controller (rev 04)
The Intel HDA codec for these controllers is apparently not quite ready yet; as a result, the mixer sliders are slightly broken in that there is no master channel, the speaker channel has no actual volume slider, changing the PCM channel’s volume causes some slight noise, and I suspect some features are missing as well. Despite this, the driver works for basic usage given some precautions with the KDE sound system to choose the correct (PCM) channel for audio instead of the sliderless (speaker) channel. I would not mind to spend some additional time researching the situation later, but I really need to get back to work on non-audio stuff (a.k.a. AtS) right now, so that will have to wait.
Incidentally, the Debian KDE desktop task includes PulseAudio now (I believe this wasn’t the case with Squeeze). Rather unsurprisingly, PA continues to be a considerable annoyance for my usage (e.g. lockup during KDE login, 1% extra CPU usage during playback from any application), so I ditched it after a day or two for plain ALSA. I don’t really have a need for the extra layer of indirection since PA uses ALSA anyway and my sound needs are very basic — basically, just playing sound from media players, games, and application notifications.
For graphics I’m using a decidedly inexpensive NVIDIA graphics card for the sake of having an NVIDIA graphics card and parting ways with Mesa for a good while. And while I had intended from the get-go to install the proprietary drivers, a forced and thankfully short Nouveau intermission confirmed that Nouveau indeed eats kittens. And that’s really all there is to say on the matter.
Both the machine and Debian wheezy can do UEFI, but I quickly stumbled upon a couple of issues:
Using the EFI version of GRUB means the only way to get a working text console on Linux is to use a framebuffer console driver such as efifb. This is not supported by NVIDIA and the driver complains quite loudly about it.
The machine appears to enumerate my (USB) 3G modem’s built-in storage as the first and second hard disks when it is connected, breaking GRUB’s expectations about the location of the disk from which it will boot, which becomes the third (SATA) hard disk in such a situation. The PC BIOS version of GRUB only gets to see the real hard disk drive.
Since this is my first time dealing with an UEFI-based system yet, I don’t really know whether the second point is a bug in GRUB, or the platform itself. Regardless, the first point pretty much convinced me to not spend any further time on that and just go back to the BIOS flavor of GRUB. This doesn’t seem to have done anything for my broken Windows 7 installation, which I probably don’t really need.
I have been working on transferring my configuration and files from Reicore since this Monday, approximately, and I think I’m nearly ready to get back to business now.
(I actually wanted to post this on the 7th but I got sidetracked by the system migration and testing.)
First there was an old (1997) Windows 95 OSR 2 box boasting a P55C Intel Pentium processor with an staggering clock frequency of 166 MHz; 16 MiB of RAM (later expanded to 32), a 1.2 GB* hard disk; it had an onboard S3 Trio64V+ with 1 MiB of video RAM.
* Hard-disk manufacturer ‘gigabytes’.
Then, there was another OEM machine (2002), running Windows XP on a 1.3 GHz Intel Celeron (“Celeron-S”) including 256 MiB of RAM and a 40 GB hard disk; before it was decommissioned for good, it ran both Windows XP SP2 and openSUSE 10.0; it was the first machine on which I ever installed Linux (SUSE Linux 9.3), and my original introduction to Wesnoth (0.9.5 from openSUSE 10.0) happened there; the onboard Intel 810E IGP became the victim of various Linux graphics-related shenanigans. (This was the last computer I ever owned that included a 3.5" floppy disk drive; unfortunately, it was broken and it took me a year and various casualties to figure this out.)
Later during 2006, Blackcore appeared: another OEM machine running Windows XP SP2, equipped with a 2.6 GHz Intel Pentium 4 (Prescott) with Hyper-Threading; 1 GiB of RAM, a 160 GB hard disk, and an IGP from the biggest piece of shit chipset manufacturer otherwise known as VIA. This was my first named computer, a practice which has truly paid off to this day. It currently runs the same original installation of Windows XP upgraded to SP3; it has run various Linux distributions and versions and I’ve not stuck with any of them simply because VIA is the biggest piece of shit chipset manufacturer.
Following the color-themed naming scheme, Greycore became the first laptop I ever owned around mid 2007; an Acer Aspire 5050 including an AMD Turion 64 MK-36, an amount of RAM I don’t remember anymore, 80 GiB hard disk drive, and Windows Vista. It first ran openSUSE 10.2 and openSUSE 10.3 besides Windows for a long time, until I got fed up with an incident involving a security update utterly ruining my system with terrible timing. It took a while before I finally decided to switch to another distribution instead of keeping the same old 10.3 installation around, but it was worth it — Debian Lenny (testing at the time, Q3 2008) was my choice and I have stuck with Debian ever since.
Bluecore started with 2 GiB of RAM and ended up with 4 GiB as Wesnoth began to demand significantly more memory for compiling. The 2 GHz dual core AMD Athlon 64 performed very well at the beginning, but our favorite open source game’s development largely outpaced it. The 250 GB hard disk served me well despite running into low space situations in various opportunities as I began to experiment with the processor’s hardware-assisted virtualization capabilities. This overheating beast (51 °C - 64 °C idle, 65 °C - 92 °C under load) has only run Debian as its native operating system besides Windows — first Lenny (testing, later stable), then Squeeze (testing), and very recently, Wheezy (testing). The ATI Radeon HD 3200 was an infinite source of frustration when it came to OpenGL on Linux until very late 2009.
Its untimely and infuriatingly IGP-driven demise resulted in Reicore taking over; first temporarily, and then permanently as its 2.1 GHz dual core Intel Pentium T4300 and Intel GM45 graphics processor ended up proving far more worthwhile than Bluecore’s AMD-based configuration. Reicore (an HP Pavilion dv4-1624la) was purchased for someone else at first, and ran Windows 7 until she became mine, and then I proceeded to wipe it out to make room for Debian — first Squeeze (stable), and now Wheezy (testing). I have never run out of space with its 500 GB hard disk, and even today my /home partition has a little more than 50% of free space. It helps that the processor’s lack of virtualization capabilities has not been very encouraging in the virtual machine department, I guess.
Name
Year
Decom.
CPU
RAM
HDD
Graphics
OS
―
1997
―
Intel Pentium (P55C) 166 MHz
32 MiB
1.2 GB
S3 Trio64V+
Windows 95 OSR 2.0
―
2002
2006
Intel Celeron (‘Celeron-S’) 1.3 GHz
256 MiB
40 GB
Intel 810E
openSUSE 10.0, Windows XP SP2
Blackcore
2006
―
Intel Pentium 4 (Prescott) 2.6 GHz HT
1 GiB
160 GB
VIA POS
Windows XP SP3, Debian GNU/Linux 6.0 (Squeeze)
Greycore
2007
2008
AMD Turion 64 MK-38 2 GHz
??? GiB
80 GB
ATI Radeon Xpress 1100
Debian GNU/Linux 5.0 (Lenny), Windows Vista
Bluecore
2008
―
AMD Athlon 64 X2 QL-62 2 GHz dual core
4 GiB
250 GB
ATI Radeon HD 3200
Debian testing 2012-10-22 (Wheezy), Windows Vista SP1
