Ykkrosh

For wcscasecmp, that should be straightforward to fix - filed as #414. For wstring_from_string, that's trivial so I've fixed it in SVN. For uint64, does the problem go away when you apply that patch to the game's libraries/spidermonkey/src/js/src/jsotypes.h (instead of a system version of the library)? (It's not clear to me from the forum post you linked to, and I can't test it myself.)

Thanks, applied By the way, do you have a real name and/or email address? It'd be nice to keep this list relatively up to date (although I'm not sure we've done a perfect job of that so far...), to keep track of who's patched the code in any way. About the patch process: The current approach is that some people are following Trac's timeline RSS feed and will see any attachments and comments, and ideally one of the people ought to test and apply the patch straight away, so you shouldn't have to do anything. But that's not really very reliable, so it might be necessary to comment on Trac or on the forum somewhere if you've not heard anything after a few days. Maybe what we should do is add some kind of 'requesting review' flag on Trac, which people can set when adding patches, and then periodically we can check for any lost patches with that flag? That might be the simplest solution to stop things getting lost, unless anyone has better ideas.

By writing code to embed it . We use SpiderMonkey (the JS engine used in Firefox), which is designed to be easily embedded into non-web-browser applications. For implementing gameplay code (currently not much, but it should be much more in the near future), and for GUI behaviour. No. There's a trillion pages on the web and two thirds of them use JavaScript; how much more popular do you want? It's true that JS seems to be rarely used in games, but we chose JS a long time ago (before I joined the project) and I think it was a good decision (since it's quite a nice language, and implementations have been improving a lot recently).

It says: ../../../source/ps/CConsole.cpp: In member function ‘void CConsole::InsertChar(int, wchar_t)’: ../../../source/ps/CConsole.cpp:461: warning: Non-constant format string argument - can't check types ../../../source/ps/Interact.cpp: In member function ‘void CMouseoverEntities::RenderOverlays()’: ../../../source/ps/Interact.cpp:1045: error: Invalid argument type "long int" for format specifier "%d" ../../../source/lib/file/file_system_util.cpp: In function ‘void fs_util::NextNumberedFilename(const PIVFS&, const VfsPath&, size_t&, VfsPath&)’: ../../../source/lib/file/file_system_util.cpp:136: warning: Non-constant format string argument - can't check types ../../../source/lib/file/file_system_util.cpp:151: warning: Non-constant format string argument - can't check types

(Thought I ought to post into this forum, because it's meant to be for technical discussion but I've kind of neglected it... Any feedback would be appreciated ) Mozilla has been developing Dehydra, which is basically a way to write scripts in JavaScript that hook into the GCC compiler and analyse C++ code in whatever way you fancy. It's pretty simple to set up and run, and (most impressively) it actually works for real. One thing it's particularly useful for is warning about certain code patterns, when the standard compiler doesn't provide the right warnings. So I spent the past couple of days learning it and writing a script to do type-checking of printf-style functions - it'll warn about printf("%s", 123) and wprintf(L"%s", L"str") etc. (GCC has some checking built in, but it doesn't handle wprintf-style (i.e. wchar_t*) functions at all (which we use a lot), and there's also some Windows compatibility issues it doesn't look at.) I've uploaded the code here. I'm quite new to this so it's probably not particularly well written, but it seems to generally work This system probably isn't hugely useful but I expect there's a number of cases where it's a nice way to automatically find certain classes of bugs, so it'd be good to explore how it could be used further. In case anyone wants to bother fixing them, the messages I get from compiling the game's code now are: ../../../source/network/NetLog.cpp: In member function ‘virtual void CNetLogConsoleSink::Write(const CStr8&)’: ../../../source/network/NetLog.cpp:457: warning: Non-constant format string argument - can't check types ../../../source/ps/CConsole.cpp: In member function ‘void CConsole::InsertChar(int, wchar_t)’: ../../../source/ps/CConsole.cpp:461: warning: Non-constant format string argument - can't check types ../../../source/ps/CConsole.cpp:492: warning: Non-constant format string argument - can't check types ../../../source/ps/Interact.cpp: In member function ‘void CSelectedEntities::RenderOverlays()’: ../../../source/ps/Interact.cpp:241: error: Invalid argument type "long int" for format specifier "%d" ../../../source/ps/Interact.cpp:265: error: Invalid argument type "long int" for format specifier "%d" ../../../source/network/NetServer.cpp: In static member function ‘static void CNetServer::PlayerAttributeUpdate(const CStrW&, const CStrW&, CPlayer*, void*)’: ../../../source/network/NetServer.cpp:916: error: Invalid argument type "long unsigned int" for format specifier "%d" ../../../source/ps/GameSetup/GameSetup.cpp: In function ‘void Init(const CmdLineArgs&, int)’: ../../../source/ps/GameSetup/GameSetup.cpp:969: warning: Non-constant format string argument - can't check types ../../../source/ps/scripting/JSCollection.h: In static member function ‘static JSBool CJSCollection<T, ScriptType>::ToString(JSContext*, JSObject*, uintN, jsval*, jsval*) [with T = CPlayer*, JSClass* ScriptType = (& CJSObject<CPlayer, false>::JSI_class)]’: ../../../source/ps/scripting/JSCollection.h:90: instantiated from ‘JSFunctionSpec CJSCollection<CPlayer*, (& CJSObject<CPlayer, false>::JSI_class)>::JSI_methods [8]’ ../../../source/ps/scripting/JSCollection.h:244: instantiated from ‘static void CJSCollection<T, ScriptType>::Init(const char*) [with T = CPlayer*, JSClass* ScriptType = (& CJSObject<CPlayer, false>::JSI_class)]’ ../../../source/ps/GameSetup/GameSetup.cpp:489: instantiated from here ../../../source/ps/scripting/JSCollection.h:266: error: Non-portable %s used in wprintf-style function ../../../source/ps/scripting/JSCollection.h:266: error: Invalid argument type "long unsigned int" for format specifier "%d" ../../../source/lib/ogl.cpp: In function ‘void ogl_WarnIfError()’: ../../../source/lib/ogl.cpp:307: warning: Non-constant format string argument - can't check types ../../../source/lib/app_hooks.cpp: In function ‘void def_log(const wchar_t*)’: ../../../source/lib/app_hooks.cpp:70: warning: Non-constant format string argument - can't check types ../../../source/simulation/Projectile.cpp: In static member function ‘static JSBool CProjectile::Construct(JSContext*, JSObject*, uintN, jsval*, jsval*)’: ../../../source/simulation/Projectile.cpp:230: warning: Non-constant format string argument - can't check types ../../../source/gui/CGUI.cpp: In member function ‘void CGUI::ReportParseError(const wchar_t*, ...)’: ../../../source/gui/CGUI.cpp:1055: warning: Non-constant format string argument - can't check types ../../../source/gui/CGUI.cpp: In member function ‘void CGUI::Xeromyces_ReadObject(XMBElement, CXeromyces*, IGUIObject*)’: ../../../source/gui/CGUI.cpp:1318: error: Invalid argument type "const short unsigned int*" for format specifier "%hs" ../../../source/gui/CGUI.cpp:1448: warning: Non-constant format string argument - can't check types ../../../source/simulation/Technology.cpp: In member function ‘bool CTechnology::LoadElEffect(XMBElement, CXeromyces&, const VfsPath&)’: ../../../source/simulation/Technology.cpp:301: error: Invalid argument type "const short unsigned int*" for format specifier "%hs" ../../../source/lib/file/file_system_util.cpp: In function ‘void fs_util::NextNumberedFilename(const PIVFS&, const VfsPath&, size_t&, VfsPath&)’: ../../../source/lib/file/file_system_util.cpp:136: warning: Non-constant format string argument - can't check types ../../../source/lib/file/file_system_util.cpp:151: warning: Non-constant format string argument - can't check types ../../../source/ps/scripting/JSCollection.h: In static member function ‘static JSBool CJSCollection<T, ScriptType>::ToString(JSContext*, JSObject*, uintN, jsval*, jsval*) [with T = HEntity, JSClass* ScriptType = (& CJSComplex<CEntity, false>::JSI_class)]’: ../../../source/ps/scripting/JSCollection.h:90: instantiated from ‘JSFunctionSpec CJSCollection<HEntity, (& CJSComplex<CEntity, false>::JSI_class)>::JSI_methods [8]’ ../../../source/ps/scripting/JSCollection.h:244: instantiated from ‘static void CJSCollection<T, ScriptType>::Init(const char*) [with T = HEntity, JSClass* ScriptType = (& CJSComplex<CEntity, false>::JSI_class)]’ ../../../source/simulation/scripting/SimulationScriptInit.cpp:46: instantiated from here ../../../source/ps/scripting/JSCollection.h:266: error: Non-portable %s used in wprintf-style function ../../../source/ps/scripting/JSCollection.h:266: error: Invalid argument type "long unsigned int" for format specifier "%d" ../../../source/scripting/ScriptGlue.cpp: In function ‘JSBool WriteLog(JSContext*, JSObject*, uintN, jsval*, jsval*)’: ../../../source/scripting/ScriptGlue.cpp:120: warning: Non-constant format string argument - can't check types ../../../source/lib/res/graphics/ogl_tex.cpp: In function ‘LibError OglTex_to_string(const OglTex*, wchar_t*)’: ../../../source/lib/res/graphics/ogl_tex.cpp:488: error: Invalid argument type "long unsigned int" for format specifier "%x" ../../../source/lib/res/sound/snd_mgr.cpp: In function ‘LibError alc_init()’: ../../../source/lib/res/sound/snd_mgr.cpp:278: error: Non-portable %s used in wprintf-style function ../../../source/lib/sysdep/os/linux/ldbg.cpp: In function ‘LibError debug_DumpStack(wchar_t*, size_t, void*, const wchar_t*)’: ../../../source/lib/sysdep/os/linux/ldbg.cpp:115: error: Invalid argument type "void*" for format specifier "%08x" ../../../source/lib/sysdep/os/linux/ldbg.cpp:117: error: Invalid argument type "void*" for format specifier "%08x"

That shouldn't happen - the idea is for the code to be continually portable (not to write it for Windows, and then release it, and then port it to other platforms afterwards), and it shouldn't take that much effort to fix the platform-specific bugs that pop up, so all the version ought to be usable at approximately the same time.

They did over a year ago, if I'm reading that bug report correctly. Jaunty has 1.4, Karmic has 1.8. Well, it has the advantage that it has no automatic package manager and therefore you'd have to compile everything from source manually, and it doesn't have a standard compilation environment so that's usually a huge pain, and so library developers take pity on you and provide pre-compiled binaries that you hope might be compatible with the CRT version you're using

Sounds like some file permissions are wrong. If you're using the latest version of the code from SVN, I think it's trying to create the directory ~/.local/share/0ad/screenshots/ at the point where it's failing - is that location writable by the user you're running the game as?

It looks like those are all just warnings (not errors) in third-party code (FCollada, SpiderMonkey), and probably harmless in practice, so I think it's fine to just ignore them for now

There's also a recent (2 week old) update of OpenAL Soft (which I believe most Linux distros use), so it may be worth seeing if that fixes the PulseAudio issues.

Be nice to tourists, but make sure you don't explain the toll system to them

Looks like it succeeded that time . The only output is warnings in third-party code, which can be safely ignored. In theory, you should be able to run pyrogenesis_dbg from binaries/system/ now.

I guess you didn't search the FAQ . But that is extremely out of date, and it was based on complete guesswork anyway. I don't believe it will work with that little RAM. I guess it should work with 512MB, but it'd be better to have at least 1GB, particularly depending on what other stuff you have running in the background (e.g. Windows). Don't really know about CPU. It shouldn't need much disk space (probably a few hundred MB). For graphics, it should still technically work with a GeForce 3, but probably not with great performance (particularly with shadows) and not with all the graphical effects (like shiny water).

Yes. (They are the Unicode versions of the library, which we require.) (If you work out all the packages that are needed, it'd be great if you could update the wiki to list them (like how it currently lists Ubuntu packages) to help other Mandriva users )

Make sure you have the development headers, not just the normal package - it looks like it might be called libbinutils2-devel on Mandriva.

You need BFD, which probably comes from a package called binutils-dev (depending on what Linux distro you use).

Hugin: Works fine for me with Boost 1.39 on Gentoo, but I got exactly the same problem as you after changing version - you have to run "make clean" and then "make" again, else the build system will get confused and look for old files. creation: Works fine for me with Boost 1.35 and 1.36 and 1.39 on Gentoo, so it doesn't seem to be an obvious problem with Boost or with our usage of it. It might be an issue with openSUSE's packages, or with something weird on your local system, but I have no way of reproducing the problem so I can't tell what it is.

The output you posted looks okay, but you need to run "cd gcc" and "make" again to build.

It'd be good to file these issues as tickets on Trac, so we don't forget about them. Yeah, the current organisation is probably not ideal, since it's grown gradually over the years. I don't think creating a new civ is something that many(/any) people will actually do, so it's more important to focus on making it easy to work on civs that already exist - but more centralisation of civ data would be good in any case, and I don't believe any of it should be hard-coded in the GUI files. Rearranging the data is probably something to look into after rejigging the game's simulation system (but that might take a while...) Making games is hard - everything explodes into a zillion little things . One problem here is that some GUI scripts do insane things because the engine doesn't quite provide enough capabilities (particularly for dynamic layout), and sometimes they're just not designed as well as they could be - it'd be good to discuss any such issues that you see.

It's great that you're looking at this I'm fairly sure there isn't. There probably should be, and ideally it would be independent of the GUI code and scripts.I currently have a crazy (but necessary) plan to rewrite most of the game's simulation system, with one consequence being that things like civs can be represented as first-class entities in the system, so that would probably be the best way to handle it in the future. But that doesn't exist yet, so there's not much option other than hacking it into the GUI for now. I once had a crazy (and unnecessary) plan to replace the game's whole GUI system with WebKit (the HTML engine from Safari and Chrome), so everything could be written with full fancy HTML and CSS and JS and everything. I still think that'd be a great thing to do, but a lot of work and very risky - I don't think anyone has embedded WebKit in a high-performance cross-platform OpenGL application before, so there might be serious difficulties making it work or it might have unacceptable performance, and it might be hard to maintain the code as WebKit evolves. It's much less risky to stick with the current GUI system, whose problems are mostly well-known and can be fixed incrementally. So I'd be very happy if someone wanted to try embedding WebKit, but in terms of getting a working game I think it's an unnecessary distraction.(I actually implemented a prototype where I had WebKit rendering a Theora video with rotation and real-time reflection (all using simple HTML and CSS) inside the game engine, which I thought was pretty cool, so it's certainly possible and opens a lot of possibilities, but that was Linux-only and a very long way from being usably complete...) Anyway... You can still embed some simple formatting commands in the current GUI system - I don't know if/where it's documented, but there's code to support and and and images etc. It shouldn't be hard to add some other simple formatting extensions if necessary. It's not HTML, but it might be adequate

Glad it's working . I've updated cxxtestgen.pl in SVN to include the extra error detail. You get that warning because you don't have S3TC (texture compression) support enabled - the easiest solution is to run 'driconf' and turn on the "Enable S3TC ..." option, which should fix it. (We do need to make this warning message a bit friendlier )

Hmm, not quite sure what causes that. Could you try changing build/bin/cxxtestgen.pl line 302 from open OUTPUT_FILE,">$output" or die("Cannot create output file \"$output\"\n"); to open OUTPUT_FILE,">$output" or die("Cannot create output file \"$output\": $!\n");and then run it again and see what the error message is?

Actually I think he's just a spammer.

Hmm, that sounds bad, and something that ought to be fixed, but I have no idea how. But a temporary workaround is to add "-quickstart" to the list of command-line arguments when running the game (which will disable audio and should avoid that problem).

Uploaded that change now.