janwas

That's bad news, I can't see why that is happening unless you happened to leave out some parts of the VC++ install (most notably the platform SDK), especially since you've done a complete reinstall I think most of us were using VC2005 and it has worked without problems. VC2008 SP1 is also known to work - is upgrading an option?

Thanks to Philip for reviewing + committing this, and to Cygal for the patch!

Thanks for confirmation of AL_NONE I've created a trac ticket and am looking through Philip's trace file, which is probably going to be awesomely helpful..

Thanks for reporting these warnings! We already have a trac ticket for this particular issue, and will fix them when time permits -- or would be grateful for help in doing so

Looks good

The workaround suggestion is good for starters. Attempted analysis of cause: The OpenAL spec says alSourceQueueBuffers fails with "invalid operation" if: 1) No current context 2) Adding a buffer of a different format 3) Source has static buffers attached #1 is ruled out due to the non-existance of an "alc_init failed" error message, which implies alcCreateContext returned non-NULL and alcMakeContextCurrent did not encounter an error. #2 is 'impossible' (except if memory is corrupted) because the buffer format is set once per file and never changed or transferred. #3 can't happen because we never set static buffers (the only time we alSourcei(.., AL_BUFFER) is when buf=AL_NONE). Could you please verify that AL_NONE = 0 on your system? The most likely of these options appears to be #2. Could you please add a debug_printf("%d\n", sd->al_fmt); line before returning from snd_data_buf_get? The first two times (main menu, in-game music), it should output the format for 16-bit stereo, all subsequent outputs should be equal and for 16-bit mono.

Dude, that thread contains at least a half-dozen separate problems. You mean post#32 (the same "resourceObject has no properties" warning), right? Ah. To be more specific, building a single Hippikon (cav sword) is enough to trigger the problem. That also points us at the problem: the hele_cavalry_swordsman_b.xml file was structured incorrectly (build time was a child of Resources, which means the time object was being treated as a resourceObject). Fixed. It'd be best to attach it to a trac ticket, so that it's more easily found and cross-referenced. However, you can also attach the file to a forum post. hrm?

Sorry, that's not nearly enough detail to begin debugging. hm, that system should definitely suffice Are you running a debug build? Switching to release boosts the framerate considerably. It would only take seconds and helps us as well as yourself (e.g. notification when something related to the issue changes). Thanks for trying though

OK, 1.38 might also work. Does a file named boost_system-mt.* exist at all on your system? Boost can be linked statically or dynamically. Unfortunately I can't help in more detail (am developing on Windows).

Do you have Boost 1.35 installed? The error message refers to a missing library that belongs to that package (libboost-dev); if it's installed, then we may be looking for it in the wrong directory.

Greetings, You need to install Visual C++ to compile the game.

hm, I don't think we've seen that before. What are the steps to reproduce this problem? (What map? Was it triggered by giving the order to chop wood / work a farm etc.) I've just added a readme.txt there that explains that log files are only created at this location if you launch with -writableRoot. The log files should be located in %appdata%/0ad/logs. hm, do you mean build issues? That thread is mostly Linux-specific, I can't see what problem you are referring to.

hrm, it looks like you launched the game from the VS IDE. Could you please run it without a debugger so it has the chance to write out a crashlog? What are the steps required to reproduce this problem? hm, that's a vicious circle - if the framerate is too low, then a debug_printf raises that warning, which is quite slow, thus further lowering the framerate and so on. What are your system specs? There's little that can be done here besides using a release build and/or disabling the warning. Ooh, that is bad news indeed. Right, resources are computed within Javascript, which has different behaviour concerning variables and typing (or lack thereof). Could you please create a trac ticket for that one? (trac.wildfiregames.com) It'd also be helpful to know if that was a once-off event (happened only once during 10 test runs) or whether it's common and always happens if you farm for xx seconds.

Sounds good! I'd think so, (reliably) solving the frequently occurring SpiderMonkey problem is already valuable and update-workspaces isn't run that often, so a few seconds doesn't hurt at all.

I didn't see any relevant info, either :/ (We do need to clean up those warnings, though) Just one thing looked strange: Is it trying two linkers (and failing to print a newline after the first error)? That's interesting..

heh, true In fairness I'd say our build script isn't horribly complicated, and it remains readable by virtue of being Lua (not my favorite language, but still way more intelligible than CMake or m4). I didn't know about --as-needed, thanks for the pointers.

Ah, ok; that'd just require simple changes to the Paths class (i.e. hardcoding the paths). That's a good argument. Only supporting the single-directory mode on Windows would've been a copout, to be honest. Thank you for your comments, they are helpful! Awesome! I agree that being 100% robust there is unrealistic (symlinks are tough, but also due to unpredictable contents of argv[0] and getcwd/initial_path - they may be total garbage). However, the source copies the old/deprecated normalization stuff from boost, and I'm wondering why realpath wasn't used - that looks to be more robust and should at least correctly handle symlinks. One more comment: relying on cwd doesn't work on Windows because it in turn is not always correctly set *sigh* (I forget in what cases, but launching from a shell and explorer and debugger behaved differently).

Greetings! Sorry about the delayed reply. Help is very welcome. We are happy to accept patches, and the process for selecting tickets to work on is exceedingly simple: whatever grabs your eye! (See http://trac.wildfiregames.com/report/3) Really anything not marked as an 'enhancement' would have a tangible benefit, and one of the advantages of being a hobbyist group is that there's no boss ordering you to do stuff you don't want to do. If you're in things for the long haul, we'd love to see you join the team. That can be arranged by having a quick chat in IRC to get to know each other a bit better. It looks like things will be pretty hectic today, but how about mid-day tomorrow (Sunday)? Am I correct in assuming you are currently in the GMT+2 time zone?

The directories are referenced from build/premake/extern_libs.lua but aren't present in libraries/. Comsuppw (Windows-specific) is a .lib file shipped with the compiler; X11 ought to be present on most *nix but I don't know where/whether we need a directory or just a single file. I don't know about DL, either. Seems quite doubtful that these warnings point to a problem that prevents the library from being loaded, though.

hm, it's safe to say that the cause is a NULL this pointer (offsetof m_RenderData is 0x9C, which is also the faulting address). Unfortunately this member function appears to be called often, so it's difficult to see what's going wrong. Did the game write a crashlog.dmp to %appdata%\0ad\logs? Posting that would be helpful.

Right, that's pretty much our plan on Windows, too (Just substituting CSIDL_APPDATA for My Documents) That's the advantage of XDG - we write a bit more code once, then users/systems can easily change environmental variables to support their particular path setup. hm, that's an idea, but I'm not sure we'd always want to require configuration+compilation. Wouldn't it make sense to provide binary packages (debs or rpms) eventually?

Reading the thread would have pointed out the reason for a more complicated build system - Makefiles or autotools do not meet the requirements set out above. Does that include Premake and scons? hm, I don't have much Linux experience, but only linking in the bare necessities doesn't exactly sound like a killer feature. Is that so important?

That's currently true for many systems, but newer versions of Windows and least-permission user accounts forbid writing to some directories, especially under Program Files. Hence, we should also separate data and executables on Windows. hm, I don't know about acceptable practice on Linux. The XDG layout scheme (what we're now using) was recently suggested. Can someone else with more experience comment on whether fixed paths would be acceptable? (Simplicity is a pretty compelling argument ) However, XDG isn't that much more complicated. I think what's "killing" us is correct relative search on Linux, as Philip points out. What if we only enabled the option for that on Windows (where GetModuleFilename is easy+reliable)?

hehe, it's not quite that simple. Sure, we can check if the error is "file not found". However, what was happening in this case is "dir not found" (files and directories are tracked separately). I think the capability of differentiating them is potentially useful, but it'd be burdensome if user code had to check for both of them. (Worse yet, delayed population of directories can postpone file enumeration errors - e.g. due to antivirus - until the first file lookup.) GetFileInfo only avoids an *additional* error dialog from CHECK_ERR if you "pass in a flag" (i.e. set pfileInfo to 0), independent of the actual error. However, the new code doesn't silently ignore other errors because they are still reported when first returned from a function. *nod* I've implemented our own CreateDirectories with a mode_t parameter. Sounds good Have noted this in the never-ending todo list.

Ah, that explains it I've changed related code to silently and safely handle disabled WMI (r7071). About memory leaks and antler: yep, we are aware of both but they haven't ever reached the top of the TODO list (The latter is due to an error in deer_mesh.dae and not code)