Problem Update MFD to Orbiter 2016

[Mythos]

I tried to update my MFD to Orbiter 2016 and struggle. Orber (no mods, just D3D9Client2016-R1) just crashes when loading any scene with my module activated.

Of course I used the new SDK paths to compile. My first thought was to update to newer IDE version also, but I was not in the need and canceled that idea. I managed to break down to a version that is running, just having a return early in critical methods.

The running version displays the title, button labels and even reacts to pressed buttons.

It crashes when I uncomment one of following lines:

bool HoverMFD::Update (oapi::Sketchpad *skp)
{
  Title (skp, "Hover MFD 1.1.1 2016");
  // taken from MFDTemplate for testing:
  skp->SetFont (font1);
  skp->SetTextAlign (oapi::Sketchpad::CENTER, 
    oapi::Sketchpad::BASELINE);
  skp->SetTextColor (0x00FFFF);
  skp->Text (W/2, H/2,"Display area", 12); // CRASH HERE
  // commented all the rest anyway
}

I looked up the new MFDTemplate if there's something new, but there isn't.
Maybe I'm the only one that thinks writing text is essential...

DLLCLBK void InitModule (HINSTANCE hDLL)
{
  static char *name = "HoverMFD";
  MFDMODESPECEX spec;
  spec.name = name;
  spec.key = OAPI_KEY_T;
  spec.context = NULL;
  spec.msgproc = HoverMFD::MsgProc;
  g_MFDmode = oapiRegisterMFDMode (spec);
  g_HoverModule = new HoverModule(hDLL);
  oapiRegisterModule(g_HoverModule); // CRASH HERE
}

This one even crashes when my HoverModule (class HoverModule : public oapi::Module) is really doing NOTHING AT ALL! So I skipped this line for all other tests.

What's going on here?

I felt very happy noticing great news about Orbiter but that stops my excitement right away

---------- Post added at 23:03 ---------- Previous post was at 04:22 ----------

Still don't know what was going on, but solved the problem like this, maybe someone needs to reproduce:
- opened MFDTemplate from new Orbiter 2016 SDK
- tested that this does work
- extended to use described no-content-module, tested successfully
- understood property sheets at last
- copied MFDTemplate and property sheets to my usual projects folder
- fixed solution to match new path for property sheets
- renamed folder, solution and project to HoverMFD (file and text content)
- put all my old .cpp and .h files in and added to project
- compiled and tested

So I somehow made the project to match a clean fresh start on new version but kept the old content.

Now I used property sheets correctly, as far as I read this will make installing 2008 redist unneccessary?

Then again thought about upgrading to newer IDE, but realized .vsprops files are not supported in modern vstudio, files need to be .props. Tried migrating the new built project WITH vsprops so vstudio should convert them. But I got errors about some (?) properties not being supported and decided to not have the time to dig in.

I will now need to do some adjustments:
- drawing rectangles does not work or works differently
- altitude reading below zero at Brighton Beach
- test and maybe think about ground elevation stuff

 

[turtle91]

This would be really nice to have this great,helpfull and extreme precise MFD in Orbiter2016.
Just imaging to travel on a moon from base to base while watching the new 3D scenery.:yes:

So many thanks for for further developing HoverMFD. :hail:
Btw...I have successfully re-compiled some MFD's for Orbiter2016 and still using MS VS 2010.
When doing re-compiling, I allways create a new/empty SLN...just in case.
So I copy all the C-files and the headers to a (out-of-Orbiter) project folder and start with a new SLN from there.

 

[ADSWNJ]

Now I used property sheets correctly, as far as I read this will make installing 2008 redist unneccessary?

The property sheets help make the compile & link work smoothly for Orbiter. You should just reference the property sheets in the resources folder.

The redists are unnecessary for you as the developer, of course, as you already have them installed. If you dynamically link the redist, then your users need to ensure they have the redists installed. If you statically link, then your DLL is self-contained.

 

[Mythos]

If you statically link, then your DLL is self-contained.

Is that option set in the shipped property sheets?

 

[boogabooga]

Cheers to Mythos and good luck converting Hover MFD! :thumbup:

 

[ADSWNJ]

Is that option set in the shipped property sheets?

Default is dynamic linking.

 

[Mythos]

Default is dynamic linking.

Hmm well, I will have a look to change that maybe next time. I stayed with Visual C++ 2008. Same requirements as before.

Here's the new version: [ame="http://www.orbithangar.com/searchid.php?ID=6993"]Hover MFD 1.1.2[/ame]

 

[Mythos]

Default is dynamic linking.

This is what I had read:

If you link with the static runtime libraries you won't need users to install the Visual Studio redistributables. That is set by going to Properties -> Configuration Properties -> C/C++ -> Code Generation and setting Runtime Library to "Multi-threaded Debug (/MTd)" for debug builds and "Multi-threaded (/MT)" for release builds. As long as you don't free (delete) a memory block allocated by Orbiter (which you shouldn't do anyway) it should work fine. [XR vessels use static linking.]

In my project the setting is "Multi-threaded DLL (/MD)".

I think its from these lines in Orbiter.vsprops that is used (inherited from "Orbiter plugin.vsprops"):

<Tool
	Name="VCCLCompilerTool"
	AdditionalIncludeDirectories="$(SDKIncludeDir)"
	PreprocessorDefinitions="_CRT_SECURE_NO_WARNINGS"
	RuntimeLibrary="2"
	BufferSecurityCheck="false"
	FloatingPointModel="2"
	WarningLevel="3"
/>

So does it mean this?
Multi-threaded DLL (/MD) = dynamic linking
Multi-threaded (/MT) ) = static linking

 

[Mythos]

So does it mean this?
Multi-threaded DLL (/MD) = dynamic linking
Multi-threaded (/MT) ) = static linking

right or wrong?

 

[martins]

(no mods, just D3D9Client2016-R1)

The single most helpful piece of information would be to know if this also crashes with the inline graphics client.

 

[turtle91]

right or wrong?

From what I have found at google, it seems to be that your statement is "true".
I searched for it, because I have had trouble to use MT, caused by some third-party libs, which does not liked to be compiled staticly. (I guess user error from my side btw...)

 

[Mythos]

The single most helpful piece of information would be to know if this also crashes with the inline graphics client.

Inline graphics client just made a white blank screen, so went straight to D3D instead of looking into video setting (It was a very stupid fault on my side). Now I tried reasonable video settings and was able to run inline graphics also.

About that original problem: I just recomiled for 2016 a new copy of my old 2010 version without my cleanup. I can not reproduce the problem, neither D3D nor inline graphics.

 

[dbeachy1]

So does it mean this?
Multi-threaded DLL (/MD) = dynamic linking
Multi-threaded (/MT) ) = static linking

right or wrong?

That is correct: "Multi-threaded" is static runtime linking, and "Multi-threaded DLL" is dynamic runtime linking. If you use dynamic linking, your users will need to download and install the correct Visual Studio redistributable files if they don't already have them installed.