Fixing broken Asserts

Where is that Python? What function is it in? It seems you should just remove it entirely.

It's in CvEventManager.

EDIT:
*Slaps forehead*. The whole reason I never found the XML files was because I removed them a while ago, as I have 5-7 (it varies) copies of RoM in my mods folder (All with Diff. names), so I can test out new things all at once. I removed the Advanced Nukes Modules from this copy, as this was a clean copy, for final testing. However, I included the ANM code in my CvEventManager to keep compatibility (otherwise, we overwrite each others.) The fun stuff we have to do to keep compatibility with modmod's. Is there a better way to store python files with Bug 4.0 so we don't keep having to do this hacky stuff? It really sucks.
 
The preferred method to add events with BUG is to put them into your own modules and use a BUG Config XML file to hook them up. The wiki docs show how to do this, and there are plenty of examples inside BUG. You should definitely not modify CvEventManager, ever. Nor should you modify BugEventManager, ever. ;)
 
. You should definitely not modify CvEventManager, ever.

Try telling that to the guys over in Mod Components. All of them are editing the CvEventManager. Anyways, I'm going to work on getting an AfforessEventManager working today.
 
Weird. All of the modcomps I merged with BUG used CvCustomEventManager. Then again, most of those came from Ruff's mod taken from HOF mod, and that used CvCEM. It's been around forever. Perhaps it's time for some good old fashioned evangelism. :mischief:
 
Weird. All of the modcomps I merged with BUG used CvCustomEventManager. Then again, most of those came from Ruff's mod taken from HOF mod, and that used CvCEM. It's been around forever. Perhaps it's time for some good old fashioned evangelism. :mischief:

War Prizes and The_J's modcomps and the Advanced Nukes Mod all modify CvEventManager.
 
Okay, so we have two Asserts fixed, many more to go. Let's try to do this in order:

Assert Failed

File: CvGlobals.cpp
Line: 4059
Expression: iExisting==-1 || iExisting==idx || strcmp(szType, "ERROR")==0
Message: xml info type entry RELIGION_HELLENISM already exists

What could cause this one? At first I thought it was another XML error, but a quick search found that this is no typo, there is a religion called Hellenism.
 
Give us some context. I have no idea what that line looks like nor the code surrounding it. That will be a big clue as to what the problem is.
 
Give us some context. I have no idea what that line looks like nor the code surrounding it. That will be a big clue as to what the problem is.

Oh, sorry, I forgot. It appears to be part of WoC. I highlighted the troubled function in red.

Code:
/*************************************************************************************************/
/** SORT_ALPHABET                           11/19/07                                MRGENIE      */
/**                                                                                              */
/** Rearranging the infos map                                                                    */
/*************************************************************************************************/
/*
void CvGlobals::setInfoTypeFromString(const char* szType, int idx)
{
	FAssertMsg(szType, "null info type string");
#ifdef _DEBUG
	InfosMap::const_iterator it = m_infosMap.find(szType);
	int iExisting = (it!=m_infosMap.end()) ? it->second : -1;
	FAssertMsg(iExisting==-1 || iExisting==idx || strcmp(szType, "ERROR")==0, CvString::format("xml info type entry %s already exists", szType).c_str());
#endif
	m_infosMap[szType] = idx;
}
*/
[COLOR="Red"]void CvGlobals::setInfoTypeFromString(const char* szType, int idx, bool hideAssert)
{
	FAssertMsg(szType, "null info type string");
#ifdef _DEBUG
	if(!hideAssert)
	{
		InfosMap::const_iterator it = m_infosMap.find(szType);
		int iExisting = (it!=m_infosMap.end()) ? it->second : -1;
		FAssertMsg(iExisting==-1 || iExisting==idx || strcmp(szType, "ERROR")==0, CvString::format("xml info type entry %s already exists", szType).c_str());
	}
#endif
	m_infosMap[szType] = idx;
}[/COLOR]

void CvGlobals::logInfoTypeMap(const char* tagMsg)
{
	CvString szDebugBuffer;
	szDebugBuffer.Format(" === Info Type Map Dump BEGIN: %s ===", tagMsg);
	gDLL->logMsg("CvGlobals_logInfoTypeMap.log", szDebugBuffer.c_str());

	int iCnt = 0;
	std::vector<std::string> vInfoMapKeys;
	for (InfosMap::const_iterator it = m_infosMap.begin(); it != m_infosMap.end(); it++)
	{
		std::string sKey = it->first;
		vInfoMapKeys.push_back(sKey);
	}

	std::sort(vInfoMapKeys.begin(), vInfoMapKeys.end());

	for (std::vector<std::string>::const_iterator it = vInfoMapKeys.begin(); it != vInfoMapKeys.end(); it++)
	{
		std::string sKey = *it;
		int iVal = m_infosMap[sKey];
		szDebugBuffer.Format(" * %i --  %s: %i", iCnt, sKey.c_str(), iVal);
		gDLL->logMsg("CvGlobals_logInfoTypeMap.log", szDebugBuffer.c_str());
		iCnt++;
	}

	szDebugBuffer.Format("Entries in total: %i", iCnt);
	gDLL->logMsg("CvGlobals_logInfoTypeMap.log", szDebugBuffer.c_str());
	szDebugBuffer.Format(" === Info Type Map Dump END: %s ===", tagMsg);
	gDLL->logMsg("CvGlobals_logInfoTypeMap.log", szDebugBuffer.c_str());
}
/*************************************************************************************************/
/** SORT_ALPHABET                           END                                                  */
/*************************************************************************************************/
 
This happens when a new object is being defined from an XML file, and it looks very much like RELIGION_HELLENISTIC is being defined again. Make sure it doesn't appear in any modules you have installed.
 
This happens when a new object is being defined from an XML file, and it looks very much like RELIGION_HELLENISTIC is being defined again. Make sure it doesn't appear in any modules you have installed.

Yeah, I had the same thought, that some module was causing an issue. I looked through my modules folder, but I don't have any that have another religionsinfo in them. The only ones that even had a religion tag were the some extra leaderheads. Could that be a problem?
 
This might help track down the problem. Change that function to this:

Code:
void CvGlobals::setInfoTypeFromString(const char* szType, int idx)
{
	FAssertMsg(szType, "null info type string");
#ifdef _DEBUG
	InfosMap::const_iterator it = m_infosMap.find(szType);
	int iExisting = (it!=m_infosMap.end()) ? it->second : -1;
	[B]CvString szError;
	szError.Format("info type %s already exists, Current XML file is: %s", szType, GC.getCurrentXMLFile().GetCString());[/B]
	FAssertMsg(iExisting==-1 || iExisting==idx || strcmp(szType, "ERROR")==0, [B]szError[/B].c_str());
#endif
	m_infosMap[szType] = idx;
}

This will display the current XML file where that duplicate key is found. I'm including this in BULL right now.
 
Thanks, I have to recompile the Debug DLL, but in 15 minutes, we'll see.

Edit:
You could have saved me some time and warned me to update the header file.
 
I got that DLL to compile. After running the new Debug DLL, it pointed me to gameinfos\religioninfos.xml. So I was curious, what happened when I commented out Hellenism. Well, I commented it out, and reloaded the game. This time a got a completely new Assert, telling me that religion Hellenism did not exist. See for yourself:

Assert Failed

File: CvGlobals.cpp
Line: 4027
Expression: strcmp(szType, "NONE")==0 || strcmp(szType, "")==0
Message: info type RELIGION_HELLENISM not found, Current XML file is: xml\Units/CIV4PromotionInfos.xml

I'm beginning to think this assert is broken. It won't seem to make up it's mind.
 
Since there is evidently only one map of the info strings, it could be defining RELIGION_HELLENISM is some other file entirely - it does not actually have to be a religion. Perhaps in one of the text files, say for a string that is supposed to be displayed for the religion, a "TXT_KEY_" prefix was accidentally left off.
 
You could have saved me some time and warned me to update the header file.

Update what header file? My last code modified an existing function, so no header file should have changed.

Those are two separate asserts. One checks if a type exists when you are asking for its ID and the other checks that a type you are defining hasn't been defined already. Very different errors.

And God-Emporer is right, all the objects are stored in a single lookup table. I haven't checked about the <TEXT> objects, and I'd hope they were stored elsewhere, but it wouldn't matter. You could have a unit with <Type> RELIGION_HELLENISTIC or any other object type.
 
Update what header file? My last code modified an existing function, so no header file should have changed.

You eliminated the "bool hideAssert" argument.

I haven't checked about the <TEXT> objects, and I'd hope they were stored elsewhere

In retrospect, I would hope this is the case as well - they aren't really info mappings.

But the idea is to search the entire XML folder structure for the RELIGION_HELLENISTIC string.
 
Back
Top Bottom