BUG Crashes vanilla BtS when displaying event log

When we put SimCutie's in, I'm sure that we must have used her color values. I remember when we were making the Options that EF was using them in there as well.
 
I searched our code for those and didn't turn up any. EF also said he was using standard color values in a post somewhere.
 
I got a copy of the game DLL with asserts on (what ever that means). It threw this error when I tried to bring up the in-game log ...
What it means, is wherever in the code there is an Assert: Test if Statement is True. If the statement being checked is False, the game crashes.

This DLL shows you what Assert is causing the game to crap out.
 
yeah ... good, but where do I go from here? Why is 'e' greater than the total number of colors and where is the total number of colors set?
 
Sometimes when code crashes it isn't necessarily that - which is causing the bug.
I recall it being mentioned changes were done to Autolog for whether it is turned on or not, or perhaps it was only hotkey changes.
But I do see a fairly significant difference between 2.20 and 2.30 in -\python\Contrib\autolog.py
The Following is missing from 2.30 completely.
Code:
	def setLogFileEnabled(self, LogFileEnabled):
		BugAutolog.setEnabled(LogFileEnabled)
		BugAutolog.write()

	def Enabled(self):
		if BugAutolog.isEnabled():
			return True
		else:
			return False
Which implies to me, possibly the logfile is not initialized when we are trying to open it for the first time...
 
different log file - talking about the alt-tab in game log, not the autolog.
 
debug ... how? Do I need any special software to do that?
 
I dunno, it was one of the [ Tab ] choices on your screenshot.
It might require "Debugging Tools for Windows" (WinDbg), or CIV might have it in the SDK?

I used to use GDB in Cygwin, but that was when I was doing Mud coding and gcc compiling C code.

With a debugger you would be able to see what called getColorInfo, and the value of the variable it passed to it.

The game is crapping out on the Assert that checks value > numberOfColors
So something is calling getColorInfo and passing a value that is too big.

Honestly I am not familiar enough with the code, I perused it for a while but too many unknowns.

If I had to guess, ColorUtil.py isn't being properly initialized or its attempting to pass a color value greater than the game expects.

It's possible between versions the order which things are loaded has changed. Which could have some impact down the line.
 
Or if you can print info to the log, add a line to ColorUtil.py that logs the call it is making to getColorInfo, and the value of the variable it is passing. Since that is the only place I see a call to getColorInfo in BUG.
 
I'm looking for references to 'getNumColorInfos' in the c++ code. It is referenced in the following:

  • Vanilla
    • C:\Program Files\Firaxis Games\Sid Meier's Civilization 4\CvGameCoreDLL\CvGlobals.cpp
    • C:\Program Files\Firaxis Games\Sid Meier's Civilization 4\CvGameCoreDLL\CvGlobals.h
    • C:\Program Files\Firaxis Games\Sid Meier's Civilization 4\CvGameCoreDLL\CvInfos.cpp
    • C:\Program Files\Firaxis Games\Sid Meier's Civilization 4\CvGameCoreDLL\CvXMLLoadUtilitySet.cpp
    • C:\Program Files\Firaxis Games\Sid Meier's Civilization 4\CvGameCoreDLL\CyGlobalContext.cpp
  • BtS
    • C:\Program Files\Firaxis Games\Sid Meier's Civilization 4\Beyond the Sword\CvGameCoreDLL\CvGlobals.cpp
    • C:\Program Files\Firaxis Games\Sid Meier's Civilization 4\Beyond the Sword\CvGameCoreDLL\CvGlobals.h
    • C:\Program Files\Firaxis Games\Sid Meier's Civilization 4\Beyond the Sword\CvGameCoreDLL\CyGlobalContext.cpp

CvGlobals.cpp
Code:
int CvGlobals::getNumColorInfos()
{
	return (int)m_paColorInfo.size();
}
Code:
CvColorInfo& CvGlobals::getColorInfo(ColorTypes e)
{
	FAssert(e > -1);
	FAssert(e < GC.getNumColorInfos());
	return *(m_paColorInfo[e]);
}
CvGlobals.h
Code:
	DllExport int getNumColorInfos();
	std::vector<CvColorInfo*>& getColorInfo();
	DllExport CvColorInfo& getColorInfo(ColorTypes e);
CyGlobalContext.cpp
Code:
CvColorInfo* CyGlobalContext::getColorInfo(int i) const
{
	return (i>=0 && i<GC.getNumColorInfos()) ? &GC.getColorInfo((ColorTypes)i) : NULL;
}

CvInfos.cpp
Code:
bool CvPlayerColorInfo::read(CvXMLLoadUtility* pXML)
{
	CvString szTextVal;
	if (!CvInfoBase::read(pXML))
	{
		return false;
	}

	pXML->GetChildXmlValByName(szTextVal, "ColorTypePrimary");
	m_iColorTypePrimary = pXML->FindInInfoClass( szTextVal, GC.getColorInfo(), sizeof(GC.getColorInfo((ColorTypes)0)), GC.getNumColorInfos());

	pXML->GetChildXmlValByName(szTextVal, "ColorTypeSecondary");
	m_iColorTypeSecondary = pXML->FindInInfoClass( szTextVal, GC.getColorInfo(), sizeof(GC.getColorInfo((ColorTypes)0)), GC.getNumColorInfos());

	pXML->GetChildXmlValByName(szTextVal, "TextColorType");
	m_iTextColorType = pXML->FindInInfoClass( szTextVal, GC.getColorInfo(), sizeof(GC.getColorInfo((ColorTypes)0)), GC.getNumColorInfos());

	return true;
}
Code:
bool CvYieldInfo::read(CvXMLLoadUtility* pXML)
{
	CvString szTextVal;
	if (!CvInfoBase::read(pXML))
	{
		return false;
	}

	int iNumSibs, j;

	pXML->GetChildXmlValByName(&m_iHillsChange, "iHillsChange");
	pXML->GetChildXmlValByName(&m_iPeakChange, "iPeakChange");
	pXML->GetChildXmlValByName(&m_iLakeChange, "iLakeChange");
	pXML->GetChildXmlValByName(&m_iCityChange, "iCityChange");
	pXML->GetChildXmlValByName(&m_iPopulationChangeOffset, "iPopulationChangeOffset");
	pXML->GetChildXmlValByName(&m_iPopulationChangeDivisor, "iPopulationChangeDivisor");
	pXML->GetChildXmlValByName(&m_iMinCity, "iMinCity");
	pXML->GetChildXmlValByName(&m_iTradeModifier, "iTradeModifier");
	pXML->GetChildXmlValByName(&m_iGoldenAgeYield, "iGoldenAgeYield");
	pXML->GetChildXmlValByName(&m_iGoldenAgeYieldThreshold, "iGoldenAgeYieldThreshold");
	pXML->GetChildXmlValByName(&m_iAIWeightPercent, "iAIWeightPercent");

	pXML->GetChildXmlValByName(szTextVal, "ColorType");
	m_iColorType = pXML->FindInInfoClass(szTextVal, GC.getColorInfo(), sizeof(GC.getColorInfo((ColorTypes)0)), GC.getNumColorInfos());

<more of this section that I snipped>

CvXMLLoadUtilitySet.cpp
Code:
	if (bLoaded && Validate())
	{
		SetGlobalClassInfo(&GC.getColorInfo(), "Civ4ColorVals/ColorVals/ColorVal", &GC.getNumColorInfos());
	}
 
The number of color infos returned by getNumColorInfos() is determined when creating all the color infos as the game loads up. They are created using the XML files.

BUG originally had SimCutie's extra colors, but we have since removed those. BUG at this moment is not created any new colors.

What's happening is that while BUG is running a log message is created using a color code X that doesn't exist outside of BUG. The thing is, there shouldn't be any colors defined in BUG, so this should be impossible. I'll take another scan through the files to make sure, but I'm perplexed.
 
Hi EF - I scanned the BUG python files for COLOR_* and couldn't find any that aren't in BtS standard. Is there a way of printing out the total list? Run the code in BUG, run the code in vanilla BtS and compare.
 
Maybe we should change the alerts to have actual colors instead of calling something like COLOR_YIELD it will call COLOR_YELLOW?
 
I put this code (actually, slightly different you know what I mean) into BUG ...

Code:
if ( eventType == self.EventKeyDown ):
	if (int(key) == int(InputTypes.KB_T) and self.bShift and self.bCtrl):
		for i in range(0, 126):   #range(0,1000000):
			ci = gc.getColorInfo(i)
			ci2 = "XML Val %i %s" % (i, ci.getXmlVal())
			print ci2

It printed out the first 127 colours. The next colour (#127, the 128th) caused a crash. I then created an almost empty customassets folder with 1 file in it and printed out the colours from there. This time, the last colour (#126, the 127th) caused a crash. The different colour ...

"XML Val 126 COLOR_PLAYER_LIGHT_BLACK_TEXT"

This value occurs in 'CIV4ColorVals.xml' (BtS only) and just happens to be the very last (of 127) text entry ...

Code:
- <ColorVal>
  <Type>COLOR_PLAYER_LIGHT_BLACK</Type> 
  <fRed>0.251</fRed> 
  <fGreen>0.251</fGreen> 
  <fBlue>0.251</fBlue> 
  <fAlpha>1.00</fAlpha> 
  </ColorVal>
- <ColorVal>
  <Type>COLOR_PLAYER_LIGHT_BLACK_TEXT</Type> 
  <fRed>0.392</fRed> 
  <fGreen>0.392</fGreen> 
  <fBlue>0.392</fBlue> 
  <fAlpha>1.00</fAlpha> 
  </ColorVal>

So, BUG finds the BLACK_TEXT entry but vanilla BtS doesn't? Doesn't that imply that vanilla BtS has a bug and BUG doesn't?
 
Why wouldn't this cause the game to crash when anyone opens it? We should pull up Warlords and see if we get the same results or not.
 
it could be that BUG writes something to the log using that color and then vanilla BtS crashes when it tries to retrieve the color info for it. Wish we had a utility to extract the log from a saved game.
 
A quick search for LIGHT_BLACK in BUG found these:

In Civ4PlayerColors Infos:

Spoiler :
Code:
<PlayerColorInfo>
	<Type>PLAYERCOLOR_BLACK_AND_GREEN</Type>
	<ColorTypePrimary>COLOR_PLAYER_LIGHT_BLACK</ColorTypePrimary>
	<ColorTypeSecondary>COLOR_PLAYER_MIDDLE_GREEN</ColorTypeSecondary>
	<TextColorType>COLOR_PLAYER_LIGHT_BLACK_TEXT</TextColorType>
</PlayerColorInfo>

And #126, and #127 in the Color Infos,

Spoiler :
Code:
<ColorVal>
	<Type>COLOR_PLAYER_LIGHT_BLACK</Type>
	<fRed>0.251</fRed>
	<fGreen>0.251</fGreen>
	<fBlue>0.251</fBlue>
	<fAlpha>1.00</fAlpha>
</ColorVal>

and

Spoiler :
Code:
<ColorVal>
	<Type>COLOR_PLAYER_LIGHT_BLACK_TEXT</Type>
	<fRed>0.392</fRed>
	<fGreen>0.392</fGreen>
	<fBlue>0.392</fBlue>
	<fAlpha>1.00</fAlpha>
</ColorVal>

That's the only place. Nothing in the logs use either of those colors.

Maybe just switch around the two values in the Color.xml so BLACK_TEXT is 126, and BLACK alone is 127?
 
In my log, that was crashing 2.30 there was lightBlack text.
Which is nearly illegible against the black background of the AlertsBox.
(I reverted back to the 2.20 I had from last year to finish that game)

So its probably a combination of savegames that used SimCuties colours... or savegames from previous version of BUG that used simCuties colours.

If thats the case deleting the old alerts-log file should stop the crashes.
 
Top Bottom