Creatures in War [CIW] [Mod in the making] [Need some support and ideas]

I've got a debug dll compiling so I can check it out thoroughly now. I've gotta step out and it probably won't take me overnight to resolve everything (even assuming I can.)

But I'll do my best for ya.

Keep in mind, merging becomes as difficult as straight programming from scratch after you've merged enough things into one dll. You will need all the same knowledge to do it from the ground up if you start running into conflicts, which in most cases during a merge process you will. The dll is not very friendly to modular modding in general, which is a big reason I work with C2C as a base - I believe it to be the best dll on the site so far. That said, I know that there are some works of others that would be nearly impossible to easily merge in that are really good here but much of what Afforess achieved for us was an excellent place to start.
 
Thank you, you will see that game work but sometimes you will get some message to debug or ignore, but i am not get CTD for now.

Yes i agree with you, C2C have fantastic game core but i don't like too much stuff in one mod. It's not easy to play some mods, if they have lots of new options and strategies. Civilization is hard to play as basic version (BTS), but it's very nice if you can play with new idea and options.

"Sword with two blades" - proverb
 
New version will come when Thunderbrd fix my .dll or send me instruction how i to fix .dll, i don't know when he will do that. Meanwhile, i will return to art working :D
 
God-Emperor said:
This particular assert is telling you that it could not load something from the XML that it really wants to load. The CvXMLLoadUtilitySet.cpp you are using is not the same as the one from plain BtS since line 1328 is not an assert in that. You may or may not be in the CvXMLLoadUtility::SetGlobalClassInfo function as that is where the only line that reads "bool bSuccess = pClassInfo->read(this);" is located in regular BtS (on line 1294). If so, then this is the main function for loading an info class - it calls the InfoX::read function which is failing from some info entry (one per failure).

Make sure your XML is not missing any required tags, and things of that nature.
Click to expand...
Ok, a little more information here.

GE stated something I was not aware of myself here and it's very valuable information but I can add to it. Again, not a coding issue in the dll but an issue in the xml somewhere. What is being loaded is the Global Art Defines. Something isn't right in the XML or perhaps schema in the global art defines - in particular UNIT art definitions. That seems to be the truest highlight for this mod so a lot of work has been done there and unfortunately I can't be certain what is exactly causing trouble here but I can say for certainty that the problem exists in:
Civ4ArtDefines/UnitArtInfos/UnitArtInfo.

See what you can figure out about that file and what might be 'off' there. I'm not terribly familiar with working with art definitions so I'll hand this one back to you.

I discovered this as I ran the debug dll as I opened the mod. I went into VS2008 and drop selected Attach to Process from the debug menu and selected the Beyond the Sword program thread. When the debug dll is running and you have the solution open in VS and attached to the BtS process you can then hit the Debug button on the assert message that pops up and it'll take you to where in the code the crash is taking place... looks like you know this.

However, then you can look at the 'Call Stack' tab and figure out from there which functions were called leading up to this crash.

In this case:
Code: 
 	CvGameCoreDLL.dll!CvXMLLoadUtility::SetGlobalClassInfo<CvArtInfoUnit>()  Line 1328 + 0x3b bytes	C++
 	CvGameCoreDLL.dll!CvXMLLoadUtility::LoadGlobalClassInfo<CvArtInfoUnit>()  Line 1462	C++
>	CvGameCoreDLL.dll!CvXMLLoadUtility::SetGlobalArtDefines()  Line 491	C++
You can double click on the function lines to go to those functions and wherever the 'green arrow' is located is generally a step past the line you moved to the next function from.

So in this case:
void CvXMLLoadUtility::SetGlobalClassInfo(std::vector<T*>& aInfos, const char* szTagName, bool bTwoPass)
{
char szLog[256];
sprintf(szLog, "SetGlobalClassInfo (%s)", szTagName);
PROFILE(szLog);
logMsg(szLog);

// if we successfully locate the tag name in the xml file
if (gDLL->getXMLIFace()->LocateNode(m_pFXml, szTagName))
{
// loop through each tag
do
{
SkipToNextVal(); // skip to the next non-comment node

T* pClassInfo = new T;

FAssert(NULL != pClassInfo);
if (NULL == pClassInfo)
{
break;
}

bool bSuccess = pClassInfo->read(this);
FAssert(bSuccess);[/code]
The last line is where we found the assert thrown. So looking back at what called this function we find:
Code: 
void CvXMLLoadUtility::LoadGlobalClassInfo(std::vector<T*>& aInfos, const char* szFileRoot, const char* szFileDirectory, const char* szXmlPath, bool bTwoPass, CvCacheObject* (CvDLLUtilityIFaceBase::*pArgFunction) (const TCHAR*))
{
	bool bLoaded = false;
	bool bWriteCache = true;
	CvCacheObject* pCache = NULL;
	GC.addToInfosVectors(&aInfos);

	if (NULL != pArgFunction)
	{
		pCache = (gDLL->*pArgFunction)(CvString::format("%s.dat", szFileRoot));	// cache file name

		if (gDLL->cacheRead(pCache, CvString::format("xml\\\\%s\\\\%s.xml", szFileDirectory, szFileRoot)))
		{
			logMsg("Read %s from cache", szFileDirectory);
			bLoaded = true;
			bWriteCache = false;
		}
	}

	if (!bLoaded)
	{
		bLoaded = LoadCivXml(m_pFXml, CvString::format("xml\\%s/%s.xml", szFileDirectory, szFileRoot));

		if (!bLoaded)
		{
			char szMessage[1024];
			sprintf(szMessage, "LoadXML call failed for %s.", CvString::format("%s/%s.xml", szFileDirectory, szFileRoot).GetCString());
			gDLL->MessageBox(szMessage, "XML Load Error");
		}
		else
		{
			SetGlobalClassInfo(aInfos, szXmlPath, bTwoPass);

			if (gDLL->isModularXMLLoading())
The last line is where the green arrow is pointing so it would've been the SetGlobalClassInfo(aInfos, szXmlPath, bTwoPass); line before it that was where we had advanced from this function to the one we found the assert in. I'm not sure if the value I get when I hover over the aInfos makes any difference (it's pointing to the 226th item in that vector or array.) Sometimes this enumeration can help you pin down which game object has the problem but I think that array may indicate something that isn't all that helpful here... not sure though. If it IS the # of the game object we're having trouble with then it's actually the 227th item because 0 is counted as the first in the vector/array numeration. (Thus if this was a unit itself causing an issue it might be the 227th unit in the core file.) Again... not entirely sure without looking a lot deeper into the whole unit art loading process.

But the stack breakdown makes it very clear that we're dealing with an error in the UNIT art infos.


Now... looking through the rest of the asset files, I found the unit art file you have there though you don't have your own schema... that might help but I'm not sure it's necessary. Anyhow... all I can really say is the problem is in that file itself. Somewhere. Strategyonly might know more about art issues like these.

If I'm not mistaken, C2C's dll would probably let me know more due to new messages built in to help with issues like these. But there's so many other dependencies there such as added xml expectations that I'm thinking it'd be impossible to get it's assistance on this mod.

However, there IS a pretty good xml validator program that Alberts built that could possibly be pretty useful here. I suppose I could go and copy over the core BtS schema into this Art file and run the validator to see what I can figure out from that... hmm...

Anyhow... looking further into it.
Click to expand...
 
Hmm... the validator seems to show everything's fine but it could still be wrong... I'd take the time to take out the file and start over adding in one unit art entry at a time and see if you can find the one that has an issue.
 
Ok, then you have another issue in the loading process that is very similar and is affecting CIV4PromotionInfos.xml.

And then you get this assert thereafter:
Code: 
Assert Failed

File:  CvGlobals.cpp
Line:  3624
Expression:  strcmp(szType, "NONE")==0 || strcmp(szType, "")==0
Message:  info type PROMOTION_BARRAGE not found, Current XML file is: xml\Units/CIV4PromotionInfos.xml
Which means that a game object entry in CvGlobals is calling for PROMOTION_BARRAGE and not finding it among promotion assets. This probably means, coupled with the previous assertion, that the whole promotion mod file is simply failing to load due to an xml error there. So this one probably gets fixed when the PromotionInfos.xml file gets repaired.

~

Then it goes into the mod.

So what it looks like is that there is no problem with the dll or code sets (we may find some further issues when we start the game but we should seek to clear up the issues we know of before trying to load a game because we already know we're likely to have some serious trouble missing a few asset files of major importance that failed to load.)



Here's where I'm a little weak with this. C2C has some further indicators in it's assertion messages on load processes that I've come to rely on as a crutch and these original load process assertions fail to give the in-depth info I'd normally use to find and fix problems like these. Additionally, we can also rely on an SVN that tracks every change we make to help identify the source of problems that we get vague identifications on. And as a team we can often ask others to help solve problems in areas we aren't ourselves masters of. In this case, the example is Art - not my specialty zone.

Promotions ARE however so I may be able to take a look into that and figure out what is going wrong there...
 
Ok, figured it out.

You have no issues in the code.

In the XML of the unit art and promotions files you need to remove the comment lines. XML and comment lines between object entries do not often get along. By removing all comment lines after the xml really begins (the ones at the top are not problematic) I was able to resolve the first two assert issues.

Then the assert:
Code: 
Assert Failed

File:  CvGlobals.cpp
Line:  3624
Expression:  strcmp(szType, "NONE")==0 || strcmp(szType, "")==0
Message:  info type PROMOTION_BARRAGE not found, Current XML file is: xml\Units/CIV4PromotionInfos.xml
I found was pointing to a reference to a prerequisite promotion of PROMOTION_BARRAGE. You don't have a promotion of this type - it's actually named PROMOTION_BARRAGE1. Just search for PROMOTION_BARRAGE and add a 1 to that incorrect reference and you'll be fine.

Otherwise, seems like all is good. At least without starting a game. I may try that tomorrow.
 
Thunderbrd, i can tell you BIG THANK YOU only for text, others cannot be described in words.

I read all. And i am remove all comments in all XML files instead schemes and BBAI_AI_Variables_GlobalDefines.xml, BBAI_Game_Options_GlobalDefines.xml, LeadFromBehind_GlobalDefines.xml, TechDiffusion_GlobalDefines.xml.

And when mod loading i only get one error:
Code: 
Assert Failed

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

----------------------------------------------------------

Before this i am gets 2 debug messages. During the game I did not test, after removing comments.

I must remove comments when my .dll type is DEBUG? I really don't know this. I am look in art files, remove excess and art units is now as in BTS. I will check all again tomorrow.
 
Reality is, this is all you really needed to read:
Thunderbrd said:
Ok, figured it out.

You have no issues in the code.

In the XML of the unit art and promotions files you need to remove the comment lines. XML and comment lines between object entries do not often get along. By removing all comment lines after the xml really begins (the ones at the top are not problematic) I was able to resolve the first two assert issues.

(This part above will fix the first two asserts you're getting.)

Then the assert:
Code: 
Assert Failed

File:  CvGlobals.cpp
Line:  3624
Expression:  strcmp(szType, "NONE")==0 || strcmp(szType, "")==0
Message:  info type PROMOTION_BARRAGE not found, Current XML file is: xml\Units/CIV4PromotionInfos.xml
I found was pointing to a reference to a prerequisite promotion of PROMOTION_BARRAGE. You don't have a promotion of this type - it's actually named PROMOTION_BARRAGE1. Just search for PROMOTION_BARRAGE and add a 1 to that incorrect reference and you'll be fine.
(This part will fix the assert you're getting that you just quoted me in the above post!)

Otherwise, seems like all is good. At least without starting a game. I may try that tomorrow.
Click to expand...

The debug dll is telling you where you have problems. In theory, you still have those problems when you're running the normal dll... you just aren't being told you have them. That can create crashes and certainly upsets your modding intentions when assets aren't included in the game that were supposed to be. ;)
 
Thank you Thunder i am fixed barrage and i am not more got errors in loading, but during game i am got this messages:
Code: 
1)Assert Failed

File:  CvUnitAI.cpp
Line:  14045
Expression:  iParatrooperCount > 0
Message:  

----------------------------------------------------------


2)Assert Failed

File:  CvUnit.cpp
Line:  11550
Expression:  getOneUpCount() >= 0
Message:  

----------------------------------------------------------

3)Assert Failed

File:  CvUnit.cpp
Line:  11669
Expression:  getStackEffectCount() >= 0
Message:  

----------------------------------------------------------

I will give you credit for help/support.
 
Yeah, I figured you might see some asserts in play. I'll have to go into a game to take a look. Do you have any savegames that are more advanced or will I need to play through?
 
That first assert:
Code: 
Assert Failed

File:  CvUnitAI.cpp
Line:  14045
Expression:  iParatrooperCount > 0
Message:
I'm really very uncertain what it's trying to accomplish. I've worked with this before and as I recall it was an issue in the original code that you merged. I would ask Koshling what you should be doing with this - I can no longer recall.

Problem is, with all 3 of those asserts I'm really unsure if there's a problem at all and if there is, how to resolve it. I can figure out how to resolve a crash scenario if there is one (and btw... what is up with your forests producing SOOOOO much food and such????) but with these, we're working with the intentions of the original designers and I'm finding it tough to follow their thinking on these matters. I'll keep looking but I'm thinking I may not be all that much help here unfortunately.
 
Ok, that said, I DID figure out what the problem was with that second assert, getOneUpCount.

Apparently, the promotion that provides the added one up value can be removed when the unit upgrades due to an invalidating factor. When this takes place, if the One Up has been used up for that unit, the removal of the promotion will leave the unit in a state where there is less than one 'life' remaining for the unit. It probably would be better to change this so that when the unit dies and is regenerated, the promotion is removed. However, the scenario this presents with a potential for numerous promotions having the ability does present some complexities there - they could be sorted out so that one promotion with the ability is removed whenever the unit is regenerated BUT if there are promotions that have MORE than just that ability, you'd really have to tax the processing to figure out which of the multiple promotions should be removed first. So perhaps it is easier to work it this way.

But to do this properly, so that the promotion can be removed safely from a unit that has already lost the extra life before (and so that it can retake the promotion later without it merely compensating for the negative 'oneup' value) I'd just rewrite this to the following:
Code: 
void CvUnit::changeOneUpCount(int iChange)
{
	if(m_iOneUpCount += iChange >= 0)
	{
		m_iOneUpCount += iChange;
	}
}

You will be leaving the function to do nothing if the OneUpCount is already at 0. That should be a better way to go about it.

Mind you, I don't think this is a problem with your merging skills... probably an issue with the original. We had some stuff that needed sorted out after I merged in that stuff to C2C but Koshling sorted out those after-details once I'd put the merge in. He may be able to offer some further insights as to how we resolved these issues.
 
I'm quite certain the stack effect issue is very similar. I'd suggest changing the assert (a warning that things aren't working quite as expected) to an enforcement that things would work as expected. The math processing is almost identical and the problems presented almost identical so you should be able to easily use the above recoded function as a template to rework this one too. Let me know if you need me to write it out for you explicitly again though.
 
Actually... on second thought - this solution has its own set of issues.

If you have 2 promos that add a one up and one gets used and another is lost, you're left with 0 one ups. This MAY be considered appropriate though... the only alternative I can think of though would be to remove one of the promos rather than reducing the count directly when a one up is used. And that's going to take some consideration of how to priortize which promo to remove if that takes place and the unit has multiple promos with a OneUp feature.

If you aren't happy with the consequences of this initial 'simple' method of resolving the issue, we'd have to consider how to establish which promo gets removed instead.
 
That's bad, in this moment i really don't know what to do with SDK, merge all again, or merge some other components. Thank you for help.
 
For now, just implement this into your code, replacing the current changeOneUpCount:
Code: 
void CvUnit::changeOneUpCount(int iChange)
{
	if(m_iOneUpCount += iChange >= 0)
	{
		m_iOneUpCount += iChange;
	}
}

And the current changeStackEffectCount with
Code: 
void CvUnit::changeStackEffectCount(int iChange)
{
	if(m_iStackEffectCount += iChange >= 0)
	{
		m_iStackEffectCount += iChange;
	}
}
 
You must log in or register to reply here.
Top Bottom