OHM HUDDrawer SDK v.0.4 for Orbiter 2016

[Ripley]

Ok, it's not the way it's meant to be used, but if you launch a scenario where you have HUDDrawer on an MFD, and another MFD (which doesn't use HUDDrawer), then you click on some of HUDDrawer's buttons, you get a CTD.

Tested in Orbiter2016 (no D3D9)

Example scenario:

BEGIN_DESC
Current scenario state


Contains the latest simulation state.
END_DESC

BEGIN_ENVIRONMENT
  System Sol
  Date MJD 51985.8786267787
  Help CurrentState_img
END_ENVIRONMENT

BEGIN_FOCUS
  Ship GL-01S
END_FOCUS

BEGIN_CAMERA
  TARGET GL-01S
  MODE Cockpit
  FOV 50.00
END_CAMERA

BEGIN_HUD
  TYPE Surface
END_HUD

BEGIN_MFD Left
  TYPE User
  MODE HUDDrawer MFD
END_MFD

BEGIN_MFD Right
  TYPE Orbit
  PROJ Frame
  FRAME Ecliptic
  REF Moon
END_MFD

BEGIN_PANEL
END_PANEL

BEGIN_SHIPS
ISS:ProjectAlpha_ISS
  STATUS Orbiting Earth
  RPOS -1738349.724 -6082020.266 2295543.404
  RVEL -7165.5209 2509.7859 1235.7990
  AROT 171.312 -48.219 11.630
  VROT -0.0407 -0.0241 -0.0278
  AFCMODE 7
  PRPLEVEL 0:1.000000
  IDS 0:588 100 1:586 100 2:584 100 3:582 100 4:580 100
  NAVFREQ 0 0
  XPDR 466
END
Mir:Mir
  STATUS Orbiting Earth
  RPOS -1177641.386 -456532.419 -6574068.567
  RVEL 7563.9390 409.6531 -1415.4154
  AROT -116.491 27.810 61.988
  VROT 0.0854 -0.0089 -0.0172
  AFCMODE 7
  IDS 0:540 100 1:542 100 2:544 100
  XPDR 482
END
Luna-OB1:Wheel
  STATUS Orbiting Moon
  RPOS -1777960.451 -1361304.710 -377.869
  RVEL 899.5292 -1174.8861 -0.1252
  AROT 0.005 0.000 -151.404
  VROT 0.0000 -0.0000 10.0000
  AFCMODE 7
  IDS 0:560 100 1:564 100
  XPDR 494
END
GL-01S:DG-S
  STATUS Orbiting Moon
  RPOS 610595.404 1163964.923 1133179.380
  RVEL -3.0317 -0.0706 1.7157
  AROT 142.923 -18.947 158.068
  RCSMODE 2
  AFCMODE 7
  PRPLEVEL 0:1.000000 1:0.999178 2:0.998512
  THLEVEL 19:0.037669 20:0.037669
  NAVFREQ 486 166 84 114
  XPDR 0
  RCOVER 1.0000 0.0000
  HOVERHOLD 0 1 0.0000e+000 0.0000e+000
  TRIM -0.004220
  GEAR 1.0000 0.0000
  RADIATOR 1.0000 0.0000
  STROBELIGHT 1
  NAVLIGHT 1
  AAP 0:0 0:0 0:0
  PSNGR 2 3 4
  PANELCOL 4
  TANKCONFIG 1
END
SH-03:ShuttleA
  STATUS Landed Earth
  BASE Habana:4
  POS -82.3982414 23.0005396
  HEADING 70.00
  ALT 2.912
  AROT 50.119 -65.937 19.478
  AFCMODE 7
  PRPLEVEL 0:1.000000 1:1.000000
  NAVFREQ 0 0
  XPDR 0
  PODANGLE 0.0000 0.0000
  DOCKSTATE 0 0.0000
  GEAR 0 0.0000
  PAYLOAD MASS 0.0 0
  ATTREF 0 0 0
  ADI_LAYOUT 0
END
PB-01:ShuttlePB
  STATUS Landed Earth
  BASE Habana:1
  POS -82.4000000 22.9994604
  HEADING 22.00
  ALT 1.287
  AROT 62.913 -18.678 7.875
  AFCMODE 7
  PRPLEVEL 0:1.000000
  NAVFREQ 0 0
END
GL-02:DeltaGlider
  STATUS Landed Mars
  BASE Olympus:3
  POS -135.4299995 12.7366186
  HEADING 359.97
  ALT 2.533
  AROT 81.143 -8.838 -45.371
  AFCMODE 7
  PRPLEVEL 0:1.000000 1:1.000000
  NAVFREQ 0 0 0 0
  XPDR 0
  HOVERHOLD 0 1 0.0000e+000 0.0000e+000
  GEAR 1.0000 0.0000
  AAP 0:0 0:0 0:0
END
SH-01:ShuttleA
  STATUS Landed Moon
  BASE Brighton Beach:1
  POS -33.4375000 41.1184067
  HEADING 0.00
  ALT 3.027
  AROT 64.274 33.319 48.978
  AFCMODE 7
  PRPLEVEL 0:1.000000 1:1.000000
  NAVFREQ 0 0
  XPDR 0
  PODANGLE 0.0000 0.0000
  DOCKSTATE 0 0.0000
  GEAR 0 0.0000
  PAYLOAD MASS 0.0 0
  ATTREF 0 0 0
  ADI_LAYOUT 0
END
END_SHIPS

BEGIN_ExtMFD
END

 

[Enjo]

Oh what a rookie mistake. Reuploaded.

 

[turtle91]

I still get CTDs when just opening the HudDrawerMFD.
While HUDdrawer is doing its job(on the HUD), its just the corresponding MFD, which causes the crashes.

Steps to reproduce:

-load "DG-S ready o take off to ISS" or any other default scenario
-open HudDrawerMFD
=no issues
-open another MFD to move HudDrawerMFD out of the picture
-open LaunchMFD
-open again...HudDrawerMFD
=CTD

Same scenario again, but other procedure-order:
-open LaunchMFD
-open HudDrawerMFD
=CTD

So it looks like, that as soon as a MFD has registered into HudDrawer's API, the HudDrawerMFD does not "like" it.

 

[Enjo]

Thanks for the test, but I cannot recreate it. Can anybody else try the procedure?
Are you sure that you installed the right version?

 

[ADSWNJ]

Confirmed reproduction on O2016 with the Sep 11th versions of Hud Drawer 0.4 and LaunchMFD 1.6.4. In one MFD, select HUDDrawer MFD, then select LaunchMFD, then select HUDDrawer again, and you get an unhanded exception (access violation) CTD.

 

[turtle91]

I just realized, that this version does not draw any additional elements on the HUD while using LaunchMFD during its launch.
I am using the 0.4 version for Orbiter2016:
"HUDDrawer.dll ......... [Build 160907, API 160828]"

 

[Ripley]

I launched to the moon yesterday, and indeed it drew some symbols on the HUD.

LaunchMFD.dll ......... [Build 160905, API 160828]
HUDDrawer.dll ......... [Build 160907, API 160828]

 

[turtle91]

Just to the moon ? I launched to Mars...

Ok...I have just run another test, and there seems to be something wrong with the latest HudDrawerMFD/SDK:

-scenario DG-S ready to takeoff to ISS
-LaunchMFD...target Moon
=HUD-Drawer is displaying the additional elements at the HUD :thumbup:

-using same scenario, but the latest XR2
-LaunchMFD...target Moon
=no HUD-Drawer elements there :thumbsdown:

This was working in previous HUD-Drawer version.

Here my combo(so...the same):
Module LaunchMFD.dll ......... [Build 160905, API 160828]
Module HUDDrawer.dll ......... [Build 160907, API 160828]

 

[Enjo]

I think I nailed down the problem. Unfortunately I'm unable to reproduce it under Linux, but it was possible under Windows. The culprit was statically linking the redistributables (or at least libcmt of HUDDrawer). I will keep on researching this during the week...

 

[turtle91]

I have had some problems with static-linking, too. (...and still have...)
I found this, which might help in my case(not tested yet).
Not sure if it's related to your issues:

https://github.com/bin-y/nodefaultlib

 

[ADSWNJ]

The culprit was statically linking the redistributables (or at least libcmt of HUDDrawer).

Oh my God! The static / non-static debate flares back up again! Really looking forward to your analysis of this one.

 

[Enjo]

I couldn't get myself to do it all, because RL is dragging me. For now I uploaded dynamically linked HUDDrawer for 2016, but 2010 still crashes, although I think I rolled everything back... I guess not...
Please test.

---------- Post added 23-09-16 at 08:12 AM ---------- Previous post was 22-09-16 at 02:21 PM ----------

Version for Orbiter 2010 reuploaded. Linux toolchain saved the day.

 

[ADSWNJ]

The question is ... why? What's causing this behavior?

 

[Enjo]

My bet is on libcmt. Believe it or not, but I have no chance to verify it right now... but my wife returns to her job on Monday, so there's a chance that I will have the time

 

[Ripley]

I had some CTDs after opening HudDrawer MFD (O2016, with or without D3D9), came here to post and remembered/realized this has been a long standing issue.

 

[Enjo]

Hi Ripley,

please provide a scenario file or any information that would help me recreate it. I ran the MFD with and without registered modules in it, and had no CTD.

 

[Ripley]

Post #21
https://www.orbiter-forum.com/showthread.php?p=541828&postcount=21

Sorry for late reply.
I'll try to recreate it later, evening time (CET).

 

[Enjo]

Hi Ripley,

Do you remember our discussion about getting rid of the VC++ redist? I believe this is the same problem again. I've tried to link it statically and got two bug reports. I will link it dynamically, will ask you guys to try again... and will never ever think about static linking of that redist.

 

[Ripley]

Ok, try to launch the scenario in post#21, and select LaunchMFD in the right mfd...
Instant CTD, with or without D3D9.

 

[Enjo]

I have no Windows here on vacation to run it. I'll be back in two weeks.