06-11-2003 20:31									#31
	Support Apolyton, buy Alpha Centauri

Asmodean,

Yes, John has the game working perfectly, but it's a pity he seems to be just about the only one

John,
Well, normally I should be the one to create the packages of new patches, so you don't have to worry about that That is, assuming we can get this annoying crash fixed

Regarding the movie logo, I guess we could cut the Activision logo out of the intro movie, that should only take about 10 seconds for anyone with the right software (not counting the time to load and save everything ). I think even I could do that. But I'm not sure if it's really worth the trouble -- it would mean that everyone would have to download a 30 meg large file just to get rid of a stupid logo. But if anyone were ever to design a cool new intro movie, I'm all ears

	06-11-2003 22:40									#32
	Support Apolyton buy from Amazon

I've uploaded a diff file:

http://apolyton.net/csd.php?http://...ay/Ctp2diff.zip

This is the diff between a version of the ctp2_code directory which I believe is original, except for me compiling the Debug Browse version of crater.dll, and my current version of the ctp2_code directory. The information you seek should be in there somewhere...

If anyone has any other iideas as to how we could compare, I'm open to suggestions.

	06-11-2003 23:06									#33
	Support Apolyton, buy Call to Power 2

Thanks muchly, John. I'm going to check this out as soon as possible.

	07-11-2003 05:41									#34
	Findings from diff file. Support Apolyton, buy Civilization III: Complete

Nothing earth shaking... the following are the apparent differences in the source files (all which we essentially know about):

ctp2_code/ctp/civ3_main.cpp obvious added disclaimer
ctp2_code/ctp/ctp2_utils/c3errors.cpp=cd check stuff
ctp2_code/ctp/ctp2_utils/c3errors.h=disclaimer message box header alterations
ctp2_code/ctp/display.h= #include multimon.h
ctp2_code/ctp/dll/map/Crater.dll= binary file differs?
ctp2_code/ui/interface/NationalManagementDialog.cpp= added fix for rushbuy

The following, however are the differences in the flex and byacc compiled files (or I guess they are created from there)

ctp2_code/ctp/eventcb.txt=different, based on where compiled?
ctp2_code/ctp/slicdbg.txt=different numbering no idea why?
some... not all of the .stamp files differ in numeric values

===

So.. my thoughts? I don't see any significant source file difference to speak of- I've added the change to display.h and thats the only theoretical problem that I see could cause the crash. The rest are new additions or pre-existing bugs.

The differences in the manual compile stuff bothers me.

It could be I'm doing that wrong, but I don't see how. Why would it fail if I did a debug build, then a final build, with the #include change?

Incidentally I've gotten two consistent warnings on two lines in debugcallstack; unreferenced local variable definitions, solved by putting inside ifndefs, but they don't change solve anything either way.

I've done manual and automated flex/byacc etc. Same result.

So... possible differences.

*Different DirectX build. Possibily. I'll check, and try if different. You were using '03 summer?
*Different miles.h and mss32.lib. Which ones are you using, John?
*Different manual compiled files, somehow. The only way to see if its this is to get those files.

My ideal solution would be to copy the (working) directory to another location. Run the uninstall for it. Which will remove any unchanged files. Remove the exe's, map files and the contents of the final directory.

That should leave the 'different' files.

Zip/rar that up (multipart to 5 Megs, I guess, if necessary), including full directory paths.

I'll install a fresh source into there, then copy the contents of the zip over the top.

That should solve it, I guess... I hope...

	07-11-2003 19:04									#35
	Support Apolyton, buy Civilization: The Boardgame

I was indeed using DirectX '03 summer. If you look at the chat transcript I believe Locutus and I discussed this in detail.

I'm using the miles.h and miles.lib from the first post of the "Success with the sound" thread (note that they did change, I got the latter versions).

I presume the crater.dll difference is due to one being a final build and one being a debug browse build, but I'm not sure.

The slicdbg.txt is generated at runtime and depends on what SLIC code is being loaded.

eventcb.txt I knownothing about, essentially.

Doing as you suggest has some problems: The DX stuff in the directory structure will make it huge, and I'm slightly worried about screwing up my own setup now I have it working. I'm also running low on disk space, so it gets hard to make lots of backup copies and so forth.

Differing DirectX versions still seems the most likely cause, or some other more subtle variation in our setups...

	07-11-2003 19:14									#36
	Suffering from ads?

The following post might be pertinent to these problems:

http://apolyton.net/forums/showthre...144#post2468144

	07-11-2003 21:01									#37
	Support Apolyton or Terrorists Win

I reinstalled the Summer release of 9.0b. Copied the new libs in.

New debug build, then new final build, and it crashes.

Exactly the same spot.

Odd since the regular game and that exe you produced work.

I really don't have any clue how to proceed, particularly since the problem is seemingly causing a debugger crash (but other debug situations don't)

	07-11-2003 21:02									#38
	Get a bigger avatar today!

I, by the way, did have the later miles.h and mss32.lib, but recopied them just to be sure.

	07-11-2003 21:16									#39
	Full PM-box? Change here!

BTW... I haven't mentioned this recently, but I'm getting really quite significantly frustrated with this.

The code I've done at work from scratch, or in a team has never been this kind of a problem.

	08-11-2003 02:50									#40
	Get a bigger avatar today!

I guess you can try to narrow down the exact time of the crash by putting in messageboxes everywhere (use c3_errorDialog, or whatever it's called). I was doing that earlier when I thought the debug build was stalling.

My personal attempts at C++ code usually run into the kinds of problems I can't track down as soon as I'm linking different files together...

	27-11-2003 05:05									#41
	Support Apolyton, pre-order Civilization IV

I've been trying to locate the source of the mysterious crashes by adding the test message "c3errors_ErrorDialog(NULL, "test");" in various places in the code. This hasn't lead to a solution yet, but I have established how the proces of loading a new game works:

The function CivApp::PostStartGameAction can be called from a number of places in the UI files and adds a startGameAction to the action list, which aui_UI::HandleActions (which continously runs: it is called from the aui_UI::Process, which itself is called from CivApp::ProcessUI, which is in turn called from CivApp::Process, which is called in the main while loop of CivWinMain in civ3_main.cpp) then picks up and runs by calling StartGameAction::Execute. This calls the civApp::StartGame function, which calls CivApp::InitializeGame, which actually sets up a new game.

The crash does not occur in the CivApp::InitializeGame function itself, this completes just fine. So do civApp::StartGame and StartGameAction::Execute. Putting a test message after the last command of the for loop that handles the startGameAction event (in aui_UI::HandleActions), displays this message correctly. So the problem does not appear to be in the handling of the startGameAction event. It is not possible to place test message in the main body of aui_UI::HandleActions or its caller aui_UI::Process, as these functions are part of a while loop and are executed continuously while the game runs. The game would probably be interrupted by error messages millions of times before getting to the point of the crash, if you'd even get there at all.

The cause for the crashes appears to be in one of the main process functions (I suspect in CivApp::Process), not in the code that sets up a new game. The next course of action would seem to be to create/use a test message system that writes test messages to a log file, so that test messages can be placed in the various Processes, to see when exactly the crash occurs without interrupting the game. Currently I don't have time for this though.

Does anyone have ideas on how to best place test message in the Process functions? Maybe someone else who's experiencing the same crashes can pick things up from here? If not, I'll continue myself when I have time again.

	27-11-2003 23:31									#42
	Support Apolyton, buy Civilization 2

If you are using a debug build, you can log information with DPRINTF statements. Have a look in civ3_main.cpp for some examples. These will be logged to civ3log*.txt files in the logs directory, and seem to be created automatically.

	28-11-2003 00:00									#43
	Increase the size of your Attachments

'civ3_main.cpp' ? you don't mean that do you, or else no wonder they were after CTP2 so much in the courts

	28-11-2003 00:32									#44
	Remove this text

yes they did there some text files to

	28-11-2003 00:34									#45
	Tired of ads?

quote: If you are using a debug build, you can log information with DPRINTF statements. Have a look in civ3_main.cpp for some examples. These will be logged to civ3log*.txt files in the logs directory, and seem to be created automatically.

That's the whole point: the crash doesn't happen in the debug build. Only in Release and Final...

	28-11-2003 00:35									#46
	Support Apolyton, pre-order Civilization IV

CoT,
There's plenty of references to Civ3 in the ldl and other text files as well, so ooold news

	28-11-2003 00:38									#47
	Support Apolyton

locutos you did tell that to the files you have to compile first

	28-11-2003 00:39									#48
	Support Apolyton, buy Call to Power 2

I suggest then that you locate the definition of DPRINTF and make an analagous version (called RPRINTF, perhaps) which does the same thing for the release and final versions.

	28-11-2003 03:17									#49
	Support Apolyton, buy Galactic Civilizations

The following set of files will allow you to use DPRINTF statements in the Release version, provided that you add USE_LOGGING to the preprocessor definitions of the project (tested with the Release version).

USE_LOGGING.zip

Notes:

1. CityData.cpp has been based on the version in the Altered Source thread. If you want to use the original version, just compile without the file in this set. The compiler will report a missing declaration, but that should be easy to solve.
2. If the (amount of) logging makes the crash disappear, you may have to fiddle with the c3debug_SetDebugMask arguments in civ3_main.cpp.

	11-12-2003 23:40									#50
	Suffering from ads?

Thanks, Formafar, those files were most useful.

Edit: nevermind, didn't find the cause of the bug after all.

Last edited by Locutus on 11-12-2003 at 23:45

	11-12-2003 23:44									#51
	Remove this text

D'oh! Stupid me, ignore my last post.

	14-12-2003 00:46									#52
	Support Apolyton buy from Amazon

Maybe you already had noticed it, but reporting it here just to be sure:

When a program exception occurs, the program will dump its call stack to crash.txt in the logs directory.
For the debug and release versions this will occur automatically. For the final version you have to set EnableLogs to Yes in userprofile.txt.

	15-12-2003 08:29									#53
	Full PM-box? Change here!

Decided to uninstall/reinstall VS and all the other components again.

This time the game still crashes , but the debugger doesn't...

The crash is a divide by zero in CPUINF32, called from c3cpu.cpp, something to do with the P4?

I'll give turning off hyperthreading a shot... that doesn't explain why another compile worked for me tho...

*smiles* Well... at least I'm getting somewhere.

Last edited by MrBaggins on 15-12-2003 at 08:47

	15-12-2003 09:13									#54
	Remove this text

Woot! Solved it. (Well.. a workaround, but at least I know where to look)

Just explicitly specified the frequency of the processor, and the thing runs just fine... woot!

Anyone else compiled and running fine with a P4(C) on WinXP?

	15-12-2003 15:43									#55
	Increase the size of your Attachments

well im running a Celeron 2GHz on win xp and i have no problems at all.

	15-12-2003 16:44									#56
	Get a bigger avatar today!

Great news MrBaggins

Well, I *did* notice my processor speed being listed as 0MHz in the debug version, so I guess that will work for me as well (I have an Athlon XP 2000+ though).

I'm not at home so I can't test it now, but it will be the first thing I do when I get home. Where did you specify the frequency MrBaggins? In c3cpu.cpp?

	15-12-2003 18:52									#57
	Support Apolyton, buy Civilization 2

in c3cpu_Examine, I changed the g_cpuspeed assignation line to

g_cpuSpeed.norm_freq = 2400;

norm_freq is the only variable in the structure it seems to use later...

Its obviously not a solution, though...

	16-12-2003 00:24									#58
	Browse Apolyton AD-FREE

I'm using a P4 1.6GHz, and IIRC it lists my processor speed at something like 1.4GHz...

	16-12-2003 01:15									#59
	Put an end to popups!

My prosseor is also listed as 0Mhz in the debug version, but if I remember correctly there wasn't such a crash in the last non debug exe unfortunatly this build is not very recently.

-Martin

	16-12-2003 02:09									#60
	Support Apolyton, buy Civilization: The Boardgame

quote: From the cpuinfo/cpuinf32.dll documentation: While this program works on all current Intel processors, the code is designed to not analyze processor speed if the processor is NOT an Intel processor.

For my AMD 1000 MHz, all 4 processor speed values are reported 0. But this does not seem to cause any crashes.