OHM Glideslope 2.7 for Orbiter 2010

OrbitHangar

Addon Comments
Joined
Apr 9, 2008
Messages
3,832
Reaction score
18
Points
0

Author: adswnj

*** Do not use for Orbiter 2016 ***

MMExt2 native release: no more Error 126. Minor change to non-atmo data screen, to add VAcc and HAcc indicators. For best experience, please also install ModuleMessagingExt v2.1 or later. 

Glideslope 2 is a reentry guidance utility to assist you to make precision landings from orbit to the runway or landing pad. It is based on the original Glideslope by Chris Jeppesen. For atmospheric landings, Glideslope 2 calculates the reentry profile downt to a Heading Alignment Cylinder (HAC) tun similar to the profile that the Space Shuttle used to fly. The utility has extensive configuration files to allow you to create your own custom reference landing profiles for different vessels or types of reentry (e.g. you could create an emergency descent profile for a DG, or an max weight landing for a Shuttle).

Updates this version: tight interaction with the new BaseSync v3.0 for the new deorbit autopilot. Plus a whole new vacuum landing mode for precision landings onto the Moon, Mercury, etc.



DOWNLOAD
 
Latest v2.2 update to Glideslope now live for your enjoyment.

I forgot to mention, I added a number of Scenarios in a Glideslopes folder, so you can try shooting some approaches to KSC and WIN in the XR2. There's also a scenario in there custom-built for blixel's challenge ... doing KSC to WIN in under 22 minutes!!

Enjoy
 
Sweet! I actually used the last version to fly the G42 from Edwards to WIN to nice results. I will most certainly be trying it again with your update.

Thanks!
 
Sweet! I actually used the last version to fly the G42 from Edwards to WIN to nice results. I will most certainly be trying it again with your update.

Thanks!

That should work just fine. Modify the KSC to WIN scenario editing in the Edwards co-ords. The reference glideslope for KSC to WIN will be close enough for you, until you save your own reference (SAV button).

Blixel reported that there still may be some issues with SAV. If you don't get a good file, then either DELETE the GS2glideslope_UserSave.cfg completely, or copy GS2glideslope_XR.cfg over the top of GS2glideslope_UserSave.cfg, until I can figure out why it's failing!
 
I like this update. The mode titles make it easier for me to identify which screen you're talking about :)

The bearing indicator is extremely useful for these suborbital speed runs. I just have to get better at anticipating how much offset I need for a particular base. (e.g. you need to err to the northwest of Wideawake so you can be lined up with RWY 12 when you get there. I have a tendency to come in just south of the island, which makes for some pretty lousy hairpin landings.)

Near as I can tell though, the SAV function still doesn't work.

Also, the default data set for the KSC to Wideawake suborbital hop needs to be edited. That profile is really weird looking, and you should never climb much above 72km in that flight ... except for right at the very end where you jump up to about 75-76km to flip over.

Here are some pics of what I mean:

IihgA.jpg


xKobf.jpg


Here's another example flight using your updated GS. (Forgive the lousy island alignment. I'm still having a bit of trouble showing up at the island in proper alignment.)

 
LOL !!! That weird altitude spike was where I lost control of the altitude somewhat at max velocity. I was a bit too high, so the inverted flight was not developing enough lift to hold my altitude down. That's why I need a pro to do the flight to generate a cleaner reference for me! At least the last 10 mins of the flight is super-smooth after I got it back under control, and the approach to landing was almost a perfect straight-in approach at a 40º steep glideslope!

I need to find out why there is still an issue with that SAV mode. The original bug was something like this:

1. The GS2.cfg references UserSave as one of the glideslopes (to make it really easy to select your last run as a reference).
2. If there is an incomplete save on the SAV function, so the UserSave is invalid, then on the next launch of GS2, it will fail to parse that file. (Check in the Config\MFD\GS2\Logs parse files.)
3. The failure to parse it accidentally left a file handle open on the UserSave file.
4. So ... when running the next SAV function, it could not open the file for exclusive write, and so the save failed.

To break the dependency loop above, comment out the UserSave GLIDESLOPE entry from GS2.cfg, and/or delete the UserSave cfg file, and/or copy a clean reference glideslope (e.g. the XR glideslope over the UserSave cfg.

I can't look at this now until next weekend, but hopefully this advice will get you clean user save in the meantime.

---------- Post added at 03:12 AM ---------- Previous post was at 03:00 AM ----------

I watched the video. Really nice to see how you keep the altitude, despite getting to a crazy velocity. And that final approach was just wild!

By the way - you need to hit the OK after you hit SAV, to complete the save. Maybe exiting orbiter without hitting OK is what's causing the UserSave not to save? (Something else for me to check.)
 
By the way - you need to hit the OK after you hit SAV, to complete the save. Maybe exiting orbiter without hitting OK is what's causing the UserSave not to save? (Something else for me to check.

Ah ... hmm... I think I hit OK after I stopped recording, but maybe not. I'll do a few short flights to test the SAV function. I would like to be able to save my profiles so I can use the last best attempt as the benchmark for each new attempt going forward.
 
FYI, I found a bug.

If there is a tab character separating the longitude latitude values in the "Location" line of a base .cfg file, glideslope will CTD when it parses the file.

Replacing the tab character with a space fixed the problem.
 
FYI, I found a bug.

If there is a tab character separating the longitude latitude values in the "Location" line of a base .cfg file, glideslope will CTD when it parses the file.

Replacing the tab character with a space fixed the problem.

:thumbup: Thanks for the heads-up. I'll fix on the next release.
 
I use the VACC tape a lot to control descent, but the +/-10 m/s^2 scale makes it hard to be precise. I very rarely get up to 1 m/s^2, and most of the time I'm below 0.3 m/s^2. Is anyone really using 10 m/s^2 during a controlled reentry?
The VACC tape on the SurfaceMFD covers +/- 0.3 m/s^2, but it has a moving scale that actually covers 0.6 m/s^2.

Regardless of that small niggle, this is going on the must-have list. Top job. :thumbup:
 
I use the VACC tape a lot to control descent, but the +/-10 m/s^2 scale makes it hard to be precise. I very rarely get up to 1 m/s^2, and most of the time I'm below 0.3 m/s^2. Is anyone really using 10 m/s^2 during a controlled reentry?
The VACC tape on the SurfaceMFD covers +/- 0.3 m/s^2, but it has a moving scale that actually covers 0.6 m/s^2.

Regardless of that small niggle, this is going on the must-have list. Top job. :thumbup:

A GS2 TAPE screen afficionado! I didn't know if anyone used that mode still. For next version, I will lock the VACC scale at +-1 ms2 for you. Would you also like a VACC on the GS2 DATA screen? And what else would you like changed on the GS2 TAPE screen?

Thanks for the feedback! I appreciate it!
 
A GS2 TAPE screen afficionado! I didn't know if anyone used that mode still. For next version, I will lock the VACC scale at +-1 ms2 for you. Would you also like a VACC on the GS2 DATA screen? And what else would you like changed on the GS2 TAPE screen?

I guess I'm a bit of an oddball in that area. I never seem to use addons in the same way that the majority does. :lol:

Don't add anything to the data screen on my account, because i don't like to read too many numbers during critical maneuvers. I like to see at a glance what direction I need to go.
I just found it odd that the VACC tape never moved, but it just might be because the scale was too large.

The only other thing I can think could be changed is the default HAC radius. The STS used 5 km radius so the default 15 km looks very large to me. But the optimal radius depends mostly on the type of craft, so it might be worth considering putting a "standard" HAC radius in the glideslope file. But you have enough time to tinker with the that before entry interface, so it may be too much work for a tiny benefit.

---------- Post added at 03:17 PM ---------- Previous post was at 01:15 PM ----------

PS: Actually I think +/- 2 or 3 m/s^2 would be more appropriate for the VACC tape scale.
 
:thumbup: Thanks for the heads-up. I'll fix on the next release.

Boy do I feel stupid.

That problem EDIT: (the tab vs space problem in the .cfg file) happened with the original Glidescope, not GS2. I didn't realize I was using the old version until a bit ago.

:facepalm:
 
Last edited:
Boy do I feel stupid.

That problem happened with the original Glidescope, not GS2. I didn't realize I was using the old version until a bit ago.

:facepalm:

Sooo... put up the Glideslope and Glideslope 2 on your 2 MFDs (they can coexist quite happily), and look at the before and after. Let me know what you think.

I tried to make the text more readable, and the colors slightly different. Plus the standard white/red color treatment for high/low. What do you reckon?
 
Sooo... put up the Glideslope and Glideslope 2 on your 2 MFDs (they can coexist quite happily), and look at the before and after. Let me know what you think.

I tried to make the text more readable, and the colors slightly different. Plus the standard white/red color treatment for high/low. What do you reckon?

I like it a lot. It helps the eye find relevant information easier.
 
the displays in your version are all around superior to the old one. Especially with the tape display. The old Glideslope had some display issues under D3D9 client, none of which I have seen your your version.

I still just need to fine tune my de-orbit procedure to better get on the slope....my last attempt I burned too early and ended up too low when guidance started up.
 
I still just need to fine tune my de-orbit procedure to better get on the slope....my last attempt I burned too early and ended up too low when guidance started up.

Try 200x200km Ecc=0.000 orbit, then BaseSync deorbit to 80KM alt, 60º ant, 0.7º angle. There's a number of scenarios in the Scenarios \ Glideslopes directory if you want to try shooting some approaches!
 
Try 200x200km Ecc=0.000 orbit, then BaseSync deorbit to 80KM alt, 60º ant, 0.7º angle. There's a number of scenarios in the Scenarios \ Glideslopes directory if you want to try shooting some approaches!

Thanks!

But I think I should elaborate. I avoid using the throttle as much as I possibly can. So I use various MFDs to give me a solution that I can plug into IMFDs dV program and burn. To me this is how space ships are supposed to work. Mainly because that is how the Shuttle worked...and I suffer from massive STS nostalgia and I pretty much put Shuttle like procedures onto every Space Plane I fly in Orbiter, including the XR-2.

So right now I am experimenting on the proper offset required to get my old de-orbit procedure to line up with the XR2 glideslope that you have supplied. So far, I am close, but still a little short. I think I should get it soon.

And I have also bounced between the .7 angle and a .8 angle. My old procedure was a 1.2 angle so, there is a little bit that needs adapting. I like the .7 and .8 more and using this MFD as I can better utilize the crossrange.

Anyway, enough of that...... I look forward to your work on this. And when ever you want something tested or whatever, I am game :thumbup:
 
If anyone is interested, I made a DGIV glideslope.

One needs to add the following line to <orbiter root>Config\MFD\GS2\GS2.cfg
GLIDESLOPE DGIV "DGIV"


It includes a scenario. To deorbit in the scenario, enter the BaseSyncMFD and set
ANG to 1.4
ANT to 26
ALT to 70

Burn when indicated.

EDIT: I forgot to mention, those values set one up to do a 35 degree AoA reentry.
 

Attachments

Last edited:
Back
Top