Interface Redesign

[AF]

It is the lobby that writes the start script

[renrutal]

I'm looking forward to use the Java interface.

[hoijui]

nice to hear renrutal
but.. its still some time till then.

so AF, how would you like it to be then?
GAME//AI0//type=LUA & GAME//AI0//name={name}
this is BrainDamages preffered sollution, and mine too.
to easy up life for lobbies, unitsync could add a property to AI infos:

Code: Select all

type=LUA
or
type=skirmish

the lobby would just have to write this value to the start script (for all types of AIs), and therefore could treat all AIs in the exactly same way. ok with that?


right now, i am revising the engine internal workings of the AI interface, to better meet AFs proposal from the first post of this thread (see below). I wanted to get the group AI C interface going, and read this post again, and it was the first time i actually though i understood the idea that you had, AF :D
I am now working on this again, so the work on the Java interface is paused now.

[AF]

tbh I think ti should be the lua AI info file that specifies the interface, the lobby should not need to know in order to specify the AI.

However the lobby should still be able to get information about the interface and type of an AI, not for engineering or technical purposes, but to better inform the end user should the GUI allow it.

[Agon]

I made a request, maybe 'we' can include this in the AIOptions.lua file?
http://spring.clan-sy.com/phpbb/viewtop ... 21&t=16791

[Agon]

Found a problem with a name of a variable.

Code: Select all

struct InfoItem {
	const char* key;
	const char* value;
	const char* desc;
};

Code: Select all

const char* value;

This should be renamed because C# is using the value tag in its language specifications.
I suggest the name "data".

[Tobi]

IMHO the wrapper code should just take care of this (and expose it as e.g. 'value_' or '_value' or 'data' even in C#). There are too much keywords in too much languages to try to prevent clashes with all of those...

[jcnossen]

Also, i think 'value' is only a C# keyword within a property get/set method body, so it rarely causes a problem.

[AF]

Is it possible that we could have an SDK? A build of spring and headers all set up so we can immediately start using the new interface without having to set up spring and mess with svn revisions?

If its possible perhaps we should discuss merging the C interface into trunk in development so that buildbot could serve this purpose and we can focus on development of the libraries implementing other languages and testing.

[imbaczek]

+1 for merge soon.

[AF]

I believe its time that this interface be deployed as quickly as possible so we can get mass exposure and drive AI development

[hoijui]

bibims buildbot can build branches:

Code: Select all

!rebuild [sys=windows|windows64|linux] [rev=<revision>|HEAD] [upload=yes|no] [branch=<branchName>] [tag=<tagName>]

and translate stack traces for branches:

Code: Select all

!translate file=<URL> [rev=<revision>|LAST] [branch=<branch>] [tag=<tag>]

i am integrating things from the branch into trunk already, eg exportdefines.h. basically everything not under AI/ nor rts/ExternalAI/.
but yeah, i want to do it soon too. i wanted to have the Java interface usable before though.
i also would like some testing before the main part gets integrated into trunk, as it includes lots of changes and there were initial problems with all others that tried/used the branch so far. i forgot uploading files, it was needed to have env vars set, they had problems cause they use a different compiler or at least version.

before merging, i will also make the remaining AIs use the new interface and test them (so far, i only used RAI and KAIK for testing).

what i want to do before the merge into trunk, in short:

• get Java interface usable (only major part missing is one relatively big awk script)
• merge not AI specific changes into trunk
• make rest of AIs use the new interface (very little work, if no problems arise)
• some testing (would appreciate help of 3 or 4 people for that)

SDK:
I didn´t think on that so far. But .. it is kind of not my business.
I think we need no SDK for AI Interface development, as this is complex enough for that we can expect devs to have a look at the code, the wiki, ask in the forum for help and use other interfaces as examples or kick offs.
For AI development, each Interface library (eg C, Mono or Java) would need its own SDK.
I dont think we should have an SDK for the Legacy C++ interface, as we want it to disapear slowly, and it works the same way as before, so devs of existing AIs wont need an SDK, as they already know how it works. I also don't expect that anyone wants to code a C AI, so an SDK for it would be pointless. A new C++ interface (event based?) should be little work, but first had to be done before we have an SDK for it.
When the Java interface is usable, I will do an SDK for it. I think of a simpe shell script, that copies some files together and creates a zip.

[hoijui]

This idea came up because we were discussing how make (Mod specific) LUA stuff available to Skirmish AIs:
instead of having methods like getMetalIncome(), getEnergyIncome() and getEnergyUse(int unitId), we could generalize/abstract the resource related methods:

Code: Select all

int getNumResources();
const char* getResourceName(int resourceIndex);
bool getResourceGoodToHave(int resourceIndex);
...

float getResourceIncome(int resourceIndex);
float getResourceStorage(int resourceIndex);
float getUnitResourceUsage(int unitId, int resourceIndex);
...

all mods would have resourceIndex=0 -> "Metal" and resourceIndex=1 -> "Energy", plus optionally other resources defined in a LUA file in the mod VFS: resourceIndex=2 -> "Ammunition".

I will use this in the new AI interface (it will only support Metal and Energy in the beginning).

Any comments?

[AF]

I support this, although initially we would need to preserve backwards compatibility so that we can port the AIs over to the new system. I can imagine for full flexibility a number of refactors and changes will need to be made, however, in the meantime in each ai we can just search for metal and energy and use the IDs for those as a short term fix untill a proper fix is applied.

[hoijui]

I will not change the C++ interface, only the C one. Therefore, this change is not visible to the current AIs because of the Legacy C++ interface wrapper (which i will adjust to map these new functions to the old C++ ones, as you described, AF.
For now, i wrote rts/Sim/Misc/ResourceHandler and rts/Sim/Misc/Resource (only in the C AI Interface branch so far, and not yet comitted).
So far, the CResource class has std:string name and bool goodToHave and the ResourceHandler contains just a vector with CResources. A "Metal" and and "Energy" CResource are added by code in hte constructor of the ResourceHandler. I will only use these two classes in the new AI interface (for now).
It is very little code, and can easily be changed or removed again in the future.

[Agon]

Lurker has written a concept for multiple resources: http://spring.clan-sy.com/phpbb/viewtop ... 42#p319042
Maybe adapt to it.
A function for getting the resource index by providing a string would be nice, too.
int getResourceID(const char* name);

Also we would need functions to get resource information from units which use multiple resources.
float getStoreFromUnit(int unitID, int resourceID);
+ cost, make, use, upkeep
or (Storage, cost and income(+/-))

[hoijui]

Thanks for referencing that thread, Agon; did not come into my mind.

a function to get the resource by name.. right, good idea.. am putting it in there right now.

the last part: units using multiple resources
is already in hte interface (though, also there, only supporting metal nad energy so far)
...not yet comitted, but that commit may come this evening.

[AF]

Perhaps instead it would be best to give a value representing the ideal resource value, e.g. 0, infinity or -infinity, for maximum flexibility.

[hoijui]

yeah, i agree, will do that.
I just added bool goodToHave as a reference. once we decided on a number of things we need for resources, i will put them into the code. so you may suggest that here:
(Luarules <-> AI, part 1 of 0: resources) viewtopic.php?f=15&t=16889&p=319042#p319042

[hoijui]

i have done all major changes i wanted to do. it is now time for testing, and then moving everything into trunk; whether before or after the next release.

current status:
working interface:

• C/C++ (plus Legacy wrapper)
• Java (plus ObjectOriented wrapper)

AIs using the C interface:

• RAI
• KAIK (not crashing, but not doing anything, I don't know why :/)
• NTai (not crashing, probably working well with the correct config files)
• AAI
• NullAI (Test AI; simplest of all the AIs, in pure C)
• NullLegacyCppAI (Test AI; using the Legacy C++ wrapper (former TestGlobalAI))
• NullJavaAI (Test AI; simple AI, using the Java Interface)
• NullJavaOOAI (Test AI; using the Java Object Oriented Wrapper over the Java Interface)

a note about the Callback:
if you have a look at the rts/ExternalAI/Interface/SAICallback.h, you will see that the callback functions have long (and sometimes ugly) names. i made this to faciliate generation of Object Oriented wrappers for this flat interface. one such wrapper is already at work for the Java interface. An example: in the C callback, we have these function(-pointer)s:

Code: Select all

int (CALLING_CONV *Clb_0MULTI1SIZE0UnitDef)(int teamId);
int (CALLING_CONV *Clb_0MULTI1VALS0UnitDef)(int teamId, int unitDefIds[], int unitDefIds_max);
const char* (CALLING_CONV *Clb_UnitDef_getName)(int teamId, int unitDefId);
float (CALLING_CONV *Clb_UnitDef_getBuildTime)(int teamId, int unitDefId);
float (CALLING_CONV *Clb_UnitDef_0REF1Resource2resourceId0getUpkeep)(int teamId, int unitDefId, int resourceId);
int (CALLING_CONV *Clb_0MULTI1SIZE0Resource)(int teamId);
int (CALLING_CONV *Clb_0MULTI1FETCH3ResourceByName0Resource)(int teamId, const char* resourceName);
const char* (CALLING_CONV *Clb_Resource_getName)(int teamId, int resourceId);
float (CALLING_CONV *Clb_Resource_getOptimum)(int teamId, int resourceId);

for which the AWK script generates an OO wrapper, that can be used like this (pseudo code):

Code: Select all

List<Resource> resources = myClb.getResources();
Resource r = resources.at(0);
String rName = r.getName();
float rOptimum = ud.getOptimum();

List<UnitDef> unitDefs = myClb.getUnitDefs();
UnitDef ud = unitDefs.at(0);
String udName = ud.getName();
float udBuildTime = ud.getBuildTime();
float udUpkeep = ud.getUpkeep(r);

print("UnitDef " + udName " has a " + rName + " upkeep of: " + udUpkeep);
// example output -> "UnitDef corcom has a Metal upkeep of: 0.75"

putting all info into the function name (plus the return type and parameters) avoids name clinches, and ensures (or at least suggests) that all AI Interfaces will use the same class model, which will make it easy to port AIs from one language to an other, and in general unify the whole thing.

Get the branch:
https://spring.clan-sy.com/svn/spring/b ... iinterface

issues:
..quite some issues with the build systems:
* in the scons build script, i am using env.Jar(...) for the Java AI Interface and the Java AIs, which works fine on my machine, but the buildbot claims not to know the command 'Jar'. am in contact with bibim over pm to have a look at this. CMake builds fine, but the buildbot only uploads the dedicated server when compiling with cmake.
But maybe it would be good anyway if you compiled it yourself, locally, so we have more test cases (linux|win32|win64 ~ scons|cmake).
* there is still a lot of GroupAI code in the repository, but some of it is commented out, and the rest is not used anymore (mostly). i will remove it some (soon) day. don't worry about it.

so.. please help testing the new interface!
if you are an AI dev, you may want to check if your AI still works as it did before.
you may also just do some test games against bots for bug hunting.
if you are rather interested in the Java interface only, have a look at Java AI Interface topic here in the forum:
viewtopic.php?f=15&t=12308&start=140