Skirmish AI: E323AI 3.22.4

[Error323]

1: for some unknown reason i get crashes a lot in the late-mid/late game with the AI now. I cant point out any reason for this If you want i can send the infolog, however, i dont think it is very helpfull.

2: sometimes remains of attackgroups become idle after they have eliminated a player. The group (4-8 units) will sit still and idle for a while just to suddenly wake up again after 3 minutes. (something with the new merging scripts?)

3: The AI seems to perform less with a veh start then a bot start. It won more often in the .12 version then it does now in .13 . The AI benefits a lot from the cheaper bots, it enables it to perform more raids, and make more attack groups.
But!!... if you make it spam flash (remove all tags from non flash units in the vehplant :D ) It just overruns all AIs in 3v1 hahaha (ccr) it allmost looks human

4: Some ideas. Maybe they are usefull.
Is it posible to bind the probability of the construction of certain units (unit type) to a state? ie, state 1: artilery: 5% assault: 35% scouter: 60 etc. Because it often starts to build januses, stumpys or wolverines in state 0 or 1. Those have no use in BA at that stage.
Same would be usefull in the late game, you can filter out lowlevel eco buildings at higher stages, no more t1 metalmakers/solars when you have 150M/3000E.

1) This combined with the other posts suggests serious flaws somewhere, I'll take a good look at it. Its such a pitty that I can't use the infologs to find out exactly where it crashes. I have to run the simulation myself in the gdb and "hope" for the crash to appear.

2) Yes most likely, I have spotted this myself too and this is definitly a serious issue.

3) Yeah I hate vehicle for this reason, they are soo clumsy in terms of movement and they are much bigger. They clog up the factories, the only real way for the AI to use them would be to define precisely from what location they can assist and where they can build what. And this is a lot of work .

4) Interestingly that is close to how it works now:

• It counts all the enemy types (SCOUTER,ANTIAIR,ASSAULT,...)
• Calculates the probabilities of each type (like a pie chart or roulette wheel)
• By selecting a random number r somewhere in the piechart it returns, with high probability, the unit that occurs most in the current game
• Finally a build order is given to build the unit that best counters the unit selected by the previous step. I.e. for type AIR the best counter is ANTIAIR obviously

I will make this last step configurable as you guys know what counters what the best.

[FaerieWithBoots]

What i meant was that allthough the stumpy carries the tag ASSAULT (and an assault unit may be good against unit type X) You cant afford it them at 10M. You are allways better off with a cheaper unit (flash) I added the assault tag to the flash as well, but that didnt make the AI build less stumpys. So wouldnt it be an idea to make the choice of unit dependant on both income(state) and oppponents army composition. (maybe you allready do this, havent studied the source)

[FaerieWithBoots]

I will make this last step configurable as you guys know what counters what the best.

This would be so cool! The result is a pretty large config file though XD (370 units, each with at least 4 counters, thats a small database) But, hey!, you got the entire BA community to that for you

3) Yeah I hate vehicle for this reason, they are soo clumsy in terms of movement and they are much bigger. They clog up the factories, the only real way for the AI to use them would be to define precisely from what location they can assist and where they can build what. And this is a lot of work .

This can be solved by nanos
Placement shouldnt be that hard, use the same cluster algorythm you use for defenses placement, take only turrets and factorys into account et voila.
The controll of nanos is more difficult.(as you know even better then i do, lol)
1 Easiest implementation is just build and patroll. Will result in stall sometimes.

2 Make nanos wait or switch to higher priority project on stall. Yay! even more stuff to calculate :) They shouldnt take more CPU time then any other con though.

3 Defending nanos. Give repair of static defense highest priority. Will take even more calculations (checking health of all nearby defenses).

4 Defending nanos++ Reclaim attackers! (Obvioiusly, nanos are the most powerfull unit in BA) In case there are no defenses to repair and an enemy is near, reclaim it. Again, pretty cpu intensive stuff.

Didnt you have some sort of emergency defense system implemented? You could switch the nanos into "defensive mode". You reduce cpu load because you dont have to check for enemys all the time for nanos as well.

The moment to switch to nanos instead of regular cons could be set in the state. ie state 3: metal > 20 makeNanos = true

Maybe my imagination is just running wild, and none of this is realistic. :D I like just it to think about this kind of stuff

[Error323]

Well it would be done on the same level as the categorizations are so something like:

SCOUTER > ARTILLERY
ASSAULT > SCOUTER
ANTIAIR > AIR
ARTILLERY > ANTIAIR
SNIPER > ASSAULT

About your previous post I'll see what I can do, states are currently not taken into account for factorybuilds which they should.

[FaerieWithBoots]

oh, you added a reply while iw as editing XD

[yuritch]

Looks like something like STATE0, STATE1, etc tags could be used on units (to define at which minimal state this unit should be produced). And then something like MAXSTATE0, MAXSTATE1, etc to define when to stop building that unit because it's obsolete for current resource level.

(since the number of numbered state-dependent tags may get a bit too big with many states, how about changing config file format to something like state machine uses, so units can have minstate: 1 and maxstate: 4 for example).

[JohannesH]

very impressive unit micro. if you did want to take it even further for sadistic mega micro, have it take units out groups that are on low health- 15% or less- and run them back to base to heal (obv dont do this with scouters). when healed, put them into another group. if you could have cons repair waiting damaged units, even better.

Cool idea, I'll look into it.

Just pull them back a bit in their own group so they dont get fired on, retreating units all the back to base is usually bad, better to get those extra shots & win the battle, reclaim its wreck and have that used instantly, than having it do nothing for a long while and faring worse in the current fight. Or retreat whole group together when they get to low hp. But dancing would be useful, yes. Though kiting is probably the first type of better micro you want to implement.

I don't think there is any point having it build multiple t1 land factories, probably do better to go t2 where it currently goes vehicles.

It will be removed! Does this also apply for T2?[/quote]He's wrong, building another t1 lab is much safer than going t2. Dont remove stuff based on the hunches of people who dont even play BA :). Both with or without nanos, though with nanos you need nanos & labs placed near together (which is true about t2 fac as well though).

[slogic]

When attacking enemy unit group i recommend concentrate fire on units with high DPS (damage per second) first. So, you may loose less units.

Also there should be some algo with high priority to neutralize LRPC. I was watching a match where E323AI could win 3 other AIs but when RAI built 2 Berthas, the game started to go wrong for E323AI. E323AI could easily kill at least one of them but decided to continue execution of its own resource harassing algo. Finally it was pushed to its corner and died.

[hoijui]

about the crash when E323AI gets eradicated:
so far, it only happend 2 times to me, and in both of these games, i had settings accidentially on com ends, instead of kill everything, though i dont know what this should help.. could it be a problem that many units (including com) die in the same frame? (they all get destroyed if com dies and its set to comm ends).

[FaerieWithBoots]

Very strange behaviour on Aquatic divide: It refuses to raid :S It gathers up a big group of AKs/PEewees in its base.
E323 v3.13.1 vs KAIK
Playing with both Core and arm. On other maps this doesnt occur. I checked the categorisation and config, they are fine. If you want the rep file i can send it to you.

[hoijui]

Aquatic Divide.. sounds like a water map, is it not?
(caseu as stated in the last few release posts, these are not supported by the AI)

[Tobi]

It is not, it just has a small piece of water dividing the land, but there are also two land bridges (choke points) to the other side.

Also it has some water in two of the corners, but these pools are not used for sea stuff usually.

[slogic]

If the map has any segment of deep water then current version of AI is not suitable for this map. So, wait until Error323 removes "No watermaps support yet" note. Yep, this message does not mean AI does not support naval units. It means worse.

[FaerieWithBoots]

aha, i understand. That explains, thanks
I assumed no water support meant it would ignore water

[Error323]

If the map has any segment of deep water then current version of AI is not suitable for this map. So, wait until Error323 removes "No watermaps support yet" note. Yep, this message does not mean AI does not support naval units. It means worse.

xD

[Tobi]

Ah right, a bit stricter definition of water map

[Error323]

E323AI v3.14.2 - High Templar
Changelog:

• Fixed pathfinding on watermaps :} (thx Tobi)
• Restored building both KBOT and VEHICLE
• SIGSEGV fix

E323AI SO/DLL: E323AI-HighTemplar
E323AI SRC: E323AI@github

So watermaps are now possible, however the AI itself will never build water stuff. Furthermore, vehicle is still crap. I need to work on nanotower support. But first tell me it doesn't crash and pathfinding works everywhere :D

- Error323

edit:
Damn I found a SIGSEGV myself just now on a watermap, bluh supporting that creates a lot more complexity. I can't just assume anymore that I can attack everything etc. Sigh... next version is gonna take a while I think.

[Abaddon]

Still chashes

Code: Select all

[  38818] Spring 0.80.5.2 (0.80.5.2-0-g67e2f5b{@}-cmake-mingw32) has crashed.
[  38818] Exception: Access violation (0xc0000005)
[  38818] Exception Address: 0x0cced43f
....
[  38818] Stacktrace:
[  38818] (0) D:\Games\Spring\AI\Skirmish\E323AI\3.14.2\SkirmishAI.dll [0x0CCED43F]
[  38818] (1) D:\Games\Spring\AI\Skirmish\E323AI\3.14.2\SkirmishAI.dll [0x0CCED5DB]
[  38818] (2) D:\Games\Spring\AI\Skirmish\E323AI\3.14.2\SkirmishAI.dll [0x0CCD5D36]
[  38818] (3) D:\Games\Spring\AI\Skirmish\E323AI\3.14.2\SkirmishAI.dll(release+0xf3f) [0x0CCF5BA5]
[  38818] (4) D:\Games\Spring\AI\Skirmish\E323AI\3.14.2\SkirmishAI.dll(release+0x2a0e7) [0x0CD1ED4D]
[  38818] (5) D:\Games\Spring\AI\Skirmish\E323AI\3.14.2\SkirmishAI.dll(release+0xdc5a) [0x0CD028C0]
[  38818] (6) D:\Games\Spring\AI\Skirmish\E323AI\3.14.2\SkirmishAI.dll(handleEvent+0x96) [0x0CCF4947]
[  38818] (7) D:\Games\Spring\spring.exe [0x0084B946]
[  38818] (8) D:\Games\Spring\spring.exe(skirmishAiCallback_Unit_CurrentCommand_getOptions+0xcfc6) [0x0086A666]
[  38818] (9) D:\Games\Spring\spring.exe(aiInterfaceCallback_DataDirs_getWriteableDir+0x3869) [0x00880869]
[  38818] (10) D:\Games\Spring\spring.exe(skirmishAiCallback_Unit_CurrentCommand_getOptions+0x14434) [0x00871AD4]

[elias79]

This is probable already know but E323AI cheats alot when finding targets to attack,
like walking in the right direction without scouting

[1v0ry_k1ng]

non-resource hacking AIs need LoS hacks to be competetive, because they dont have the human ability to know and second guess and predict what their opponent is doing.

bearing in mind decent human players can still beat every AI into the floor, im all for LoS hacks.