Now working on drag-and-drop support for Wesnoth RCX. Dropping image files and actual image data already works with some simple and quickly crafted code thanks to Qt4’s power and simplicity. The next logical step is enabling RCX to drag the original and generated image data to other applications.
After that, RCX 0.1.2!
A new revision of codename “Morning Star” is available, this time with a preliminary production name — meet Wesnoth RCX 0.1.1.
bdb9c31e6e43ca1bf985e1e4d390d96dbab19e1a
The main changes in this version include fixing the glitches with dragging the selection in the color ranges list view, making the window resizable again (this time the contents adjust to its size), and a few minor revisions here and there.
Since I’ve got no packagers to help at the moment, the only way to install for now is from source. Since I’ve been working only with Qt Creator so far, there’s no specific build recipe other than the project file (morningstar.pro), which you are expected to use to generate a Makefile using QMake.
To do this, just make sure you have Qt4’s development files and QMake installed (package qt4-qmake on Debian and Ubuntu), and type the command as follows:
$ qmake morningstar.pro
Note: If you have Qt3’s version of QMake installed, you may have to explicitly use qmake-qt4 instead to avoid confusing the generator and messing up the sources.
Once QMake generates the Makefile, just issue make and wait for compilation to finish. The binary morningstar will appear in the source dir, and you can now run it from there — no installation is required.
There’s also a Git repository hosted at Gitorious.org, from which you can download the latest source code, follow the history, and switch releases according to tags.
git clone git://gitorious.org/wesnoth-tc/morningstar.gitgit clone http://git.gitorious.org/wesnoth-tc/morningstar.gitDon’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!
UPDATE (2010-12-06): migrated files to SourceForge.net
With the intention of documenting the oldest Battle for Wesnoth development releases from the 0.x line, I started the Wesnoth Evolution series, which so far comprises the following articles, in chronological order:
It’s been a long time, but I have decided to stop procrastinating and fire the time machine again to take a look at Wesnoth 0.1’s immediate successor, version 0.2. This is just the beginning of an amazing journey which, with luck, time and patience, will lead us back to Wesnoth 1.8 from the perspective of a long-time player, UMC author and mainline developer.
As in the last installment, I’ll use a cross-compiled (Mingw32) version of Wesnoth 0.2 for Windows on Linux/Wine. The distribution's contents timestamp is 2003-07-13 09:31 UTC. Both this distribution and 0.1's include many hidden .swp files (vi/vim temporary working files) so it’d seem Dave packaged 0.2 in middle of coding work.
UPDATE: the bugs in 0.1.0 were so annoying I uploaded a fixed version 0.1.0.1 shortly afterwards. Enjoy!
At last, the first working version of codename “Morning Star” is available — this is the new Qt4 GUI for team-colorization and palette switching for Wesnoth sprites.
After a day or so of working on it, distributed amongst 4 days, version 0.1.0 is now ready for downloading from this very site for testing purposes, although it should be usable for production from now on as well. Just don’t blame me if it eats your precious input.
132d326d265b61ae7441a599f7dc10537c13bc8eIn all seriousness though, I want this application to become usable by the general audience after reaching version 1.0. Artists are naturally the intended target audience, although users who just want to recolor Wesnoth sprites to use as their forum avatar may also find a use in this tool. 😉 However, to achieve this, I need your feedback. Please try Morning Star out, report bugs, suggest features (within the scope of the project’s goal), and if you think you can help with anything else, tell me!
Don’t forget that Morning Star is also in need of a definitive name!
Since I’ve got no packagers to help at the moment, the only way to install for now is from source. Since I’ve been working only with Qt Creator so far, there’s no specific build recipe other than the project file (morningstar.pro), which you are expected to use to generate a Makefile using QMake.
To do this, just make sure you have Qt4’s development files and QMake installed (package qt4-qmake on Debian and Ubuntu), and type the command as follows:
$ qmake morningstar.pro
Note: If you have Qt3’s version of QMake installed, you may have to explicitly use qmake-qt4 instead to avoid confusing the generator and messing up the sources.
Once QMake generates the Makefile, just issue make and wait for compilation to finish. The binary morningstar will appear in the source dir, and you can now run it from there — no installation is required.
There’s also a Git repository hosted at Gitorious.org, from which you can download the latest source code, follow the history, and switch releases according to tags.
git clone git://gitorious.org/wesnoth-tc/morningstar.gitgit clone http://git.gitorious.org/wesnoth-tc/morningstar.git*Note: most of these issues have been fixed in version 0.1.0.1, uploaded around an hour after 0.1.0 for your convenience.
UPDATE (2010-12-06): migrated files to SourceForge.net
After a burst of inspiration, I managed to finish implementing Morning Star’s most basic functionality: recoloring images!
Thanks to Qt4’s awesome high-level interface to images (using QImage objects), the recoloring logic turned out to be much shorter and easier to understand than Wesnoth-TC’s, which had to deal with libpng and all the storage format details with PNG files. Instead, Morning Star just needs to care about reading, comparing and writing 32-bit ARGB values.
The interface design is pretty much set in stone now for version 1.0, but there’s still a lot of functionality missing. Nonetheless, this is starting to look good and I should have a working version for releasing to the public very soon. Hopefully this time artists will like this tool.
My collaborators know well that I often refer to Mozilla’s current flagship browser as “Failfox”. Many have read what I’ve got to say about several versions of Mozilla Firefox before. A few also know my stance on the foundation’s trademark policies and their sole existence.
Yet I can’t bring myself to hate this awesome browser that’s still superior to Google Chrome in user interface design as far as I am concerned.
After switching to Iceweasel/Firefox 3.6 from Debian experimental a couple of months ago — after learning of its status at the website of one of the maintainers — I have had a pleasing and stable experience with Firefox that I’d not had since 3.0 was released. Now I’m also beta-testing Firefox 4 for Windows on my XP SP3 virtual machine, and awaiting the future stable release.
I thought I’d clarify this for those who might have thought I was yet another Firefox-hater, based on my previous rants. Of course, it’s a bit jarring that it took Mozilla and/or Debian so long to stabilize Firefox on amd64 systems, but I guess you can’t ask for more — it mostly is, after all, a volunteer-driven effort, and amd64 builds had not appeared before in the official FTP server until the Firefox 4 betas, for some reason.
Thanks to the power of Qt4, my long-delayed sister project to Wesnoth-TC, codenamed “Morning Star”, is finally commencing to materialize.
While I’m progressing slowly on this as always, partly due to my parallel work on Rei 2 IRC bot, this project is very likely to get completed soon thanks to Qt Creator, an awesome IDE designed for the development of Qt4-based software applications — with a familiar feel akin to Microsoft Visual Studio, which was incidentally involved in my early learning process with C#.
Morning Star is not a front-end to Wesnoth-TC as I initially planned. Instead, it is a whole new application built upon the same logic which will be oriented to the general audience so that artists can take advantage of its preview features, and even export recolored images, all without the need to use a command prompt, which is the main limitation of Wesnoth-TC right now. 😉
I have not decided upon a name for Morning Star, so if anyone can propose an adequate formal name for this project, I’d appreciate suggestions.
The Battle for Wesnoth forums have been working since quite a while as an authentication source for Multiplayer server users, who can register forum accounts to claim ownership of a username, making it unavailable in MP except to people who can provide the correct login credentials. phpBB 3.0.x, however, doesn’t help a lot in regards to user registration rules since it supports more stuff in usernames than what wesnothd (the Wesnoth MP server software) does.
To fill this gap, I wrote a quick hack long time ago, and enabled it in the forums, forbidding further registrations of incompatible usernames. Nowadays, all new accounts must comply with some simple rules which my mod implements.
Only this night I bothered to actually MODX-ify the hack, which had been previously circulating in the form of a Git commit in my source tree. Now I present to you the Wesnothd Usernames mod for phpBB 3.0.7-pl1.
1229f401eeac171887cfee8c0ccecd9aaa19dd4aThis might be useful only to very few people since the whole phpBB authentication support code is barely documented — but if you find a use for this mod in your phpBB+wesnothd installation, please feel free to drop me a comment so I can know your experience and fix any bugs that you may find. Of course, it’s unlikely that there are any bugs here since this modifications has been part of the official Wesnoth.org forums for more than a year. 😉
It’s a tradition for the Battle for Wesnoth community to explain what our software version numbers mean to newcomers, since these often ask what’s the difference between the stable series, and the development series, and what happens when a new stable version is defined.
A simple answer addressing the difference between odd/even minor version numbers (i.e. Y in X.Y.Z) has usually sufficed, but now that we are producing releases for the 1.9 development series, misconceptions about the next major series (2.x) spread like the plague. I wrote clarification post a couple of months ago, on the numbering scheme — since it’s getting lost in the depths of the Users’ Forum archive, I'll replicate it here for the few anonymous people who read this.
I’m also going to explain what’s the deal with this magic “2.0” version number, although that part is going to be a lot more subjective — in other words, I’ll address that subject from my own point of view instead of the development team’s.
Continue reading “On Wesnoth's version numbering scheme, and Wesnoth 2.0”
After some hesitation, I have deployed Prosilver Special Edition on the Wesnoth.org forums, with multiple changes meant to make it more similar to mainline Prosilver in terms of layout. Wesnoth’s custom Prosilver changes have also been applied on our copy of Prosilver SE.
In fact, Prosilver SE as used in Wesnoth.org depends completely on the main Prosilver template rather than its own partial template set, and it also replaces the default Prosilver theme/stylesheets and imagesets, since otherwise very few people would choose to use it. Besides, OAB.
Of course, further changes are not unlikely to occur, depending both on the users’ feedback and my own testing experiences.