wraitii

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

Some update on the iconv.h issue: basically the configuration script does some magic around lines 14000-15000 that makes it decide against setting ICONV_CONST, which results in the iconv header being non-const, which is different from the win32 version we're shipping. I'm really not sure why, or how we can change this since I have the hardest time reading configure. There are a few ways to fix this, we could: -find some way to have configure pass ICONV_CONST — a proper fix, but can it be done? -Patch libiconv after downloading to always act like we passed ICONV_CONST. This could be done in a variety of way: patching include/iconv.h after compilation, patching configure, … -change our code in source/something so that it doesn't expect a const iconv. I'm leaning towards patching so far. The rest is basically already fixed, and I've mostly figured out why imo, so I'll try to get it clean and commit the code. Edit: wait there's actually something in extern_libs for that which could fix the issue.

Okay I have succeeded at compiling against latest SVN on my iMac which was fairly clean. The steps before SHOULD alone work, only you might have to re-copy iconv.h after the first build-osx-libs.sh and retry. Also you will most likely need to pass --disable-atlas to update-workspaces.sh since for me it crashed (wxXml… issue). Edit: success on my iMac too. Both of my computers are on 10.9.3 and my system works for A16 and svn. I would like someone else to try and confirm, possibly with help over IRC.

This is the kind of beautiful, simple idea that would probably never have occurred to me (who did the other rewrite). It's probably a better solution than mine too. I might just update my patch to work with that method and revert to the dynamic sized template. AFAIK we have found no better system than a simple grid.

I'm going to take a different stance form Yves here. Triggers imo should be powerful, but utterly limited to the map. Of course you could code victory conditions in them, but we don't have to, so I really don't see the point. If people want different game modes, they can ship a mod, it'll work better. I don't really have any comment otherwise, except that the most powerful scenario editor is RoN since the triggers were actual scripts

Hmmm, I've got some weird news. I get the error you get, but only when trying on Xcode. If I run "build-osx-bundle", I get no such error. For some reason. Try removing the boost and gloox folder and running build-osx-bundle, which should call build-osx-libs to rebuild those, and see what happens.

I'm pretty sure Aegis has function that takes a template and returns a "powerfulness" scalar.

Odd. Your error message says ./../../libraries/osx/iconv/include/iconv.h:83:15: note: candidate function not viable: no known conversion from 'const char **' to 'char **' for 2nd argumentextern size_t iconv (iconv_t cd, char* * inbuf, size_t *inbytesleft, char* * outbuf, size_t *outbytesleft);Which seems to be different from your actual file.Edit: that second error seems like the old boost using libstd++. Check out this post. I wasn't sure if that was necessary, but it seems to be. Edit: Hmmm, I got the same error you do, tried adding MishFTW's stuff back and still get it. This is weird.