nice! :D thank you! will try today! about GetFriendlyUnits() it should return the units of the AIs team aswell, as it uses TeamHandler.Ally(allyTeam1, allyTeam2), and each allyTeam is allied with itsself. ... thanks to you, i found some bugs in the pureint branch :D when i had a look at GetFreindlyUnits()
yeah.. don't have an idea right now why it would be different for mexes from ones own team.
I would like to warn that you may still notice double mexes during situations when AI decided to build a mex & then while a builder is approaching its goal another allied player completes its own mex so that building place is not overlapped with the place AI has chosen. AI currently does not periodically validate its goal if the way to it takes too long & can't change its mind.
Yes, i thought about it while coding but was lazy (and tied) to make a loop. But it is not enough actually. We need API to trace a stripe, not a ray. D-Gun is wide enough. So, even making a loop will not make 100% intellectual D-Gun usage. May be we can imitate stripe trace with making two ordinary traces on the edges of a stripe. It will be perfect until stripe width is more than width of the smallest unit bounding box.
It would be interesting to set up an FFA with all the existing AI and see who wins the most games out of 5. I currently have no idea which AI is the best and hardest to play against. Could somebody link me up? There's a bunch of threads here with many pages to follow so I cba to dig through it all to find the best AI for BA.
KAIK crashes with BOTA 1.6 (fix-8) because ai->cb->GetUnitDefList() (file UnitTable.cpp, method CUnitTable::Init()) fills vector with NULLs since about 40th element. I tried to ignore error with "continue" statement (smth similar is done in E323AI), but then i got a crash inside SkirmishAI.dll!std::_Lockit::~_Lockit(). I don't know what it is.
By the way, other AIs work with BOTA (personally tested RAI & E323AI). They have another approach in parsing unit definitions.
Last edited by slogic on 22 Jan 2010, 21:00, edited 1 time in total.
its still BOTAs fault. the engine fills the unit DefList with NULL's if the defines are invalid. in the past, the engine did not do this, but now does (uses stricter tests.. its the right way to do as it is now). Supreme Annihilation has hte smae problem, XTA had it too, ... BOTA devs should be bugged to fix/cleanup their mod.
other AIs works with BOTA (personally tested RAI & E323AI). They have another approach in parsing unit definitions.
There is nothing bad to make AI more stable & forgive modders some of their mistakes.
PS. I almost forget. Increase dst buffer up to 2048 bytes in Util.cpp. I don't know why but using strcpy_s() under MSVC causes a crash when you try to copy data from 2048-sized buffer into 1024-sized even if 2048-sized buffer contains a string with much less effective symbol count than 1024. 2048 is taken from CAIAICallback::GetValue:
yeah true.. if KAIK would forgive that, it would be ok too. i guess nobody would dismiss a patch doing this. and as all other stuff seems to work fine even with NULL values in the unitDef list, modders usually care little about fixing it.
Normally I would do an if check at start up on whether the unitdef is NULL and skip that particular definition. Not the best of situations but I guess if the unitdef shows up as null for the AI and inside the engine too then there's no chance of the unit ever being built and the AI not being able to handle it.
The moral of the story here being that the AI interface is an API too, and your code should check what the return values are for errors, and validate the contents, and display error messages and abort/recover if necessary.
Changelog: * fixed a crash with insufficient buffer length if compiled with MSVC2008 (looks like in debug mode only) * best metal spot range is fixed: now AI really will not build (take decision actually) occupied metal spots by allies; at first attempt i made changes according to code template which was actually wrong * (experimental) AI will reclaim enemy metal maker nearby its brand new metal maker (this may occur if enemy metal maker is not armed)
i have these changes in 3 different commits now (pushed to master). it was quite a mess though, please use git, and if you think git is strange, then please explain why, i would like to explain you. in the end, it will be better for both of us. we all had our problems/confusion with git in the beginning, nothing to be ashamed of.
KAIk has been running pretty smoothly lately, except for a recent game where it got stuck. This happend because it build its first factory right next to a rock wall, blocking the factory exit. cons vehicles couldn't exit so after a few units the bot got stuck.
maybe it should detect this situation and use the commander to start a new factory. or even better, prevent the situation at all
In 3 way FFA tests with shard rai and kaik under evorts, KAIK builds one or two metal extractors then builds nothing, could you look into this?
It's because all EvoRTS energy-producing buildings are "armed" with pseudo-weapons to generate FX, so KAIK thinks they are ground defenses (which it doesn't build anyway) and gets stuck because of a hardcoded "build two metal and two energy structures first" rule.
The last time I thought about refactoring this was before I started XAI, but we'll see.
For my Java port of KAIK (Yep, still alive, still working on it, and it's gonna be rather playable once the Spring pureint branch gets into production :) ), I'm thinking of just opening the unit config file a lot more, so people can override categories. So for mods where units get miscategorized (Evo, CA, everything not BA/XTA :D), people could solve it with config. Think that's a good idea? :) Not sure if there would be other snags elsewhere, 'll find out soon tho I think ^_^
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