To begin this holidays week, I have introduced a few minor changes to the Wesnoth forums which should hopefully increase organization and ease of communication amongst us.
First, there’s now a separate Miscellaneous forum dedicated to those silly Forum Games, which is not indexed, doesn’t account for post counts, and doesn’t have an associated Atom feed unlike the rest of the board. Its topics are not listed in the Active topics view either.
Second, we now have new profile fields that can be optionally filled-in by users wanting to share with the community a bit more of information about themselves. These are the gender, languages and IRC nickname items. They are all displayed in the regular individual profile view, as well as in your User Control Panel, and may be modified visiting User Control Panel → Profile → Edit Profile.
(Wesnoth.org being an international community, it makes sense to allow people to tell us what languages they speak so we may be able to give them assistance in their natural language whenever applicable, or to help us choose new moderators.) 😉
Not too long ago, I forked a branch from Wesnoth’s trunk and started committing stuff to it in the mainline repository, thanks to the awesome power of Git branching through the git-svn bridge. My main goal is to experiment with improvements to the add-ons download interface, trying to address some of our users’ most common complaints, while not touching trunk directly to allow Ilor — who’s in charge of the WIP new add-ons server/client implementation — to easily merge his changes with trunk and the other way around until I can get confirmation from him about the mergeability of my own work.
Right now there’s very little done in my umcmg branch, but today I’ve come up with some patches that should be trivial to mix into trunk.
Pictured to the right is the new Add-on Description dialog (taddon_description), intended to finish my quick-and-dirty hack from September 2009, which made it to trunk nearly at the same time as a string freeze entered in effect, making it impossible for me to polish this feature for 1.8.
At the left you can see something potentially less interesting, a work-in-progress Download progress viewer (taddon_download_progress) that is written using mordante’s GUI2 toolkit instead of the old GUI1. This is hardly usable right now, and in fact, crashes the game, proving yet again that I’m not really fit for messing with the network layer of our dear game.
It’s really tempting to just run over the Download/Update dialogs with a steamroller, but mordante’s got his own plans for that and the GUI2 listbox widget, which will unconditionally become a basic building block of the hypothetical, unified add-ons manager dialog, plus there’s also Ilor’s work on the new server/client; therefore I can only wait for now until these matters are settled and try to have something ready for 1.10 as a last resort if neither of the aforementioned solutions are available by the time we hit another string/feature-freeze period.
Today, around 15:00 UTC, the Wesnoth.org board was disabled by none other than me, in order to perform some maintenance work in the forum files. With this, the forums were upgraded from phpBB 3.0.7-PL1 to phpBB 3.0.8 and one mod was updated to a newer version still awaiting validation from the phpBB mods team.
Additionally, I added a new server-side redirection rule to convert old http://www.wesnoth.org/forum/ and http://wesnoth.org/forum/ links to use the current forums vhostname, forums.wesnoth.org. This should solve issues with inconsistent links lingering around and polluting people’s bookmarks and web pages with different forum paths — of course, this is not automatic and existing references need to be manually updated to reflect any required changes, but at least now /forum has got a well deserved final rest.
There isn’t really any other exciting news to share with you, although I do expect an undefined amount of users to have login problems the next time they visit the forums. This should not be a permanent issue, however, but if it turns out to be I have a solution (a.k.a. “plan B”) prepared for the occasion.
Windows package:wesnoth-rcx-0.1.4-win32.zip (Zip archive, 5.2 MiB)
SHA1 checksum: 3832ddb798110f2e890aecc37519097e1e18e2b6
Mac OS X binary:wesnoth-rcx-0.1.4.app.zip (Bundle, 14.9 MiB)
SHA1 checksum: 60a5724d35b0bf64d02b4553ff9c1543d5964344
This binary is kindly provided by Alarantalara from the forums.
The only major change in this version is the addition of zoom support in the user interface, so you can take a look at your team-colored pixel art at 100%, 200%, 400% and 800%, or even at 50%. No more levels are supported at the moment, and will probably never be unless you submit a patch — this is really just supposed to be a help tool, so if you need more exotic zoom levels use a real graphics manipulation tool such as Adobe Photoshop or the GIMP. And don’t forget you can also drag and drop images now!
There’s also a brand-new grayed-out menu for you to observe and admire. Only observe — don’t touch it.
As with the last time, the instructions for building the source are in the included INSTALL file in the distribution archive. This file is not present in the Win32 distribution for obvious reasons.
Don’t hesitate to comment on RCX’s development, usability, bugs, or suggest new features! The only way things can get fixed or improved is that you make sure I am aware of what needs to be changed. If you think you can help with something else, please tell me!
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”.
It’s almost over. Time flies even faster as we get closer to the end of 2010, and apparently there’s a lot to summarize despite we’re not in the finish line yet!
This has been a particularly difficult year for me in a more personal sense, and I’ve faced some trials I won’t speak about and then some, but I’ve also learned new things in the road — things that may be of greater use to me in the future. There’s really a lot that could be said about this year but I’ll restrict it to computer stuff to avoid boring the audience too much bore the audience as much as possible.
The Wesnoth-UMC-Dev Project has been around for quite a while now and it’s helped in the preparation of three user-made add-ons for entering Wesnoth’s mainline repository. As time passes more content finds its place into our facilities and more people learn to take advantage of Subversion. There’s still more to come, as ESR and Fabian Müller (fabi/fendrin) are working on a new drake campaign for mainline titled Wings of Victory.
We are currently in need of more people interested in helping around with repository maintenance and application processing tasks, though. Espreon, AI and I do our best to handle new registrations and keep everything tidy and clean, but we also have projects of our own!
As part of a series of changes I hope to have ready before March 2011 — just in time for our 3rd anniversary — the development of a new website “skin” codenamed Hakone, has started today.
I already have most of the CSS rules working, but this template is not leaving the early development stage soon, for I still want to try new and crazy ideas on it before the final deployment phase. In particular, I want to reorganize the site structure at the same time to make it more accessible to our target audience while providing as much documentation as we can. You can have a taste of the preliminary plan clicking on the screenshot above.
Due to my unusual workflow, things are likely to be dropped, replaced and added as I deem necessary or convenient. I’m going to make use of Twitter to post major updates as I go during the next few months.
Finally, I’ve also been making steady progress on improving Rei 2 IRC Bot’s power and cleanness, and for a couple of weeks Shikadibot has been running with her core instead of Shikadibot 0314’s (R.I.P.). Nonetheless, #wesnoth-umc-dev’s bot is unlikely to change much in terms of features, as she doesn’t run with all of Rei 2’s modules for the sake of resource saving.
Due to general laziness, it took me a long while to research how to make my EPSON Stylus TX105 multifunctional inkjet printer work natively on Linux. I got one of the steps done, arguably only because it was relatively easy to do on a Debian system without messing things up too much — I got the printer piece working on May 2009 with Debian GNU/Linux 5 “Lenny.” Ever since then, I’ve stuck with Windows Vista for scanning and Linux for printing.
This is not the case anymore, now that I’ve learned better. This is one of the many ridiculous things one may need to do when stuck with old hardware that doesn’t work on Linux out-of-the-box. In comparison, I recently installed a Brother HL-2140 laser printer by just plugging the USB cable and waiting for KDE to tell me that the device was configured and ready. Amazing.
So, without further ado, here’s my personal recipe for making the TX105 work natively on Debian GNU/Linux 6 “Squeeze.”
Despite Mordante/SkeletonCrew’s absence from the #wesnoth-dev IRC channel for a while, I’ve still been making progress on converting more parts of the Wesnoth game interface to the GUI2 toolkit. As I mentioned before, completing the transition to GUI2 is an important step towards the next major milestone that is Wesnoth 2.0, and there’s still a lot of work to be done in this area.
Yesterday I pushed a set of commits that convert the Campaign Difficulty selection dialog to GUI2, as part of the changes for Wesnoth 1.9.3. Although It was rather simple to implement, I had to refactor out from the in-game character dialog ([message]) window some code to parse the legacy GUI1 menu items markup, which is now possible to combine with Pango to achieve funky effects in the difficulty menu like what After the Storm already managed with GUI1, and more.
As a result, both the campaigns menu and the difficulty menu consistently use the same toolkit now and there’s even less remaining to be done to discontinue the usage of legacy widgets:
The whole gamemap view and the surrounding UI still use GUI1 elements, as do context and main menus in the game.
Every dialog with unit previews (debug-create, unit list, recruit, recall, load game, level-up) still needs to be converted to GUI2. There are experimental versions of the Load/save game and Debug-create dialogs in development since a while ago and they can be previewed with the --new-widgets command-line option.
The whole help system and the Credits screen accessible from the main menu still need to be converted.
Story screens don’t use GUI2 yet but they do use Pango for rendering text on the title and body regions.
The game preferences, hotkey configuration/input and network progress dialogs still use GUI1.
The add-ons manager (install/update) dialog needs to be remade in GUI2 as soon as possible in order to address the many usability complaints found in the Ideas forum.
The End-of-game and loading screens still use what I like to call “GUI0”, a widget-less presentation format that uses the legacy SDL_ttf-based text rendering code.
The game status and statistics windows.
The multiplayer game setup and waiting screens also need to be converted to GUI2, although an experimental/WIP version of the former is already available.
Floating text labels in the game still need to be converted to use Pango instead of SDL_ttf.
Despite the possibly incomplete but long list above, we are much closer to having a consistent game UI that can be later updated and polished as necessary without the involvement of ugly and hard to maintain hacks. Eleazar and West already have some cool ideas which would be nice to implement in the near future.
Frequent visitors of the Scenario & Campaign Development Forum at Wesnoth.org’s board may have noticed that there’s a release announcement for After the Storm version 0.3, which is available at the official 1.9.x add-ons server and at SourceForge.net thanks to the Wesnoth-UMC-Dev Project.
I’m certain at this point that I can’t promise regular updates, but I’m trying to resurrect this project after a long period of inactivity that unfortunately followed the ceasing of development on its predecessor Invasion from the Unknown.
The truth is, I have been busy with all sorts of stuff this year — as a result, AtS has had to endure some parental abandonment. Although things aren’t becoming much easier for me in the following weeks, I hope to be able to finish episode I by next February, if not earlier.
As for IftU, I may resurrect it for 1.9.x if my time and creativity allows. Some convenient conversions of WML code to Lua are already done in SVN trunk, and at least the first scenario works, but more testing is required. In any case it’s unlikely to see the sunlight again until some more drastic (non-technical) changes I have planned become possible.
