Single Player bugs and crashes - After the 23rd of September 2013

[strategyonly]

That CTD an old one and neither Thunderbrd or myself where able to fix or fully understand it.
With what revision did you start that Game?

No idea??

Also i just declared war on Australia, and my assassin(s) all three, were in different towns, but as soon as i did declare, they were ejected from their spots and put into my territory, thats just not right????
Jivaro

 

[strategyonly]

New problem (i believe) dont know for sure what is going on?? Anyways:

Before SVN 7006 there was a "hesitation" ALOT, you could bear it when the music was playing, like skipping noises, it has been that way for a little while before even, but then after 7006, it was gone (it might have been 7007?) Music was playing fine, no hesitation in gameplay, everything was fine, then after SVN 7022, it was back again

So i again went to the latest SVN 7027 and it is gone again

Which only bring me to conclude and no offense to anyone, that when submitting the SDK/dll stuff, not all the modders are using the same stuff?? Might be a file out of place or something. i am just guessing here, so please take this with a grain of salt, thx. . . SO

EDIT: I guess i write too early, the hesitation is back also now??


EDIT: Hydro

Just found this in the tech tree, looks like a missing btn:

Trench MG pic 1

Lets Play area needs to be updated. pic 2

Also what is the deal with the siege rams?

Cant bombard walls?? pic 3/4???

 

[Thunderbrd]

Siege Rams no longer bombard. They destroy city defense values when they attack the city. They may only attack cities. They won't have any chance to damage the defender until they've broken down all possible defense they can. Once they have, they can damage the defender up to 50% before they will then automatically withdraw. They are often lemmings but can be very effective at destroying the city defenses quickly, particularly if they gain high Breakdown Chances (the chance it will harm the city defenses each round of battle) and Breakdown Damage (the amount they'll reduce the city defenses - modified by the city's collateral resistance - each round they make a successful breakdown check against their chances.)

The odd part about the assassins is that they are being ported back to your cities, not that they are being ejected from the cities they are in (presuming they were all in cities of the player you went to war with.) Your troops cannot 'hide' in cities of enemies you're at war with and any unit inside a civ's borders whom you declare war on will be moved outside the nation when you declare war. Assassins can actually attack cities when you're at war with a nation. I'm not sure where it decides to transport your hidden units back to your cities and not just to the edge of the border but it may be for the best for those units as it makes sure those units are safe when it transports them out. Otherwise they could accidentally end up somewhere where troops may see and attack them before you can do anything about it.

 

[Dancing Hoskuld]

Your Hidden nationality units did not used to be expelled from a nation when you went to war with them. Or am I thinking of spies?

 

[Thunderbrd]

They probably wouldn't be if they weren't in cities where it is completely incompatible for them to be there since they then overlap an attackable enemy suddenly.

 

[Hydromancerx]

EDIT: Hydro

Just found this in the tech tree, looks like a missing btn:

Trench MG pic 1

Lets Play area needs to be updated. pic 2

Also what is the deal with the siege rams?

Cant bombard walls?? pic 3/4???

1. The Trench Machine Gun is under ls612's mods. So I don't know why the button is pink. Its been in the mod for a long time now. The dds button/icons seems to still be located in his mod folder.

2. Those guys still have videos up, just not recent videos.

3. Ask TB about that. He has been messing around with the Rams.

 

[strategyonly]

Those guys still have videos up, just not recent videos.

I know that, i mean, aren't there others now also??

Also what is the deal with Iron Wares, i am getting sick and tired of having Iron and cant build my Swordsman and higher units when i need them to fight right away???

 

[Hydromancerx]

I know that, i mean, aren't there others now also??

Also what is the deal with Iron Wares, i am getting sick and tired of having Iron and cant build my Swordsman and higher units when i need them to fight right away???

I dont know where that whole idea came from and who talked about all this before it was changed, but i absolutely HATE it.

1. Yeah, there were more when I made that, I just did not want to make a huge list of every single one. I just put some of the most popular at the time. However I did make a point to list them under the Great Artists random names.

2. That's how all wares work. You need Ore -> Ingot -> Wares to make any of them. Its the whole processing system for crafting goods.

3. If you have Iron Wares you should be able to build a Light Swordsman. Also Copper Wares and Bronze Wares should work too. Note that Iron Ore and Iron Ingots will not work. You still need to convert those into Wares.

 

[Koshling]

That CTD an old one and neither Thunderbrd or myself where able to fix or fully understand it.
With what revision did you start that Game?

What do you know about it - anything I might be able to provide a pointer about?

 

[alberts8]

What do you know about it - anything I might be able to provide a pointer about?

These two posts explain the situation.
I think the error shown in the diassembly a wrong call to CvUnitInfo::isNoRevealMap instead of CvUnit::isDelayedDeath came from not performing a full Rebuld then building the FINAL_RELEASE after making some changes. All games started with such a corrupt DLL could also become corrupt because if you load such a Game and use a Recompiled DLL the game still crashes but the exception is another one. That was the reason i asked strategyonly for the revision he started the game with because i thing it's an older one with a corrupt DLL. I never saw that CTD in a Game played and started with a non corrupt DLL.

Then debugging such a corrupt Game with a non corrupt DLL you get an Access violation in the marked line of CvSelectionGroupAI::AI_update()

			CvUnit* pHeadUnit = getHeadUnit();

			if (pHeadUnit == NULL || pHeadUnit->isDelayedDeath())
			{
				break;
			}

			resetPath();

			[COLOR="Red"]if (pHeadUnit->AI_update())[/COLOR]
			{
				// AI_update returns true when we should abort the loop and wait until next slice
				break;
			}

Also removing the corrupt units from the save makes it playable again.

But i might be completely wrong and there is another reason.

I'm wondering if I can trust the results I'm getting by applying a new trick I've figured out with a minidump file.

If I can... this is a problem I cannot begin to hope to be able to self-determine a solution for and will need some advice. I believe we've seen this sort of thing before but I can't fathom how it happens nor how to determine that nor how to fix it.

When I pull up these mini's I've been getting (which don't repeat for me but then maybe that's BECAUSE I'M RUNNING THE DEBUGGER TO CHECK THEM) I get the following in the call stack:

	73616220()	
>	CvGameCoreDLL.dll!CvUnitAI::AI_update()  Line 430	C++
 	CvGameCoreDLL.dll!CvSelectionGroupAI::AI_update()  Line 293 + 0x7 bytes	C++
 	CvGameCoreDLL.dll!CvPlayerAI::AI_unitUpdate()  Line 1909 + 0xb bytes	C++

My presumption is that the final reference in the stack there is in the EXE?

This only shows when I'm running the minidump in a folder with both the dll and pdb documents in the same folder as the minidump.

When I run it from the Final Release or Debug folder that includes all the codes - not JUST the pdb and dll, I get a very different call stack that runs through a LOT of python calls then ends the same way but never gets back far enough to report anything taking place in the dll.

But here's the trick I discovered that I finally tried tonight: When I double click on the last dll call there in the stack, it directs me to search through my computer for the location of the source files. Guiding it to that source folder it immediately opens up that file and shows where it last visited the function:

#ifdef _DEBUG
	if ( NULL != getGroup() && !isDelayedDeath() )
	{
		getGroup()->validateLocations();
	}
#endif

	return (!isDelayedDeath() && AI_isAwaitingContract());
}

Pointing to the last return line there in the AI_Update() function.

Now HERE'S the VERY WEIRD THING: When hovering over isDelayedDeath() it shows a hover that states:
0x05363be0 CvUnitInfo::isNoRevealMap(void)

Now... if I'm not mistaken, this is telling me that whatever isDelayedDeath() is returning is 'whatever the value of isNoRevealMap(void) happens to be'.

How on Earth does this happen? And of course... how is it repaired?

I also noticed what you are saying about the minidump.

I think this could be a Compiler Bug and if not !! This is from the diassembly

		// if no longer automated, then we want to bail
		return (!isDelayedDeath() && !getGroup()->isAutomated());
05732400  mov         ecx,esi  
[COLOR="Red"]05732402  call        CvUnitInfo::isNoRevealMap (05733BE0h) [/COLOR] 
05732407  test        al,al  
05732409  jne         $L228152+245h (0573241Dh)  
0573240B  mov         ecx,esi  
0573240D  call        CvUnit::getGroup (05697670h)  
05732412  mov         ecx,eax  
05732414  call        CvSelectionGroup::isAutomated (056613E0h)  
05732419  test        al,al  
0573241B  je          $L228152+29Ah (05732472h)  
0573241D  pop         edi  
0573241E  pop         ebp  
0573241F  pop         esi

	return (!isDelayedDeath() && AI_isAwaitingContract());
0573245C  mov         ecx,esi  
0573245E  call        CvUnitInfo::isNoRevealMap (05733BE0h)

It is calling CvUnitInfo::isNoRevealMap and not CvUnit::isDelayedDeath()

 

[Koshling]

These two posts explain the situation.
I think the error shown in the diassembly a wrong call to CvUnitInfo::isNoRevealMap instead of CvUnit::isDelayedDeath came from not performing a full Rebuld then building the FINAL_RELEASE after making some changes. All games started with such a corrupt DLL could also become corrupt because if you load such a Game and use a Recompiled DLL the game still crashes but the exception is another one. That was the reason i asked strategyonly for the revision he started the game with because i thing it's an older one with a corrupt DLL. I never saw that CTD in a Game played and started with a non corrupt DLL.

Then debugging such a corrupt Game with a non corrupt DLL you get an Access violation in the marked line of CvSelectionGroupAI::AI_update()

			CvUnit* pHeadUnit = getHeadUnit();

			if (pHeadUnit == NULL || pHeadUnit->isDelayedDeath())
			{
				break;
			}

			resetPath();

			[COLOR="Red"]if (pHeadUnit->AI_update())[/COLOR]
			{
				// AI_update returns true when we should abort the loop and wait until next slice
				break;
			}

Also removing the corrupt units from the save makes it playable again.

But i might be completely wrong and there is another reason.

Sounds to me like your problem is that you don't have the PDB that matches the DLL that was used to generate the minidump. That would explain the confusion over function names. It has to be the PDB from the exact build that built the exact version of the DLL that created the minidump (so FINAL_RELEASE I assume since SO provided the minidump, of whatever release it was).

Is it repeatable using the latest version with SO's save game? If it is then just repeat it under the debugger in the debug version. If it's not and you don't have (or are not confident you have) the correct PDB for the minidump there's really not much you can do.

 

[alberts8]

Sounds to me like your problem is that you don't have the PDB that matches the DLL that was used to generate the minidump. That would explain the confusion over function names. It has to be the PDB from the exact build that built the exact version of the DLL that created the minidump (so FINAL_RELEASE I assume since SO provided the minidump, of whatever release it was).

Is it repeatable using the latest version with SO's save game? If it is then just repeat it under the debugger in the debug version. If it's not and you don't have (or are not confident you have) the correct PDB for the minidump there's really not much you can do.

That is very possible but i was thinking in that case it might be a error inside the Dll because.
A minidump from a corrupt Dll shows this message
'The thread tried to execute an invalid instruction.' a minidump from the same save with a non corrupt Dll shows
'The thread tried to read from or write to a virtual address for which it does not have the appropriate access.' Why two different messages without any code changes the only difference is the second one comes from a Dll built with a full Rebuild.
The invalid instruction would suggest that it's not only a problem with the Pdb.
But i might be wrong and just misguided by that. I tried to come up with a fix for this and could write alot more about my results but i can't because i'am very bad in explaining things in a way others understand it.
You are definitely more qualified maybe you can take a closer look.

 

[Hydromancerx]

So I was attempting to add new Language civics, but their text keeps falling off the edge. how can I expand the size of the background like the other civics have?

 

[Dancing Hoskuld]

So I was attempting to add new Language civics, but their text keeps falling off the edge. how can I expand the size of the background like the other civics have?

It is dynamic ie it should be getting the correct size by counting the number and then drawing the block to that size. Just in case delete the cache and try again. It s a long shot.

 

[Hydromancerx]

Well its on the SVN now. Do you get this or did it resize correctly for you? If not we need to figure out why.

 

[Dancing Hoskuld]

I don't have access to the SVN here.

 

[strategyonly]

Well its on the SVN now. Do you get this or did it resize correctly for you? If not we need to figure out why.

Looks fine to me:

 

[Thunderbrd]

Sounds to me like your problem is that you don't have the PDB that matches the DLL that was used to generate the minidump. That would explain the confusion over function names. It has to be the PDB from the exact build that built the exact version of the DLL that created the minidump (so FINAL_RELEASE I assume since SO provided the minidump, of whatever release it was).

Is it repeatable using the latest version with SO's save game? If it is then just repeat it under the debugger in the debug version. If it's not and you don't have (or are not confident you have) the correct PDB for the minidump there's really not much you can do.

As I recall, I was able to step through the crash with a running game and witness the dll use the indicated incorrect function for no apparent reason. It's not just the PDB being different. Recompiling a full rebuild it went through fine without a hitch but ended up with a crash later. It appears that SO found the problem again due to what must've been a dll that hadn't been fully reconstructed. I've been finding it a pain in the arse to delete the debug and final release folders and get a full rebuild every time I prepare for commit but it's all that seems to avoid this problem.

 

[Hydromancerx]

Looks fine to me:

Cool. Thanks for checking.

 

[Flinx]

Faustmouse introduced recently some buildings which can only bee build by Great Persons:
- some beliefs by prophets and
- the national wonder standard measurement, by a Great Scientist or Great Engineer.
Says the sevopedia.
Fact is, ingame you cannot build this buildings, although the xml looks fine.

My question to Faustmouse: can the Great Persons build the wonders in your civ- set-up?