FfH2 AI Mod (Highly Experimental!)

[Turinturambar]

No, the AIAutoPlay mod is included as part of Better BTS AI and isn't in the base mod.

Huh? Kael specifically mentions it in the bug thread. If you go into the Python Console and type CyGame().setAIAutoPlay(x) , the AI plays for you for x number of turns.

is the Better BTS AI Autoplay something else?

 

[Lone Wolf]

On a side note, I've discovered that the AI will sometimes use the mobility promotions on its 1-move melee and archery units, if you give it the AI weight of 50.

 

[Skyre Noktis]

Huh? Kael specifically mentions it in the bug thread. If you go into the Python Console and type CyGame().setAIAutoPlay(x) , the AI plays for you for x number of turns.

is the Better BTS AI Autoplay something else?

It has a few extra features - there's a keyboard shortcut for it, you can change the civ you control and it disables certain popups. The problem was caused by a Python file in the Better BTS AI mod related to this.

On a side note, I've discovered that the AI will sometimes use the mobility promotions on its 1-move melee and archery units, if you give it the AI weight of 50.

Sounds good. The promotion choices really need some looking at, to be honest, especially ones for countering other units.

I'd like to take free promotions into account better when picking units, too (especially for 'counter' and 'city counter' AI types), but every time I look at it it seems like a huge amount of work to get it to do this properly, especially if we take into account free XP (and the possibility to churn out melee units that start with shock, for example).

 

[Sephi]

I don't think it is a good idea to increase the Weight value of a common promotion like mobility, atleast not when you have access to the dll. For any unit in a selectiongroup with a catapult for example, the mobility promotion is a wasted promotion.

 

[Lone Wolf]

For any unit in a selectiongroup with a catapult for example, the mobility promotion is a wasted promotion.

Not really, since I always promote my units to Mobility the moment it becomes available, with the exception of those who are assigned to purely garrison duty. If a unit is currently in a stack with catapults in it, it doesn't mean it will stay that way.

 

[Sephi]

If a unit is currently in a stack with catapults in it, it doesn't mean it will stay that way.

Only very few actions will cause units to leave a selectiongroup. The reason number one will be death.

Your idea to let the AI value mobility promotions more is very interesting. I think in FF UNITAI_EXPLORE units have a higher promotion value on mobility. There are probably other UNITAIs like PILLAGE or COUNTER that could also use it.

 

[Lone Wolf]

Don't know about the AI, but for me, the mobility units are useful in nearly all circumstances. For example, reinforcements to the main stack can arrive more quickly, mobility units have the choice of quick getting out of danger zone, etc. Catapults are effective, but not that essential in FfH anyway, and in fact, when having highly promoted units, I often attack without them, due to their slowness. If the AI was taught to throw fireballs and bombard with them more consistently...

BTW, AI doesn't really understand that in FfH, catapults aren't so suicide-y as in classic Civ. When it uses them as a collateral-damage causing weapon in defence, it doesn't bother to protect them after they had finished the attacking.

 

[Turinturambar]

While working on my mod I noticed a few civ-specific deficiencies, which I couldn't easily fix. Maybe you could tackle these:

1) The Luchuirp AI does not seem to understand that it needs to protect its workers (the mud golem) from Barbarians/other civs. My guess is that they don't get properly classified due to their defensive strength.
This can lead to lots of dead mud golems.

2) The Sheaim AI loves to upgrade all its warriors to Pyre zombies. Since Pyre zombies don't count as military police all cities tend to suffer from "we demand military protection" unhappiness, which becomes quite large with a big city size.

3) The Calabim do not seem to value the governors manor properly. Especially for organized leaders it should be one of the first buildings, but the AI builds them only extremely rarely and only in very well developed cities.

Noncivspecific:

The Ai tends to attack barbarian skeletons at poor odds (e. g. with an unpromoted warrior against a skeleton on a forest), which can lead to them upgrading to spectres and the subsequent death by wraith. Maybe a special check would be helpful to only attack them at very good odds to prevent early AI death.

Edit Two more:
a) The AI has an absurdedly high valuation for mana, so it will give you every spare resource and all its gold per turn for your useless Shadow mana. In addition you get a +4 diplo modifier for the generous trade. I think the valuation is set to 100, but it really should not be more than a generic strategic resource.

b) The AI will not actively seek contact with other civs if it already has the terrain info via map trading. This leads to a lack of trade partners that could be easily corrected by just sending out one explorer unit.

 

[Skyre Noktis]

Thanks for the excellent feedback.

I'm planning to put out another minor version tonight, if all goes to plan, which should help address the Governor's Manor issue as the AI now correctly sees it as a production building, giving a hammer for each unhappy face. I think the fact that they're only -20% maintenance (and +1 unhappy) tends to make the AI not value them much until feudalism and vampires, otherwise.

Others:

1. Will look at this. This might help explain why the Luchuirp usually suck in my test games.

EDIT: Found (CvUnitAI::AI_workerMove):

if (!(getGroup()->canDefend()))
{
	if (GET_PLAYER(getOwnerINLINE()).AI_isPlotThreatened(plot(), 2))
	{
		if (AI_retreatToCity()) // XXX maybe not do this??? could be working productively somewhere else...
		{
			return;
		}
	}
}

It needs to be determining whether it's likely to win the battle, not just whether it can defend (however poorly), as it is as the moment.

2. Pyre Zombies should not be considered for UNITAI_CITY_DEFENSE (due to giving no military happiness). Are these city defense warriors that are being upgraded? If so, something's not working quite right here or maybe I'm misunderstanding the upgrade system. Might be worth a Python check to make sure it keeps one living unit per city, anyway. (Edit: From reading your post again, I'm not 100% sure if you meant you'd tested these with my mod in addition to yours. If not, and it turns out not to be a problem, we can ignore this one.)

3. (Covered above)

4. I'm wondering if this could be partly due to the iBaseAttackOddsChange and iAttackOddsChangeRand values in the leader XML file. These artificially increase the odds the AI sees, sometimes by quite high values. The only purpose I can see for this is to make the AI stupider. Remove?

5. Agreed.

6. Could be tricky, could be extremely simple. I'll have a look.

 

[Turinturambar]

Thanks for the excellent feedback.

I'm planning to put out another minor version tonight, if all goes to plan, which should help address the Governor's Manor issue as the AI now correctly sees it as a production building, giving a hammer for each unhappy face. I think the fact that they're only -20% maintenance (and +1 unhappy) tends to make the AI not value them much until feudalism and vampires, otherwise.

The problem is probably also related to the incorrect tooltip, which only gives hammers according to pop over the happy cap. If the AI calculates it as such, no wonder it almost never builds the building.

2. Pyre Zombies should not be considered for UNITAI_CITY_DEFENSE (due to giving no military happiness). Are these city defense warriors that are being upgraded? If so, something's not working quite right here or maybe I'm misunderstanding the upgrade system. Might be worth a Python check to make sure it keeps one living unit per city, anyway. (Edit: From reading your post again, I'm not 100% sure if you meant you'd tested these with my mod in addition to yours. If not, and it turns out not to be a problem, we can ignore this one.)

If you have already blocked units with AI_CITY_DEFENSE from being upgraded, it could very well not be a problem in your mod, I haven't merged my mod to yours yet. But in the base game the AI tends to upgrade all warriors.

4. I'm wondering if this could be partly due to the iBaseAttackOddsChange and iAttackOddsChangeRand values in the leader XML file. These artificially increase the odds the AI sees, sometimes by quite high values. The only purpose I can see for this is to make the AI stupider. Remove?

Hmm it's pretty flavourful for e.g. Perpentach and attacking at low odds is not always a bad idea due to the possible high experience reward. A bit of unpredictability is not bad to hurt for example choking tactics. I'd keep it.

 

[Skyre Noktis]

The problem is probably also related to the incorrect tooltip, which only gives hammers according to pop over the happy cap. If the AI calculates it as such, no wonder it almost never builds the building.

It didn't factor it in at all. In fact, none of the new XML attributes for buildings are taken into account properly.

Hmm it's pretty flavourful for e.g. Perpentach and attacking at low odds is not always a bad idea due to the possible high experience reward. A bit of unpredictability is not bad to hurt for example choking tactics. I'd keep it.

So that brings us back to your initial problem, warriors attacking skeletons at too low odds.

I think it's worth removing the random odds change from calculations for heroes, at least, as that should improve their longevity quite a bit. It can be pretty large, though. Unless I'm reading things wrong, Mahala will average +16% on every odds calculation.

 

[Turinturambar]

So that brings us back to your initial problem, warriors attacking skeletons at too low odds.

Hmm I guess if you could remove the random chance only when attacking barbarian units that would solve the problem?

 

[Skyre Noktis]

New version is up. I haven't done any work on it since last week, so don't expect anything 'cutting edge'.

Also, since Turin posted a comparison...

Fall from Heaven 2 v0.41a:



Fall from Heaven 2 v0.41a with FfH2 Better AI v0.2.2:



Maybe not quite as impressive as his economically (a head to head would be fun), but I'm sure a merger could sort that out.

 

[Turinturambar]

Heh can you post the save? I'll merge and we see what comes out .

Those screenshots look very impressive too.

 

[Skyre Noktis]

Here you go.

It's a worldbuilder save, as the actual save games aren't binary-compatible (a couple of extra XML fields). Just select Varn at the menu screen and it should be exactly the same setup as the ones I posted.

 

[[to_xp]Gekko]

a merge of the two mods would be great

 

[Skyre Noktis]

I'm half-working on it.

There will be a few changes so that it better fits in with things I've already altered/fixed, though. I ripped out all the religion-founding stuff from AI_chooseTech, for example, because I have code in the DLL that serves a similar purpose.

 

[Opera]

Just checked your code in CvPlayerAI. I like what you've done with the weights (it's a shame they weren't used before!). You removed everything related to favoriteReligion? Why?

I just fought some hours to exposed getReligionWeightModifier to python in order to use the weights in AI_chooseTech... Maybe I will use the DLL then... But I find it too convoluted. I mean, AI_bestTech is a huge function with so much things to take into account...

 

[Skyre Noktis]

Just checked your code in CvPlayerAI. I like what you've done with the weights (it's a shame they weren't used before!). You removed everything related to favoriteReligion? Why?

The XML field wasn't used and the religion weight values make it obsolete, IMO.

I just fought some hours to exposed getReligionWeightModifier to python in order to use the weights in AI_chooseTech... Maybe I will use the DLL then... But I find it too convoluted. I mean, AI_bestTech is a huge function with so much things to take into account...

With the Python, you should just be able to add a single line to one of the CyInfoInterface3.cpp to get the religion weights exposed. In the definition for the CvLeaderHeadInfo class:

.def("getReligionWeightModifier", &CvLeaderHeadInfo::getReligionWeightModifier, "int (int i)")

 

[Opera]

The XML field wasn't used and the religion weight values make it obsolete, IMO.

That makes sense. I forgot that I use it only with my new leaders... Anyway, I want to keep it, I don't know why. I could just enter 100 in ReligionWeight... Well, without your changes, FavoriteReligion is still used in some places instead of the weights, so...

With the Python, you should just be able to add a single line to one of the CyInfoInterface3.cpp to get the religion weights exposed. In the definition for the CvLeaderHeadInfo class:

.def("getReligionWeightModifier", &CvLeaderHeadInfo::getReligionWeightModifier, "int (int i)")

Thanks I had found it, though