Specific Bug Reports

...I'm surprised no crashes have been reported in BBAI 1.0 since I'm sure that has to be where this crash is coming from...[/url]

I found a good reason why now. The crash only occurs when running a debug dll, a final release dll chugs on as though there is no problem, so it's likely this bug is in the new AI logging functions. Regardless those saves should help you track down and fix the issue.
 
So JDog... if capturing the holy city for an AI's own state religion is of extra value, then depriving an enemy of the holy city for his own state religion should be worth doing as well, shouldn't it?

2 is just my value, you could go with 4 if you want. (Though I still think much higher values are better for wonders and holies in this function, ie 8 and 24. :p) But with this, if two civs with the same state religion are at war and one has the holy city for it, the fighting over that city could be especially intense, ala Jerusalem. (That was an argument for not getting any clever ideas about putting an "else" before the second "if", btw. ;))

Added near the top of CvPlayerAI::AI_targetCityValue

Code:
/************************************************************************************************/
/* BETTER_BTS_AI_MOD                      05/16/10                     Mongoose & jdog5000      */
/*                                                                                              */
/* War strategy AI                                                                              */
/************************************************************************************************/
	iValue += 2*pCity->getNumActiveWorldWonders();

	for (iI = 0; iI < GC.getNumReligionInfos(); iI++)
	{
		if (pCity->isHolyCity((ReligionTypes)iI))
		{
			iValue += 3;

			if (GET_PLAYER(pCity->getOwnerINLINE()).getStateReligion() == iI)
			{
				iValue += 2;
			}
			if (getStateReligion() == iI)
			{
				iValue += 4;
			}
		}
	}
 
Ok it's working now, thanks.
Another oddity I've seen is that some leaders will give you the diplo hit "our close borders spark tension" right from the start, even though obviously you're still far from sharing cultural borders. Not all leaders do that though, Gilgamesh and Alexander are concerned but not Ragnar/Mansa/Pericles... not tested all of them.
I don't remember seeing this with the previous release so I think it may come with this update.

Edit : Hannibal does it too.
I think I know where that comes from. It's a side-effect of jdog's changes to CvTeamAI::AI_isLandTarget(), which might have been made to make early rushes possible, not sure if that function even has any influence there though. It must have been there in the 2010-05-26 version already though, nothing was changed there in today's update.

You will get these diplo hits if both you and the other leader have the capital on the same continent, and that leader has a iCloseBordersAttitudeChange of -3 or lower. (Alexander has -4, Gilgamesh -3). But that only happens when large portions of the continent are unclaimed, so it should go away as you settle more land.
How I fixed it: bullai r96
 
I'm getting a crash and a freeze/loop in Planetfall after merging in Better AI 1.0. The previous BBAI version included was .84.

The crash is caused (in two different and well-advanced games) when a barbarian ship (or in Planetfall lingo a native IoD) attacks another ship. In the attached screenshots you can follow the call stack which leads to the crash.

Some questions:

1) Is it normal headMissionQueueNode is NULL after the attack, or is this an indication something went wrong somewhere?
2) Why was that code added? What was the bug mentioned?
3) Is "Error: Expression cannot be evaluated" under CvUnit::isCargo() also an indication of trouble? What could cause this to happen??

Removing the "crash protection" code in fact stops the crash.

***

The freeze/loop happens in CvGame::updateMoves(). Code included in spoilers:

Spoiler :
Code:
void CvGame::updateMoves()
{
	CvSelectionGroup* pLoopSelectionGroup;
	int aiShuffle[MAX_PLAYERS];
	int iLoop;
	int iI;

	if (isMPOption(MPOPTION_SIMULTANEOUS_TURNS))
	{
		shuffleArray(aiShuffle, MAX_PLAYERS, getSorenRand());
	}
	else
	{
		for (iI = 0; iI < MAX_PLAYERS; iI++)
		{
			aiShuffle[iI] = iI;
		}
	}

	for (iI = 0; iI < MAX_PLAYERS; iI++)
	{
		CvPlayer& player = GET_PLAYER((PlayerTypes)(aiShuffle[iI]));

		if (player.isAlive())
		{
			if (player.isTurnActive())
			{
				if (!(player.isAutoMoves()))
				{
					player.AI_unitUpdate();

					if (!(player.isHuman()))
					{
						if (!(player.hasBusyUnit()) && !(player.hasReadyUnit(true)))
						{
							player.setAutoMoves(true);
						}
					}
				}

				if (player.isAutoMoves())
				{
					for(pLoopSelectionGroup = player.firstSelectionGroup(&iLoop); pLoopSelectionGroup; pLoopSelectionGroup = player.nextSelectionGroup(&iLoop))
					{
						pLoopSelectionGroup->autoMission();
					}

					if (!(player.hasBusyUnit()))
					{
						player.setAutoMoves(false);
					}
				}
			}
		}
	}
}

The problem is that player iI = 2 (so the third in row) keeps having a Ready Unit. player.hasReadyUnit keeps returning true. As a consequence Automoves doesn't get set true, and as a consequence Automoves doesn't get set back to false, and as a consequence the turn of the next player doesn't get activated and player.isTurnActive() for player 2 keeps returning true, causing an eternal loop. The reason why player 2 has Ready Unit(s) is because a selection group(s) has ACTIVITY_AWAKE. I haven't been able to figure out what selection group that is, or why it was set to ACTIVITY_AWAKE or why it doesn't snap back out of it.

Are all units supposed to end their turn with something else than ACTIVITY_AWAKE?

Given that this loop, just like the crash, both involve ACTIVITY_AWAKE, I'm wondering if these could be related? Removing the "crash protection" code doesn't prevent the loop though, so that speaks against the theory.

***

Any idea what might be the cause of these issues? I'm at a loss on how to proceed. :(
 
phungus & Maniac -

I'm thinking you might both be seeing the same issue ...

My guess is that the asserts I added when chasing some issues with AI units getting stuck in activity_sleep are causing problems in situations which might only arise in mods. There are two lines to comment out:

In CvSelectionGroupAI::AI_update

Code:
FAssert( getHeadUnit()->isCargo() || getActivityType() != ACTIVITY_SLEEP );

and in CvSelectionGroup::setActivityType

Code:
FAssert(isHuman() || getHeadUnit()->isCargo() || eNewValue != ACTIVITY_SLEEP);

My hunch is that the isCargo call could turn bad if a stack dies during the turn ... or maybe it's when a ship carrying cargo dies while attacking? I haven't seen any issues pop up in test games with debug DLLs and couldn't recreate, but this is my sense.

It's pretty clearly the solution for what you're seeing Maniac, and the symptoms are the same as you reported phungus. If this doesn't work for you guys I'll try the LoR saves tomorrow.
 
So JDog... if capturing the holy city for an AI's own state religion is of extra value, then depriving an enemy of the holy city for his own state religion should be worth doing as well, shouldn't it?

Good point, that should make for some good behavior. I'm going to try making the target city values visible in debug mode one of these days, as I feel they've never really been investigated/tweaked in game situations ...

How I fixed it: bullai r96

Thanks Fuyu!
 
Code:
/************************************************************************************************/
/* BETTER_BTS_AI_MOD                      05/16/10                              jdog5000        */
/*                                                                                              */
/* War tactics AI                                                                               */
/************************************************************************************************/
void CvPlayerAI::AI_conquerCity(CvCity* pCity)
{
	bool bRaze = false;
	int iRazeValue;
	int iI;

	if (canRaze(pCity))
	{
		iRazeValue = 0;
		int [COLOR="Blue"]iCloseness[/COLOR] = [COLOR="Red"][B]pCity[/B][/COLOR]->AI_playerCloseness(getID());

pCity is a new city. This means that pCity is owned by the conqueror player.
The conqueror player is "this" player (getID() player).

Then, iCloseness means a closeness from the getID() player to the same player's city.
I believe that it should be a closeness from the getID() player to the OLD city.

But... pOldCity is already deleted at CvPlayer::acquireCity() before calling this function.

I believe you have to calculate iCloseness at CvPlayer::acquireCity() before deleting pOldCity and to pass it to this function.
(I did so in my own modmod. Or perhaps you are able to construct more smart method. ;))

I have written this report with only virtual running in my brain. No actual testing.
I'm sorry if my pointing is meaningless.
 
You have correctly understood what is happening there, but this is what I want. The closeness value is the closeness to the rest of the conqueror's empire, so that if the city is right on the border of territory they already own then the conqueror will be more inclined to keep it. If it is instead fair away from the rest of their cities, then they're more willing to burn it down.

(If you want closeness to the previous owner's empire for something, you could get closeness from pCity->getPreviousOwner(). I think perhaps cultural pressure from the previous owner would be more useful here though.)
 
phungus & Maniac

Thanks for the help! Your solution solved the crash. The loop was caused by some bad written code added some time ago by myself to Planetfall. A unit was constantly leaving and joining the same selectiongroup. No idea why it only caused a problem now. I guess the situation where the bad code could cause a problem must have been extremely rare.
 
Thanks jdog5000, for explaining your intention.
I didn't find you had already changed CvCityAI::AI_playerCloseness() and mistook it could not calculate own city closeness.

I will steal your work again and again.:thumbsup:
 
I'm going to try making the target city values visible in debug mode one of these days, as I feel they've never really been investigated/tweaked in game situations ...

I picked my values by looking at the other values assigned for things in that function. If a city is already fully-bombarded (or defenseless to start with) that's a free 10 points right there. I don't know about you, but for most wonders and all holy cities I'd happily spend the time to bombard a new city instead.

Heck a city gets at least 4 points for each resource in its radius... I'd much prefer wonders and holies (which affect one's whole empire) over any number of resources I already have, and maybe even over ones I don't have (except key strategics). Actually that minimum value of 4 per resource is ridiculous, I'm changing it to 2 right now lol, then I need to look at the values AI_bonusVal() returns and see if those need work too.

The rest of AI_targetCityValue()'s values look pretty good to me though, so I think if you just switched to my wonder value (8) and holy city value (24) you'd be a lot better off... and game balance is one of my specialties... but don't worry that's the last time I'll mention this, I swear! :) :) :)
 
I have an interesting bug. In this CheatCode Info in CvGameTextManager, this causes an infinite loop in my mod (or any mod with really large tech trees, like RoM).
Code:
				for (int iI = 0; iI < GC.getNumTechInfos(); iI++)
				{
					iPathLength = GET_PLAYER(pPlot->getOwner()).findPathLength(((TechTypes)iI), false);

					if( iPathLength <= 3 && !GET_TEAM(pPlot->getTeam()).isHasTech((TechTypes)iI) )
					{
						szString.append(CvWString::format(L"\n%s(%d)=%7d", GC.getTechInfo((TechTypes)iI).getDescription(), iPathLength, GET_PLAYER(pPlot->getOwner()).AI_techValue((TechTypes)iI, 1, false, false, paiBonusClassRevealed, paiBonusClassUnrevealed, paiBonusClassHave)));
						szString.append(CvWString::format(L" (bld:%5d, ", GET_PLAYER(pPlot->getOwner()).AI_techBuildingValue((TechTypes)iI, 1, bDummy)));
						szString.append(CvWString::format(L"unt:%5d)", GET_PLAYER(pPlot->getOwner()).AI_techUnitValue((TechTypes)iI, 1, bDummy)));
					}
				}

I suspect getting the Path Length of Future Era techs gets stuck somewhere. Since the AI's only look at techs +1 era ahead of their current era, might I suggest this info do the same? Otherwise your wasting CPU time...
 
What about:
Only 2 min per resource; 6 per active world wonder; holy cities: 4 +2/+8/+4 (base theirs/ours/favorite) for a max total of 18 if we share religions and its our favorite.

That's certainly a lot better than vanilla's values, yeah. I give holy cities as much as I do (24 base + 12 for being theirs + 24 for being ours for a possible total of 60) because they can both provide a huge income boost from the shrine and a huge strategic advantage from vision of cities all over the world. However I suppose it'd probably be a good idea to scale this based on the current penetration/influence percentage of the religion, since I'd probably prefer a wonder over a holy whose religion only has like 2 to 5% influence.

I'm not sure about bringing a leader's favorite religion into this; if you did you'd again want to put a bonus in for depriving an enemy leader of his favorite as well. But a favorite just affects which religions a certain leader will try to found; it doesn't change anything once he's already founded what he has, whereas a state religion has real tangible benefits (and drawbacks) once it becomes active.

Though I suppose if a favorite also affects which religion a leader chooses when choosing his state religion, which I'm sure it does, then it might have longterm implications for what the state religion will be in the future, thus making the holy a bit more valuable... Though if leaders change over the course of a game like they do in my mod that's going to make this even more convoluted heh. But yeah I guess I can see a small bonus for favorite status being a good idea.

Alright, here's what I've cooked up. Remember, huge wars, generational struggles, and the rise and fall of whole societies have come about as a result of conflict over at least one specific holy city in the past; even though Jerusalem may be the only extreme historical example, we want the state religion bonuses here to be relatively high imo. I also increased the value of a city being coastal from 1 to 5 (primarily for allowing harbors and custom houses, and for helping with naval control in a war). Take from this definitive version what you will ;):

Code:
int CvPlayerAI::AI_targetCityValue(CvCity* pCity, bool bRandomize, bool bIgnoreAttackers) const
{

...

	//
	// Mongoose AITargetCityValueFix BEGIN
	//
	if (pCity->isCoastal(GC.getMIN_WATER_SIZE_FOR_OCEAN()))
	{
		iValue += 5;
	}

	iValue += pCity->getNumActiveWorldWonders() * 8;

	for (iI = 0; iI < GC.getNumReligionInfos(); iI++)
	{
		if (pCity->isHolyCity((ReligionTypes)iI))
		{
			iValue += 2 + ((GC.getGameINLINE().calculateReligionPercent((ReligionTypes)iI) * 2) / 3);
			if (getStateReligion() == iI)
			{
				iValue += 8;
			}
			if (GET_PLAYER(pCity->getOwnerINLINE()).getStateReligion() == iI)
			{
				iValue += 4;
			}
			if (GC.getLeaderHeadInfo(getLeaderType()).getFavoriteReligion() == iI)
			{
				iValue += 4;
			}
			if (GC.getLeaderHeadInfo(GET_PLAYER(pCity->getOwnerINLINE()).getLeaderType()).getFavoriteReligion() == iI)
			{
				iValue += 2;
			}
		}
	}
	//
	// Mongoose AITargetCityValueFix END
	//

	if (pCity->isEverOwned(getID()))
	{
		iValue += 3;
	}
	if (!bIgnoreAttackers)
	{
		iValue += std::min( 8, (AI_adjacentPotentialAttackers(pCity->plot()) + 2)/3 );
	}

	for (iI = 0; iI < NUM_CITY_PLOTS; iI++)
	{
		pLoopPlot = plotCity(pCity->getX_INLINE(), pCity->getY_INLINE(), iI);

		if (pLoopPlot != NULL)
		{
			if (pLoopPlot->getBonusType(getTeam()) != NO_BONUS)
			{
				//
				// Mongoose AITargetCityValueFix BEGIN
				//
				iValue += std::min(2, std::max(1, AI_bonusVal(pLoopPlot->getBonusType(getTeam())) / 10));
				//
				// Mongoose AITargetCityValueFix END
				//
			}

			if (pLoopPlot->getOwnerINLINE() == getID())
			{
				iValue++;
			}

ps - Holy carp AI_baseBonusVal() is a huge function. :p
 
Remember, huge wars, generational struggles, and the rise and fall of whole societies have come about as a result of conflict over at least one specific holy city in the past; even though Jerusalem may be the only extreme historical example, we want the state religion bonuses here to be relatively high imo.
You're thinking too much in historical terms and even there I think you are overrating the value of such a city.

I'm only thnking about whether or not this makes the AI better in warfare. And while I agree that useful wonders should have some value (4-6), and that holy city value should scale to spread ((2 + ReligionPercent/10) or so), I fear your super high values would make the AI too predictable and potentially less effective. The value for our own state religion should be high ("Crusade bonus": 6-10), the rest is just too much.
Their state religion: less than half of crusade bonus, our favorite: 2, theirs: 0.

But maybe that's just the atheist in me speaking :p

.. and coastal would get a +3 from me.
 
Can you two come to a consensus? :p I'm changing that function around every day now! :lol:
 
I have my doubts about that :lol: We'll wait for jdog to see what he has to say about it.
But in the end, you can use whatever values you see fit if it's for your own mod, no need to conform with anyone here.
 
You're thinking too much in historical terms and even there I think you are overrating the value of such a city.

I'm only thnking about whether or not this makes the AI better in warfare. And while I agree that useful wonders should have some value (4-6), and that holy city value should scale to spread ((2 + ReligionPercent/10) or so), I fear your super high values would make the AI too predictable and potentially less effective. The value for our own state religion should be high ("Crusade bonus": 6-10), the rest is just too much.
Their state religion: less than half of crusade bonus, our favorite: 2, theirs: 0.

But maybe that's just the atheist in me speaking :p

.. and coastal would get a +3 from me.

Well I already toned down my holy city value from its original 24-60, except where you have religions with like 50-100% influence or something rare like that. And 8 isn't too much higher than your wonder tolerance of 6. :) It's just that, like I said above, if you look at what the rest of the function is handing out, +10 for being fully bombarded, +2 to +10 (guessing; AI_baseBonusVal() is too much work to analyze right now lol) per resource when cities typically have 2 to 6 resources in their radius, and I would usually take wonders over any number of resources...

Then at the bottom another penalty of -1 per extra tile of distance, which alone causes anything but the closest target to be quickly ruled out unless you have decent values on wonders and holies, and even with mine they still won't be considered at more than a moderate distance away... Finally you have a random value in the range of zero to half the city's population, which is a wider spread in a random range than the entire value of a wonder with my values, so I don't think the AI becoming predictable is a huge issue... And even if it were, so what? If you played against me, and had a wonder I really wanted, I would try my darndest to capture it no matter how predictable that might make me. At the end of the day being unpredictable is all well and good, but only up to the point where you start giving up more in spoils than you gain from wily tactics.

But yeah the AI is already very predictable, in that it will always strongly prefer both closer cities and larger-population cities. Again, I'd choose wonders over high population numbers any day, if it were me, though I agree with those being more valuable than small cities all else being equal. So you kinda have to give wonders enough of a value to be competitive. And holies, which can easily reach values like +100 gold per turn and active vision of a third of the cities on the map, should be worth even more imo.

I realize extremely well I was making a historical rather than a gameplay argument there with Jerusalem btw, but in this case the historical behavior is what I would want to see, at least occasionally, in my games. The situation where you have two civs at war but on the same state religion is relatively rare anyway, and the holy city won't always be controlled by one of them either. If that does happen, I think there should be a little fireworks. Small boost further if the leaders favorite that religion. Rare situation, interesting behavior. Should actually make them a bit less predictable I would think. Still, if the populations or distances are large it won't matter anyway. And so 5 is, imo, a good value for coastal, when you factor in huge boosts to trade route values with the buildings it enables, and a potentially significant naval advantage.

And yes, I have been careful to sprinkle in imo's here, b/c I can't prove I'm right like I can when submitting a bugfix or something; no need to go highlighting them in your quotes of me. :p But I'm still convinced I am right. That being said I've now made the best argument I can make, so yeah JDog will go with whatever he wants to do; it's his mod afterall. And besides, you know I wuv yew Fuyu. :) :) :)
 
Hi again,

I just started a new team multiplayer game after updating to BBAI 1.0 (and BUG mod 4.4) and around 1000BC CIV crashes to desktop with the "Microsoft Runtime crashes for civbts.exe" message. From now on this happened every 10 minutes.
I tried reboot, graphic driver reinstall, emptying civ cache, lower graphic settings, compatibility mode for XP (runnning Windows7 64). But the crashes continued to happen, when I or my friend are doing something in the GUI (lowering taxes, moving units etc.)

Anybody seen this crash with BBAI 1.0? I have used the several BBAI (and BUG) versions almost from the beginning of this fantastic mod and never got this bug :(
 
Top Bottom