wraitii

Do report it here, it's as good as any other place (also, please post your map settings)

Allright, everyone, so this has finally been committed to SVN, and will show up in Alpha 13. A short list of new features (the AI referring to Aegis): -Speed ups in many parts of the AI, in particular having many Aegis Bots should be noticeably faster (though not yet fast) -Improvements in many parts of the AI. Defense should be slightly better, dropsite placement has been noticeably improved. Aegis should be able to be more efficient. Many many bug fixed. -Support for technologies. Aegis itself goes up in phases, and will research technologies (though it chooses which randomly) -Early support for naval maps. On some maps, the AI will build a dock and try an amphibious attack (very experimental still). -Early difficulty support. You can choose from one in three settings (note: this may get a GUI side before Alpha 13). More technically: You may experience a little lag when the map generation reaches 100%: that's from the AIs initializing. It should not feel too long. I can't recall if there was still some, but that should seriously help with the weird "initial lag" that sometimes happened right at the start of a game. Expect Aegis on the hardest difficulty to be noticeably sharper in the first 15 minutes if you leave it alone.

Caused by some changes I did to the AI system yesterday. Will be fixed anytime. Thanks for reporting!

I think he means some sort of adaptative AI that would learn from the player/games and slowly improve. They're quite in fashion right now, I'm not sure how efficient they could get though, but it'll be very interesting to see anyway .

And of course the Wilhelm now and then. (note: not actually advocating it)

You need to look in source/simulation/components, for the AIManager (and the corresponding AI interface stuff in both c++ and js). Basically, what you want to do would require changing the AI Manager substantially. Right now it calls a JS script, and gets info about the simulation from another JS script. You will want to change that script to give you any information you need, and you will want to change the AI manager to work in C++ (that is actually mostly trivial once you have parsed in C++ the javascript simulation state.) Most of what you described is already possible. However, the code might need a little time to get used too.

Gave it a go in release mode. Seems to work pretty nicely, doesn't slow it down toooo much (basically a .5 second lag quite regularly. Seems AI tied but can't be too sure)

Perhaps we could have minimap modes. One where the terrain would be shown, much like now. One "strategic", where it would basically only show information relevant to gaming.

I regularly play with Engine.SetSimRate(10) or so, usually get the same messages, but no crashes.

I believe there is a "cheat" command in command.js that the AI can fairly easily call.

Confirmed by philip and apparently someone else on IRC. Compiles cleanly on my mac, though.

Look pretty cool.

Pretty sure the third bug is fixed to some extent on the upcoming (whenever it is) new version of Aegis.

I'm not quite sure about the quad tree/octree thing. There might be a slight speed up which would be interesting to have. As Philip said yesterday on IRC, we must be wary of the cost of updating entities in the octree. This could get high. Perhaps we could rather use an octree/quadtree with some added pointers to their direct neighbors, instead of having to go the long way in some cases. Would be longer at initializing but probably faster later on. Basically we need to take into account that we're having an RTS with fairly small maps, not an FPS (for which octrees seem more fitting)

AI-wise, I can expect to commit API v3 (with some changes before committing) this summer, and probably even keep working on that, adding some of the ideas I already discussed, and likely improving naval and tech support; then focusing on speed optimizations. By the end of summer, I can reasonably expect the AI to be able to handle most of the game's feature at least basically. Can't say too much about speed, but I should be able to at least put some work on it.

This is still pretty important so there have been elements of progress. But obviously it's not too easy. AI support is still a pretty long way. it is however planned, as an AI without (even basic) naval support won't be satisfactory.

FYI, it compiled on my iMac (under 10.8 or 10.7, can't recall), which does have macports. So it might not be strictly linked to that.

Looking pretty good. Not too sure about the specular (makes it kinda plastic on the armor/textile) or the actual game rendering, but it looks good overall. The hero elephant in particular is really great!

I'm getting a -liconv but no libiconv with that link. It's indeed the same error I had.

The V3 API (uncommitted) does go up in phases though. So progress is not as stalled as it seems. This is indeed one of the areas where the AI will be improved.

I'm getting this error against 10.7 using the bundle maker: Undefined symbols for architecture x86_64: "_iconv", referenced from: wxMBConv_iconv::wxMBConv_iconv(char const*) in libwx_baseu-2.9.a(baselib_strconv.o) wxMBConv_iconv::ToWChar(wchar_t*, unsigned long, char const*, unsigned long) const in libwx_baseu-2.9.a(baselib_strconv.o) wxMBConv_iconv::FromWChar(char*, unsigned long, wchar_t const*, unsigned long) const in libwx_baseu-2.9.a(baselib_strconv.o) wxMBConv_iconv::GetMBNulLen() const in libwx_baseu-2.9.a(baselib_strconv.o) (maybe you meant: __ZN14wxMBConv_iconvD0Ev, __ZN14wxMBConv_iconvD1Ev , __ZN14wxMBConv_iconvD2Ev , __ZTV14wxMBConv_iconv , __ZN14wxMBConv_iconvC1EPKc , __ZN14wxMBConv_iconvC2EPKc , __ZTS14wxMBConv_iconv , __ZTI14wxMBConv_iconv , __ZNK14wxMBConv_iconv5CloneEv , __ZNK14wxMBConv_iconv11GetMBNulLenEv , __ZN14wxMBConv_iconv14ms_wcNeedsSwapE , __ZN14wxMBConv_iconv16ms_wcCharsetNameE , __ZNK14wxMBConv_iconv9FromWCharEPcmPKwm , __ZNK14wxMBConv_iconv7ToWCharEPwmPKcm , __Z18new_wxMBConv_iconvPKc ) "_iconv_close", referenced from: wxMBConv_iconv::~wxMBConv_iconv() in libwx_baseu-2.9.a(baselib_strconv.o) "_iconv_open", referenced from: wxMBConv_iconv::wxMBConv_iconv(char const*) in libwx_baseu-2.9.a(baselib_strconv.o) ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) make[1]: *** [../../../binaries/system/libAtlasUI.dylib] Error 1 make: *** [AtlasUI] Error 2 make: *** Waiting for unfinished jobs.... (I'm compiling with Clang but I'm also getting it with Gcc). The other path works just fine.

It looks pretty good. Quite a sturdy warship so the swords and things like that don't seem like that big of a problem. It feels kind of un-intimidating though, which may or may not be an issue.

I believe this was discussed and agreed upon at some point, but it has not been implemented (at all) now.

Ah. Then I believe the word bad accurately describes this situation. Though then again 4 Aegis at 200 units is not exactly fast right now...

Certainly. 40ms alone seems a lot though, I assume debugging slows things down slightly.