wraitii

You probably would get a better result by simply thinning the posts at the bottom over water, to have a grid.

This is very cool . If you do enough wall variations, we could probably add it to the in-game auto-placer.

The unit speed issue has been noticed by a few team members (at least me and Scythetwirler) so it's likely to change.

My personal preference for AI behavior would also have two criteria, but those would be "difficulty" and "personality". Difficulty would basically make the AI use less varied, less efficient strategies. Personality would range from "efficient" to "plays for fun/excentric". "Efficient" AIs would try to win the game as quickly and as ruthlessly as they can. "Play for fun" AIs would just play, attacking once they've amassed a formidable army or things like that, use a wide variety of strategy (some not necessarily really efficient). Basically they'd be in control, so if you attacked them they'd retaliate and stuff, but wouldn't necessarily try to beat you as quickly as possible. The "efficient" AI would simulate a "real" MP game between players that want to win, the "excentric" one more of an MP game between two laid back players. But that requires a much more efficient AI than what we now have. For now, I agree with WhiteTreePaladin.

I've updated my script to take counters into account and changed a few other stuffs, here are the new results. The lack of hardcoded counters paints a very different picture overall. It also seems you've buffed all units attack up. SVN:balance comparison.zip

I'll look into it, thanks for reporting.

A quick guide to what C++11 can offer us (near the bottom): http://isocpp.org/wiki/faq/ Stuffs like "auto", decltype and range-for statements can improve readability. Lambda improves usability and readability. Proper usage of "move" can avoid using pointers when they should not be needed, and can help with memory management in some algos. Initializer_lists are more convenient and improve readability. It also cleans initing up a bit. Usage of "nullptr" instead of "NULL" could help us alleviate some issues with uninitialized stuffs. There's also improvements to types, and more structs can be recognized as POD (I'm fairly sure we have a few of those). You can also force arrays to be aligned as whatever you want, though I doubt we'd see the use for that. There's also language static asserts, so we will be able to ditch our macros for that, and these kinds of conveniency. Finally the STL has been revamped with convenient things like initializer lists, the move operator (good example of how a simple syntax works better now), more functions, the "unique/shared/weak_ptr" family, and we also get some useful new ones such as unordered_set and unordered_map, for which we would have had to rely on boost. And std::array if you want to.

Good move imo, the new syntaxes are interesting and it's not that big a change.

Greenlaser: sadly, Apple has made many breaking changes in OSX Mavericks (10.9), and all devs now run it, so supporting older OSes for bundles is no longer practical. You can try to compile the game however.

Nevermind, I had 100% not forgotten to remove some debug info in my last commit and that 100% did not make the water black.

Hm, I seem not to have. What do you mean by "broken"? Everything works for me so. Gameboy: what happens when you have neither Fast & Ugly not HQ water?

It's not supposed to be broken. Could you try different settings for water and see what happens?

You'll be able to do a lot more in A17 (or SVN) regarding water, so you should be able to get a better effect. The rest of your map looks excellent though.

Ah, it's alright then

You need to work on those water settings.

I've lost twice to medium. I think you can make medium hard, possibly skip current "hard" and keep very hard as it is. Possibly give them the HP buff we talked about. Sandbox and easy should be fine, but I haven't played them.

I've done my testings with "making units move faster" and the effect is 100% what I expected: gameplay feels nervous and quick. I had hardcoded into CCmpUnitMotion that all units moved twice as fast, which is a little fast, but I think changing templates so that all walking speed are between 1.5 and 2 times their current values will help the feel of the game greatly. (Merchants OTOH shouldn't be changed, they were ludicrously fast). However it also makes training times seem ludicrously long, which is bad. Training a batch of 5 women at the start of the game right now takes about 1:30 (game time), which is just a ton of idle time. (testing done using svn, not your branch)

I thought I had already amended it, in fact, but obviously my Bash-skills aren't up to par. So I'll have to update yet again. Indeed it's the minimum version stuff that goes wrong because compiling with min OSX version makes the default library libc++, whereas compiling with earlier min OSX sets it to libstdc++ (annoying) regardless of SDK, which leads to weirdness and in this case to conflicting "<type_traits" reports. Which is also why the bundle worked, like you said.

3FFA: Open a folder window, press "Alt+g", type in "~/Bibliothèque/Application Support/0ad/logs/sim_log", should be there.

Hmm, I though my last commit would have fixed that. Are you on mavericks?

Mac users: http://releases.wildfiregames.com/rc/

Okay, I have a 544Mb 7z archive and a 744 .dmg version of A16, with uPnP but not Atlas because I had some weird error and don't really want to bother. I intend to try and send the latter to Philip, asking for his feedback. Not sure how to upload it. Anyways I have succeeded at compiling SVN pyrogenesis on xCode this morning, apparently to compile it properly I should pass "MIN_OSX_VERSION" as 10.9 too or the compiler defaults to libstdc++ or something. Anyways, it worked so I'll consider OSX compilation is mostly OK now. On the other hand, Atlas compilation fails because TransformObject.cpp uses some XML stuff, in <wx/xml/xml.h>, but for some reason in the OSX config wxUse_XML is set to "false" so it can't work. Not sure how to fix that. Edit: got it up and running on an http server if someone wants to try it.

Okay I've committed the fix, I'd like someone to try and run build-osx-bundle, it should work. I might have forgotten something since I haven't run a complete recompilation of all libraries (too long) but I don't think I did. Against SVN, this will work. A16 requires a few more stuffs, but I'll do that by hand for the bundle. I'm now going to try and do a proper bundle. Edit: OK I have a 600Mb RC. It's not perfect (atlas doesn't load up, so you end up being stuck in nothingness if you click on it) and I disabled uPnP but it should work otherwise.

Those are actually changes I directly took from MishFTW before, I'll revert them as they should be unneeded. I checked the upgrade to 3.0.1 on SVN and there's a compilation error, but it seems unrelated to 3.0.1 so I'll try against A16 and see if it fixes our error. Echelon fixed the UpNp bug, if someone else confirms I could include that patch.

I've got a commit ready to go that would fix compilation on Mavericks but might break it on earlier systems (10.7 downwards ), should I commit it? Attached is the patch for latest SVN. OSXFix.patch