[1.12.x] BetterBurnTime v1.10: Provides extra burn-time indicators on the navball for suicide burns & target rendezvous.

[Jognt]

Just read the last two pages to get an idea of 1.4.1 compatibility/current issues and I have to say:

I expected a lot more... snarky replies to people asking questions (see what I did there?). How dare you be kind and considerate!

Thanks for being awesome and making/maintaining this can't-play-without mod.

[Hotel26]

Two questions.  SpaceDock says CKAN, but I can't find it there.  It also says it supports 1.4.1 now (attaboy!).  Does this same (latest) version still support 1.3.1?  Thanks!

[Snark]

22 hours ago, Hotel26 said:

SpaceDock says CKAN, but I can't find it there.

That's not a question. 

I don't know anything at all about its status on CKAN; I never use CKAN myself, have not the slightest inkling how it works.  The sum total of my involvement with CKAN is that I check the little checkbox for CKAN when I'm making a new mod.  So, there you go, you know know as much as I do.

22 hours ago, Hotel26 said:

It also says it supports 1.4.1 now (attaboy!)

Not much of an "attaboy", really-- I didn't really have to do anything to it.  I suspect I could have just marked it as 1.4.1 compatible without actually touching it.

22 hours ago, Hotel26 said:

Does this same (latest) version still support 1.3.1?

My guess would be yes, but since I never bother running old versions of KSP and certainly don't ever take the time to test any of my mods there, I'm not the best person to ask.    "Try it and see," is my advice.  I suspect it'll be fine.

[Quoniam Kerman]

Better Burntime is one of the most useful simple mods for those who want to begin to use mods in KSP. It changes only one thing: the infamous brun time prediction that is never accurate in the stock game and can come quite infuriating since in stock you need to use the engines to know how long a burn will last and it automatically render your maneuver node obsolete in some cases. So BBT is nice since it indicates the real burn tme whether your engines are running or not and keeps track of your thrust limitation setup as well.

Othoer nice interesting parameters it adds are the time to rendez-vous, time to rentry, time to exit atmo, time to impact, so many informations you can use with your burning time to execute a perfect rendez-vous or asteroid catch...

It makes life so easier ! One of the things we wish the stock game was equipped with...

[shachar2like]

I have a problem with the time-to-impact timer.

1. when engine power was insufficient I didn't get a warning (a red text warning or blinking red "time to crash"  would be nice. edit: thinking about this more an advance warning version would have a warning sound. real airplanes that I've seen on the discovery channel for example have two warning beeps then a "pull up!" voice. I'm thinking more of a voice warning in the background {two beeps like in a plane or an alarm sound} along with text and a voice, something like "crash imminent" or "rapid disassembly, imminent" )

2. the timer is incorrect by a large margin, I was under the assumption that this is an exact timer now I'm guessing that I should burn at halfway to impact AFTER the deadline...

 

if I were to see the same timer on a planet with atmosphere, how would that effect the result?
you might put an option to enable it for planets with atmosphere saying that it's incorrect or a beta feature

Edited April 8, 2018 by shachar2like

[Snark]

On 4/8/2018 at 4:48 AM, shachar2like said:

when engine power was insufficient I didn't get a warning (a red text warning or blinking red "time to crash"  would be nice. edit: thinking about this more an advance warning version would have a warning sound. real airplanes that I've seen on the discovery channel for example have two warning beeps then a "pull up!" voice. I'm thinking more of a voice warning in the background {two beeps like in a plane or an alarm sound} along with text and a voice, something like "crash imminent" or "rapid disassembly, imminent" )

Well, a couple things.

First... I generally don't mod anything with sound, ever, mainly because I tend to play KSP with the sound turned off anyway so there's nothing in it for me; it's simply not worth it to me to climb that particular learning curve and then code it into the mod. 

Second, it's a philosophical thing with me.  I like minimalist mods that only provide what they have to and nothing else.

It's not completely clear what exactly you mean when you say "engine power was insufficient".  Maybe you mean "TWR is lower than local gravity so it's physically impossible to land on this body with this ship, ever, so you're doomed no matter what".  Or maybe you just mean "you're descending so fast and have so little time left that even if you maxed the burn right this instant you'd crash anyway."  Or maybe you meant something else.  But the point is... a warning at that point would be useless.  If you have a craft in a situation where it's going to die no matter what... what's the point of having an alarm or an alert?  The purpose of an alert, in my world, isn't to add drama or atmosphere-- it's to allow the user to do something about their predicament.  So if it's already too late to do anything about it, there's little point in issuing an alert.

(Besides, as far as I'm concerned, it already has what amounts to a warning.  If you see "Impact in 5 seconds" and it's telling you that you need a 30 second burn... yeah, you're toast.)

It may be, though, that I've misconstrued what you've said.  If you can describe exactly the situation you have in mind, and exactly the UI experience you'd like to see, then I could better respond (either with a "hey yeah, great idea" or with a "no, I prefer not to because <reason>").

On 4/8/2018 at 4:48 AM, shachar2like said:

the timer is incorrect by a large margin, I was under the assumption that this is an exact timer now I'm guessing that I should burn at halfway to impact AFTER the deadline...

It's not that it's incorrect, it's that you're misinterpreting what it means.  I can see how this might be something that's easy to get confused about, which is why I specifically call out what's going on in the OP of this thread (perhaps you missed it):

On 11/21/2015 at 3:28 PM, Snark said:

Note that the time-to-impact is based on the assumption that you don't do a retro-burn and just coast to your doom.  So if you're figuring out "when do I start my retro-burn to land," you'll generally want to wait a little bit after the point at which time-to-impact equals estimated burn time.

So, the mod isn't wrong.  It simply is doing a very simple calculation, that isn't as sophisticated (and useful) as what you'd like it to do. 

What you'd like it to do is show you a countdown indicator that tells you exactly when to start your burn to do a surface landing, right?

That would be really useful, sure.  It would even be doable-- I've got a good idea in my head how I'd go about coding it.  But it's quite a large chunk of work to do right, and I've found that I can manage to land reasonably well with the current behavior, which is why I haven't yet gotten around to adding the (very complex) code to add such functionality.  That's why the impact tracker deliberately does not show any countdown timer:  it doesn't actually know when you should start your burn, so it doesn't lie to you by telling you when you should.

On 4/8/2018 at 4:48 AM, shachar2like said:

if I were to see the same timer on a planet with atmosphere, how would that effect the result?
you might put an option to enable it for planets with atmosphere saying that it's incorrect or a beta feature

Nope.  It deliberately doesn't give any impact indication at all on worlds with atmosphere, because it turns out that's really hard.  When I was first writing the impact tracker, I actually did try to enable it for atmosphere... and the results were so horribly, laughably wrong that I concluded "no, I can't release this, even as a 'beta'."  It would be doing you a disservice if I had.   So I just shelved it, and locked the functionality to apply only to vacuum worlds.

That's not to say that I might not revisit the idea again sometime in the future-- but I've dabbled with it enough to know that getting it to be accurate enough to be useful, helpful, and reasonably reliable would be a very big coding and testing job, so my motivation there is very low (especially since I can land fine without it, if there's an atmosphere).

So, a landing indicator for atmospheric worlds isn't impossible, it's at least conceivable I might add it someday.  But it's low on my priority list and won't be any time soon, so don't hold your breath. 

[shachar2like]

Let's start from the start:

issue 1: I was trying a mun landing with an experimental lv-atomic engine. the engine weights 3.5 tons and has a thrust of 60kn.
when coming in for landing the burn time was at 45 or 47 seconds, when trying to burn when I had 45-47 seconds to (impact) the burn time remained the same all the way to impact.
so I've tried again, I believe I've tried only once or twice because I've already figured out it might not be enough but still. I've tried burning when I had a lot more time to (impact? I don't remember the phrasing you've used) and then I figured out that it's not enough thrust because the timer remained the same all the way to impact (it even increased by a bit)

a little change to detect such a situation would have been nice, something to notify me that I'm dump and should think of another solution quickly before collision/impact...

 

issue 2: I do not completely understand the burn time and how to use it. you've indicated to wait a bit (I assumed a second) before starting to burn (which again I assumed to reach touch down). is the burn time calculated to "land" you at 100m from the ground or something like it?
this would make people understand it better.

 

as for issue 1. while I had a single engine and no alternative other people MIGHT have more engines which are turned off or an emergency abort rocket or something. just an indication that I don't have enough thrust or some other indication would have been enough. although I had no other course of action it would have been a nice indication to know that (hey! you're dumb and you're going to crash!). I've already tried a couple of (unsuccessful) mun landing because of various issues, it would have been nice to know the issue from the first try and at least not have to repeat it...

[severedsolo]

5 hours ago, shachar2like said:

(I assumed a second)

In fairness, the first page is not very clear about this (Snark did address it in another post, which is how I know this, but I get why you are confused).

As Snark said, the "time to impact" and "burn time indicator" are "wrong", but they are predictably wrong. (Note: They aren't actually wrong, they just don't do the calculation you want them to do. They assume you aren't going to burn at all (I think, can't find the original post that gave me this info), so they are right "right now" but become wrong the moment you start your burn).

Anyway: they are predictably wrong because you can get it "close enough" if you pay attention. What you need to do is start your burn at 60-70% of the "estimated burn time". I usually do two suicide burns, one at 70% of the "initial fix" and then another at 70% of the "new fix" - that gets me to landing velocity within 200m of the surface and I can then coast down.

Example (numbers plucked out of my bottom):

BBT tells me I need to burn for 30 seconds - I start my burn at "Time to impact: 21 seconds" - (0.7*30) - when my velocity gets down to about 12m/s I cut the engines. Now because I've been burning, and I was conservative with my burn - I'm not close enough yet.

So I check the readout again, now it says I need a 10s burn. So I start another full throttle burn at 7s to impact (10*0.7) - this time I get down to landing velocity within 200m of the surface (153 if I remember correctly from the last time I did it) - at which point I throttle down and start my low powered descent as I would anyway for a soft touchdown.

Now it's worth noting that you can actually start your burn at around 60% of the estimated burn time - however in my experience this needs a) razor sharp reflexes (I've blown the engine up a couple of times because I came in a little hard) and b) the terrain calculation needs to be 100% accurate (and it rarely is, because BBT just looks at whats directly below you, and we all know that most airless bodies have variable terrain) - so I use 70% because that's a bit conservative, but ALOT better than if I do it manually.

[shachar2like]

7 minutes ago, severedsolo said:

As Snark said, the "time to impact" and "burn time indicator" are "wrong", but they are predictably wrong. (Note: They aren't actually wrong, they just don't do the calculation you want them to do. They assume you aren't going to burn at all (I think, can't find the original post that gave me this info), so they are right "right now" but become wrong the moment you start your burn).

Anyway: they are predictably wrong because you can get it "close enough" if you pay attention. What you need to do is start your burn at 60-70% of the "estimated burn time". I usually do two suicide burns, one at 70% of the "initial fix" and then another at 70% of the "new fix" - that gets me to landing velocity within 200m of the surface and I can then coast down.

So the original post or explanation should be rephrased to say something like: This is an estimated burn/impact time NOT an exact "suicide burn maneuver"
then you can go on explaining in more technical details about terrain height & that precise calculations would take too long to do and stuff.

Edited April 10, 2018 by shachar2like

[Snark]

3 hours ago, shachar2like said:

So the original post or explanation should be rephrased to say something like: This is an estimated burn/impact time NOT an exact "suicide burn maneuver"
then you can go on explaining in more technical details about terrain height & that precise calculations would take too long to do and stuff.

Except that the OP is already pretty long, and I fear that making it any longer would, as you have already demonstrated here cause people to not actually read it, or to skim it and miss the explanation, or whatever.  I'm not going to insert long technical explanations there.

At no point in the OP does it say that it is an exact "suicide burn maneuver" timer-- I'm very careful never to say that anywhere.  I only say literally exactly what it does, and I also go out of my way to include a cautionary note for the impact tracker,

On 11/21/2015 at 3:28 PM, Snark said:

Note that the time-to-impact is based on the assumption that you don't do a retro-burn and just coast to your doom.  So if you're figuring out "when do I start my retro-burn to land," you'll generally want to wait a little bit after the point at which time-to-impact equals estimated burn time.

...which is literally exactly what the player needs to know, and I fail to see how anyone who's paying attention and actually reading the post could be misled.  I can't make it any plainer than that.  And if someone's not reading the message, then it doesn't matter what I say and no explanation would help. 

In general, I think the empirical evidence thus far is that the current messaging works pretty well.  The mod has had nearly a quarter of a million downloads on SpaceDock, and in the more than two years that the mod has been out there, I've had maybe two or three people ask me questions such as yours in spite of the explanation.  So, I'm sorry that the explanation didn't work well in your case-- but given that the current messaging seems to work for literally over 99.99% of users, I think I'll stick with it for now.  I'd prefer not to mess with a working formula.

I don't think it's physically possible to guarantee that literally nobody will ever make a mistake over the course of hundreds of thousands of downloads, so in the very rare cases where someone "slips through the cracks", as you did, then they can always ask about it here, as you did, and I'm happy to explain, as I did. 

Basically, it's one of those "you can't have everything" situations.  Make an explanation more detailed, and you'll make it clearer to some people-- but then discourage other people from reading the explanation at all.  It's a balance, and sometimes less is more.

In any case: I do appreciate the feedback (even if I don't always choose to take action on it)-- thank you for taking the trouble to make the suggestion, and I'm sorry that the way I've presented the information in the OP didn't work well for you.

[shachar2like]

On ‎10‎/‎04‎/‎2018 at 8:16 AM, shachar2like said:

Let's start from the start:

issue 1: I was trying a mun landing with an experimental lv-atomic engine. the engine weights 3.5 tons and has a thrust of 60kn.
when coming in for landing the burn time was at 45 or 47 seconds, when trying to burn when I had 45-47 seconds to (impact) the burn time remained the same all the way to impact.
so I've tried again, I believe I've tried only once or twice because I've already figured out it might not be enough but still. I've tried burning when I had a lot more time to (impact? I don't remember the phrasing you've used) and then I figured out that it's not enough thrust because the timer remained the same all the way to impact (it even increased by a bit)

a little change to detect such a situation would have been nice, something to notify me that I'm dump and should think of another solution quickly before collision/impact...

as for issue 1. while I had a single engine and no alternative other people MIGHT have more engines which are turned off or an emergency abort rocket or something. just an indication that I don't have enough thrust or some other indication would have been enough. although I had no other course of action it would have been a nice indication to know that (hey! you're dumb and you're going to crash!). I've already tried a couple of (unsuccessful) mun landing because of various issues, it would have been nice to know the issue from the first try and at least not have to repeat it...

I didn't quiet understood the original phrasing but fine, we'll drop it.

what about this issue and this specific case?

[Snark]

10 hours ago, shachar2like said:

what about this issue and this specific case?

I can certainly see how the situation would be annoying to you, so it's a reasonable request you're making-- I'm not disputing that. 

However... basically, you're asking BetterBurnTime to do things that it simply doesn't do, now.  And the reason it doesn't do them is, 1. to give you what you actually want would be a very large and complex technical task that would take up a lot of my time, and 2. it's really not necessary if the player understands how rockets work and what the numbers mean.  Bear in mind that BetterBurnTime is not intended to be an autopilot, or to be a substitute for navigational skills.  It simply provides some numbers that a player would otherwise simply not have access to.  The philosophy of BBT is:  pick out a very few (but very important) numbers that the player otherwise would just have to guess at, and provide those numbers in a useful place, and leave it up to the player to interpret the numbers and decide what to do about them.

So from your point of view, you're asking for a feature that you really want that you would like, which is perfectly reasonable of you.  But from my point of view, it's asking me to commit a very large amount of coding time for a negligible benefit while going against the philosophy of BBT that's why I wrote it in the first place.

10 hours ago, shachar2like said:

the engine weights 3.5 tons and has a thrust of 60kn.
when coming in for landing the burn time was at 45 or 47 seconds, when trying to burn when I had 45-47 seconds to (impact) the burn time remained the same all the way to impact.

Ding ding ding ding ding.

That's your great red warning sign, right there.  If you're burning at full power and your estimated burn time at impact isn't dropping... it means you're in bad trouble right now.  As should be obvious to the player, assuming they understand what the numbers mean and how to use them.  (Which of course is a perfectly reasonable assumption, because the mod is a tool, and nobody should use a tool if they don't know how it works.  If they choose to use the tool anyway, then that's the user's choice-- nothing the mod author can do about that.)

As the OP makes perfectly clear, that "estimated burn time" on the impact tracker is telling you, in practical terms, Here's how fast you're going to hit the surface, projecting your current trajectory.  If it says "45 seconds", that means "your current trajectory would have you slam into the surface at a speed that's equal to 45 seconds of continuous thrust."  Which means if you burn, you should see that number go down (because you should be reducing your speed, which means the how-many-seconds-of-thrust-will-my-impact-speed-be should be going down, too).  If you're burning and the number isn't changing, it means something is badly wrong and should be a flashing red alarm bell in your brain.

In your brain.

Not in the mod.

Why?  Because it's a pattern.  And patterns are vague, and fuzzy, and human brains are very good at interpreting them, and computers absolutely suck at it.  The numbers can fluctuate all over the place.  Your brain needs to be looking at a pattern of rate of change of the numbers that is different from "normal" or "usual" or "expected"-- on the general principle of "anything different is bad".  And it's easy to do this, for a human; we're wired for it.  Anybody who plays with BBT and makes a few vacuum landings with it is going to fairly quickly start to see patterns there-- "when I burn like this, the numbers change like that, and here's the situation that results."  You may say, "But I'm having trouble interpreting those patterns," in which case I'm sorry-- just means some more practice is needed.  However, consider that if you (with your enormously powerful pattern-matching supercomputer in your head) have trouble with this, why do you think a pinheaded mod developed by one guy in his spare time is going to be able to do it?

There is a whole set of complicated variables going on during a vacuum landing.  Some of these are easily accessible to the mod; others aren't.  You may be approaching the ground steeply or shallowly; you may have high or low TWR; the terrain may be flat, or sloping up, or sloping down, or alternating between up/down slopes; you may be intending to switch on other engines later, or you may not; you may have ballast you can drop, or you may not.  Just the terrain fluctuation alone can cause all kind of distortions in the pattern-- if I tried to program BBT to sound an alert because "the pattern of the number dropping isn't good", how the heck do I define "good"?  I can't just pick a number and choose "above or below this number"-- it would be giving false negatives and false positives all the time when the terrain fluctuates, and would therefore be worse than useless to the user by lying to them.

I'm not going to write a mod that lies.  If I'd like to provide a number... but it's not a reliable one and is wrong in unpredictable ways.... then I'm not gonna provide that number.  Do not want.  I'd be doing my users a disservice.

So, in short:  In your situation, you did get an alarm; you simply hadn't learned how to interpret it.  The alarm was "hey, my estimated burn time isn't dropping the way it should", as displayed in those two numbers.  The solution isn't for me to write a bunch of code, taking a huge amount of my time to generate results that will often be wrong and kill kerbals.  The solution is to learn how to interpret the numbers, e.g. "I want my time to impact to be about 60-70% of the estimated burn time."  That rule of thumb will tell you when to start the burn, and how to adjust the throttle during the burn, if necessary.  Just takes a little practice.

10 hours ago, shachar2like said:

a little change to detect such a situation would have been nice, something to notify me that I'm dump and should think of another solution quickly before collision/impact...

Sure, that would be nice.  Except that it would be a large change, and it would be unreliable to you.  Which is why I haven't done it.

10 hours ago, shachar2like said:

while I had a single engine and no alternative other people MIGHT have more engines which are turned off or an emergency abort rocket or something. just an indication that I don't have enough thrust or some other indication would have been enough.

"Hey, my estimated burn time isn't dropping as I burn!"

^ There's your warning right there.

Also, quite aside from any  info that BBT provides you... simply from what the stock game gives you, your eyeballs should have been grabbing hold of your brain and yelling "HEY, WAKE UP, I'm getting closer and closer to the surface and WOW I'm still going really really fast and I don't seem to be getting slower and this looks like I'm gonna crash."

Which means "okay, I'm doomed, either I need to pull a miracle out of a hat, or else revert and try something else."

Again:  BBT is not intended to be an autopilot.  There are other mods for that.

Also, it is not intended as a spacecraft design aid.  If the player has only got a tiny engine on a massive ship, and they're heading towards a planet or moon whose surface gravity is greater than the acceleration of the ship under maximum thrust... well, in my book, that's entirely the player's mistake for using that ship for that mission in the first place.  If their ship's TWR isn't high enough to counteract the Mun's surface gravity... don't go to the Mun, or else redesign the ship.  It's basic diligence in the vehicle editor.  "Where do I want to land this thing?  Okay, what's the gravity there?  Okay, take my kN of thrust and divide by my ship mass.  Is it sufficiently bigger to be reasonable?  No?  Okay, back to the drawing board."  Takes a couple of seconds with a pocket calculator.  Or, for players who don't like doing manual calculations, there are always mods like KER to help with that sort of thing.

 

10 hours ago, shachar2like said:

other people MIGHT have more engines which are turned off or an emergency abort rocket or something

Sure.  And when a person can see (from the numbers, and from the way things are moving on the screen) that this is an uh-oh situation, that's when they would engage any such emergency measures.

10 hours ago, shachar2like said:

just an indication that I don't have enough thrust or some other indication would have been enough.

Sure.  It also would be a much harder technical problem to deliver that warning than you realize.  (Which is not a criticism; it's simply because you're neither a computer programmer nor a physics major, which describes over 99% of the population, so you're in good company.)   It's just one of those problems that looks simple but is actually a lot more complex than you'd think, once one starts delving into the technical minutiae.

I've actually given some thought to making the impact tracker better.  There are things it could do that would make for nicer numbers, even without trying to do any of that sort of fancy "pattern matching" that humans are so good at and which computers aren't.  I've got the algorithms worked out in my head, I've got a mental framework of what the code would look like, all I'd need to do would be to sit down and code it.  It would provide a better, more useful experience for the impact tracker, and would (I suspect) have the side effect of solving the problem that you've got here.  The enhancements I have in mind are totally doable.

But they'll be a time sink, and I'm pretty busy, and this is something that's just a hobby and eats into my very scant free time.  Also, the problem that it would be solving is one that I, myself, don't have, since I find I can land just fine with the current implementation.  This latter point is highly relevant, due to the "hobby eating into scant free time" thing-- I primarily mod for myself, to solve issues with the game that bug me, and then I share my mods publicly on the chance that what bugs me might be bugging other people too.    Generally it tends to work out pretty well that way.  But it means that spending large amounts of time solving a problem that I, personally, don't have (even if lots of users do) is something that I simply don't have a lot of motivation to do.

If making these enhancements were something quick and easy, I'd probably just go ahead and do 'em.  However, given that it would be a large investment of effort for me, in return for solving a problem that I don't have and that isn't a blocker for anyone who practices vacuum landings a bit... well, that doesn't mean that I won't do it, but it does tend to lower the priority of the feature-- I've got other mods to work on with things that I want more urgently than this.  When I've got more things-I-want-to-do than time available to do them, something's gotta wait in line, and this feature is one of them.

I'm sorry about that, but it's just how it is.

For anyone who's curious about the technical details of the feature enhancement I have in mind (i.e. the one I've been thinking about for over a year but have been too busy to do), technobabble in spoiler section.  I may get around to it at some point, but it'll have to wait for other stuff and I'll do it if-and-when I have time and inclination.

Spoiler

First and foremost, there is no way to make the impact tracker any better without making it more terrain-aware.

Right now, BetterBurnTime is completely ignorant of topography.  It's not projecting your impact point, at all.  When it's doing its time-to-impact and estimated burn time calculations, it's just taking the almost embarrassingly simple-minded approach of "what's the elevation of the ground directly under the ship right at this moment" (because that number is easily, cheaply, and instantly available to the code), and then making the extremely-simplified assumption that the ground is flat and level.

That works great if you're landing somewhere that actually is flat and level, like Minmus' flats... but usually the ground isn't.  Sometimes spectacularly so.  And when the ground's not level, that's going to throw off the estimate.  If the ground is sloping down away from you as you descend, then your impact time is going to be farther into the future than it's telling you.  And if the ground is sloping up to meet you... well then, impact will be sooner than it's telling you, so you'd better watch out!  That's how ships go splat.

This doesn't mean the tool is useless.  It does continuously update its estimate, so if you're flying over sloping ground, it will continuously update the estimated impact and burn times.  But this means that the player has to pay attention to the terrain and keep an eye on how the ground is sloping.  If you see that you're flying over upward-sloping ground, you know you'd better start your burn earlier.

Well... there's a way to make that better.  I could alter BetterBurnTime so that it actually does project your trajectory ahead of you, and figures out where the actual impact site would be, and uses the terrain elevation there.  This would make it more accurate.

However, it would also be a substantial programming job, because there's no simple algebraic formula to code here-- basically the code would have to numerically brute force it by sampling the elevation at multiple points along the projected suborbital path, then recursively zeroing in to find a good candidate.  That's not only a fair amount of code to write, but it's also computationally expensive and not something that I can do on every frame without slowing the player's CPU to a crawl, which means I'd need to write more code to make it update the calculations only at intervals and cache the results and so forth, so it's a chunk of work.

So... that's "level 1" of the improvement.  It would make the impact tracker better and more accurate, and would be absolutely required before further work can be done-- but it would not, by itself, be enough to give you an accurate suicide-burn countdown.  That's because it would only be giving an accurate impact prediction if you leave your engines off and coast to your doom, which of course is generally not what the player wants to do.  You want to land, not just proceed to a highly-accurately-predicted lithobraking.    Which means you're going to be turning on your engines.  And the moment you start your burn, you're going to be altering your speed/direction profile, a lot, so that the projection of your future trajectory under thrust will be completely different.

Which means that to enable the "accurate suicide burn countdown" feature, what I'd have to do is first implement "level 1" as described above... and then do an even bigger chunk of work to implement level 2, which would be this:  as the ship descends, repeatedly do calculations where it says "okay, suppose I start a burn right now, let's simulate the physics and predict where the ship will go by doing a highly iterative, very computationally expensive set of calculations to simulate the descent.  And then re-do that calculation frequently during the entire descent phase to correct for any errors that accumulate along the way.  And somehow do all of that without utterly hosing the player's CPU."

That is probably reasonably doable, to at least a reasonably close degree of fidelity.  It would allow me to add a set of "countdown timer" dots to the impact tracker, the same as it currently has for the maneuver-node tracker and target-rendezvous tracker, so that ideally all you'd have to do is basically exactly what you want:  wait until the dots count down to zero, and then hit the gas.  (And if its projection shows that there's no way for you to land because you're underpowered or whatever... that would, of necessity, pop out of the calculations, and I could just show an "N/A" instead of a set of dots for the countdown timer, or something.  Which would give you exactly the warning you want.)

So yeah, such a feature would be kinda neat.    But it would be a big programming job.  And also a very tedious testing job.  And also there's a significant chance I could put in a few weeks of work, and get it implemented, and only then discover that I just can't get the CPU usage low enough to make the feature both accurate and usable, in which case I'd have to just scrap it and would have spent all those weeks of work for nothing.  And it's all to solve a "problem" that I, myself, don't actually have in my own gameplay, since I find that I can land just fine in the current implementation.

So... hopefully that kinda gets across why doing something like this isn't super high on my priority list, relative to other stuff.

 

 

Please understand, in all of the foregoing, that I'm not even slightly criticizing you, or your skills, or your preferences, or your play style, or anything else.  At all.  KSP is a wonderful, flexible game that allows for a variety of play styles-- which means that different players want and expect very different things.

One player's "fun challenge" is another player's "tedious chore" is another player's "game-breaking impossibility".  Let's say the task is "launch ship to LKO."  Some players find that a tedious chore because they just want to get on with what they think of as the real fun, which is playing out their "space colonization story", and the umpteen-hundredth rocket launch to LKO is just a hassle.  A player like that may therefore run MechJeb, so all they have to do is push a button and it flies the ship to orbit for them.  But for a different player... flying it to orbit is itself the fun, which means that not only do they not need MechJeb, but it would actually ruin the game for them.

One player's "necessity for fun" is another player's "game ruiner".  And neither player is wrong; neither of them is any "better" than the other.  It's just that different people want different things out of the game.

One of the aspects in which players vary, a lot, is "how much automation do you want."  It's a spectrum, and where you fall on that spectrum is going to affect how you want things done.  Myself... I happen to fall fairly far out on the "don't want automation" end of the spectrum.  Which means I will never, ever use mods like KER or MechJeb-- not because there's anything wrong with them (I hear they're great), but simply because they would ruin the game for me.  And I wrote BetterBurnTime because it fills a niche for players like me:  I wanted something that would give me more (and better) numbers than the stock game does, but not too much information because I want the game to stay challenging to me and there's stuff that I want to do, myself, with my own two hands as a player, rather than having a mod do it for me.  There wasn't a mod for me that did that, so I wrote one that would. 

So, that philosophy is baked pretty hard into BBT:  it's a mod that's designed for players like me.  Doesn't mean I'm saying "that's the right way to be", just that it's my mod so it's going to do the thing that I myself want, as a player.  People who want more and fancier automation are probably going to find it lacking-- perhaps MechJeb could be a useful alternative.

So when I give you all these reasons "here's why I think it's not reasonable for BBT to give you what you asked for"-- it's really not saying that you're being unreasonable to want those things.  It's just saying that that's not really what BBT's intention is.  BBT is targeted at a very specific type of player, and that player is me.    I've been pleasantly surprised at how many other players turn out to be similar enough to me that they also find BBT useful.  But it's not going to be everyone's cup of tea, either now or in the future, since different players like different things.  And that's fine.

[15Redstones]

Anyone got a copy of the 1.2.2 version? It's unavailable on Spacedock, I just get an error screen.

[shachar2like]

I have a bit of background in programming (a very tiny bit, basic from the 80ies).

I assume then that you cannot simply take the current path from the game and use that... What I would have done is done the suicide burn calculation with say something like +100 height elevation and let people deal with the rest. that keeps your job simple.

if you need to compute the TWR and all of the other "curses" from scratch then I'll simply ditch the warning idea although I do suspect you can do a simple one with the current code and maybe change the text warning to something more along the line of "check thrust"

 

I've read some of your other posts and you do seem to be an experienced programmer. you don't have to do everything perfectly, if you can't get the current course from the game then that's simply too much of a job, you're basically writing a small engine to predict stuff...

[DStaal]

2 minutes ago, 15Redstones said:

Anyone got a copy of the 1.2.2 version? It's unavailable on Spacedock, I just get an error screen.

That's a misstatement of the problem: It's not that that the version for 1.2.2 is unavailable on SpaceDock, the problem is that SpaceDock is down.

Hopefully by the time anyone could find a personal version of the 1.2.2 version, SpaceDock will be back up.

29 minutes ago, Snark said:

So yeah, such a feature would be kinda neat.    But it would be a big programming job.  And also a very tedious testing job.  And also there's a significant chance I could put in a few weeks of work, and get it implemented, and only then discover that I just can't get the CPU usage low enough to make the feature both accurate and usable, in which case I'd have to just scrap it and would have spent all those weeks of work for nothing.  And it's all to solve a "problem" that I, myself, don't actually have in my own gameplay, since I find that I can land just fine in the current implementation.

So... hopefully that kinda gets across why doing something like this isn't super high on my priority list, relative to other stuff.

And by the time you're doing that, you've pretty much built a full autopilot into this mod, so why not just have the player use MechJeb?

...And come to think of it, even MechJeb doesn't do the full modeling and calc you're talking about here.  It does landings in multiple stages - and the main decent stage stops quite a bit above the surface.  So it can take an average height over an area, calculate to +$dist$ over that, and then it cancels horizontal velocity, so the final landing calculation is much simpler as the terrain height won't change.  You just have to assume the player won't specify a highly-sloped landing zone.  (And I've seen MechJeb mess up with extreme elevations - especially when landing below 'zero' altitude.)

[DStaal]

11 minutes ago, shachar2like said:

if you need to compute the TWR and all of the other "curses" from scratch then I'll simply ditch the warning idea although I do suspect you can do a simple one with the current code and maybe change the text warning to something more along the line of "check thrust"

Quick question: How does that actually help?

If you're landing and not firing all engines you reasonably can, you're wasting fuel.  So telling the player that they don't have enough thrust at that point...  Says that they designed the ship wrong, or shouldn't be trying to land it on this planet.  Which isn't something they can do anything about at that point, besides reverting.

Basically it would be a warning light saying 'you're about to die, and there's nothing you can do about it'.  Which is kind of pointless - warning you doesn't help.

[shachar2like]

2 minutes ago, DStaal said:

Quick question: How does that actually help?

If you're landing and not firing all engines you reasonably can, you're wasting fuel.  So telling the player that they don't have enough thrust at that point...  Says that they designed the ship wrong, or shouldn't be trying to land it on this planet.  Which isn't something they can do anything about at that point, besides reverting.

Basically it would be a warning light saying 'you're about to die, and there's nothing you can do about it'.  Which is kind of pointless - warning you doesn't help.

I really don't want to repeat everything I said but I'll try to summarize it up:

1. people are stupid, what's why you use a user friendly OS like windows and not something else
2. stupid people not realizing and not being sure what went wrong will load and repeat the same process again, wasting time. (and not being user friendly when you could just told them: "hey stupid! you're an idiot and you're going to crash!"
3. while most of the time you'll have no other choice some people might have other choices be it other turned off engines, abort systems, ejecting Kerbals or whatever
4. the last point being is that it's more user friendly when something tells you you're going to crash instead of giving you a bunch of numbers: calculate weight/what you have left to get the twr * your velocity * your height * your new height / you're not dead

[Snark]

1 hour ago, shachar2like said:

take the current path from the game

Trivially easy.

1 hour ago, shachar2like said:

and use that

Super difficult and hard.  Weeks of work, super computationally expensive, requires clever design to avoid bringing the player's computer to its knees by hogging the CPU, probably requires configurability options so that players on different kinds of computer can adjust the accuracy-versus-performance tradeoff.

In short, a large job.

1 hour ago, shachar2like said:

done the suicide burn calculation

Hard, computationally difficult, requires tricky design, etc.

1 hour ago, shachar2like said:

that keeps your job simple.

No, it doesn't.  It's a hard problem.  Unless, of course, you use an overly simplistic algorithm that's quick and cheap and easy to code and doesn't use a lot of CPU and gives wrong results that kills your users' kerbals and then a torch-and-pitchfork-wielding mob shows up on your doorstep wanting to know why your mod lied to them. 

Look, when I say "this is hard," I mean it, okay?  I'm a physics major who's been working as a professional software engineer for nearly a quarter-century and who has a fair amount of experience modding KSP.  So I've got at least a reasonable clue what I'm talking about, here.

You can just take my word for it that "this is a lot harder than you think it is", or I can start going into a few pages' worth of dense physics-and-math-and-computer-algorithm technobabble that will basically just boil down to "yes, it's really hard."

1 hour ago, shachar2like said:

if you need to compute the TWR and all of the other "curses" from scratch

Static TWR is trivially easy to calculate.  Dynamic time-variable TWR during a variable pitch burn on a suicide-burn trajectory... is not.  Computationally messy to predict the path.  One can write simple, computationally cheap code that gives wrong results and kills kerbals.  Or one can write simple, computationally excruciatingly expensive code that gives correct results but brings the player's computer to its knees and ruins the KSP playing experience.

Or one can maybe have both, and make sometihng that's both accurate and performant... but that takes a lot of algorithmic cleverness and a whole bunch of code and a whole lot of hours of coding and testing, and not actually find out whether it's possible to have both until after doing all the work, and if the answer turns out to be "no" then all the effort was wasted.

And unless the solution is both accurate and performant, it's worse than useless to players.  It's not to difficult to get a solution that's one or the other... but getting both at the same time is hard.

1 hour ago, shachar2like said:

change the text warning to something more along the line of "check thrust"

The wording of the alarm is not the hard part.  It's figuring out whether there needs to be an alarm that's hard.  So this isn't a solution.

1 hour ago, shachar2like said:

you do seem to be an experienced programmer.

Yep.    So perhaps give me just a little credit for having thought this through?

1 hour ago, shachar2like said:

if you can't get the current course from the game then that's simply too much of a job

No, it's trivially simple to get the current course from the game.  It's literally like one line of code.  That's not the hard part.

No, the hard part is knowing where that path is going to intersect terrain, when the terrain is a highly rugged and variable height map.  Very difficult and computationally expensive.  And if you want to do that with the assumption that you're thrusting your engine and changing your speed and direction with variable acceleration as you descend, then that boosts the difficulty of the problem to a whole new (much uglier) level.

1 hour ago, shachar2like said:

you're basically writing a small engine to predict stuff...

Ding ding ding ding ding.  That is an absolute requirement to solve this problem.  It cannot be solved analytically, it has to be done numerically.  And predicting means simulating, i.e. "You know that physics that normally KSP calculates 20 or 30 times per second?  And which normally your computer would spread the computation load over the 30-60 seconds you're doing the burn?  And which causes a lot of players to have performance problems even when they've got 30-60 seconds to do that calculation?  Do all of that, but you have to do the 30-to-60-seconds' worth of calculations many times per second"  ...nope.  Uh-uh.  That's a hard problem.  Even taking shortcuts and being smart about it and deliberately being imperfect so as to keep it (hopefully) accurate enough while saving computation... it's still really hard.

Look, if you don't believe me, perhaps go and try to code it yourself first, and then we'll talk?

1 hour ago, shachar2like said:

calculate weight/what you have left to get the twr * your velocity * your height * your new height

Nope.  Sorry, wrong, this is too simplistic and will give you wrong answers.  If you do this, there will be a large number of cases where you tell people "you're fine" when they're not and they go cruising to their doom and basically your mod has just murdered their kerbals, and also a large number of cases where you'll be sounding the alarm when actually they're fine and now you're crying wolf and irritating the players.

It's not that simple.  Really.

It's also unnecessary for the target audience of this mod.  Because the only way this simple approach could be reasonably confident about its warnings would be if it only warns when it knows that you're really seriously hopelessly doomed meaning that your mission profile is absolutely hopeless.  And the target audience of this mod is players who take the time to learn enough KSP that they can easily spot "this is a hopelessly doomed mission" without needing a mod to help them.

1 hour ago, shachar2like said:

I really don't want to repeat everything I said but I'll try to summarize it up:

Okay.

1 hour ago, shachar2like said:

people are stupid, what's why you use a user friendly OS like windows and not something else

I disagree.  I like using Windows because it's convenient, not because I'm stupid.  KSP is a game about rocket flight and rocket design.  That's not a pursuit for stupid people.  I don't think the average KSP player is stupid.  And I think that the reason for apps like KER and MechJeb is not "make stupid people able to play the game", but rather "take some aspects of the game that some, but not all, players find to be inconvenient, and make those aspects more convenient."

1 hour ago, shachar2like said:

stupid people not realizing and not being sure what went wrong will load and repeat the same process again, wasting time. (and not being user friendly when you could just told them: "hey stupid! you're an idiot and you're going to crash!"

KSP is deterministic.  If you do the same thing again, the same thing is going to happen.  No mod is going to help you with that.

A KSP player might be a "calculating" type-- i.e. carefully figure out ahead of time, via math, whether a thing will work or not.  Or they might be a more seat-of-the-pants type who uses trial and error-- i.e. try a thing, oops that didn't work, okay I'll use what I just learned to try something different and hopefully better.  There are lots of KSP players who fit into both of these categories, and BBT can work well for both of them.

However, you seem to be positing a third type of KSP player, one who's basically just a random button-masher who doesn't learn from experience and doesn't observe problems and then adjust to try to avoid them.  I think that most KSP players are not like that.  But even if there are such players... BBT is not for such people.  That's not the target audience.  I'm not writing an autopilot.  I'm deliberately, purposefully writing a mod that requires the user to think, learn, and understand.

I'm doing that because I like to think, learn, and understand.  That's what I like to do.  That's why I enjoy KSP, because it's a game that requires me to think, learn, and understand.  A mod that takes the thinking, learning, and understanding away from me would make the game less fun for me, not more.

So I write a mod for people who like to do that.  If someone doesn't like to do that, fine-- nothing wrong with that!    They can play KSP however they like.  However... this mod isn't for them, because that's not what this mod is about.  So they'd probably be better served by trying some higher-automation mod such as MechJeb.

1 hour ago, shachar2like said:

while most of the time you'll have no other choice some people might have other choices be it other turned off engines, abort systems, ejecting Kerbals or whatever

Sure!  And they can do that.  Because the target audience of this mod-- i.e. KSP players who enjoy flying by the seat of their pants, don't want too much automation, and have therefore taken the trouble to observe the numbers that BBT results and can easily interpret them-- can do that right now.  It's trivially easy.  They just glance at the numbers that BBT reports, see instantly that those numbers look unhealthy, and then activate their additional engines or whatever.

So if you want to, you can do this, too.  Simply take the time to practice a bit, and learn how to interpret the numbers, so that you can see those patterns, too, and then it's easy.  In which case BBT already does exactly what you need, and your problem is solved.

Or maybe that sounds like a hassle to you-- i.e. that would take too much time and trouble, and you want more automation in a mod so that it will do it for you.  There's nothing wrong with that-- lots of players prefer automation.  But if that's what you want... BBT is not aimed at you, so you'd probably be better served by using some mod that goes in for more automation.

[Loren Pechtel]

3 hours ago, Snark said:

Ding ding ding ding ding.

That's your great red warning sign, right there.  If you're burning at full power and your estimated burn time at impact isn't dropping... it means you're in bad trouble right now.  As should be obvious to the player, assuming they understand what the numbers mean and how to use them.  (Which of course is a perfectly reasonable assumption, because the mod is a tool, and nobody should use a tool if they don't know how it works.  If they choose to use the tool anyway, then that's the user's choice-- nothing the mod author can do about that.)

As the OP makes perfectly clear, that "estimated burn time" on the impact tracker is telling you, in practical terms, Here's how fast you're going to hit the surface, projecting your current trajectory.  If it says "45 seconds", that means "your current trajectory would have you slam into the surface at a speed that's equal to 45 seconds of continuous thrust."  Which means if you burn, you should see that number go down (because you should be reducing your speed, which means the how-many-seconds-of-thrust-will-my-impact-speed-be should be going down, too).  If you're burning and the number isn't changing, it means something is badly wrong and should be a flashing red alarm bell in your brain.

In your brain.

Not in the mod

  Reveal hidden contents

First and foremost, there is no way to make the impact tracker any better without making it more terrain-aware.

Right now, BetterBurnTime is completely ignorant of topography.  It's not projecting your impact point, at all.  When it's doing its time-to-impact and estimated burn time calculations, it's just taking the almost embarrassingly simple-minded approach of "what's the elevation of the ground directly under the ship right at this moment" (because that number is easily, cheaply, and instantly available to the code), and then making the extremely-simplified assumption that the ground is flat and level.

That works great if you're landing somewhere that actually is flat and level, like Minmus' flats... but usually the ground isn't.  Sometimes spectacularly so.  And when the ground's not level, that's going to throw off the estimate.  If the ground is sloping down away from you as you descend, then your impact time is going to be farther into the future than it's telling you.  And if the ground is sloping up to meet you... well then, impact will be sooner than it's telling you, so you'd better watch out!  That's how ships go splat.

This doesn't mean the tool is useless.  It does continuously update its estimate, so if you're flying over sloping ground, it will continuously update the estimated impact and burn times.  But this means that the player has to pay attention to the terrain and keep an eye on how the ground is sloping.  If you see that you're flying over upward-sloping ground, you know you'd better start your burn earlier.

Well... there's a way to make that better.  I could alter BetterBurnTime so that it actually does project your trajectory ahead of you, and figures out where the actual impact site would be, and uses the terrain elevation there.  This would make it more accurate.

However, it would also be a substantial programming job, because there's no simple algebraic formula to code here-- basically the code would have to numerically brute force it by sampling the elevation at multiple points along the projected suborbital path, then recursively zeroing in to find a good candidate.  That's not only a fair amount of code to write, but it's also computationally expensive and not something that I can do on every frame without slowing the player's CPU to a crawl, which means I'd need to write more code to make it update the calculations only at intervals and cache the results and so forth, so it's a chunk of work.

So... that's "level 1" of the improvement.  It would make the impact tracker better and more accurate, and would be absolutely required before further work can be done-- but it would not, by itself, be enough to give you an accurate suicide-burn countdown.  That's because it would only be giving an accurate impact prediction if you leave your engines off and coast to your doom, which of course is generally not what the player wants to do.  You want to land, not just proceed to a highly-accurately-predicted lithobraking.    Which means you're going to be turning on your engines.  And the moment you start your burn, you're going to be altering your speed/direction profile, a lot, so that the projection of your future trajectory under thrust will be completely different.

Which means that to enable the "accurate suicide burn countdown" feature, what I'd have to do is first implement "level 1" as described above... and then do an even bigger chunk of work to implement level 2, which would be this:  as the ship descends, repeatedly do calculations where it says "okay, suppose I start a burn right now, let's simulate the physics and predict where the ship will go by doing a highly iterative, very computationally expensive set of calculations to simulate the descent.  And then re-do that calculation frequently during the entire descent phase to correct for any errors that accumulate along the way.  And somehow do all of that without utterly hosing the player's CPU."

That is probably reasonably doable, to at least a reasonably close degree of fidelity.  It would allow me to add a set of "countdown timer" dots to the impact tracker, the same as it currently has for the maneuver-node tracker and target-rendezvous tracker, so that ideally all you'd have to do is basically exactly what you want:  wait until the dots count down to zero, and then hit the gas.  (And if its projection shows that there's no way for you to land because you're underpowered or whatever... that would, of necessity, pop out of the calculations, and I could just show an "N/A" instead of a set of dots for the countdown timer, or something.  Which would give you exactly the warning you want.)

So yeah, such a feature would be kinda neat.    But it would be a big programming job.  And also a very tedious testing job.  And also there's a significant chance I could put in a few weeks of work, and get it implemented, and only then discover that I just can't get the CPU usage low enough to make the feature both accurate and usable, in which case I'd have to just scrap it and would have spent all those weeks of work for nothing.  And it's all to solve a "problem" that I, myself, don't actually have in my own gameplay, since I find that I can land just fine in the current implementation.

So... hopefully that kinda gets across why doing something like this isn't super high on my priority list, relative to other stuff.

 

 

 

Huh?  If your engines can't bring you to a stop in the time it's saying you need it was saying  less time than you actually needed.  The only way I can see this happening is if BBT isn't looking at the local gravity field at all and simply figuring the burn needed to kill your velocity in open space.  In general you'll have a pretty high TWR when landing on airless bodies so this wouldn't cause too much  of a discrepancy (no doubt less than the amount it's overcalculating due to not figuring how much the rocket slows during the burn) but it's possible to have fairly low TWRs on small bodies.  I've flown stuff that lands with a TWR under 2 on the Mun (it was a ISRU-based hopper.  I made sure it could fly even with full tanks but there wasn't reason to put a lot of extra power on it.  A short hop to the biome next door and it could be landing with nearly full tanks.)

[Snark]

14 minutes ago, Loren Pechtel said:

If your engines can't bring you to a stop in the time it's saying you need it was saying  less time than you actually needed.

Yep, can easily happen.  When you first get your "here's how fast you'll be going at ground level" estimation, BBT is basing that on simpleminded calculations that assume the ground where you land will be at the same elevation as the ground where you are now.  So, for example, if you're flying over downward-sloping ground, then the place where you actually end up eventually landing might be a lot lower than it thought, meaning you're going faster than it expected you would.

I expect that normally this wouldn't be much of an issue for most people, because most vacuum landings are on fairly low-gravity worlds which means that the lander probably has a pretty high local TWR which means the landing burn will be relatively brief which means the ship won't travel all that far horizontally during the braking burn which means that the ground elevation won't change all that much during the burn.  But if someone has a pathologically low TWR (such as in the case we're discussing here)... then yeah, I could see that happening.

14 minutes ago, Loren Pechtel said:

In general you'll have a pretty high TWR when landing on airless bodies so this wouldn't cause too much  of a discrepancy

Yes, exactly.  But the example we've been discussing here isn't the "in general" case-- it's a ship with a pathologically low TWR that may actually be significantly less than 1.

14 minutes ago, Loren Pechtel said:

It's possible to have fairly low TWRs on small bodies.  I've flown stuff that lands with a TWR under 2 on the Mun (it was a ISRU-based hopper.  I made sure it could fly even with full tanks but there wasn't reason to put a lot of extra power on it.  A short hop to the biome next door and it could be landing with nearly full tanks.)

Sure.  I've done vacuum landings at <2 local TWR myself (usually for ISRU landers, sometimes for ion craft on fairly lightweight moons).

But we're dealing here not with a "fairly low" case, but with a "pathologically low" case.  And for a really, really low TWR, then oddities in the timing can get magnified.

Is that a fixable problem?  Yes-- "just" change BBT to not use such a simple-minded assumption, and actually project the path forward to figure out where it intersects terrain.  But it's a great big whacking chunk of work to do, as discussed above.

[Loren Pechtel]

31 minutes ago, Snark said:

Yep, can easily happen.  When you first get your "here's how fast you'll be going at ground level" estimation, BBT is basing that on simpleminded calculations that assume the ground where you land will be at the same elevation as the ground where you are now.  So, for example, if you're flying over downward-sloping ground, then the place where you actually end up eventually landing might be a lot lower than it thought, meaning you're going faster than it expected you would.

I've never found a terrain feature on a low-g world that was steep enough for this to be an important factor.

And even if it was there's the far more serious problem that if you have a lot of horizontal velocity you're burn has to be off axis in order to kill that--and thus your engines aren't slowing your fall as much as expected.

[Snark]

24 minutes ago, Loren Pechtel said:

I've never found a terrain feature on a low-g world that was steep enough for this to be an important factor

Neither have I, but then again I've never tried to land on a vacuum world with a local TWR less than 1.

well, not twice, anyway...

[JAFO]

2 hours ago, Loren Pechtel said:

I've never found a terrain feature on a low-g world that was steep enough for this to be an important factor.

Have you done many Munar Pole landings? (and I don't mean just near the edges of the polar biome, but right up near the actual pole) Those can be freakishly scary.

[Loren Pechtel]

55 minutes ago, JAFO said:

Have you done many Munar Pole landings? (and I don't mean just near the edges of the polar biome, but right up near the actual pole) Those can be freakishly scary.

Never been right up to the pole, solar cells don't work very well up there.

3 hours ago, Snark said:

Neither have I, but then again I've never tried to land on a vacuum world with a local TWR less than 1.

well, not twice, anyway...

How can you land with a TWR under 1??  (Unless you have landing gear and are coming down on someplace like Gilly.)

[Snark]

5 minutes ago, Loren Pechtel said:

How can you land with a TWR under 1??

You can't.  That's why I don't try to do it.

That's presumably why the person who started this whole conversation was running into difficulty:  he was trying to land on the Mun with an ultra-low-TWR ship, and was running into tragic results, and was asking for "couldn't BBT have given me a warning from the get-go that I was doomed", and then my explanation about why not.