[1.12.x] AutoAGL v1.2: Automatically switches altimeter between AGL and ASL as appropriate.

[Snark]

10 minutes ago, ioresult said:

There are airless moons with huge mountains. Especially with planet packs like OPM (Priax comes to mind). I've crashed more than once especially in map mode in low orbits. I've even recently crashed on Earth's Moon because I thought I was 11km AGL but I was in ASL and hit a 11.5km mountain. Switching high up makes the altitude fluctuate, but I really just look at the big numbers.

Sure, but there's nothing magical about the division between "high space" and "low space".  In most cases, that boundary is way higher than any mountains the body possesses, i.e. to the point that terrain is irrelevant.  On the Mun, for example, I think it's at 60 km, which is around 10x higher than the Mun's highest elevation.

I mean, you raise a valid point, but it sounds to me like really what you're saying isn't "need notification at the high/low space boundary" per se, but rather simply "need notification higher up, 30 seconds just isn't enough".  In which case you can just slide that slider higher than its default 30 seconds.

10 minutes ago, ioresult said:

So no surprises 10 seconds before impact when it's too late to burn radially. 

Right, which is why the default on vacuum worlds is 30 seconds, not 10. 

And also why it's a setting that you can adjust upwards if you like.  (And a separate setting from atmospheric.)

10 minutes ago, ioresult said:

Same reason in atmosphere if I'm flying above high mountains. OPM's Tekto is a good example. Lift comes very high up but low gravity also means high plateaus and mountains. I like to see AGL when approaching KSC on Kerbin over the mountains there. Also when trying to approach the two mountain monoliths using a VTOL on Kerbin.

Pretty much the same deal.  You care about this because you care about collision with terrain, which matters in terms of how high above the terrain are you, not how much lift you're getting or what-have-you.  So if 10 seconds isn't enough warning, you can always crank that higher.

It totally makes sense to me that some people want the ASL/AGL boundary to be higher than others-- what I'm having trouble seeing is why one would tie that to atmospheric pressure, rather than height above terrain.

In the above scenarios, what aspect of the problem wouldn't be solved simply by adjusting the relevant threshold sliders?

[VoidCosmos]

This mod works like a charm, @Snark

[DMagic]

2 hours ago, Snark said:

Sure, but there's nothing magical about the division between "high space" and "low space".  In most cases, that boundary is way higher than any mountains the body possesses, i.e. to the point that terrain is irrelevant.  On the Mun, for example, I think it's at 60 km, which is around 10x higher than the Mun's highest elevation.

The high/low space/flying value probably isn't very helpful. But KSP does have some more useful data about this sort of thing.

CelestialBody.minOrbitalDistance will give you the lowest safe orbit (which, if you subtract the body radius gives you the highest point on the surface), I'm not sure about bodies with an atmosphere (I think that value will just come back with the atmosphere height), but there is also the FinePrint utility method, CelestialUtilities.GetHighestPeak that will tell you the highest point. Basic Orbit uses this data to trigger the display of radar altitude when in orbit. Considerations could also be made about the threshold level based on being in orbit vs being sub-orbital, or in flight.

[Snark]

13 minutes ago, DMagic said:

CelestialBody.minOrbitalDistance will give you the lowest safe orbit (which, if you subtract the body radius gives you the highest point on the surface)

Oooh, interesting.  Didn't know about that one, handy to know!

Though I'm still not sure how I'd use that for sure.  Just because I'm at a body that happens to have one high mountain on it, that isn't relevant to me unless I'm imminently about to smash into it-- I could orbit and orbit and orbit, for a long time, without coming close to it.  (Forever, if its latitude happens to be greater than my orbital inclination.)

One thing that does occur to me is that I could provide a bit of "lookahead" when doing the "how many seconds until terrain collision" calculation, i.e. check where the orbit calculator puts me 1, 2, 3, etc. seconds in to the future (up to some reasonable limit), and checking the ground height there, rather than simply using the ground height under the ship right at the moment.

That would provide earlier warning if I'm heading towards a crater wall or steep mountain cliff that's suddenly looming up in front of me.

Hmmm, let me think on that.  It obviously would have to be handled with a certain amount of care (so as not to spam the CPU with excessive calculations), so there will be a bit of code complexity involved, but just off the top of my head it seems like it ought to be reasonably doable.  And wouldn't require any new settings or configuration-- it would simply "get smarter" about upcoming terrain.

[DStaal]

50 minutes ago, Snark said:

One thing that does occur to me is that I could provide a bit of "lookahead" when doing the "how many seconds until terrain collision" calculation, i.e. check where the orbit calculator puts me 1, 2, 3, etc. seconds in to the future (up to some reasonable limit), and checking the ground height there, rather than simply using the ground height under the ship right at the moment. 

I was wondering about that - I'm rarely going straight down, unless my parachutes have already fully deployed.  (And not even always then.)

[Snark]

2 hours ago, DStaal said:

I was wondering about that - I'm rarely going straight down

Me neither. 

The project-trajectory-forward thing is unambiguously "better" (in the sense of being more accurate), I think-- the reason I didn't already do it was mainly that it's more work, and I've found that the current approximation tends to be "good enough" in most cases.

But the notable case where it might not be (e.g. heading straight at a cliff wall) might be a useful thing to know...

[ioresult]

21 hours ago, Snark said:

In the above scenarios, what aspect of the problem wouldn't be solved simply by adjusting the relevant threshold sliders?

Okay, @Snark, you win the argument this time! I guess I'll just have to push the sliders to the right! 

[Tonka Crash]

I haven't had complaints with autoAGL yet in it's default settings.

It sounds like people really want a ground proximity warning system. Despite the title it indicates it functions for vacuum landers. I have no idea how well this works. I just saw this discussion and wondered if there was a mod for that.

 

[Snark]

Hi all,

I'm pleased to announce the release of AutoAGL v1.1, now with path projection! 

This feature looks a few seconds ahead of the ship, so that if you're cruising along and suddenly there's a mountain rising up in front of you, it'll switch to AGL mode several seconds earlier than it otherwise would have, in anticipation.  It's not a "proximity warning" system, but it should make it a bit friendlier so that you don't get just a brief burst of AGL mode while you're cruising right over the mountain peak.

The feature is enabled by default, but I've added a new checkbox to the options dialog that allows you to disable the feature, if you are so inclined:

...it's that "Enable path projection" down there at the bottom.  Unchecking it causes the mod to revert to v1.0 behavior, i.e. looking solely at the ground elevation directly under the ship's current position.

No action is needed on your part-- the feature just makes the mod a bit smarter about when to switch to AGL, is all.

Enjoy!

(Thanks to @DMagic for providing expert coding advice about how to work with surface elevations.)

[Snark]

Hi gang,

Just a note that I've released AutoAGL v1.2.  No new features, just a compatibility update for KSP 1.8.

[angelix]

can we have configurable flat altitude settings(like if in range 0-100000 set mode to AGL)?

Edited July 12, 2020 by angelix

[Snark]

20 hours ago, angelix said:

can we have configurable flat altitude settings(like if in range 0-100000 set mode to AGL)?

It's not a bad idea, will bear it in mind-- thank you for the suggestion.

Not guaranteed to happen, though, and definitely not soon, as, 1. it would take some time to implement (and IRL is kinda busy), and 2. it's not a feature I would actually use myself, ever, and 3. I tend to be very parsimonious about features, as a design philosophy, especially when there's UI impact-- which tends to make me reluctant to add features for which I don't have a strong use case.

Like I said, though, I'll bear it in mind, and perhaps at some point in the future.