Java AI Interface for Spring

[hoijui]

Am currently working on the config-file thing. it will be a simple XML. i think i will do it so if the file is not present, i will scan for impls in a folder and use them in some undefined combination.

[Tobi]

Ideally one AI DLL would be able to report back multiple AIs, but that will need quite some changes over the entire infrastructure:

• add interface to unitsync
• add interface to AIs to query multiple AIs from DLL (preferably assuming single AI if this special interface isn't present)
• announce interface addition to lobby developers
• wait until they actually implement it (or patch it yourself too)

(IIRC lobbies now list AIs by just looking for *.dll/*.so in AI directories, and not by querying a Spring interface.)

The nice thing with this solution is of course that it could integrate with LuaAI too, plus no lobby changes would be required for any other new type of AI in the future.

A more hackish temporary solution could also be to make the JAI DLL load a similarly named jar file, so you could just make renamed copies of the DLL to have multiple AIs. (ie. MyJAI.dll / MyJAI.jar, AnotherJAI.dll / AnotherJAI.jar, etc.)

Not sure this would actually allow multiple AIs in same game tho, since I guess you would be instantiating multiple JVMs in this case.

As for what to do now with the code, it's really separate AI only right or did you make changes to Spring too to support it? Maybe you could upload it somewhere so I could take a quick look?

[hoijui]

ah thanks tobi!
hmm.. i did not know that it would need that many changes, but i knew the lobbies had to be changed at least.
i did not change anything on the spring code to support anything so far. right now when you submitted this post, i finnished implementing the xml config thing.
but now i got confused after reading your post...
as i understood it: when i open a game with 2 bots which use the same dll, lets say JAI.dll, then the dll is loaded only once, right? (i though its not possible loading one dll 2 times), and this dll is querried for 2 AI instances, right?
your concern about multiple JVMs was only for the case of multiple copies of the smae dll, like MyJAI.dll, YourJAI.dll, ...
right?

and.. yeah i think its a good moment right now that you would have a look at it. i will prepare it and send it to you by email.
thanks!

[Tobi]

Yes, I'm pretty sure if you make a game with e.g. 4 JAI.dll's the DLL will get loaded only once and the CreateAI (or whatever it's name is) called 4 times.

(Just checked, Spring actually seems to call LoadLibrary/FreeLibrary/GetProcAddress for every AI separately; still I think these functions internally maintain a ref count, since, as you say indeed, I don't think it's possible to load one DLL multiple times into the address space.)

[AF]

If your willing to add support for specifying ai.jar rather than ai.dll then I will modify AFLobby to do a second check for .jar files. Its not too hard, and the other lobbies should be able to cope just as well.

[hoijui]

ok Tobi
i sent what i call my first alpha to you, AF and zenzike by email (seeing right now that it failed to send to AF). What you wanted AF is not yet built in. Right now, it uses an xml config file to select the jar/class-name of the implementation to use.
it may be practical if this is the default: if no list of jars is specified otherwise, it uses the config file, and if in some the jar or jars to use are specifyed otherwise, these values are used.
btw.. how would you like to specyfy the jars to use, and how would you like to retrieve a list of available jars/class-names?
through files or through calling something?

[AF]

The idea of having to take the time and effort to learn how to parse xml in java so I can read your config file and then learning how to write xml back is a huge turn off.

Right now I am fine with a simple aidll tag that accepts dll so dylib and has a special case jar. The main reason its more consistent and its extremely easy to implement.

Introducing xml invokes the age old procrastination argument, the same argument that delayed cookiebot using a simple xml file for 4 months after which a primitive xml file function was written but I had hacked it together form something betalord had in chanserv and it didn't work too well so I ditched it.

There is nothing more harmful to your effort at the moment than your reliance on that xml config.

[hoijui]

well its easyer for me then a properties file would have been, and .. as i tryed to explain... i would make an other way, which woudl be easyer for you but... i didn't get how you want it. what kind of Tag? where tag?
i would implement that, but you have to explain me better. where would you specify this tag? where can i get it from, where do i have to read it to load the correct jar then, and how would you want to retrieve a list of available jars?

[BrainDamage]

all you need is the path to the jar file, right?

spring has anlready an option inside script.txt to specify the AI path (the aforementioned AIDLL=/opath/to/the/ai

all it would be needed is to allow .jar files to be added to such node in the script.txt file and detect AI type by it's extension

to list java AIs, lobbies can use the unitsync VFS to list .jar files inside global AI folders and list them to the user, the path of the AI will be inserted in the AIDLL tag path

[hoijui]

ahhhh....
well so far i alwyas though of JAI beeing just an other dll liek the others.. but that way it woudl be an interface besides the native one, and we would have dlls and jars in the Bot-Libs folder then.
yeah that would work!
though i would have to move my JAI.dll that i have so far out of Bot-Libs then, and it had to be loaded separatly somehow (someone else would have to do that.. pls )
well.. so far i used [path-to-jar]:[classname] bundles to specify implementations, but if we only allow one AI implementation per jar, which should not at all be a problem, then the jar name is enough, yes.

so .. what do you others thing? should it be a special interface for global AIs or just an other .dll as its now?

if its a specia linterface.. how would we do that? or.. if i have to do it.. can you .. give me some hints where i had to build it in?
and.. how would i get the AIDLL tag path value?

[Kloot]

The Java AI proxy .dll/.so would still need to know which .jar to
load, allowing "aidll=blablAI.jar" isn't enough since the engine
just calls the proxy's public GetNewAI() without passing along
the name of the .jar or the team number (but it could ).

e: an alternative is to let the proxy lib read the setup script.txt
in GetNewAI() itself, GetAICallback() (and GetMyTeam()) should
already be callable at that point (but then the script'd have to
reference both the proxy and the actual jar-name per team).

[hoijui]

hmm.. sounds kind of ugly to me :D
maybe the lobby could write the jar and the team number into an other file (would not even have to be xml ).

[AF]

hmm.. sounds kind of ugly to me :D
maybe the lobby could write the jar and the team number into an other file (would not even have to be xml ).

such as script.txt?

You do realize that lobby development involves very very long lists of things that need to be done and even longer lists of things that should have been done months ago? You should cater to us if you want support not the other way around. Granted its not a pretty situation, but lobby development has many more issues to deal with than AI development, and I'm saying this as both an AI and a lobby developer.

If its too much work to do it'll get sidelined in favour of other tasks, just go look at the spring lobby road maps, they have literally hundreds of open tickets regarding features and architectural things they need to do, tasclient and aflobby are in a similar situation, although they lack the pretty graphs to demonstrate it..

I will implement the code to use .jar AIs in the lobby using the same method as .dll and .so. The primary reason for this is because it would be a copy paste operation then editing the dll to jar in the text string, very very little work, something that could be done in under a minute. I'm not going to go about refactoring my code to allow for a special case scenario that allows usage of Java AIs when no java AI currently exists

[hoijui]

:D you seem to have a bad day today :D
yeah i didnt think of that :/
simple an other tag in script.txt then...

soo.. i would have to parse script.txt and look for what exactly?
lines like this:
AIDLL=JAI.dll;
?
and on the following line there will be an other tag then, lets say...
JAIJAR=JAI-impl-hoijui.jar;
?
did i get it? what would you like the tag to be called like?

[AF]

Code: Select all

AIDLL=JAI-impl-hoijui.jar;

[hoijui]

ok.. and the lobbies will have to be rewritten then, so they know they have to load JAI.dll whenever they see an AIDLL tag with a value ending in jar?

[Tobi]

Lobbies don't load AIs, Spring does.

I'd prefer a bit clean solution as opposed to a hack like more AIs that read script.txt.

Extending the AI interface with a method to create a new AI based on name seems good solution, and I can accept a modification to the engine so it treats JARs as AI DLLs and behind the scenes loads JAI.dll and calls GetNewAIByName("blah.jar") for it instead of GetNewAI().

Actually I think hardcoding the fact that .jar in AI DLL is AI too in Spring or Lobbies may even be better then querying the AI DLLs for AIs they contain, since the latter requires loading all DLLs just to list AIs, and hence every AI get's the chance to corrupt Spring/unitsync/lobby memory in that case (in the listing routine)
IOW, it'd allow a malicious/corrupt AI DLL file to make Spring+lobby unstartable; I'd call it defective by design if that is possible to happen.

To the point; I think this is what needs to be done:

• Patch GlobalAI.cpp/GlobalAI.h to check for a GetNewAIByName method in the DLL.
• Make it call that method if it exists in the DLL and the standard method GetNewAI otherwise.
• Add a conditional to the DLL loading in CGlobalAI: if file extension == ".jar" then load JAI.dll instead or throw an error if it does not exist, or doesn't have GetNewAIByName method. (would be required for JAI.dll)
• Make an announcement asking lobby developers to add *.jar to possible AI file extensions. (Put the JAI .jar files that represent the AIs in same dir as AI dlls then.)

[hoijui]

hmm... sounds good to me!

so JAI.dll would have to be in an other folder, lets say..
AI/Jai/Jai.jar
instead of AI/Bot-Libs/JAI.dll
so lobbies won't find it and add it to their list as an available AI, right?

[Tobi]

Yes.

[Kloot]

If nobody objects I'll do the first three items; hoijui, could you write
a simple TestGlobalJAI to test (and demonstrate ) your JAI loader
with in the meantime if you haven't already?