[ANN] Baczek's KP AI 1.2

[zwzsg]

I believe it would be the hight density of datavents, as I saw the Lua AI beat the C++ AI on major madness as well, in a System vs System duel. The Lua AI doesn't care about anything but datavents, it assign troops to datavents, more on the frontier line, less inland, and attacks by reassigning them to enemy owned datavents. While your AI seem to handle groups of units independantly of datavent placment. So when map is covered by datavents, this somehow helps the Lua AI.

Another factor that helps the Lua AI, also noticeable in human vs Lua AI fights, is that its knows to flip the bug.

[imbaczek]

yeah, my AI consistently fails as hacker. known issue.

[zwzsg]

No, it's not that bad as hacker. It's bad against hacker: Baczek's KP AI tightly grouped units are easy target for KP Lua AI obelisk and exploit. Maybe make units move out when under fire?

But cheer up, of all three AIs that can play KP (afaik), yours is still the best.

[hughperkins]

edit:
is it possible to programmatically add a dir to the library path?

I don't understand. I thought you'd magically solved this problem in your C and Java interfaces? At least, the C interface appears to be a dll/so in a subdirectory AI/Interfaces/C/0.1? What information am I missing?

By the way, I am very impressed that you managed to tidy up the dlls into subdirectories like that that It is much tidier now.

[hoijui]

the talk was about a 3rd party native lib, beeing used by a native AI, and the 3rd party lib would be linked at link-time (thtas what you usually do, with GCC you do it eg like this: "gcc ... -L/my/libs/dir -lmyLib ..."), not at runtime (in the code: myLib = LoadLibrary("myLib")).
It is not possible to sovle this nicely, if you only know the dirs to add at runtime.
..well.. the full explanation is longer, but maybe you get it, nad if not.. it does not matter, cause its not possible and not worth putting time in (i did some investigation about this back then).

[hughperkins]

the talk was about a 3rd party native lib, beeing used by a native AI, and the 3rd party lib would be linked at link-time (thtas what you usually do, with GCC you do it eg like this: "gcc ... -L/my/libs/dir -lmyLib ..."), not at runtime (in the code: myLib = LoadLibrary("myLib")).

Your idea about preloading the dll with loadlib in an earlier post sounded like it ought to work. I'm not sure why it wouldn't. What issues did you see when you tried this?

Edit: what I mean is: if the code that loads the AI dll first preloads the additional required dlls, then the AI dll should I feel use those preloaded dlls.

So, one way forward for example could be to embed the names of dlls to preload in AIOptions.lua, and get the AI interface to preload them before loading the main AI.

Edit2, just to illustrate this graphically.


At the moment:

Code: Select all

Spring
    -> loads   C Interface dll
             ->  loads Baczek AI
                     -> causes thirdparty.dll to immediately load, or fail to load
                     - later call to loadlibrary is too late

Maybe worth trying:

Code: Select all

Spring
    -> loads   C Interface dll
             -> reads list of third party dlls from AIOptions.lua
             -> preloads thirdparty.dll with loadlibrary
             ->  loads Baczek AI
                     -> thirdpartyAI.dll already loaded, so link is just fine
                     - calls to thirdparty.dll go through ok

[slogic]

depends.exe (comes with Support Tools) shows me the following DLLs are not needed:

• boost_date_time-vc90-1_39.dll
• boost_regex-vc90-mt-1_39.dll
• boost_signals-vc90-mt-1_39.dll
• boost_system-vc90-mt-1_39.dll
• boost_thread-vc90-mt-1_39.dll

You can throw them from archive.

[imbaczek]

this, uh, depends on the compiler. if you're using the msvc version, i'm 99% sure those dlls are needed.