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.
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.
A few days ago I got bored and decided to give the Wesnoth GUI2 transition, as described in this post a bit of help. In consequence, all of the following dialogs in Wesnoth trunk, after the release of version 1.9.2, have been converted to GUI2 and should be able to display languages such as English (Shavian alphabet) correctly.
Every confirmation dialog in the game with exception of the add-ons dependencies resolution window (revisions 47443, 47445, 47446, 47447, 47448, 47450, 47451, 47509.)
The gamemap labels editor dialog (revision 47482.)
Four list-type dialogs:
Selection of the next scenario with the :cl debug command (r47463)
Display resolution list in Preferences (r47469)
Theme selection in Preferences (r47472)
List of installed add-ons for removal (r47467)
This should be considered yet another step forward for GUI2 and the Pango-based text rendering in trunk, bringing us a tad closer to the much awaited… Wesnoth 1.10 release. 😉
Long ago, Jetrel from the Battle for Wesnoth Project contacted me regarding possible extensions to the image path functors module of the game engine.
One of those extensions, which I implemented just in time for Wesnoth 1.6, and later gave it a separate syntax of its own was palette-switching using the same secondary algorithm used by the game’s color range-based team-coloring code. The ~PAL() functor, originally implemented as an extension to ~RC(), was thus born.
Wesnoth RCX 0.2 is not out yet due to some heavy refactoring that’s in progress, but a major feature that it’s going to sport in this opportunity is the ability to define custom color ranges and palettes.
The aforementioned extension to the game engine, which I shortly merged into the command-line based Wesnoth-TC tool, was originated by a possibility Jetrel discussed with me on IRC, namely randomizing individual units’ hair colors (and other compatible traits) on recruit. This sure doesn’t sound like a major task from the C++ side, and in fact the only thing missing right now is a transparent mechanism for defining these variations in [unit_type] nodes. However, it involves heavy revisions in the art department, to clear any traces of paintbrush strokes and sprites using excessive shades of a single color.
The goal: defining strict palette sets for recoloring. Above: Jetrel’s WIP revised baseframes for some of the elves.
Since trying artwork transforms like this in the game can easily become a tedious task (and not just because of the WML coding), Wesnoth RCX is soon going to step forward and provide artists with the ability to try out their own color ranges and palette sets and tweak them as required until achieving the wanted result. I hope that Wesnoth RCX will not just become the artists’ favorite tool, but more like an essential item for the mainline art development workflow.
Another couple of features are also going to feature in 0.2: zooming (suggested by artisticdude in the forums), and compete drag-n-drop support, so users can drag the transformed image into their favorite image editing application for further tinkering. I’m sure Mac users will especially like this new addition. 😉
Some may recall that during my review of Wesnoth 0.1 I found a mysterious package inside the 0.1 distribution named strategy-source.tar. On closer inspection, the contents turned out to predate the sources of the first version of Wesnoth released to the general public by at least four days. However, I didn’t try to compile or run the mysterious application in that opportunity.
We are now going to take a route back in time to codename “Strategy”, which is a prototype version of the same engine powering Wesnoth 0.1. For readability purposes, we’re going to dub it Wesnoth-00 and proceed with the review.
