Help Needed Compiling 'plymouth Cold War'

[elwood_s]

I want to make a modified version of Plymouth Cold War.  I've downloaded Blackbox's source code from here, but because it doesn't include a .dsp or .sln file I haven't figured out how to compile it.  

I've setup the SDK with Visual C++ 2008 Express Edition according to the instructions in AmIMeYet's Tutorial and completed a few of Sirbomber's "Outpost 2 Coding 101" lessons.  This unfortunately is the total of my C programming experience.  I tried using the "Create Project from Existing Code Files Wizard", but when I tried to build it I got a bunch of errors that I don't understand. I've attached the build log to this post.

Any help will be sincerely appreciated.

[Hooman]

Disclaimer: I've basically never looked at this project, other than a cursory glance a very long time ago.


Sounds like a function definition/body is given (with {}), when only a function prototype was expected.

Code: [Select]

void func(int param);  // Prototype
void func(int param) {} // Definition

Note the semicolon versus the braces. I suspect some compilers (particularly older ones), may be more lax about checking if an imported function is defined internally.


Edit: On closer inspection, yes.

Code: [Select]

ODASL_API(int) wplInit(wplOptions *inf) { return 0; }
ODASL_API(void) wplExit() {}
ODASL_API(void) wplSetPalette(HPALETTE pal) {}
ODASL_API(int) wplGetSystemMetrics(int nIndex) { return 0; }
ODASL_API(BOOL) wplAdjustWindowRect(LPRECT lpRect, DWORD dwStyle, BOOL bMenu) { return 0; }
ODASL_API(HBITMAP) wplLoadResourceBitmap(HMODULE hModule, LPCTSTR lpName) { return NULL; }
ODASL_API(int) wplManualDialogSubclass(HWND dlg) { return 0; }
ODASL_API(void) wplEnable() {}
ODASL_API(void) wplDisable() {}

The import/export declaration is controlled in the header file starting at line 23:

Code: [Select]

#ifdef BUILDING_ODASL
#define ODASL_API(rt) __declspec(dllexport) rt __cdecl
#else
#define ODASL_API(rt) __declspec(dllimport) rt __cdecl
#endif // BUILDING_ODASL

This defaults to import mode, which is what you need. There are no guards in the .cpp file. This would seem to suggest that the .cpp file is NOT part of the main project. The header file is used to basically link the two parts together. Remove the odasl.cpp file from your project and try again.


Edit2: Just noticed a .cbp file, which is a CodeBlocks project file. The project was created a while back when CodeBlocks was the only free IDE we knew how to setup. That's probably why there are no other project files. It's just a text file. You can look at it to see what project settings it uses, and what source files it's meant to include. Check the <Unit> tags near the bottom to see which files are part of the project. Just make sure not to add any header files as if they were source code files. You do *not* compile header files, only include them from compiled modules (aka "source" files - .cpp).
 

[elwood_s]

Hi Hooman,

Thanks so much for your post.   Sorry for not responding sooner.  

   There are no guards in the .cpp file. This would seem to suggest that the .cpp file is NOT part of the main project. The header file is used to basically link the two parts together. Remove the odasl.cpp file from your project and try again.....

 Just make sure not to add any header files as if they were source code files. You do *not* compile header files, only include them from compiled modules (aka "source" files - .cpp).

Per your suggestions, I excluded the odasl.cpp file and all the header files from the project and tried to build it again.  This eliminated the nine "definition of dllimport function not allowed" errors but unfortunately left me with the following new error:
.\OP2Script.rc(10) : fatal error RC1015: cannot open include file 'afxres.h'.

I searched my hard drive for afxres.h, and found that I don't have it, then wasted  wasted considerably more time looking online for a copy of the file that I could download.  The only one I could find was at koders.com and it looks line some kind of dummy file, since it only contains the following three lines of code:

Code: [Select]

#ifndef AFXRES_H
#define AFXRES_H
#endif // AFXRES_H

Also, when I tried using it I got the same two errors that I got when I simply commented out the #include "afxres.h" line:

.\OP2Script.rc(20) : error RC2144 : PRIMARY LANGUAGE ID not a number
.\OP2Script.rc(29) : error RC2135 : file not found: 907

Several places during my search I read that #include "windows.h" can be substituted for #include "afxres.h" when MFC or ATL support aren't required.  So I tried that.  Didn't work.  Resulted in seventy-some "LNK2019: unresolved external symbol " errors!!!     The other thing I gathered from my reading is that VC++ 2008 Express Edition doesn't have MFC or ATL support, so if either of those are required I may be screwed.

[Hooman]

There's no MFC or ATL used in the project. It's just straight Win32 API stuff. The afx stuff I believe is related to precompiled headers. I usually turn those off in my projects, and don't really know too much about working with them. At the moment I'm not too sure what to suggest, other than looking into precompiled header files, or perhaps figuring out how to turn them off (or on). If there are include directives that use the header, than you can try replacing them with an include to other header files. Add enough header files to account for any missing symbols. The only header outside of the project folder that will be required is probably <windows.h>.
 

[Sirbomber]

It's not compiling because of some stuff BB added to have that "briefing" dialog box popup before the game starts.

[Hooman]

Well, since I've seen plenty of request to find this project, and plenty more on how to compile it, I've spent a bit of time looking at it today. I've added an MSVC 6.0 project and workspace file for the project to help compiling it, and stored a copy in the SVN. I've tested compiling with MSVC 6.0, not running the result.

Note that I also modified the source a little to help with compiling. Some simple edits were paths in include directives. Another was the diffModifier variable was changed to an int, it was initialized to 10 times it's original values, and references to it had a "/10" added to it. That gets rid of the reliance on floating point (and extra runtime library support, which was causing link issues), and also removes the need for the pragma to disable the warnings. I believe the results should be the same, but I haven't done any runtime tests to verify. It's entirely possible I've changed behavior there due to rounding, or maybe an accidental order of operation change.
 

[elwood_s]

It's not compiling because of some stuff BB added to have that "briefing" dialog box popup before the game starts.

Thanks Sirbomber.

I thought that might be the issue, but don't have any idea how to deal with it.  

[Sirbomber]

You should PM Arklon.  I think he figured out how to get it working.

[elwood_s]

Well, since I've seen plenty of request to find this project, and plenty more on how to compile it, I've spent a bit of time looking at it today. I've added an MSVC 6.0 project and workspace file for the project to help compiling it, and stored a copy in the SVN. I've tested compiling with MSVC 6.0, not running the result.

Note that I also modified the source a little to help with compiling. Some simple edits were paths in include directives. Another was the diffModifier variable was changed to an int, it was initialized to 10 times it's original values, and references to it had a "/10" added to it. That gets rid of the reliance on floating point (and extra runtime library support, which was causing link issues), and also removes the need for the pragma to disable the warnings. I believe the results should be the same, but I haven't done any runtime tests to verify. It's entirely possible I've changed behavior there due to rounding, or maybe an accidental order of operation change.

Thanks Hooman.  You're the greatest!!!

I did finally get a successful build using your project.  

Running VC2008 Express I still had to substitute "#include <windows.h>" for "#include <afxres.h>"  which again resulted in the long list of "LNK2019: unresolved external symbol " errors.  Then I suddenly thought to check the 'Configuration Properties > Linker > Input' properties that AmIMeYet (in his tutorial) said had to be changed to make older projects work in VC 2008...  And sure enough,  there was no "..\lib\op2.lib" in the 'Additional Dependencies' box.  I added that and the project compiled with no errors!

 I briefly tried the resulting .dll and it did run.  I'm going to try some minor tweaks and then do some more extensive testing and will post again after that.

[elwood_s]

You should PM Arklon.  I think he figured out how to get it working.

Thanks for the suggestion.   Maybe I can talk him into letting me use some of his source code.

I'd like to have a version of this game where on normal it's considerably easier to get some defenses up in time to meet the combined sticky/starflare waves, while at the same time it's a lot harder to destroy the A-lab. I think his AI with the dual-turret lynxes goes a long way towards achieving the second (and more difficult) part of my goal.

[elwood_s]

Note that I also modified the source a little to help with compiling. Some simple edits were paths in include directives. Another was the diffModifier variable was changed to an int, it was initialized to 10 times it's original values, and references to it had a "/10" added to it. That gets rid of the reliance on floating point (and extra runtime library support, which was causing link issues), and also removes the need for the pragma to disable the warnings. I believe the results should be the same, but I haven't done any runtime tests to verify. It's entirely possible I've changed behavior there due to rounding, or maybe an accidental order of operation change.

I've now had some time to test the "Plymouth Cold War" built from the project and source code that you were kind enough to place in the SVN last week.  I appears that the changes you made affected at least one thing, because I played the normal level past mark 300 and the AI was still only sending single micro-lynx attack waves.  When playing the original P.C.W. on normal, the AI's first starflare always seems to show up around mark 150. I suspect that the cause is in the following section; that "/10" might need to be added to the end of each of the "if" and "else if" conditions.

Code: [Select]

// Check the count and increase the AI strength as needed
    if (saveData.aiCount == 10 * saveData.diffMultiplier)
    {
        // Starflare time
        saveData.aiMassGrp.SetTargCount(curType, mapStarflare, 3 - saveData.diffMultiplier * 15 / 10);
    }
    else if (saveData.aiCount == 20 * saveData.diffMultiplier)
    {
        // Stickyfoam time
        saveData.aiMassGrp.SetTargCount(curType, mapStickyfoam, 3 - saveData.diffMultiplier * 15 / 10);
    }
    else if (saveData.aiCount == 30 * saveData.diffMultiplier)
    {
        // EMP time
        saveData.aiMassGrp.SetTargCount(curType, mapEMP, 3 - saveData.diffMultiplier * 15 / 10);
    }
    else if (saveData.aiCount == 45 * saveData.diffMultiplier)
    {
        // RPG time
        saveData.aiMassGrp.SetTargCount(curType, mapRPG, 3 - saveData.diffMultiplier * 15 / 10);
    }
    else if (saveData.aiCount == 70 * saveData.diffMultiplier)
    {
        // ESG time
        saveData.aiMassGrp.SetTargCount(curType, mapESG, 3 - saveData.diffMultiplier * 15 / 10);
    }
    else if (saveData.aiCount == 75 * saveData.diffMultiplier)
    {
        // Nova time
        saveData.aiMassGrp.SetTargCount(curType, mapSupernova, 3 - saveData.diffMultiplier * 15 / 10);
    }

If my guess is right, I suppose the AI will start producing starflares around mark 1500, but I'm not willing to play that long just to find out.

On the plus side, I learned enough tinkering around with your project that I was able to fix the project I'd created earlier (from BlackBox's original source), it compiled with no errors and when played the starflares show up right on time.  So now I'm trying adjustments to that.   When I have something that I think is worth playing,  I'll start a new thread and upload the .dll so that anyone who's interested can try it.

Thank you again for all your help.

[Hooman]

Hmm, quite right. I missed a few. Well, maybe I'll fix them if I have time, unless someone else beats me to it. There seem to be a few more than just those if statements though.