OHM Launch MFD - v. 1.6.6 for Orbiter 2016

I figured out that although I can't check the concrete class type of the vessel, I still can check its name.
If you just want to check which VESSEL class version it's inherited from, then there's VESSEL::Version () method returning: 0 for VESSEL, 1 for VESSEL2, and 2 for VESSEL3.
 
If you just want to check which VESSEL class version it's inherited from, then there's VESSEL::Version () method returning: 0 for VESSEL, 1 for VESSEL2, and 2 for VESSEL3.

Just superb. I can't believe I missed it. I've fixed the problem for good.

The only issue what is puzzling me is, that even when Launch-MFD is not active (so no HUD), even then, I have the CTD's.
That's just the top of the iceberg that you see. There's plenty of magic going on behind the scenes. It turned out to be slightly faulty.

And yes....I am using this brilliant Launch-MFD since Orbiter 2006...and all was working well(with otr without UCD).
That's also the reason, why it took me ages, to find this incompatibilty bewteen Launch-MFD and Kulch's UCD.
Both packages are allways belonging to my standard Orbiter installs.
But, it's long time ago, that I have used UCD...so I have never encountered this problem in Orbiter 2010 before.

However, the issue is not urgent for me. I have just seen, that some other people have also random CTD's, when using UCD.
So I thought, that my post would be a small help.

It was great help! I wish I had more reports like this :cheers:

I think your problems with vessel compilation could be resolved if you asked specific questions in the SDK section.


OK then. We're closing for another MFD release, with a more stable HUD drawing library.
 
BTW, I LOVE the autopilot.

It easily gets to a circular orbit at 220K with an aligned plan WITH 10X time acceleration!!!

Pretty nice when I just want to get to an orbit quickly to do something, without sitting there flying to orbit in real-time.
 
Once you exit the thick atmosphere (note PID Autopilot Space on the bottom of the MFD), you can increase the time acceleration to 100x.

---------- Post added at 08:57 AM ---------- Previous post was at 07:45 AM ----------

And a new version has been released. Changes:

v. 1.5.5 28-01-2013
– Made zooming GC and changing inclination as continuous buttons
– Smoother offplane correction
– Not reseting trim after disabling AP during atmospheric (SCRAM) ascent (reported by pitx)
– Automatically creating configuration subdirectories of vessel classes for storing variables
– HUD drawing: Autodetecting incompatible vessels and preventing a CTD (reported by turtle91, helped by orb)
– New library: MFDHUDDrawer. Allows MFDs to draw on HUDs
– MFDButtonPage: added continuous button support (like TransX)
– MFDButtonPage: allows switching to specific pages
– Added proper namespaces to libraries
 
Last edited:
Wow, this was really fast.
I have just tested the new release within my curent messy(5GB+) setup.
So, I have used the same setup/install, like before.
No more CTD's, when using UCD. :thumbup:

Many thanks, the fastest fix I have ever seen, since joined the IT business :tiphat:
 
:rofl: That's just because I was just in a phase of gathering small things for a new release, and that's because I'm finally starting to have a better mood.
 
Tried version 1.5.5.
If I go to the direct ascent page without having a specific target selected, I get CTD. This is super-pervasive, and is a problem for every vehicle I've tried. This was not the case with version 1.5.1. I don't use direct ascent, but it causes a problem since I can't go back and forth between the main page and vertical launch page without going through direct ascent. I don't think OrbiterLog had any useful info.

Also, tried the autopilot with DG for 97 degree retrograde orbit. It ended up in totally the wrong orbit, inclined 113 degrees. This seems to be a problem for all targeted retrograde orbits.
 
Last edited:
OK thanks. I'll have a look on the weekend.

---------- Post added at 08:05 PM ---------- Previous post was at 11:04 AM ----------

Tried version 1.5.5.
If I go to the direct ascent page without having a specific target selected, I get CTD.

Unfortunately I couldn't reproduce this. I've changed a moment of initialization of an important control variable to as soon as possible. Maybe this helps. Please test the attached version.

Also, tried the autopilot with DG for 97 degree retrograde orbit. It ended up in totally the wrong orbit, inclined 113 degrees. This seems to be a problem for all targeted retrograde orbits.

Hah. It turned out that it has been working this way since version 1.4.5, after I've made large structural changes in the code, and that was almost 2 years ago! Fixed it.
 
:facepalm: I see what has happened. The file was rejected because it was a .dll
 

Attachments

So? Does it work or you haven't checked yet?
 
No crash to desktop. :)
Sun-synchronous orbits can now be achieved :)

Right now I'm having problems using the autopilot with anything but stock Delta Glider. I went into the vessel LaunchMFD configs where PID values are stored. I set a specific pitch program for a certain vessel. It seems as though after I ran LaunchMFD it reverted to "universal" PID values and deleted my pitch program. I'm confused.:blush:

Example:

I go to Config\MFD\LaunchMFD\Velcro\NovaMMS10E-1_variables.cfg
(It's a SSTO Velcro rocket)

pasted in (just as a test) and saved
Code:
SPACE_XY = 2 6 0
UPSIDE_DOWN = TRUE
ROLL_ALT = 0.17 

PITCH_PROGRAM_ALTITUDE
0 90
0.17 88
5 65
10 56
15 48
20 41
25 34
30 28
35 22
40 16
45 16
50 17	;SRB sep
55 18
60 19
85 19
90 18
95 16
100 14	;press DEF here, manually adjust pitch
END_PITCH_PROGRAM_ALTITUDE

Ran the scenario from Velcro rockets for this rocket in Orbiter. Launched with LaunchMFD autopilot. The actual profile did not resemble what I had pasted in at all. I closed orbiter and this is what the file had after:

Code:
SPACE_XY = 2.5 16 0
SPACE_BANK = 1 12 0
ATMO_XY = 2 2.49848 0
ATMO_BANK = 3 6 0
NEXT_LAUNCH_TIME = 0
SYNCHRO_OFF_BY_RATIO = 0

Everything I had entered in is gone.
 
Last edited:
No crash to desktop. :)
Sun-synchronous orbits can now be achieved :)
Great. Now I know what to avoid in my code.

The 2nd problem results from lack of documentation. The newest behavior of Launch MFD is to treat the file with _variables suffix as a temporary output-only file, that will be overwritten on each simulation exit with the variables that you've set during that simulation session. The place where you should be placing your read-only, permanent configuration (for example with some variables copied from the _variables file) is:
Config\MFD\LaunchMFD\Velcro\NovaMMS10E-1.cfg
as opposed to:
Config\MFD\LaunchMFD\Velcro\NovaMMS10E-1_variables.cfg
The permanent configuration file will never be overwritten by the MFD.

Perhaps I should have been creating the permanent config file with commented information what to do with it, if the file doesn't exist.

Hope it helps.
 
Last edited:
:facepalm:

O.K. Thanks. I'm starting to see how powerful this MFD can be.

One more issue:

When equatorial inclinations are chosen, could you make it selectable whether to use the ascending or descending azimuth? I noticed that you choose an inclination close to your launch latitude (example 29 degrees from Cape Canaveral), the autopilot can get confused and flip-flop between the two.
 
Yeah, I have seen this a few times, and worked around it by adjust the inclination by very small amounts in mid launch to make sure I keep the vehicle headed on the right one.

I wouldn't mind seeing the ability to force the northern or southern azimuth in all general
inclinations as well.

:)

Easy for me to just request things.....but Enjo knows I love this MFD.
 
When equatorial inclinations are chosen, could you make it selectable whether to use the ascending or descending azimuth? I noticed that you choose an inclination close to your launch latitude (example 29 degrees from Cape Canaveral), the autopilot can get confused and flip-flop between the two.

Yes, that's how it works and it's expected to behave like that in such situations, because there's no "azimuth locking" mechanism employed when using manual inclination. I could enforce it though, like lock the currently chosen azimuth, so that after you know you're heading in the right one, it won't switch.
Let's remember that now I have an unlimited amount of buttons to create, and when I've started developing the MFD, and when the described behavior was defined, the limited number of buttons was one of my main limitations.
 
Last edited:
OK try the attached version. Azimuth switching is done by Shift+U or AZI button, switches between values BOTH | NORTH | SOUTH and it works only when in flight and when no target is selected.

Have fun.
 

Attachments

I think it would help with accuracy if Launch MFD put a Rolex on my wrist. And a Porsche in my driveway. :lol:

Was worth a try.
 
Back
Top