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

[Loren Pechtel]

5 minutes ago, Snark said:

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.

The thing is, if the TWR is under 1 there's no solution for the burn time in the first place.  It shouldn't be giving any answer beyond impossible.

[Beetlecat]

1 hour ago, Loren Pechtel said:

The thing is, if the TWR is under 1 there's no solution for the burn time in the first place.  It shouldn't be giving any answer beyond impossible.

In that case, BBT is *assuming* that the current rocket "probably does" have a TWR available to not crash? (otherwise, why would we have put that lander in orbit to begin with??)-- only proving us wrong once we start burning and realize the number isn't going down.

Maybe we need to get that N/A back just for these edge case scenarios.

Edited April 12, 2018 by Beetlecat

[Snark]

3 hours ago, Loren Pechtel said:

The thing is, if the TWR is under 1 there's no solution for the burn time in the first place.  It shouldn't be giving any answer beyond impossible.

2 hours ago, Beetlecat said:

Maybe we need to get that N/A back just for these edge case scenarios.

Strongly disagree, for a variety of what I consider to be good reasons, but am too tired to explain in detail right now.  It boils down to:

• Doing that would be inconsistent, which for me is a mortal sin when it comes to user interactions.  I value consistency over virtually everything else.
• Doing that would make the mod less informative and less useful for learning curve; would make it harder to learn from mistakes.  Which would directly defeat a major part of the purpose of BetterBurnTime.

Explaining why it would be inconsistent and less usefully informative would take more energy than I have right now.  Sorry guys, I'm pretty much used up for today.  Will have to expound upon this another time.  Suffice to say that it's a thing I've thought through in detail well before today, and have good reasons for it being the way it is.

 

[Beetlecat]

1 hour ago, Snark said:

 

(Argh! Sorry, Snark-- I was totally supporting your response but far too subtle about it. Being ironic and invoking Poe's Law inadvertently... )

Edited April 12, 2018 by Beetlecat

[Superfluous J]

5 hours ago, Loren Pechtel said:

How can you land with a TWR under 1??

It's tough, and I don't suggest you ever try except to try it. I've personally never succeeded though I did try quite a few times after seeing someone do it on YouTube. Sadly that was over 4 years ago and the few searches I tried failed.

The basic idea is to make sure you're never going down much until the VERY end. You skim the surface slowly tilting more and more upward, sacrificing slowing down for keeping your "orbit" above the ground. By the time you can't keep it in the "air," you're going slow enough that you can stop. In theory. In practice, it's close enough to be impossible that I personally gave up on it.

And even if you DO do everything correctly, an unplaned-for mountain can totally ruin your day.

[Joal ban Kluane]

14 hours ago, shachar2like said:

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

I think this post shows you're looking actually for something that Better Burn Time is not going to give you: tutorial-like support. I actually think you might be on to something... for a different mod, a mod that would look over your shoulder and tell you what you are doing possibly wrong (something like what Wernher Checker or Extensive Engineer Report are doing for the VAB), checking that you have minimum requirements for what it believes you are trying to do (in this case, determine that you are on a collision course with a body for which you do not have enough TWR to land properly on... telling you so, so you can revert and try again, or drop excess weight or whatever).

Maybe you could start such a mod, or post in the Mod Discussion section (so somebody interested picks it up), or something. In any case, it does not look like it is anything like the purpose of BBT, as Snark patiently explained (and by the way, @Snark, thank you for these long, detailed explanations, they are quite enlightening). But I think this would be a good idea for KSP learners (and probably something I would put in my son's install... when he actually starts attempting more than non-flying replicas of the Millenium Falcon)

[JAFO]

12 hours ago, Loren Pechtel said:

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

You should try it some time.. just be sure to pack plenty of batteries (and some landing lights!)

The terrain slopes are terrifying, and there's very little ground that's level(ish) enough to land on. Which makes it something everyone ought to experience at least once!

4 hours ago, Joal ban Kluane said:

(and by the way, @Snark, thank you for these long, detailed explanations, they are quite enlightening)

Seconded! Most informative.. thanks, @Snark!

[Trann]

Full disclosure: KSP 1.3.1 and BBT 1.5.4; it behaves the same with all my mods or none (just BBT and Squad folders); I'd test in 1.4 but I can't get past a black startup screen...

The dots are encroaching on the navball.  Everything seems to function just fine, it's just the layout that's off.

I've read the README and found config.xml and tried to add a set of leading spaces to act as a buffer but no joy.  Any thoughts?  I realize this is a previous version so feel free to treat it as low- or no-priority.

[Snark]

14 hours ago, Trann said:

The dots are encroaching on the navball.  Everything seems to function just fine, it's just the layout that's off.

Hmm, interesting.

I note that not only are they in the wrong place, but they're the wrong size, too-- they're supposed to be the same font size as the "estimated burn" and "node in ..." text displays, but clearly they're a lot bigger, there.  Here's how it's supposed to look:

My initial guess was that this is probably something to do with navball scale and/or positioning.  Technobabble reasoning in spoiler.

Spoiler

Reason to suspect navball scale:

Unlike the other two text objects-- which are "owned" by the stock game, and BBT just hijacks their content-- that countdown display is a brand-new object that I create from scratch by cloning one of the other ones.  The code that places it does math to try to make the positioning consistent:  i.e. "there's this much (Δx, Δy) from the "est. burn" to the node indicator, so apply that same (Δx, Δy) from the node indicator to the countdown indicator."

Normally, it works exactly as desired.  However... I could imagine a scenario in which the user has rescaled and/or repositioned the navball, and suppose I've got it hooked up so that it's parented to the wrong transform, or something, with the result that I end up applying the (Δx, Δy) in a "scaled-up space" that causes it to move too far.  Or something like that.

If there were such a bug in BBT, it would be easy for it to slip past me, since I never tinker with the navball scale or position myself, so it's not the kind of bug I'd be likely to catch in my own gameplay.

...However, I just now went and spun up KSP 1.4.2, and tried using the setting option to rescale and reposition the navball, and I didn't see any problems-- everything worked exactly as I expected it to work, so I wasn't able to reproduce your issue.

14 hours ago, Trann said:

tried to add a set of leading spaces to act as a buffer but no joy

Correct, because the code that reads the countdown indicator text from config specifically trims all leading and trailing whitespace to protect you from yourself. 

So yeah, that's not gonna work.

14 hours ago, Trann said:

I realize this is a previous version so feel free to treat it as low- or no-priority.

Well, I wouldn't have thought this would be a thing that would care about KSP version much.  And I don't think the fact that you're running an older BBT version should matter-- 1.5.4 is fairly recent, and I've looked at the code diff between 1.5.4 and the current 1.6.1, and I'm not seeing anything that ought to affect the text placement or scaling.

So... no idea what to tell you, I have no idea what's going on.  I guess about all I can suggest is that if-and-when you manage to update to KSP 1.4.x, try giving it another whirl and see whether it's still doing it for you.

(In the meantime... I suspect it should be fine for you to run BBT 1.6.1 on your current KSP 1.3.1; my guess is that it'll be backwards-compatible.  So maybe try that and see how it works?  Even if it doesn't fix your bug, at least you'll get to use the new "atmosphere tracker" feature.) 

[Trann]

5 hours ago, Snark said:

My initial guess was that this is probably something to do with navball scale and/or positioning.  Technobabble reasoning in spoiler.

...However, I just now went and spun up KSP 1.4.2, and tried using the setting option to rescale and reposition the navball, and I didn't see any problems-- everything worked exactly as I expected it to work, so I wasn't able to reproduce your issue.

Since you gave the green-light for 1.6.1, I happily dropped it in.  The problem persists.

But you're not wrong to suspect scaling and I have some interesting images to confirm that.  Normally, I run with the navball to the far left (probably not an issue) and at 80%.  I decided to tinker with the scale.  With the game paused, I slid the navball scale up and down and the *dynamic* offset remained the same.  On a fluke, I left it at 150% but misclicked, going back to the space centre instead of resuming active play.  When I jumped back in, the navball scale was the same but the indicators picked up the *previous* offset.

I then dropped the scale to 50% and did the same thing -- space centre, return to ship -- and poof: oversized pips, itty-bitty navball.

Lastly, setting the scale to 100% and repeating the scene change restores the offset correctly.

I don't know what magic is involved in scene changes affecting the offset but it sounds like I've revealed an interesting puzzle for you.  Sorry

EDIT: Looking at these together, I think my premise is off.  The pips all seem the same size (even though the image regions aren't) so I'm wondering if perhaps the UI's preferred scale isn't being applied to the pips when entering the scene?  That seems far more reasonable than what I wrote.

Edited April 13, 2018 by Trann

[Snark]

24 minutes ago, Trann said:

The problem persists.

<nice repro steps>

Thanks!  Looks like that's a good starting point to investigate-- I ought to be able to reproduce it, and I expect a fix shouldn't be too hard.

Not sure when I'll have a chance to get to it (kinda busy these days), but it doesn't sound like a large fix to me.

Many thanks for running down a nice set of repro steps, saves me a ton of time trying to find the smoking gun.

[Trann]

You're quite welcome.  I say no rush, of course: it still functions as it should.  And if my mad IT skillz make it easier for you to fix this wonderful mod, I'm more than happy to lend a hand.

[Cyrious]

Can I make a suggestion? For the closest approach mode for the indicator where it gives the distance that the craft will reach during closest approach (ex Target@ 0.7km in 83s), can it be changed (either via a config file or even just clicking on that part of the indicator) so it switches from 0.n KM to nnn KM (0.7km to 723m)? It would allow for maneuvers on final approach to be finely tuned so the pilot doesnt have to do further maneuvers/waste time closing the gap after velocity matching has been done.

[Snark]

3 hours ago, Cyrious said:

Can I make a suggestion? For the closest approach mode for the indicator where it gives the distance that the craft will reach during closest approach (ex Target@ 0.7km in 83s), can it be changed (either via a config file or even just clicking on that part of the indicator) so it switches from 0.n KM to nnn KM (0.7km to 723m)? It would allow for maneuvers on final approach to be finely tuned so the pilot doesnt have to do further maneuvers/waste time closing the gap after velocity matching has been done.

It's not a bad idea, and I actually looked into doing it at one point... except that when things get really close to each other, there's a collision risk.  The problem is that the distance displayed is based on a point (i.e. the "location" of a craft, e.g. its CoM, or its control-from-here point, or the center of the targeted part, or whatever), whereas spacecraft have nonzero size.

If my spacecraft is 20m across, and my target is 20m across... then we'll physically collide when we're still supposedly 20m "apart".  I'm loath to show an exact-meters distance because it would tend to mislead players:  "Okay, I'm going to adjust my path so I'll miss the target 10 meters to one side..." <bonk> <explode> "AAAARGH, you stupid BetterBurnTime!"  <shakes fist>

I made the minimum resolution be 0.1 km, i.e. a full 100 meters, because that's big enough that it would be rare for a ship to be large enough to matter.  Yes, it makes things a bit inconvenient on final approach.  But I would much rather fail-to-provide-extra-convenience than to provide misleading information that could lead people to grief.  In my book, "no information" is better than "misleading information".

Also... I actually kinda like a bit of inconvenience.  It's why I wrote this mod instead of installing KER or MechJeb.  I like doing the fine-tuning for final docking maneuvers.  Also, the way I play, no time is wasted.  I don't kill-velocity-and-end-up-100-meters-away, so no time is wasted.  My docking process looks like this:

1. When still many kilometers distant, use the BBT closest-approach indicator to get it tuned to "0.0 km" or "0.1 km"
2. As the ship gets within a couple of kilometers, rotate it so that it's pointing target-relative
3. Check the relative positions of versus   (I want them to be perfectly lined up)
4. If they're not perfectly lined up, point my nose slightly to one side of and thrust a bit to push it until it precisely lines up with
5. Brake to a stop when I'm just a dozen meters away or so.

...that's how I dock, that's how I've always docked, and having a precise-meters display wouldn't provide the slightest bit of additional convenience or really save any time, and would make docking less fun for me because it would nudge me into setting things up before I'm in visual range of the target and thereby would be less eye candy for me.

So, yes, it's a nice suggestion, and thank you for that.    However, it's an idea that I've already thought through in a fair amount of detail, quite some time ago, and chose not to pursue for various reasons.

 

[Zeiss Ikon]

@Snark Okay, I hope I've just done something wrong or failed to do something I should.  I just upgraded to 1.4.3 this past long weekend (installed in a new folder and linked to my save on Dropbox, as as in 1.4 and 1.4.1), and (as I did in 1.4 and 1.4.1) installed the same Better Burn Time download I'd had in 1.3.1.  It works perfectly in 1.4 and 1.4.1, but in 1.4.3 I'm seeing two things that don't work (one matters, one doesn't, much).

First, in the countdown dots, the last three before "Z time" (which used to be circles with a dot inside) are now hollow squares, more or less the kind of character that shows when a font lacks the character you need.  If all i need to do is copy a font file from an older install, that'd be great, but if there's no fix, this isn't a deal breaker.

Second, and potentially much more important, I'm not getting countdowns to either leaving atmosphere or re-entry as I did in previous KSP versions.  I've made multiple launches and reentries, both new craft and craft already in flight before the upgrade, with the same (lack of) result.

I installed the same way I've done before -- opened the .zip file in Ubuntu (MATE 16.04)'s archive manager, and drilled down into the Game Data folder, and drag-copied the Better Burn Time folder into the Game Data folder in the KSP install.  Other functions seem fine -- though I haven't tested suicide burns, I'm still getting good results on maneuver nodes and closest approach rendezvous burns.

I'm running the direct KSP Store download, KSP 1.4.3 on Ubuntu MATE 16.04.5 LTS, kept up to date (daily, if necessary) with nVidia drivers (I doubt that makes a difference, but the KSP Launcher won't run on my desktop machine, and it does on my laptop with Intel graphics).  I have an AMD FX-8350, 8 cores at up to 4.1 GHz, with 16 GB RAM and GTx750 with 1 GB dedicated VRAM, and my storage for OS and the game is a 256 GB SSD.

[Snark]

15 hours ago, Zeiss Ikon said:

Okay, I hope I've just done something wrong or failed to do something I should.  I just upgraded to 1.4.3 this past long weekend

So far so good... latest version of BBT (1.6.1 as of this writing) works just fine in 1.4.3, I've been playing with it myself for many hours and haven't had any problems at all. 

15 hours ago, Zeiss Ikon said:

installed the same Better Burn Time download I'd had in 1.3.1

Whatever you're running, I'd suggest upgrading to the latest BBT version (1.6.1 as of this writing-- see below).

15 hours ago, Zeiss Ikon said:

First, in the countdown dots, the last three before "Z time" (which used to be circles with a dot inside) are now hollow squares, more or less the kind of character that shows when a font lacks the character you need.  If all i need to do is copy a font file from an older install, that'd be great, but if there's no fix, this isn't a deal breaker.

Sorry, no clue.  Works fine on my machine (running Windows 10).  If there's some font issue on your machine, maybe you need to install some font, but I would have no clue what that would be.  FWIW, the countdown-dots display is customizable via the settings file, so if there's some other character that does work for you, you can just edit the dots display to be whatever you want.

15 hours ago, Zeiss Ikon said:

Second, and potentially much more important, I'm not getting countdowns to either leaving atmosphere or re-entry as I did in previous KSP versions.  I've made multiple launches and reentries, both new craft and craft already in flight before the upgrade, with the same (lack of) result.

What version of BBT are you running?  If it's not 1.6.1, you should upgrade.

For a while BBT had a bug in the atmosphere tracker that prevented it from displaying a countdown (and made it spam exceptions to the log) if you hadn't upgraded the tracking station yet.  I fixed that bug in 1.6.1, which was released on 2017-12-29.  By any chance, are you getting this problem in a new career where you haven't upgraded the tracking station yet?

If upgrading to 1.6.1 doesn't solve the problem... could you take a look at the log file and see whether exceptions are showing up there?

Other than that... not sure what to tell you, other than it works fine in 1.4.3 on my machine.

[Zeiss Ikon]

I'm getting this in a career with all the ground installations (except the Admin building) fully upgraded.

Just checked the downloaded .zip file I installed from -- looks like I've got 1.6.  I'll try upgrading BBT to 1.6.1 first and see if that fixes the atmosphere interface times.  If it does, and I still get hollow squares instead of "target" dots for the last three seconds, I can live with that (or I'll dig in the settings file and find something else to replace them).  I honestly doubt it's a font issue, unless it's a font that's internal and private to KSP, because I've had no trouble with 1.3.1, 1.4, and 1.4.1 on the same Ubuntu installation.

[Patupi]

On 4/2/2018 at 8:50 PM, Snark said:

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.

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.

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.

Just to let you know, currently Ckan indicates that the max KSP version for BetterBurnTime is 1.4.3, not 1.4.4 But even if this doesn't get updated soon there is a workaround to force mods to be downloaded and installed manually through Ckan (if you don't want to do it the old fashioned way, or just happen to like the list on Ckan etc *shrugs*)

 

Use (Windows Key)+R to open Windows' own command line interface (not the one in Ckan, that confused me for a bit), type cmd and enter to get into the dos lookalike section, and then navigate through the Dos style commands to the appropriate folder that your KSP prog is in. Then type the following:

ckan install <identifier of mod as listed in Ckan on bottom right> = <mod version number as listed on bottom right>  --allow-incompatible

 

ie for Better Burn Time:

 

ckan install BetterBurnTime=1.6.1 --allow-incompatible

 

that should run it through dos to install it, you having to hit 'y' and enter to agree to the incompatible download and install

 

Note the '--allow-incompatible' is with two minus signs in front, and one inbetween the words. Also for this mod there is no space between 'BetterBurnTime' words, even though in the description on Ckan it looks like there is a space between 'Burn' and 'Time'. Oh, and the last thing, it won't work as long as Ckan is running, so get everything ready, copying the various stuff into the command line, but close Ckan before hitting enter.

 

Hope this helps someone, either for this mod or others. I'm no expert on Ckan, I just googled and hunted till I found something that worked for me. Done it successfully on two separate mods now, but be warned this is bypassing the checks for KSP version. Only do it on something you know works with your version of the game!

 

EDIT: missed a section getting into the dos command. Edited accordingly.

Edited July 6, 2018 by Patupi

[Athen]

I literally cannot live without this mod now.

[hab136]

Looks like BetterBurnTime got copied in KSP 1.5:

http://kerbaldevteam.tumblr.com/post/178546629889/ksp-weekly-the-falcon

The display of delta-V vs stages (the green bar) is actually quite clever.

[linuxgurugamer]

3 minutes ago, hab136 said:

Looks like BetterBurnTime got copied in KSP 1.5:

http://kerbaldevteam.tumblr.com/post/178546629889/ksp-weekly-the-falcon

The display of delta-V vs stages (the green bar) is actually quite clever.

Yes, it’s a nice improvement, but doesn’t do all of what BTW does:

• When the ship is in vacuum and on a collision course with the ground, it will automatically show time-to-impact, and the estimated burn time to kill your velocity at ground level.
• When the ship is in orbit and has an upcoming rendezvous with a target ship, it will automatically show time-to-closest-approach, and the estimated burn time to match velocity to the target.
• When the ship is on a course to enter or exit atmosphere in the next few minutes, shows time until the transition.
• For maneuver nodes and closest-approach, it shows a countdown indicator to tell you when to start your burn.

[Burning Kan]

23 minutes ago, hab136 said:

Looks like BetterBurnTime got copied in KSP 1.5

downloaded right now and see it was DL over quarter million times,seems Squad knows whats popular,

congratulation to Snark,and thx

[BlackHat]

Would be nice if they could also incorporate those abilities into the new stock BBT too. I do like the stage dV bar. 

[Atroner]

On 9/29/2018 at 5:19 AM, linuxgurugamer said:

Yes, it’s a nice improvement, but doesn’t do all of what BTW does:

• When the ship is in vacuum and on a collision course with the ground, it will automatically show time-to-impact, and the estimated burn time to kill your velocity at ground level.
• When the ship is in orbit and has an upcoming rendezvous with a target ship, it will automatically show time-to-closest-approach, and the estimated burn time to match velocity to the target.
• When the ship is on a course to enter or exit atmosphere in the next few minutes, shows time until the transition.
• For maneuver nodes and closest-approach, it shows a countdown indicator to tell you when to start your burn.

Do you think this mod will work in 1.5? Regards.

[linuxgurugamer]

1 hour ago, Atroner said:

Do you think this mod will work in 1.5? Regards.

Not without some reworking, according to the author