[Problem] Glideslope MFD

[AA737PILOT]

I have loaded the new Glideslope MFD into Orbiter 2016 and selected it in the modules list but it is not a selectable mfd when in a scenario. Any ideas?

[Face]

Quote:

Originally Posted by AA737PILOT

 I have loaded the new Glideslope MFD into Orbiter 2016 and selected it in the modules list but it is not a selectable mfd when in a scenario. Any ideas?

Check the orbiter.log for module loading error codes.

[AA737PILOT]

here is my orbiter log for the MFD's not loaded. I am lost other than trying to lo============================ ERROR: ===========================
Failed loading module Modules\Plugin\BurnTimeMFD.dll (code 126)
[Orbiter::LoadModule | .\Orbiter.cpp | 600]
================================================== =============
============================ ERROR: ===========================
Failed loading module Modules\Plugin\Glideslope.dll (code 126)
[Orbiter::LoadModule | .\Orbiter.cpp | 600]ad a clean copy of orbiter. any ideas?

[Face]

Quote:

Originally Posted by AA737PILOT

 here is my orbiter log for the MFD's not loaded. I am lost other than trying to lo============================ ERROR: ===========================
Failed loading module Modules\Plugin\BurnTimeMFD.dll (code 126)
[Orbiter::LoadModule | .\Orbiter.cpp | 600]
================================================== =============
============================ ERROR: ===========================
Failed loading module Modules\Plugin\Glideslope.dll (code 126)
[Orbiter::LoadModule | .\Orbiter.cpp | 600]ad a clean copy of orbiter. any ideas?

Sounds like you are missing the necessary middle-ware called ModuleMessagingExt, or its mandatory prerequisite VS2015 redist.

[AA737PILOT]

That did it! Thanks a lot!

[Face]

Quote:

Originally Posted by AA737PILOT

 That did it! Thanks a lot!

You're welcome.
You were not the first with this problem, though. Unfortunately, it seems like many of the MFDs using this middle-ware don't document the need for its separate installation prominent enough.

[ADSWNJ]

Quote:

Originally Posted by Face

 You're welcome.
You were not the first with this problem, though. Unfortunately, it seems like many of the MFDs using this middle-ware don't document the need for its separate installation prominent enough.

A simple fix would be to update the OrbitHangar phrase "Compatible SDKs:" to read "Mandatory Pre-Requisites:", so it's much more prominent in the boilerplate rather than in the text. But yeah - I can also annotate the description to be more clear on this dependency!

[Face]

Quote:

Originally Posted by ADSWNJ

 A simple fix would be to update the OrbitHangar phrase "Compatible SDKs:" to read "Mandatory Pre-Requisites:", so it's much more prominent in the boilerplate rather than in the text. But yeah - I can also annotate the description to be more clear on this dependency!

Changing the phrase would make it confusing for those using other SDKs that are not so strictly linked.

E.g. using OrbiterSound SDK doesn't make an addon crash if the proper middle-ware is not present. Instead it uses late-binding techniques together with static linking of the thin forwarder-lib to decouple the addon from the middle-ware. If the later is not present, some features don't work, but the addon is still usable. IMHO this is a much better approach for middle-ware concepts, especially if the distribution isn't easily done "atomic" due to versioning problems ("Don't distribute the middle-ware with your addon, because that way the user has to get it from the original author and thus benefits from fixes/patches/extensions.").

Instead of changing the phrase I'd suggest to add a new field with the text you proposed.