OHM Launch MFD - v. 1.6.6 for Orbiter 2016

[Cras]

Awesome stuff! Can't wait to try this out. Ill let you know how it goes when I do!

 

[Enjo]

I work now some distance from my house, but on the other hand, I rent a room there and as all the basic stuff is made there for me for my money, now I can code like I'm supposed to
So here comes:

v. 1.5.6 23-02-2013
– Direct Ascent is now super precise and fully planet-wise generic and without any magic number coefficients
– Direct Ascent Offplane Corrector - plane overfit prevention and general stability tweaks
– Solved CTD for some machines when no target is selected and user switches to Direct Ascent page (reported by boogabooga)
– Fixed retrograde orbits (reported by boogabooga)
– Added option to setup equatorial target orbit with specific LAN by using additional 'q' character
– Autogenerating config files usage information inside them
– Ability to choose and lock one of azimuths when using a manual target (Shift + U)
– Great Circle – ability to draw GC using lines instead of dots (Shift + L)
– Direct Ascent code cleanups

I urge you to try that new Direct Ascent. If you are able to get your plane under 5-4* Rinc with the target before final insertion, then you'll literally fly throught the target

Unfortunatly, if you've been using the MFD with older ships, you switched between new and old ships and got a CTD, then it's my fault again, or more precisely the HUD drawing's. It's been like this since version 1.5.2 or so. I'll focus on this problem next and I will take very seriously information contained in the Axial Velocity HUD thread. Wish me luck!

 

[IronRain]

I work now some distance from my house, but on the other hand, I rent a room there and as all the basic stuff is made there for me for my money, now I can code like I'm supposed to
So here comes:

v. 1.5.6 23-02-2013
– Direct Ascent is now super precise and fully planet-wise generic and without any magic number coefficients
– Direct Ascent Offplane Corrector - plane overfit prevention and general stability tweaks
– Solved CTD for some machines when no target is selected and user switches to Direct Ascent page (reported by boogabooga)
– Fixed retrograde orbits (reported by boogabooga)
– Added option to setup equatorial target orbit with specific LAN by using additional 'q' character
– Autogenerating config files usage information about inside them
– Ability to choose and lock one of azimuths when using a manual target (Shift + U)
– Great Circle – ability to draw GC using lines instead of dots (Shift + L)
– Direct Ascent code cleanups

I urge you to try that new Direct Ascent. If you are able to get your plane under 5-4* Rinc with the target before final insertion, then you'll literally fly throught the target

Unfortunatly, if you've been using the MFD with older ships, you switched between new and old ships and got a CTD, then it's my fault again, or more precisely the HUD drawing's. It's been like this since version 1.5.2 or so. I'll focus on this problem next and I will take very seriously information contained in the Axial Velocity HUD thread. Wish me luck!

Thank you for your hard work, it is highly appreciated!

 

[Interceptor]

Thanks,Enjo you work is greatly appreciated.:thumbup:

 

[insanity]

Enjo, just tried out the latest stable and it's awesome. Thanks so much for all your continued work on this

 

[garyw]

Just curious here but is it possible to use Launch MFD to plot an ASAT type launch? I.e. one where the missile is launched into a suborbital path opposite the orbit of the satellite?

 

[malisle]

I have a question about launch compass that is usually drawn on the HUD (see pic attached).
.
After updating to a new version of LaunchMFD (after I skipped a few) it is not visible on the HUD of some spacecrafts. For example it works fine for default Atlantis, SpaceX launch vehicles and Dragon, Themis launch vehicle and some other add-ons, but it seems to me that it does not work for multistage.dll based vessels. HUD button in MFD doesn't make it appear. I am using D3D9 R9 client. Problem persists both with and without GDI compatibility. Before, GDI compatibility was needed for the launch compass to work :shrug:

 

[Enjo]

Just curious here but is it possible to use Launch MFD to plot an ASAT type launch? I.e. one where the missile is launched into a suborbital path opposite the orbit of the satellite?

I don't think that this will work for ASAT in the current state. The purpose of DA is intercepting the target with 0 distance and 0 relative velocity, the 2nd of which disqualifies it as an ASAT missle. In fact, the target approaches you from behind when you're just about to reach the orbit. However when you think about it, it's caused by the fact that the target orbit is curcular. The PEG always targets periapsis of the target orbit. If it were elliptic, then the ship would need more energy to reach the periapsis with the set apoapsis, so there would be a chance, that the ship approaches the target from behind. I'll have to try it out later myself, because right now I override any PEG altitude settings when the DA autopilot is on.

After updating to a new version of LaunchMFD (after I skipped a few) it is not visible on the HUD of some spacecrafts. (...) I am using D3D9 R9 client. Problem persists both with and without GDI compatibility. Before, GDI compatibility was needed for the launch compass to work :shrug:

Thre reason why it worked was also a source of potential CTDs, discovered by tutrle91, earlier in this thread. AFAIK multistage2 is based on VESSEL2 class, which originates from 2006 Orbiter interface. In the 2010 version of Launch MFD I had to discontinue support of 2006 vessels because of the CTDs. What should work though, is using Launch MFD 2006 in your Orbiter 2010, with GDI compatibility on. Please let me know if it works.

Unfortunatly, if you've been using the MFD with older ships, you switched between new and old ships and got a CTD, then it's my fault again, or more precisely the HUD drawing's. It's been like this since version 1.5.2 or so. I'll focus on this problem next and I will take very seriously information contained in the Axial Velocity HUD thread. Wish me luck!

Luckly this problem didn't reach the public, only my own setup, where I experiment with two modules that try to draw on HUD. What happened was exactly the situation explained by Wraith. Yesterday evening I've tried to implement the idea presented by Agentgonzo, and it worked! Let me requote the idea:

If you're going to do this, you won't just be able to cut-and-paste this functionality into each MFD. Even if you implemented it as a singleton class and just cut-and-pasted the code into each MFD, they'd get compiled into each MFD DLL as a separate bit of code and you'd end up with 2 or 3 identical implementations of singleton classes that would each try and hook the HUD callback assuming they were the only ones.

You'd need a separate DLL (HUDHook.DLL or something like that) that each of the prospective HUD Hookers would link to and call the one hooking function from that to make sure that there is only one hook object instantiated and only one hooking performed. You'd then include the HUDHook.DLL with every release that used it (though that's not a problem really).

If you're going down the route of one separate library hooking DLL then you'll want to make the exported functions simple and not change. You'll also want to future-proof it, so while you're at it, you may as well add the functionality to hook *any* of the virtual methods of VESSEL2.

In principle it works. I only need to provide the functionality to hook all these virtual methods and this takes valuable time. For a good start I'll begin only with a proper interface for HUD drawing, and make the interface extensible, so that nobody will ever need to make any vessel hookings again, because this leads to the problems described in the Axial Velocity HUD thread.
[EDIT] On the other hand I personally can't imagine any other usage of VESSEL2's virtual table other than for HUD drawing. At least n the last 6 years I haven't seen it...

 

[Leospace]

Hello,
Thanks for the release Launch MFD.

I can't use Direct Ascent with the ship DG IV. The ship seems to be very unstable and fail to intercept the target ISS.

Is there a hope to use Direct Ascent with the ship DG IV ? Thanks for your answer.

 

[Enjo]

[EDIT] I've just tried it. No problems at all. You must be doing something wrong but I need to know what. Is the control of ship's RCS unstable? Is the engine control unstable?

 

[Leospace]

No, it did not work for me.

I watched your Playback scenario number 1 for the ship Deltaglider with Scram (DG-S), and then I tried several times to do the same with the ship DeltaGlider IV,
but I never succeeded :

1 * launch with standard autopilot to get the general direction (AP),
2 * switch to Ascent mode (twice Mod),
3 * enable Plan correction (COR),
4 * enable the autopilot for Direct Ascent (AP).
and... it failed.

 

[malisle]

Thre reason why it worked was also a source of potential CTDs, discovered by tutrle91, earlier in this thread. AFAIK multistage2 is based on VESSEL2 class, which originates from 2006 Orbiter interface. In the 2010 version of Launch MFD I had to discontinue support of 2006 vessels because of the CTDs. What should work though, is using Launch MFD 2006 in your Orbiter 2010, with GDI compatibility on. Please let me know if it works.

It does work. Thank you :thumbup:

 

[Enjo]

and... it failed.

Well I need to know ANY symptoms. But from what you've written it may be possible that you've simply disabled the offplane correction, because now it's enabled by default. No idea.

 

[Max Pain]

Hello,
first I have to thank you for this outstanding MFD.

I have a small problem regarding the new release. I want to use launch mfd to launch from earth into the moons orbital plane. Verson 1.5.5 found solutions from wideawake (and I checked with Map mfd that it is possible), however version 1.5.6 just suggests to launch with a heading of 90 degrees.

Please try the attached scenario with v. 1.5.5 and v. 1.5.6, you will see the difference and know what I mean.

 

[insanity]

Hello,
first I have to thank you for this outstanding MFD.

I have a small problem regarding the new release. I want to use launch mfd to launch from earth into the moons orbital plane. Verson 1.5.5 found solutions from wideawake (and I checked with Map mfd that it is possible), however version 1.5.6 just suggests to launch with a heading of 90 degrees.

Please try the attached scenario with v. 1.5.5 and v. 1.5.6, you will see the difference and know what I mean.

You could always just enter the inclination and LAN for the moon as a manual target (you can get the info from Orbit MFD).

 

[Enjo]

I see where the problem is. It's a side effect of fixing the CTD problem when switching to Direct Ascent page when no target was set. I'll need some time to fix it though (to simplify the targeting system) so I suggest to use insanity's workaround for now.

 

[Enjo]

OK, it wasn't that hard. I've dumbed down the targeting system, so that now when you target a celestial body, the LaunchMFD-Probe is spawned. Thanks to this, the body's great circle may be drawn.

One word of warning though: the attached version uses new VesselHooking and HUDDrawer modules to register itself as a client of HUD drawing (as mentioned few posts above). You'll have to enable the HUDDrawer module to get the functionality in LaunchMFD.

 

[Max Pain]

Thanks a lot, it works now.

A minor thing I noticed (which doesn't happen when I input the Inc and Lan manually) is that it calls out "Half of orbital velocity reached" at a very small velocity, if the moon is selected. I guess that happens because it takes the orbital velocity of the moon? It is not really a bug, I just wanted to mention it.

 

[Enjo]

No problem.
Hmm it shouldn't make any difference compared to manual inclination and LAN entry. Oh well.

 

[Enjo]

Just curious here but is it possible to use Launch MFD to plot an ASAT type launch? I.e. one where the missile is launched into a suborbital path opposite the orbit of the satellite?

I don't know if I understand you correctly here. It's currently possible to launch anything into a suborbital path and keep it under the target's plane until the planned interception manouerve (that's the phase 1 of direct ascent), but as the target interception goes, (phase 2 of direct ascent) you'll need to use a different interception algorithm, as my own doesn't handle the interception very well if the apoapsis is larger then periapsis, as I've described before.