I thought I had fixed this error. I haven't. See PH13 (page 2 and 3) (http://forums.civfanatics.com/showthread.php?t=271476) for an example. I'm going to try to reproduce this error in a very simple game so that we can find what part of BUG is causing it. I think it has something to do with the color schemes of items that we log.

Pic of the log when I have Civ4-logging running ...

http://img219.imageshack.us/img219/4918/ph130051mr2.jpg

The first set was played with BUG, the second with vanilla BtS.

There's only one picture, so are you saying that just the black log entries (the ones that are very hard to read) were created while using BUG? If so, did they appear black while playing with BUG, or did they change only once you removed BUG?

I can see how the color schemes could cause a problem. Each log entry must specify the colors to be used. If a color from the new set is used, then when BUG is removed the log will not be able to find that color. However, I didn't think any of the colors used in the log messages (e.g. Civ4lerts) were from the new set. They all worked before I added the extra colors.:confused:

The black entries are from the first set of the SG (using BUG). The other 3 entries are from the second set (not using BUG).

Given that, I could see how the extra colors cause the problem, but above you said that this isn't the problem after all, right? Or is the BUG used in the picture the new version without the colors?

Are you sure you didn't include any codes from SimCutie? I think we just pulled the .xml file with the color codes out completely. If we had it point somewhere that was no longer there, wouldn't it go black like that?

maybe ... I will check. I also tried looking for the code that creates the log ...

tracking down what creates the log:

1) search for 'Event Log' in the xml file - found 'CIV4GameTextInfos.xml', key = TXT_KEY_EVENT_LOG
2) search for TXT_KEY_EVENT_LOG in python files - found nothing ... #$%@$ its in the DLL

I looked at all the Civ4lert messages in the XML, and they all use built-in Civ4 colors like COLOR_YIELD_FOOD and COLOR_TECH_TEXT.

I don't remember SimCutie's mod requiring any code. It just defines in XML a bunch of new colors that you can reference from XML text or from code, but I never did that, and I don't know if the game itself will try to use them for player colors or whatnot.

Since Ruff removed the XML file, that should be the end of it. :crazyeye:

PH13's first two saves generate an in-game log crash when using the latest version of BUG (as of today). I've just run a couple of tests:

Test #1: A game where I played 10 turns on quick with vanilla BtS and then 10 turns with BUG, swapping back to vanilla --> result, no in-game log crash.
Test #2: A game where I played 10 turns on quick with BUG and then 10 turns with vanilla BtS opening the log in various spots --> result, no in-game log crash.


Well, the bug didn't crop up for me. I'm going to repeat the test with BUG v2.2 and v2.3 and see what I get. If anyone wants to join in on the great bug hunt, feel free. If you find a game that crashes, please describe exactly what you did and post various saves from that game (starting save, intermediate save, crashing save, etc).

did you remember to turn off error logging? It seems that removes the crash.

yes - ran it with no python error logging. No crash. Going to check that I had all of BUG turned on (ie alerts).

I noticed this over in the Ethnic Artstyles thread:
Thanks again for reporting.

Btw, how did you find these? XML error check or something?
I used a BTS 3.13 debug DLL with Asserts on, compiled for me by mrgenie (the Vi from ViSa), the lead programmer of the WoC project.
I wonder if that would be useful for tracking down issues with BUG?

thx - have posted a question over there.

Doh, it seems Melior has played with BUG. :cry:Damn, I'm sorry about that. I did a fresh install of BtS a while back, but I guess maybe that didn't completely wipe out BUG.Hi Guys - can you tell me what version of BUG you played with (check the BUG option screen, its on the bottom right)On another note; I just downloaded and installed BUG, but I still crash from opening the event log? :hmm:From my point of view, this is great news. Melior's version of BUG introduced the in-game log bug that vanilla BtS crashes on. Rusten's version of BUG (v2.3 I'm assuming from looking at the screenie) also has the in-game log crash. This means that v2.3 of BUG has a similar reaction to vanilla BtS to this BUG, thus implying that v2.3 of BUG doesn't contain the code to over-ride or introduce (this last bit might be a bit of a stretch) the bug.

Melior - what version of BUG did you use? Do you know? Was it d/l from an install exe or zip or did you pull it from the SVN? If we can get your version, then I can look at what the differences are between it and v2.3 and see how we 'fixed' it.

I'm grabbing a copy of 'Ungy-02 AD-0375.CivBeyondSwordSave' for bug testing purposes.

I've looked at the above save and found the following:
revision 606 - no crash revision 613 - no crash revision 614 - crash revision 615 - crash revision 616 - crash revision 619 - crash revision 625 - crash revision 650 - crash revision 675 - crash revision 700 - crash revision 725 - crash revision 755 - crash

So I look at what is different between revision 613 and 614 and find that the only different file is 'CvTechChooser.py'. The difference in this file ...

Revision 613 Line 125: xPanelWidth = screen.getXResolution()
Revision 614 Line 125: xPanelWidth = screen.getXResolution() - 60

So, that stupidly small change means that 613 doesn't crash when you open the in-game log while 614 does.

Suggestions anyone?

This means that v2.3 of BUG has a similar reaction to vanilla BtS to this BUG, thus implying that v2.3 of BUG doesn't contain the code to over-ride or introduce (this last bit might be a bit of a stretch) the bug.

Aha! You may be correct as I removed our non-3.13-updated copy of CIV4GameText_BTS.xml. This is great news.

Oops, missed your other post. I thought BUG has been crashing like this for a long while, long before 613. But you're saying that somewhere along the way it got fixed, and 614 now broke it again??

And I serious doubt that change could be related. They are totally different screens, and plenty of screens choose full and partial resolution. Color me perplexed.

I don't know the version that created this file - I'm thinking that it is a pre-613 file (user claims v2.3 but what do users know). So, bug created with pre-613 version and post 614 version keels over - al la vanilla BtS. Which sort of implies that it is fixed?

Someone is getting me a debug version of the DLL that shows errors. Will retry when I get that.

When you are attempting to bring up the log, is there one?
Or is it a save-game w/ no log data, and BUG is trying to load a file that doesn't exist.

Or is there a version of BUG where the LOG data has changed format? The save is in previous format, and BUG trying to load that.

I get CTD when trying to load my old savegame when attempting to pull up the log under 2.30, works fine when I copy over BUG 2.20 - that the game was originally saved with.
(I Did add in the updated files from the svn into 2.30, didn't try a "clean" 2.30)

A DLL with asserts on gives you feedback (popup screens) when the DLL encounters things it can't handle very well.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 ...

http://img254.imageshack.us/img254/6346/ingamelogbugsz1.jpg

snippet from that cpp file ...

CvColorInfo& CvGlobals::getColorInfo(ColorTypes e)
{
FAssert(e > -1);
FAssert(e < GC.getNumColorInfos());
return *(m_paColorInfo[e]);
}


Now to track down where that number is stored. I'm thinking that it must be in the XML system somewhere but ... looking at BUG, we only share 2 XML files with the core game ...

1) CIV4Hints.xml - we put in some additional hints and this file only contains 'pointers' to our hints
2) CIV4ArtDefines_Interface.xml - contains path directions for our BUG art work (PLE, Unit Action, Chevrons, Servopedia)

We also share the GameFont_75.tga font file with the core game - is that a problem? Everything else is python.

Any suggestions?

The GameFont_75.tga file that we are using is the same one that's been around for a while, without problems in other mods. It has to either be the Hints file, or the Interface file. I'd drop the Hints file and rerun it first. Is the easiest and will have little chance of breaking other functions of it's removed. We may want to go through both files and delete all color tags, or change them to basic values, to make sure we removed traces of SimCutie's colors.

I really don't think it is either. Somewhere the system has the number of total colours and BUG has managed to increase or decrease that number.

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.

well, let's start with pulling the Hints and see what we get.

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.

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.

Can you [Debug] and see what called getColorInfo

The only place I see it, is in ColorUtil.py

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
int CvGlobals::getNumColorInfos()
{
return (int)m_paColorInfo.size();
}


CvColorInfo& CvGlobals::getColorInfo(ColorTypes e)
{
FAssert(e > -1);
FAssert(e < GC.getNumColorInfos());
return *(m_paColorInfo[e]);
}
CvGlobals.h
DllExport int getNumColorInfos();
std::vector<CvColorInfo*>& getColorInfo();
DllExport CvColorInfo& getColorInfo(ColorTypes e);


CyGlobalContext.cpp
CvColorInfo* CyGlobalContext::getColorInfo(int i) const
{
return (i>=0 && i<GC.getNumColorInfos()) ? &GC.getColorInfo((ColorTypes)i) : NULL;
}


CvInfos.cpp

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;
}


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

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 ...


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 ...


- <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:

<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,

<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

<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.

And no log messages use light black text AFAIK for that reason. This is truly truly bizarre. :confused:

I was playing Fox-30 the other day and my version of BUG actually crashed. Someone had used v2.3 previously an now v2.3+ (pls don't ask me what the differences are) crashes. Weird.

Let me see if I have this right.


Someone else was using the "release" 2.30 version.
You are using the latest SVN "2.30+" version.
You opened the log in your game, and it crashed.

This makes me think that we solved the problem (however that happened) in the latest SVN version, and as people start upgrading to SVN or the next release (2.40), this problem should disappear.

Or this problem will continue to appear and disappear with each release, causing much gray hair and frazzled nerves, perhaps the end of life as we know it. :goodjob: