Inquisitors and the AI

[bane_]

How well does the AI handle Inquisitors? Do they even produce them?
I am wondering this because I want to make a Civ UU that replaces the Inquisitor.

While I do use CPP, I am asking this here - instead of there - to know how well the unmodded BNW-enabled game handles it.

 

[whoward69]

How well does the AI handle Inquisitors?

If it buys them with faith (see below), it will use them to remove other religions first and then defend their holy city

Do they even produce them?

Eventually. The AI's faith buying priority (hard-coded in the DLL) is prophet to found religion, prophet to enhance religion, prophet to re-establish religion, missionaries to convert all our non-puppet cities, our faith building(s) in all non-puppet cities, our other buildings that can be bought with faith, buy GPs (industrial and later), missionaries to convert puppet cities, missionaries to convert civs without their own religion, inquisitors, missionaries to convert any other civs, any faith building from other religions in our cities

I am wondering this because I want to make a Civ UU that replaces the Inquisitor.

Not going to work without a modded DLL (mine or CP or any other that replaces hard-coding of units with unit classes)

void CvReligionAI::BuyInquisitor(ReligionTypes eReligion)
{
	CvPlayer &kPlayer = GET_PLAYER(m_pPlayer->GetID());
	UnitTypes eInquisitor = (UnitTypes)GC.getInfoTypeForString("[B][COLOR="Red"]UNIT_INQUISITOR[/COLOR][/B]");
	...

Even if using a modded DLL, the AI will always use Inquisitors for remove heresy or defending the holy city from conversion - it will not use any other special abilities - so you'd need to use Lua to keep over-riding how the game-core wants to use them

 

[bane_]

Good to know, thank you again.

My Inquisitor replacement will be a stay-at-home-dad too, but I'm wondering if they only defend the Holy City or their other cities as well.

 

[whoward69]

The code is "number of cities to flip back plus one", so there'll only ever be one spare, and they always buy in the holy city so it'll just hang-out around the holy city

 

[bane_]

This is sad. Oh well, I will try to give them some Inquisitors every once in a while and see how that goes.

 

[whoward69]

This is sad.

I have that on repeat whenever I'm modding the DLL

You'll possibly need to keep pushing Move To orders for them as well, or they all may just flock back to the holy city

 

[AW Arcaeca]

Not going to work without a modded DLL (mine or CP or any other that replaces hard-coding of units with unit classes)

void CvReligionAI::BuyInquisitor(ReligionTypes eReligion)
{
	CvPlayer &kPlayer = GET_PLAYER(m_pPlayer->GetID());
	UnitTypes eInquisitor = (UnitTypes)GC.getInfoTypeForString("[B][COLOR="Red"]UNIT_INQUISITOR[/COLOR][/B]");
	...

Even if using a modded DLL, the AI will always use Inquisitors for remove heresy or defending the holy city from conversion - it will not use any other special abilities - so you'd need to use Lua to keep over-riding how the game-core wants to use them

Ooh. I hope I'm not derailing this thread, since it's a similar topic - do you know if this is also the case with unique missionaries? i.e. 1) can unique missionaries exist (I think CL did this somehow?), and 2) would they be used for anything other than spreading religion? What if that special ability was constructing an improvement - I assume the AI would still ignore that altogether?

 

[whoward69]

All religious and trade units are hard-coded to the unit type, not the unit class. IIRC some mods detect the creation of the standard unit and then swap them with the UU variant.

The Maya UA is hard coded to GP unit types, not class

AI choice of free GP is hard-coded to unit, not unit class

AI's with UUs for workers or archaeologists will be unable to disband them if they need to for economic reasons, as those decisions are also hard-coded

Without a modded DLL, the AI won't use secondary abilities (build roads/forts, fish, found, etc) at all - only workers build things and only settlers found cities.

Fishing boats are particular badly coded as it's tied to the Samurai and NOT the associated table column

Spoiler :

 	if (pPlot->isWater())
 	{
		if ((isEmbarked() && !pkBuildInfo->IsCanBeEmbarked())  && (strcmp("UNIT_JAPANESE_SAMURAI", getUnitInfo().GetType()) != 0))
		{
 			return false;
		}
 	}

Buildings are not as bad ... only guilds are consistently hard-coded - so UBs for them are a bad idea - and the AI checks for broadcast towers (not UB variants) when allocating GWs to maximise it's tourism output

Edit: All of these issues are fixed in my, and the CP, DLL

 

[LeeS]

Buildings are not as bad ... only guilds are consistently hard-coded - so UBs for them are a bad idea - and the AI checks for broadcast towers (not UB variants) when allocating GWs to maximise it's tourism output

*cue heavy sigh* Which explains some of the troubles I've seen people on steam reporting whenever they try to add unique versions of the Guilds.

*cue additional heavy sigh* re the Broadcast Towers. But at least that seems consistent with the CultureOverview panel

Spoiler :

Been so long since I looked at the code for the Broadcast Tower that I didn't even remember it has a slot for a Great Work of Music.

Edit: All of these issues are fixed in my, and the CP, DLL

*cue additional additional heay sigh* that you, Gazebo, etc., et al, even had to go to all that effort to find and fix the obvious bad methods used by the devs when working up CP and VMC, and the Unified Yields code.