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

[Alshain]

2 hours ago, Snark said:

Hi all,

I've posted v1.4.3 of BetterBurnTime.

The new feature is a configuration option to allow showing a numeric countdown indicator, rather than a graphic one.

To do this, simply change the CountdownText configuration setting to something including a "{0}", like this:

<string name="CountdownText">Start burn in {0}</string>

...If you do that, then the time will be shown numerically, instead of a graphical row of dots (e.g. "Start burn in 39s" or whatever).

Enjoy!

Wow, speedy service.  Thank you so much @Snark!

I need to put some spaces in the format strings, but I love it!

Edited May 20, 2016 by Alshain

[Snark]

15 hours ago, Gordon Dry said:

Nearly and I like it.

My idea was to show the countdown to the burn and after that in brackets the countdown to the ullage acceleration but this way is also okay.

Glad to hear that the idea's useful!  The big difference between the solution that I described and the one you mention (i.e. the idea of showing two numbers in brackets) is that the former requires no change to BBT at all, whereas the latter would be really, really hard:  it would require deep architectural changes and intercommunication between mods, which is Really Hard.

 

15 hours ago, Gordon Dry said:

But my main question was if a timewarp inside a MJ maneuver setup to a burn will me always set to the node time or is it capable of warping me to a time before the ullage has to begin?

That's entirely a MechJeb question-- has nothing to do with BetterBurnTime, so I have no idea what the answer would be.  Best to ask that question in the MechJeb thread.

 

15 hours ago, Gordon Dry said:

And if not, could this be made possible my communicating MJ to BBT internally?

The answer to that one's a definite "no" -- not now, and unlikely to happen ever, for a lot of reasons.  What you're asking is a perfectly reasonable question, and I can see why it would seem like a straightforward request.  But this is one of those things that's actually a lot harder than you might think.

Lengthy explanation of why is in spoiler section, for anyone who's interested.

Spoiler

Communicating between two different mods is Really Hard, if they're independent mods and one isn't dependent on the other.

MechJeb doesn't depend on BetterBurnTime, and BetterBurnTime doesn't depend on MechJeb.  That's as it should be-- they're both independent mods, neither one requires the other.  However, that state of affairs makes communication between the two problematic.  At the absolute minimum, it would require close coordination between the authors of both mods, and likely changes to the internal structures of both mods (i.e. hours of work for both authors).  And it's not just a chunk of work to make it happen in the first place.  It's also an ongoing "tax" on both mod authors forever into the future, in order to maintain the compatibility going forward across upgrades and so forth.

The fact that you're talking about interactions with yet a third mod (i.e. whatever realism mod you're running, that introduces ullage into the mix) just further adds to the web of complications.

On top of which, there's the fact that I never run MechJeb or any "realism" mods myself, and probably never will (not that there's anything wrong with 'em, I'm sure they're great, they're just not my personal cup of tea). Thus, implementing such a feature would mean putting many hours of my time into something that I myself will never use when I'm playing KSP.  That's a major hit to the ol' motivation. 

Not to mention that most BetterBurnTime users wouldn't get benefit out of it.  Lots of players use realism mods, sure... but I don't think they're the majority.

And my time's limited.  It's not like I get paid for any of this (nor do I expect or want to)-- it's a hobby for my free time, which is scarce due to having a day job and various IRL responsibilities.  It's also worth noting that each hour I spend modding KSP is an hour I don't get to spend playing KSP, which is, after all, how all this got started in the first place.

So the hours I have available for modding are precious, and I need to be judicious about where I spend them.  Not to put too fine a point on it, each hour I spend modding needs to be for something that's some combination of the following:

• I enjoy creating it for its own sake, and/or
• it will make a difference in my own gameplay, and/or
• it will have a big impact on the population of players who use my mods

...and this feature, though quite a reasonable request on the face of it, doesn't meet any of the above.  It would be a story of "big expensive feature to create, with ongoing maintenance cost into the foreseeable future, which won't benefit my own gameplay at all, and will affect only a minority of BBT users", which pretty much makes it the poster child of an ain't-gonna-happen feature.

I'm sorry about that-- I know it would be a helpful feature to you, and certainly your request is reasonable on the face of it-- but the practical realities of the situation mean that it's just a non-starter.

 

[Gordon Dry]

It looks like that for me now:

Using this config.xml:

Spoiler

<?xml version="1.0" encoding="utf-8"?>
<config>
    <bool name="UseSimpleAcceleration"></bool>
    <bool name="ShowImpactTracker">1</bool>
    <double name="MaxTimeToImpact">120</double>
    <bool name="ShowClosestApproachTracker">1</bool>
    <double name="MaxTimeUntilEncounter">900</double>
    <double name="MaxClosestApproachDistanceKm">10</double>
    <double name="MinTargetDistanceMeters">200</double>
    <string name="CountdownText">Start burn in {0}</string>
    <string name="CountdownTimes">1, 2, 3, 4, 5, 10, 11, 12, 13, 14, 15, 20, 25, 40, 70, 130, 250</string>
    <string name="FormatSeconds">{0}s</string>
    <string name="FormatMinutesSeconds">{0}m{1}s</string>
    <string name="FormatHoursMinutesSeconds">{0}h{1}m{2}s</string>
    <string name="FormatHoursMinutes">{0}h{1}m</string>
    <string name="FormatHours">{0}h</string>
    <string name="FormatWarning">(~{0})</string>
</config>

 

 

[Snark]

1 hour ago, Gordon Dry said:

It looks like that for me now:

Thanks for the heads-up!  So, there are two issues going on here:

1. For some reason it's saying "N/A" for the burn time, i.e. clearly it's having trouble calculating
2. It's showing a time-until-burn-start of ">24 h" even though the node is only five minutes away.

As for what's going on with #1, I have no idea.  It may be perfectly legitimate; it could be a BBT bug; or it could be a case of BBT getting confused by some mod you're running.  I've heard reports of BBT having trouble with certain realism mods, so that could be it.

#2 is clearly a bug.  When BBT gets into a state of "I can't calculate the burn time", clearly it shouldn't try to show any countdown indicator at all.

So I'll add #2 to my "fix" list.  As for #1, dunno what's going on there without knowing more about your ship and/or the mods you're running.

The normal, expected case for BBT to show N/A is when it thinks you really have no available engines, so that a burn is physically impossible.  Examples:  if your ship has no engines at all; if all engines are disabled; if all engines have thrust limiters set to zero; if all engines are starved of fuel.  If any of those conditions apply to your ship, then the "N/A" display is by design.  If none of those conditions apply, my guess would be that you're running some mod that BBT doesn't know how to handle, so it thinks you have one of those problems when actually you don't.

[Gordon Dry]

RO got this "Engine Ignitor" stuff, the upper-stage engines are in fact deactivated until they're staged.

But a proper dV is calculated by FAR or MJ no matter what (they differ a little, but at least they can provide it).

[Snark]

2 hours ago, Gordon Dry said:

RO got this "Engine Ignitor" stuff, the upper-stage engines are in fact deactivated until they're staged.

Not quite sure what you mean by that.  All engines are deactivated until they're staged, including in stock.  That's what staging means.  As long as you have staged the engines, so that they're active (but throttled to zero, since you haven't started the burn yet), BetterBurnTime ought to pick up on them.  Clearly there's something going on with the mod you're using that's somehow interfering with BBT's calculations, but I have no idea what that might be.  Do you have a clear repro case?  Describe the state of the ship when you're seeing the N/A?

2 hours ago, Gordon Dry said:

But a proper dV is calculated by FAR or MJ no matter what (they differ a little, but at least they can provide it).

Just want to be sure we've got our terminology straight-- dV is completely irrelevant to burn time, and to the BetterBurnTime mod.  A 100 m/s burn is a 100 m/s burn.

Do you mean "burn time"?  (Which is a completely different thing from dV.)

[Atlas2342]

Awesome! @Snark Thanks! Just one question, when the last dot disappears in the countdown indicator (when you are supposed to start your burn), is the time split before and after the maneuver node or is it exactly when you reach it?

[Snark]

1 minute ago, Atlas2342 said:

Awesome! @Snark Thanks! Just one question, when the last dot disappears in the countdown indicator (when you are supposed to start your burn), is the time split before and after the maneuver node or is it exactly when you reach it?

Split.  i.e. if it's a 30-second burn, then the last countdown dot disappears when you reach 15 seconds before the burn.

 

[Atlas2342]

Aww yiss, this feature makes this mod worthy to download alone. This is infinitely useful for people like me  who are bad at burning accurately. Thanks for this mod again @Snark!

[Gordon Dry]

Perhaps the fact is interesting for you:

After a maneuver is done (or deleted by me) the "Start burn in > 24h" still is on the screen ...

Edit:

I found this in the log:

Spoiler

[BetterBurnTime] Using complex acceleration model
 
(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 64)

Parent of RectTransform is being set with parent property. Consider using the SetParent method instead, with the worldPositionStays argument set to false. This will retain local orientation and scale rather than world orientation and scale, which can prevent common UI scaling issues.

Dunno if these lines belong together, but who knows...

Complete log:
https://www.dropbox.com/s/yvoguif7yhgkbll/2016-05-21-1%20BBT%20-%20a%20log.7z?dl=0

Edited May 21, 2016 by Gordon Dry

[Snark]

1 hour ago, Gordon Dry said:

Perhaps the fact is interesting for you:

After a maneuver is done (or deleted by me) the "Start burn in > 24h" still is on the screen ...

Edit:

I found this in the log:

  Hide contents

[BetterBurnTime] Using complex acceleration model
 
(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 64)

Parent of RectTransform is being set with parent property. Consider using the SetParent method instead, with the worldPositionStays argument set to false. This will retain local orientation and scale rather than world orientation and scale, which can prevent common UI scaling issues.

Dunno if these lines belong together, but who knows...

Complete log:
https://www.dropbox.com/s/yvoguif7yhgkbll/2016-05-21-1%20BBT%20-%20a%20log.7z?dl=0

Thanks for the log, I'll take a look.

I don't think the RectTransform thing is relevant-- I see it myself from time to time, I'm not even totally sure it's BBT causing it, but even if it is, it seems harmless.  Certainly it's not related at all to whether or not you get "N/A", or to the "> 24h" thing.

The ">24h" thing is certainly a BBT bug.  It's not super surprising, since it's a brand-new feature that I just implemented, and even before looking at the code, I have a pretty good idea of what the problem is likely to be.  It's almost certainly a simple, straightforward, one-line fix.  Put succinctly, the bug is "numeric countdown time shows >24h whenever the estimated burn time is N/A".  So I'll fix that.

The only real unknown remaining is why you're getting the "N/A" in the first place.  I assume it's some interaction with some mod you're running, but I have no idea what that might be.

[dewdkorn6969]

i think @Gordon Dry may be missing a 0 or 1 in his config.xml for line

<bool name="UseSimpleAcceleration"></bool>

Edited May 21, 2016 by dewdkorn6969

[Snark]

7 minutes ago, dewdkorn6969 said:

i think @Gordon Dry may be missing a 0 or 1 in his config.xml for line

<bool name="UseSimpleAcceleration"></bool>

Nah, I think it oughta be fine.  If it's not present, I think it'll just default to "false", which is the normal default.

(Which is demonstrated by Gordon's log snippet, which shows "using complex acceleration", and is the expected default.)

"Complex acceleration" is a good thing.  That's the bit where it takes into account the fact that your TWR will increase as you burn fuel, and therefore the burn time will be shorter.  If you disable this (by setting UseSimpleAcceleration to 1), then it will ignore that and just calculate burn time based on the assumption that your TWR will stay constant.

In other words, "simple" acceleration is less accurate, so there's no reason for you to use it in normal gameplay.  It doesn't save computation or anything, either (the so-called "complex" acceleration is more lines of code, but it's trivial math for the computer to do.)

The only reason I included that option at all was to assist with debugging issues that might come up (e.g. "How many seconds does it tell you?  Okay, now set it to simple acceleration, what does it say now?"), and also to enable side-by-side comparison with the stock burn-time calculator (which uses simple acceleration, which is one of the things that's wrong with it and a big part of the reason for using BBT in the first place).

[Gen. Jack D. Ripper]

I just want to say 'thank you' for the most recent update. The precise countdown time is perfect - it just looks *right* in that corner of the screen. Now I don't need KER to report the exact time.

[Botts89]

So I can't seem to get this mod to work. I'm playing through Steam, so I have the most current version of KSP. I extracted the folder into my gamedata folder, but it just doesn't seem to be doing anything. I don't know what I am missing. The folder in the gamedata folder is, "BetterBurnTime-master"

 

What am I missing? Thanks for any help.

[Snark]

2 hours ago, Botts89 said:

So I can't seem to get this mod to work. I'm playing through Steam, so I have the most current version of KSP. I extracted the folder into my gamedata folder, but it just doesn't seem to be doing anything. I don't know what I am missing. The folder in the gamedata folder is, "BetterBurnTime-master"

Hmm, that sounds wrong.  There should be a folder called simply "BetterBurnTime" in GameData, which should contain BetterBurnTime.dll and a few text files.

Is it possible that you downloaded the source code zip file from github, instead of an actual release instead?

Here's the zip file you should be downloading (the current latest version):
https://spacedock.info/mod/21/BetterBurnTime/download/1.4.3

That'll give you a download, BetterBurnTime-1.4.3.zip.  Open that, and there's a GameData folder in it, inside which is a BetterBurnTime folder.  Move that BetterBurnTime folder into your own GameData and you should be good to go.

[Cairol]

On 21.11.2015 at 1:49 AM, Snark said:

My own personal micro-mod hero is the author of Navball Docking Alignment Indicator. Aside from the incredible usefulness of the mod, I love its Zen-like simplicity. Zero UI to futz with. Zero screen real estate. It just adds a little icon to the navball, automatically, and only when it's needed. Hats off. That is the ideal I strive for.

Just for comparison, I like this far more than the other popular docking aid I see referenced a lot, Docking Port Alignment Indicator, because the latter adds UI and takes up screen space. I find it interesting that the one I don't like is four times more popular in terms of KerbalStuff downloads than the one I like, no idea why.

As far as I can tell from the description/pictures of "Navball Docking Port Alignment Indicator", it only shows you if you are poining towards the docking ports angle.
It seems not to tell you if you translation is correct to actually hit it. You could be aligned according to the Navball indicator and when throttling up, still miss the target by hundrets of meters.
(As seen by the 3rd picture)
You need to use the 3rd person camera in addition to the indicator to get the correct translation and be head-on with the port.
The more "intrusive" Docking Port Alignment indicator mod with it's extra UI is more complex, but it also enables you to align yourself staight to the targeted docking port
with all 3 axis and the correct translation without having to use the 3rd person camera at all.
So I understand and second your point of minimalistic/unintrusive mods. But I think your example is actually not the best one.
DAI has a reason for it's extra UI.

Edited May 27, 2016 by Cairol

[Snark]

6 hours ago, Cairol said:

But I think your example is actually not the best one.   DAI has a reason for it's extra UI.

Actually, it is a good example, and no, DAI's extra UI isn't actually needed-- you've just helped to demonstrate my point precisely, thank you! 

Lengthy explanation in spoiler section, since this isn't directly relevant to BetterBurnTime.

Spoiler

6 hours ago, Cairol said:

As far as I can tell from the description/pictures of "Navball Docking Port Alignment Indicator", it only shows you if you are poining towards the docking ports angle.

Correct!  Because that's all it needs, and it leverages the navigational aids built into the stock game to give you everything else you need.

Cover my monitor with  a sack, and cut a little hole in it showing only my navball and nothing else, and I'll perform a flawless docking using only this mod and nothing else.

6 hours ago, Cairol said:

It seems not to tell you if you translation is correct to actually hit it.

Right!  Because it doesn't need to.  The stock game already gives you the translation information, for free.  It's called a "target indicator" and is a pink circle.  If that's centered, your translation is perfectly aligned.  If it's off-center, then that shows you exactly what your translation error is and what direction you need to move sideways to correct it.

6 hours ago, Cairol said:

You need to use the 3rd person camera in addition to the indicator to get the correct translation and be head-on with the port.

No, you don't.  Standard nav-ball indicators are all you need.

To be correctly lined up for docking, you need exactly three things:

• Orientation (i.e. you're pointed the right way).  This is what the Navball Docking Alignment Indicator mod gives you.
• Position (i.e. your lateral translation is lined up).  This is what the stock pink-circle target indicator gives you.
• Velocity (i.e. you're moving in the right direction).  This is what the stock target-relative-velocity indicator gives you.

Line those up appropriately, and it's all you need.  No camera view whatsoever is needed.  Here's an illustrated docking tutorial I put together which demonstrates the process, if it'll help.

6 hours ago, Cairol said:

The more "intrusive" Docking Port Alignment indicator mod with it's extra UI is more complex, but it also enables you to align yourself staight to the targeted docking port

Except that it's unnecessary.  The navball-only version that I like so much lets you do exactly the same thing (as I demonstrate above), without requiring all the intrusive extra UI.  The UI is simply unnecessary.

One of the things I love so much about the navball docking alignment indicator is not just how it does so much with so little, but how well it leverages the functionality already present in the stock game.  For example, consider the pink "target" indicator on the stock navball.  By itself, it's pretty much useless as a docking-translation indicator.  It tells you what direction the target is, but nothing else.

However, when you team it up with Navball Docking Alignment Indicator, suddenly that pink circle becomes much more powerful and informative.  Because if you're aligned the right way-- i.e. if you have the mod's red "alignment" indicator centered in your crosshairs-- then the stock pink "target" circle now perfectly tells you exactly what you need to know:  "what's my translational error? which sideways direction do I need to move to line up, and how much?"

Absolutely brilliant.

Incidentally, the original mod appears to have been abandoned by the original author-- looks like they may have moved on from KSP.  There's a "community edition" being maintained here, for anyone who's interested in the mod:

 

...So I stand by my original recommendation of "less is more".

Will happily discuss this at length if you like, but since it's not really about BetterBurnTime, this thread's really not the place for it.  Perhaps in the threads of the docking mods.

[Cairol]

14 minutes ago, Snark said:

Actually, it is a good example, and no, DAI's extra UI isn't actually needed-- you've just helped to demonstrate my point precisely, thank you! 

Lengthy explanation in spoiler section, since this isn't directly relevant to BetterBurnTime.

  Hide contents

Right!  Because it doesn't need to.  The stock game already gives you the translation information, for free.  It's called a "target indicator" and is a pink circle.  If that's centered, your translation is perfectly aligned.  If it's off-center, then that shows you exactly what your translation error is and what direction you need to move sideways to correct it.

 

 

No need for a lengthy discussion.
I didn't know the target indicator of the stock game takes translation into account when you target a docking port.
If that's the case, I learned something new. That's all to say for me.

[Snark]

15 minutes ago, Cairol said:

I didn't know the target indicator of the stock game takes translation into account when you target a docking port.

Actually, not quite.  The target indicator of the stock game doesn't "take translation into account," so you didn't miss anything.  It simply points the direction to the target (e.g. a docking port, if you've selected that as a target), nothing more.  It doesn't "switch modes," or anything fancy.

As the spoiler-sectioned, lengthy explanation in my above post points out, if you're playing in pure stock, the pink indicator is actually kinda useless for telling you the translation.  But when you team it up with Navball Docking Alignment Indicator, suddenly it's much more informative, and now it does give you the information you need!  Not because the stock target indicator's behavior changes with the mod (it doesn't), but because those two indicators put together give you information that's more than the sum of its parts, in a way that's simple and intuitive.  All you need to do is look at the navball icons and know how to read them. 

[Botts89]

14 hours ago, Snark said:

Hmm, that sounds wrong.  There should be a folder called simply "BetterBurnTime" in GameData, which should contain BetterBurnTime.dll and a few text files.

Is it possible that you downloaded the source code zip file from github, instead of an actual release instead?

Here's the zip file you should be downloading (the current latest version):
https://spacedock.info/mod/21/BetterBurnTime/download/1.4.3

That'll give you a download, BetterBurnTime-1.4.3.zip.  Open that, and there's a GameData folder in it, inside which is a BetterBurnTime folder.  Move that BetterBurnTime folder into your own GameData and you should be good to go.

Thank you. New to this modding thing, and just starting doing KSP. Thanks for your timely response!

[Bloojay]

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

Note: No countdown indicator is currently shown for the "time to impact" indicator; this is because "when should I start?" is more complex, depending on a lot of factors including your descent angle, TWR, etc.  This feature may eventually be added, but until then, you're on your own.

why not just calculate how long a burn is needed to cancel your velocity? You know, just as an estimate for us to go off of 

Also that might have already been suggested I just couldn't be bothered to read through 9 pages of forums to check

Edited May 29, 2016 by Bloojay

[Kerbart]

5 minutes ago, Bloojay said:

why not just calculate how long a burn is needed to cancel your velocity? You know, just as an estimate for us to go off of 

Also that might have already been suggested I just couldn't be bothered to read through 9 pages of forums to check

Unless you're moving perfectly along a radial or landing on perfectly flat terrain, the altitude of the surface is a moving target due to slope. And the slope isn't constant either. That means that the “distance to impact” (the basis for the calculations) changes from second to second. Even when it's only off 10m (either way) that's the difference between crashing and surviving the landing. To prevent angry “ur mod killed my Jeb, you moran!” posts (or to simply manage expectations) there's no countdown timer.

[Bloojay]

2 minutes ago, Kerbart said:

Unless you're moving perfectly along a radial or landing on perfectly flat terrain, the altitude of the surface is a moving target due to slope. And the slope isn't constant either. That means that the “distance to impact” (the basis for the calculations) changes from second to second. Even when it's only off 10m (either way) that's the difference between crashing and surviving the landing. To prevent angry “ur mod killed my Jeb, you moran!” posts (or to simply manage expectations) there's no countdown timer.

i mean just how long it would take for you to cancel out all motion realative to the surface

[Snark]

13 hours ago, Bloojay said:

why not just calculate how long a burn is needed to cancel your velocity? You know, just as an estimate for us to go off of 

Also that might have already been suggested I just couldn't be bothered to read through 9 pages of forums to check

i mean just how long it would take for you to cancel out all motion realative to the surface

The impact tracker does show you how many seconds of burn time is needed to cancel your velocity at the surface.

And the time-to-impact shows how long to hit the surface if you didn't do a burn, with the caveat that Kerbart mentions about terrain approximation.

However... that's not enough to show a countdown indicator, really.  If I understand you correctly, what you're asking is "please show a countdown indicator that would put the start-of-burn exactly when the time-to-impact equals the time-to-burn."

Certainly I could do that... but it would be badly wrong.  It would leave the player hovering high above the ground, every single time, and I'd be deluged with posts of "the countdown's wrong!"  And they'd be right.  Because it would be wrong.

The point at which you start your burn will actually be later than that.  A common rule of thumb is that a good time to start burn is when the time-to-impact is about 60-70% of the time-to-burn.  In other words, if it's telling you that your time-to-burn is 20 seconds, then you should typically start burning about 12-14 seconds before impact.

However, that IS just a rule of thumb.  It's an approximation that works well, for me, most of the time.  But that depends on local TWR and angle of descent.  Somebody who's landing in places that I don't commonly land, or flies their ships differently than I do, or designs their landers differently than I do, might need a slightly different percentage.

And therein lies the rub.  As Kerbart points out:  a tiny error of waiting a second or two too late, and you're splattered over the landscape.  I'm not, repeat NOT, going to give my users a countdown that has a high probability of being lethally wrong.  Until and unless I can make it accurate enough that it's safe every time, I'm just not gonna go there.  Lethally wrong information is a lot worse than no information at all.

As it stands, you've got the burn-time indicator (which is highly accurate), and the time-to-impact indicator (which is fairly accurate... and when it's wrong, it's fairly predictably so, given the lay of the land-- with a bit of practice you can work with it quite well).  As for when to start the burn, you can pick your own estimate over that.