Single Player bugs and crashes - After the 24th of February 2014

[Thunderbrd]

1st CTD in a long time, but i haven't even gone 25 turns???

Traceback (most recent call last):

File "CvScreensInterface", line 1371, in forceScreenRedraw

File "CvMainInterface", line 1535, in redraw

File "CvMainInterface", line 6349, in updateHelpStrings

RuntimeError: unidentifiable C++ exception
ERR: Python function forceScreenRedraw failed, module CvScreensInterface

EDIT: Just looked and this is a REPEATABLE CTD

It's a divide by 0 error. Not sure how this happens but it's after your workers finish a path I believe. There ARE some strange references taking place in the valuation of the path itself - doing some more to try to narrow in on how that might be happening.

Is there anything wrong with the path art? A failure in 'forceScreenRedraw' is somewhat suggesting of an art issue perhaps. From what I can see it seems to be asking for this because the path is finishing up. This is not 100% provable but simply suggested since a call for 'bestroute' evaluation was made just before the crash. In some ways you've seen more in the python report than I can from the dll.

 

[Thunderbrd]

to clarify - they dont need to be reported?

No - they're suggesting possible problems and can be very helpful to figure out how a crash takes place but we can see them when we run the debugger as well and I assure you they are given consideration when seen. From the forum though it's hard to tell what it's pointing at even though some of those I haven't seen. When attached to VS the asserts can take you right to the code spot where it's calling the assert and you can do further investigation and that's all that really makes it useful.

Anyone know what this is all about?? Brand new game.

It looks like you're playing on mastery setting or domination victory setting and you don't have any other AI players setup in the game?

 

[BlueGenie]

Anyone know what this is all about?? Brand new game.

No one else has placed a city yet, or one other only, and the Domination Victory conditions are being met.
You are playing with none or only one opponent.

Edit: TB beat me too it.

Cheers

 

[Thunderbrd]

You added to it though some thoughts I had afterwards and didn't bother to edit in


@Alberts: SO's save is frickin' weird!!!!

Apparently, in
RouteTypes CvSelectionGroup::getBestBuildRoute(CvPlot* pPlot, BuildTypes* peBestBuild) const
I'm showing that the for (iI = 0; iI < GC.getNumBuildInfos(); iI++) is looping out to an ID of 295. 295 is generating wildly random numbers in its values as if it were somehow an overflow (or drawing from an undefined source.)

So I deleted the cache and checked the load sequence and lo and behold there IS no Build ID 295!!! So HOW does it loop up to an ID of 295??

I tried to find where the Build ID vector is being loaded but I couldn't find the .pushback for that vector (I think I may be way off base as to how the class is constructed from the xml somehow.)

This is obviously problematic and potentially an indicator of a much much much much bigger problem somewhere. It took me a while but I think I've invented an appropriate patch for THIS situation - and I'm hoping I don't need to apply it all over the place in so many other situations. The patch will have the downside of introducing slightly reduced efficiency.

Is this some kind of bad xml? I didn't see any indication of an xml problem anywhere in the load sequence for Builds so I'm stumped.

 

[olduser]

You added to it though some thoughts I had afterwards and didn't bother to edit in


@Alberts: SO's save is frickin' weird!!!!

Apparently, in
RouteTypes CvSelectionGroup::getBestBuildRoute(CvPlot* pPlot, BuildTypes* peBestBuild) const
I'm showing that the for (iI = 0; iI < GC.getNumBuildInfos(); iI++) is looping out to an ID of 295. 295 is generating wildly random numbers in its values as if it were somehow an overflow (or drawing from an undefined source.)

So I deleted the cache and checked the load sequence and lo and behold there IS no Build ID 295!!! So HOW does it loop up to an ID of 295??

I tried to find where the Build ID vector is being loaded but I couldn't find the .pushback for that vector (I think I may be way off base as to how the class is constructed from the xml somehow.)

This is obviously problematic and potentially an indicator of a much much much much bigger problem somewhere. It took me a while but I think I've invented an appropriate patch for THIS situation - and I'm hoping I don't need to apply it all over the place in so many other situations. The patch will have the downside of introducing slightly reduced efficiency.

Is this some kind of bad xml? I didn't see any indication of an xml problem anywhere in the load sequence for Builds so I'm stumped.

Are you using the Debug dll or Release?
The Release dll can display all kinds of wrong data.

SO's save points here in CvUnit::build

		// Super Forts end
		//ls612: Workers now get XP on finishing a build
		int iCost = GC.getBuildInfo(eBuild).getTime();
		int iSpeedModifier = workRate(true);
		if (iCost > 0 && !GC.getBuildInfo(eBuild).isKill())
		{
			[COLOR="Red"]changeExperience100(iCost / ((2 * iSpeedModifier) / 100), -1, false, false, false);[/COLOR]		}

After this change the CTD goes away but the Worker get's 1.74XP is that too much?

		// Super Forts end
		//ls612: Workers now get XP on finishing a build
		int iCost = GC.getBuildInfo(eBuild).getTime();
		int iSpeedModifier = workRate(true);
		if (iCost > 0 && !GC.getBuildInfo(eBuild).isKill())
		{
			changeExperience100(iCost / [COLOR="Red"]std::max(1, (2 * iSpeedModifier) / 100)[/COLOR], -1, false, false, false);
		}

 

[Thunderbrd]

Are you using the Debug dll or Release?
The Release dll can display all kinds of wrong data.

SO's save points here in CvUnit::build

		// Super Forts end
		//ls612: Workers now get XP on finishing a build
		int iCost = GC.getBuildInfo(eBuild).getTime();
		int iSpeedModifier = workRate(true);
		if (iCost > 0 && !GC.getBuildInfo(eBuild).isKill())
		{
			[COLOR="Red"]changeExperience100(iCost / ((2 * iSpeedModifier) / 100), -1, false, false, false);[/COLOR]		}

After this change the CTD goes away but the Worker get's 1.74XP is that too much?

		// Super Forts end
		//ls612: Workers now get XP on finishing a build
		int iCost = GC.getBuildInfo(eBuild).getTime();
		int iSpeedModifier = workRate(true);
		if (iCost > 0 && !GC.getBuildInfo(eBuild).isKill())
		{
			changeExperience100(iCost / [COLOR="Red"]std::max(1, (2 * iSpeedModifier) / 100)[/COLOR], -1, false, false, false);
		}

Ok, now I'm really weirded out on this one! I AM using the debug dll... on my call stack breakdown it doesn't even suggest the spot you found. That sounds like a spot that sure could be dividing by 0 though.

The xp does sound like a lot but I don't see another way to address it.

So... what could be wrong with my setup here that my debug dll wouldn't point that out properly? Maybe I need an update. I'm a few revisions behind the latest.

EDIT: Note my 'patch' didn't work because apparently I'm being misled by crazy value references that aren't actually taking place - they show this way after the crash hits which kinda makes sense because the divide by 0 throws the mem for a loop. Apparently all I was really seeing was a code mirage. Still don't know why my debugger was telling me the crash was happening in a spot it couldn't show me though.

 

[olduser]

Ok, now I'm really weirded out on this one! I AM using the debug dll... on my call stack breakdown it doesn't even suggest the spot you found. That sounds like a spot that sure could be dividing by 0 though.

The xp does sound like a lot but I don't see another way to address it.

So... what could be wrong with my setup here that my debug dll wouldn't point that out properly? Maybe I need an update. I'm a few revisions behind the latest.

Asset changes could also explain this problem.

Edit:
Was the correct Pdb for your dll loaded while debugging?

 

[Thunderbrd]

Ah... makes sense then.

I also figured out why the units are getting more than usual xp - it's due to their SM category changes... It's an interesting exploit one way or another based on combat quality being so low for workers. I'll have to consider that further but I just wanted to assure that the xp gain sounds right after your adjustment.

 

[Thunderbrd]

Ack... my internet is killing me here!

 

[Thunderbrd]

Asset changes could also explain this problem.

Edit:
Was the correct Pdb for your dll loaded while debugging?

I wasn't trying to debug from the mini because I knew my code set is probably a touch different from what he was running on due to minor changes on my end since then. So it was just a savegame runthrough and I've never seen those go offbase like this.

 

[olduser]

I wasn't trying to debug from the mini because I knew my code set is probably a touch different from what he was running on due to minor changes on my end since then. So it was just a savegame runthrough and I've never seen those go offbase like this.

You can set the Exceptions causing the Debugger to Break maybe the Integer Divide by Zero Exception is not set. It is listed under Win32 Exceptions.

How to: Break When an Exception is Thrown

 

[Thunderbrd]

I got the popup asking me if I wanted to break (due to a divide by 0 error), only it then went on to show a call stack that indicated the break was taking place in an ntfs process I couldn't view. The last dll function it showed me was the bestpath eval function.

 

[Ingenieria]

With a text editor (like notepad) open the files /C2C/Assets/Modules/Custom _Civilizations/Comanche/Comanche_Civ4UnitArtStyleTypeInfos.xml and /Custom_Civilizations/Navajo/Navajo_Civ4UnitArtStyleTypeInfos.xml
Change the line <MiddleArtDefineTag>ART_DEF_UNIT_NATIVE_WARLORD_MEDIEVAL</MiddleArtDefineTag> to <MiddleArtDefineTag>ART_DEF_UNIT_WARLORD_ANCIENT_SIOUX</MiddleArtDefineTag> in each file. That should do the trick.


Edit: I have no idea where the extra spaces in MEDIEVAL and SIOUX come from. Disreard them and write then as one word.

I just downloaded v34. When I try to load my game from v33, I get the error that the above was supposed to address (ArtInfo: 'art_def_unit_native_warlord_medieval' was not found). I made the the changes indicated above but still get the same error. Is there a known solution to this problem? Is this the right place to look for it?

Thank you, all, for the help. I love C2C; I appreciate all the work that goes into it.

 

[strategyonly]

I just downloaded v34. When I try to load my game from v33, I get the error that the above was supposed to address (ArtInfo: 'art_def_unit_native_warlord_medieval' was not found). I made the the changes indicated above but still get the same error. Is there a known solution to this problem? Is this the right place to look for it?

Thank you, all, for the help. I love C2C; I appreciate all the work that goes into it.

See this post:

http://forums.civfanatics.com/showpost.php?p=13180445&postcount=869

 

[masaykh]

Traceback (most recent call last):

File "CvRandomEventInterface", line 8264, in doVolcanoDormantEruption

File "CvRandomEventInterface", line 8196, in doVolcanoPlot

NameError: global name 'iX' is not defined
ERR: Python function doVolcanoDormantEruption failed, module CvRandomEventInterface

 

[olduser]

Traceback (most recent call last):

File "CvRandomEventInterface", line 8264, in doVolcanoDormantEruption

File "CvRandomEventInterface", line 8196, in doVolcanoPlot

NameError: global name 'iX' is not defined
ERR: Python function doVolcanoDormantEruption failed, module CvRandomEventInterface

I also had this error but it should be fixed now in the svn.

 

[Dancing Hoskuld]

I just downloaded v34. When I try to load my game from v33, I get the error that the above was supposed to address (ArtInfo: 'art_def_unit_native_warlord_medieval' was not found). I made the the changes indicated above but still get the same error. Is there a known solution to this problem? Is this the right place to look for it?

Thank you, all, for the help. I love C2C; I appreciate all the work that goes into it.

You didn't put the space in "_S IOUX" did you? ie you used "_SIOUX"

Traceback (most recent call last):

File "CvRandomEventInterface", line 8264, in doVolcanoDormantEruption

File "CvRandomEventInterface", line 8196, in doVolcanoPlot

NameError: global name 'iX' is not defined
ERR: Python function doVolcanoDormantEruption failed, module CvRandomEventInterface

Excellent, I have been waiting for someone to post that. I have not been getting that event in my games.

edit it only happens when there are units on the plot where the volcano erupts.

 

[strategyonly]

CTD

was just changing units again and poof CTD

 

[Yudishtira]

i. The Moai improvement is in BuildInfo as TXT_KEY_BUILD_MOAI_STATUES I think it is in the gametext xml as TXT_KEY_BUILD_MOAI

ii. Camel Workers can't build Desert Camps

 

[Yudishtira]

Great work on the Transport promos, but the Carrack needs to have the ability to Transport Troops back. Mine can only get Transport People, making it the only UU to be the poor relation of its generic counterpart (ie. the caravel has one "people" space to start off with).