[Advanced Question] getting a pointer to a vessel child-class - possible?

[jedidia]

Well, for some reason it never returned true... I had that line pretty much te way you wrote it.

However, I'm doing it with dynamic cast now, which works. There's just one slight problem...
UMMUSDK seems to duplicate VESSEL::Version. I can't call version on a vessel without the linker spitting out errors related to UMMUsdk. So it looks like I can't check the version. May god have mercy on the poor soul that ever tries to attempt to dock a genuine first-generation vessel

I think they should be rare enough by now to not be much of a problem.

Just in case anyone's interested in the linker errors:

UMmuSDK.lib(UMmuSDK.obj) : error LNK2005: "public: int __thiscall VESSEL::Version(void)const " (?Version@VESSEL@@QBEHXZ) already defined in orbiter.lib(Orbiter.exe)
UMmuSDK.lib(universal_mmu.obj) : error LNK2005: "public: int __thiscall VESSEL::Version(void)const " (?Version@VESSEL@@QBEHXZ) already defined in orbiter.lib(Orbiter.exe)

[orb]

Quote:

Originally Posted by jedidia

 I had that line pretty much te way you wrote it.

...Just without the closing parenthesis after "Version () >= 2" and before "&&", which was a copy paste error from shortcutting a couple of ifs into one.

[jedidia]

Ah yes, I did notice that one. Since I had to throw out the version check just to build the thing.

[jedidia]

Oh great, of course standard config-created vessels are not VESSEL2

Meaning, currently I get a crash when I dock one of them, and since the modules from which these ships are built are usually config file created, that is not good (extreme understatement).

So I need to get that version checking to run, and I need UMMUsdk in the project. Both together currently don't work at all, as mentioned before. I get the following Linker errors when trying:

	if (vessel->Version() >= 2)

UMmuSDK.lib(UMmuSDK.obj) : error LNK2005: "public: int __thiscall VESSEL::Version(void)const " (?Version@VESSEL@@QBEHXZ) already defined in orbiter.lib(Orbiter.exe)
UMmuSDK.lib(universal_mmu.obj) : error LNK2005: "public: int __thiscall VESSEL::Version(void)const " (?Version@VESSEL@@QBEHXZ) already defined in orbiter.lib(Orbiter.exe)

I tried reading up a bit and solving the problem on my own, but the only advice I came up with in the end is "to reverse the loading order of the libraries". Thing is, I don't even know how to do that, as the libs are just added to my project explorer, and I can't seem to adjust their order.

---------- Post added at 06:37 PM ---------- Previous post was at 04:43 PM ----------

I found a short thread on DanStephs forum where someone had a very similar problem. The answer was that orbiter.lib was called twice. Now, if I was any smarter, I would maybe even know what that exactly means and how to avoid it. I tried shifting around the includes in the headers, but al with more or less catastrophic results

[orb]

Quote:

Originally Posted by jedidia

 

UMmuSDK.lib(UMmuSDK.obj) : error LNK2005: "public: int __thiscall VESSEL::Version(void)const " (?Version@VESSEL@@QBEHXZ) already defined in orbiter.lib(Orbiter.exe)
UMmuSDK.lib(universal_mmu.obj) : error LNK2005: "public: int __thiscall VESSEL::Version(void)const " (?Version@VESSEL@@QBEHXZ) already defined in orbiter.lib(Orbiter.exe)

Change in the project properties "Configuration Properties > C/C++ > Optimization > Whole Program Optimization" to "No". This works for me. UMmuSDK.lib apparently doesn't like link-time code generation.

And it's a whole way better to move UMmuSDK.lib (similarly OrbiterSoundSDK35.lib, if you use it) to the OrbiterSDK's "lib" folder and include it as additional linker dependency, than include it as a part of your project, as also UMmuSDK.h (similarly OrbiterSoundSDK35.h, MfdSoundSDK35.h for OrbiterSound), which you move to the "include" folder and remove from the project file list (and then you don't use relative paths, but plain file names).

[jedidia]

*sigh* no joy. Optimisation wasn't even enabled to begin with.

I heeded your other suggestions, but with the same result. It's interesting to notice, though, that the error goes both ways: If orbiter.lib is loaded first, I get the above error. If ummusdk is loaded first, I get the message inversed, I.E. orbiter.lib complaining about ummusdk.lib...

Did I mention that I hate compilers?

---------- Post added at 09:02 AM ---------- Previous post was at 08:23 AM ----------

I cleaned up all my include paths. Both orbitersdk.h and ummusdk.h are only included in one header file now, , without affecting the result.

What strikes as very weird, though, is that I can completely remove ummusdk from the additional dependencies list and the error still persists. I.E. he seems to be linking it although it isn't mentioned anywhere in the project settings.

Removing orbiter.lib from the additional dependencies, though, results in major mayhem, and the two are located in the same directory...

[Face]

Quote:

Originally Posted by jedidia

 What strikes as very weird, though, is that I can completely remove ummusdk from the additional dependencies list and the error still persists. I.E. he seems to be linking it although it isn't mentioned anywhere in the project settings.

Removing orbiter.lib from the additional dependencies, though, results in major mayhem, and the two are located in the same directory...

This is because Dan used a compiler directive in the ummusdk headers:

PHP Code:

#pragma comment(lib,"UMmuSDK.lib") 


According to MSDN, this directive causes the linker to load the referenced library: http://support.microsoft.com/kb/153901

Maybe you can remove this line, so the linker is not doing something you didn't specify?

regards,
Face

[orb]

Can you check if UMmu_ShuttlePB_Example throws the same linker errors after you add to it version checking of some vessel object, e.g.:

VESSEL * vessel = oapiGetVesselInterface (vesselObject);
if (vessel->Version () >= 2) {/* either do something or nothing */}

This is what I checked, and it linked just fine, until I enabled "Whole Program Optimization". Then it threw your errors for me. But first I changed the project to use Orbiter property sheets, instead of all parameters defined in the project file, and removed all UMmuSDK files from project explorer.

The version of Visual Studio may be important, too. I have Visual C++ Express 2005, 2008 and 2010, and the appropriate version of it opens for loading solution when I open the solution file (from Explorer / FAR manager), so it opened VC++ Express 2005 for UMmu_ShuttlePB_Example for me.

[jedidia]

Quote:

Maybe you can remove this line, so the linker is not doing something you didn't specify?

Well, that explains why I could completely remove all references to UMMUsdk.lib from the project and still having it load. Removing the line produces the expected linker errors until I add the lib to the additional dependencies, but alas that doesn't fix the other problem, no matter what loading order.

Quote:

The version of Visual Studio may be important, too. I have Visual C++ Express 2005, 2008 and 2010, and the appropriate version of it opens for loading solution when I open the solution file (from Explorer / FAR manager), so it opened VC++ Express 2005 for UMmu_ShuttlePB_Example for me.

I did what you recommended (VS 2008 here), and it works without any trouble in the ShuttlePB example. I even added another cpp file which includes ShuttlePB.h just to make sure that it still works if the header is referenced multiple times in the project, and still no problems. Now I seriously don't know what to do. It seems obvious that the problem originates from some compiler option somewhere, but how to find it? Especially if you don't know what half of them mean...

---------- Post added at 01:25 PM ---------- Previous post was at 01:07 PM ----------

CORRECTION: UMMUShuttlePB does produce the error, but only in debug mode. IMS fails in both debug and release mode. Definitaley an unfriendly compiler option somewhere...

---------- Post added at 04:14 PM ---------- Previous post was at 01:25 PM ----------

Phew, got it working finally after playing around with compiler options for hours, comparing them to the shuttlePB example. It started working when I set optimization to maximise speed... wtf?

[orb]

Quote:

Originally Posted by jedidia

 It started working when I set optimization to maximise speed... wtf?

This option shouldn't matter. I have it set to optimize for size in the ShuttlePB UMmu example, and it's linking fine. Maybe you also changed something else at that time.

[jedidia]

change it to disabled

[orb]

Quote:

Originally Posted by jedidia

 change it to disabled

Never! I always optimize for size.