Launch MFD releases

[Andy44]

Probably. Where can I download her?

Here is the link to Sputnik's X-20 DynaSoar on OH:

[ame="http://www.orbithangar.com/searchid.php?ID=1030"]Dyna-Soar w/MOOSE v1.31[/ame]

The HUD compass seems to work when I fly the DG, but since I take off horizontally in the DG it's not really as useful. The X-20 is launched vertically, though, so that's where the launch compass really comes in handy.

 

[Face]

I can't see that the FPS issue is derived from the unhooking/hooking as it's just writing over a byte of memory which shouldn't take that many cycles. I would imagine that it is more likely to be the GDI drawing functions as it draws quite a bit on there and GDI is not the fastest drawing set of functions.

Well, I was more thinking about VirtualProtect()...

I haven't done much assembly and prefer not to in-line assembly if at all possible as it's messy and not readable.

In this case it would be just a workaround to call a class function with another object handle, but it is less readable, indeed.

EDIT: Yes, just done a quick test. The FPS issue definitely isn't the hooking/unhooking. It's the GDI code that causes the slowdowns. I didn't get such a dramatic drop as 60->15 though. More like 130->115

Yep, I can confirm that on my machine, too. I checked out revision 40 and rebuild it with VS8 (there are some rooted pathes in the configuration, BTW), and I got no FPS-drop either.

I found one minor issue, though: if the fast-shutdown of Orbiter is disabled (e.g. the "release memory"-option is enabled) and a second scenario is started after a first was closed, Orbiter hangs reproducable for me. Since the fast-shutdown is default in Orbiter, it may have gone unnoticed...

And BTW: thanks for this MFD! A really cool addition to the Orbiter expirience.

regards,
Face

 

[Enjo]

Thanks for help offer, and feedback Face. I've tried to reproduce the bug, but it seems that it's not LaunchMFD related, as my debugging session showed, and the same crash happens if I disable LaunchMFD, and start a scenario without LaunchMFD.

 

[Andy44]

Okay, I have tried the Launch MFD with the Nova-SSTO, which is also a CVEL launch vehicle, and the HUD compass doesn't work with it, either. I'm thinking that it's a CVEL thing.

 

[agentgonzo]

Okay, I have tried the Launch MFD with the Nova-SSTO, which is also a CVEL launch vehicle, and the HUD compass doesn't work with it, either. I'm thinking that it's a CVEL thing.

Thinking about it, the way that drawing to the HUD is accomplished is it hooks the VESSEL2 class method. If the CVEL vessel is using the old VESSEL rather that VESSEL2 class, then there may be no HUD function to hook. I'll try and take a look at the code in the coming week.

 

[agentgonzo]

I've just looked through the code for CVEL vessels and they inherit from COMMON_VESSEL_EX, which in turn inherits from VESSEL, rather than VESSEL2. As the clbkDrawHUD method that I hook is in VESSEL2, rather than VESSEL, I can't hook it (or more accurately, I'm hooking another random section of memory). I don't know how orbiter creates vessels and how it knows whether a vessel is a VESSEL- or VESSEL2- derived module. I also don't know whether COMMON_VESSEL_EX has HUD functionality that I can hook into.

Any help on this would be appreciated.

 

[Enjo]

Launch MFD 1.2.8

Today we bring you
[ame="http://www.orbithangar.com/searchid.php?ID=2802"]Launch MFD 1.2.8[/ame]
with the following features:


- Off-plane correction (by Agentgonzo) - switch it on with COR button or Shift O combination. Works for SSTO craft only for now.

See the correction string almost at the bottom. The off-plane correction can be explained using this diagram:

The correction is used to help you minimise LAN error, but is not an alternative of timing the launch correctly. The worse you time it, the more fuel you'll use.

- Data which is displayed on HUD (pitch marker in Standard Mode and in Compass Mode) can be also displayed in the MFD area for old vessels derived from VESSEL class, which don't support HUD drawing.

(old screenshot)
Click on DEF button, or press Shift D in the Standard mode to disallow taking pitch into account

- Altitude for PEG more ergonomic

- Right mouse click on button which increases a value, decreases this value
This is a feature that's meant to get the users used to this functionality. We'll probably have to get rid of two buttons eventually, so tell me how you get on with this feature. Mind that it works only with Glass Cockpit for now (Orbiter limitation). All the keystrokes remain the same.

- Displaying Time To MECO (by Agentgonzo)

 

[Belisarius]

Super MFD, really useful for vertical launches. I'm downloading the new version right away. Thanks for your great work, Enjo and Agentgonzo.

 

[tblaxland]

- Off-plane correction (by Agentgonzo) - switch it on with COR button or Shift O combination. Works for SSTO only for now.

Excellent work! This is a feature I have been waiting for in particular.

 

[agentgonzo]

It also has support for tail-sitters (craft that only have a hover engine and no main, like the Apollo LM). It should detect when there is no main and just a hover and switch to calculating from that. The targeting cross on the HUD will remain in the centre of your view rather than in the direction of travel.

 

[aebrett]

When using the launch compass, should I be pointing my ship's velocity vector at the cross, or should I be pointing my ship's nose at it?

 

[agentgonzo]

Edit: Sorry, got confused.

 

[Enjo]

The question was about Lauch Compass, but let's remember that this is not a general rule. It's easier when you point your velocity marker at the cross, but for example while using the direct ascent program in the moment of performing a bootleg turn it's impossible to immediately change the velocity vector, which in fact is predicted by the azimuth calculation function, ie. it expects you to point your direction marker at the cross.

Still I speak for the azimuth calculation function, which has its contribution in the cross' position. I'm not that sure about PEG (vertical position) to be honest... It's a good chance to lay it down at this point.

[EDIT]
Let's consider a simple example. You're on your way to orbit, and nearly reached it. At this final stage PEG tells you point your ship below 00 pitch line. Can you point your velocity vector there? No, you're moving too fast. If you don't point your direction marker there, you'll end up in an elliptical orbit instead of circular.
The reason why I said that it's easier to point your velocity marker on the cross is that if you don't do it, you'll have to constantly keep putting your direction marker there, fighting with aerodynamics, because the direction tends to resemble the velocity vector. At least for the DG. Generally though you need to point your direction marker at the cross.

 

[Enjo]

Version 1.4.0 released!

After a while, and after making proper tests, it's time to release the newest version, 1.4.0. It comes in 3 versions:

1. [ame="http://www.orbithangar.com/searchid.php?ID=2802"]Launch MFD for Orbiter 2010[/ame]
2. [ame="http://www.orbithangar.com/searchid.php?ID=4408"]Launch MFD for Orbiter 2006[/ame]
3. [ame="http://www.orbithangar.com/searchid.php?ID=2803"]Launch MFD for Orbiter 2010 - Polish translation[/ame]

I've decided to continue supporting version 2006, because some folks may still want to use the on-HUD flight director, present only in 2006. However I've submitted a feature request for the same functionality in Orbiter 2010. Please vote for it if you want it implemented and I will gladly utilize this in Launch MFD while I still have time </pressure>

What's new:

1. Fuzzy autopilot working for fictional and some realistic craft. Also supports flight method that uses SCRAM jet engines (DG-S, XR)
2. Correct time to launch, also taking nonspherical gravity sources into account
3. Direct ascent improvements - uses fuzzy logic and models great circle properly

Point 3. isn't interesting for a regular user. It's just an info that I'm working on it and improving it with some success.

2. is just as it says. It was still wrong before, when the ship was landed. The nonspherical gravity sources are also modeled, although not perfectly, so using them gives an error of about 12-25 seconds for each launch window.

Point 1., the fuzzy autopilot, is described in the documentation with the following text:

HOT! Fuzzy autopilot

Thanks to my C++ port of Fuzzy Engine for Java, libFuzzyEngine++, I was able to implement fuzzy logic autopilot in the Launch MFD. All it does is following the flight director, which means that if the flight director is wrong, the autopilot will be as well. There will be always place for the fuzzy autopilot improvements, so I will only describe as common basics as possible.

After the AP is enabled, with (Shift P), or AP button , it will try to bank the ship so that the flight director is on top, which lets the ship use its aerodynamic surfaces better to orient itself to the marker. You may soon notice that the flight director's pitch increases greatly, especially if you use complex flight model. This is the PEG's problem and you should take this into account by not trusting the PEG and thus the AP too much. The solution is roughly pitching up manually before enabling the AP to get a proper readout first. There's also a moment when the AP switches to space operation mode, where there's obviously little or no drag. You will notice this when the AP suddenly “jumps” to a bit different pitch. After reaching orbit, the AP will deactivate itself automatically.
If you disable the autopilot manually, it will reset all the control surfaces and enable killrot autopilot. Be sure to disable it later.

There's a possibility to use the AP only for azimuth corrections, for example when you use a SCRAM powered ship (DG-S, XR ships), and so you want to be able to control the pitch by yourself. You can do it by pressing (Shift D) or DEF button in the Standard mode, so that the pitch readout is disabled, and then by enabling the AP. After you reach nearly orbital velocity, I advice against enabling the PEG with DEF button, because it will provide erratic values. Instead, you'd better finish the insertion by yourself. The same behaviour is present in the Direct Ascent mode, where you don't need to press anything, just activate the DA mode.

The AP may be ran with time acceleration of 10x and for multiple vessels simultaneously, independently of the MFD itself.


Shift D = Disable pitch readout (in Standard mode)
Shift P = Switch fuzzy autopilot

Have fun!

 

[Enjo]

I've released a small update.

Some people were reporting problems with ships flying upside down. The problem was that to obtain input angle to the fuzzy controller I used atan() which gives (-90*, 90*), so if you were upside down, it was still giving (-90*, 90*), instead of (-180*, 180*). atan2() solves the problem.
If something like this reoccurs, the best way to deal with it is to record a video with Orbiter's built-in recorder. I can then display debug strings and react accordingly.

Another update is concerning space version of autopilot - its rules are now very simplified and are based upon classic fuzzy logic example. You can check it in the binary release of my fuzzy logic port:
https://sourceforge.net/projects/libfuzzyengine/

Go to bin directory and run example-wxCarriage, if you have some spare time.

 

[Ripley]

Cool!
Zip name still says 1.4.1, though.

 

[Mantis]

I think there might have been a file mixup - I downloaded what I thought was the newer 1.4.3 version but it appears that it was actually the older 1.4.1 version - the files inside the ZIP file are older than those already on my system.

 

[Enjo]

Whoops. Terribly sorry. Fixed now.

Never release addons and talk via phone in the same time...

 

[Mantis]

Great job! Thanks Enjo

 

[Enjo]

I've received feedback from Stardude about the newest autopilot behaving unstable so I've reverted it to version 1.4.2 after all...
This is a big problem - you can't make one-autopilot-fits-all, because the ships have different parameters...

An ideal situation would be if I let the users define their own fuzzy rule bases and membership functions via text files for each ship they fly, but I'm so time limited that it's not possible, I'm affraid.

I'm leaving it as it was before, but if anybody with time budget wishes to join and help me, I'm open for propositions.