Assert in CvPlayer.cpp DoGold()

Chazcon

Prince
Joined
Feb 16, 2006
Messages
476
Location
Left Coast
Modding BtS - in CvPlayer.cpp I get this assert at some point in every game I'm playtesting while debugging. For the life of me I can't track down this damn bug. I haven't modded anything specifically to do with gold but you know how it is... as you can see I've commented it out so I can continue to test my mod stuff but at the end I'd like this bug to be resolved. Anyone else encounter this?

Code:
// Protected Functions...

void CvPlayer::doGold()
{
	bool bStrike;
	int iGoldChange;
	int iDisbandUnit;
	int iI;

	CyArgsList argsList;
	argsList.add(getID());
	long lResult=0;
	gDLL->getPythonIFace()->callFunction(PYGameModule, "doGold", argsList.makeFunctionArgs(), &lResult);
	if (lResult == 1)
	{
		return;
	}

	iGoldChange = calculateGoldRate();

	//FAssert(isHuman() || isBarbarian() || ((getGold() + iGoldChange) >= 0) || isAnarchy());// ChazModTEMP asserts here, bug not found

	changeGold(iGoldChange);

	bStrike = false;

	if (getGold() < 0)
	{
		setGold(0);

		if (!isBarbarian() && (getNumCities() > 0))
		{
			bStrike = true;
		}
	}

	if (bStrike)
	{
		setStrike(true);
		changeStrikeTurns(1);

		if (getStrikeTurns() > 1)
		{
			iDisbandUnit = (getStrikeTurns() / 2); // XXX mod?

			for (iI = 0; iI < iDisbandUnit; iI++)
			{
				disbandUnit(true);

				if (calculateGoldRate() >= 0)
				{
					break;
				}
			}
		}
	}
	else
	{
		setStrike(false);
	}
}
 
Yes, in all my mods and many other people's mods, and in an unmodded game even. If you're just worried about it, then stop and disable it. Assert is not a bug. This assert simply means that one of AI players is suffering from an economic crisis and is losing more GPT than it has Gold, which has no bad consequences (Gold doesn't become negative). Normally the AI handles its economy to avoid getting broke, but it happens often in scenarios, and it can happen even in an unmodded game if you pre-place some cities/units in the editor.
 
Well isn't an assert a place to verify that a value is within a range you're expecting at that point? In order to see if your code is working as intended? And if it's not, isn't that the definition of a bug?

Or, you place an assert while coding as a tool to check bits of code, but before release you pull all those out. My 2 cents.

Anyway thanks, I'll leave it commented out and keep on keeping on.
 
Back
Top Bottom