KAIK 0.13 Unofficial (Spring 0.80.5*)

[hoijui]

an other crash

infolog: http://pastebin.com/f1636e7fd
gdb stack trace: http://pastebin.com/f27ac2c4b

it happend on the springheadless branch of hughperkins after some 10-15mins into the game; 1vs1, KAIK vs KAIK on Brazillian Battlefield, BA 7.01.

[cranphin]

Not seeing any work on kaik since last version?

Good, means my Java thingyport can catch up XD

I guess kloot's occupied with more important work ? :)

[Kloot]

Degree work, mostly, but I did sneak in some fixes for hoijui's two crashes. Also, I thought your port was already (to borrow a phrase) fully armed and operational?

To answer your older questions:

Where numFriendlies is the number of -all- friendly units, not just the buildings.
Now I'm still figuring out what all this K stuff does... But I could see it possibly making more sense using friendlyPositions.size() (just the buildings) instead of numFriendlies .

I didn't write any of that code, but I assume the cluster-count estimate incorporates mobile units because they're often located near important buildings (constructors build-assisting factories, for example). Could just be a bug too, of course.

I intend to add a THANKS or THANKYOU file, which will be logged to to infolog on startup (good idea?) , could you provide a nice list for that ? :)

AFAIK the only people who ever worked on KAI (long) before me were Krogothe, Tournesol and Firenu.

I'd prefer sticking a generic GPL license on everything, think that's possible?

Possible and even required, since KAIK code itself is GPL'ed.

I'm fairly sure this happens when the target chose isn't destroyed, the ai keeps in a 'airattack' mode, but doesn't assign any new planes to the target, so it just waits for the target to die by itself :)

Confirmed; if the target isn't destroyed, AND all attacking planes are shot down during the run, then the state is never reset until the target's health drops to 0 in some other way, so any newly built aircraft go unused and can pile up to a huge swarm. That's what you get for testing against unarmed targets.

[cranphin]

Degree work, mostly, but I did sneak in some fixes for hoijui's two crashes. Also, I thought your port was already (to borrow a phrase) fully armed and operational?

Ahh, I see, hope that's going well! :)
As for my port, it pretty much works, but until hoijui can get his Java performance branch finished and in, and I do some more optimization in the code itself, performance compares woefully to kaik itself ^_^
And I've got a feeling it's got a bug or two in still that makes it lose more <.<

right, gonna read rest of your post now :)

[cranphin]

I'm fairly sure this happens when the target chose isn't destroyed, the ai keeps in a 'airattack' mode, but doesn't assign any new planes to the target, so it just waits for the target to die by itself :)

Confirmed; if the target isn't destroyed, AND all attacking planes are shot down during the run, then the state is never reset until the target's health drops to 0 in some other way, so any newly built aircraft go unused and can pile up to a huge swarm. That's what you get for testing against unarmed targets.

I like to test against myself, helped by a few /cheat spawned krogoths and a lot of air defense built with some spawned fusions/metalmakers :D
Then I end up fidgeting around for so long that I don't get round to fixing bugs or so :D

I put in some code in the Java thing to improve on this, but it needs more tinkering and bugfixing :)
It kinda failed for example when there's fighters or torpedo bombers in the mix, which can't attack most targets :)

[hoijui]

:D thanks Kloot!
i merged master back in to hughperkins springheadless fork, and two KAIKs now successfully ended a battle
(... well one died of course)

@cranphin
yeah.. i still did not do it.. it is not realy joyfull work, but i think i settled with a way to do it in my head, so .. i just need some special motivation now, like a few girls comming to visit me in my cellar or so.. they somehow come along seldomly though :/
nah.. will do it, will do it ...

[cranphin]

@cranphin
yeah.. i still did not do it.. it is not realy joyfull work, but i think i settled with a way to do it in my head, so .. i just need some special motivation now, like a few girls comming to visit me in my cellar or so.. they somehow come along seldomly though :/
nah.. will do it, will do it ...

Take your time, just don't give up :D
It's better if it's well thought out and tested anyways :)

Can't help you with the girls tho
But those distract anyways :D

[slogic]

Does KAIK use its own pathfinding algorithm? Playing on 2Lakes map i noticed that non-floating builders try to overcome the river in some narrow, but still deep places. Also a big group of units can't reach an opponent to struggle against him.

[cranphin]

KAIK uses it's own pathfinding :)
Not sure if that causes the issues you describe though.

I'm sure Kloot can tell you more ^_^

[slogic]

I guess this is done due to optimization purposes. The map is really hard for land pathfinding. I hope the reaction on "can't reach the destination" will be faster at least.

[1v0ry_k1ng]

can you make it build air repair pads in EE?

[slogic]

Kloot, can you fix CUNIT::ReclaimBestFeature(bool metal, float radius) in Unit.cpp? When searching for the best feature to reclaim ignore those which are underwater (compare unit maxwaterdepth (or i guess you should take it from movement class which assigned to current unit) with ai->cb->GetFeaturePos(featureIDs).y) in for-cycle. On Tangerline map AI sends kbot builders to reclaim a rock in the center of map which is underwater.

[slogic]

D-Gunning should be adjusted. At least make a preliminary trace to avoid self or team units/buildings on selected D-Gun path. I've attached a replay to show that D-Gun could be KAIK's enemy number one :)

Here is 2xKAIKs vs E232AI replay.

[slogic]

Hope i fixed the previous situation. Sorry, have no time to make MSVC2008 project file & test it by myself. Kloot, if you have time you can merge & test the following sourcefile.

I did another trace behind an enemy unit on DGun path. It is not perfect (i don't know how to get all units on a trace with ease) but will cover most of confusing situations when KAIK uses DGun.

[hoijui]

it looks to me, as if KAIK does not build new mexes if the wrecks remain. i guess a call to a canBuild function returns false becuase of the wreck or so...
am just watching a game wiht KAIK, where early on, the 3 mexes in his base got destroyed, and wrecks remain of all 3.. and despite having 3 cons and the commander idling in its base since minutes, it does not rebuild them (though it desperatly would need the metal).

edit:
something related: KAIK also builds mexes where allies already have mexes (maybe only if the mexes are not centered on the spot?).

[slogic]

If you want to compile sources under MSVC2008 you should replace

Code: Select all

#define MY_FLT_MAX		3.40282347e+38F

with

Code: Select all

#define MY_FLT_MAX		3.402823466e+38F

or better rewrite this with std::numeric_limits<float>::max().

This is also concerning FLT_BIG macro in MicroPather.h.

PS. I missed ";" in my DGunController.cpp.

[slogic]

edit:
something related: KAIK also builds mexes where allies already have mexes (maybe only if the mexes are not centered on the spot?).

Code: Select all

// KLOOTNOTE: this needs to ignore spots already taken by allies
float3 CMetalMap::GetNearestMetalSpot(int builderid, const UnitDef* extractor) {

Currently i wrote a code which fixes it, but can't compile AI to test it.

PS. Is it correct (at KAIK.cpp):

Code: Select all

CR_BIND(CKAIK, );

? I got error:

Code: Select all

e:\prj\vcpp\spring\ai\skirmish\kaik\kaik.cpp(8) : error C2039: memberRegistrator: is not a member of "CKAIK"

PPS. Ok, solved. I had to define USING_CREG.

[hoijui]

Is it correct (at KAIK.cpp):

Code: Select all

CR_BIND(CKAIK, );

without looking at the file in particular, this sort of code is valid and often seen for creg, even doh it looks wrong in the eyes of a dev (as it is fail in most programming languages).

thanks for the fixes slogic!
hope we can test them soon.
also.. maybe it would be time to give it a new version number if all that stuff is applied.
.. then again.. who cares for that.

[slogic]

Not too fast I'm thinking more & more that MSVC is not for open source development:

Code: Select all

 	SkirmishAI.dll!_crt_debugger_hook(int _Reserved=2290032)  Line 65	C
 	SkirmishAI.dll!_invalid_parameter(const wchar_t * pszExpression=0x00000000, const wchar_t * pszFunction=0x00000000, const wchar_t * pszFile=0x00000000, unsigned int nLine=0, unsigned int pReserved=0)  Line 112	C++
 	SkirmishAI.dll!_invalid_parameter_noinfo()  Line 125	C++
	SkirmishAI.dll!CUnitHandler::BuildTaskCreate(int id=912)  Line 638	C++
 	SkirmishAI.dll!CUnitHandler::UnitCreated(int unitID=912)  Line 141	C++
 	SkirmishAI.dll!CKAIK::UnitCreated(int unitID=912, int builderID=909)  Line 77	C++
 	SkirmishAI.dll!CAIUnitCreatedEvent::Run(IGlobalAI & ai={...}, IGlobalAICallback * globalAICallback=0x03eb30e0)  Line 32	C++
 	SkirmishAI.dll!CAIAI::handleEvent(int topic=5, const void * data=0x0022f2a8)  Line 164	C++
 	SkirmishAI.dll!handleEvent(int teamId=0, int topic=5, const void * data=0x0022f2a8)  Line 103	C++

It is after 2 sec AI has been activated.

[slogic]

Changelog:
* fixed a crash (at least for me) on first 2 seconds of gameplay when DLL was compiled by MSVC2008
* avoid taking a decision to build a MEx near allied MEx
* better avoid situations when commander D-Guns at too high rate without considering of sad consequences
* threat map is considered when commander decides to reclaim or capture an enemy unit

Still will build a MEx right near another MEx which has been just captured (doesn't GetFriendlyUnits() return its own units?).