OHM BaseSyncMFD 3.3 for Orbiter 2016

[Enjo]

The MM / MMExt curse happens to everybody...

 

[ADSWNJ]

126 = MMExt, for sure.

However - I'm recompiling all my addons now, so standby for new clean O2016 versions shortly. I'll break people a different way after that (VC2015 runtimes ).

 

[dbeachy1]

However - I'm recompiling all my addons now, so standby for new clean O2016 versions shortly. I'll break people a different way after that (VC2015 runtimes ).

BTW, if you rather, you can link your add-ons statically with the Visual Studio runtimes (this is done in Visual Studio settings with Configuration Properties -> C/C++ -> Code Generation -> Runtime Library = Multi-threaded (/MT) instead of its default Multi-threaded DLL (/MD) setting). That way your add-ons will "just work" without each user having to manually install the VS 2015 redistributables. :tiphat:

 

[ADSWNJ]

I could... but I feel that it's bad form to do that. Redists should be free to be patched at any time, IMHO.

 

[Wolf]

I have a similar problem with LaunchMFD. Installed v.1.6.4-2010 and got an error message saying "VesselHooking.dll is missing".

Is the solution here: http://www.orbiter-forum.com/showthread.php?t=31624

or simply v1.6.4. does not work with Orbiter 2016?

PS Sorry if this is out of topic

 

[ADSWNJ]

Download and install HUDDrawer SDK v0.3 to fix VesselHooking DLL missing. This library allows Launch MFD to draw on the HUD.

By the way ... when you download MFD's like Launch MFD, take a moment to read the pre-requisites in the description, or check out "Compatible SDK's". Compatible SDK's is actually badly named ... as it really means MANDATORY PRE-REQUISITES THAT MUST BE INSTALLED IF YOU WANT THIS TO WORK

 

[Enjo]

or simply v1.6.4. does not work with Orbiter 2016?

For now use the Beta 55 versions:
http://www.enderspace.de/orbiter/addons-beta/

 

[JonnyBGoode]

I just added it to my install, activated the module, then started a scenario, went to the MFD window, pressed SEL to select it, and it doesn't appear as a selection!

 

[Enjo]

I just added it to my install, activated the module, then started a scenario, went to the MFD window, pressed SEL to select it, and it doesn't appear as a selection!

... and all that because I forgot to install [ame="http://orbithangar.com/searchid.php?ID=6966"]ModuleMessagingExt for Orbiter 2016[/ame] ! :lol:

 

[JonnyBGoode]

Doh!:facepalm:

---------- Post added at 12:14 AM ---------- Previous post was at 12:07 AM ----------

Edit: Nope, still didn't work...

 

[Enjo]

Then you might be missing Visual Studio C++ 2015 redistributable. Choose the x86 one.

 

[JonnyBGoode]

I added the 64 bit one; I'll try the other.

---------- Post added at 08:59 AM ---------- Previous post was at 08:55 AM ----------

That did it. Thx.

 

[ADSWNJ]

I added the 64 bit one; I'll try the other.

---------- Post added at 08:59 AM ---------- Previous post was at 08:55 AM ----------

That did it. Thx.

Annoying, isn't it? IMHO, the 64bit redists should always install the 32bit ones as well (i.e. superset install).

 

[ADSWNJ]

New release for Orbiter 2016. Enjoy!

 

[boogabooga]

Wait, I'm confused.

I've had "BaseSyncMFD for Orbiter 2016 v3.0" installed since Sept. 1.

What exactly got updated today? Why does it not have a different version number?

 

[ADSWNJ]

Wait, I'm confused.

I've had "BaseSyncMFD for Orbiter 2016 v3.0" installed since Sept. 1.

What exactly got updated today? Why does it not have a different version number?

Exact same code, just relinked against the final Orbiter 2016 libraries. Should be identical, but just in case..

 

[boogabooga]

I would still perhaps recommend a different version number. (Say 3.1 or 3.0.1 or something)

If there IS an issue, it will get very confusing if there are two different versions of 3.0 floating around.

 

[ADSWNJ]

Will do

---------- Post added at 12:40 AM ---------- Previous post was at 12:12 AM ----------

OK - version bumped up to 3.1. Also in this release: the getting of the Glideslope TGT is now referenced as GS instead of GS2. (Although if you type GS2 out of habit, it'll still work!)

 

[Enjo]

I don't remember where the discussion was started, but I'll give you another reason for statically compiling the runtimes:
It's now perfectly possible to run Orbiter under Wine. It's also very to install any VC runtimes, but there's a problem: the debian-stable branch is always a bit lagging, and currently doesn't support the latest stable version of Wine, where it's equally easy to install VC2015 runtimes. The previous stable version of Wine allows to install up to VC2013 runtimes, therefore you're locking many Debian-stable (and its sub-brands) users from your addons. And it's a shame after all the work you put into them, I must say.

 

[ADSWNJ]

I don't remember where the discussion was started, but I'll give you another reason for statically compiling the runtimes:
It's now perfectly possible to run Orbiter under Wine. It's also very to install any VC runtimes, but there's a problem: the debian-stable branch is always a bit lagging, and currently doesn't support the latest stable version of Wine, where it's equally easy to install VC2015 runtimes. The previous stable version of Wine allows to install up to VC2013 runtimes, therefore you're locking many Debian-stable (and its sub-brands) users from your addons. And it's a shame after all the work you put into them, I must say.

Try that again?

Are you saying that you cannot install a VC2015 redist to this mutant environment, but if I statically link it, you are fine?

What does the orbiter dev comumity think to static linking. I know dbeachy is a fan. I can do it of course, but I always felt it was wrong to give a user a runtime they cannot update. But if it's in a specific use-case (i.e. Orbiter) versus a general use-case (e.g. supporting web e-commerce), then maybe the risk is lower?




EDIT: for the Wine users - give this static linked version a go and let me know if this fixes things. (unload it into Modules/Plugin as usual).