# OHMPursuitMFD 2016

#### turtle91

##### New member
Many thanks for that.
Good to know, that you are back :thumbup:

The only change was to use the new "surface_elevation()" modell, to include the new altmode_ground.
And off course a re-compile was manadatory just to have the MFD working in new Orbiter without CTD.
I have also made the MFD a (very tiny)bit more tollerant during the very last step in the landing-phase.
So, i.e. on Mars, it's more likely that the MFD "declares" a successfull landing (means the AP switched off the engines..and does not try to overcorrect one missing meter lateral-offset forever).

The only outstanding issues, I see so far:
-If moving from one major body to another (i.e. Eart/Sun/Moon), the REF function seems to be causing CTD's, when using this button after the "body-change" happened.
-some vessels are using customized RCS-logic (i.e. to compensate COG changes...like Kulch's "Tranzit").
However, vessles which are using customized RCS-code, seem to be crashing this MFD, too.

But beside this small issues, this MFD is really helpfull and a "must be" in all my Orbiter-installs.
It is so helpfull and precise in so many different situations...it's just awesome.
:tiphat:

#### Interceptor

##### Well-known member
Hey Rawash could you please add the 2010 version of pursuit mfd to OH,also,I think some people will still use orbiter 2010,and it would be a shame not to be able to have it avaliable anymore,BTW thanks for the update for 2016,I can't wait to try it out.Thanks

#### turtle91

##### New member
Hey Rawash could you please add the 2010 version of pursuit mfd to OH,also,I think some people will still use orbiter 2010,and it would be a shame not to be able to have it avaliable anymore
As far s I can see, the (updated)2010-module is included into the zip-file.
It's called "(orb2010)".

#### Interceptor

##### Well-known member
Ok,thanks turtle,I didn't see it at first,sorry Rawash forget,I said anything.:blink:

Last edited:

#### turtle91

##### New member
Ok, I have dome some tests with the new PursuitMFD2016, esp the landing-mode.

First, I really like the new look. Having a main-menu, makes it easier to access the required function.:thumbup:

Landing on the Moon went fine, but I have issues on Mars.
I.e. below is a scenario, where I have tried both MFDs, the new 2016-one an "my" build.

If using the new version, the descent went fine, but it comes to trouble above the landing pad (where radio-alt reads 30 meters and about 2 meters away from the final-decent/landing point).
The thing is, that nothing happens when vey close to this point.
So the MFD waited a bit, until the target has been overshooted at about 20 meters, and then tried to compensate, using heli-hover-style.
At the end, the vessel hard-landed about 50 meters from the pad.

If do the same using "my" (sorry again..for hijacking...) build, the landing went fine.

Here the scenario, using a XR2-vessel. (ok...it's a night-landing...I need to learn more to better use TransX).
But it should be fine for testing, alitude about 250 km, orbiting into the direction of Olympus....plane is ok.

Code:
BEGIN_DESC
Orbiter saved state at T = 12447496
END_DESC

BEGIN_ENVIRONMENT
System Sol
Date MJD 52128.7243596101
Help CurrentState_img
END_ENVIRONMENT

BEGIN_FOCUS
Ship XR2-01
END_FOCUS

BEGIN_CAMERA
TARGET XR2-01
MODE Cockpit
FOV 52.00
END_CAMERA

BEGIN_HUD
TYPE Surface
END_HUD

BEGIN_MFD Left
TYPE Orbit
PROJ Ship
FRAME Ecliptic
ALT
REF Mars
END_MFD

BEGIN_MFD Right
TYPE Orbit
PROJ Ship
FRAME Ecliptic
ALT
REF Mars
END_MFD

BEGIN_PANEL
END_PANEL

BEGIN_SHIPS
XR2-01:XR2Ravenstar
STATUS Orbiting Mars
RPOS 1164016.238 -1636194.736 3042544.122
RVEL 1997.8907 -2061.3440 -1872.9717
AROT -132.021 -35.700 -67.023
VROT 0.0000 0.0539 0.0000
PRPLEVEL 0:0.854439 1:0.990115
IDS 0:199 100
NAVFREQ 588 466 84 114
XPDR 193
SECONDARY_HUD 0
LAST_ACTIVE_SECONDARY_HUD 0
TAKEOFF_LANDING_CALLOUTS 3665.891877 85614.817349 85614.829770 0.000000 -0.071755
APU_FUEL_QTY 0.938770
LOX_QTY 0.944169
CABIN_O2_LEVEL 0.209000
CREW_STATE 0
INTERNAL_SYSTEMS_FAILURE 0
COGSHIFT_MODES 0 0 0
MWS_ACTIVE 0
COOLANT_TEMP 31.200000
DMG_0 1.000000 Left Wing
DMG_1 1.000000 Right Wing
DMG_2 1.000000 Left Aileron
DMG_3 1.000000 Right Aileron
DMG_4 1.000000 Landing Gear
DMG_5 1.000000 Nosecone
DMG_6 1.000000 Retro Doors
DMG_7 1.000000 Top Hatch
DMG_9 1.000000 Airbrake
DMG_10 1.000000 Left Main Engine
DMG_11 1.000000 Right Main Engine
DMG_12 1.000000 Left SCRAM Engine
DMG_13 1.000000 Right SCRAM Engine
DMG_14 1.000000 Fore Hover Engine
DMG_15 1.000000 Aft Hover Engine
DMG_16 1.000000 Left Retro Engine
DMG_17 1.000000 Right Retro Engine
DMG_18 1.000000 Forward Lower RCS
DMG_19 1.000000 Aft Upper RCS
DMG_20 1.000000 Forward Upper RCS
DMG_21 1.000000 Aft Lower RCS
DMG_22 1.000000 Forward Star. RCS
DMG_23 1.000000 Aft Port RCS
DMG_24 1.000000 Forward Port RCS
DMG_25 1.000000 Aft Star. RCS
DMG_26 1.000000 Outboard Upper Port RCS
DMG_27 1.000000 Outboard Lower Star. RCS
DMG_28 1.000000 Outboard Upper Star. RCS
DMG_29 1.000000 Outboard Lower Port RCS
DMG_30 1.000000 Aft RCS
DMG_31 1.000000 Forward RCS
DMG_32 1.000000 Bay Doors
IS_CRASHED 0
MET_STARTING_MJD 51985.647035
INTERVAL1_ELAPSED_TIME -1.000000
INTERVAL2_ELAPSED_TIME -1.000000
MET_RUNNING 1
INTERVAL1_RUNNING 0
INTERVAL2_RUNNING 0
ACTIVE_MDM 3
TEMP_SCALE 2
CUSTOM_AUTOPILOT_MODE 0
AIRSPEED_HOLD_ENGAGED 0
SCRAM0DIR 0.000000 0.000000 1.000000
SCRAM1DIR 0.000000 0.000000 1.000000
HOVER_BALANCE 0.000000
MAIN0DIR 0.000000 0.000000 1.000000
MAIN1DIR 0.000000 0.000000 1.000000
GIMBAL_BUTTON_STATES 0 0 0 0 0 0
ATTITUDE_HOLD_DATA 0.000000 0.000000 1 0 0.000000
DESCENT_HOLD_DATA 0.000000 -2.857255 0
AIRSPEED_HOLD_DATA 0.000000
OVERRIDE_INTERLOCKS 0 0
TERTIARY_HUD_ON 0
CREW_DISPLAY_INDEX 0
GEAR 1 1.0000
RCOVER 1 1.0000
NOSECONE 0 0.0000
AIRLOCK 0 0.0000
IAIRLOCK 0 0.0000
CHAMBER 0 0.0000
AIRBRAKE 0 0.0000
HATCH 0 0.0000
SCRAM_DOORS 0 0.0000
HOVER_DOORS 1 1.0000
APU_STATUS 0
EXTCOOLING_STATUS 0
TRIM 0.000000
LIGHTS 1 1 1
PARKING_BRAKES 0
XR1UMMU_CREW_DATA_VALID 1
UMMUCREW XI0-Lee_Nash-39-65-78
UMMUCREW XI1-Kara_Miller-32-65-58
END
STATUS Orbiting Mars
RPOS 1164013.694 -1636193.653 3042545.666
RVEL 1997.8907 -2061.3440 -1872.9717
AROT -132.021 -35.700 -67.023
VROT 0.0000 0.0539 0.0000
ATTACHED 0:3,XR2-01
AFCMODE 7
END
STATUS Orbiting Mars
RPOS 1164016.877 -1636196.493 3042542.942
RVEL 1997.8907 -2061.3440 -1872.9717
AROT -132.021 -35.700 -67.023
VROT 0.0000 0.0539 0.0000
ATTACHED 0:0,XR2-01
AFCMODE 7
NAVFREQ 0 0
END

END_SHIPS

Btw. the only change I made within EI.cpp was at about line 434 regarding the final-offset:

Code:
if(fabs(pos.x)<3.5 && fabs(pos.z)<6.0 && fabs(hv)<0.5) flg[0] = true; // finish trigger ///more tolerance to improve mars landing by turtle (was 2.5 and 5.0 and 0.5)

and more harsh landing (60 cm free-fall):

Code:
if(pos.y <= 0.6) {
//			flg[0] = false;
LandPhase = LANDED;
return;

Last edited:

#### Rawash

##### New member
I've launched the scenario you gave and I didn't get yet the overshooting you experienced in the landing phase.

Did you get small MFD refresh rate drop in the final? It could be important in the calculation.
Did the error at the end of the approach phase was not too high?
If the vessel misses the narrow area to initiate the final descent (1x2meter with speed less than 0.25m/s in this build), it will be hard to compensate smoothly the growing error (weak AP, indeed, in this phase and I thought few times to write another one).
A little tip : at this moment you should hit the hold key to stop AP and the ship will keep its current altitude and set its velocity to zero (too basic too work well, I will look at this :hmm, giving the time to regain control manually .

Anyway, the current final phase is really tricky because of its use of hover or main engines direction to control all the forward & lateral trajectory and highly dependent of the previous phase. It's less precise and more vulnerable to error than using the linear thrusters in conjunction but I feel it should be like it is (and maybe I'm wrong...).

The changes you've made are close to those, currently, for the ArrowFreighter and similar (big ship with no roll thrusters dedicated).
I didn't tweak it too much after recent changes but it sounds good afterall.
It also sounds like it needs a configuration file for less.

#### turtle91

##### New member
Did you get small MFD refresh rate drop in the final? It could be important in the calculation.
Did the error at the end of the approach phase was not too high?

Good points, I forgot to mention.
Yes...MFD-refresh-rate could be an issue. I used 0.1, which is the max for this MFD according to the docs.
But if I go to a lesser value (i.e. 0.05), the new D3D9-client kills my FPS-rate.

The error happend when crossed my landing-spot, about a few meters before the landing spot at an altitude of exact 30 meters.
So first it was looking good, but than it crosses the landing spot, without any intervention, and missed. (maybe the intervention was in the 0.05 time-frame...so in a 0.1-time-frame, the exact spot has been missed/skipped).

So in short words: the descent from "30-0" has never happened.

Just for fun, I tried "my" build yesterday to its extreme.
Same situation, but altitude at about 760*760 kms :facepalm:.
A real steep aproach, but the landing was even here successfull.(I have not expected this...).

Maybe putting a "more tolerant profile" into the CFG page, so the user can decide if:
-he wants to be very precise i.e. landing in the exact middle of a pizza
-he does not care about 1-3 meters miss, and has stable gear (early engine cut-off (i.e. 50-60 cm freefall).

Btw:

A little tip : at this moment you should hit the hold key to stop AP and the ship will keep its current altitude

This is good to know, that the hover keeps active.
I believe this was different in previous version.

So I could switch AP off and can let "HoverMFD" do the rest few meters for example.

Last edited:

#### boogabooga

##### Bug Crusher
I like the option of turning off the roll control. Nice.

#### Rawash

##### New member
Hi turtle91,
The MFD refresh rate is the number at the bottom right corner.
It should not be more than 0.3sec at normal acceleration time, unless calculation goes fuzzy.
It's different than MFD (display) refresh that I split from background calculation.
btw: did you enable the limter in the D3D9Client config file?
I set mine to 60fps.

The errors between calculated and current trajectory are the two data named errY (height) and errZ (distance to target) below the graph. They should not exceed around 0.2 close to the switching time between approach and landing. If so, the position and the velocity constraints needed for targeting and smooth deceleration lead to a missing landing.
You should try to build for testing with your landing setting.
Those are good and more fuel friendly.

HoverMFD offers a different way to land. PursuitMFD can be stopped at the end of the approach phase (by pressing hold two times) in order to switch to another landing MFD.

Last edited:

#### turtle91

##### New member
Hi Rawash,

I just realized, that you have provided a test-scenario with a standard DG, approaching Valles Marineris.
So I used this scenario for another test....and a mind blowing landing experience.
This time I tried to concentrate on the FPS and the error-rate.
It was not so easy to monitor the values, while enjoyed the spectacular panorama..:camera:

The FPS-indicator (nice feature btw) was in the 0.01-0.02 range, so FPS should not be an issue.
The error-rated went down to X=0.002 Z=0.63 when transitioned from aproach to final-landing-stage.
Even that the landing was a success this time, the target was overshooted about 8 meters. The 5m to 0m descent was a bit slow, so the target drifted away a bit.

I will do this test again, but using the XR2. Maybe here, FPS could be an issue on my lame system.
I didn't used the FPS-limiter so far, but will give it a try.

As a last step I will ry to rebuild PursuitMFD2016 with my previous settings.
At least the alt-cutoff should be a bit higher (I believe you set it now do 25 cm ?).

However, much stuff to test from my side.
I let you know the details within the next days.

#### pclaurent

##### Daydreamer
In docking mode, activating the TRIM autopilot doesn't seem to do anything. With this new version, I cannot automatically dock as the RCS in linear mode doesn't seem to be controled any more by the MFD. The alignment (roll) works fine, but the vessel is not automatically aligned in x, y or z... I didn't have this behaviour with the previous version which worked fine for both orientation and x,y,z alignment. Did I miss something?

#### rcraig42

##### New member
well It's kind of good to know that it isn't just me, the Trim does nothing at all for me either, is there an archive available where I can get an older version that DOES work?

ETA: I downloaded the zip provided up thread and it works fine for my present needs.... station keeping the dragon and maintaining the ISS in LVLH, finally going to be able to try out the Canadarm

Last edited:

#### Rawash

##### New member
small update

Hi,
I've just updated to version 171119.
Trim should be back...

#### Cras

##### Spring of Life!
Donator
Just gave this (170619) a try in Orbiter 2010, the RPM and TOR modes send an XR-2 into a wild tumble

#### Thundersnook

##### New member
EDIT: Nevermind ... issue solved...

Last edited:

#### ACH0002

##### New member
Hello,

are there a more detailed guide for PursuitMFD somewhere?

Thank you!