DEBUG: Get Continent Assert Failure

[Ekmek]

I compiled a CTP_debug version and the game wont load with a debug because of an assert failure

void World::GetContinent(const MapPoint &pos, sint32 &cont_number, BOOL &is_land) const
{
	BOOL GET_CONTINENT_RETURNED_INCONTINENT_VALUE = FALSE;
	is_land = !IsWater(pos); 
	
	
	cont_number = GetCell(pos)->m_continent_number;
	if (is_land) { 
		cont_number -= LAND_CONTINENT_START; 
	} 

	if (cont_number < 0)
	{
		
		[b]Assert(GET_CONTINENT_RETURNED_INCONTINENT_VALUE);
        is_land = FALSE; [/b]
        cont_number = 0; 
	}

	if (!is_land && cont_number >= LAND_CONTINENT_START)
	{
		
		Assert(GET_CONTINENT_RETURNED_INCONTINENT_VALUE);
        is_land = FALSE; 
        cont_number = 0; 
	}
}

saying the problem is the line in bold

EDIT: (the spacing messed up when i pasted from msvc)

[Ekmek]

civ3log00.txt

Here's the log

 SlicEngine.cpp@2090: SLIC: control InitPlayWindow.NewGameButton used
 SlicEngine.cpp@2090: SLIC: control SPNewGameWindow.StartButton used
   gameinit.cpp@1645: ** RANDOM SEED 5241187
     wldgen.cpp@991 : Good Aluminium has a base value of 1.050000
     wldgen.cpp@991 : Good Coal has a base value of 1.050000
     wldgen.cpp@991 : Good Elephant has a base value of 0.040000
     wldgen.cpp@991 : Good Horse has a base value of 0.040000
     wldgen.cpp@991 : Good Iron has a base value of 1.050000
     wldgen.cpp@991 : Good Lumber has a base value of 0.043333
     wldgen.cpp@991 : Good Oil has a base value of 0.020000
     wldgen.cpp@991 : Good Rubber has a base value of 1.050000
     wldgen.cpp@991 : Good Uranium has a base value of 1.050000
     wldgen.cpp@991 : Good Cocoa has a base value of 0.048333
     wldgen.cpp@991 : Good Coffee has a base value of 0.048333
     wldgen.cpp@991 : Good Cotton has a base value of 0.036667
     wldgen.cpp@991 : Good Spices has a base value of 0.048333
     wldgen.cpp@991 : Good Sugar has a base value of 1.050000
     wldgen.cpp@991 : Good Tobacco has a base value of 0.045000
     wldgen.cpp@991 : Good Cattle has a base value of 0.045000
     wldgen.cpp@991 : Good Fish has a base value of 0.010000
     wldgen.cpp@991 : Good Fruit has a base value of 0.046667
     wldgen.cpp@991 : Good Rice has a base value of 0.048333
     wldgen.cpp@991 : Good Tropical Fruit has a base value of 0.048333
     wldgen.cpp@991 : Good Wheat has a base value of 0.046667
     wldgen.cpp@991 : Good Dye has a base value of 0.036667
     wldgen.cpp@991 : Good Fur has a base value of 0.046667
     wldgen.cpp@991 : Good Gems has a base value of 0.048333
     wldgen.cpp@991 : Good Incense has a base value of 1.050000
     wldgen.cpp@991 : Good Silk has a base value of 0.041667
     wldgen.cpp@991 : Good Wine has a base value of 0.048333
     wldgen.cpp@991 : Good Game has a base value of 1.050000
     wldgen.cpp@991 : Good Gold has a base value of 1.050000
     wldgen.cpp@991 : Good Whale has a base value of 0.016667
     wldgen.cpp@991 : Good Bioweapons has a base value of 1.050000
     wldgen.cpp@991 : Good Chemical weapons has a base value of 1.050000
     wldgen.cpp@991 : Good Gunpowder weapons has a base value of 1.050000
     wldgen.cpp@991 : Good Automatic weapons has a base value of 1.050000
     wldgen.cpp@991 : Good Nuclear weapons has a base value of 1.050000
     wldgen.cpp@991 : Good Music has a base value of 1.050000
     wldgen.cpp@991 : Good Movies has a base value of 1.050000
     wldgen.cpp@991 : Good Tourism has a base value of 1.050000
     wldgen.cpp@991 : Good Avionics has a base value of 1.050000
     wldgen.cpp@991 : Good Electronics has a base value of 1.050000
     wldgen.cpp@991 : Good Automobiles has a base value of 1.050000
     wldgen.cpp@991 : Good SPECIAL_GOOD_MERCHANT_FLEET has a base value of 1.050000
    c3debug.cpp@320 : Assertion (GET_CONTINENT_RETURNED_INCONTINENT_VALUE) Failed in File:F:\SVN-Code\trunk\ctp2_code\gs\world\WrldCont.cpp, Line:474
    c3debug.cpp@323 : Stack Trace: '  0x00457990  [char * __cdecl c3debug_StackTrace(void) + 0x20]
  0x004523e4  [void __cdecl c3debug_Assert(char *,char *,int) + 0x44]
  0x0063fa3e  [public: void __thiscall World::GetContinent(class MapPoint const &,long &,int &)const  + 0x7e]
  0x0063fcad  [public: void __thiscall World::FindContinentNeighbors(void) + 0x8d]
  0x0063e6d3  [public: void __thiscall World::NumberContinents(void) + 0xa3]
  0x0063092e  [public: void __thiscall World::CreateTheWorld(class MapPoint * const,long * const) + 0x10e]
  0x0060ec45  [long __cdecl gameinit_Initialize(long,long,class CivArchive &) + 0x6f5]
  0x0046af6c  [public: long __thiscall CivApp::InitializeGame(class CivArchive &) + 0x20c]
  0x0046ddc6  [public: long __thiscall CivApp::StartGame(void) + 0x16]
  0x0046fa67  [public: virtual void __thiscall StartGameAction::Execute(class aui_Control *,unsigned long,unsigned long) + 0x17]
  0x008c89e2  [public: void __thiscall aui_UI::HandleActions(void) + 0x62]
  0x008c894c  [public: virtual enum AUI_ERRCODE __thiscall aui_UI::Process(void) + 0x4c]
  0x0046d5e0  [public: long __thiscall CivApp::ProcessUI(unsigned long,unsigned long &) + 0x200]
  0x0046db4e  [public: long __thiscall CivApp::Process(void) + 0xce]
  0x00461e9e  [int __stdcall CivMain(struct HINSTANCE__ *,struct HINSTANCE__ *,char *,int) + 0x3be]
  0x004614a3  [WinMain@16 + 0x83]
  0x00b94c73  [WinMainCRTStartup + 0x1b3]
  0x7c816d4f  [\177zlib1_NULL_THUNK_DATA + 0x7b45149f]

I included the goods because the base value exceed over 1 on a bunch and i think thats what makes them unavailable. but not sure why it made Sugar unavailable because it has the same values as the rest. more on that later


what going on with:

Assertion (GET_CONTINENT_RETURNED_INCONTINENT_VALUE) Failed in File:F:\SVN-Code\trunk\ctp2_code\gs\world\WrldCont.cpp, Line:474

[Martin Gühmann]

That seems very odd, espeacilly because the following line isn't followed by an exception stack of its own:

0x7c816d4f [\177zlib1_NULL_THUNK_DATA + 0x7b45149f]

One idea would be that it is only in your ctp_debug.exe, therefore I would recompile everything to see whether the problem is still there.

-Martin

[Martin Gühmann]

Originally posted by Martin Gühmann
One idea would be that it is only in your ctp_debug.exe, therefore I would recompile everything to see whether the problem is still there.

And E did this idea help?

-Martin

[Ekmek]

no, it wasn't by ctp_debug because in a different copy of ctp2 my debug worked fine. So something that can be changed in the txt files somehow affects calling the Getcontinent but I traced it as much as I could and didn't see any DB link. My best guess was the AI with samecontinent but that wasn't it.

I'm going to try a new debug later today.

[Martin Gühmann]

OK in the mean time I put your mod into a scenario folder at I can tell you that it does not crash but I get the incontinent continent falure hundrets of times. So something is definately wrong.

-Martin

[Ekmek]

wrong with my mod or incontinent continent failure?

[Martin Gühmann]

Originally posted by E
wrong with my mod or incontinent continent failure?

Well I did not test it with the default game, but as you told me that there was no problem with the default game I asume so far that it is a problem with your mod. Maybe a step by step replacement of text files would bring us further to the problem.

-Martin

[Fromafar]

Actually, a failing Assert is not a crash, but just a note to you that things are not as expected. This particular Assert tells you that the continent numbering in a loaded game is inconsistent.

I have seen this before - in the updated Alexander scenario, where Locutus had modified the original scenario map by adding some great rivers. The river tiles were land tiles in the original map, and still had the old "land continent" numbers stored in the save file. As you can see when you look at the code, this is no problem at all: after reporting the Assert failure, the tiles are marked as water tiles and the continent numbers are removed.

When you do have a real crash, it most likely means that you have either a corrupted save file, or corrupted the save file loading. The latter may be caused by e.g. the changes you made to TerrainImprovementData. The middle-insertion of the new member m_materialBonus will break the save game compatibility, so any file saved with a version before this change is most likely to crash.

[Martin Gühmann]

Unfortunately the problem did not occur with a save game, but with a new game. I got the suspicion that the Assert was thrown for every tile on the map and that worries me much more.

-Martin

[Martin Gühmann]

Originally posted by Fromafar
When you do have a real crash, it most likely means that you have either a corrupted save file, or corrupted the save file loading. The latter may be caused by e.g. the changes you made to TerrainImprovementData. The middle-insertion of the new member m_materialBonus will break the save game compatibility, so any file saved with a version before this change is most likely to crash.

Indeed this middle insertion is a problem. Therefore I moved it to the end of the data member list, but now I get this Assertion falure:

    c3debug.cpp@320 : Assertion (ARCHIVE_MAGIC_DUD) Failed in File:C:\Activision\Ctp2\ctp2_code\robot\aibackdoor\civarchive.cpp, Line:458
    c3debug.cpp@323 : Stack Trace: '  0x00457590  [char * __cdecl c3debug_StackTrace(void) + 0x20]
  0x00451fe4  [void __cdecl c3debug_Assert(char *,char *,int) + 0x44]
  0x00855290  [public: void __thiscall CivArchive::TestMagic(unsigned long) + 0x60]
  0x0058bb3b  [public: void __thiscall MaterialPool::Serialize(class CivArchive &) + 0x4b]
  0x005956cc  [public: void __thiscall Player::Serialize(class CivArchive &) + 0x3ac]
  0x005947ea  [public: __thiscall Player::Player(class CivArchive &) + 0x92a]
  0x0060bd1c  [long __cdecl gameinit_Initialize(long,long,class CivArchive &) + 0x258c]
  0x0046ab0c  [public: long __thiscall CivApp::InitializeGame(class CivArchive &) + 0x20c]
  0x0064cbab  [public: unsigned long __thiscall GameFile::Restore(char const *) + 0xdeb]
  0x0064a4ab  [public: static void __cdecl GameFile::RestoreGame(char const *) + 0x6b]
  0x0046dbcc  [public: long __thiscall CivApp::LoadSavedGame(char *) + 0x18c]
  0x0046f66e  [public: virtual void __thiscall LoadSaveGameAction::Execute(class aui_Control *,unsigned long,unsigned long) + 0x1e]
  0x008b8472  [public: void __thiscall aui_UI::HandleActions(void) + 0x62]
  0x008b83dc  [public: virtual enum AUI_ERRCODE  __thiscall aui_UI::Process(void) + 0x4c]
  0x0046d180  [public: long __thiscall CivApp::ProcessUI(unsigned long,unsigned long &) + 0x200]
  0x0046d6ee  [public: long __thiscall CivApp::Process(void) + 0xce]
  0x00461a9e  [int __stdcall CivMain(struct HINSTANCE__ *,struct HINSTANCE__ *,char *,int) + 0x3be]
  0x004610a3  [WinMain@16 + 0x83]
  0x00b83563  [WinMainCRTStartup + 0x1b3]
  0xbff8b560  [(kernel) + 0x0]

By the way E what is the m_materialBonus thingy thought for?

-Martin

[Ekmek]

m_materialBonus was another attempt at trying to get a value out of a tileimprovement not in a city radius. The colonies give PW thing that I tried in player. This time I had to add something in access to get to it, but it still didnt work.

but why does it affect getcontinent?

[Martin Gühmann]

Originally posted by E
but why does it affect getcontinent?

Probably it doesn't affect GetContinent in any way. However Framafar did brought it up. And there is is no other place to talk about it.

So far I figured out the cause of my crash, and note this time it is really an termination of the program, however in this case it is probably caused by the exit function.

The problem is located in Readiness, you added another member, that made Readiness objects longer and broke the save game loading. Fortunately for you is that the is an unused member m_pad that I can rename.

The only thing I wonder is that loading works even if I change it to double that is 8 byte long instead of 4 byte. Actually this should not work.

But anyway I think in the final version I will release it as sint32.

-Martin

[Fromafar]

There is no direct connection between the materialbonus and GetContinent. When you have saved a file with a version that did not include this item, trying to restore this file with a later version (which expects this item in the file) will corrupt everything that is in the file after the first occurence of some materialbonus read attempt. Where you think you are reading a materialbonus sint32, you will just read the 4 next bytes - whatever these were in the original file - and from that point, all bytes are shifted 4 positions, leading to a complete misinterpretation of everything that comes after it in the file.

The Assert(ARCHIVE_MAGIC_DUD) failure is a dead giveaway that this happened. At a couple of points the program saves/verifies some unlikely-to-occur-in-normal-data "magic" byte sequences. When you have a misinterpretation because of an unexpected shift, these are very likely to fail.

[Ekmek]

Should I just move it to the end? is it that simple? or just out comment it for now until I get something working with it?