Ykkrosh

sys_get_executable_name doesn't work as expected. In particular, if I run "./pyrogenesis_dbg" then it returns "./pyrogenesis_dbg", and GameSetup.cpp ends up thinking the root is "" (when it should be equivalent to ".."). (But if I run "gdb ./pyrogenesis_dbg" then it returns "/home/philip/0ad/trunk/binaries/system/pyrogenesis_dbg", which is probably why I didn't see the problem at first.) I notice this code has relevant comments around its use of dladdr. I don't see any way to avoid having to do lots of ugly stuff like they do (resolving against cwd if it's relative, searching PATH if it's just the filename).

(I've changed the code to default to windowed.) I was just about to post "Unfortunately everything seems to work fine for me on Linux ", but then I tried the game once more and it failed, so I'll see if I can see why...

Thanks for doing this A few things I notice: http://trac.wildfiregames.com/changeset/7065#file6 -- the intent was that any errors other than file-not-found would be ignored here, and reported normally when trying to open the file normally a few lines later. With the new change, if e.g. your disk accidentally turned into cheese then you'll get a "Cannot find config file" warning instead of the proper disk-is-made-of-cheese error, which would be confusing. So either it should ignore all errors except the legitimate file-not-found/container-directory-not-found/etc ones (so it'll try to open the file and complain about any persistent errors), or else the warning text should be changed. (Or we could add a "don't bring up the ugly assertion-failure dialog if the file merely doesn't exist" flag to g_VFS->LoadFile.) (Edit: Hmm, actually it should probably use ps/Filesystem.h's FileExists.) The tests fail: Running 114 tests.....................................................................vfs.cpp(111): Function call failed: return value was -110101 (Unknown error (-110101, 0xFFFE51EB)) udbg_bfd_init: loading symbols from ./test_dbg. Function call failed: return value was -110101 (Unknown error (-110101, 0xFFFE51EB)) Location: vfs.cpp:111 (LoadFile) Call stack: (0x08539368) ldbg.cpp:101 debug_DumpStack(wchar_t*, unsigned int, void*, char const*) (0x084f679e) debug.cpp:340 debug_BuildErrorMessage(wchar_t const*, char const*, int, char const*, void*, char const*, ErrorMessageMem*) (0x084f6c99) debug.cpp:498 debug_DisplayError(wchar_t const*, unsigned int, void*, char const*, char const*, int, char const*, unsigned char*) (0x084f70af) debug.cpp:552 debug_OnError(long, unsigned char*, char const*, int, char const*) (0x08514429) vfs.cpp:111 VFS::LoadFile(boost::filesystem::basic_path<std::string, VfsPathTraits> const&, boost::shared_ptr<unsigned char>&, unsigned int&) (0x081f1e17) test_MeshManager.h:86 TestMeshManager::copyFile(char const*, char const*) (0x081f28b9) test_MeshManager.h:133 TestMeshManager::test_load_pmd_with_extension() (0x081f2d01) test_MeshManager.cpp:24 TestDescription_TestMeshManager_test_load_pmd_with_extension::runTest() ... Directories aren't created with 0700 permissions (which XDG basedir requires) - they seem to be 0755. There's no tests for the new code, so it would be easy to break it in the future and start putting files in the wrong locations and not notice.

Hmm, sounds like the new filesystem stuff doesn't quite work as planned . (I guess the reason it's running fullscreen is that it fails to load the config file which sets the windowed=true default, and then it carries on anyway until it dies later). I'll see if I can look into it this evening.

It looks like you're using wxWidgets 2.6 - the code is likely to work better with wx 2.8 instead.If you run these commands: wx-config --unicode=yes --cxxflags wx-config --unicode=yes --cxxflags --version=2.8what output do you get? Also, what Linux distribution are you using? Regardless of this, I've also committed a change which might possibly make the code compile better (but probably won't); but using wx 2.8 would be best.

The first one was from a macro (checking min <= argc <= max, instantiated with min == 0), so it's a useless warning in that case, but I've changed the code to avoid the warning. The second was an error (though in code that's probably never executed), so I've (hopefully) fixed that now.

Yep, looks like the space is causing problems. (I'm not sure how hard it'd be to change our build system to cope with those spaces - someone should feel free to look into it )

Some more thoughts: Regardless of whether we're at a point in development where it entirely makes sense, people want to produce Linux packages for the game, and we need to make it work sensibly so the packagers don't have to resort to disgusting hacks. So we do need to solve this problem. But Windows and OS X are largely separate issues, and don't need to be solved now. The current single-directory approach (i.e. everything is inside binaries/) is better for development (I like to have multiple independent copies of the game), as well as some deployments like running directly from a USB stick. So it should be an option, alongside the new installation approach. The XDG basedir spec seems like a good idea. (It's already written, so we don't have to make everything up ourselves; some applications already use it; it has some technical benefits (e.g. you can safely blow away the whole of $HOME/.cache); there's a free (MIT) library that implements it). A very brief summary of what it defines: $XDG_DATA_HOME (default $HOME/.local/share) -- user-specific data files $XDG_CONFIG_HOME (default $HOME/.config) -- user-specific config files $XDG_DATA_DIRS (default /usr/local/share/:/usr/share/) -- data files $XDG_CONFIG_DIRS (default /etc/xdg) -- config files $XDG_CACHE_HOME (default $HOME/.cache) -- user-specific cached files *_DIRS are colon-separated, in order of decreasing precedence when searching. *_HOME takes precedence over *_DIRS. Files go in $XDG_*/subdir/filename. Missing directories are created with 0700. We theoretically want to let people install multiple games based on the Pyrogenesis engine. Each game would have a different and separate version of the engine. Therefore the directory names should identify the game rather than the engine. (Also that makes it easier to find for a user who doesn't care about our engine name). Spaces and punctuation are bad, so we should use the name "0ad". Rearranging the writable contents of binaries/: data/mods/*/*.zip -> $XDG_CACHE_HOME/0ad/mods/*/*.zip data/cache/ -> $XDG_CACHE_HOME/0ad/cache/ data/screenshots/ -> $XDG_DATA_HOME/0ad/screenshots/ data/profiles/ -> $XDG_CONFIG_HOME/0ad/profiles/ logs/ -> $XDG_CONFIG_HOME/0ad/logs/Alternative: Maybe we could skip the mods/*/*.zip thing, by not dynamically creating archives - just do it once during system-wide installation, and never at runtime. http://www.pathname.com/fhs/pub/fhs-2.3.html is relevant for system-wide installation locations. (I suppose some Linux distributions might have different ideas, so they might need to tweak the defaults, but we should have sensible defaults anyway.) (It suggests /var/games for modifiable game data, but we don't want to do that because of security (someone could write a corrupted file in there, and another user might run the game and it will load that file, and we don't (currently) attempt to guarantee any kind of safety when loading data files).) Thus, read-only files could be like: data/config/local.cfg -> $XDG_CONFIG_HOME/0ad/config/local.cfg data/ -> $XDG_DATA_HOME/0ad/data/:/usr/share/games/0ad/data/ (search in both, install into the latter) system/pyrogenesis -> /usr/bin/0ad system/lib*.so -> /usr/lib/0ad/lib*.soFor simplicity, the HTML logs should be changed to standalone files (i.e. get rid of the logo, and use inline CSS). For efficiency, /usr/share/games/0ad/data/cache/ should be initialised (on installation) with conversions of all the .xml and .dae files.

Strange, I don't get that va_list error. Anyway, #include <stdarg.h> seems the right thing to do, so I've added that - thanks!

Hmm, sounds like you might have glibc older than 2.4, which doesn't support the stack-protection feature. So either we need to make the build system detect this, or you can hack it by removing the "-fstack-protector-all" line (I think that's all that's needed; if not, maybe the next line too) from build/premake/premake.lua and then do ./update-workspaces.sh and make clean etc.

r7060 fixes it for me (on Linux).

Oh, right - if there was an error while compiling Atlas then Atlas is definitely not going to work

About -fstack-protector-all: Hmm, I tested with GCC 4.1 but not with 4.0, and it seems like it's not supported in 4.0. I think it's a worthwhile flag to have (it found one stack corruption bug recently), so I guess we either need to update premake.lua to detect whether you're using GCC >= 4.1 and enable the flag, or else just state that we require GCC >= 4.1. About "enet/enet.h: No such file or directory": You need to install the ENet library. (This might be relevant). Edit: Oops, just saw you said you had it installed already. In that case, it's still not being found by the compiler, so you need to do something but I have no idea what (I'm not aware of our code / build system having changed recently in a way that would affect that...)

That means it's failing to find the Atlas code to load - you might need to make sure you're running pyrogenesis_dbg directly from the directory it's installed into (i.e. binaries/system/), or set DYLD_LIBRARY_PATH to point to that directory if you're running it from outside.

Yes - if you cancel it half-way through (I assume TortoiseSVN has an obvious button somewhere), then (if I remember correctly) you can use the context menu (in the checkout folder) -> TortoiseSVN -> Update command to resume downloading everything.

That sounds like you're connecting through a proxy which is incompatible with SVN (specifically some extensions to HTTP). Depending on what proxy it is, it might or might not be possible to configure it to allow that; if not, I don't think there's much you can do without finding a different way to connect to the internet.

You'll get the same error if the cache directory exists but is unwritable, e.g. if your username doesn't have write permission. Until we sort out the writable-directory thing properly, you should probably just make the whole game directory writable. (It needs at least data/cache/ and logs/ and probably some others.)

What Belisarivs says is valid (though maybe unnecessarily impolite ) - the game is under development and far from complete, so there are likely to be lots of bugs, and if you use a pre-packaged version then it's very hard to work out what problem you're experiencing, so there's little we can do to solve it without an excessive amount of effort. Best to wait until the game becomes more stable

Try following the instructions again from the "make -j3" step.

(Sorry, forgot to reply!) As far as I'm aware the server is fine and nobody else has encountered problems, so it sounds like a problem on your network, but I have no idea what the problem actually is . The intermittent failures with ping seem particularly strange. I can't think of anything to suggest, other than temporarily disabling any firewall software to see if that helps, or trying it on a different computer.

Hmm, sounds like it might be some kind of inconsistency in how SpiderMonkey was compiled. Not sure how to fix it. I guess we really do need to bundle SpiderMonkey ourselves to make sure it's all compiled properly...

I'm sure there are ways you could help the project without needing crazy programming skills or anything like that . If you figure out how Atlas works then maybe you could write some kind of documentation for new users, or suggest features that would make your life easier, or report bugs, or make pretty screenshots, or all sorts of other things which I can't quite think of

The code that is released is (very nearly) all the code we have - we don't have any private new features or changes. (The only exception is a couple of external tools which aren't being released as open source, and aren't really related to the game but were convenient to put in SVN originally.) The art that is released (models, textures, etc) is only for 2 of the 6 civs - the others are currently private, and still largely work-in-progress. (Some maps that rely on the private data are private too.) The screenshots are carefully arranged and sometimes cheat a bit to get the right effect when features are missing from the engine, e.g. I guess you make it look like units were standing on ships by raising tiny patches of land to just beneath the deck and then stand the units on there while the ship is in the water.

Looks like you need to install SpiderMonkey. Try the "libmozjs-dev" package (I'm not sure if that actually works so it'd be good to know), else try the SpiderMonkey installation instructions.

How did you install the game? If you run it from the command-line, then it should print some message when it stops, so it would be good to know what it says.