Wesnoth.org appears to have DNS issues at the moment, resulting in the site’s address being impossible to resolve to a numeric address (IP) for most people. We are doing everything that’s possible at the moment to restore it.
UPDATE: Apparently, it’s been solved already. However, the new records could still take some time for some people to have an effect due to DNS caching.
UPDATE 2: My own evidence indicates that it’s not solved yet.
UPDATE 3 (Oct. 3rd): It’s solved now. Some DNS servers could still claim wesnoth.org doesn’t exist, so just give them a few more hours.
If you trust me (since I’m the forum administrator and all), you can follow these simple instructions to fix your access to Wesnoth.org’s services in the meantime. If you don’t feel comfortable editing system files or don’t have admin access, you can try connecting directly to Wesnoth.org’s current IP, 65.18.193.12, but this will not work correctly with the wiki and forums which use the wiki. and forums. subdomains.
Do note that what I describe should be considered a temporary workaround. If Wesnoth.org’s IP changes in the future, you’ll need to remove any hosts file entries you added.
Linux, BSD derivatives
Note: make sure to backup your /etc/hosts file first in case you accidentally delete its previous contents, which could cause some applications to behave incorrectly.
Edit the file /etc/hosts with a plain text editor such as gnome-editor, Kwrite/Kate, vi/vim, Emacs, and such.
An alternative is just issuing the following command as administrator. Notice that it uses >> instead of the usual > in order to append rather than replace the file!
Edit or create the file C:\WINDOWS\System32\Drivers\etc\hosts with a plain text editor such as Notepad (replace C:\WINDOWS with the correct installation path of your OS if necessary.
Unfortunately, I have no idea about Mac OS X since I’ve never had an Apple computer. If anyone knows more than I do, feel free to post a comment explaining the steps.
After a record break of 6 months I got back to work on scenario 9 of After the Storm and completed it, in a fairly different fashion than I originally planed. Still, it’s another step towards completion of Episode I. Version 0.4.0 is available for download now in the 1.9.x add-ons server and SourceForge.net.
I think I have avoided to spread many spoilers about AtS’ plot since day zero; there were, of course, some early storyboards circulating around the forums and IRC at the beginning, but as I’ve been saying for quite a while, they are no longer canon and I am departing from the original plan on purpose.
I am fully aware that some people will not like my choices in 0.4.0, and they may even seem blasphemous, but the truth is I scattered enough foreshadowing everywhere to prepare them for the time being. What are these choices I speak of, anyway? Too bad, you’ll have to play the campaign to find out!
When I prepared the final draft of the October 2010 revision of the Wesnoth.org Forums Posting Guidelines, I deliberately skipped clarifying a specific point regarding posting rate conducts, more specifically, point 1f, in order to see what the community would make out of it.
That’s not to say I didn’t alter it in any way whatsoever since the previous revision, which was basically a left-over of Turuk’s administration:
Before:
Think and Read.
Read the entire thread before you post. And when you post, explain your reasons. Nonsense may be deleted without warning, especially in a working topic. Posting the same thing after it has been deleted will get you a warning. Doing it again will get you a ban.
No Spamming.
Post a single idea/question/comment in only one forum. Do not double post, edit your previous post if you have something new to add but no one has posted yet.
After:
No spamming — think and read
Post a single idea/question/comment in only one forum. Do not double post, and instead edit your previous post if you have something new to add and no one has posted yet. Technical support requests may be bumped after a while in case they have been forgotten and sink past the first forum view page. Read the entire thread before replying to it. Nonsense may be deleted without warning, especially in a working topic.
I introduced the support requests bit with the intention of giving users in the support forums (Technical Support, Release Announcements, Compiling & Installation; WML Workshop, Coder’s Corner, Lua Labs, Scenario & Campaign Development) special protection as bumping topics in there is usually a legitimate and reasonable course of action. But in reality, there are other cases where bumping by means of double-posting should be allowed. Those are not described or explained in the Guidelines because I felt that elaborating on a specific point would derail the whole post.
One of those cases applies to campaign development topics, where the OP may post the announcement for a new version of the campaign and only a few hours later find himself or herself in need of another announcement because of a quick update fixing some important bug.
Another case, more technical than practical, is the maximum number of attachments per post, which exists to discourage and limit senseless spamming of unwanted content by automated and non-automated agents, and encourage use of compressed containers like tarballs, zip files and rar archives to keep our overall disk usage relatively low. Users exceeding the attachment limit will need to continue posting their content in consecutive posts.
Generally speaking, users reporting double/multiple posting according to section 5 of the Guidelines have enough common sense to understandhat sometimes exceptions need to be granted and that this is one of the reasons we don’t call them the “Forum Rules”. Rent-a-modders occasionally lack this common sense, however, and they make their intentions evident through this mechanism. I imagine one can never be too anvilicious while reminding them what this entails.
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!
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.
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.)
I’m not exactly the resident usability expert in the Wesnoth development team (multiple people have claimed that title under dubious circumstances before) but I believe I can recognize a design issue when it’s in front of me.
The issue in question is the game’s Preferences dialog. Over time it has accumulated needless cruft in the form of options that no-one should ever need to use, which are nevertheless offered to the player under the Advanced Preferences section. Funnily enough, the programmatic design of this area lends itself to random developers and patch contributors senselessly throwing crap into it; this is the only piece of user-visible configuration that can be defined almost entirely in WML, requiring only a couple of accessor functions in the C++ side for whatever module needs to query or set those options at runtime. In the “best” case, just a single getter suffices.
Of course, Preferences is built upon the previous Wesnothian GUI toolkit jokingly referred to as “GUI1”. Despite what some people may say, it’s far from ideal to work with hardcoded widget locations and an inflexible rendering scheme. As new options have been added to the game, developers have preferred to do things the lazy way and abuse Advanced, leading to arguably essential entries getting clobbered in middle of the rubble.
Naturally, I tried to tell people about this problem. But since it’s been nearly a week and I’ve not gotten reactions of any kind, I decided to start chopping trees.
→
The main thing here is that the Enable scroll tracking of unit actions and Reverse Time Graphics options were moved to Advanced, and in their stead I brought Show Unit Standing Animations and Animate Map, and messed around with some spacing.
With Wesnoth 1.9/1.10 boasting a plethora of standing unit animations and animated terrains, a performance drop is to be expected on low-end machines — or even high-end as well, depending on what other processes are running in the background and local factors such as map size, amount of visible units and possible targets during AI turns. Increasing the visibility of performance impacting options makes a lot of sense if it will result in less complaints. 😉
→
If one looks hard enough, it’s always possible to find other details to nitpick. A little patch went into 1.9.7 to add some indentation and change font sizes for slider labels in Preferences that were associated to checkboxes, but I preferred to leave the follow-up for 1.9.8 — the Sound tab sliders had some overly verbose labels that truly only served to give translators three extra strings to manage.
That said, Preferences still glitches at the bottom on the minimum resolution of 800x480 pixels. The effect can be seen here on the Close button itself. I don’t think I’m able or particularly interested to tame this beast, however, so fixing it may have to wait for the GUI2 redo of the dialog. Meanwhile, OpenPandora users will have to do with this minor inconvenience.
• • •
I should note that my original plan was to completely scrap the Reverse Time Graphics option. After doing some research, I discovered that ESR did it once, and that it got reverted the next day by alink. The rationale? I’m not sure, but the IRC logs are quite entertaining.
