janwas

Ah, that's a good point, but it looks like philosophical territory. The original intent was that all (low-level) errors be reported immediately when they are generated (i.e. by using WARN_RETURN ERR::xxx instead of return ERR::xxx), so the cheese error (hehe) wouldn't be ignored. Also, there is something to be said for the main game code saying "cannot find config file" regardless of whether it's just because the file wasn't found or because the disk is made of cheese - the result is the same. Finally, how can the game code (or for that matter, LoadFile) know what errors to ignore and which ones should actually reported? I'm pretty happy so far with the policy of reporting everything unless a particular error happens often/legitimately, but am happy to be convinced otherwise. Uhoh Unfortunately I'm out of time today and probably won't be able to look into the issue until the weekend due to an upcoming trip. Yep, I couldn't see a way to do so with the boost filesystem API - create_directory lacks a mode_t parameter: We should revert to calling mkdir then, eh? Yeah, I'm kind of worried about confusion regarding profiles etc., especially because the old location is still supported (depending on cmdline args). Do you have any ideas?

Interesting, I've not seen such an error before. Are you running on a least-permissions account or as admin? Vista, XP or Win7? 64-bit? Yep, we use WMI to retrieve certain system information. Until the problem is found and fixed, you can launch with the -quickstart command line argument (which disables the system detection code and sound). The error#4 bit is just so we can see exactly which function failed. If you have access to a debugger, could you please post the value of hr? (If not, the error code should be visible in the Application section of the Windows EventLog) A web search shows several similar problems. If you start->run compmgmt.msc -> services and applications -> wmi control -> right-click -> properties, do you see an error? http://www.pcreview.co.uk/forums/thread-526766.php was solved by ensuring %windir%/system32/wbem is on the path. You may also want to check out the wmidiag tool (it seems to be useful for such problems).

Yep, the error code means "directory not found" in very early init (the config file). Hopefully Philip will find the cause, unfortunately I can't debug on Linux. In the meantime, there remains an escape hatch in the form of the -writableRoot command line argument that should restore the old directory lookup scheme if it worked before.

Yep, that's the cause (cxxtestgen is the culprit). The build instructions call for checking out into a directory without spaces; it would be slightly nicer (in a low-priority sense) to rule out this cause of errors, but I have no idea how much trouble that would entail. hm, that's strange (and slightly worrisome to have unknown bugs lurking nearby). One thing that changes with time is the translation of XML files to XMB. I guess it's possible for one of them to have been garbled, and the recent change from binaries/cache to $appdata/0ad/cache may have hidden the issue. Would you like to try deleting the former and renaming the latter cache folder?

Fixed

Sorry for the inconvenience. That code was only a stopgap until the proper directory logic was implemented and has now been replaced. However, it did compile on VC2005, not sure why.

After two coding sessions yesterday and today, the support for user/home directories is in place. Crashlogs and screenshots are written to a subfolder of appdata/0ad or the appropriate XDG folder. Ticket 81 has been updated. It works on Windows but is untested on *nix Please drop me a line if there are problems.

Hm, this might be another instance of a known problem when the SpiderMonkey library wasn't compiled with the same version/flags we need. Mid-term, Philip (who knows more about the topic) was wanting to add source+makefiles to SVN so that we can rule out such incompatibilities. Unfortunately I don't know a short-term workaround, nor can I help with the wxW issue.

Hi Brandon and thanks for reporting the problem! Those files are all generated by the test_gen project and do not exist in the non-public repository, either. Could it be that test_gen isn't being built, or that dependencies are incorrect? (test_gen needs to build before test) About the game crash problem: whether unrelated or not, we'd be happy to try and solve it. Please feel free to create a trac ticket (CCing "jan" ensures I'll see it faster) or attach binaries/logs/crashdump.* here.

Ah, that is helpful! The crash is apparently inside the error reporting code, which is why you aren't seeing the "Program Error" dialog. However, the crashlog.dmp file in binaries/logs/ should have been written by that time and is essential to finding out what happened. Can you please post that as well as pyrogenesis.exe and pyrogenesis.pdb?

I'm fine with using XDG, it's reasonably straightforward. Subdirectory 0ad - makes sense. mkdir with 0700 - done. I'm fine with that. This archiving code has long been dormant anyway. How would that work? Do we really want to create a separate cache-everything routine or executable? BTW, the VFS was designed for this kind of thing, but the underlying path.cpp's Path presumes that everything will reside in one directory. Am currently removing that logic.

Interesting. I would've thought that to be "impossible" because we have a crash handler that should intercept any errors (and report information about them) before the normal Windows dialog comes up. Do you see anything in the Windows event viewer, or when running DbgView while attempting to start the game, or any files created in binaries/logs/? heh, no worries. Let's just keep in mind that the probability of fixing an error is directly proportional to the amount of information provided. Frankly, with the above four reports, that chance is near zero. An analogy for non-software-developers: imagine you build an oil rig and someone tells you: "it exploded". Is that enough information to understand the cause?

Those compile errors are from Atlas (and its freestanding tools), which is compiled separately from the game (thus explaining why it still runs). That's possible, but I thought we'd concluded that GCC > 4.2 causes the error. Here it's the opposite. Can you post a few of the referenced lines in il.h and ilu.h so I can check?

The latest errors are caused by the DevIL library not being found on your system, but unfortunately I can't help with installing it. IIRC there were several threads mentioning it, though.

(I'm beginning to feel like a broken record..) What is the exact error message? Is it shown by Windows in your native language or by an english-language dialog entitled "Program Error"? To give us a realistic chance of diagnosing the error, can you post binaries/logs/crashdump.*?

Oops, sorry We've been emulating secure CRT (e.g. strcpy_s) functions for non-Windows platforms as needed, I didn't realize vsprintf wasn't yet included. r7060 attempts to fix this. (I can only test on Windows, please yell if that doesn't do the trick)

Right click pyrogenesis (bold) in project explorer -> debugging -> command arguments. (or you can launch pyrogenesis.exe yourself from a shell) Incidentally, I hope to have just solved the "resolution <= 2e-3" problem, see http://trac.wildfiregames.com/ticket/253.

What's the error message? Can you post binaries/logs/crashdump.*? I don't think it makes a difference on which machine you compile, except for maybe the compilers' runtime libraries already being installed. However, we account for that issue (they should all be distributed in SVN).

Automatic creation of directories now hopefully works. Could you please try again after deleting the cache/ directory you created?

hehe. Good point, I have just (locally) changed the error message formatting to include the error number

Looks like the same error as above. Are you running Vista? 64-bit or 32? This message is just a warning, and until it's fixed (which requires more information for purposes of debugging) you can either just ignore it (choose continue or suppress) or start the game with -quickstart (which disables the system-detection code that calls ReadVersionString as well as sound). This one's probably a show-stopper. The game isn't going to run well without a GeForce III-level GPU, and current onboard offerings aren't there yet. Is upgrading your GPU an option? Are those the only errors that show up? We can't debug crashes without more information, most importantly the files crashdump.txt and crashdump.dmp.

Context menu -> Settings -> Network.

Don't get me wrong, we are happy to look at the issue, it's almost certainly not caused by the installer itself. (The wdll_ver issue is likely caused by Windows' automatic path redirection. Are you running a 64-bit version of Vista?) As Jeru says, though, we need the crashlogs to get anywhere. Please feel free to CC "jan" if you create a ticket so that I'll see it sooner.

hm, indeed strange. When you say "connect via network" - are you using a proxy? If so, you need to notify TortoiseSVN, it apparently doesn't automatically copy Internet Explorer's settings.

Hi and thanks for the output! This sounds a bit like http://trac.wildfiregames.com/ticket/279 - it seems I screwed up a mkdir() and will need to fix that (there should be some time for coding this weekend). Can you please check if binaries/data/cache exists, and if not, whether creating it avoids the problem?