COMPILE: Getting the source to compile

[Martin Gühmann]

I was able to build ctp2r.exe it is a 12.143 kb file. Unfortuinatly I get after loading an slic error message "GM1_APOL_Slic.slc: No function named OpenBuildQueue." And then the game is closed.

OK now the missing file is there I can try again the debug version.

-Martin

[J Bytheway]

Originally posted by Martin Gühmann
Costum build setting where can I find this option, John?

Right-click on the file in question, go to Settings, and it should be the second tab - there will be a line like:

$(CDKDIR)\flex -i -o$(ProjDir)\..\gs\slic\lex.yy.c $(InputPath)

That is what you need to run (with the various $(...) variables substituted for the appropriate things). I suggest that before doing it manually you first try compiling individually through the option in the right-click menu.

[J Bytheway]

Cross-posting galore...

Originally posted by Locutus
On the Debug build I get this:

Debug Assertion Failed!

Program: D:\Games\Activision\source\ctp2_code\CivCTP_dbg.ex e
File: D:\Games\Activision\source\ctp2_code\gs\fileio\Gam
eFile.cpp
Line: 2093

Expression: g_soundManager != NULL

I guess I must have outcommented a bit too much

It will inevitably be NULL - see the function SoundManager::Initialize, where you have presumably commented out the line which creates the SoundManager. I'm slightly worried because just after the assertion in GameFile.cpp the function returns when there's no SoundManager, and that means it misses the last few lines of the function which look like they are setting up starting locations and scenario settings, which might be important.

On the other hand, it seems to work properly at least at first glance... Certainly my settlers are being created at some location. Perhaps the problem will arise if a scenario with custom start locations is used.

[Locutus]

Originally posted by J Bytheway
I got a couple of assertion errors in GameFile.cpp line 2093 where the non-NULLity of the sound manager is asserted, so I commented that one out

Solving a bug by deleting an asserting, cute

But in this case it makes sense of course, 'cause the Assertion *should* fail with the soundmanager being a stub. Didn't realize the assertion was actually causing the crash, I initially thought it was a symptom.

[Locutus]

Yet more crossposting

I'm slightly worried because just after the assertion in GameFile.cpp the function returns when there's no SoundManager, and that means it misses the last few lines of the function which look like they are setting up starting locations and scenario settings, which might be important.

I agree, this could in the future prove to be a problem, but from what I can tell can simply be solved by moving the soundmanager part to the very end of that function, after the startingPlayer line.

[J Bytheway]

Well, in my latest test I successfully started a game, played a few turns and quit without any assertion or other errors, so I'll take that as a good omen and go to bed now.

I am surprised by how much slower the debug version is - about a factor of 5-10, I think. It's rather annoying, because it will make testing more difficult... I wonder how the original developers coped given that their processors were almost certainly considerably slower than ours (Although mine's only 1.6GHz).

[J Bytheway]

Originally posted by Martin Gühmann
I was able to build ctp2r.exe it is a 12.143 kb file. Unfortuinatly I get after loading an slic error message "GM1_APOL_Slic.slc: No function named OpenBuildQueue." And then the game is closed.

OK now the missing file is there I can try again the debug version.

I was getting lots of SLIC errors like that - I suggest that for the moment you switch back to original game settings. We'll try to get the mods working properly later...

[Locutus]

Strange, I really haven't noticed that much of a difference between debug and the other builds...

However, I do get an assertion error when using the /rnd command, which is *very* annoying for testing...

[Fromafar]

Locutus:

I have retried it from scratch (the CTP_Source.exe). When starting with a final build the first time, the Command and Output fields for e.g. ui\ldl\ldl.l are definitely empty. As J.Bytheway suggested, doing a debug build first will solve the problem by generating the .c and .h files.

On the other hand, the final build for me has the same behaviour as the original ctp2.exe with regard to the CD check. I tested this by placing the generated file in the ctp_program\ctp directory.

I do not get the intro movie at all. This is probably because my PC has no sound card and has been this way for the original version as well. Without the CD inserted, I get as far as launching a new game, but then a popup appears. Inserting the CD and pressing Retry makes it proceed with the launch. The funny thing is, that the release (9 MB) version does not look for the CD at all, and just launches the game.

For what it is worth, I have not modified any source file (yet). I only have modified project settings, and added a stub for mss.h in libs\miles.

[Admiral PJ]

When using Net, one issue is that it no longer supports Stream classes as STANDARD, such as CIN and file handling.

(This is because these functions aren't thought of as good programming practice.. they break the official standards supposedly.. )

Add the following to the beginning of the code, in the main header file :-

line1> // REQUIRED FOR VSC NET to allow C streams etc.

line2> using namespace std ;


I think this will fix the file handling errors in CTP2 as it appears to use streams.

I use the old stream functions in my code.. seems to be the easiest way to do file handling.


DIRECTX may work fine , its mainly directinput that has some differences with dx9 etc.. and that dosen't appear to be in CTP2.. (haven't checked the mouse code yet tho)
DirectDraw might need some rewriting, it seems to use more clippers etc now, its not even fully supported in DX9 so maybe we should stick to the original compiler.

I think its just stricter than the old compiler .. the code will probably compile but there might be more run time errors, if its anything like converting my code from vc6 to 7.


IN GENERAL:

It dosen't appear that bad , its written well , and it shuldn't take too long to add more features using the original code.. fixing bugs might be a bit tricky , but with time and manpower we'd have a better chance than the original programmers who had a strict timelimit (they were doing it commercially ).

Its good the original text files are included.. but people like me don't have a copy of CTP which might be difficult..
interesting the game references that its Civilisation 3 in the code file names.

[Locutus]

Originally posted by Fromafar
I have retried it from scratch (the CTP_Source.exe). When starting with a final build the first time, the Command and Output fields for e.g. ui\ldl\ldl.l are definitely empty. As J.Bytheway suggested, doing a debug build first will solve the problem by generating the .c and .h files.

Ah... that explains it then...

On the other hand, the final build for me has the same behaviour as the original ctp2.exe with regard to the CD check. I tested this by placing the generated file in the ctp_program\ctp directory.

D'oh! Should've thought of this myself... The CD checks works properly for me as well when placed in the correct folder.

The funny thing is, that the release (9 MB) version does not look for the CD at all, and just launches the game.

Yes, I noticed this as well. Not surprisingly when you think about it: when the Activision team was working on the game, they obviously didn't have the CDs yet

For what it is worth, I have not modified any source file (yet). I only have modified project settings, and added a stub for mss.h in libs\miles.

That's brilliant A far more elegant solution than replacing existing code with stubs. Will download and use it myself as well, thanks

[Locutus]

t dosen't appear that bad , its written well , and it shuldn't take too long to add more features using the original code..

Yes, that was my impression as well, the code looks quite okay

but people like me don't have a copy of CTP which might be difficult..

If you want to, you should be able to pick up a copy of CtP2 really cheap from the bargain bin. Not all shops have the game anymore of course, but there are still plenty that do...

[J Bytheway]

I believe the reason for the lack of CD check on non-final versions is in ProfileDB.h, around line 510, where it defines ProfileDB::IsProtected differently depending on the definition of the _BFR_ constant (_BFR_ is defined in the final build). The CD checking code looks this property up.

Mine also successfully finds the CD when I copy it into the other directory... Now I'm going to try and figure out why it's any different.

[J Bytheway]

Further, if you want to override this behaviour you can set Prophylaxis=Yes in userprofile.txt - that will cause it to perform the CD check even on builds other than the final build (Unsurprisingly, you can't change the final build behaviour). This explains why noone was able to figure out what the Prophylaxis option did.

[J Bytheway]

I've figured it out - there's a file called texture.dat in ctp2_program/ctp in a normally installed version. This file contains the track lengths it looks for in an encrypted form. If you copy this file over to ctp2_code/ctp then it should make the CD check successfully.