The Rise of Wesnoth for Android

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!

This really makes me want to get an Android-based smartphone now! If only such a thing could fit in my budget…

Automatic rebasing of master for Frogatto Git

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.

Heaps and heaps of Ideas

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.

Yeah, I know:

Q: Why doesn’t Wesnoth have my favorite feature?

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.

Firefox is dead, long live Firefox

You finally, really did it.

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.

The dilemma of the Linux laptop buyer

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.

Whether GPUs in Optimus configurations can be made to work on Linux without resorting to unsupported mechanisms appears to depend quite a bit on the computer model — for the larger unfortunate crowd there’s Bumblebee, which may have achieved memetic status due to an unfortunate typo in the installation script (not even the software proper!).

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.

Firefox 6 beta

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.

Firefox 7 in Aurora channel, however...

… Where’s Firefox 6 beta?

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.

Wesnoth-UMC-Dev: A Retrospective

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.

Continue reading “Wesnoth-UMC-Dev: A Retrospective