wraitii

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.

Echelon: I'm interested in your fix. Here's a patch for OSX compilation (tested against SVN at the time of A16, not sure of the release nb). I've stopped the script from force-rebuilding libraries since that redownloads the broken libiconv. To install, you should first run build-osx-libs.sh --force-rebuild, then apply the patch, then replace libraries/osx/iconv/include/iconv.h with the attached version, then run in the terminal (cd to your "libraries/osx/" folder) rm ./gloox/.already-builtrm ./wxwidgets/.already-builtrm ./libxml2/.already-builtThen run my modified build-osx-bundle.sh script. It should only rebuild gloox, wxwidgets, and lixml2, and with hope it works. I can't guarantee though, as I might have missed/misplaced a step. It's currently compiling against the 10.9 SDK with OSX 10.8 as min version. OSXFix.patch iconv.h.zip

What should we do for the OSX bundle? Release a somewhat patched A16 with no Atlas and some potential bugs?

I did some empirical tests with the AI. Wheelbarrow vs axes is very much dependent on wether you're going to micro your dropsites heavily or not. You need to keep walking distances short for wheelbarrow to be effectively better than axes overall (and particularly on wood). If you don't really micro (9s shuttle iirc) wheelbarrow is better than axes for all resources (including wood). Which isn't really a lot. But at the same time, building more dropsites to keep walking distances down dilutes the effect since you lose the resources you won. Overall this isn't the most interesting pair since their effect is really small and hard to differentiate, but I'd wager wheelbarrows is very slightly better for most players on the long run.

Success! So what I did above is sufficient, I had merely forgotten to recompile the libraries with the new iconv. After using force-rebuild (specifically, only wxwidgets and libxml2 ought to be needed, I also recompiled gloox). I've got an A16 bundle which should be OK, except it's got too many languages. Now on to catch up to SVN.

I'm not sure we need to make technologies a lot stronger, but I'd be interested in more branching stuffs, that would force more specialization.

Full error, I think: ICmpVision.cppclang++ -arch x86_64 -Iobj/simulation2_Release -include obj/simulation2_Release/precompiled.h -MMD -MP -DNDEBUG -DCONFIG_FINAL=1 -DLIB_STATIC_LINK -DBUNDLE_IDENTIFIER=com.wildfiregames.0ad -DUSING_PCH -I../../../source/pch/simulation2 -I../../../source -I../../../libraries/source/spidermonkey/include-unix-release -g -Wall -O3 -Wno-switch -Wno-reorder -Wno-invalid-offsetof -Wextra -Wno-missing-field-initializers -Wunused-parameter -Wredundant-decls -Wnon-virtual-dtor -Wundef -fstack-protector-all -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fstrict-aliasing -fno-omit-frame-pointer -fpch-preprocess -msse -msse2 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk -mmacosx-version-min=10.8 -fvisibility=hidden -isystem../../../libraries/osx/boost/include -MF obj/simulation2_Release/ICmpVision.d -MT "obj/simulation2_Release/ICmpVision.o" -o "obj/simulation2_Release/ICmpVision.o" -c "../../../source/simulation2/components/ICmpVision.cpp"Undefined symbols for architecture x86_64: "_libiconv", referenced from: _xmlIconvWrapper in libxml2.a(encoding.o) "_libiconv_close", referenced from: _xmlFindCharEncodingHandler in libxml2.a(encoding.o) _xmlCharEncCloseFunc in libxml2.a(encoding.o) "_libiconv_open", referenced from: _xmlFindCharEncodingHandler in libxml2.a(encoding.o)In file included from ../../../source/simulation2/components/ICmpVision.cpp:20:In file included from ../../../source/simulation2/components/ICmpVision.h:21:In file included from ../../../source/simulation2/system/Interface.h:21:In file included from ../../../source/simulation2/system/IComponent.h:22:In file included from ../../../source/simulation2/system/Message.h:21:In file included from ../../../source/scriptinterface/ScriptTypes.h:71:In file included from ../../../libraries/source/spidermonkey/include-unix-release/jspubtd.h:15:In file included from ../../../libraries/source/spidermonkey/include-unix-release/jstypes.h:25:../../../libraries/source/spidermonkey/include-unix-release/mozilla/Util.h:277:31: warning: deleted function definitions are a C++11 extension [-Wc++11-extensions] Maybe(const Maybe& other) MOZ_DELETE; ^../../../libraries/source/spidermonkey/include-unix-release/mozilla/Attributes.h:197:35: note: expanded from macro 'MOZ_DELETE'# define MOZ_DELETE = delete ^In file included from ../../../source/simulation2/components/ICmpVision.cpp:20:In file included from ../../../source/simulation2/components/ICmpVision.h:21:In file included from ../../../source/simulation2/system/Interface.h:21:In file included from ../../../source/simulation2/system/IComponent.h:22:In file included from ../../../source/simulation2/system/Message.h:21:In file included from ../../../source/scriptinterface/ScriptTypes.h:71:In file included from ../../../libraries/source/spidermonkey/include-unix-release/jspubtd.h:15:In file included from ../../../libraries/source/spidermonkey/include-unix-release/jstypes.h:25:../../../libraries/source/spidermonkey/include-unix-release/mozilla/Util.h:278:48: warning: deleted function definitions are a C++11 extension [-Wc++11-extensions] const Maybe& operator=(const Maybe& other) MOZ_DELETE; ^../../../libraries/source/spidermonkey/include-unix-release/mozilla/Attributes.h:197:35: note: expanded from macro 'MOZ_DELETE'# define MOZ_DELETE = delete ^ld: symbol(s) not found for architecture x86_64clang: error: linker command failed with exit code 1 (use -v to see invocation)make[1]: *** [../../../binaries/system/libCollada.dylib] Error 1make: *** [Collada] Error 2make: *** Waiting for unfinished jobs.... ANyone else reading this as "we don't link libiconv"? Is that an issue?

Okay, I found the fix for that particular issue. To recap what I did so far: Changed extern_libs4.lua to this: Changed build-osx-libs to this (lines 211/212) and also added MishFTW's changes but I don't think those are really useful with Philip's fixes: Applied Philip's change in r15231 in order to compile against libc++ and not pass any further flags. Recompiled against 10.8 SDK on OSX 10.9.3 Then I got the above error about const. This is because there is a difference between the osx libs and the win32 libs, apparently. Windows version line 92: extern LIBICONV_DLL_EXPORTED size_t iconv (iconv_t cd, const char* * inbuf, size_t *inbytesleft, char* * outbuf, size_t *outbytesleft) OSX version line 92: extern LIBICONV_DLL_EXPORTED size_t iconv (iconv_t cd, char* * inbuf, size_t *inbytesleft, char* * outbuf, size_t *outbytesleft) You might notice that there's a "const" missing in the OSX version. If you put it back, compilation works. So that works like you'd expect. Now I get a different linking error but I'll update shortly.Edit: new error, seems like Collada is linking improperly Undefined symbols for architecture x86_64: "_libiconv", referenced from: _xmlIconvWrapper in libxml2.a(encoding.o) "_libiconv_close", referenced from: _xmlFindCharEncodingHandler in libxml2.a(encoding.o) _xmlCharEncCloseFunc in libxml2.a(encoding.o) "_libiconv_open", referenced from: _xmlFindCharEncodingHandler in libxml2.a(encoding.o)ld: symbol(s) not found for architecture x86_64clang: error: linker command failed with exit code 1 (use -v to see invocation)make[1]: *** [../../../binaries/system/libCollada.dylib] Error 1make: *** [Collada] Error 2make: *** Waiting for unfinished jobs....

I changed the OSX folder to be the same as on Windows (iconv and not "libiconv"). The linking should now work. I still get errors though. ../../../source/third_party/tinygettext/src/iconv.cpp:118:18: error: no matching function for call to 'libiconv' size_t ret = tinygettext_iconv(cd, &inbuf, &inbytesleft, &outbuf, &o... ^~~~~~~~~~~~~~~~~ ../../../source/third_party/tinygettext/include/tinygettext/iconv.hpp:40:35: note: expanded from macro 'tinygettext_iconv' # define tinygettext_iconv iconv ^~~~~ ../../../libraries/osx/iconv/include/iconv.h:81:15: note: expanded from macro 'iconv' #define iconv libiconv Here's the output of make verbose=1 for that file: The "-I../../../source" bit seems suspicious. Maybe I still have a linking issue. clang++ -arch x86_64 -Iobj/tinygettext_Release -include obj/tinygettext_Release/precompiled.h -MMD -MP -DNDEBUG -DCONFIG_FINAL=1 -DLIB_STATIC_LINK -DBUNDLE_IDENTIFIER=com.wildfiregames.0ad -DUSING_PCH -DHAVE_ICONV_CONST -DLIBICONV_STATIC -I../../../source/pch/tinygettext -I../../../source -I../../../libraries/osx/iconv/include -I../../../source/third_party/tinygettext/include/tinygettext -g -Wall -O3 -Wno-switch -Wno-reorder -Wno-invalid-offsetof -Wextra -Wno-missing-field-initializers -Wunused-parameter -Wredundant-decls -Wnon-virtual-dtor -Wundef -fstack-protector-all -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fstrict-aliasing -fno-omit-frame-pointer -fpch-preprocess -msse -msse2 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk -mmacosx-version-min=10.8 -fvisibility=hidden -isystem../../../libraries/osx/boost/include -MF obj/tinygettext_Release/iconv.d -MT "obj/tinygettext_Release/iconv.o" -o "obj/tinygettext_Release/iconv.o" -c "../../../source/third_party/tinygettext/src/iconv.cpp"

I need to do something about that tail.

Hmm, for some reason the second part of my message was erased. I changed extern_libs4.lua to the following and had the above error. iconv = {compile_settings = function()if os.is("windows") or os.is("macosx") thenadd_default_include_paths("iconv")defines { "HAVE_ICONV_CONST" }defines { "LIBICONV_STATIC" }endend,link_settings = function()if os.is("windows") or os.is("macosx") thenadd_default_lib_paths("iconv")endadd_default_links({win_names = { "iconv" },-- TODO: glibc provides symbols for this, so we should only include that (and depend on libiconv) on non-glibc unixosx_names = { "iconv" },dbg_suffix = "",})end,},

I tried linking iconv. Seems to have made a difference, but it still fails. Error on compilation: ../../../source/third_party/tinygettext/src/iconv.cpp:118:18: error: no matching function for call to 'iconv' size_t ret = tinygettext_iconv(cd, &inbuf, &inbytesleft, &outbuf, &o... ^~~~~~~~~~~~~~~~~../../../source/third_party/tinygettext/include/tinygettext/iconv.hpp:40:35: note: expanded from macro 'tinygettext_iconv'# define tinygettext_iconv iconv ^~~~~/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/iconv.h:69:8: note: candidate function not viable: no known conversion from 'const char **' to 'char **' for 2nd argumentsize_t iconv (iconv_t /*cd*/, ^In file included from ../../../source/lobby/XmppClient.cpp:19:In file included from ../../../source/lobby/XmppClient.h:27:In file included from ../../../source/scriptinterface/ScriptVal.h:21:In file included from ../../../source/scriptinterface/ScriptTypes.h:72:In file included from ../../../libraries/source/spidermonkey/include-unix-release/jsapi.h:28:In file included from ../../../libraries/source/spidermonkey/include-unix-release/js/HashTable.h:14:

Same error as the pastbin above, though I don't think the warning quoted is related. I tried forcing libiconv to be 64 bit (apparently by default it's only 32?) but that didn't seem to change much. Maybe I did it wrong. I seem to recall this issue having been fixed before though. I applied Philip's changes form a later revision and run into no issues with libc++ ad OSX 10.9.3 otherwise.

I would suggest making Petra the default bot in A17. Aegis hasn't been really updated in A16, and Petra seems to me like the most resilient and efficient bot at this point.

I'll try with deleting the already built. I might have modified the build-osx script once to not rebuild spidermonkey all the time…

Okay. I don't have the 10.7SDK anywhere anymore, apparently, my Xcode is too up-to-date. So I can make the bundle, but for 10.8. 10.7 is the least used version though (less so than 10.6 afaik) so it's likely not too bad. I'm giving this a go on Mavericks on my MBA because my iMac is really outdated. I'll update this post later. Edit: getting this error: ../../../source/scriptinterface/ScriptTypes.h:71:10: fatal error: 'jspubtd.h' file not found#include "jspubtd.h"

I'll give this a try tomorrow during the day, it'll likely fail so I'll try to fix the issues.

Ais use undefined variables to check for stuffs that are… undefined. Such as a garrisoned unit has no position, so it's position is undefined, and the variable will be too. I too really like the fact that spidermonkey is stricter.

800x600 is simply small in today's world. Basically any computer would support 1024x768. it's not worth it. As for the original idea, perhaps renaming it "Options & Tools" would solve the problem?