Sibling error in LeaderHeadInfos

[NotSoGood]

I am slowly getting back to modding after a little break from it. I decided I should fix few errors and crashes from my mod. But because I had bought a new computer my latest DLL with source files were kinda missing. So I rebuilt the DLL from scratch and it compiled fine. The mod starts fine but then I get this error:

There are more siblings than memory allocated for them in CvXMLLoadUtility::SetVariableListTagPair
Current XML file is: xml\Civilizations/CIV4LeaderHeadInfos.xml

I get 90 of those and I have 45 leader heads + barbarian. I tried to search from the forums if anyone had fixed this error but I couldn't find any. So if anyone could tell me what could cause this and possibly how to fix it.

EDIT: With a little testing I noticed that the contact types I had added are the cause of this error. Does this mean then that they aren't defined properly in the DLL?

 

[Asaf]

I'm guessing you have comments in this XML file?
Try removing them. In some cases the parser doesn't deal that well with them.

 

[NotSoGood]

I'll check the comments.
Also for some reason the errors appear only with debug DLL. If I use the release one there are no errors.

 

[Asaf]

This is because it's an 'assert' error - a runtime check which is only compiled when you compile the DLL in debug mode.

 

[NotSoGood]

Removing comments from LeaderHeadInfos changed nothing.

This is because it's an 'assert' error - a runtime check which is only compiled when you compile the DLL in debug mode.

Actually, if I'm not totally wrong, the sibling error has nothing to do with asserts. Here's a part of the code that throws the error:

Spoiler :

void CvXMLLoadUtility::SetVariableListTagPair(int **ppiList, const TCHAR* szRootTagName,
											  int iInfoBaseSize, int iInfoBaseLength, int iDefaultListVal)
{
	int i;
	int iIndexVal;
	int iNumSibs;
	TCHAR szTextVal[256];
	int* piList;

	if (0 > iInfoBaseLength)
	{
		char	szMessage[1024];
		sprintf( szMessage, "Allocating zero or less memory in CvXMLLoadUtility::SetVariableListTagPair \n Current XML file is: %s", GC.getCurrentXMLFile().GetCString());
		gDLL->MessageBox(szMessage, "XML Error");
	}
	InitList(ppiList, iInfoBaseLength, iDefaultListVal);
	if (gDLL->getXMLIFace()->SetToChildByTagName(m_pFXml,szRootTagName))
	{
		if (SkipToNextVal())
		{
			iNumSibs = gDLL->getXMLIFace()->GetNumChildren(m_pFXml);
			piList = *ppiList;
			if (0 < iNumSibs)
			{
				if(!(iNumSibs <= iInfoBaseLength))
				{
					char	szMessage[1024];
					[COLOR="Red"]sprintf( szMessage, "There are more siblings than memory allocated for them in CvXMLLoadUtility::SetVariableListTagPair \n Current XML file is: %s", GC.getCurrentXMLFile().GetCString());[/COLOR]	
					gDLL->MessageBox(szMessage, "XML Error");
				}
				if (gDLL->getXMLIFace()->SetToChild(m_pFXml))
				{
...

All of the "sibling errors" come from similar situations. So the error is thrown if iNumSibs > iInfoBaseLenght. The value that's been passed to iInfoBaseLenght is always the number of those things. Like GC.getNumTechInfos() or NUM_CONTACT_TYPES. As I understand this, is that for some reason the game thinks that I have more for example contact types defined in leader head infos that there is defined in the DLL.
What do you think?

EDIT: I removed all of the contact types I had added from leader head infos and the game started without any errors. I guess there must be something wrong how I defined the new contact types...

 

[Asaf]

Oops
I guess I should check before I post... Sorry.

These are the calls to this function when parsing the leader head info:

	pXML->SetVariableListTagPair(&m_pbTraits, "Traits", sizeof(GC.getTraitInfo((TraitTypes)0)), GC.getNumTraitInfos());
	pXML->SetVariableListTagPair(&m_piFlavorValue, "Flavors", GC.getFlavorTypes(), GC.getNumFlavorTypes());
	pXML->SetVariableListTagPair(&m_piContactRand, "ContactRands", GC.getContactTypes(), NUM_CONTACT_TYPES);
	pXML->SetVariableListTagPair(&m_piContactDelay, "ContactDelays", GC.getContactTypes(), NUM_CONTACT_TYPES);
	pXML->SetVariableListTagPair(&m_piMemoryDecayRand, "MemoryDecays", sizeof(GC.getMemoryInfo((MemoryTypes)0)), NUM_MEMORY_TYPES);
	pXML->SetVariableListTagPair(&m_piMemoryAttitudePercent, "MemoryAttitudePercents", sizeof(GC.getMemoryInfo((MemoryTypes)0)), NUM_MEMORY_TYPES);
	pXML->SetVariableListTagPair(&m_piNoWarAttitudeProb, "NoWarAttitudeProbs", sizeof(GC.getAttitudeInfo((AttitudeTypes)0)), NUM_ATTITUDE_TYPES);
	pXML->SetVariableListTagPair(&m_piUnitAIWeightModifier, "UnitAIWeightModifiers", sizeof(GC.getUnitAIInfo((UnitAITypes)0)), NUM_UNITAI_TYPES);
	pXML->SetVariableListTagPair(&m_piImprovementWeightModifier, "ImprovementWeightModifiers", sizeof(GC.getImprovementInfo((ImprovementTypes)0)), GC.getNumImprovementInfos());

Since you said 90 errors and 45 leader heads, I guess 2 of them are producing this error each time. both NUM_MEMORY_TYPES and NUM_CONTACT_TYPES appear twice in this list, so it's probably one of them.
You could try debugging to see exactly which.

If you want to attach your leader head infos xml file I could take a look at that, but I don't know if that alone will help.

Oh! I've just noticed your edit to the first post.

So contact types are the problem.
Note that you should have them defined in both the DLL (CvEnums.h) and XML (GlobalTypes.xml), and they should be in the same order. And also make sure you didn't give any leader head info the same contact twice in ContactRands or ContactDelays.

EDIT: I've also just noticed your second edit...

 

[NotSoGood]

I still can't notice anything wrong with my contactTypes. I have added them to CvEnums.h, CyEnumsInterface.cpp and GlobalTypes.xml. They all should be in the same order and appear only once per leader head in both ContactRand and ContactDelay. And yet the release DLL works fine but debug DLL gives the error.
I have no idea anymore what could be causing it.

 

[Asaf]

Did you change the Memory types, perhaps?

Or maybe try debugging it. See what the values of iNumSibs and iInfoBaseLength are.
And in which call to SetVariableListTagPair this happens.
You could get some clues from that.

 

[NotSoGood]

This clearly isn't my day. For some reason visual studio started to hate me. It has decided to completely ignore my breakpoints. I remember having the same problem a long time ago but can't remember how it got fixed.

 

[Asaf]

If when you run the game all the breakpoints which you've marked in VS are empty circles (instead of full circles), it could be the result of a mismatch between the running code and the actual code.

Make sure you've copied the compiled DLL to your Mods folder.
Come to think of it, this could be a reason for your problems...

That and maybe if changing the header didn't cause a compilation of the depending .cpp files (if you're using an old makefile). Try rebuilding if this is the case.

 

[NotSoGood]

If when you run the game all the breakpoints which you've marked in VS are empty circles (instead of full circles), it could be the result of a mismatch between the running code and the actual code.

Make sure you've copied the compiled DLL to your Mods folder.
Come to think of it, this could be a reason for your problems...

That and maybe if changing the header didn't cause a compilation of the depending .cpp files (if you're using an old makefile). Try rebuilding if this is the case.

I have copied the DLL many times and rebuilded it even more. Is the mismatch the only option why the breakpoint circles are white?

 

[NotSoGood]

Well because debugging doesn't help currently, I decided to come up with something else. So I used games python console to test things. First I used the release DLL and typed in:

b=gc.getContactTypes(16)
print b

and the console printed CONTACT_TRADE_JOIN_WAR which really is the number 16. Then I did it again with the debug DLL and the console printed b as 'None'. So clearly there is something wrong with the debug DLL.
But how is it even possible? I have rebuilded both yet only release DLL works. Can debug DLL be so different?
I'll have to rebuild it once again to be sure it doesn't help....

EDIT: No luck.

 

[Asaf]

This is how a breakpoint looks when you have a mismatch (hover over it to see the displayed warning):

It seems that something's wrong with your configuration.
Which version of VS do you use?

Can you attach the following:
- VS project file (.vcproj)
- makefile
- The full output from the debug full rebuild (in the VS's output window)
- The full path from which you copy the built debug DLL to the mods folder.

 

[NotSoGood]

Thank you for helping me. I really appreciate it.

I use Visual C++ 2008 Express Edition.
The stuff is attached.

 

[Asaf]

Sorry, I couldn't find what's wrong

Some far-fetched ideas I have:

Just to verify - the date on the DLL file which you copy is new every time you build it, right?

What's in your CvGameCoreDLL/include folder (does it exist at all)?

Maybe try adding some bad (non compiling) text to CvEnums.h, or CyEnumsInterface.cpp and build the debug version again, just to see if these are the actual files which are compiled...

If all else fails - attach all the source files (ignore the Debug, Release folders, but leave all the other sub folders), and I'll try building it on my machine.

 

[NotSoGood]

Just to verify - the date on the DLL file which you copy is new every time you build it, right?

What's in your CvGameCoreDLL/include folder (does it exist at all)?

Maybe try adding some bad (non compiling) text to CvEnums.h, or CyEnumsInterface.cpp and build the debug version again, just to see if these are the actual files which are compiled...

If all else fails - attach all the source files (ignore the Debug, Release folders, but leave all the other sub folders), and I'll try building it on my machine.

Yes, the date changes.
I don't have a folder called include in my CvGameCoreDLL folder. But I have the fastdep.exe in the bin folder.
When I changed the code in CvEnums.h and CyEnumsInterface.cpp I got pretty bad errors so I think they are compiled.
I attached everything in my CvGameCoreDLL folder. The bin folder, sources, project, makefile etc.
And thanks again for your kind help.

 

[Asaf]

I think I know what the problem is:

In your makefile, look for this line:

Debug_CFLAGS = /MD[B]d[/B] /Od /D_DEBUG /RTC1 /Fp"$(Debug_PCH)" $(GLOBAL_CFLAGS)

and delete the 'd' I have bolded, so you get this:

Debug_CFLAGS = /MD /Od /D_DEBUG /RTC1 /Fp"$(Debug_PCH)" $(GLOBAL_CFLAGS)

Now rebuild the debug DLL, copy it and run the game.

If it works, I'll explain (otherwise, there's no point).

 

[NotSoGood]

Works like a charm. Thank you very much.
But I'm curious, how did you know what was the problem? Did you use somekind of super-god-skill to find it?
I guess this is what you get from copying other people's makefiles.
Thank you again.

And yes, I'd like to hear the explanation why it caused what it caused.

 

[Asaf]

Works like a charm. Thank you very much.
But I'm curious, how did you know what was the problem? Did you use somekind of super-god-skill to find it?

Who told you??

The /M* flags determine which runtime library the compiled file (CvGameCoreDLL.dll) is linked to. The runtime library contains basic functions such as malloc & free.

/MD means it's compiled to another DLL - msvcr71.dll - which is loaded when the CvGameCoreDLL is loaded by the game.
/MDd means it's compiled to the debug version of this DLL - msvcr71d.dll.

(The 71 is the version of the relevant visual studio toolkit - 7.1 is VS2003).

You don't have the msvcr71d.dll library (neither do I). The non-debug version comes with the game (I'm almost sure, I'm not on my PC right now, but it usually does).

When the game tries loading the debug version which was compiled with /MDd, it tries loading msvcr71d.dll. Since it can't find this file, it silently fails loading your DLL (maybe it logs it somewhere).
And here comes the interesting part: it loads the default DLL instead.

This is why the game behaves strangely - it uses the default contact types etc.

I should've picked up on it when I compared your makefile with mine, but I missed it (probably too many other differences since I don't use the BUG makefile).

So I created a small program to load the DLL myself, and I got the 'missing DLL' error, so I kinda guessed the rest.

 

[NotSoGood]

Interesting.
Even though this fixed the error, I still couldn't set breakpoints properly.
So, I decided to take a look at your makefile you attached in your tutorial and compared it with mine. And suddenly, I noticed you had one cflag more than I did, it was the /Zi. After little bit of googling I noticed it had something to do with symbols. And after adding that I can now place breakpoints without any problems.
I also noticed you have /Oi and /Oy in the release cflags. What do they do?