Unit AI differences

DarkScythe

Hunkalicious Holo
Joined
May 6, 2014
Messages
804
Hey everyone,

I am wondering if anyone might be able to explain to me what the differences between the various Unit AI Types and the Default Unit AI are.

Specifically, I'm not entirely sure what the differences are between UNITAI_ATTACK, UNITAI_FAST_ATTACK, and UNITAI_DEFENSE.
Currently I've got them assigned to my UU's since they appeared in stock units, and they do seem to work, but I don't want the AI using this unit to attack Cities since they have a huge penalty there. I had intended for them to try and use these solely for anti-unit combat, but the AI decided to rush my City with eight of them and got completely wiped out in the attempt to take my City.

I suspect the UNITAI_ATTACK may be telling the AI that it's a valid unit for attacking cities in which case removing that should help, but I'm not entirely sure.

Thanks!
 
Well, I guess this isn't something people seem to deal with very often.

In either case, I did some more poking around and found this on the wiki which appears to contain the logic the AI might use to create an army for various scenarios.

Assuming this is true, and I'm understanding everything correctly (which I might not, as I'm making assumptions about the data here) I would also assume that when the AI wishes to create an army to do a specific task, it refers to this list in order to build an appropriately-diversified army based on whatever unit AI types are set in each unit.

Each unit "slot" appears to contain both a primary and a secondary unit type which would satisfy that particular requirement. However, I'm unsure of their exact relationship; whether the AI attempts to fill out their army with all available UNITAI_ATTACK units, and then falling back to UNITAI_DEFENSE units when it runs out, or if it looks more specifically for UNITAI_ATTACK units which also have a secondary unit AI type of UNITAI_DEFENSE.

Regardless, based on this information, it seems like I may be safe to set my units' default AI type to something such as Counter, instead of Attack, even though these units don't have the Spearman's innate "cavalry counter" ability.

Is anyone more knowledgeable about this stuff able to drop in and confirm whether or not I'm on the right track?
 
You're more or less on the right path. Basically attack -> go look around for stuff to kill; city/line defense -> hold position in designated area(s); reserve -> literally keep in reserve twiddling their thumbs until an AI strategy invokes the AI to go looking around for units to tortur.... er, play with.

Counter just means "build use this unit when I see enemy has a large number of X units that is countered by my Y unit" (at least, that's what it did in Civ4). If you're going to set random units to UNITAI_Counter when they do not have any sort of bonuses, you may find them to be rarely built (as a "counter").
 
The AI pretty much ignores the UnitAI type until it is deciding what to do with the units it has, the value plays no part in deciding what to build.

If the AI decides it needs melee units, it will build units with the highest combat value (not combat strength) that it can, if it wants ranged units, it will build units with the highest combat value that are also ranged, etc. This is why, late game, the AI almost always goes to war with SAM units - as they get ridiculous bonuses when calculating the combat value of a unit which make them almost as powerful (in the AI's eyes) as GDRs (Mechs). So if you have UU's that are meant to be defensive only, but have a high combat str or promotions that give them high bonuses, expect the AI to love them to bits and use them for just about everything.
 
The AI pretty much ignores the UnitAI type until it is deciding what to do with the units it has, the value plays no part in deciding what to build.

Ah, thought it went into the calculation for that as well (would make a little more sense with regards to leaderhead flavors i.e. "I want units that will perform X role" in addition to its unit type).
 
Thanks for the comments, guys!

I'm not sure if the various unit AI types have specific logic attached to them, or if the AI uses them all the same way, and the AI type is only to allow the AI to 'group' them together when creating these multi-unit formations.

Based on that, and what you brought up about Civ4, I may have to test it and see if it works as expected or not. The units don't have any specific counter, but rather are meant to counter all manner of land units and not Cities.

Based on what whoward said though, it may all be a wash since the AI might decide, like the mobile SAM units, that they're the best one for every job, including attacking Cities, despite having a -50% penalty.

I also wonder if, based on this, I might be able to remove the UNITAI_ATTACK type entirely, as it seems they'll still be used for attacking (cities?) regardless, assuming the AI has nothing else better and specifically defined as an attack class.

Whoward: I also gathered that the UnitAI didn't play any part on when the AI trained these units -- I was under the understanding that this was decided by the Unit Flavors. I don't mind encouraging the AI to train these units, I just didn't want them throwing them uselessly at Cities, as it's more or less comparable to throwing a ton of very expensive Scouts at a City.

Right now I'm testing by throwing a few copies of my Civ onto a map and using Firetuner to enable Autoplay and watching how the AI uses their units. I'll see if I can spot any difference.
 
The AI pretty much ignores the UnitAI type until it is deciding what to do with the units it has, the value plays no part in deciding what to build.

If the AI decides it needs melee units, it will build units with the highest combat value (not combat strength) that it can, if it wants ranged units, it will build units with the highest combat value that are also ranged, etc. This is why, late game, the AI almost always goes to war with SAM units - as they get ridiculous bonuses when calculating the combat value of a unit which make them almost as powerful (in the AI's eyes) as GDRs (Mechs). So if you have UU's that are meant to be defensive only, but have a high combat str or promotions that give them high bonuses, expect the AI to love them to bits and use them for just about everything.

That's interesting, seems I need to check the DLL source code to see how that value is calculated... Also, are the flavors important too when the AI makes a decision which unit to build?
 
CvUnitEntry:: DoUpdatePower() it's full of bugs. The worst ones being that any combat bonus multiplies the base value plus all previous bonuses, and not just the base value. That is, what should be

V = baseV + (baseV * bonus1) + (baseV * bonus2)

is actually

V = (base * (1 + bonus1)) * (1 + bonus2)

Add to that that full bonuses are given even if they are against a different domain (land vs air in the case of SAMs) and the calc for SAM units (300% vs air) are way off the scale!
 
Hrm, interesting.
It strikes me that there are many areas in this game where the math is weird, or just downright awful -- Trade route yield being one of the ones I directly encountered.

I take it flanking bonuses are also calculated the same way, despite being extremely variable and reliant on multiple adjacent units?
 
From my point of view the thing that is going to be problematic are the bonuses against specific unit classes - for example I gave some ships an attack bonus against other ships. This can't be done using a bonus vs domain or combat class, because it only allows a modifier, that works both in attack and defense, and I want attack only. So I use SQL code to create an attack bonus vs all unit classes that are naval melee units and naval ranged units. It's only 1/10 of the bonus added to the power, but still if it's against ALL ship classes, and it's multiplicative instead of addictive, it can get huge.

I also have a promotion that gives an attack bonus against all land units, and the number of land unit classes is much higher than naval unit classes, but it's only used as selectable promotion when a unit gains a level. So it can only cause problems with the promotion evaluation procedure.

But anyway I'm going to start using a custom DLL at some point, so all such problems can be fixed.
 
Are you saying that not only are the bonuses being multiplied by other bonuses, but it's also being multiplied repeatedly for each type of valid target it can be used against? That sounds beyond ridiculous.

Unfortunately, while I'm told that whoward's DLL fixes these issues, I'm still trying to get my (first) mod vanilla compatible as much as possible, so I have to deal with Firaxis' weird logic.

With all that said, I've been running tests while on autopilot with several AI, and things are getting better, though still plagued with Firaxis-math.

Adjusting my units' unit AI type, plus tweaking the leader's flavors seems to be helping quite a bit; there's now a decent mix of melee plus ranged units, although the ranged units are 98% of the time Catapults. The other units are dependent on Horses and Iron and don't seem to appear very often though, but I imagine probably because the AI doesn't seem to prioritize settling near and improving such resources?

Either way, that multi-unit formation file I linked was quite helpful in determining which AI types to use, and helped explain some of the bizarre armies they sent to siege cities with.
 
The other units are dependent on Horses and Iron and don't seem to appear very often though, but I imagine probably because the AI doesn't seem to prioritize settling near and improving such resources?

If you find the AI not improving these resources enough, you could increase the value of:

Code:
<Update>
      <Where Name="AI_PLOT_VALUE_STRATEGIC_RESOURCE"/>
      <Set Value ="80"/>
</Update>
<Update>
      <Where Name="AI_PLOT_VALUE_LUXURY_RESOURCE"/>
      <Set Value ="40"/>
    </Update>
<Update>

to be greater, although these values seem to affect mostly city plot purchases/improvements.
 
Would that not be a global update?

I'd prefer my mod to be encapsulated, with changes only to itself.
On the other hand, once they do acquire some strategic resources, I do see quite a few dependent units appear on the field, which makes me happy enough.
 
Those values are from the defines table, found in GlobalAIDefines.xml, not sure what you mean by "encapsulated".
 
Yeah, those would affect every Civ, then.

What I mean by encapsulated is that whatever changes my mod does, or adds, should only affect my own mod, and nothing else; I'm not attempting to make a global rebalancing mod or anything.

I've stumbled across that before, when I was trying to mod Pantheon and Religion costs, but realized every Civ shared one value.
 
To be more specific: do you mean "this should only affect one (or a subset of) civilization(s)"? Or "this should only affect AIs"? (and also in what context of changes are you referring to?).

Do you mean "I don't want to modify the base source files", when you say "affect my own mod"? Because updating the game database with a mod will only affect your own mod (if it's turned on), and you aren't modifying any source files at all.
 
Yeah, changes I make in my mod should be limited in scope to my mod; thus, 'should only affect one Civilization' -- mine.

My philosophy currently is that if I load up my Civ, but she is either not present in the game, or is present as an AI, I should not, if I am playing another Civ, suddenly be affected by changes I made to my Civ, or to have other AI influenced by what my Civ requires in order to get its AI doing what I want.

For example, I could not feasibly adjust the cost of the starting Pantheon or Religion, because those changes would be global and cause every single Civ to use the new values, instead of just my Civ.

Along those lines, I'd rather avoid telling every single AI to value strategic resources more highly, simply because my own Civ needed that push.

I feel these sort of "global modifications" should occur in its own, well-advertised 'overhaul' mod of sorts, and would be outside the scope of simply adding one Civilization into the game.
 
Top Bottom