yes, exactly that; but, to simplify things, i suggest splitting every use case to separate demo AI.


something like this would also be of help.


see e.g. TryTarget in Weapon.cpp:


yes, exactly this. getting mod name, version and stuff like this should also be exposed. use case is e.g. precomputing choke points for maps/mod+map combos - need ability to access pathfinder data or heightmap+slopemap (if there is such a thing in spring, not sure) and an ability to uniquely identify which map is that.

BTW I strongly suggest merging into master after you get over the build problems. I'm going to need this real soon for uni

Oh, will you write an AI for Spring?
Or only a small AI which demonstrates an algorithm?

Seems like lot of AIs will grow up this year.
I can count 6 new AI project

indeed, i plan to write an ai, but it's going to be a KP AI because TA or any other mods are too complex ^^

Well KP has already a AI (LuaAI) so you have a small competition.

I want to write a AI, too after the MonoAIInterface of course.
But I do not know which mod or how many I want to target for support.
And I'm not sure in which language, probably C# but I do not know

that KP has its own AI is a good thing, i have a benchmark opponent ^^

that is the plan anyway

Do you mean the benchmark?

I think my interface will go under as it is now

Hoijui: If you have the most things done in the new interface maybe which should discuss the Lua(mod)<->AI thing....

was reffereing to the merge into master. i compleetly missed the posts after that somehow :/

well, if i get the branch to compile on the buildbot, next thing is to merge into master..
i guess there will be some weeks of bug hunting after that.
... and then i am willing to go deeply into LUA-AI discussions.. well we can discuss now, but i wont code anything, the merge is just much more important to me right now.

LUA AI is something that current SendToAI (or whatever it's called) can take care of. The mod and the AI should agree on a protocol and just use it completely independently of spring.

I'm more interested in accessing modoptions/engineoptions/mapoptions/player settings and generally the stuff i requested examples for.

So we will talk about a protocol...
Which addresses hundreds of possibilities.

I think we already have something for custom resources, I'm right?

yes, resources are modular, from an AIs perspective.
there are not getMetalXXX() methods, but rather getResourceXXX(int resourceIndex)
i think it would be bad if mods and AIs would define special protocols. if you want that, you should rather write a LUA AI.
I think the goal of the Skirmish AI interface has to be complete modularity. also, to some extend it has to follow a common protocol, as it all has ot pass the C barrier.

but imho the priority should be to expose engine data which is otherwise inaccessible.

We have a proposal for defining extra resources via lua that we can use right?

I would suggest we sort out the debacle that is transformations/upgrades of individual units. I cant even ask if all mods use the same implementation to pull it off, and in some cases it looks so easy to support but nobodies talking when asked, or they respond with garbage answers like learn lua.

They mostly use the same gadget, and it's a simple order to issue. Issue is that the info is only exposed in the tooltip atm.

Everything but P.U.R.E. is pretty much just using CA's Morph Gadget. It should be easy enough, with Lua-->AI, to do a query through Lua to find out whether a given command ID exists, and whether that corresponds to the known command ID for Morph.

For P.U.R.E., that approach is utterly impossible. I use a transformation method that's custom to each unit-type, and the commands aren't standardized. If anybody wants to get really serious about this topic, I have a fairly lengthy set of feature specifications I'd like to propose, that would allow for the necessary flexibility.

we should start a new topic for the LUA <-> AI stuff, or in the case of resources, we could go on here, though only the details of the implementaiton are left undecided there, and they may be better discussed when we actually will be implementing it:
viewtopic.php?f=15&t=16889

In that case you could provide a wrapper layer around you implementation conforming to an agreed interface layer or mechanism. Since morphing is quite a common feature theres no reason we cant roll it into the C API

merged into master.

i should be in the lobby these days for direct help. or you might write mantis reports in hte AI section, or fix it yourself :D

You may use SpringLobby for testing, as it is curently the only lobby that supperts the new AI system. other lobby defs can come to me for help with implementing it.

known issue:
under Linux, you will probably have to do the following for hte Java AI interface to work (runtime):

while ${JAVA_HOME}/jre/lib/i386/server/ should be a folder containing libjvm.so.
It seems that this is at least needed under Ubuntu.

Nice, no more double merging master->caiinterface->monoaiinterface.

Btw. my interface should be ready in one month or less but without a prober OO wrapper or framework.