The Ideas section in the Battle for Wesnoth forums is in very bad shape right now, and despite the efforts of my trusty moderators, the root of the problem lies far beyond our ability to lock topics.
I won’t mention any names for obvious reasons, but a major behind-the-scenes administrative role in the Battle for Wesnoth Project (hint: it’s not Noy, it’s not Dave, it’s not me) once described several board sections including the aforementioned as “a place where all the noise can go to so that it does not hinder us too much”. This is not just one individual’s opinion and it shows; even when I was a user back in 2006 I always felt Ideas tended to be left aside by the development team.
Because we are building this game for ourselves, to suit our own preferences. We’re not building the game for you, in large part because this is our hobby, not our job; whether you like it or not is immaterial to us. You may wonder, then, what the point is of soliciting ideas, as we do on the forum. We, the developers, have certainly come up with many good ideas on our own, but our players often do as well, and generally ones we don’t think of ourselves. If a player comes up with an idea we like, we might implement it. Not because they asked for it, but because of its own merits as an addition to our game. […]
Of course, the extent to which a bunch of key developers can come up with ideas when they don’t even regularly play the game proper is debatable. The other side of the coin shows that users don’t really come up with good ideas most of the time. Most Ideas topics fall into one of the following categories:
Frequently Proposed Ideas (FPIs) — which go in the opposite direction of Wesnoth’s development
Good ideas that can’t be immediately implemented (BWH, from “been suggested before, we think it’s a good idea, hope to add it eventually”)
User interface ideas (usually overlaps with BWH)
Add-on and multiplayer server ideas (ditto)
FPIs can be easily handled by moderators following a few simple guidelines and the bulk of locked threads in Ideas correspond to these. The problem is that BWH entries are not correctly classified anywhere — not even Feature Requests in the Gna.org bug tracker are properly monitored and occasionally completely ridiculous entries get added there; others are forgotten and implemented by other people on their own without referencing the existing open issue(s), and there’s also a swamp of outdated issues that may no longer apply to trunk.
BWHs are also quite sad to handle because, let’s accept it, most game players have no coding skills and won’t mess with the source to contribute C++ or Lua code back to the game, no matter how prominently advertised the open source nature of Wesnoth might be. The Forum Moderators are deliberately picked up from the non-technical bunch so they don’t get overloaded with responsibilities, something that’s happened before and has resulted in a degradation of the forums’ service quality.
User interface ideas are an even worse terrain because Wesnoth’s GUI development has been largely stuck since 2008 with Mordante/SkeletonCrew’s new internal toolkit, GUI2. Pretty much no groundbreaking changes can be done until GUI2 is mature enough to support all the old features. It’s not very hard to create a campaign scenario with an absurdly long Objectives entry and watch the ensuing rendering mess — that’s just one example of how GUI2 is still inferior to the less flexible old toolkit in some ways.
GUI is also a tough matter because it’s easy for a single user or Wesnoth developer to propose an interface for some task, implement it, and later find out that most of the other users or developers don’t “get it” — this is an issue inherent to user interface design, of course.
Add-on and multiplayer server ideas are very hard to implement because they tend to require not just changes to the server and client code to suit our needs, but they also often involve new GUI elements, resulting in an overlap with both the GUI category, which in turn overlaps with BWH.
Gambit and I tried for a while to make people use topic icons in Ideas to mark BWH entries and the rare issues that get finally solved in trunk. This doesn’t work very well because other developers either don’t watch Ideas thanks to the predominance of posts in any of the categories described above, or don’t watch the forums at all.
I usually try to be optimistic about things, but I really feel like we core developers are alienating our own user base with this apparent lack of interest for communication. Don’t even get me started on the “new lobby” fiasco in version 1.8.0.
Thanks to a Wesnoth user (you know who you are!) who bought an order of the Humble Indie Bundle #3 for me last Tuesday, I finally had the chance to try the popular in-development Minecraft, thanks to the included trial that lasts until this Sunday 14th.
It’s not entirely unexpected for me, but it’s the kind of news one hopes to never find in his front door, like a car-bomb if you will. If this goes ahead I can imagine that less and less time and human and economic resources will be spent on the Mozilla Firefox proper for the PC, once B2G catches the OEMs’ attention.
I guess it’s time for me to accept (again) that Firefox has ultimately become the open-source Internet Explorer.
Bluecore is back, but this wasn’t necessarily good news for me. The current situation is a bit complicated, but it can be summed up like this: my father (who supposedly gave me rather than lent Reicore) wants a laptop again, and so do I. He doesn’t need graphics or CPU power, but I do. Right now, Reicore barely fits the bill even if it works better than Bluecore in practice thanks to the extra 100 Hz of clock frequency and not suffering from Bluecore’s mysteriously subnormal I/O performance.
The most optimal solution for us is that we buy a new laptop for me and I return Reicore to its original owner. The only problem with this is that I have even more special needs: I have to run Linux.
And I have a goal: I want to own a piece of NVIDIA hardware.
While I could easily buy the components to build a new desktop machine with the same money, this would not be a good investment now that I’m primarily a laptop user. My poor desktop machine, Blackcore is suspected of having an unstable PSU and may have more internal components damaged than it’s healthy for an expensive graphics card — until now Blackcore has been running with its utterly shitty (even on Windows) VIA Unichrome Pro IGP.
For the purpose of saving electric power while on batteries (or not, global warming and all that crap) computer hardware engineers have come up with hybrid configurations in which there’s a low-power IGP serving as front-end for a beefier discrete GPU that activates whenever it’s deemed to be required for heavy tasks. NVIDIA calls this “Optimus.”
NVIDIA Optimus is not officially supported in Linux, and won’t be, at least for a while.
Unsupported solutions with NVIDIA sound very risky to me (temporary /usr bomb aside) after witnessing the possibilities of supported ones with AMD/ATI. Besides, it seems that to get Optimus to work with Bumblebee it’s necessary to use a wrapper for pretty much every application one wants to use. That isn’t bad per se, however I’m not sure I’ll be able to boast about running Linux and Windows/Wine games like that.
NVIDIA’s official statement on the matter makes me think of their leaders as vile and smug sadists who look down on poor mobile Linux users who pay for their shit. I personally don’t feel so keen on purchasing hardware made by people like that, but it’s a well known fact that NVIDIA basically owns the consumer graphics market nowadays, truly rivaled only by AMD.
Yet, I’m not sure I want to buy laptops with AMD ATI GPUs again after all that I went through with Bluecore’s Radeon HD 3200 on Linux.
And here it is, at last. Just like the last time, the new version migrates from Aurora to Beta on Tuesday but it isn’t offered via the update channels until the next Friday, while the newer ex-Nightly is published in Aurora in the meantime.
I still think this is unnecessarily awkward for users who are interested in one specific Firefox version, or who want to avoid disabling incompatible add-ons as much as possible.
Supposedly, Firefox 6 entered the beta channel on July 5, yet there’s no signs of it in the Mozilla FTP server or in the website proper.
With Firefox 7 entering Aurora now, I’m in a slightly uncomfortable position because I hoped to continue tracking version 6 once it moved to beta — now I’m using an old version 6 snapshot from Aurora hoping that the beta will be packaged and announced soon.
It seems somewhat inconsistent from my standpoint to let Aurora be replaced by a newer version before the previous Aurora is properly promoted to Beta.
Interestingly, the same situation appears to have occurred with the announcement of Firefox 5 beta in May, the difference being that I didn’t particularly mind because it was in preparation for the first official release after Firefox 4 and the decision to switch to a rapid release schedule, so a little schedule slip was to be expected for an initial deployment.
Today, after Wesnoth-UMC-Dev reached its most important milestone, I have decided to step down from the project administrator position to leave the decision making and user support tasks to Espreon and AI0867, who have done an undeniably good job in my absence the last year while I was busy working on other projects.
This does not mean that I’m completely breaking my ties with this exciting platform for add-on development which ESR and I founded. I’ll continue to take care of infrastructure matters such as the website design, content and coding, the Registry tools and miscellaneous utilities whenever I have time; I’m not going to abandon After the Storm either, since I continue to be a user of the project either way.
I mentioned that I’d be following up the official r10000 announcement with the history of the Wesnoth-UMC-Dev Project. Most of the content below is taken from an interview I recently had with BfWEthnographer which eventually touched this subject.
The Coordinated Wesnoth User Made Content Development Project, better known as Wesnoth-UMC-Dev, has today reached SVN revision 10,000. Here’s the official announcement.
I’ll soon post details about the project’s history here.
While searching for examples of translated generic unit names from data/core/macros/names.cfg in Wesnoth (much to my disappointment, the Japanese translation uses the source strings verbatim for this), I discovered an oddly familiar name amongst the female Elvish names for the markovian generator.
Anylindë.
Back in 2007/2008, I was pretty much forced by Syntax_Error to change the name of one of the main characters in Invasion from the Unknown. Why? Because her name was Analia — never mind that female human units named “Bra” occur quite often in the game thanks to the RNG’s influence over the name generation algorithm.
So I consulted ESR, who came up with Anlindë as a possible replacement. I never noticed before that it was just one letter away from being a generic unit name. Then again, Galas and Elynia were my own design choice and they are, indeed, part of the name generator sources — I had gotten so frustrated at the design phase that I took a random generic name for Galas and the first feminine-sounding name starting with ‘E’ for Elynia.
Furthermore, I also took Analia from names.cfg and it’s still there. No overzealous purists have complained so far.
Would IftU have been a better campaign if I had used custom names for these three characters? Maybe, by a marginal difference. On the other hand, the one time a recruited elf with the name Elynia appeared during gameplay (that one Sprite I got in IftU doesn’t count), I protected her until the end the second-to-last scenario of HttT — by then she was a veteran Elvish Shyde.
Since I’ve not felt particularly inspired to finish the last two parts of my review of the Under the Burning Suns campaign’s post-quartex (1.3.x - 1.9.x) development history, I suppose I may as well bother my loyal readers with yet another useless report on GUI2 dialog conversions in Wesnoth trunk.<
Okay. I lied. The screenshot above does not come from Wesnoth trunk, but from its fork in a private branch in my local git-svn repository. The component in question is evidently the File Chooser dialog, which is used in the map editor for locating files to open or save, and in the Preferences dialog (and more rarely in the MP menu) for finding the wesnothd or wesnothd.exe MP server binary used to host LAN games.>
I figured that converting the File Chooser to GUI2 will help stomp a few bugs with files whose names look like the obsolete, so-called “WML markup”, and generally make it easier for people to improve it. Once I have reimplemented the current functionality I may look into adding some kind of bookmarks system, or at the very least shortcuts for jumping to directories that are commonly used by both mainline developers and UMC authors.
All this rewriting may also introduce new bugs, of course; hence I’ve not pushed these changes to trunk, even though they are already guarded by the --new-widgets command line switch. I have not pushed them to a public SVN branch either because local Git branches make it much easier to rebase commits against trunk as time goes on.
In the process I found myself in need of converting the New Folder dialog to GUI2 for consistency. Given the sheer size of the C++ code added in the process, I am pretty sure this won’t inconvenience anybody for now — hence I pushed this changeset directly to trunk instead.
(And yes, it should be “New Directory”. I am going to hate myself for the rest of my life for keeping the legacy “user-friendly” terminology that was already in place.)
