historic_bruno

Now that sounds like some incentive I doubt they'd give one to just anybody, it would probably have to be one person associated with 0 A.D. who was trusted to actually produce something. That said, I think it's a much better deal for them than it would be for us.

Not a priority, but while you're working on the sound manager, could you look into fixing the build when "--without-audio" is used? Here are the build errors I get with that build option, on Windows: 1> SoundManager.cpp 1>..\..\..\source\soundmanager\SoundManager.cpp(97): error C2061: syntax error : identifier 'ISoundItem' 1>..\..\..\source\soundmanager\SoundManager.cpp(214): error C2143: syntax error : missing ';' before '*' 1>..\..\..\source\soundmanager\SoundManager.cpp(214): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int 1>..\..\..\source\soundmanager\SoundManager.cpp(214): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int 1>..\..\..\source\soundmanager\SoundManager.cpp(215): error C2143: syntax error : missing ';' before '*' 1>..\..\..\source\soundmanager\SoundManager.cpp(215): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int 1>..\..\..\source\soundmanager\SoundManager.cpp(215): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int 1>..\..\..\source\soundmanager\SoundManager.cpp(43): error C2065: 'm_Items' : undeclared identifier 1>..\..\..\source\soundmanager\SoundManager.cpp(43): error C2061: syntax error : identifier 'ItemsList' 1>..\..\..\source\soundmanager\SoundManager.cpp(44): error C2065: 'm_DeadItems' : undeclared identifier 1>..\..\..\source\soundmanager\SoundManager.cpp(44): error C2061: syntax error : identifier 'ItemsList' 1>..\..\..\source\soundmanager\SoundManager.cpp(83): error C2653: 'ItemsList' : is not a class or namespace name 1>..\..\..\source\soundmanager\SoundManager.cpp(83): error C2065: 'iterator' : undeclared identifier 1>..\..\..\source\soundmanager\SoundManager.cpp(83): error C2146: syntax error : missing ';' before identifier 'lstr' 1>..\..\..\source\soundmanager\SoundManager.cpp(83): error C2065: 'lstr' : undeclared identifier 1>..\..\..\source\soundmanager\SoundManager.cpp(83): error C2065: 'm_Items' : undeclared identifier 1>..\..\..\source\soundmanager\SoundManager.cpp(83): error C2227: left of '->begin' must point to class/struct/union/generic type 1> type is ''unknown-type'' 1>..\..\..\source\soundmanager\SoundManager.cpp(84): error C2065: 'lstr' : undeclared identifier 1>..\..\..\source\soundmanager\SoundManager.cpp(84): error C2065: 'm_Items' : undeclared identifier 1>..\..\..\source\soundmanager\SoundManager.cpp(84): error C2227: left of '->end' must point to class/struct/union/generic type 1> type is ''unknown-type'' 1>..\..\..\source\soundmanager\SoundManager.cpp(84): fatal error C1903: unable to recover from previous error(s); stopping compilation

I doubt there's any such effort, but since it's an experimental port anyway, the usual technique to make it compile has been wrapping the offending code with CONFIG2_GLES macros: #if CONFIG2_GLES #warning TODO: implement this for GLES #else ... //GL code that won't compile/run here ... #endif // CONFIG2_GLES and then hoping it works Granted nobody has worked on that since Philip, and that was last year. It's even more fun if you try compiling against GLES on Windows, I don't recommend trying that. Judging by the activity in this topic, it would appear nobody is both interested in the Android port and willing to spend time making it work. I certainly don't see why effort should be put into maintaining compatibility when nobody tests it anyway (according to Philip, there have been exactly 2 users who succesfully ran the game on Android, and at least one of them was him). I also don't know how wise it would be to try, if myconid is still interested in redesigning the renderer, much of the existing code would change - fixed function would go away, which is relevant. I did try building for iOS and that required solving all the GLES build errors, so perhaps I'll dig up that patch and see if it still applies. I didn't do anything special though, just commented out a bunch of stuff as described above.

What is the error message? Check the game's error log (http://trac.wildfiregames.com/wiki/GameDataPaths)

Should be fixed in r13106.

I really like the look of the animated propped horses in the Persian stables, if it's not any more work, it adds a lot to the realism

0 A.D. doesn't use Java, so it wouldn't matter either way Apparently this exploit was quite serious though, we even had the Department of Homeland Security (US government agency) warning people to disable their Java plugins. I rarely seem to need Java when browsing, so I'd be happy to leave it disabled and then enable it in situations where I need it.

How do you mean? There are a lot of view options available under "Camera control settings" in default.cfg, around line 126.

Is that really the cause of the error? Looking at the programmer's guide and OpenAL Soft's code for alGenSources, it seems AL_OUT_OF_MEMORY is returned when the memory allocation fails by returning NULL instead of a valid address, not related to the number of sources available (which could be AL_INVALID_VALUE?) Unless I'm completely misunderstanding it. Edit: hmm digging a bit deeper, it seems AL_OUT_OF_MEMORY could also be thrown from the lowel-level API and is possibly related to sources.

It appears we're close to that level of graphics, the main things we're lacking now are splash effects, wakes and simulated boat "physics".

Personally, I haven't. Can you make/find some screenshots, videos, diagrams or something?

Correct, while perhaps the best known and most entertaining example of Middle English would be Chaucer's Canterbury Tales, this is how the prologue begins: which is almost readable when transcribed that way, though if we were looking at the old manuscript, it would seem like, well... ancient Greek to most of us I am actually fascinated by languages, but never seem to find time (or energy) to study them. And anyway when I can read works like Íslendingasögur or Kalevala in my native language, there's no need to become proficient in Old Norse or Finnish, of course the end result is only as good as the translator If I may ask, why would a Belgian need to learn Middle English? Is that university level or primary school

Am I understanding correctly that it's possible/required to break into a single script runtime/thread while the others continue running? Don't debuggers typically work by breaking all threads simultaneously? Though perhaps that's the tricky part, knowing how to suspend the various runtimes so nothing bad happens?

To clarify, build-osx-bundle is an automated process, there's no need to open anything in Xcode, though of course you do need Xcode installed for its SDKs. I think there's some confusion about the procedure for using that branch. There are two choices: 1. build a loose binary with Xcode/command line, in this case you want to run build-osx-libs.sh first, followed by update-workspaces.sh, then you're ready to build with gcc/xcode4 2. build a bundle using build-osx-bundle.sh which doesn't involve running Xcode or anything else (assuming it succeeds) They are meant to be mutually exclusive. It's not really desirable to mix the steps, though if done correctly I see no harm in running build-osx-bundle.sh first, which builds the libraries against a specific SDK and deployment target rather than the system default, and then reusing that to do another non-bundle build. In fact, I often do this simply because it takes so long to build all the libs again. Those are only warnings, if you look at the full build log, you should find the error that caused it to fail. It might be better if you run update-workspaces.sh after using build-osx-bundle.sh. When you do, don't use any SDK or bundle options, as those are only for a command line build (Xcode probably has its own special ways of handling SDKs, deployment targets, and bundles, in the project files).

Destroying your buildings is a drastic measure and not usually desirable since you'll also lose big chunks of territory, better to fight to the end. To solve the "exploit"/flaw you mention, what if we made it so that a player can't destroy their own buildings if loyalty is changing, or recently changed? It makes some kind of logical sense, if you're not fully in control of the building, how could you manage to destroy it?

Cool! I, for one, am thankful we didn't have to learn Old or even Middle English in school Unless a modern translation of Beowulf counts.

Are you sure the patch applied correctly? It doesn't look like it, I suggest reverting your working copy, deleting the added files from the patch (source/scriptinterface/DebuggingServer.*), then reapplying it.

The mentioned updates are now available on the osx-build branch. I've confirmed that the new xcode4 workspace builds with Xcode 4.5.2 and the command line tools installed on Lion. (This version of Xcode doesn't include the 10.6 SDK, which may or may not pose a problem in practice, but it doesn't seem 100% required for building a 10.6 compatible app) I'd be interested to see how it works for you and anyone else on OS X, as it's getting to the point where I'm considering merging it into SVN.

FYI it doesn't work this way in my patch for #1174, the building rising is tied into building progress %, not health level.

I don't like this solution because if enemies are damaging the foundation at very close to the rate you are building it, it will never be finished. Does it make sense in the real world? Yes, but in terms of gameplay it's a worse solution. At least give the player a chance to build it and train some units. To make it clearer to the player what the construction progress is, we could display a floating completion percentage above the foundation (or the rising building preview which I'm working on in #1174). This percentage would always start at 0% and end at 100%, no matter how damaged the foundation might be.

For what it's worth, I tested osx-build with Xcode 4.3 on Lion with r13065 and r13066, it built perfectly on the first attempt I've upgraded to Xcode 4.5 and as soon as our Github repo is updated, I'll test again with that. Out of curiousity did you run ./build-osx-libs.sh in /libraries/osx directly? It shouldn't use libnv*.dylib at all, since it should be linking NVTT statically.

Anyone know which license applies to the textures/icons inside "binaries\data\tools\atlas"? How about "build/resources"? I created 0ad.png and ps.ico from the large 0 A.D. logo in Art SVN, is it CC-by-SA? I'm working on http://trac.wildfiregames.com/ticket/1682

Ok, I've found the problem, it actually exists in SVN as well and has for some time. I was wondering why on some projects, Boost was the only library being linked, and also the cause of your error. During the build process, we don't link against anything for static libs, as that causes problems in Xcode, which this comment in extern_libs4.lua explains: This worked fine in the past, it simply ignores the link settings for projects that are static libs (they get pulled in by dynamic libs and applications instead). But we modified Boost's link settings once, and accidentally put them in the wrong spot, the result is the above logic doesn't catch that, and Boost is linked even for static libs. This is the cause of your error, which is Xcode specific. I will commit a fix to SVN and then push it to my Github repo as well. Thanks for testing!

Oops, I was wrong, it should be using libtool (which can pass flags through to ld), the problem is that for some reason the Xcode project doesn't have the paths to the libs matching my osx-build branch. Tested the Premake Xcode4 support, it seems to fix the various upgrade warnings and adds a single workspace, though it still looks like a pain to switch between release and debug builds. I don't see any problem with committing it to SVN. It's unrelated to this particular problem though.

gdb Though I do most of my development on Windows, so it's rare that I need to debug on OS X specifically. Looks like the latest Premake beta supports Xcode 4, I'll look into whether we can easily integrate it.