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

[Snark]

5 hours ago, HebaruSan said:

Thank you for a very pleasant surprise! I installed this mod without reading the whole OP simply to get the "N/A" to go away, and suddenly a helpful little suicide burn indicator popped up! It took some guessing to figure out which mod was even adding it.

Heh, you're welcome!

I've really enjoyed it myself-- wrote the mod because this bugged me, and use it myself all the time.  Got really tired, about the hundredth time I was doing a vacuum landing with the maneuver-node trick.

2 hours ago, obsidian_x said:

I've even started manually land rather than use mechjeb.

It's always great to hear that folks find the mod useful... but this totally made my day!    Thanks.

[Waxing_Kibbous]

I love this mod for the burn times, but I'm finding on the Mun and Minmus that the suicide burn calculator is off- if I burn when it says to I am still far away from the surface. Does this assume a specific trajectory coming in? I'm probably just using it wrong...

[JackBush]

This sounds terrific; I'm on my way to download now. I've always hated that "N/A" business and sometimes thought some of the estimates were a little wacky. Great work, and thanks.

[maceemiller]

Only just found this mod and cant wait to use it. Genius  thanks Snark

[Snark]

On 1/17/2016 at 11:37 AM, Waxing_Kibbous said:

I love this mod for the burn times, but I'm finding on the Mun and Minmus that the suicide burn calculator is off- if I burn when it says to I am still far away from the surface. Does this assume a specific trajectory coming in? I'm probably just using it wrong...

If you go back to the original post and read the section on the impact-time indicator, it's there. 

"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."

In other words, yes, it's "wrong," but that's by design.  The reason being, I put a lot of thought into it and decided that trying to make it "right" would be a cure worse than the disease.

A bit of additional explanation may be in order here, in case I didn't explain it very well.

Spoiler

Let's say I'm heading in for a landing on the Mun.  The impact calculator needs to figure out two things:

• How many seconds until I impact the surface?
• How much burn time do I need to kill my velocity?

These sound like simple, straightforward questions, but actually it's more complicated than that:  the numbers will be different (for both of them) depending on what assumptions you make, e.g. which possibilities you choose to include or not.  And there is no single, obvious "right answer"-- no matter which assumptions you make, they'll be wrong in certain cases that are likely to confuse people.  So when writing the mod, I basically had to just pick a set of assumptions and stick with them.

For example, consider time-until-impact.  How long will it be until I hit the surface?

Well, that depends.  Do I just coast do my doom?  Or do I brake to a halt?  If I coast to my doom, I will hit the surface considerably sooner than if I brake to a halt (since braking slows me down, and therefore cause me to take longer to reach the ground).  When writing the mod, I basically have three choices:

1. Just show the "unadjusted" time that assumes that I coast to my doom.  This has the disadvantage you've run into:  it appears inaccurate if you do in fact use your engines to land (which you probably do).
2. Show the "adjusted" time that takes engine thrust into account.  This superficially would seem to be a better idea, since what you really want is an accurate landing and this would give you that, right?  Except that when I thought it through and started looking at all the potential edge cases, it turned out to be a nasty can of worms.  Sure, it sounds appealing, but actually it would end up a worse player experience IMHO.  The trouble happens mainly because what this mod is trying to do is to predict the future, and that only works when the future is simple, obvious, and doesn't depend on player choices.  Won't go into the details unless you're really interested, but trust me, it would be a much worse experience than you imagine.  And it would turn the mod into something much closer kin to MechJeb, which is not the mod I want to write.  Not to mention requiring a whole lot more code which I didn't especially feel like writing (I'm doing this for fun, it's not as if I'm getting paid).
3. Try somehow to show both numbers.  I don't like this option because it would be cluttery and add too much information to the screen.  I really like minimalist UI and believe that less is almost always more.

So I went with #1.  The basic philosophy:  It's better to be simply, consistently, and predictably wrong than to be inconsistently and unpredictably right.

The practical upshot is that if you ignite your engines exactly when it says "time to impact equals burn time", you'll reach zero velocity before hitting the ground.  So you need to wait until the time remaining is some fraction of the estimated burn time.

Exactly what that fraction should be will depend on various things-- your TWR, the strength of local gravity, the angle of approach, the orientation of your ship.  The absolute best-possible case (infinite TWR, negligible gravity, ship going straight down, thrusting surface-retrograde all the way) would be 50%.  In practice, I generally find that around 60% to 70% works well:  not too wasteful, but leaves a reasonable safety margin.  In other words, if it's telling me I need a 10 second burn to brake, then I'll wait until time-to-impact is 6 or 7 seconds, depending on how gutsy I'm feeling.  And as I'm landing, I keep an eye on the two numbers, and whenever the remaining burn time becomes more than 70% of time to impact, I kill thrust for a bit.

If you have a very high TWR, you can get by with a lower fraction (but never lower than 50%, that's the unattainable ideal).  If you have a lower TWR (that's local TWR, i.e. your thrust divided by your weight-in-local-gravity), it will be a higher fraction.  As your local TWR gets close to 1, the fraction will go up by a lot. (And, in fact, can exceed 100%-- i.e. if your local TWR is really low and close to 1, for example something like 1.1, and the burn time indicator says you need 10 seconds, you will actually need a lot more than 10 seconds.  Be warned.  Usually this isn't an issue, because other than Tylo, most vacuum worlds have pretty low gravity and therefore local TWR tends to be high.)

Edited January 19, 2016 by Snark

[Nightshift83]

Good lord, I was looking for this mod the past 24 hours since I had seen it just two days or so before (I even sent a message to the author of the docking port alignment mod because that was one thing I remembered from this thread).. now I might finish that Duna mission. Thanks a lot for this neat little improvement.

Edited January 26, 2016 by Nightshift83

[Snark]

Hi all, just a note that I've updated the mod to v1.2.

The new feature is a "time to closest approach" indicator.  It works for orbital rendezvous the same way that the "time to impact" indicator works for suicide burns.  If you're in orbit, and you have a target vessel, and you have an upcoming rendezvous, it will show you the time until closest approach, and the burn time to match velocity with the target.

Since the time-until-closest-approach assumes no burn, you should wait until the time-until-closest-approach is half of the burn time.  In other words, if it's telling you that you need 20 seconds of burn to match velocity, you should wait until it's 10 seconds until closest approach.

There are various config settings you can tweak to control the new indicator (including the ability to disable it completely, if you don't need it.)  Please see the README file, or the comments for the mod on SpaceDock.

Enjoy!

[Nightside]

Cool! The suicide burn countdown has really made me enjoy moon landings a lot more. I used to stop way up high and spend forever drifting down, afraid to get going too fast to stop. Now it's fast and loud. 

[reckless rocket]

Thanks for this awesome addition mate!

[Mipe]

Where were you hiding all my life (in KSP)? This is one of those little things that make life much more comfy!

[MK3424]

Nice little addition to this great mod! Keep them coming! (Could you perhaps add a distance to target at closest approach?)

Edited February 6, 2016 by MK3424

[DECQ]

Good work! have a wish for the future, you can make a plug-in for automatic separation of the stages? In my opinion it was a great addition.

[MK3424]

On 17-1-2016 at 5:57 PM, Snark said:

 

It's always great to hear that folks find the mod useful... but this totally made my day!    Thanks.

I usually do landings manually, but this mod really helps to not crash onto the surface.

2 hours ago, DECQ said:

Good work! have a wish for the future, you can make a plug-in for automatic separation of the stages? In my opinion it was a great addition.

Let Alternative Resource Panel do that for you: http://forum.kerbalspaceprogram.com/index.php?/topic/54876-10x-ksp-alternate-resource-panel-v2730-aug-16/

[Snark]

3 hours ago, MK3424 said:

(Could you perhaps add a distance to target at closest approach?)

It's already there.

...note the "Target@0.2km"

 

3 hours ago, DECQ said:

you can make a plug-in for automatic separation of the stages?

Nah... I'm sure there are other mods to do that.  And in any case, I wouldn't make such a mod myself, because I like to write mods that I want to use myself, and that would go against the grain for me.  I never use any "autopilot" style mods, because I like doing all flying manually-- for me, that's where the fun is in KSP.  I like hunching over my keyboard and watching the fuel gauge for a stage go down so that I can hit the space bar at just the right time.

BetterBurnTime, in my mind, is not an autopilot tool.  It doesn't do anything for you, just presents information.  And even there, most of the information it presents is available in the game already anyway without a mod-- just not as conveniently placed.  (For example:  as cool as the BetterBurnTime impact tracker is, it doesn't do anything that you couldn't do by playing shenanigans with a maneuver node, as I comment earlier in this thread.)

So if you want that functionality, I'm sure you can get it from other mods out there, and more power to you... but you won't be getting it from one of mine. 

 

Edited February 6, 2016 by Snark

[MK3424]

2 hours ago, Snark said:

It's already there.

...note the "Target@0.2km"

 

Nah... I'm sure there are other mods to do that.  And in any case, I wouldn't make such a mod myself, because I like to write mods that I want to use myself, and that would go against the grain for me.  I never use any "autopilot" style mods, because I like doing all flying manually-- for me, that's where the fun is in KSP.  I like hunching over my keyboard and watching the fuel gauge for a stage go down so that I can hit the space bar at just the right time.

BetterBurnTime, in my mind, is not an autopilot tool.  It doesn't do anything for you, just presents information.  And even there, most of the information it presents is available in the game already anyway without a mod-- just not as conveniently placed.  (For example:  as cool as the BetterBurnTime impact tracker is, it doesn't do anything that you couldn't do by playing shenanigans with a maneuver node, as I comment earlier in this thread.)

So if you want that functionality, I'm sure you can get it from other mods out there, and more power to you... but you won't be getting it from one of mine. 

 

Oh, thank you! (i haven't had the chance to test it out... just looked at the release notes....)

Edited February 6, 2016 by MK3424

[Evanitis]

Thought I hop in to express how surprisingly awesome that mod is.

I'm usually reluctant to try mods that remove some minor inconvenience of a totally fine stock feature. I don't really know how did I get to download it - I just casually dropped it in GameData along a few other things I wanted to test.

But dang, that made me -enjoy- doing burns. I seriously didn't think that a slight added accuracy and reliability will so severely impact the gameplay. That subtle Closest Approach Indicator is just icing on the cake.

[Superfluous J]

Very cool addition to this great mod! I've got KER telling me that info but it's not so nicely placed near the navball without looking weird (to me), so I'll gladly remove those lines from it.

[Karretch]

There's an issue with compatibility between this and RemoteTech's flightcomputer, you might want to have a talk with the people over there to sort it out. The issue is that node execution using the flightcomputer is burning after reaching the node instead of half before/half after as it should.

[Snark]

6 hours ago, Karretch said:

There's an issue with compatibility between this and RemoteTech's flightcomputer, you might want to have a talk with the people over there to sort it out. The issue is that node execution using the flightcomputer is burning after reaching the node instead of half before/half after as it should.

...I'm confused.  How could my mod possibly be causing any issues with RemoteTech's flight computer?  All I'm doing is tinkering with a text display, I'm not altering any program internals.  The only way that that could possibly affect RemoteTech would be if it were actually reading the text and parsing it from the estimated burn time, which would be utterly insane for a variety of reasons.  And since the folks who wrote RemoteTech are quite clever and I doubt they're nuts, I kinda doubt that they're doing that.

Really, all BetterBurnTime does (in programmatic terms) is to alter that one text display.  It doesn't do anything else to the program's internals.  Therefore, it's unlikely to interfere with other mods.

Now, if it's the case that RemoteTech also tinkers with the "estimated burn time" display on the navball (I've never heard that it does that, but that doesn't mean that it doesn't), then I suppose RT and BBT could end up arm-wrestling over it and you could get a burn time display that's incorrect, but that wouldn't affect the correctness of the burns themselves that the RT flight computer is doing.

I just now looked at the RemoteTech forum, and found not a single reference to BetterBurnTime anywhere.  Given that RT has had half a million downloads and BBT has had nearly 18,000 at this point, it seems safe to assume that there are probably a lot of folks out there who have both of them, and if there were a serious incompatibility, I would have expected someone to have mentioned something by now.  Is it possible you're encountering the difficulty due to some other reason?

[Karretch]

7 hours ago, Snark said:

I just now looked at the RemoteTech forum, and found not a single reference to BetterBurnTime anywhere.  Given that RT has had half a million downloads and BBT has had nearly 18,000 at this point, it seems safe to assume that there are probably a lot of folks out there who have both of them, and if there were a serious incompatibility, I would have expected someone to have mentioned something by now.  Is it possible you're encountering the difficulty due to some other reason?

No idea. As far as I can tell nothing else messes with these stats, but who knows if I overlooked something. Maybe it was just a craft or install conflict, but as soon as BBT was removed RT autopilot worked.

[Snark]

36 minutes ago, Karretch said:

No idea. As far as I can tell nothing else messes with these stats, but who knows if I overlooked something. Maybe it was just a craft or install conflict, but as soon as BBT was removed RT autopilot worked.

Hmm.  That would certainly seem to indicate that there's something going on there, but it makes absolutely no sense to me.

The only thing that BBT touches, at all, when there's a maneuver node present, is the text of the "burn time" indicator.

• Here's where it finds the navball and stores a reference to the two text displays ("burn time" and "time until maneuver")
• Here and here are where it actually sets the text of the "estimated burn time" marker
• It never touches the "time until" text at all

It doesn't alter any numbers in the program at all, just that text display.

The only way I could imagine that it could affect RemoteTech at all would be if RemoteTech was relying on the text there for doing the burn... which would be nuts.  For one thing, it would mean that if you don't have BBT, lots of the time that display is just gonna say "N/A" (that's why I wrote the mod in the first place!), and then what is RT gonna do?  Surely they must be calculating their own numbers internally based on the ship state.

<rummaging through RT source code>

...Okay, yeah, here's the code where they decide when to start the burn.  And as I would have expected, they're just using numbers from the program-- things like "add up all the thrust for all the engines" and "get the total mass of the ship" and "get the time of the maneuver node" and just doing the math on them.  In other words, sensible, not-insane stuff, and they're not looking at the navball at all.

So, what I've just succeeded in proving is that:

• BetterBurnTime doesn't alter anything except the navball display
• RemoteTech never uses any of the navball contents for doing its math
• Therefore, BetterBurnTime can't possibly be breaking RemoteTech.  QED.

...Of course, set against that is the observation that you made, and I honestly have no idea what to tell ya.  All I can say is:  as far as I can tell from looking at the code, what you're observing is impossible. I realize that's not a particularly helpful thing to say ...but I simply have no clue where to go from here.

I'm curious... is anyone else on this thread using RemoteTech with BetterBurnTime?  Anyone else observing something like what Karretch is observing?  i.e.

15 hours ago, Karretch said:

There's an issue with compatibility between this and RemoteTech's flightcomputer, you might want to have a talk with the people over there to sort it out. The issue is that node execution using the flightcomputer is burning after reaching the node instead of half before/half after as it should.

?

[Snark]

Hi all...

As you may have heard, this mod's previous hosting site has gone permanently off the air. 

This makes me very sad, because I've absolutely adored it.

I loved it as a user:  I could browse mods, find the ones I want, etc.  And I loved it as a modder:  I can see the traffic history, I can see how many people are actually downloading my mod, which is a huge thrill.  It gives me an endorphin rush to see that this little thing I made has been downloaded thousands of times.  It gives me motivation to keep on modding.  It's why I've chosen that site as the download location for all my mods.

And now it's gone, and I don't have that any more.  It's a tragic loss.

[Snark]

Good news!  The site's replacement, SpaceDock, is now up and running.  (Mostly.  They're still working the kinks out, and it will take a while until all the mod authors have re-uploaded their mods, but it's "up enough" to be able to put mods there.)

I've updated the download link in the OP to point at SpaceDock.

Thanks to the hardworking devs and admins who have gotten SpaceDock up and running so quickly!

[Andem]

On 2/16/2016 at 5:56 PM, Snark said:

Good news!  The site's replacement, SpaceDock, is now up and running.  (Mostly.  They're still working the kinks out, and it will take a while until all the mod authors have re-uploaded their mods, but it's "up enough" to be able to put mods there.)

I've updated the download link in the OP to point at SpaceDock.

Thanks to the hardworking devs and admins who have gotten SpaceDock up and running so quickly!

Don't forget your signature!

[Snark]

6 minutes ago, Andem said:

Don't forget your signature!

Whoops!  Quite so.  Thanks, fixed.

(I keep forgetting about it... I reluctantly had to turn off all signature displays when switching to the new forum software, because they were just eating up too much vertical space in the new format.)