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

[Nightside]

...

Edited February 17, 2016 by Nightside
wrong thread

[Beetlecat]

I've been using this for weeks and I had no idea it displays suicides and intercepts! I only needed to *pay attention* to the bottom of my screen twice on my last Mun mission: I mis-judged the descent and wound up bouncing my lander pretty hard.

[Andem]

9 minutes ago, Beetlecat said:

I've been using this for weeks and I had no idea it displays suicides and intercepts! I only needed to *pay attention* to the bottom of my screen twice on my last Mun mission: I mis-judged the descent and wound up bouncing my lander pretty hard.

Errm, what? I uh, didn't know the mod had that function... erm... ah...

--EDIT--

Oh wait, you mean suicide burns... 

Edited February 17, 2016 by Andem

[Beetlecat]

2 minutes ago, Andem said:

Errm, what? I uh, didn't know the mod had that function... erm... ah...

--EDIT--

Oh wait, you mean suicide burns... 

Right -- just like sideburns, only far more *dangerous*--ironically named, of course. If you perform one perfectly, there's no risk of actual suicide.

[Snark]

9 minutes ago, Andem said:

Errm, what? I uh, didn't know the mod had that function... erm... ah...

--EDIT--

Oh wait, you mean suicide burns... 

Actually, it displays either one, depending on whether you do the burn or not...

[Andem]

2 minutes ago, Snark said:

Actually, it displays either one, depending on whether you do the burn or not...

[smjjames]

This would be useful as MJ is utterly confused by the Orion nuclear engines.

Just a thought regarding the time display (haven't used it yet), is there a way to have it display the minutes when it goes over 60 seconds?

Edited February 20, 2016 by smjjames

[Gen. Jack D. Ripper]

Would it be possible to give a nice time-to-burn-start option? Yes, I can divide the estimated burn time by two in my head and compare that to the time-to-node, but I'm also lazy and prefer the computer to do that kind of work for me.

[Snark]

11 hours ago, smjjames said:

Just a thought regarding the time display (haven't used it yet), is there a way to have it display the minutes when it goes over 60 seconds?

It does.  If your burn is going to take 600 seconds, the display will say "10m". 

Now, one thing you may have noticed is that it doesn't start doing that until the burn time goes over two minutes.  For example, if the burn time is going to be 110 seconds, it says "110s" and not "1m50s".  That's different from the stock indicator (which starts "wrapping" at the one-minute mark), and is quite deliberate on my part.  The reason is that deciding when to start the burn requires mentally dividing by two.  For time lengths under two minutes, I find it easier and faster to divide seconds than to divide minutes-and-seconds:  for me, to get "55 seconds" as an answer, it's faster to do "110 / 2" in my head than it is to do "30 + (50/2)", which is what I'd have to do if it said "1m50s".

3 hours ago, Gen. Jack D. Ripper said:

Would it be possible to give a nice time-to-burn-start option? Yes, I can divide the estimated burn time by two in my head and compare that to the time-to-node, but I'm also lazy and prefer the computer to do that kind of work for me.

I've thought about it.  I'd like to have some sort of indication, but I don't want to put anything in until and unless I have a solution in mind that satisfies two criteria:

• Does not introduce UI clutter
• Is consistently accurate

Your question is a good one, because it's both clear and short.  Unfortunately, this turns out to be one of those cases where the answer is neither.  There's a lot of hidden depth beneath the surface.

Warning, lengthy discourse follows.  Don't say I didn't warn you. 

 

Regarding UI clutter:  I have a non-negotiable design goal for this mod, which is to introduce zero UI.  So anything I add has to somehow fit into the existing UI.

My rant about UI clutter and "less is more":

Spoiler

This is the bane of my existence.  I loathe cluttery UIs.  I worship the mantra of "less is more."  I want mods that do not add cruft to the visual display.  That's why, for example, I strongly prefer this docking alignment indicator instead of that docking alignment indicator, in spite of the fact that the latter appears to be more generally popular (as measured by number of KerbalStuff downloads before KS went *sniffle* to reside with the morning stars).  It's because the former does its job silently and automatically, with essentially zero UI, whereas the latter pops up additional windows and requires actual user interaction.  It's my clutterphobia at work.  Maybe I'm in the minority here, but it's my mod and I get to make the calls here. 

I'm pretty proud of this mod, but the aspect of it that I'm the most proud of is probably not what most folks care about:  that it can do this without introducing any UI whatsoever.  All it does is override the contents of a text field that's already in the UI anyway, and doesn't even change the semantic meaning of that text field much.  In the case of the impact and closest-approach trackers, it does display a couple of text fields where there wouldn't have been any in stock... but they're in the exact same place as the maneuver-node fields, and fulfill the same roles, and are only displayed when they're immediately relevant, so I don't count that.  When I set out to write this mod, I drew myself a non-negotiable "line in the sand" that I would unambiguously "make things better" (thus the name) while adding zero UI.  The design may seem obvious in retrospect, but getting there took a lot of careful thought and there were a lot of discarded notions along the way.  Sometimes that meant that I had to deliberately not include a potential feature because there was simply no way to include it without adding clutter, which was a hard choice to make.

So that poses interesting design challenges, such as how to nuance more information into the design, without either introducing clutter (which I Will Not Do) or causing confusion by trying to layer too much information into too little UI.

So anyway, if I were to add some sort of "when to start the burn" indicator, I'd have to figure out a way to do it without cluttering up the UI.  Too much information can be even worse than not enough.

One idea that occurred to me would be to use color as a subtle indicator-- for example, the "burn time" indicator could change from green to red when you reach the estimated burn time.  However, that has a couple of problems.  For one thing, most folks don't realize what a surprisingly large percentage of the population has color-blindness issues; no software should ever use color as the sole indicator of any important piece of information.

If that were the only problem, it might be addressable.  I could do some sort of text-formatting indication for the "it's time" state, e.g. add a ! to the display or something.  (And I could do the red/green thing too, just as long as I also have the text indication so as to not leave color-blind folks out in the cold.)

However, there's another problem which is not so easy to work around, if one has committed oneself to adding no UI.  From a player's perspective, it's not really enough to have a simple "do it now" indicator.  You want to have a "how long until I do it" indicator so that you can anticipate it.  If all I did was the red-and-! trick that I describe above, how would that work in practice?  I'd have to hunch over the monitor, staring unblinkingly and undistractedly at the indicator, finger hovering over the Z key, so that I can mash it the instant the moment arrives.  I dunno about you, but that would seriously stress me out, and I'd end up doing the mental math anyway so that I could watch the countdown timer as my main indicator.

And that has been my main sticking point.  There absolutely has to be a time-until-node timer, because every KSP player since the dawn of maneuver nodes has had that and relied upon it and I can't take that away.  And to really solve the when-do-I-start-my-burn problem, I'd need to have some sort of other countdown timer.  And to me, having two countdown timers would be confusing clutter.

I simply haven't been able to figure out any solution to this that isn't (to me) a cure worse than the disease, which is why I haven't done anything about it.  I may still go in and add the color-and-! thing as an added embellishment (it does have some value), but it doesn't fully solve the problem the way you'd probably like.

 

Regarding consistent accuracy:

I've designed three types of displays into this mod, which all use the same UI because they don't display at the same time.  One is for maneuver nodes, one is for impact (i.e. suicide burns), one is for orbital rendezvous.

It's important to me that all three of these should work in exactly the same way and should have a perfectly consistent experience.

The timers for maneuver nodes and orbital rendezvous are pretty straightforward:  you want to start your burn when time-remaining is exactly half of the burn duration.

However, the impact tracker is the sticking point.  The best-time-to-start-the-burn is quite a hard problem, not just mathematically, but in terms of predicting user behavior.  And the consequences for failure are much worse:  screw it up by even a second or two and you've just killed the ship, as opposed to "oh well, I missed my ideal maneuver burn timing by a few seconds, no big deal."

If I put in a purported when-to-start-your-burn indicator into BetterBurnTime-- I can tell you exactly what's going to happen.  The users are immediately going to take that as gospel ("Just wait until it says NOW and then start my burn!").  And when they do that with the impact tracker, they're going to expect it to work.  They're going to expect that if they wait until it says "start the burn" and hit Z at that moment, they'll brake to a comfy, precise halt right at the surface, and won't get smashed to smithereens or end up dangling kilometers above the surface.

And they'd be quite reasonable and right to expect that, too, since that's what the mod seems to be telling them that it can do.

So if I provide such an indicator, essentially I'm making a promise... and I'd darn well better deliver on that promise, or I'll be doing users a disservice.  And I haven't been able to figure out a way to make the impact tracker reliable and accurate enough to be able to deliver on that promise.  (At least, not without adding so much complexity to the mod that essentially I'd be writing MechJeb all over again, which I'm not even slightly tempted to try.)

So in that regard, my design challenge would be "how can I present more information, which might be helpful, without seeming to make promises for something I can't deliver."

 

Edited February 20, 2016 by Snark

[Gen. Jack D. Ripper]

The impact tracker...eh, half the point of KSP is flying based on somewhat-educated guesses, rather than the finely-computed physics of real spaceflight, and part of the learning curve is figuring out that leaving a good margin for error is the difference between 'landing' and 'splattering'. I've found it useful, anyway, and your user warning was enough to tell me not to substitute its calculations for common sense.

Thus, one could just append ' (Est. Half-Burn in T- XmYs)' to the time-to-node string, perhaps with a config option to disable it, and that would be that. The promise need be nothing more than 'this will give you the time to node - (estimated burn time/2), which some find helpful for making relatively short burns'. To wit, 'It comes with some caveats, but hopefully it should be helpful for guessing when to begin burns. No more trying to do division in your head while also trying to make sure your craft is ready to start a burn.'

That's how I'd handle it, anyway.

At any rate, thank you ten thousand times for *not* cluttering up the interface. It's simple and entirely unobtrusive; it looks and works as if it were stock, and really ought to be.

[smjjames]

41 minutes ago, Snark said:

It does.  If your burn is going to take 600 seconds, the display will say "10m". 

Now, one thing you may have noticed is that it doesn't start doing that until the burn time goes over two minutes.  For example, if the burn time is going to be 110 seconds, it says "110s" and not "1m50s".  That's different from the stock indicator (which starts "wrapping" at the one-minute mark), and is quite deliberate on my part.  The reason is that deciding when to start the burn requires mentally dividing by two.  For time lengths under two minutes, I find it easier and faster to divide seconds than to divide minutes-and-seconds:  for me, to get "55 seconds" as an answer, it's faster to do "110 / 2" in my head than it is to do "30 + (50/2)", which is what I'd have to do if it said "1m50s".

That makes sense.

edit: Lol, this thing is utterly confused by the Orion nuclear pulse engines from RoverDudes Nuclear Rockets mod as well as it's giving totally ridiculous times.

Edited February 20, 2016 by smjjames

[Snark]

On 2/20/2016 at 11:47 AM, smjjames said:

Lol, this thing is utterly confused by the Orion nuclear pulse engines from RoverDudes Nuclear Rockets mod as well as it's giving totally ridiculous times.

I can believe that.  For anyone else reading this thread, here's the mod that smjjames is referring to:

...Unfortunately, there's no way for me to directly verify exactly how the mod works, since it looks like the only place RoverDude put it for download was on another hosting site that has gone defunct, and it looks as though he hasn't put it on SpaceDock yet.  So until/unless RoverDude puts it back up again, there's no way for anyone to play with it who didn't download it before KS's demise.

However, from the details about the historical Project Orion, I get the basic idea.  The thrust from Project Orion wouldn't be continuous, but a series of pulses.

Since I can't download it right now, I can't see exactly how RoverDude has implemented it.  However, from your comment (and from the way BetterBurnTime works internally), I can deduce what the issue is likely to be.  I assume that what RoverDude has done is to implement an engine that does not exert thrust-over-time, but instead produces staccato bursts of thrust, like the proposed IRL Orion.  Since BetterBurnTime has no concept of this, and just assumes constant thrust, and queries the engine for "what is your thrust", it's not surprising that this would make it get hopelessly confused.

(I'm guessing that the stock burn-time indicator would also get very confused.  Unless RoverDude has put in custom code to override the burn-time estimate behavior... in which case his mod and BetterBurnTime would end up arm-wrestling over the display, and hilarity would ensue.)

I'm not sure how fixable this is.  I've got some simple ideas in mind, that would allow BetterBurnTime to be easily patchable for "specialty" engines like this; then it would just be a matter of adding a little ModuleManager config patch for whatever the relevant engines are.  However, until I can get my hands on a copy of RoverDude's mod, there's no way for me to know whether my idea would actually work.

[Edit] Ah, wait.  Okay, apparently there is a github download for Nuclear Rockets, it's just not referenced in the forum post.  Had to dig down to page 15 of the responses, where RoverDude mentions a github link.  Okay, so it's available.  At some point I should go take a look at it to see how it's put together; not sure when that'll happen, though.  If I come up with a solution, I'll be sure to post it here.

[smjjames]

Don't worry about it @Snark, to be fair, even stock seems confused by it and the Nuclear Rockets mod has HUMONGOUS amounts of deltaV anyway, so, I don't expect this to actually be set up in order to read those and I'm not asking for it to be. Probably the main thing that is confusing both this and MJ is the fact that the engines in that are pulse engines, not continuous thrust.

[Snark]

4 hours ago, smjjames said:

Don't worry about it @Snark, to be fair, even stock seems confused by it and the Nuclear Rockets mod has HUMONGOUS amounts of deltaV anyway, so, I don't expect this to actually be set up in order to read those and I'm not asking for it to be. Probably the main thing that is confusing both this and MJ is the fact that the engines in that are pulse engines, not continuous thrust.

Well, yeah, but I just ran a little test and this is one area where I think the stock indicator actually does a better job of capturing the burn times than BetterBurnTime does.

BetterBurnTime relies on doing math on announced numbers (such as asking an engine, "what's your thrust?").  The NuclearRockets mod totally ignores that number (it just puts "0.1 kN" as the thrust), because it applies the thrust in a different fasion.  The result is that BetterBurnTime gives estimates that assume you're applying a uniform 0.1 kN thrust, which is totally useless (it just says "you'll take >24 hours").

The stock indicator, on the other hand, doesn't try to calculate anything from first principles, and looks at the actual acceleration imparted to the ship, which means that it bounces all over the place but at least gives vaguely, approximately right answers some of the time.  (By "approximately" I mean "off by a factor of 2, rather than a factor of 1000".)

So, at the very least, I'd like to provide some hooks into BetterBurnTime via ModuleManager that allow turning it off when certain specific engines are in the mix.  Don't want BBT to be worse than the stock indicator, after all.

Ideally I'd like to see if there's some way I could actually solve this the right way and provide a useful number, but that would take some time and reverse-engineering (and, possibly, input from RoverDude, who I expect is very very busy right now trying to get 1.1 out the door.)

[Joco223]

@Snark Can you please fix your mod for Real Fuels? I'm using RF Stockalike in 64k and it just gives me an N/A estimated burn time when i create a node 

[Snark]

3 hours ago, Joco223 said:

@Snark Can you please fix your mod for Real Fuels? I'm using RF Stockalike in 64k and it just gives me an N/A estimated burn time when i create a node 

Hm, interesting. 

I've never had occasion to use that mod, or look at it before.

• Real Fuels
• SolverEngines (used by Real Fuels)

...So based on just reading through the descriptions here, I can tell you right now:  a full-fledged compatibility update for BetterBurnTime to support Real Fuels ain't gonna happen.

The technical reasons why not are lengthy (see hidden text below), but it boils down to "because it's basically impossible."  Real Fuels changes engines in a way that make them impossible for a mod like mine to predict.

Spoiler

The way BetterBurnTime works (i.e. the reason it's better than the stock indicator) is that it looks at the statistics of the engines and does predictions based on those.  Therefore, it's critically dependent on the fact that engines have uniform performance.  If you ask "what's the max thrust?" and "what's the Isp" and "what's the fuel mixture it uses?", those have constant answers, thus making the engines predictable.

Real Fuels isn't just a propellant replacement.  It's not just saying, "well, now we have realistically modeled liquid hydrogen and liquid oxygen instead of 'liquid fuel' and 'oxidizer', and we've rejiggered the Isp values."  If that's all it did, BetterBurnTime would handle it just fine.

Instead, Real Fuels is doing some very sophisticated stuff under the covers, using a completely different engine module that gives all kinds of flexibility to mod authors about how engines behave.  Isp could be a function of fuel flow rate, or temperature, or whatever else.  Engines might handle different fuel mixtures.  And so forth.

There's simply no way that BetterBurnTime can predict that sort of thing if the engine behavior can't be relied upon to be constant.

That said... BetterBurnTime does add some value aside from the actual burn-time calculation itself.  For example, time-to-impact and time-to-closest-encounter.  So even though I can't make it work to give "more accurate burn times" for Real Fuels, I could mod up a BetterBurnTime extension to allow using ModuleManager config to override its behavior:  basically, to mark an engine as "don't try to calculate".  That would be fairly easy for me to code.

With a "solution" like that, here's the experience you'd have with Real Fuels:  you'd get the same burn-time indicator that's available in the stock game (i.e. as if BetterBurnTime weren't installed), but you'd still have the time-to-impact and time-to-closest-approach indicators.  Also, I'd need to look at how the stock indicator is implemented, but it might be possible for (stockalike) burn time to be added to the time-to-impact and time-to-closest-approach indicators.

I'll look into it.  Just don't expect much-- the best I'd be able to manage would be stockalike behavior for Real Fuels engines.

 

Edited February 21, 2016 by Snark

[Joco223]

@Snark Yes, i thought of that as a reason your mod doesn't work with RF. Thou that MM patch could be very useful. Does the suicide burn time from your mod count in for making the rocket lighter as burning fuel?

[Snark]

7 hours ago, Joco223 said:

@Snark Yes, i thought of that as a reason your mod doesn't work with RF. Thou that MM patch could be very useful. Does the suicide burn time from your mod count in for making the rocket lighter as burning fuel?

If you're talking about "conventional" engines and not RealFuels, then yes, it does.  The burn time needed for a given amount of dV is calculated the same way, regardless of what purpose it's for (maneuver node, suicide burn, orbital rendezvous).

If you're talking about "would it do so with the putative ModuleManager patch for RealFuels", then the answer is no, it wouldn't.  For suicide burns, the ideal best case scenario for RF would be that it would present a burn time that's essentially a clone of the stock indicator, with all of its disadvantages.  That's assuming I can find the hooks I need to be able to implement that.  The worst case scenario is that you'd get a "time to impact" indicator, but no burn time indicator at all.

[Joco223]

@Snark Ni, i didn't meant for you to make a MM patch, i know it's impossible.  But every time i use the suicide burn time, i always end up about 500-1000m above ground

[sardia]

How does this compare with how mechjeb calculates landing using it's autopilot? Since it can land, then it must have coded how long it takes to achieve the best landing.

[FullMetalMachinist]

On 2/20/2016 at 10:13 AM, Snark said:

From a player's perspective, it's not really enough to have a simple "do it now" indicator.  You want to have a "how long until I do it" indicator so that you can anticipate it.

I have an idea for a way to possibly implement a "burn now" indicator without adding too much to the UI.  Would it be possible to add a small line of either "lllllllll" or "........." in between the estimated burn time line and the time to node line? If so, then you could just have each vertical line or dot count down until none left, and then do the color change and add the "!".  It could even be based on some kind of logarithmic function, where the first few disappear every 10 seconds or so, and then as it gets closer to the "start your burn now" time, they count down one for every second. Just a thought.  Unfortunately I don't have any ideas on the issue of making the suicide "burn now" time more accurate.

[Snark]

2 hours ago, Joco223 said:

@Snark No, i didn't meant for you to make a MM patch, i know it's impossible.  But every time i use the suicide burn time, i always end up about 500-1000m above ground

Ah.  I would guess it's because you're doing the wrong thing, such as starting your burn exactly when the "burn time" equals "time until impact"?  Common mistake. 

See my explanation from earlier in this thread.  Short answer is that the "time to impact" is how long to impact if you weren't running your engines, and therefore you need to start your burn somewhat after the point at which "burn time" equals "time to impact".  (And to answer your next question of "why doesn't it give the time with engines?":  it's for several very good reasons, see my above-linked post.)

 

1 hour ago, sardia said:

How does this compare with how mechjeb calculates landing using it's autopilot? Since it can land, then it must have coded how long it takes to achieve the best landing.

MechJeb is stupefyingly complex.  Much, much more so than BetterBurnTime.  It's doing all kinds of incredibly sophisticated calculations, with reams and reams of code that calculate stuff that the stock game doesn't provide, or where it has to do its own calculations "the hard way" for things that the stock game purports to provide but calculates wrong (like moment of inertia).

The volume of code in MechJeb is well over an order of magnitude bigger than BetterBurnTime.  It's a massive tour de force.  BetterBurnTime is clever, but clever's not enough-- to do what MechJeb does, you have to be not only clever but also big.

"Fixing this" isn't just a matter of writing a line or two of code; if it was, I'd be doing it already.  It's a feature implementation that requires reams of code and complexity to do right.  And even there, MechJeb can do it because, unlike BetterBurnTime, it's working in a deterministic system.  If you're a piece of code, and you're not only observing the world but also controlling it as an autopilot, it's possible to write code that will work perfectly right every time.  Complicated and hard, but possible.  But BetterBurnTime is (very deliberately) not an autopilot, and there's no way for it to predict what the player will actually do, so it's working with a nondeterministic system and is therefore constrained in what it can predict.

So what it boils down to is, to provide the feature you'd like, I'd have to spend weeks to make that happen, greatly bloating the size of my mod, and essentially turning it into another MechJeb.  Which would be a pointless waste of my time, because we already have MechJeb, and in any case it would be making the mod less enjoyable for me personally to use, because I kinda like the challenge of applying my knowledge of TWR, angles, gravity, etc. to pick out the right landing technique.  If landing was just a matter of "wait until this thing lights up, hit Z, wait", I would very quickly get bored of landings.  And I land a lot. 

 

55 minutes ago, FullMetalMachinist said:

have an idea for a way to possibly implement a "burn now" indicator without adding too much to the UI.  Would it be possible to add a small line of either "lllllllll" or "........." in between the estimated burn time line and the time to node line? If so, then you could just have each vertical line or dot count down until none left, and then do the color change and add the "!".  It could even be based on some kind of logarithmic function, where the first few disappear every 10 seconds or so, and then as it gets closer to the "start your burn now" time, they count down one for every second. Just a thought.  Unfortunately I don't have any ideas on the issue of making the suicide "burn now" time more accurate.

Ooooh, I like that idea!  Sort of a poor man's progress bar.  I gotta think about that, thanks for the suggestion!.

The burn-now-for-impact thing is still an issue, but (for example) if I simply didn't show the "progress indicator" for time-to-impact, at least I wouldn't be lying to people and it would be better than what I have now.

Edited February 21, 2016 by Snark

[MK3424]

Cool little update!

[Snark]

Hi all,

I've just posted BetterBurnTime v1.3.  This adds a little "countdown" indicator for when to start the burn:  a little row of green dots under the "estimated burn time", which gets shorter as the time to start burning approaches.

It's an exponential countdown:  ten dots means you have 8 or more minutes until it's time to start burning, then as the dots go down, you have 4 minutes, 2 minutes, 1 minute, 30 seconds, 10 seconds, 5 seconds, 3, 2, 1, go.

Currently it only does this for maneuver nodes and time-to-closest-approach.  It currently does not do it for time-to-impact.  I left it off time-to-impact because it's considerably more complex (it's not just "split the burn", it depends on a lot of factors including descent angle, TWR, etc.).  Eventually I'd like to add that, but it would take a lot more time to code, and I figure it's better to give a little convenience now than all the convenience later.

A grateful shout-out to @FullMetalMachinist for this excellent suggestion.  It was his idea (right down to the exponential fall-off), and I shamelessly appropriated it lock, stock, and barrel.  Thank you!  (Also thanks to @Gen. Jack D. Ripper, whose feature request led to this discussion in the first place.)

I've also added a config setting that allows turning this display off, if it's not to your taste.  See notes on the SpaceDock page for details.

Edited February 21, 2016 by Snark

[FullMetalMachinist]

11 minutes ago, Snark said:

A grateful shout-out to @FullMetalMachinist for this excellent suggestion.  It was his idea (right down to the exponential fall-off), and I shamelessly appropriated it lock, stock, and barrel. 

Happy to help! I'm actually really surprised that it was (seemingly, I have no coding experience) easy enough of an idea to implement so quickly.