You'll encounter quite a few more WTFs while porting it. ;) Some are more deeply rooted than others though, and I haven't yet had the motivation to fix them all. Also, I usually work on KAIK in batches, so if things seem dead you've just caught me during a dry spell, like now (ie. periods where I do only as-needed maintenance updates in the absence of any major bugs). But any issues you find I'm always happy to hear about, even if I won't deal with them for weeks.
Okydo, I'll keep this in mind :) My main concern was porting code of which there already was a heavily bugfixed version :D Mind, it's a fun and games project, with no saying how it'll end up, don't take it too serious ;) (I'm sure you dont XD). Sofar I've only got BuildUp and UnitHandler and the dgun thing done, and I'm seeing like 10% cpu against 0.something for kaik in c++ :) I'm really fearing the pathfinder ;)
Kloot wrote:
(Proper) naval support would take a rather large refactor, so I'm reserving that for my own AI project. ;)
I've seen the code up (too) close now, so yeah, I realize this XD
Some questions if you don't mind :) - The economy tracker, am I right that it doesn't actually do anything? It seems to track stuff, but I don't see it triggering any actions or so :) (What is it for? :D ) - Defenses seem to have been in there, but are now commented out, is there any specific reason for this? (refactoring, it broke, it never worked well, you didn't like it.. :) ) - I haven't been able to work out the builderTracker.idleStartFrame yet, it seems it's only set to -1 and -2, what does it mean? :)
Things I think may be issues: - The upgrade task uses buildClosestSite, I've seen mexes been misplaced by a lot because of this :) (normal building sticks mexes on exactly the metal spot). Ofcourse just building it on the old mex spot may give issues when the terrain only allows for a small mex, which I've seen in some maps, so this isn't trivial :) - bool CUNIT::Reclaim(int target) doesn't call ai->uh->BuilderReclaimOrder(...); like it's brethern CUNIT::Reclaim(float3 pos, float radius) which does, this results in error messages about idle units having reclaim orders or so after starting a upgrade (= reclaim >> build) order. - IdleUnitUpdate in UnitHandler should check isBeingBuilt(), so that it doesn't call verifyorders on units that are still in progress of being built, I think this causes some error messages too :)
Indeed that is a good catch, metal makers should be evaluated based on the conditional makesMetal (especially since metalMake and metalUpkeep will just be zero for most CAT_MMAKER units).
cranphin wrote:
The economy tracker, am I right that it doesn't actually do anything? It seems to track stuff, but I don't see it triggering any actions or so :) (What is it for? :D )
Nostalgia, it's mostly very old (dead) code that has no real purpose anymore.
cranphin wrote:
Defenses seem to have been in there, but are now commented out, is there any specific reason for this?
I accidentally left them disabled during a refactor, but didn't really mind when I found out since their placement was never optimal anyway (so they didn't help against rushes, were hindering expansion, etc).
cranphin wrote:
I haven't been able to work out the builderTracker.idleStartFrame yet, it seems it's only set to -1 and -2, what does it mean?
Newly created (but not yet finished) builders are set to -2 so they aren't updated during IdleUnitUpdate(), as are fnished builders without orders. It's rather silly and redundant though, like you point out with your isBeingBuilt suggestion there are many better ways to achieve that. Again ancient bitrotting code.
cranphin wrote:
The upgrade task uses buildClosestSite, I've seen mexes been misplaced by a lot because of this
The issue is that the replacement build order is sometimes given before the engine has properly cleaned up the old structure; a new building should otherwise be placed at exactly the same position as its predecessor (in theory anyway) even with the use of Build_ClosestSite.
cranphin wrote:
bool CUNIT::Reclaim(int target) doesn't call ai->uh->BuilderReclaimOrder(...); like it's brethern CUNIT::Reclaim(float3 pos, float radius) which does
Thanks, that one I actually had fixed locally.
cranphin wrote:
Mind, it's a fun and games project, with no saying how it'll end up, don't take it too serious
Not a problem. All AI's should be fun and games projects, although porting rarely is
Joined: 02 Jan 2007, 16:18 Location: Bremen, Germany
Just made a test game with 6357a2a with BA and Comet Catcher Redux. KAIK just built two mexes and waited. After it was attacked a few minutes into the game, it continued to play. Weird enough, AAI did show nearly the same problem.
i can not reproduce this with Ba and the same map (i used the Skirmish AI test script). It is not likely that i will ficx it, but.. i think Kloot would need more info to reproduce too. Could you probably post the script.txt yo uare using?
Joined: 02 Jan 2007, 16:18 Location: Bremen, Germany
I get that crash in the UnitDestroyed event pretty much every game after 20 minutes or more. Haven't posted it here yet because the buildbot can't seem to translate the addresses in the AI DLL.
(@hoijui) In the future, please consult with me before making "risky" changes like 1cb55f95dc231712f80741ede96832bee8001045. There are now multiple crash reports and I'm having a hard time telling the legitimate ones apart from those caused by that commit. It's also bad press even for a release candidate
yeah ok.. though i told everyone that it was my fault and i fixed it again. you are free to revert any such commits of course, i wont be angry. best would be if you would autojoin #ai id always inform you about slightest changes then, before applying.
as your AI is my another favourite just after RAI I thought I would drop by my impressions and suggestions here.
suggestions:
- teach the AI to favour hovercraft and air units no matter what on any map
- teach the AI to decide whether it should be teching OR swarming or BOTH based on first hour of gameplay, in order to optimally beat it's opponent (ultimate victory > fast victory > unnecessary risk pattern)
- make use of naval forces (lol, it's the most severely lacking feature atm)
- if possible, make your AI work with wider range of mods (for me it works perfectly with BA but refuses to work no matter what in NOTA?)
- do something with unit pathfinding, they often get stuck and cause heavy CPU load by that ... perhaps if a unit can't move within X radius for X time, it will wait X seconds before it issues move/attack/patrol order again, to not spam the game with unable to execute orders
- reduce CPU load of your AI, it's a good thing to have, but things get unbearable with 600+ units on the screen and more than one KAIK AI bot
questions:
- when is the new version incoming? I don't ask for a date but an estimate - as a fan of (not only yours) AI I would like to know current progress on things, including what's basically done, what still causes problems, what might be done at a later date
- teach the AI to favour hovercraft and air units no matter what on any map
Quote:
- make use of naval forces (lol, it's the most severely lacking feature atm)
... are actually related, ships/hovers/aircraft require specialistic handling (for a number of reasons) while KAIK is highly oriented towards ground combat and only "knows" how to use air besides land forces. Sea support in particular can't happen without a lot of digging around and restructuring, which wouldn't really be time-effective, but I intend to address the issue in my replacement / hybrid AI project (tentatively called XAI).
Quote:
- if possible, make your AI work with wider range of mods (for me it works perfectly with BA but refuses to work no matter what in NOTA?
Probably because NOTA's "commander" unit is a static building. IIRC it used to be able to play that mod OK-ishly though.
Quote:
- do something with unit pathfinding, they often get stuck and cause heavy CPU load by that ... perhaps if a unit can't move within X radius for X time, it will wait X seconds before it issues move/attack/patrol order again, to not spam the game with unable to execute orders
- reduce CPU load of your AI, it's a good thing to have, but things get unbearable with 600+ units on the screen and more than one KAIK AI bot
Indeed the command spam (and pathfinder calls) is what force-chokes Spring, groups get too large for their own good late-game unless you kill them quickly. It needs some sort of throttling mechanism.
Quote:
teach the AI to decide whether it should be teching OR swarming or BOTH based on first hour of gameplay, in order to optimally beat it's opponent (ultimate victory > fast victory > unnecessary risk pattern)
well, typically you can do one or the other, but not both at the same time (except on SpeedMetal)
- teach the AI to favour hovercraft and air units no matter what on any map
Quote:
- make use of naval forces (lol, it's the most severely lacking feature atm)
... are actually related, ships/hovers/aircraft require specialistic handling (for a number of reasons) while KAIK is highly oriented towards ground combat and only "knows" how to use air besides land forces. Sea support in particular can't happen without a lot of digging around and restructuring, which wouldn't really be time-effective, but I intend to address the issue in my replacement / hybrid AI project (tentatively called XAI).
Quote:
- if possible, make your AI work with wider range of mods (for me it works perfectly with BA but refuses to work no matter what in NOTA?
Probably because NOTA's "commander" unit is a static building. IIRC it used to be able to play that mod OK-ishly though.
Quote:
- do something with unit pathfinding, they often get stuck and cause heavy CPU load by that ... perhaps if a unit can't move within X radius for X time, it will wait X seconds before it issues move/attack/patrol order again, to not spam the game with unable to execute orders
- reduce CPU load of your AI, it's a good thing to have, but things get unbearable with 600+ units on the screen and more than one KAIK AI bot
Indeed the command spam (and pathfinder calls) is what force-chokes Spring, groups get too large for their own good late-game unless you kill them quickly. It needs some sort of throttling mechanism.
Quote:
teach the AI to decide whether it should be teching OR swarming or BOTH based on first hour of gameplay, in order to optimally beat it's opponent (ultimate victory > fast victory > unnecessary risk pattern)
well, typically you can do one or the other, but not both at the same time (except on SpeedMetal)
Hm, so for the moment you plan to do specialistic AI's, one focusing on ground and the other being a sea/air/hovercraft one? Nevertheless, it would be interesting to see a single bot capable of it at later date.
Cheers
PS. On the other hand, you could expand your KAIK from ground-oriented to skirmish-no-water oriented. I don't ask for hovercraft now, merely for some emphasis on the air units in bigger amount to support and shield ground armies, mainly gunships and bombers.
PS2. NOTA would crash for me with your AI, no idea why. The starting building is not a commander, it's simply an anti-rush base. In options you can start the game both with commander and base, or just base. I tried both, and it always crashed for me.
when it crashes, it is always a good idea to post the whole content of infolog.txt as attachment here in the forum post, or through http://springrts.pastebin.com.
Hm, so for the moment you plan to do specialistic AI's, one focusing on ground and the other being a sea/air/hovercraft one? Nevertheless, it would be interesting to see a single bot capable of it at later date.
No, XAI will be a single bot, just with (hopefully) a bit more intelligence behind its factory selections than KAIK.
Anyway, I looked into the NOTA problem (I didn't associate "refuses to work" with a crash before) and it's similar to this bug in XTA; ie. unit definitions being removed by the engine that cause KAIK to see holes in the mod's unit line-up and panic. Best solution would be to make the NOTA guys check their infologs, if they haven't already fixed it for 1.60
Interesting, do you have a high level design document outlining the overall structure of the AI and your idea behind why you chose it and how you intend it to play? (without handing over a url to a whole git repo and referring to KAIK?)
Got all (functionally relevant) code ported to java, bugfixing now, got it all fairly functional now (managed to let it win a match against a kaik opponent :D ).
Performance on my (pretty heavy :) ) rig is nearly acceptable, tho not great. Pathfinding seems the biggest burden, but still need to optimize a lot I think, that may help, step 1 is functional, step 2 is optimization :) Enabled defense building for the heck of it, finding a defense spot takes nearly a second XD, in the code there's a mention along the lines of 'this may take long' I think tho :)
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 (yay wikipedia for explaining what the heck the algorith is tho :) ). But I could see it possibly making more sense using friendlyPositions.size() (just the buildings) instead of numFriendlies .
Does anyone remember at all why this is the way it is ? :)
I could be way wrong btw., still figuring it out ^_^
Still on the version before 0.80 btw., scared to upgrade XD
Think I found another lil thing :) I noticed the AI building up 16 planes, sending them out, then building planes but not giving any orders anymore, till much later suddenly they fly out again (like at 40 planes or so, ouch XD).
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 :)
Could solve it in many ways, assign new waves, delete the air attack state after all 16 planes died, or most of them, or drop the state after a few minutes, I'm sure you'll come up with something creative :)
Also, this is based on my Java port, but I'm pretty sure the c version does the same, check tho! :)
It's good to fix this btw., since air can be pretty nasty in long games :D (was debugging/testing, nothing happend for ages, then got double nuked and got like 40 planes all over me, aaaghdie :D)
Could be a fun idea to increase wave sizes each time too, -mayby-, dunno :)
P.S. I'm at the latest Spring version again, whee :) AI port kinda functional now, except for performance, check it out at: http://code.google.com/p/crans-java-ai/ :) 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 ? :) I'd prefer sticking a generic GPL license on everything, think that's possible?
running on Linux 32bit in GDB latest spring master (16debace1b6e0ed29d0cde9f126286d833ea23e8) BA 7.01 on Brazillian Battlefield i started the Skirmish AI test script for E323AI, and then initialized KAIK on team 0 with /aicontrol 0 KAIK, then going spectator. crashed after some minutes with:
Code:
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb6284710 (LWP 31860)] 0x95d40649 in CDefenseMatrix::MaskBadBuildSpot (this=0x9309a758, pos={static binder = {class_ = 0x0, base = 0x0, flags = creg::CF_None, memberRegistrator = 0x95dfe2e4, name = 0x95dd9c5c "float3", size = 12, constructor = 0x95da5ce6 <float3::_ConstructInstance(void*)>, destructor = 0x95da5d26 <float3::_DestructInstance(void*)>, nextBinder = 0x95dfe2c0}, static memberRegistrator = 0x95dfe354, static CMP_EPS = 9.99999975e-05, static NORMALIZE_EPS = 9.99999996e-13, static maxxpos = 2048, static maxzpos = 2048, x = -0.999706507, y = 0, z = -1.27633739e-05}) at AI/Skirmish/KAIK/DefenseMatrix.cpp:49 (gdb) bt #0 0x95d40649 in CDefenseMatrix::MaskBadBuildSpot (this=0x9309a758, pos={static binder = {class_ = 0x0, base = 0x0, flags = creg::CF_None, memberRegistrator = 0x95dfe2e4, name = 0x95dd9c5c "float3", size = 12, constructor = 0x95da5ce6 <float3::_ConstructInstance(void*)>, destructor = 0x95da5d26 <float3::_DestructInstance(void*)>, nextBinder = 0x95dfe2c0}, static memberRegistrator = 0x95dfe354, static CMP_EPS = 9.99999975e-05, static NORMALIZE_EPS = 9.99999996e-13, static maxxpos = 2048, static maxzpos = 2048, x = -0.999706507, y = 0, z = -1.27633739e-05}) at AI/Skirmish/KAIK/DefenseMatrix.cpp:49 #1 0x95d67d0d in CUnitHandler::ClearOrder (this=0x8ebb0798, builderTracker=0x8d56a080, reportError=false) at AI/Skirmish/KAIK/UnitHandler.cpp:405 #2 0x95d6884d in CUnitHandler::IdleUnitUpdate (this=0x8ebb0798, frame=7935) at AI/Skirmish/KAIK/UnitHandler.cpp:104 #3 0x95d8d8ba in CKAIK::Update (this=0x93f1d320) at AI/Skirmish/KAIK/KAIK.cpp:225 #4 0x95da4484 in CAIUpdateEvent::Run (this=0x8d633ba0, ai=@0x93f1d320, globalAICallback=0x9334ebd8) at AI/Wrappers/LegacyCpp/Event/AIUpdateEvent.h:32 #5 0x95da42b8 in CAIAI::handleEvent (this=0x9334ec18, topic=3, data=0xbf7fefb4) at AI/Wrappers/LegacyCpp/AIAI.cpp:162 #6 0x95d4478a in handleEvent (teamId=0, topic=3, data=0xbf7fefb4) at AI/Skirmish/KAIK/AIExport.cpp:98 #7 0x089a078e in CSkirmishAILibrary::HandleEvent (this=0x962f3d50, teamId=0, topic=3, data=0xbf7fefb4) at rts/ExternalAI/SkirmishAILibrary.cpp:91 #8 0x089be6b1 in CSkirmishAI::HandleEvent (this=0x9ed93250, topic=3, data=0xbf7fefb4) at rts/ExternalAI/SkirmishAI.cpp:48 #9 0x0899d362 in CSkirmishAIWrapper::Update (this=0x943c7b10, frame=7935) at rts/ExternalAI/SkirmishAIWrapper.cpp:369 #10 0x0898e05b in CEngineOutHandler::Update (this=0x99bdc0d0) at rts/ExternalAI/EngineOutHandler.cpp:181 #11 0x0833b9d9 in CGame::SimFrame (this=0x9f899ad0) at rts/Game/Game.cpp:3489 #12 0x083430c9 in CGame::ClientReadNet (this=0x9f899ad0) at rts/Game/Game.cpp:3817 #13 0x08346fe0 in CGame::Update (this=0x9f899ad0) at rts/Game/Game.cpp:2830 #14 0x088d3b57 in SpringApp::Update (this=0xbf7ff890) at rts/System/SpringApp.cpp:842 #15 0x088dbd07 in SpringApp::Run (this=0xbf7ff890, argc=1, argv=0xbf7ff974) at rts/System/SpringApp.cpp:966 #16 0x088e1bd6 in Run (argc=1, argv=0xbf7ff974) at rts/System/Main.cpp:111 #17 0x088e1c31 in main (argc=0, argv=0xa9) at rts/System/Main.cpp:127 (gdb) list AI/Skirmish/KAIK/DefenseMatrix.cpp:49 Line 49 of "AI/Skirmish/KAIK/DefenseMatrix.cpp" starts at address 0x95d40622 <_ZN14CDefenseMatrix16MaskBadBuildSpotE6float3+84> and ends at 0x95d4064f <_ZN14CDefenseMatrix16MaskBadBuildSpotE6float3+129>.
edit: did it again with current spring master, same procedure, mod & map, same crash, as it seems:
Attachment:
File comment: 2nd stack-trace KAIK_crash_2.txt [6.05 KiB]
Downloaded 20 times
Users browsing this forum: No registered users and 1 guest
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot post attachments in this forum
Home
Download
Login
Register
FAQ
Search
