AAI 0.60 released (win + linux version included)
Moderators: hoijui, Moderators
.
I just noticed something.
When testing on the same map, I think I noticed a correlation between how long the game took to crash and how high the unit limit was (it's still much more stable than 0.55 though, nice job
) - is there any chance that the AI is getting confused when it's not allowed to build more units?
I know it's pretty obvious so I'm probably wrong, but then maybe you always test at limits of 5000 (which AFAIK are never reached) and haven't noticed the bug.
Either way, this AI kicks ass and has now given me several huge battles of long duration without crashing.
When testing on the same map, I think I noticed a correlation between how long the game took to crash and how high the unit limit was (it's still much more stable than 0.55 though, nice job
) - is there any chance that the AI is getting confused when it's not allowed to build more units?I know it's pretty obvious so I'm probably wrong, but then maybe you always test at limits of 5000 (which AFAIK are never reached) and haven't noticed the bug.
Either way, this AI kicks ass and has now given me several huge battles of long duration without crashing.
I just tested the .so and it actually works! great work! Hopefully more AI devs will release linux binaries now 
I haven't tested with gcc versions lower then 4.0 yet, but you might want to put the gcc version and #of bits (ie. 32 or 64) in the name of the so. That because a 32 bit .so won't work on 64 bit compiled spring and vice versa. (but maybe nicke already told you this)
anyway, it works, but it crashed after a while (just after finishing a mex on SmallDivide), here's a backtrace (which points out the obvious advantage of including the symbols with the .so ):
E: oh, this was running mod xtape.sd7, which actually is a renamed XTAPEV5.sd7
I haven't tested with gcc versions lower then 4.0 yet, but you might want to put the gcc version and #of bits (ie. 32 or 64) in the name of the so. That because a 32 bit .so won't work on 64 bit compiled spring and vice versa. (but maybe nicke already told you this)
anyway, it works, but it crashed after a while (just after finishing a mex on SmallDivide), here's a backtrace (which points out the obvious advantage of including the symbols with the .so
):
Code: Select all
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1456001984 (LWP 14267)]
0x59bce93f in AAIExecute::FindExternalMetalSpot () from aidll/globalai/aai.so
(gdb) bt
#0 0x59bce93f in AAIExecute::FindExternalMetalSpot () from aidll/globalai/aai.so
#1 0x59bcf3cb in AAIExecute::BuildExtractor () from aidll/globalai/aai.so
#2 0x59bd0c05 in AAIExecute::CheckConstruction () from aidll/globalai/aai.so
#3 0x59bd6a4f in AAI::Update () from aidll/globalai/aai.so
#4 0x080510ef in CGlobalAIHandler::Update (this=0x8e67510) at rts/ExternalAI/GlobalAIHandler.cpp:61
#5 0x081213a7 in CGame::SimFrame (this=0x86f4448) at rts/Game/Game.cpp:1254
#6 0x0812d4ed in CGame::ClientReadNet (this=0x86f4448) at rts/Game/Game.cpp:1677
#7 0x0812e46f in CGame::Update (this=0x86f4448) at rts/Game/Game.cpp:947
#8 0x0827966e in SpringApp::Draw (this=0xffffd160) at rts/System/Main.cpp:569
#9 0x0827b5ef in SpringApp::Run (this=0xffffd160, argc=1, argv=0xffffd224) at rts/System/Main.cpp:734
#10 0x0827b826 in main (argc=152623476, argv=0x918d974, envp=0xffffd22c) at rts/System/Main.cpp:813
according to nicke it has to do with the cpu load - some multithreading issues i didnt even know about may cause the game to crash. i changed that and it seems as if my test version runs much more stable than aai 0.6Soulless1 wrote:I just noticed something.
is there any chance that the AI is getting confused when it's not allowed to build more units?
but dont ask me for further details, i dont know much about threading. im currently adding some minor things as well as aata support, i think there'll be a minor update sometimes the next week
@af:
i agree with you, a UnitBeingCaptured() callback function would be nice, iirc you wanted to take care of the ai interface. perhaps you could add this and we'll have a minor update of the current ai interface before designing a completly new one
I'm going to work on the groupAI callback instead and get NTai working under it, then add another thign I've been designing to seperate GroupAI and Global AI while keeping them in the same interface.... That way we then ahve 2 itnerfaces liek we currently do, one unified interface for groupAI + new globalAI and the old GlobalAI interface.
That and I'll release an AI udner the new setup that has the old setup inside it like a bridge between the two, and you can keep on using the current itnerface while adding bits fromt he new as you wish, or use half half transfering the AI or just the parts that'd use it.....
That and I'll release an AI udner the new setup that has the old setup inside it like a bridge between the two, and you can keep on using the current itnerface while adding bits fromt he new as you wish, or use half half transfering the AI or just the parts that'd use it.....
so there is
LAND_WATER_MAP - map contains both water and land (with direct land connections to the other bases)
and
WATER_MAP - pure water map (AAI will not build any ground assault units)
on maps like shore 2 shore and divided shores it calls it a land_water map despite the fact that the two AAI's on the map cannot reach each other with land units. Switching it to water_map means that they seem to only build ships and not planes or hovers.
Could you add another setting where it builds air and hovers in addition to water so that it would work better on island maps with neither the land-unit buildup on the shore (Land_water) nor with the lack of air support (water_map)?
LAND_WATER_MAP - map contains both water and land (with direct land connections to the other bases)
and
WATER_MAP - pure water map (AAI will not build any ground assault units)
on maps like shore 2 shore and divided shores it calls it a land_water map despite the fact that the two AAI's on the map cannot reach each other with land units. Switching it to water_map means that they seem to only build ships and not planes or hovers.
Could you add another setting where it builds air and hovers in addition to water so that it would work better on island maps with neither the land-unit buildup on the shore (Land_water) nor with the lack of air support (water_map)?
yes on some maps you have to switch the maptype manually - but remember deleting the map learn file afterwards (otherwise the changes wont take effect)
aai should build hovers and aircraft on all map types. but it remebers how efficiently it could use them in batlle, so if dozens of hover crafts get shreddered by a few ships it will more focus on building ships the next few matches
switching from land_water:map to water_map only prevents aai from building ground units
aai should build hovers and aircraft on all map types. but it remebers how efficiently it could use them in batlle, so if dozens of hover crafts get shreddered by a few ships it will more focus on building ships the next few matches
switching from land_water:map to water_map only prevents aai from building ground units
Wouldn't matter, the capture alert wouldn't be issued until the capture was completed, and it would override any further commands. The unit being captured, would still recieve orders, and attempt to carry them out, the unit doing the capturing would simply be destroyed, and wouldn't complete it. If it moves out of range the capturer should pursue.
-
unpossible
- Posts: 871
- Joined: 10 May 2005, 19:24
Sub, could you dynamically vary the 'max builders per type'?
Instead of starting off with a fixed number which all of the factories build of each type of builder before they start churning out units, could you start off with a much lower initial number (1?) and then work out how many builders there should be as the game goes on, gradually growing the building force.
It might help the ai start off a little bit quicker on the smaller maps, or when it builds an AA vehicle factory or adv kbot lab in XTA...skipping building 3 or 4 of every possible type of builder before committing to a fighting force.
Not sure exactly how to do this... perhaps relate it to the number of factories in total (as a ridiculously simple example)?
You could keep that new MAX BUILDER PER TYPE number for the AI, which it would then go about maintaining - priority replacement etc. The end game might be more fun after they start spewing out insta-bulldogs with the 20 fark builder army.
Instead of starting off with a fixed number which all of the factories build of each type of builder before they start churning out units, could you start off with a much lower initial number (1?) and then work out how many builders there should be as the game goes on, gradually growing the building force.
It might help the ai start off a little bit quicker on the smaller maps, or when it builds an AA vehicle factory or adv kbot lab in XTA...skipping building 3 or 4 of every possible type of builder before committing to a fighting force.
Not sure exactly how to do this... perhaps relate it to the number of factories in total (as a ridiculously simple example)?
You could keep that new MAX BUILDER PER TYPE number for the AI, which it would then go about maintaining - priority replacement etc. The end game might be more fun after they start spewing out insta-bulldogs with the 20 fark builder army.
-
unpossible
- Posts: 871
- Joined: 10 May 2005, 19:24
Maybe the max limit could be pretty soft, i mean let the ai decide the limit based on available resource (STRUCTURES/BUILDINGS!). Or maybe detect the 'good' builders like farks and produce more to boost manufacture speeds.
The minimum 'limit' (or just the one) is the key for sure. After that the 'max' needs to be a dynamic target, based on available resources.
The minimum 'limit' (or just the one) is the key for sure. After that the 'max' needs to be a dynamic target, based on available resources.
aai does already rate builders atm. i've often seen games wheer it built 4 or 5 cons. kbots but only 2 beavers (in aa). but apart from that i absolutely agree with you. i just have to find out a good way to determine the game state (independend from the mod)unpossible wrote:Maybe the max limit could be pretty soft, i mean let the ai decide the limit based on available resource (STRUCTURES/BUILDINGS!). Or maybe detect the 'good' builders like farks and produce more to boost manufacture speeds.
right now im working mainly on fixing bugs. the coming aai version should be much more stable and there have been plenty (~10) of other bugs fixed (which didnt crash the game but cause odd behaviour)