After the Storm 0.6.0 has just been released, despite the original deadline I set for myself just a few days ago being Christmas Eve. As a consequence, that day will be the deadline for AtS version 0.6.1 instead, which should include a working scenario E2S4 (i.e. fourth scenario of the second episode). Of course, if a major bug arises in the meantime, that tentative version number will have to change.
Apparently, I work faster when I feel the need to deliver within a specific time frame. In this case, the need stems from fear of public humiliation. Probably.
The changelog for this version follows:
Version 0.6.0:
--------------
* Increased minimum Wesnoth version requirement from 1.9.5 to 1.9.7.
* Scenarios:
* Reworked character recall logic.
* Episode 2 (Fate):
* Scenarios 1 and 2 completed.
* Scenario 3 completed, consisting of two cutscenes.
* Units:
* Reduced Sprite's required XP to advance from 70 to 40.
* Reduced Fire Faerie's required XP to advance from 100 to 70.
Regarding the version requirement increase, it’s not so much because of changes in WML syntax but rather because of a new terrain added in 1.9.7 that’s used in E2S2.
After completing the first episode of After the Storm, a short vacation was a logical option so I could return to work later with fresh ideas and more energy. By ‘vacation’ I don’t mean a traditional Wesbreak as most people do, though — quite the contrary, in fact.
For a long time I’ve been bothered by the haphazard-looking design of the Editor Settings dialog. This (already GUI2) dialog’s main focus is a bunch of lighting options intended for map or terrain authors to test what their creations look like under different Time of Day lighting presents, or even custom lighting, which is also useful for campaign designers trying to come up with an atmospheric feel within Wesnoth’s rendering engine limitations.
→
I don’t claim to be a UI design expert — I’m fairly certain I’m not — but I feel my vision of the dialog is better than the original author’s, and for this reason I recently committed to trunk these changes along with a couple of fixes for related long-standing bugs that were definitely not introduced by me. I think. I hope.
I am not keen on having Title Case on checkboxes, either, but for some reason the wiki says it’s what we should use, so I’m going to stick to that for 1.10 as it’s already used in most places anyway. I hope we can clear that up during the 1.11.x development cycle since even GNOME’s Human Interface Guidelines recommend sentence case for such elements.
(Note to self: rephrase the MDI option label again since “allow having” doesn’t sound proper at all.)
→
The item selection menu triggered by the Starting Position tool in the editor was a generic GUI1 dialog, until now. I decided to tackle this conversion task and add a feature in the process: existing starting locations are shown in the second column of the player list, in the form of map coordinates. This is not too helpful since we already had keyboard shortcuts to reach starting locations in the map editor (1-9 number keys), but in my opinion looks nice. The giant help tip in the dialog description had to go though, but don’t worry, for the tooltip on the editor palette already provided the exact same information in a more consistent fashion with regard to the other editing tools.
→
And finally, something more useful for the large majority of the userbase: removing multiple add-ons at once without having to return to the Uninstall Add-ons menu. I have not committed this to trunk yet, though, and I’m not even sure I’ll be able to merge it before the feature freeze in preparation for the final lap towards 1.10 comes into effect.
As I previously reported, reicore’s hard disk might be dying. This is not surprising in the least, since I have been hearing loud noises from the drive during high activity since a long while — playing vanilla Minecraft is apparently the most straining task for it for some reason. Considering reicore didn’t present any such issues at the beginning, it’s possible the person who gave her to me when bluecore croaked did something bad to her while I wasn’t looking. He’s unlikely to confirm such a thing, though.
A short drive self-test last night revealed that one of the bad blocks is currently part of the very root filesystem. Since I started to consistently hit a bad block while logging into KDE, I decided to run e2fsck -c on all partitions from a Grml live CD system (also Debian-based).
(Yes, I just realized I inadvertently left the swap partition out of the emergency check procedure. I just ran badblocks on it in read-only mode and it appears to be clean.)
Scanning a 466 GiB hard disk for bad sectors isn’t a quick task, but it took just as long as it did with the 1.18 GiB disk on my first computer back in 1998 — about two hours and some minutes — and here are the good news: there are only two damaged sectors, both of them within the root filesystem, and only one file was lost: /usr/lib/libQtDesigner.so.4.7.3, provided by the libqt4-designer package in Debian wheezy.
Why the dynamic linker felt it necessary to access this file while launching Akregator and KMail during the login process is beyond me, but it’s good that nothing was lost, as I promptly reinstalled the package. Either way, I had a fresh pre-upgrade backup in my external 2 TiB hard disk drive ready just in case.
I’ll certainly have to get used to making backups more often than my previous, sloppy biweeklyn-weekly schedule. Thanks goodness for rsnapshot.
The last time I tried to switch from Debian stable to testing I was hit by a disease known as X.org Server 1.10, and more specifically, fd.o bug #31017, which made my KDE experience less than worthwhile, to say the last. The solution I devised was not particularly productive either.
However, X.org Server 1.11.1 hit Testing a while ago, and it’s what I am using right now — I successfully switched to “wheezy” again, today, and this time it would seem a massive rollback won’t be required, since the aforementioned bug is finally fixed.
I don’t think I can claim the upgrade was smooth, though.
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.
Wesnoth.org appears to have DNS issues at the moment, resulting in the site’s address being impossible to resolve to a numeric address (IP) for most people. We are doing everything that’s possible at the moment to restore it.
UPDATE: Apparently, it’s been solved already. However, the new records could still take some time for some people to have an effect due to DNS caching.
UPDATE 2: My own evidence indicates that it’s not solved yet.
UPDATE 3 (Oct. 3rd): It’s solved now. Some DNS servers could still claim wesnoth.org doesn’t exist, so just give them a few more hours.
If you trust me (since I’m the forum administrator and all), you can follow these simple instructions to fix your access to Wesnoth.org’s services in the meantime. If you don’t feel comfortable editing system files or don’t have admin access, you can try connecting directly to Wesnoth.org’s current IP, 65.18.193.12, but this will not work correctly with the wiki and forums which use the wiki. and forums. subdomains.
Do note that what I describe should be considered a temporary workaround. If Wesnoth.org’s IP changes in the future, you’ll need to remove any hosts file entries you added.
Linux, BSD derivatives
Note: make sure to backup your /etc/hosts file first in case you accidentally delete its previous contents, which could cause some applications to behave incorrectly.
Edit the file /etc/hosts with a plain text editor such as gnome-editor, Kwrite/Kate, vi/vim, Emacs, and such.
An alternative is just issuing the following command as administrator. Notice that it uses >> instead of the usual > in order to append rather than replace the file!
Edit or create the file C:\WINDOWS\System32\Drivers\etc\hosts with a plain text editor such as Notepad (replace C:\WINDOWS with the correct installation path of your OS if necessary.
Unfortunately, I have no idea about Mac OS X since I’ve never had an Apple computer. If anyone knows more than I do, feel free to post a comment explaining the steps.
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!
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.
Apparently, Battle for Wesnoth is already out in the Android Market! There’s no official announcement about it right now, but I got these tasty links (posted in Twitter as @WesnothOrg as well) a few minutes ago from the maintainer, cjhopman in the forums and IRC!
Since Frogatto & Friends moved from its own SVN repository to a Git one on Github, some people have got confused by the appearance of true merge commits in history due to them working on their master branch directly, pulling from upstream and pushing again. I don’t personally think that this is the best workflow, but for former SVN users it appears to be the most suitable transitional option.
But Git isn’t a 1:1 equivalent solution — and I won’t get too deep into that subject, so I’ll explain instead what the method that works best for Frogatto (without merge commits!) at the moment is.
$ git config branch.master.rebase true
$ git config rebase.stat true
The first line sets a configuration option that tells Git to try rebasing our local master against upstream after using git pull on it. The result of a rebase operation is that local commits not merged upstream are temporarily removed from history, the branch is reset to its previous diversion point, fast-forwarded to the new upstream HEAD, and the local commits are then rewritten on top, giving the user the choice to solve conflicts by hand as they appear, should they appear at all. The second line makes automatic and manual rebase operations to display a summary and stat display of changes merged in the fast-forward operation. I’m not entirely sure why this is not the default; normal fast-forwards and true merges (controlled by the merge.stat option) on git pull and git merge already do this.
See also git-rebase(1) for further information on what the rebasing procedure entails.
Once the configuration is adjusted with those two lines, it’s safe to git pull right away and later git push once everything is ready for committing to the Github repository for everyone to see.
For Frogatto’s SVN-inspired linear approach to history this means that merge commits won’t be generated and they won’t pollute history and confuse people who are not used to distributed version control systems.
