janwas

We differentiate between "leaving" (a game session, returning to the main menu) and "exiting" (the entire game). The former defaults to Escape, and the latter to Ctrl+F4 or Ctrl+Break. Both work on my machine (Windows). Have you made any changes to default.cfg or created a local.cfg or user.cfg?

Thanks for passing on your experience pavolzetor, slochewie: does disabling PulseAudio work around the trouble you're seeing?

Gameplay would be things like deciding when to promote units, the effect of auras, harvesting - basically what defines 0ad. The rule of thumb for adding new gameplay-related code is: if it should be moddable (by non-C++-programmers) and it's not time-critical and there's no tight coupling with existing C++ code, write it in JS.

I'm sorry about the lack of a response - this thread got lost in my flood of open tabs. Thanks again for tracking down the bug, and also asking about its status via IM! The issue is now fixed, I've checked all call sites and also improved the indexing logic in the rest of terrain.cpp.

Thanks, fixed (again except for file_system_util, looks like that one will remain)

This is pure gold - thanks! Those %hs vs %s vs %ls spots run rarely (in error output code) and are very hard to catch otherwise (slipped through my regex?!). The non-constant format string warnings were mostly due to passing (user-controlled or output) strings as format strings, which is a total disaster for security. I've fixed all of them except that warning in file_system_util (where the format string is a function parameter), and anything that may have been lost when the IDE crashed. Would you mind giving it another go? (no longer non-constant format strings may also add a few new ones)

Man, that sounds terrible, and who knows when they'll actually switch to OpenALsoft. Development on Windows does have a few occasional advantages If you are able to do so, building a recent version of OpenALsoft (e.g. from git or snapshot) would definitely be an improvement.

Welcome, and thanks for your interest The networking code was in the process of being moved to Enet, but that's not entirely done yet, no (the old code is still commented out in places). The current status allows connecting and basic communication for MP games, but that's about the extent of it. Dacian/dax was working on this, but recently became a father, so it's safe to say that it is on hold for quite some time. We'd welcome your help in this area. Can you give more details on what you'd intend to do? Why is a thread pool necessary?

hm, what kind of artifacts? Popping/Crackling? Any chance you could record a clip of the output you're hearing? Fair point. I will say, though, that OpenAL on Linux has caused disproportionate amounts of trouble - we've noticed several bugs there. OpenAL on Window seems to be much more solid. Unfortunately I don't know much about diagnosing this. Is it possible to switch to another backend? (See ~/.openalrc)

Thanks! A slightly modified version of that has been committed, and I've also added the terrains.xml for grass terrain type that was (for some reason) only present in mods/internal.

Previous post deleted You're still missing wxWidgets. Please grab all the dependencies listed in http://trac.wildfiregames.com/wiki/BuildInstructions

hm, I'm guessing here, but this bug appears to bite when an OpenAL source is reused (the second music track that's played when a map has loaded) and its properties somehow aren't reset correctly by AL and it doesn't handle the resulting divide-by-zero. I was foolhardy enough to rely on the documented defaults instead of always setting all properties - it would be better to always set every single property in vsrc_latch (even though that costs a bit of performance). Would you be interested in tackling this? That would be helpful, especially because I can't duplicate the problem (it apparently doesn't come up on X-fi, where the OpenAL implementation is a native driver instead of a software layer on top of DX)

OK, I've made a second pass through the tickets and marked a few more - please have another look at the above query URL. In particular, 307 and 311 would be helpful and straightforward (duplicate the error, see what pointer is NULL and why, fix ), and #100 might be interesting if you have a thing for sound/music/OGG vorbis. (Will be away for the weekend; have a good one + see you after)

OK hm, I'm afraid #113 might not be a good fit then - not only due to OpenGL (some knowledge would be good, to understand how the GUI renders its controls) but also because the GUI engine is also related to scripts (those drive the UI). Does anything else grab your eye?

Glad you found the problem

Greetings and thanks for your interest! Help is very welcome We've started looking through the list of tickets and adding a "simple" keyword to indicate the task is limited in scope and doesn't require knowledge of a large portion of the codebase. You can search for such tickets with the following query URL: http://trac.wildfiregames.com/query?keywords=%7Esimple Two of those are related to OpenGL and extension handling; another is basically a quick test of the game on a multiple-monitor system. If none of those strikes your fancy, please feel free to look through the list of tickets or post here and we'll find some more

heh, I see you've been lurking for quite a while But how do you reconcile the term "vaporware" with the existence of a public SVN repo and a semi-playable alpha release?

Sorry for the lack of a reply, I apparently missed this thread while on the road and coicidentally saw it now. hm, I wonder if the OpenAL framework renaming thing was bad, but if that is the first error you are encountering, then at least the device init was successful, which makes that explanation unlikely. It's possible that the values being passed to vsrc_latch are invalid. Fortunately we have some printfs that should be writing the values to stdout or stderr - do you see such output? Unfortunately I forgot to update the printfs after adding code to set distance model, so the output is currently incomplete.. have just committed a fix. Just FYI, sound problems can be worked around by launching with -quickstart . My bad, the correct path is: $XDG_CONFIG_HOME/0ad/logs, where $XDG_CONFIG_HOME defaults to ~/.config . Does the crashlog.txt exist there? (just ensuring that works, but I don't think it'll add much information in this case)

Erik is right, we haven't had many developers working under OS X. Not sure if these problems are due to Snow Leopard; have you checked previous OS X threads here? http://www.wildfiregames.com/forum/index.php?showtopic=12591 mentions NSPR and a variable that may need to be set (unfortunately this hasn't made it into the build instructions) See also http://www.wildfiregames.com/forum/index.php?showtopic=12607 with further workarounds that may be applicable.

hm, I see a slight problem that Internet Explorer (it's all I have on this laptop ) is unable to deal with: the "img src" URLs contain %20 spaces, while "a href" links are correct and work. Could you please revise those? I'm sure Philip would love to add another flag; the necessity of translation is best judged by yourself. Is the English language really that universal in .nl? Your neighbors to the east certainly aren't all capable of more than a few words of English.

Yes: "make[1]: *** Keine Regel vorhanden, um das Target »../../../source/lib/file/path.h«," since that causes make to abort, it is most definitely a problem. Interestingly, path.h was removed in r7063 (one month ago), I'm not sure how/why references linger on, especially in the graphics code. Since the error comes up immediately, it might be due to precompiled headers. Could you please grep for "path.h" in source and header files? If anything comes up, it can and should be removed. You might also try "make clean". Simple: this is an early development version, where problems are inevitable. We're happy to work together with developers to get things working on other systems, but frankly, we can't hold hands here (it'll only frustrate both sides and take away resources from development).

OK No worries, we're not in a rush..

At a guess, build.sh might contain >>> and <<< markers that indicate the conflict. In that case, you should edit that file to reincorporate idle's CFLAGS change and remove the markers.

Great stuff That's quite compact in comparison to the Latin-based texts. Philip has been adding the localized versions to http://os.wildfiregames.com/ . I've notified him to make sure he sees this. Could you please make his life easier by adding your localized text to a copy of the abovementioned HTML page that already contains the images etc.?

hm, another instance of breakage due to parallel builds.. there's a small note about this in the build instructions, but perhaps not obvious enough. (I've now bold-faced the Note:) Seems rather disconcerting that the compiler toolchain is this flaky. I'd recommend running non-parallel builds for now. Glad to hear it