Jump to content
COMBATSIM Forum
mikew

The Combat Simulator Project

Recommended Posts

Every now and again I look at this with a slightly better knowledge of software development each time. Unfortunately not much has happened in the last 10 years, but I still think that this is still an impressive open source effort which compiles (with a plethora of warnings) and runs today.

cspsim.png.6d24836ddba3eb205716ed8e54eb974b.png

In the demo build, the F16 on the right will take off, fly around between some waypoints and land back at the single airbase in the scenario. The player can do whatever they want in the other plane but unfortunately there is not much implemented on the combat side.

 

The code is reasonably well documented and running Doxygen on it produces a fairly detailed top-level map.

csp_doxy.png.d8ed767eb646322cb7a8748d1ad5c196.png

 

While right now it compiles with GCC on Linux, i'm not sure what will happen with the Windows compiler. It worked 10 years ago, but I suspect it won't now.

So, today's fun task will be to assemble the Windows dependencies which I'm sure will end in total frustration. :(

 

Some parts of this may be useful for TFXplorer as there are some Python world building tools that may be reused or at least provide some inspiration.

 

A link to the code:

https://github.com/nsmoooose/csp

 

 

Share this post


Link to post
Share on other sites

On second thoughts, I'll first try to use some 10 year old pre-built binaries. I'm not so worried if the build fails as the initial goal is to get the SCons build system working.

 

The original CSP documentation was hosted on Sourceforge, but seems to have now disappeared and probably only accessible by Google,Facebook, the 3 letter agencies and evil foreign governments. I scraped what I could from the 'Wayback machine' at archive.org and put it here, together with the installer for the 0.6.2 version of the CSPDEVPACK (containing the aforementioned Windows binaries) and a 0.7 version of its files:

https://app.box.com/s/z3ym9xcwkufcnhvcxt3hho0x5tpsbt27

 

Share this post


Link to post
Share on other sites

Quite impressive … I’ll have a look at the code! If there are problems with building the Windows version, feel free to ask me …

Share this post


Link to post
Share on other sites
25 minutes ago, Krycztij said:

Quite impressive … I’ll have a look at the code!

It is, but I suspect you'd go about things a bit differently. :D

 

26 minutes ago, Krycztij said:

If there are problems with building the Windows version, feel free to ask me …

Thanks! although I'll ask the owner of the above github account first.

 

I haven't compiled it on this Win7 machine before, so am already running into 'path' problems where SCons can't find some Windows libraries. I think in the olden days, there was a 'Platform SDK' but now most of that stuff is included in the Community version of VS2017...or something like that.

 

Share this post


Link to post
Share on other sites
13 minutes ago, mikew said:

I think in the olden days, there was a 'Platform SDK' but now most of that stuff is included in the Community version of VS2017...or something like that.

 

Yes. The DirectX SDK and the Platform SDK have been merged into the Windows SDK. This is installed with Visual Studio, and you find it under C:\Program Files (x86)\Windows Kits\<version number>. The version number is just important for the feature set and does not define a requirement for the final executable – if you choose the 10.0 SDK but don’t call Windows 10/8/7-specific APIs, it will run on Windows Vista as well.

Share this post


Link to post
Share on other sites

Thanks! My path is a bit different, but on this machine I added 'c:\program (x86)\microsoft sdks\windows\v7.1a\lib' to both the User and System 'path' parameters in the Environment Variables and restarted the terminal, but SCons doesn't find the libs it checks in the config phase. I've obviously missed some simple step.

SCons is written in Python, so it should be straightforward to find out what it's looking for, but a bit soul destroying to be having to put so much effort into some environment pre-check. :(

Doesn't bode well for actually building the project. :)

Share this post


Link to post
Share on other sites

That solved it!

I should have remembered that, but it's been years since I tried anything like this.

 

Anyway, I think the environment is OK now and we get the first proper error...and immediately:

scons: Building targets ...
cl /Focsplib\.bin\data\Archive.obj /c csplib\data\Archive.cpp /GR /MD /O2 /EHsc /W3 /nologo /wd4251 /wd4275 /wd4290 /DWIN32 /D__WIN32__ /D_USRDLL /D_DLL /DNDEBUG /D_CRT_SECURE_NO_DEPRECATE /D_USE_MATH_DEFINES /DCSPLIB_EXPORTS /ID:\dev_csp\csp-git /IC:\Python27\include "/IC:\Program Files (x86)\cspdevpack-0.6.2\include\AL" "/IC:\Program Files (x86)\cspdevpack-0.6.2\include"
Archive.cpp
D:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.11.25503\include\hash_map(16): fatal error C1189: #error:  <hash_map> is deprecated and will be REMOVED. Please use <unordered_map>. You can define _SILENCE_STDEXT_HASH_DEPRECATION_WARNINGS to acknowledge that you have received this warning.
scons: building terminated because of errors.

 

That'll do for now. I'll raise a ticket.

Share this post


Link to post
Share on other sites

Why oh why do I get this error from the linker?

csplib\.bin\csplib.dll.manifest : general error c1010070: Failed to load and parse the manifest.

Well, it's not there, although the dll has been built. I have no idea what a manifest file is, so it can't be important. :)

 

Based on 'something I read on the internet', I added a /MANIFEST:NO switch, so the command starts like this:

link /dll /INCREMENTAL:NO /RELEASE /MANIFEST:NO /nologo /out:csplib\.bin\csplib.dll /implib:csplib\.bin\csplib.lib /LIBPATH:C:\Python....etc etc

...but I still get the error

Share this post


Link to post
Share on other sites

I see a manifest file was generated when I ran this back in the VS2008 (or maybe VS2010) days, so I should try to generate one to keep it happy.

There is apparently a manifest tool (mt.exe) that is used to generate it and it is probably not being invoked by SCons for some reason. I'll look into it later.

 

By the way, there were a lot of compiler errors which needed to be fixed before getting to the linker stage. In every case, I could just paste the long error string into a search engine and get the answer from MSDN or Stackoverflow so I feel like a true professional software developer. :D

Invarariably, the solution was to remove 'something' that was needed to be done for the MS compiler, since that 'something' is now illegal.

Share this post


Link to post
Share on other sites

Yes, they have worked hard towards standard compliance and finally reached it in the first half of 2018. There are some switches for backwards compatibility, but honestly it is far better to delete the old MS-specific cr*p :) You’re doing great!

Share this post


Link to post
Share on other sites

Thanks! The manifest thing was solved by just specifying /MANIFEST. According to MS, that's the default option and shouldn't be needed, but whatever...

After some more code fixes we come to build the next dll, but disaster strikes:

fatal error LNK1120: 1 unresolved externals

 

The culprit is one of the external dependencies that I've been too scared and lazy to rebuild with VS2017. I'll start with libsigc++ tomorrow.

https://github.com/libsigcplusplus/libsigcplusplus

Share this post


Link to post
Share on other sites

...Well, not quite tomorrow as it took a while to drum up some enthusiasm to tackle the dependency hell (starting with libsigc++), but a problem straight away:

I'm using the 'x86 Native Tools Command Prompt for VS 2017', but my .lib file is emerging in x64 format. How is that possible?

Share this post


Link to post
Share on other sites

It's possible because I was using SCons and not the compiler commands directly, and that defaulted to x64.

In my defense, I was having a traumatic saturday evening with libsig++ where I tried the latest version first. This came ready to go on VS2017 just needing to run a nmake command, hence the 'x86 VS2017 Command Prompt'. Even in administrator mode, it would not generate the libraries until I manually created the destination folders.

Anyway, that version of the library was too new,  as it turns out the API had changed in the last year or so, so had to download an earlier version.

This came with a VS2008 .sln file, which VS2017 happily converted so it was just a case of pressing 'Build'...except that it complained about missing source files. WTF?

Turns out that I needed to run some Unix Autoconf commands first to generate some source files from .m4.

So, installed Cygwin which I'm sure would have worked if it acknowledged that automake was a valid command. That component was installed, but it wouldn't have it.

Anyway, my LInux PC to the rescue. Just download the package, ./configure and copy the resulting files back to the Windows PC.

Building the libraries was then fairly straightforward using SCons, and I just needed to set its environment to x86.

 

Armed with my fresh x86 VS2017 .lib file, the main project build continued another minute or so until another linker error:

Terrain.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: void __thiscall std::basic_ofstream<char,struct std::char_traits<char> >::`vbase destructor'(void)" (__imp_??_D?$basic_ofstream@DU?$char_traits@D@std@@@std@@QAEXXZ) referenced in function "void __cdecl `dynamic atexit destructor for 'm_Logfile''(void)" (??__Fm_Logfile@@YAXXZ) etc etc.

 

The internet seems to think that this is a Windows library problem and suggests setting /VERBOSE in the Linker commands to find out why. I've done that and have a 62MB text file to plough through, so I might be gone some time...

 

I'll never become a brogrammer at facebook with my own cubicle at this rate. :D

Share this post


Link to post
Share on other sites

The reason I didn’t answer is that I don’t know what to do either. nmake configure script hell with unresolved externals is exactly the reason why I never compile any projects from the internet.

 

basic_ofstream is the wrapper for standard output streams like stdout and stderr. If the linker cannot find them, then I’m pretty sure it’s because of the Visual C++ Runtime Library. If not in the IDE, it is controlled via these switches but the documentation must be the worst I’ve ever seen, so let me take an educated guess here:

  1. Either the module itself or one of the dependent library projects looks for basic_ofstream but doesn’t find it.
  2. basic_ofstream is in the Visual C++ Runtime (CRT).
  3. If your program looks for this symbol at link time, that means that somewhere, something is linked statically to the CRT (/MT or /MTd switch).
  4. If the linker does not find this symbol, that means that you are linking dynamically (/MD or /MDd switch).
  5. You are mixing up static and dynamic linking in one of your dependencies. This is a pretty hard error and I’m afraid I don’t know any easy way to solve it.
  6. I would start looking for the /MT or /MTd switch in all dependent projects and, if found, check for a version of the project with dynamic linking instead (which is the default for new projects).
  7. Wait, no! The error says it can’t find the __declspec(dllimport) version of the function.
  8. So you are probably already compiling against the dynamic CRT, but missing its import library.
  9. Check if you are linking libvcruntime.lib and libucrt.lib (or, in Debug builds, libvcruntimed.lib and libucrtd.lib). Visual C++ does link those by default, but it opts out under some rare circumstances (like custom entry points or the /nodefaultlibrary switch).
  10. Sorry for your experiencing the darkest side of C/C++.

Share this post


Link to post
Share on other sites
2 hours ago, Krycztij said:

....is exactly the reason why I never compile any projects from the internet.

Yes, I admire the purity of TFXplorer. Sorry to drag you into this filth, but I'm trying to keep things to general C++ problems rather than specifics of the project.

In a way, I'm sort of enjoying this. :)

 

Anyway, from the linker /VERBOSE output, the libs you mention look they have been 'disallowed':

Processed /DEFAULTLIB:vcruntime.lib
Processed /DISALLOWLIB:libvcruntime.lib
Processed /DEFAULTLIB:ucrt.lib
Processed /DISALLOWLIB:libucrt.lib

...but that fits in with the /MD switch I'm using.

 

I'll see if I can find out where that is defined..and currently reading this:

https://docs.microsoft.com/en-us/previous-versions/abx4dbyh(v=vs.140)

 

The only odd thing that stands out is that these libraries are searched for in different places:

    Searching D:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.11.25503\lib\x86\vcruntime.lib:
    Searching C:\Program Files (x86)\Windows Kits\10\lib\10.0.15063.0\ucrt\x86\ucrt.lib:

Those seem to be the latest versions I have on this PC though.

 

Now I'm wondering if this is an artifact of something upstream in the compile phase.

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×