New Java AI, HughAI

[hughperkins]

Hi 1v0ry_k1ng,

Ok, fair enough :-D Your comments are very concise and appear to be very insighful.

I suppose a next step for HughAI could be:
- make the config system flexible enough and / or precise enough so that you can specify the build order changes you wish
- make ... something ... so that it's possible to specify that the commander just guards the base rather than wanders around randomly
- - the actual trigger for this could be many things. You said "after the first 5 minutes" though I get the feeling that was just a turn of speech rather than the rule you wished to use :-D
- - However, as a first draft, we could have a config value like 'commanderOnlyAssistsAfterThisTimeMinutes'?

For the freezing up of Spring the end of a game, I'll see what we can do about that, though I'm not quite sure how that can be solved at the moment.

For the crashing of the AI once someone dies, that should be solvable. If you happen to have the exception stack trace for any of these crashes, that might be fairly quick to solve.

[hughperkins]

the config system (priorities and number of units) needs an overhaul imo, it just isnt flexible enough. the current build order needs work: should make 3mex-->2 solar-->factory

Actually, this should be possible within the current workflow system, by simply adding the 3 mex and the 2 solar explicitly into the workflow file with a higher priority than the factory:

Currently:

Code: Select all

<listitem priority="2.0" quantity="1" unitname="corvp"/>
<listitem priority="2.1" quantity="2" unitname="corfav"/>
<listitem priority="2.0" quantity="10" unitname="corraid"/>
<listitem priority="2.0" quantity="10" unitname="cormist"/>
<listitem priority="1.95" quantity="4" unitname="cormex"/>
<listitem priority="1.95" quantity="4" unitname="corsolar"/>
...

Could be tweaked to:

Code: Select all

<listitem priority="2.3" quantity="3" unitname="cormex"/>
<listitem priority="2.2" quantity="2" unitname="corsolar"/>

<listitem priority="2.0" quantity="1" unitname="corvp"/>
<listitem priority="2.1" quantity="2" unitname="corfav"/>
<listitem priority="2.0" quantity="10" unitname="corraid"/>
<listitem priority="2.0" quantity="10" unitname="cormist"/>
<listitem priority="1.95" quantity="4" unitname="cormex"/>
<listitem priority="1.95" quantity="4" unitname="corsolar"/>
...

[hughperkins]

I feel we could have a couple of different workflows actually.

You know, I'd quite like an AI that just sits there, builds a bunch of nukes and then fires them :-DDDD

Anyway, back to reality for a moment... it is possible to provide multiple workflow files in the BA_<side>_workflows directory. At the moment, the AI simply reads default.xml, but it could choose randomly from them instead (very simple tweak to the code, or maybe a config value 'chooserandomworkflow=yes/no'), and then we could have a bunch of different workflows:

rush.xml : same as current default.xml
level2.xml : assumes the other side won't rush, builds lots of constructors, mexes etc, gets up to level 2, and then builds tanks to attack
level2air.xml : assumes the other side won't rush, builds lots of constructors, mexes etc, gets up to level 2, builds a bunch of farks, and then spams brawlers
etc ...

I'm not sure I have any attack code for level 2 air, but it's fairly easy to add in, since it's basically a copy and pasted ground attack code, but with different movement constraints (can move anywhere, simplifies things!). Ten minutes coding plus 30 minutes testing. (obvoiusly the testing would be easier if there was a ladder to test this stuff automatically in...)

It would also be fairly easy to add in attack code for nukes, especially with maphack in: just pick an area of the map with maximum enemy power in, and nuke that, so if that would be interesting to you, fairly easy to add in.

[JohannesH]

I tried playing against it, but it keeps crashing pretty early into the game, around 1 or 2 minutes. It leaves no stacktrace or error message in infolog or the ai console. Maps were Alien Desert and Cooper Hill.

Also the things it is currently building appear as ghosts on the ground for some reason. Not sure if that applies to all buildings/units but at least sometimes.

When it comes to gameplay other than that, i cant comment on the exact build cause i didnt watch replays but it keeps misplacing its mexes and rushing a missile truck.

And when it comes to future build orders, please dont make it do sucky t2 rushes, just spam t1 like any decent human would. Newbs wont learn much playing an opponent like that. Also itd be great if it would alter its build depending on constuctor count or similar easy number, at least with maphack that should be doable.

[hughperkins]

I tried playing against it, but it keeps crashing pretty early into the game, around 1 or 2 minutes. It leaves no stacktrace or error message in infolog or the ai console. Maps were Alien Desert and Cooper Hill.

Hmmm, that sounds odd... kind of hard to debug that without stack traces! Maybe I'll try to download one of those maps and try.

Also the things it is currently building appear as ghosts on the ground for some reason. Not sure if that applies to all buildings/units but at least sometimes.

Yes, it's a debug feature, so I can see what it's doing. I should probably turn that off when debug is turned off. Was debug turned off by the way? In the gui, there is a tab 'config', and there should be a value 'debug'. Can you check this is unticked, and then do 'save'?

it keeps misplacing its mexes

Yes, I've seen this behavior. I should do something about that.

and rushing a missile truck.

It is configured to rush quite a lot at the moment, since that works quite well against other AIs. Probably need to make some less rushy strategy for matches against humans though... or at least get it to attack with its rushed units rather than just have them guard the commander!

Also itd be great if it would alter its build depending on constuctor count or similar easy number, at least with maphack that should be doable.

You mean, like, if the other person has air factories, build lots of antiair, if they have lots of ground only troops, build lots of air, something like that?

[JohannesH]

Oops, I had forgotten that it does give me an error message, I was reminded after trying a game on comet catcher and battle for planet. After spring crashes it gives me a box with header "fatal error" and the text "std::bad_alloc", but nothing besides that. On Battle, a very hilly map, it started veh as always, not the best of ideas :). But on that map it lasted whole 7:43 minutes, as i was just sitting back doing nothing.


And yes it should be building/"rushing" a lot of stuff, but on most maps its better to make jeffy/weasel and then gator/flash and not samsons EDIT: at first.

You mean, like, if the other person has air factories, build lots of antiair, if they have lots of ground only troops, build lots of air, something like that?

Yes, except when enemy has lots of grouond troops and you build air you heavily risk getting overwhelmed, depending on situation... If you want help concerning gameplay, ask away.

[hughperkins]

Oops, I had forgotten that it does give me an error message, I was reminded after trying a game on comet catcher and battle for planet. After spring crashes it gives me a box with header "fatal error" and the text "std::bad_alloc", but nothing besides that. On Battle, a very hilly map, it started veh as always, not the best of ideas :). But on that map it lasted whole 7:43 minutes, as i was just sitting back doing nothing.

Hmmmm, that is a C++ error, and HughAI is written in Java. Rather odd, and not a good sign...

[hoijui]

i can confirm the hang when trying to close the game, and then having to manually kill the process (spring).

as i run it in gdb, i can interrupt and see where it hangs:

Code: Select all

(gdb) bt
#0  0xb7ee4430 in __kernel_vsyscall ()
#1  0xb76f50e5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0
#2  0xb76f58f2 in pthread_cond_wait@GLIBC_2.0 () from /lib/tls/i686/cmov/libpthread.so.0
#3  0x9ea19c95 in os::PlatformEvent::park () from /opt/jdk1.6/jre/lib/i386/client/libjvm.so
#4  0x9e9ffc0e in Monitor::IWait () from /opt/jdk1.6/jre/lib/i386/client/libjvm.so
#5  0x9ea002de in Monitor::wait () from /opt/jdk1.6/jre/lib/i386/client/libjvm.so
#6  0x9eac16be in Threads::destroy_vm () from /opt/jdk1.6/jre/lib/i386/client/libjvm.so
#7  0x9e9352f1 in jni_DestroyJavaVM () from /opt/jdk1.6/jre/lib/i386/client/libjvm.so
#8  0x082d3ff0 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

DestroyJavaVM is a JNI function, and it first waits for all threads to finnish, and then kills the JVM. So i guess hte problem is, that some thredas are still running, and therefore the freeze. This problem does not exist with NullOOJavaAI, so it coudl well be inside your AI. I guess goes for some GUI/SWING related thread. Try to make sure to kill them all when your AI is released.
I just tested with /aikill, and the same thing happens there (freeze, hanging in the same native function like above). The Swing window is still open, evne doh your AI shoudl alreayd be gone by then, which makes my gues more probable.

[hughperkins]

Hi hoijui,

Ah, cool! Thanks! That's very helpful info. So... basically, I can override OOAI.release() and kill stuff it looks like? Great!

[hughperkins]

Hi 1v0ry_k1ng,

Ok, so I got the new AILadder to run some games against E323AI, and it seems everything you say is exactly right, and insightful.

E323AI basically annihilated HughAI in every game...

http://manageddreams.com/ailadder/viewresults.py

(posted this after 3 games, E323AI won 3 out of 3 ... there are 7 more games queued)

firstly, on the two machines I tried it on (both with wildly diffrent specs and slightly diffrent java versions) it crashes 100% of the time when a player is defeated, either itself or another faction.

I think this is fixed now.

it is also impossible to quit the match without the crash freezing spring up requiring it to be manually closed. it leaves no clues as to why in the infolog.

hoijui has helped me to fix this; I think this is fixed now.

attacking behavior seemed good when it actually happened, although most the time units just gaurded the commander irregaurdless of hughAIs undefended base being attacked and events elsewhere on the map.

Yes, that sounds unfortunately right...

the commander seems to be the weakest element of the AI, simply walking around building and often walking into defences/other commanders and exploding

Yes, you are right!

[hughperkins]

startscript option parsing added to HughAI, in git.

The following options are available:

maphack=yes/no
debug=yes/no
guiactivated=yes/no
defaultworkflowname=default

I'm not sure the format in the AIOptions.lua file is quite correct. I can't test it, since there is no AIOptions.lua client on linux AFAIK? , but HughAI itself can read the values from the startscript.

Basically, any primitive value that can be specified in the xml file can be specified in the startscript too, optionally, and will override the value in the xml file.

[hoijui]

Code: Select all

OptionValues ov = ooAICallback.getSkirmishAI().getOptionValues();
int size = ov.getSize();
for (int i=0; i < size; i++) {
   String key = ov.getKey(i);
   String value = ov.getValue(i);
}

in short, there should never arise the need in an AI to parse any file except its own.
in case you think again that this is needed, it is either not, or the interface lags it, and it should be added to the interface. anyway -> check hte callback or ask me

[hughperkins]

Sorry, I miscommunicated I believe it is up to the developer to write their own AIOptions.lua file? Which means: I need to know what the correct format of this file should be

[hoijui]

for the format:
http://springrts.com/phpbb/viewtopic.ph ... 07#p381207

[hughperkins]

Ah thanks!

Right, so HughAI git now has the following options available through the start-script:
- maphack =true/false (default true)
- guiactivated = true/false (default true)
- debug = true/ false (default false)

[hoijui]

cool!
well .. yeah now lobby support would be nice too.
btw, maybe add all hacks/cheats to a cheats section in AIOptions.lua? would work like this:

Code: Select all

    {
       key="ba_options",
       name="Balanced Annihilation - Options",
       desc="Balanced Annihilation - Options",
       type="section",
    },
	{
		key="deathmode",
		name="Game End Mode",
		desc="What it takes to eliminate a team",
		type="list",
		def="com",
		section="ba_modes",
		items={
			{key="killall", name="Kill Everything", desc="Every last unit must be eliminated, no exceptions!"},
			{key="com", name="Kill all enemy Commanders", desc="When a team has no Commanders left it loses"},
			{key="comcontrol", name="No Commander, No Control", desc="A player without a Commander cannot issue orders"},
		}
	},

in springlobby, a section is a bordered pane with the name attribute as title and desc as tooltip. so it is just kind of a help for hte user .. and could be so for the ailadder too maybe (eg, let it identify a hack/cheat it does not know about as a hack, and consequently disable it in tests where the other AIs do not have this hack available, maybe).

[1v0ry_k1ng]

imo map hack on by default

[hoijui]

defaults should be the AI devs decission, and then the lobbby would ideally allow saving presets, as it is wiht modoptions already.
If the AI dev thinks his AI does not need it, and wants to concentrate testing and users feedback on a non cheating version of his AI, he should do it this way.

[1v0ry_k1ng]

any progress ?

[hughperkins]

Working on the ladder Only so many hours in the day!

Edit: however it is nice to see interest. I appreciate your asking.