Java AI Interface for Spring

[hoijui]

this was my first though as well back then, but the thing is:
the events and hte callbakc are quite separate, logic wise, code wise, and the Java versions are generated by different AWK scripts. Introducing a dependency like this one would be well ugly, and need a lot of extra management and ...
it wont happen.

[LoidThanead]

To me, the game knowing what frame it's at seems fairly logical, but since I have zero knowledge of the internal workings of the callback, I'm quite ready to believe you if you say it isn't so.

From a developers point if view, it seems like a waste of effort to have to duplicate the code to keep track of the frame number everywhere I want to use it...
Since I'm writing a wrapper anyway, I'll give some thought on how to make this more convenient. The first thing I'll do is add a 'frame' property to all of my events.

Ideas on the matter are quite welcome.

[3Px]

I feel that the current interface could be enhanced a bit, specifically the event unitDamaged doesn't provide any information about the weapon that was used by the attacker. Human players have visual information - they can see the projectile. Is including a WeaponDef in this event possible?
Or maybe I'm not seeing some obvious way to determine what kind of weapon was used on my unit?

[hoijui]

I feel that the current interface could be enhanced a bit, specifically the event unitDamaged doesn't provide any information about the weapon that was used by the attacker. Human players have visual information - they can see the projectile. Is including a WeaponDef in this event possible?

done with commit 4e45a293db062bcef9fec1f14a0ab181d5b1ed79.
you may have to touch rts/AI/Interfaces/Java/src/native/JavaBridge.c before rebuilding spring, for this to work with the Java interface.

[3Px]

Thanks a lot! :)
Just one question - is argument paralyzer any different from what you can get from weaponDef.isParalyzer()?

[hoijui]

In practice, it will be the same i guess, in theory, it could be different (i think).
The thing is, it is internally passed as a separate argument too, on this event, so i though it has some reason. From looking at the code, i think a paralyzer weapon with 0 or less damage, will have this argument set to false, but the weaponDef.isParalyzer() set to true.. though..
i don't know if a paralyzer weapon wiht damage smaller then 0 can be used to deparalyze...
in short, i don't know, but it wont hurt.

[hoijui]

about the crash on the ReleaseAIEvent:
JNA has problems with 0 sized Structs/Structs with no members. In the past, i was preventing this crash through manually setting the size to 1, for 0 sized structs. sinze JNA 3.2, it is not possible to manually set the size anymore. I posted the issue on the JNA mailinglist again, but it is possible they wont "fix" this, as they have problems seeing the use case for empty stucts .
anyway, if you are interested, the mailinglist is here:
https://jna.dev.java.net/servlets/Brows ... 1&count=41
search for: "failure on calculating size of empty struct"
i will wait for them to decide if htey will fix this is or not, and if not, i'll have to revert to an older JNA again.

[imbaczek]

if they won't fix it, i guess hacking in a NULL pointer will be the best option. reverting isn't really a solution.

[hoijui]

i dont think so.
There is little we gained from the latest JNA versions, and this hacking in of NULL will need a lot of adjustments, and change basic logic of the whole C interface, add ifs in central locations where they are not nice, force adjustments in other plugins (current nad those to come), just to work around a bug in a library used by a plugin (the Java interface).
plus it would be a more ugly design.

[hoijui]

they wont fix it, i think.
I just made the release event non-empty
i didnt know what to put so i asked around.. Aus suggested what it contains now:

Code: Select all

/**
 * This AI event tells a Skirmish AI instance, that it is no longer needed. It
 * can be used to free memory or do other cleanup work.
 * It is sent only once per AI instance and game, as the very last event.
 * Values description for reason:
 * 0: unspecified
 * 1: game ended
 * 2: team died
 * 3: AI killed
 * 4: AI crashed
 * 5: AI failed to init
 * 6: connection lost
 * 7: other reason
 */
struct SReleaseEvent {
	int reason;
}; // EVENT_RELEASE

The Java AI crash on release is fixed now.

[imbaczek]

good idea, +1.

[LoidThanead]

I was gonna ask for that, but kept forgetting. :) Knowing the result of a game could be used for learning purposes.

[hoijui]

mm.. the things you like most are the ones i personally think are the most useless :/
nm.. glad it was even a usefull choice then :D

edit: fix bad type

[LoidThanead]

No information is ever useless. Worst it can be is superfluous. There's always some kind of use for any type of information.

[hoijui]

Falsy buffered values should now be gone.
see commit: 3eee834e2516d4f10fd244f8a5966ea53d66c2fb

AI: Java: do not buffer values returned from functions with parameters
This prevents bugs where wrong values were returned, eg:
UnitDef.getCost(Resource.METAL) -> 10
UnitDef.getCost(Resource.ENERGY) -> 10, while 20 would be correct

The reason i disable buffering instead of using buffering in a map or soething, is that in some places it could hurth performance (memory and CPU) quite some, eg when the function has multiple parameters, lets say 3. Not to mention that the code would get ugly (recursive HashMaps/ArrayLists and stuff).

[hughperkins]

Hi,

The Java AI interface looks potentially incredibly cool.

By the way, whoever refactored the AI interface, this looks potentially awesome!

Right, onto practicalities. I've spent several hours with fighting with trying to get a basic null java oo ai running, and failed.

According to http://springrts.com/wiki/AIInterface:Java , the default spring install contains the Java AI interface, but mine does not:

Code: Select all

user@701:/opt/taspring/spring_0.79.1.2$ dpkg --listfiles spring-engine | grep Interfaces
/usr/lib/spring/AI/Interfaces
/usr/lib/spring/AI/Interfaces/C
/usr/lib/spring/AI/Interfaces/C/0.1
/usr/lib/spring/AI/Interfaces/C/0.1/InterfaceInfo.lua
/usr/lib/spring/AI/Interfaces/C/0.1/libAIInterface.so

I installed spring from the Ubuntu repositories ( # deb http://ppa.launchpad.net/spring/ubuntu jaunty main ), a few weeks ago.

I've vaguely fought with trying to build the interfaces by hand, by gcc, by scons etc, but it's eating up tonnes of time. Part of the reason of using java is to escape all this compiling stuff

What can I do so I can simply obtain an environment where I can start adding java code to build solar panels and stuff and get this to run?

Environment:
- ubuntu 9.04 (jaunty) running on eeepc 4g (yes, spring does run on this, slowly, but it runs).
- sun jdk 6 update 6
- spring 0.79.1.2

[hughperkins]

(Or, to put it another way: how can I tell scons configure where my java is? It is at /opt/jdk1.6.0_06 , which isn't covered by any of its default guessing. How can I do something like:

Code: Select all

scons configure --javapath=/opt/jdk1.6.0_06

?

)

[imbaczek]

scons is kinda deprecated, it works, but cmake works better.

also, there's a null java ai included, so start there?

[Agon]

Yeah, but maybe he wants to test it?

The text in the wiki is referring to the windows build I think or at least not to ubuntu or openSUSE.
Hm maybe I should add the java interface in the new rpm builds for 0.80.* .
And yeah, use cmake but there you need to configure your special jdk path, too.

[hoijui]

well... the Java interface should be in the official default spring install since spring 0.79; this is the case for the windows isntaller. if the package paintainers do not include it... well they do it for free, but they are not consistent then... BAAAD!

for compiling it yourself:
as baczek said, it is better to use cmake instead of scons. First get spring compiling, as described here:
http://springrts.com/wiki/Building_Spring_on_Linux
if the jdk is not in one of the locaion it searches by default, then all you have to do is set JAVA_HOME to the JDK dir globally. best is if you put export JAVA_HOME=... into yout ~/.profile file, and then open new terminals or issue

Code: Select all

. ~/.profile

before compiling.
The main problem with the java interface is, that if the java code fails to compile, it wont retry to compile it again. this has to do with CMakes inability to handle Java sources well (SCons is not really better there, though).
so if it fails, you best trigger a rebuild with touch AI/Interfaces/Java/src/native/JavaBridge.c.
if you dont want to/have to build all of spring, this should be enough:

Code: Select all

make Java-AIInterface

.

btw, i did the refactor and the java interface. it is written all over the place

you also want to autojoin the #ai channel in the lobby.