historic_bruno

Something messed with it, if it was modified It looks like Awesomium is 32-bit only in OS X, so if it did alter any system files, that would potentially cause problems building a 64-bit binary. Anyway it's very naughty behavior, there's no excuse for modifying those files (unless an OS X update is responsible).

Try a clean build with this command before building: export CC=llvm-gcc CXX=llvm-g++ Edit: actually for the clean build I'd suggest ./clean-workspaces.sh first, then update-workspaces.sh, etc. Maybe not required but I like to clean everything when changing the compiler.

It would be a good opportunity to change the idle animation as well, it's very irritating...

Assuming you're using MacPorts, can you check which wxWidgets port is installed? "port -v installed wxWidgets-devel" ought to do it. Also make sure you don't have the old wxWidgets 2.8 installed by mistake: "port -v installed wxWidgets". It might be a good idea to update MacPorts and the installed ports as described here - but I can't guarantee that will solve your problem. Didn't you update Xcode recently? Have you installed anything on the system that might have modified the OpenAL framework? Someone had a similar problem here and the solution was to replace the framework from another source. I'd make a backup first, just in case, but it surely doesn't seem like a 0 A.D. issue.

I don't think previews should even cast shadows.

You mean the the "naked fanatics"? Wikipedia says:

You can add it to contributors.txt as well, after A12 is released When I updated that file, I didn't use people's real names unless they mentioned them publicly, as in their forum signature.

I don't think triggers should have anything to do with random maps, unless you are creating a random interactive scenario... Otherwise, if the random map generator needs to know something about entities before it places them, we just add entity template parsing into the random map generator. It's really no big deal, we only have to get to it eventually.

It sounds like a primitive AI, only with the UI included as part of the state it can affect/respond to. So it's a matter of determing which state the triggers need and building that state. We already do something very similar in the GuiInterface component. I would recommend not inventing our own scripting language, nor adding some other, instead we can use JSON for ease of integration with existing scripts. A single JSON file could define a "condition" with its description, unique name and expected parameters (what the scenario designer will see), and a condition function to evaluate. An "effect" JSON file would be similar only with an effect function to evaluate. We could have a library of functions (API) to save trigger devs from writing a bunch of state accessors and tests. Example condition file: Example effect file: The advantage would be every condition and effect fits that template, and the only complicated part is for the trigger devs to write the logic. There should be enough state provided to evaluate any useful condition and effect; if something is missing, we add it. A trigger would consist of one or more conditions (or in the simple case, only one), one or more effects, and the parameters selected by the scenario designer. Each trigger would have a unique ID, so they could reference eachother, you'd end up with a hierarchy that allowed fairly complex behavior. I suppose that would also be JSON, embedded in the scenario's XML, as we do for map settings currently. Example: Mostly you'd never look at the "raw" trigger data, because you'd have a UI... The Atlas UI for creating triggers might be the hardest part, it would need to clearly show the relation between triggers, the logic of conditions for each trigger, and offer controls for the parameters of both conditions and effects. C++ parsing of JSON is yucky, but it would be minimal in this case, really only name (string), description (string) and parameters (list - but we might have to worry about types and data validation?)

Hi, this might be a good resource for beginning: http://trac.wildfiregames.com/wiki/Modding_Guide . It's only an overview but it has links to useful documentation.

For what it's worth, the new pathfinder may avoid that entirely. See the work-in-progress very old patch here.

Nice job tracking that down. Fixed in r12793

Nothing personal, but we don't need someone's personal agenda pushed on 0 A.D. Leave the German antifascist scene in Germany where it belongs, please.

Floating point arithmetic isn't safe in the simulation code due to hardware and compiler differences, it must produce identical results for each player in a multiplayer game.

Hi, were you using time warp by chance? That feature is not intended for heavy use and will eventually cause an out of memory error.

For what it's worth, this looks identical to http://trac.wildfiregames.com/ticket/1662 and there are some other recent reports of "too much recursion".

You could make a script that contains that command, updates workspaces and builds the game. I think you could also add that line to ~/.bash_profile

The legal argument against having swastikas in the game seems tenuous at best, it appears to be more of a cultural/social issue for a minority of the game's users, and in that case, how many groups do we have to appease to release 0 A.D.? How much history do we need to revise or erase before it's approved by the politically correct? The Mauryans existed outside the context of modern Germany, free of its guilt, they had their own history, and the same is true of modern Asians. The swastika is still used to this day, totally independent of Nazism. We would be doing a disservice to the Mauryans and Asian cultures by removing this symbol if it was truly important to them. To me that is just a form of cultural imperialism; the rest of the world has to alter its history to suit the sensitivities of modern Germany. Can you imagine being made to feel ashamed for seeing or using a symbol your ancestors have used for millennia because someone in Germany distorted that symbol 70 years ago into something awful? Me either. Edit: and more to the point, a lot of websites for example host content that is illegal in Germany but legal most other places. Music, videos, art, and writing to name a few media. The solution is pretty simple, you have a disclaimer that says there may be content that is illegal in Germany. If anyone is really worried beyond that, there could be a patch to remove the offending content from the game.

Even though players won't typically see these "first person" perspectives, many of them look good enough that we should consider making trailers with that view or even using it for cutscenes in campaigns

For some reason, I don't get this bug anymore. Can you confirm, zoot?

The Save As dialog is misleading because it appears to give you the choice of where to save the file, but really it will save it in the currently loaded mod directory. On most OSes that will not be writable and it will fail. Indeed it would make more sense to save them somewhere in the user's home directory, but the engine needs to be modified to handle that and a few other cases. It's on our TODO list Meanwhile, it might have saved the map in the cache folder, can you check that? http://trac.wildfire...i/GameDataPaths

Also the EXE is part of SVN, included for Windows users, so you'll always see that.

We do have a major African civ, Carthaginians I seem to recall a vague plan of having some African mini-factions eventually, but that would be low priority compared to everything else (mini-factions would mostly be included for scenarios, not a fully playable civ). Mauryans will be a major Asian civ. Additionally, we may have a Chinese "mod pack", as an example of a mod pack. I'm not in favor of adding American civs though. If you can name other major civs we've neglected that fall into the timeframe of 500 B.C. to 1 B.C. then go ahead

That would only be for UI scripts wouldn't it? I believe zoot is referring to simulation code, which is in a different context. Either way, I think the sound manager should be responsible for this, including managing how the transition takes place (peace <-> battle).

That's the purpose of this topic