Java AI Interface for Spring

[hoijui]

when compiled in debug mode, the Java interface is debuggable at localhost:7777. you can debugg with eclipse or netbeans or... there are other GUIs.

I have a 32bit WinXP too, just did not test on it for some time, will have to do that again...
once the buidbot supports compiling GIT branches (i have been told this should be soon; in a few days), we can build debug spring there. you have to wait till then, or compile it yourself.

I will update the wiki (somewhen) to explain how to debug a Java AI in more details. I will report back here, when it is done.

[AF]

I loaded up the AI page in the wiki linked to and it was a little bemusing in that the old AIs and the new skirmish AIs were all jumbled up and no explanation of the tag 'new' was given.

It wasnt very clear either where to go to see how to do a java AI, and there's a tonne of disjointed quasi outdated semi relevant information scattered across this thread.

• Add javadoc to every method in the API
• Build a basic hello world AI and comment the hell out of it
• Provide this basic AI in netbeans and eclipse projects. You should be able to load these projects and press build and get a working AI, along with very short instructions explaining how to make it unique. It should be as simple as change the name build and launch/debug.

I see all this talk of class loaders and exceptions etc etc, and this is only going to drive new people away. Remember most of the AIs here were built by people learning C++ while they were doing it who had relatively little programming experience beforehand.

We need smash bang hey presto, here's a project you can load in an IDE, no faffing around required, load it up and start hacking away as you please.

[hoijui]

i have two kind-of hello world Java AIs.
they need more documentation though, but i prefer to first document more the parts that are more basic, eg. what is an interface library, as this matters for all AI devs, not just the Java ones, and even for engine devs.

i plan to do a script where you just enter the name of your AI, and then it creates a new folder with all you need to build your own Java AI.
i did already comment lots of stuff in the interface.. (main battlefield there: SAICallback). but some things i just do not know, and i do not have mood to comment every field of UnitDef, WeaponDef and FeautureDef plus the rest. just do it yourself please, it is easy, just comment SAICallback.h, and it will be copied to the Java files automatically.

i already provide ant scripts for the example AIs plus the AI interface, which is more portable then neatbeans or eclipse projects. i dont know about eclipse, but i guess it can use a non eclipse generated ant script aswell; neatbeans can.

you are right that it is not so easy at the moment, to do a Java AI, but it is still beta, and this is not really my main concern right now.
i luckyly have a few guys that already try to work with the interface, and they are helping me to find flaws and errors. this is a much more healthy way then: "comment everything"
i still have quite some other things on the todo list aswell.

[LoidThanead]

Would it be possible to have an installer of the latest CAIInterface branch? I haven't had any success in getting it to compile on my machine, and find myself unable to spend enough time on the problem. However, I'd still like to continue working on an AI.

[imbaczek]

caiinterface should be merged into master real soon.

[LoidThanead]

A few more comments on the interface:

- I noticed that UnitDef.equals(otherUnitDef) returns false even if UnitDef.getName().equals(otherUnitDef.getName()) returns true. Shouldn't they be equivalent?
This would make it easier to find UnitDefs in a set or list. The Set.contains() method uses the equals() method to check for equality.
I suspect something similar happens to Unit.equals(otherUnit), which probably is not equivalent to Unit.getUnitId().equals(otherId).
It seems Unit and UnitDef objects are always recreated, instead of existing ones being reused.

- The method Map.findClosestBuildSite() still uses a unitDefId instead of taking a UnitDef parameter. An oversight, or is this intentional?


As a note to other uses of the interface: when issuing a BuildUnitAICommand(), the map.findClosestBuildSite() and map.isPossibleToBuildAt() methods don't take into account the presence of the builder with which you want to build. I have not yet checked if it does check for other units that are present. It may be nescessary to clear an area of mobile units, and manually check for a spot without immobile units in the way.

[hoijui]

Thank you!

the equals thing is clearly a bug, i will fix it, quite important!

About reusing/aching the objects...
i do not remember anymore why i did not do it.. its all prepared, should need little code.

Map.findClosestBuildSite() still uses a unitDefId
... yeah, i forgot it
i saw it now testing with you, but agian forgot it.

will report back when these things are fixed.

btw, the caiinterface branch is merged into master now.

[hoijui]

those things are fixed

[LoidThanead]

Not sure if this is a bug, or supposed to work this way... I'm trying to find units to use in an attack by using unitDef.isAbleToAttack(). But this returns true for nearly all units, including the contruction kbot and vehicles. In fact, for BA, the only unit that it returns false for is the Hulk (armtship).

Contruction units can't attack, right? They can capture enemies, but that's the isAbleToCapture() method.

[hoijui]

me neither know, but maybe the attack of construction units is reclaiming, or all units that have a weapon return true for that method...
in general, from what i learned so far, when writing spring skirmish AIs, it is never so easy as to just query one tag, or call one function.
you will have to query many tags and call some functions for eveyrthing. maybe you have to iterate over the weapons, and see if they are suitable to attack, plus query this function, plus ... i dont know. try out, check the code of the other AIs.. or maybe one of the AI devs can help.

[Tobi]

Yeah, canAttack from UnitDef (I suppose that's what it returns) is just true by default for everything and can be set to false to prevent units with weapons from attacking (or at least I think it works like that )

[AF]

Ideally we should set it to false for units that do not have any kind of WeaponDef attached, ofcourse being overriden by the content dev,this would bring it into line with the 'expected' value.

Reclaiming is not an attack, but dont let that stop you using it. NTai commanders would test to see if dgunning was more expensive than reclaiming, and would thus reclaim peewees in XTA rather than dgunning them because it was both cheaper and faster.

[LoidThanead]

I have not yet found a method of checking if a unit is capable of inflicting some kind of damage. Playing around with the WeaponDef object currently.

Also, Map.getResourceMap(Resource) returns a list of bytes? Isn't a map usually at least 2D? How do I get actual map coordinates of each of the values?

I'm not sure if these questions belong in the Java Interface thread, even though that is what I'm using. Is there someplace else I should be asking them?

[hoijui]

Yeah, this nad hte last questions ar both not Java related, but.. you can never really know that.. you can open a new thread if you want, but well.. i dont care so much if you ask here.

all the maps (Radar map, jammer map, resource map, ...) are single dimension arrays of some sort, which are actually meant to be 2D maps. To access it correctly, you can use Map.getWidth() and Map.getMapHeight(), with the correct resolution factor. The factor depends on the individual map, so the Radar map is eg (mapWidth/8) * (mapHeight/8), while the jammer map is possibly (mapWidth/4) * (mapHeight/4). These values are just not documented . I remember that the factors are between 1 and 8 (and the above two exampamples are just invented, i dont know if the factors are like that).
Would be quite a good idea to document this :D.

from inspecting the code, i currently have these values for map sizes:

Code: Select all

// height map
width * height

// slope map
width/2 * height/2

// los map
(width >> Mod.getLosMipLevel()) * (height >> Mod.getLosMipLevel())

// radar map
(width / ?) * (height / ?) * 2

// jammer map
????????

// metal map
width/2 * height/2

I'd like someone to correct this list and fill out the gaps, so i can document it. If the *2 on the radar map is correct.. why?
Well... best woudl be if someone else would document it, as i will just have to guess. Eg higher values on ht ejammer map means its more jammed? or are they 0 and 1 only anyway? 0 on the heightmap means water level? ...
documentation is needed in SSkirmishAICallback.h, if someone else is going to do it.

[Kloot]

IAICallback.h documents all of the typemap sizes already, with a semi-readable hint on how to index them. Copy it, clean it up, job done.

[hoijui]

doh! :D
i looked at most other places it could be.. but .. this is the most obvious one.
Though, when i compare this docu with what i found in the code. it is outdated already. eg the los map resolution is not fixed, but mod dependant now, and possible the radar map changed too?

mm.. looks like i dont have any of the docu of IAICallback in SSkirmishAICallback..
an other awk script for that!
btw.. wouldnt it make sense to do documentation like this in DoxyGen format, instead of // in the same line after the member/function to document? or does that have any drawbacks?

[imbaczek]

have you looked into jvm crashing when swing/awt is loaded? i'll be very sad if it won't be possible to show a window...

[Kloot]

Though, when i compare this docu with what i found in the code. it is outdated already. eg the los map resolution is not fixed, but mod dependant now, and possible the radar map changed too?

Ah, true, those comments date back many years. However, it appears the necessary C callbacks (Map_getWidth, Map_getHeight, Clb_Mod_getLosMipLevel) are already in place to calculate the size of the LOS map on the AI side, so a quick note about that ought to bring them back in line (the radar-map resolution is still constant).

wouldnt it make sense to do documentation like this in DoxyGen format, instead of // in the same line after the member/function to document? or does that have any drawbacks?

None that I know, just more work to write and maintain.

[AF]

None that I know, just more work to write and maintain.

There are numerous tools that should automate this for the most part. Aswell as that tools like netbeans etc allow autogeneration of javadoc, so theres nowhere in the toolchain that has an excuse for not being documented.

[LoidThanead]

I downloaded the lastest installer, and tried it out. Converting my AI to the new interface wasn't too much trouble, but now the game crashes right after starting.
The Java Interface log tells me that it 'failed to delete global reference.' Is there anything I'm doing wrong?

I've put the log up here.