Everyone who follows me on Twitter can stop reading here.
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
##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:
- /trunk/After_the_Storm file listing (tarball link at the bottom)
- /trunk/AtS_Music file listing (tarball link at the bottom)
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:
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.
Nowhere near ready yet, but here’s a few screenshots (warning: large pictures) from the unfinished AtS E3 finale scenarios:
As 2012 approaches its inevitable end in Chile, I say: goodbye, 2012.
Happy New Year, everyone! And thanks for all your support.
... screen #0: dimensions: 1920x1080 pixels (513x292 millimeters) resolution: 95x94 dots per inch ...
I regret nothing.
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).
Ever since I got my first laptop, I always wondered what kind of people are actually meant to use the ‘tap’ capability built into touchpads.
I remember being stumped at first when I would try to do normal things (on Windows) only to get continuously interrupted by some unexplained drag-and-drop action or accidental click. There was absolutely nothing anywhere evident explaining that ‘tapping’ was a thing I was expected to do, and in fact, was accidentally doing repeatedly. It took me some experimentation to get the gist of the interface and its configuration, and as soon as I understood it better I went and disabled it.
Later when switching (back) to Linux I would encounter the same issue and I’d have to check the X.org synaptics driver man page to figure out the necessary options to add to
/etc/X11/xorg.conf to get rid of that questionable ‘feature’. Fortunately, nowadays I can just install the
kde-config-touchpad package on Debian and configure everything according to my preferences through a more user-friendly mechanism.
Alas, just like the power button, that laptop’s touchpad buttons were not designed for daily use — thankfully KDE (like Windows) includes a feature to control the pointer with the keyboard.
What touch-based input lacks is intrinsic tactile feedback. Unlike button or key-presses, I cannot feel the action of tapping a touchpad any more than I can feel the action of casually or accidentally sticking my finger on it. A very small amount of pressure counts as a tap, whereas pressing a normal touchpad or mouse button requires a much larger amount, and with good reason; that pressure could be the difference between holding back an embarrassing post and inadvertently submitting it, or (when dragging gestures are enabled) ruining one’s system by dragging half of the Windows system files to the wrong place. Fortunately, most of my experiences in that regard have been of the “cannot drop a folder onto itself” kind.
There is also the issue that not everyone has the common sense to keep their hands clean at all times. Helping other laptop users can be a quite unpleasant experience without a mouse handy — yuck.
And then there are cell phones. Touchscreens are becoming irritatingly common (even in the low-end market) and they are even worse than touchpads in most respects. Sure, you can see what you are going to tap right there, but is that any help against “fat finger” mistakes? Scrolling gestures are a hit or miss action by design, and it is awfully easy to screw up the timing and have the device register it as a tap. These are your time and money in the balance here; you do not want to miss while navigating cell phone menus. And exactly how am I supposed to point other people at some element on the screen without activating it or giving up accuracy and pointing from afar?
In any case, I am pretty sure I do not want to be forced to use a touchscreen-driven phone to call an ambulance.
The obscene joke that is Windows 8 was clearly intended to push OEMs to produce more and more touchscreen-based garbage, as if we needed to merge phone and tablet user interface paradigms with desktop and laptop computers. I could rant some more about Windows 8, but that would take at least a dozen more paragraphs for a worthless tangent. The only thing that matters is that Microsoft will most certainly succeed regardless of the platform’s user experience merits (of which there are basically none compared to Windows 7), simply because of the OEMs and software vendors’ obligation to lick Microsoft’s smelly boots. I can see non-touch monitors becoming increasingly rarer in the future for this reason; I can see the pain for user interface toolkit developers and clients (users) in a few years when everything is required to support touch input — yes, even Wesnoth.
And in this case, mice are not an optimal alternative. I have tried the Windows 8 Release Preview on virtual machines with a mouse and I can safely say I find any other version from 3.0 through Windows 7 to be more efficient for daily use. I guess your mileage may vary after a while, though. Perhaps technologically-challenged kids and elders will learn to use the “modern desktop” faster and better than us veterans?
Not my business anyway — as long as the KDE crowd doesn’t fuck up, that is. Let us all hope Canonical doesn’t fuck up in a similar way too, because everyone likes to imitate Ubuntu nowadays.
My initial experience with computers was through MS-DOS and old-fashioned keyboards. I grew up using standard two-button mice in tandem with more old-fashioned keyboards, and later upgraded my experience with scrolling wheels, and wireless mice. Scrolling wheels are great for web browsing, coding, examining lengthy terminal output buffers, and even drawing, but the cheaper mice out there don’t really last very long, and lint and hair do not really help matters when the design doesn’t include a simple way to access and clean the wheel’s gear.
Wireless mice are apparently a love-it-or-hate-it subject. My current mouse has lasted over a year, it is large enough to work well as a laptop mouse and a desktop mouse, and the battery charge tends to last nearly a month. I bought a couple of rechargeable AA batteries with it and I always keep one fully charged for quick replacement; the mouse only uses one battery at a time. All of my previous mice used two AAA batteries, which lasted significantly less. Their scroll wheels were evidently not designed to last either.
I am pretty sure I will not be buying any touch-based devices for the foreseeable future. My new cell phone is more than enough to keep my patience below nominal levels for a while, at least when using it; I am grateful that the manufacturer was kind enough to include a physical numeric keypad along with two actual call and dismiss buttons.
Just wanted to note that I am ceasing 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.
From my previous post:
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
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:
shadowm@nanacore:~$ sudo apt-get install wine [sudo] password for shadowm: Reading package lists... Done Building dependency tree Reading state information... Done The following extra packages will be installed: gcc-4.7-base:i386 libasound2:i386 libc6:i386 libc6-i686:i386 libdbus-1-3:i386 libdrm-intel1:i386 libdrm-nouveau1a:i386 libdrm-radeon1:i386 libdrm2:i386 libexpat1:i386 libffi5:i386 libfontconfig1:i386 libfreetype6:i386 libgcc1:i386 libgcrypt11:i386 libgl1-mesa-dri:i386 libgl1-mesa-glx:i386 libglapi-mesa:i386 libglu1-mesa:i386 libgnutls26:i386 libgpg-error0:i386 libgpm2:i386 libgsm1:i386 libice6:i386 libjbig0:i386 libjpeg8:i386 libltdl7:i386 liblzma5:i386 libmpg123-0:i386 libncurses5:i386 libodbc1:i386 libp11-kit0:i386 libpciaccess0:i386 libpng12-0:i386 libsm6:i386 libssl1.0.0:i386 libstdc++6:i386 libtasn1-3:i386 libtiff4:i386 libtinfo5:i386 libuuid1:i386 libv4l-0:i386 libv4lconvert0:i386 libwine:i386 libwine-alsa:i386 libwine-bin:i386 libwine-gecko-1.4 libwine-gl:i386 libx11-6:i386 libx11-xcb1:i386 libxau6:i386 libxcb-glx0:i386 libxcb1:i386 libxcomposite1:i386 libxcursor1:i386 libxdamage1:i386 libxdmcp6:i386 libxext6:i386 libxfixes3:i386 libxi6:i386 libxinerama1:i386 libxml2:i386 libxrandr2:i386 libxrender1:i386 libxslt1.1:i386 libxxf86vm1:i386 uuid-runtime wine-bin:i386 zlib1g:i386 Suggested packages: libasound2-plugins:i386 glibc-doc:i386 locales:i386 rng-tools:i386 libglide3:i386 gpm:i386 libmyodbc:i386 odbc-postgresql:i386 tdsodbc:i386 unixodbc-bin:i386 wine-doc:i386 libwine-cms:i386 libwine-sane:i386 libwine-ldap:i386 libwine-print:i386 libwine-openal:i386 libwine-gphoto2:i386 Recommended packages: uuid-runtime:i386 ttf-liberation:i386 xml-core:i386 The following NEW packages will be installed: gcc-4.7-base:i386 libasound2:i386 libc6:i386 libc6-i686:i386 libdbus-1-3:i386 libdrm-intel1:i386 libdrm-nouveau1a:i386 libdrm-radeon1:i386 libdrm2:i386 libexpat1:i386 libffi5:i386 libfontconfig1:i386 libfreetype6:i386 libgcc1:i386 libgcrypt11:i386 libgl1-mesa-dri:i386 libgl1-mesa-glx:i386 libglapi-mesa:i386 libglu1-mesa:i386 libgnutls26:i386 libgpg-error0:i386 libgpm2:i386 libgsm1:i386 libice6:i386 libjbig0:i386 libjpeg8:i386 libltdl7:i386 liblzma5:i386 libmpg123-0:i386 libncurses5:i386 libodbc1:i386 libp11-kit0:i386 libpciaccess0:i386 libpng12-0:i386 libsm6:i386 libssl1.0.0:i386 libstdc++6:i386 libtasn1-3:i386 libtiff4:i386 libtinfo5:i386 libuuid1:i386 libv4l-0:i386 libv4lconvert0:i386 libwine:i386 libwine-alsa:i386 libwine-bin:i386 libwine-gecko-1.4 libwine-gl:i386 libx11-6:i386 libx11-xcb1:i386 libxau6:i386 libxcb-glx0:i386 libxcb1:i386 libxcomposite1:i386 libxcursor1:i386 libxdamage1:i386 libxdmcp6:i386 libxext6:i386 libxfixes3:i386 libxi6:i386 libxinerama1:i386 libxml2:i386 libxrandr2:i386 libxrender1:i386 libxslt1.1:i386 libxxf86vm1:i386 uuid-runtime wine wine-bin:i386 zlib1g:i386 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.