Ykkrosh

I think you might be able to solve it with sudo apt-get install libmozjs-dev Otherwise, you do have to follow those "Installing thread-safe SpiderMonkey" instructions (it's still necessary with the current version of the game).

You could try PlayDeb.

Hmm, the build.sh doesn't work for me at all (I get "ld: unrecognized option '-Wl,-R/usr/lib/nspr'", because "nspr-config --libs" says "-Wl,-R/usr/lib/nspr -L/usr/lib/nspr -lplds4 -lplc4 -lnspr4 -lpthread -ldl"). So I guess the bundled SpiderMonkey should be considered experimental, i.e. probably broken Those PR_* errors come from failing to link correctly with nspr. What output do you get when running "nspr-config --cflags" and "nspr-config --libs"?

Hmm, maybe the game thread is still running but the UI thread is frozen? (Judging by the screenshot, it seems to have stopped somewhere in the middle of loading the UI.) (I don't have the game installed on OS X myself, and I'd prefer not to go to all the effort of doing so, and I know nothing about OS X development, so I'd be very happy if someone else had time and patience and a debugger and sorted out the problems in my code )

Hmm, sounds like some kind of DNS issue... A few things to try: Can you open http://svn.wildfiregames.com/public/ps/trunk in a web browser? Are you connecting to the internet through some kind of proxy? What OS are you using? If you can run "ping svn.wildfiregames.com", does it give some kind of error message or does it work and give a proper IP address? Does it work if you wait a while and try again?

As far as I'm aware, it has never worked correctly under OS X. If it freezes, can you find where it's freezing? (probably by running in gdb, using ctrl+c to interrupt it when it's frozen, then using bt, and being careful to look in the right thread since it has one for UI and one for the game engine (and the engine has some others for random bits and pieces))

I don't think that attitude is really necessary. There's a lot of information in the build instructions, not all organised perfectly, and it's easy to miss bits or make mistakes. It's also possible that the instructions are just wrong, or there's a bug in the code. The forums are (at least partly) here to help people with this kind of problem

Did you run "svn up" in the snapshot trunk directory after extracting it? (There have been some changes to the build system since that snapshot.)

Could be related to #235 - starting more than one game is, uh, not a supported feature . I guess someone just needs to test it and fix all the problems, but it doesn't seem like a high priority at the moment.

It might be good to be clearer about which documents are sufficiently stable and useful to be translated. E.g. the OS page is very stable (it's more of a press release, not a continually current description of the game, so it shouldn't ever change (unless any serious errors are found)) and is useful as an introduction to the game and the open sourcing. On the other hand, the build instructions page is not at all stable (we'll often make technical changes during development), and an outdated translation is worse than useless (since it'll lead people into build errors), and we won't be able to keep translations updated, so I think it shouldn't be translated at all. Other pages fall in different places on that scale. It's hard enough getting the English documentation written and updated at all, so anything that makes that harder (i.e. requiring more manual effort from whoever is writing or updating it) isn't acceptable. But automatic tools (e.g. Trac's wiki page history and diffs) might help a lot, so we should work out how to use those appropriately.

Looks good I've removed those LibXML directories from SVN in r7035 (and updated the Windows build to not use them), so hopefully it will work a bit more automatically.

Added that to the wiki now - thanks! There were a few known problems with that on 64-bit systems - I've tried to fix them now, so hopefully you shouldn't get any of those warnings if you update and recompile.

If you delete (or rename) libraries/fcollada/src/FCollada/LibXML and libraries/fcollada/include/LibXML, then recompile FCollada, then compile the game, it ought to pick up the system library correctly. (It fails on OS X and not on Linux because OS X typically has a case-insensitive filesystem, so it uses the LibXML directory instead of libxml.)

My /usr/include/libxml2/libxml/tree.h (from libxml2 2.7.3) says xmlDocDumpFormatMemory (xmlDocPtr cur, xmlChar **mem, int *size, int format);so I think this change will cause errors if int != intptr_t (i.e. on 64-bit systems) with that version of libxml2. Older versions (e.g. 2.6.30) seem to use "int *size" too. Where is the intptr_t* coming from? (Edit: Oops, took too long to reply and terato beat me.) Edit again: Oh, this is probably because OS X is using FCollada's LibXML directory instead of the system library, and we copied FCollada 3.05B's code which introduced this intptr_t patch for some unknown reason. This should be fixed on OS X by using the system libxml2 instead of FCollada's copy. (Not sure what should be done on Windows). I've reverted janwas's patch now, since it's not the right solution.

Sounds like you need to install Boost onto your system, e.g. with "apt-get install libboost-dev" or something similar depending on what Linux distribution you use. If you don't have a /usr/include/boost, then that's probably the problem. (It's also possible that Boost is just installed into a strange location. If you've already got it installed and still have problems, what Linux distro/version are you using?)

Fixed now. Oh, crumbs. That's because I had tried to be clever with wrapping text around the logo tightly, then someone pointed out that it was preventing them clicking links in text that was behind the logo image, so I raised the z-ordering of the text to fix that, and didn't realise it was now raised higher than the screenshots. (And it worked fine in Opera 9.6 anyway, and I didn't test much in Firefox). Anyway, fixed now - thanks for finding this The closing tags are entirely optional in HTML - the page is perfectly valid . (The <body>, <head> etc tags are optional too, and I like to be minimalist and omit them.)

Hmm, I would be reluctant to add any automatic language-based content negotiation (unless someone convinces me otherwise ). I know several people who say they prefer to see web content in its original language, rather than in their native language, because the original is typically more accurate and up-to-date, which seems a plausible argument to me. If someone can read English well, they should read the English version of our page, since it's had more people checking it and avoids the risk of translation errors. It's generally only possible to determine the language of the user's browser UI, not whether they are comfortable with English too, so we can't detect that automatically and give them the ideal version, so anything will be imperfect and defaulting to English might be no worse than defaulting to their browser UI language. Also, all the wiki content and the main web site and the forums etc are in English, and (currently) the game is too, so it seems the most sensible default.So... I'm currently thinking that it'd be best not to change anything, and just default to English and let people manually choose translated copies. (From a technical standpoint, it would be nicer to use the HTTP Accept-Language header on the server rather than navigator.language in script, but it's not a fundamental difference.) Done.

Okay, I'll leave it and will blame you if anyone complains . (I didn't expect the page to be translated at all, so I didn't think about leaving more space. Hopefully we'll be more careful in the game's GUI layout to cope with this kind of thing!)

Do you mean you forgot to change it to today's date, or forgot to translate it? (I've intentionally been leaving them all as the 10th of July, since that's when the content was first published (even though it's not when the translation was published). I don't mind much either way, but this seemed easier.) (But if you mean translating the date text into Hebrew, I can add that easily if you say what to say )

ger_man: Forgot to mention one issue: "Wiederverwendbarkeit" is too long a word . It doesn't fit in the margin (at least with my font on Linux), and I'd prefer not to change the layout just for that page - would it be possible to use shorter words or hyphenate it or something? Jeru: Thanks, uploaded . I changed the HTML a bit so it's as similar as possible to the other pages, and it looks to me like it's still working in Firefox 3.5, but let me know if anything's wrong. (Hmm, hadn't tested it in Firefox before and didn't realise it put an ugly blue border around the flags. Fixed that now.)

ger_man: Great, thanks - HTML saves me a lot of manual copying-and-pasting . Uploaded. (By the way, the flags are from this page.)

Thanks - uploaded (With the flags, I've chosen to adopt the policy of using the flag of the country with the largest number of native speakers of that language, hence the Brazilian flag for Portuguese - I hope that's not too controversial! (The only exception is the British flag for the English language version, because I'm biased.)) Hmm, over-sensitive forum censoring? (I changed it to "as​síncrono", which seems to be what was intended.)

Great, thanks . Converted to HTML and uploaded (hopefully not introducing too many errors!)

Don't have any exact numbers for downloads, but the Subversion server has had roughly 900GB of outbound traffic in slightly under two weeks since the release, and I think (but haven't checked) it's approximately 300MB per copy, so it's probably a few thousand downloads. Most of the community involvement is visible in the forum or Trac, though you'd have to sort through the raw data yourself. But as Erik says, it's only been a couple of weeks so it's very early stages and doesn't provide any kind of long-term view. (But before the open source release, many people have been working on this for many years with no pursuing of monetary gain - I guess the people devising the current economic models can't imagine people just working for fun )

A number of people have encountered this issue, so it would be good to get it solved, but I'm not sure exactly how, so discussion and/or patches would be good The problem: People want system-wide installation of the game, since that's what Linux package managers do (it's installed by root and then executed by (possibly multiple) users). We also want a similar system on Windows, so we can install as Administrator and then run as unprivileged users. The game wants to write some files at run-time. In particular it wants to write to data/cache/, data/screenshots/, data/profiles/, logs/, probably data/mods/*/*.zip, and maybe some others. World-writable directories are unacceptably insecure. So we need to either avoid writing the files at run-time, or we need to write them into per-user directories. Some thoughts: It's possible to compute the contents of data/cache/ and data/mods/*/*.zip ahead of time, since they just depend on the contents of data/mods/. They're quite large, so it would be good to share between users to save disk space. If nothing in data/mods/ is changed (and the code itself doesn't change), I believe the game won't even attempt to write into those directories. But when something is changed (e.g. when the user installs a local mod), we need to be able to write new cache files and would like to be able to write new .zip files. (These could probably go in the user's home directory, effectively layered on top of the system files.) screenshots is initially empty, so it can just be created in the user's home directory. logs initially contains a .jpg and .css file to make the generated logs prettier, so they'd need to be copied(/linked) into the user's home's logs directory. profiles isn't properly implemented yet - it could probably be ignored entirely, except that we save console history in there, and we might want a proper profile system in the future. The game's file-handling code has been designed with awareness of these issues, so it shouldn't be too hard to implement a solution, but it needs to be configured and maybe tweaked or extended to handle everything we need. Is there some standard for how current Linux games deal with these issues? I'm not familiar with the 'proper' way of doing these things. Ideas would be appreciated!