Version 2.52 released!

Tholal

Emperor
Joined
May 19, 2009
Messages
1,676
2.52 officially released on December 30th, 2013. (should be compatible with previous 2.51 saves)

Download link

A little New Years present.

Thanks to lfgr, MagisterCultuum, Terkhen and fe79 for the coding assistance!

Bugfixes


  • Index page now displays properly in Sevopedia (fix by MagisterCultuum)
  • canMakePuppet() now checks for isPuppetStateTrading rather than isVassalStateTrading
  • Game will no longer crash if a unit with the Boarding ability captures a fort occupied only by naval units
  • casting Declare Nationality will no longer automatically deselect the unit (the code was forcing the unit to create a new group (so that HN units wouldnt end up grouped with non-HN units) - I changed it so that if the unit is in a group of one, it wont form a new group)
  • units should now receive civ-appropriate art when upgraded
  • fix for UNITAI_EXPLORE_SEA units getting stuck in a loop
  • fix for OOS logs not being generated (fix by fe79) - also includes an updated OOSLogger.py file from C2C
  • Pillar of Fire will now attempt to start fires in the target tile
  • Fixed an issue that was causing the AI to ignore the allowed UNITAI types in UnitInfos.xml when choosing what troops to build
  • Hero units should no longer be assigned to UNITAI_INQUISITOR
  • Fix for an assert error when opening the Civopedia from the main menu (find and fix by Terkhen)
  • War Tortoise entry in Civopedia will no longer display info about War Elephants

AI:


  • AI more interested in techs that give free Great People; AI should be better about pursuing victory techs when trying for an Altar victory
  • AI should no longer build UNITAI_MISSIONARY_SEA units if it has no religion or missionary units
  • AI will now cast Sanctuary and March of the Trees based on opponents' power percentage rather than number of wars they are involved in
  • AI should be better about claiming useful resources in areas with bad terrain
  • When the AI is pursuing a Conquest victory, it will delay building Conquest stacks until it has a Warplan in place
  • first pass at adding AI_STRATEGY_ECONOMY_FOCUS to MNAI (base code taken from K-mod)
  • some tweaks to how the AI stages Naval Assaults; tweaks to how the AI groups units flagged with GROUPFLAG_CONQUEST and how Conquest stacks pick target cities
  • AI less likely to run a DAGGER strategy when pursuing an Altar or Tower victory
  • AI should no longer declare war when staging a naval invasion until their ships/troops are in range of the enemy territory
  • Angels now default to UNITAI_ATTACK_CITY
  • AI less likely to target cities that will Auto-raze on capture
  • AI should produce less naval units if they have only a few coastal cities
  • AIs with few cities but large production should be better about pursuing Wonders and Hero units
  • AI should no longer value units that cant be built (ie War Elephants) when choosing techs

UI:


  • Updates to Worldbuilder (code by MagisterCultuum and playpting)
  • Entertain spell message will no longer display as a loss of negative gold to the target player

Code:


  • Additional logging
 
Ohh shiny! Stuff!

Btw, Tholal, I dont know where it originates but I am sure you are aware of the Kuriotate MP OOS bug. I encountered it while playing Extra Modmod and Magister's mod with some people online. I was wondering if you know how to fix it?
 
Ohh shiny! Stuff!

Btw, Tholal, I dont know where it originates but I am sure you are aware of the Kuriotate MP OOS bug. I encountered it while playing Extra Modmod and Magister's mod with some people online. I was wondering if you know how to fix it?

That bug has been around for AWHILE... Good thing I don't do MP lately :D
 
Ohh shiny! Stuff!

Btw, Tholal, I dont know where it originates but I am sure you are aware of the Kuriotate MP OOS bug. I encountered it while playing Extra Modmod and Magister's mod with some people online. I was wondering if you know how to fix it?


Check the OOS Discussion, Tracking and Fixing thread for information.
 
In BarbsPlus, units that spawn from lair exploration (possibly multiple at once), stay at the lair and push your units out, like Magister implemented in his mod. This caused them often to stay there and do nothing. I found the relevant code in CvUnitAI.cpp, AI_barbAttackMove():
Code:
if (!bHero && plot()->isLair(false, isAnimal()))
{
	if (plot()->plotCount(PUF_isUnitAIType, UNITAI_LAIRGUARDIAN, -1, (PlayerTypes)BARBARIAN_PLAYER) == 0)
	{
		// ToDo, split off a unit to guard it if we are in a group
		if ((!bHero || iCaution >= 4) && getGroup()->getNumUnits() == 1)
		{
			AI_setUnitAIType(UNITAI_LAIRGUARDIAN);
			getGroup()->pushMission(MISSION_SKIP);
			return;
		}
		else // wait till we have a guard unit
		{
			getGroup()->pushMission(MISSION_SKIP);
			return;
		}
	}
}

First, I think that the (!bHero || iCaution >= 4) is unnecessary. Since !bHero is already forced in an &&, it will be always true, making the whole expression true. The following code is equivalent:
Code:
// ToDo, split off a unit to guard it if we are in a group
if (getGroup()->getNumUnits() == 1)
{
	AI_setUnitAIType(UNITAI_LAIRGUARDIAN);
	getGroup()->pushMission(MISSION_SKIP);
	return;
}
else // wait till we have a guard unit
{
	getGroup()->pushMission(MISSION_SKIP);
	return;
}

If I understand correnctly, the ToDo (and the else) is especially for the case that the unit is a hero or very incautious. Therefore, if the group is not hero or very incautious, the head unit just can split off and defend (you'd probable want to loop through the units to get the best defender/worst attacker, but I have no idea how to do that). Heroes and incautious units instead should wait.

This is what I came up with finally:
Code:
if( plot()->isLair( false, isAnimal() ) && plot()->plotCount(PUF_isUnitAIType, UNITAI_LAIRGUARDIAN, -1, (PlayerTypes)BARBARIAN_PLAYER) == 0 )
{
	if( !bHero && iCaution < 4 )
	{
		// split off a unit to guard it if we are in a group
		// TODO: select unit to split off
		AI_setUnitAIType(UNITAI_LAIRGUARDIAN);
		if( getGroup()->getNumUnits() > 1 )
			joinGroup(NULL);
		getGroup()->pushMission(MISSION_SKIP);
		return;
	}
	else // wait till we have a guard unit
	{
		getGroup()->pushMission(MISSION_SKIP);
		return;
	}
}
I tested several cases with one or two barb skeletons with different unitAIs on a barrow and two of my units nearby as potential targets:
2 UNITAI_ATTACK_CITY: one attacks, the other becomes a lair guardian
1 UNITAI_ATTACK_CITY + 1 UNITAI_HERO: the hero attacks, the other becomes lair guardian
1 UNITAI_HERO + 1 UNITAI_ATTACK_CITY: the hero waits one turn, then attacks. Not optimal.
2 UNITAI_HERO: both stay at the lair. Also not optimal, it should check whether there are already units/groups guarding the lair. Not sure how to do this best (check for MISSION_SKIP?).
In BarbsPlus, I either way prefer heroes leaving lairs unguarded over guarding them, so I just removed the last else block and the caution check.

Sorry for all the text, just wanted to be sure you understand my intentions to find possible mistakes.
 
In BarbsPlus, units that spawn from lair exploration (possibly multiple at once), stay at the lair and push your units out, like Magister implemented in his mod. This caused them often to stay there and do nothing. I found the relevant code in CvUnitAI.cpp, AI_barbAttackMove():

Thanks for the report. All of your assumptions seem correct. Looking at the code, I might consider just commenting out that LairGuardian section. I dont think it's really doing much that is useful.
 
This is still being worked on? :clap:
 
Top Bottom