wraitii

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?

From svn

Any chance that it's working correctly and your GC just can't handle it? edit: mmh, seems unlikely for your 610M… Edit2: I've uploaded a different patch, that fixes the issue for me and I wonder if the "#version 120" at the top could make a difference.

I've given a look at the code. Seems like you mostly took it where I wanted but never did and fixed quite a few of the style/redundancies. I'm liking where this is going. Now I should try this in-game, but I can't see why it'd be way less efficient.

I disagree with the "usability problem" issue. There are several ways we could show the civs of other player (one I just thought of is a ring of color, à la "xbox controller", around the civ chosen by a player). We can perfectly add some quick info on top of Mythos mockup, such as the map and its size. Also, if we implement something like "double-click on a civ makes you select it" the extra click become meaningless.

Swap the "Random" for the group name (with the button still acting as random" and I'm all for it.

I can't be bothered to review all the French translations so I'd be more than happy to leave it to voluntary translators. I know I've added a few (like 10 of 'em perhaps ), but that's about it. If there's some sort of specific issue that can't be decided without team input I'd be happy to help however.

Looks fine if it's empty, to me, but I expect the full ship to be lower too. I'd put the water line somewhere around the logs/windows on the side of the hull (what are those?)