Page 22 of 23
Re: Interface Redesign
Posted: 24 Jan 2009, 21:17
by imbaczek
hoijui wrote:You mean, we should have a "Hello, World" Test AI scheme, which is then implemted in each language (eg. C, C++, Java, C#) in a Test AI.
This scheme had to be working with absolutely every kind of mod, an if not everything can be done, it had to not crash at least, and report why it could not do what.
yes, exactly that; but, to simplify things, i suggest splitting every use case to separate demo AI.
An example for such a scheme:
something like this would also be of help.
it is possible to draw points, lines, paths and figures wiht the AI interface as it is now, i dont know if arrows are in fugures, or if they had to be constructed manually out of 3 lines eg.
see e.g. TryTarget in Weapon.cpp:
Code: Select all
//geometricObjects->AddLine(weaponMuzzlePos, weaponMuzzlePos+dif, 3, 0, 16);
you mean hashes for the mod and the map, to not use cached data for BA6.6 when BA6.8 is loaded eg?
if i am not wrong, this is not possible through the interface at the moment, would have to be added. is this the cleanest solution? (eg, what about mod-name + version?)
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.
Re: Interface Redesign
Posted: 27 Jan 2009, 17:11
by imbaczek
BTW I strongly suggest merging into master after you get over the build problems. I'm going to need this real soon for uni
Re: Interface Redesign
Posted: 27 Jan 2009, 17:38
by Agon
imbaczek wrote: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
Re: Interface Redesign
Posted: 27 Jan 2009, 17:44
by imbaczek
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 ^^
Re: Interface Redesign
Posted: 27 Jan 2009, 17:55
by Agon
imbaczek wrote: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
Re: Interface Redesign
Posted: 27 Jan 2009, 18:06
by imbaczek
that KP has its own AI is a good thing, i have a benchmark opponent ^^
Re: Interface Redesign
Posted: 27 Jan 2009, 18:09
by hoijui
that is the plan anyway
Re: Interface Redesign
Posted: 27 Jan 2009, 18:25
by Agon
hoijui wrote: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....
Re: Interface Redesign
Posted: 27 Jan 2009, 19:52
by hoijui
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.
Re: Interface Redesign
Posted: 27 Jan 2009, 20:14
by imbaczek
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.
Re: Interface Redesign
Posted: 27 Jan 2009, 20:36
by Agon
So we will talk about a protocol...
Which addresses hundreds of possibilities.
I think we already have something for custom resources, I'm right?
Re: Interface Redesign
Posted: 27 Jan 2009, 21:04
by hoijui
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.
Re: Interface Redesign
Posted: 27 Jan 2009, 21:05
by imbaczek
but imho the priority should be to expose engine data which is otherwise inaccessible.
Re: Interface Redesign
Posted: 28 Jan 2009, 23:35
by AF
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.
Re: Interface Redesign
Posted: 29 Jan 2009, 04:42
by lurker
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.
Re: Interface Redesign
Posted: 29 Jan 2009, 05:10
by Argh
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.
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.
Re: Interface Redesign
Posted: 29 Jan 2009, 08:59
by hoijui
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
Re: Interface Redesign
Posted: 29 Jan 2009, 14:34
by AF
Argh wrote: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.
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
Re: Interface Redesign
Posted: 23 Feb 2009, 16:05
by hoijui
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):
Code: Select all
LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:${JAVA_HOME}/jre/lib/i386/server/
while
${JAVA_HOME}/jre/lib/i386/server/ should be a folder containing libjvm.so.
It seems that this is at least needed under Ubuntu.
Re: Interface Redesign
Posted: 23 Feb 2009, 17:14
by Agon
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.