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

[Marschig]

22 hours ago, Snark said:

The stock burn indicator in KSP 1.5+ is better than BetterBurnTime, overall:  it actually takes staging into account, which BBT does not do and never will do

But it does this wrong. The stock indicator thinks that all engines are working, but only LV-N works. It shows "Burn Time: 4s" instead of "Burn Time: 65s" and incorrect Start Burn. It's a serious bug, that makes the stock indicator completely useless. BBT 1.6 handles this case correctly.

Spoiler

 

 

[Snark]

1 hour ago, Marschig said:

But it does this wrong.

Not my problem.  If there's a bug in it, presumably there will be a bug fix where needed.  I'd rather give Squad time to fix bugs, at zero effort on my part, rather than trying to second-guess them and spend a bunch of my time to work around their bug.

If their burn indicator turns out to be cripplingly wrong in a majority of use cases and stays that way for a really long time, then I may revisit the decision.  But for now, I view this as a bug-to-be-fixed rather than a missing feature.

Let's focus our effort on giving good bug reports to Squad about the burn indicator so that they have the best opportunity to fix it-- which will benefit everyone in the KSP community, not just the minority who happen to be using this mod. 

@Marschig, if you've got an example of a ship (built with stock parts) that the stock indicator doesn't work for... could you please post a .craft file somewhere so it's possible to download & try out?

(Reason I ask:  the programming problem that Squad is trying to solve with their new burn indicator is a really hard one.  The thing that makes it really hard is that there's so much flexibility of ship design in KSP, so it's easy for there to be "edge cases" that their algorithm doesn't account for.  My guess as to what's going on if you've got a ship that breaks it, is that you've managed to bump into an edge case that's unaccounted for.  Therefore, it's really important to make sure that they have access to that specific ship.  If I were in Squad's shoes and wanting to "fix the burn indicator", it's going to involve trying to address all kinds of edge cases-- so I'd want a list of "here are the various ships that people have had trouble with" so that it's possible to evaluate and debug exactly why they're not working, so that the code can be remedied.)

[Marschig]

9 hours ago, Snark said:

Let's focus our effort on giving good bug reports to Squad about the burn indicator so that they have the best opportunity to fix it-- which will benefit everyone in the KSP community, not just the minority who happen to be using this mod.

I posted the bug to the bugtracker https://bugs.kerbalspaceprogram.com/issues/20265

 

[Snark]

8 hours ago, Marschig said:

I posted the bug to the bugtracker https://bugs.kerbalspaceprogram.com/issues/20265

Excellent, thank you!  This is exactly the sort of thing they need for finding & fixing bugs.

[Bej Kerman]

The stock 1.5 manoeuvre still makes you burn when time to manoeuvre matches time to burn - you're supposed to burn when time to burn is double time to node. Aren't you?

[Beetlecat]

1 minute ago, Bej Kerman said:

The stock 1.5 manoeuvre still makes you burn when time to manoeuvre matches time to burn - you're supposed to burn when time to burn is double time to node. Aren't you?

You can switch on the "extended mode" in settings that will allow you to set the time-to-burn countdown to the desired percentage of total burn time, not just half.

[Bej Kerman]

Just now, Beetlecat said:

You can switch on the "extended mode" in settings that will allow you to set the time-to-burn countdown to the desired percentage of total burn time, not just half.

Oh, I already have that on - I thought that was how much fuel you wanted to burn on the node. I do notice that it shows proper burn time predictions with this mod on. Honestly, I salute you for not half-assing the manoeuvre node like squad did.

[Snark]

1 hour ago, Beetlecat said:

the desired percentage of total burn time

Correction:  it's cooler than that.  It's desired percentage of total dV, not time.

In other words, say you've got a 1000 m/s burn, and it's projected to take 60 seconds.  And suppose you've got that control set to 50% (the default).  It won't tell you to start your burn at T minus thirty seconds (which would be half the time).  It'll tell you to start at a time such that when you hit T-zero, you have burned 500 m/s of dV and have 500 m/s remaining.

That's actually pretty darn cool, because that's something that's not so trivial to punch out on a hand calculator.  It's made me re-think how BBT does its countdowns (the countdown is still there, for orbital rendezvous tracker)-- maybe I should switch to "half of dV" rather than "half of time", myself.  (Not that it makes that big of a difference in practice, at least for orbital rendezvous-- the amount of dV involved there is usually not super huge, so 50% of dV is likely to be pretty close to 50% of time anyway.)

 

1 hour ago, Bej Kerman said:

Oh, I already have that on - I thought that was how much fuel you wanted to burn on the node. I do notice that it shows proper burn time predictions with this mod on. Honestly, I salute you for not half-assing the manoeuvre node like squad did.

Um, I'm confused.  We're talking about the stock maneuver node indicator here for KSP 1.5+, yes?  You'll get the same experience for that regardless of whether you have BetterBurnTime installed or not.  Because as of BetterBurnTime 1.7, that's what you're getting for maneuver nodes now-- the stock indicator.  How is what they did "half-assed"?  (Or are you talking about the old stock indicator, before KSP 1.5?)

[Bej Kerman]

3 minutes ago, Snark said:

Um, I'm confused.  We're talking about the stock maneuver node indicator here for KSP 1.5+, yes?

Yes

 

4 minutes ago, Snark said:

You'll get the same experience for that regardless of whether you have BetterBurnTime installed or not.

Before I installed it, the 1.5 stock burn time indicator sometimes gave incorrect readings, which also became pretty obvious when doing long burns.

5 minutes ago, Snark said:

How is what they did "half-assed"?  (Or are you talking about the old stock indicator, before KSP 1.5?)

Talking Pre-1.5

[Bej Kerman]

Does this mod also make manoeuvre nodes account for jettisoned stages? I've just noticed the "Start Burn" indicator jumps deep into the negatives when I jettison to a less powerful stage.

[Snark]

Just now, Bej Kerman said:

Does this mod also make manoeuvre nodes account for jettisoned stages? I've just noticed the "Start Burn" indicator jumps deep into the negatives when I jettison to a less powerful stage.

When you ask a question like this, you really need to be specific about what you're running.

• What version of KSP are you playing?
• What version of BetterBurnTime are you running?

It matters a lot because these things change over time.  In particular, things changed a lot with KSP 1.5 / BetterBurnTime 1.7, so the answer will be very different based on exactly what you're running.

 

If you're using KSP 1.5 or later, with BetterBurnTime 1.7 or later, what you're seeing is nothing to do with this mod because you are looking at the STOCK burn indicator.

If you're asking about older KSP-- i.e. KSP 1.4.5 or earlier, running with BetterBurnTime 1.6.1 or earlier, then the answer is no, BetterBurnTime's calculations never took staging into account, at all.  It never has.  The new stock burn indicator in KSP 1.5 does take staging into account, which makes it better than BetterBurnTime's maneuver-node calculations, which is why I turned off BetterBurnTime's maneuver-node indicator in my 1.7 release.

[Bej Kerman]

2 minutes ago, Snark said:

• What version of KSP are you playing?
• What version of BetterBurnTime are you running?

1.5.1, 1.7

3 minutes ago, Snark said:

BetterBurnTime's calculations never took staging into account, at all.  It never has.

Exactly.

 

3 minutes ago, Snark said:

The new stock burn indicator in KSP 1.5 does take staging into account

The burn bar shows when to jettison stuff but doesn't seem to tell that to the burn time - this screwed me over once (five minutes ago) when launching a missile as the Wolfhound engine is much less powerful than a liftoff tank with 3 vector engines glued on back. It told me that I'd have to burn a few seconds then told me it'd take much more time and then I basically just belly-flopped into the atmosphere, making a futile attempt to escape its clutch - so I'd love to see some algorithm changes that take into account more than 1 stage at a time.

Also, the burn time for syncing speeds with the target is clipped inside the navball - thought I'd give a heads up for people with OCD.

[Snark]

22 minutes ago, Bej Kerman said:

The burn bar shows when to jettison stuff but doesn't seem to tell that to the burn time - this screwed me over once (five minutes ago) when launching a missile as the Wolfhound engine is much less powerful than a liftoff tank with 3 vector engines glued on back. It told me that I'd have to burn a few seconds then told me it'd take much more time and then I basically just belly-flopped into the atmosphere, making a futile attempt to escape its clutch - so I'd love to see some algorithm changes that take into account more than 1 stage at a time.

It does, very much so.  I use it routinely, when I've got a high-thrust lower stage coupled to a low-thrust upper stage, for circularization burn.  Works great.

That said, the real issue for making a piece of software that can do multi-stage calculations in KSP is the insane number of possible rocket configurations-- the number of edge cases is just astronomical.  It's a seriously difficult programming problem, which is why I was never even slightly tempted to attempt it in BetterBurnTime; this is a spare-time hobby for me, I don't have that kind of time.  I'm happy to see that Squad has taken it on, and in general they appear to have done a pretty good job, as far as I can tell from my own gameplay.

However, it's also clear that they have some bugs that have issues with certain specific edge cases-- so maybe you're running into one of those, which is why you think "it's broken" when I think "it's fine".  But the devil's in the details-- exactly why you're seeing what you're seeing would depend on the exact specifics.  i.e. the specific design of your rocket, the specific circumstances of the burn.  So, not really possible to have any idea of what's going on with you, based on what you've said so far, because you haven't given those specifics.

But, please don't give that info here.  This is not a thread about the KSP stock burn indicator.  This is a thread about BetterBurnTime.  Please take discussion about the stock burn indicator elsewhere.

So if you have any issues with the burn time for maneuver nodes, with KSP 1.5-or-later and BetterBurnTime 1.7-or-later, this thread is not the place to talk about that.  It's a great discussion to have, but please take it somewhere that it's actually relevant-- e.g. KSP Discussion, or Technical Support, or Suggestions.  Even better, file a well-formed bug report on Squad's bug tracker so that they know about the problem and can address it.

No point in bringing it up here, because nobody who matters will read about it here, and there's nothing that anyone here (including me) can do anything about it.

[therealcrow999]

Lol, you almost have to rename this now. Better Navball Indicators or something. 

[therealcrow999]

@SnarkI have the info overlaying on the navball. I believe my navball is re-scaled down to 80% or 90%. 

My Logs.

I just downloaded this like a hour ago on CKAN. So its the new mod, in my bunch.

[Snark]

On 10/22/2018 at 11:42 AM, Bej Kerman said:

Also, the burn time for syncing speeds with the target is clipped inside the navball - thought I'd give a heads up for people with OCD.

6 hours ago, therealcrow999 said:

@SnarkI have the info overlaying on the navball. I believe my navball is re-scaled down to 80% or 90%.

Thanks!

Yep, other folks have mentioned some issues with rescaled navball, too.  I've only ever played at standard default size, which means when I wrote the code I didn't test all the other sizing options available.

I should fix it, yes-- this has been known for quite some time. Main reason I haven't, thus far, is that it would take a large amount of my time.  Not that I expect the fix to be super complicated; I'm guessing that it will ultimately turn out to be some really simple one-or-two-line tweak to the code.  However, it's finding the right tweak that's the challenge; it would involve a lot of head-scratching and trial-and-error coding and testing and so forth, in the area of Unity UI which, personally, I find very arcane and cryptic to work with.

So unless someone figures out a solution and just tells me exactly what to look for, a fix for this problem will have to wait until I have a lot of free time on my hands and nothing else to do, which could be a while.

[therealcrow999]

10 hours ago, Snark said:

Thanks!

Yep, other folks have mentioned some issues with rescaled navball, too.  I've only ever played at standard default size, which means when I wrote the code I didn't test all the other sizing options available.

I should fix it, yes-- this has been known for quite some time. Main reason I haven't, thus far, is that it would take a large amount of my time.  Not that I expect the fix to be super complicated; I'm guessing that it will ultimately turn out to be some really simple one-or-two-line tweak to the code.  However, it's finding the right tweak that's the challenge; it would involve a lot of head-scratching and trial-and-error coding and testing and so forth, in the area of Unity UI which, personally, I find very arcane and cryptic to work with.

So unless someone figures out a solution and just tells me exactly what to look for, a fix for this problem will have to wait until I have a lot of free time on my hands and nothing else to do, which could be a while.

Weird thing is I was using this mod in 1.4.5 and no issues. I always used the same re-scale, for a long while. It's all good, just one of those things. Thanks.

[incal1]

The countdown indicator does not appear for me at all !

I had grown so used to those little dots

As far as I can tell the rest of the mod seem to work, perhaps the dots are stuck behind the navball?

I have tested this on a fresh install with no other mod, and I made sure I downloaded the latest version. I'm playing ksp 1.5.1 on windows, if that's any help.

[DStaal]

5 minutes ago, incal1 said:

The countdown indicator does not appear for me at all !

I had grown so used to those little dots

As far as I can tell the rest of the mod seem to work, perhaps the dots are stuck behind the navball?

I have tested this on a fresh install with no other mod, and I made sure I downloaded the latest version. I'm playing ksp 1.5.1 on windows, if that's any help.

The timer you're seeing is actually now from stock KSP, not from this mod - at least for maneuvers.  Read back through the thread - Snark doesn't feel the need to override the new stock behavior.  (Especially since the countdown itself is actually more accurate than his system was.)

[incal1]

30 minutes ago, DStaal said:

The timer you're seeing is actually now from stock KSP, not from this mod - at least for maneuvers.  Read back through the thread - Snark doesn't feel the need to override the new stock behavior.  (Especially since the countdown itself is actually more accurate than his system was.)

I skimmed the pages but somehow missed that part. My bad. A shame.

There's still older versions of the mod if I want the dots back, I guess.

Edited November 7, 2018 by incal1

[Snark]

1 hour ago, incal1 said:

There's still older versions of the mod if I want the dots back, I guess.

Assuming you're either running a pre-1.5 version of KSP, that is.  I make no guarantees that BetterBurnTime 1.6.1 or earlier will work with KSP 1.5 or later.  If it does, then good for you, but I haven't tested it, and won't be testing it, and won't be offering any support for that.  I wouldn't be surprised if it has indigestion caused by trying to arm-wrestle with the new stock navball.

[incal1]

25 minutes ago, Snark said:

I wouldn't be surprised if it has indigestion caused by trying to arm-wrestle with the new stock navball.

I actually tested a backup of BBT,  1.6.1, with the latest version of ksp. Beside the slightly misplaced dots, no burps so far...

I could live with that. But if anything else happen I'll know to just wave the dots goodbye. I shall miss them.

[Snark]

Apropos of which, this question came up in another thread regarding a bug in the new-and-improved burn indicator in KSP 1.5.x (it has problems with multiple LV-N or ion engines on a craft):

1 hour ago, Rocket In My Pocket said:

Please don't take this the wrong way (not trying to pester you) but, have you given any further thought to even a temporary reinstatement of BetterBurnTime's version of burn time indication, in light of this bug and in the event a fix from Squad doesn't materialize in a timely fashion? (Despite their recent announcement about faster updates, with the holidays coming soon; I have a bad feeling we won't be seeing this fixed for at least a month or two.)

Nah, it's fine, this is a perfectly reasonable question.   

My impression is that they're trying to minimize the "point" releases (i.e. the "x" in 1.5.x) only to a bare minimum of highly targeted game-critical fixes.  So my assumption is that there won't be any more 1.5.x releases after 1.5.1, and we'll need to wait for KSP 1.6 to see this fixed in the stock game.

And since they said they were going to aim for roughly one update per three months, that would tentatively put KSP 1.6 somewhere around mid-January 2019.  (No, I don't have any inside info, here-- I'm just extrapolating from their public statements.)

The burn indicator bug with multiple LV-Ns or ions seems to me like a problem that isn't bad enough to merit another 1.5.x release, but sufficiently serious that I'd be astonished if they don't fix it in 1.6.

So, we're looking at (hopefully) about two months from now until this is fixed in stock.

1 hour ago, Rocket In My Pocket said:

have you given any further thought to even a temporary reinstatement of BetterBurnTime's version of burn time indication, in light of this bug

I thought about it, but I'm not super inclined to do it.  It would be (presumably) throwaway work, and I'm not in a super hurry since the problem doesn't bite me, personally, all that badly (I do like using LV-Ns and ions, but my designs usually don't involve multiple of them, so I tend not to get bitten by this bug often).  And two months is soon enough for me-- if I thought it were likely to take a year or something, then I'd be more likely to consider it.

It wouldn't be all that big a time investment... but it would be nonzero, and I'm busy enough IRL these days that I'm unlikely to invest much effort in a problem that, 1. doesn't affect me much, and 2. is likely to be fixed in a couple of months anyway.

1 hour ago, Rocket In My Pocket said:

On the same note; does the last version of BBT that had it, still work in 1.5.1? i haven't tried it but I get the feeling the mod and stock "systems" won't play nice together?

Happily, the answer actually appears to be that yes, it does work.  I haven't tested that myself (nor do I intend to), but please see @incal1's post immediately above this one-- he's apparently been running BBT 1.6.1 okay with KSP 1.5.x.

So if this really bugs you a lot, it looks like you can use the older BBT version.  Just be aware that I don't consider it to be a "supported" scenario, so if you do encounter any problems or edge cases or whatever, it's not worth reporting to me because my rubber-stamp reply will be "not supported, please use the latest BBT". 

 

[Rocket In My Pocket]

Thanks for the response! I understand your reasoning completely.

I may give the older version a try for now myself, since I still have a copy sitting around in my Downloads folder.

I do have one more question actually, which is more just for curiosities sake; Did you encounter any similar issue when coding BBT as Squad is encountering now? Ie. Did you wrestle with taking multiple NERV/Ion's into account as well in some way? Or is this a deeper problem with the game's new "behind the scenes" Delta V calculations itself? Not expecting you to know exactly per se, just was interested in hearing your relatively expert opinion on the matter.

[Snark]

12 minutes ago, Rocket In My Pocket said:

since I still have a copy sitting around in my Downloads folder

And even if you didn't, Spacedock has a handy feature that lets you download any past version you want.  Just go to the "changelog" tab-- it lists all the past versions, with a download link for each.

30 minutes ago, Rocket In My Pocket said:

I do have one more question actually, which is more just for curiosities sake; Did you encounter any similar issue when coding BBT as Squad is encountering now? Ie. Did you wrestle with taking multiple NERV/Ion's into account as well in some way?

Nope, not even slightly.  It "just worked".  And, in fact, when I heard about this bug in the new KSP 1.5 stock indicator, I was kinda scratching my head, because... how?

I mean, there's nothing special about LV-Ns or ions.  They're just engines.  That is, they're just "a part which consumes <propellant mix> at <rate> in order to generate <thrust>."  The calculations for that should be essentially one-size-fits all, regardless of how much thrust or what rate or what propellant mix.  Those are simply variables.  It means that either the whole shebang works (for all engine types), or it's got a bug and none of it would work.

So, it was kind of a head-scratcher for me how one would manage to work for other engines but not these.  I mean, if I had deliberately wanted BBT not to work with, say, multiple LV-Ns, I would have had to write special code to do so.  The simplest "path of least resistance" is to "just work."

(Well, actually, okay, there is one special case I put in:  if one of the "propellants" required is electricity, e.g. as with ions, then BBT deliberately ignores the electricity requirement.  Otherwise it would tell you things like "you don't have enough electricity to make this burn" even though you've got plenty of solar panels to maintain a steady supply.  But that's one little special case, and I've noticed that Squad did the same thing in their implementation.)

34 minutes ago, Rocket In My Pocket said:

Or is this a deeper problem with the game's new "behind the scenes" Delta V calculations itself?

This.

I have no idea what the problem is, exactly, since I don't have access to their source code.  But whatever it is, it's something specific to their implementation.

Just to be clear:  Please don't interpret any of my "gosh sakes, how the dickens could this happen" musings above as implying in any way that the Squad folks who implemented the new stock burn indicator are bozos, or lazy, or anything like that.  It's worth noting that they're solving a far harder problem than I did in BBT, because their feature actually takes staging into account.  That may not seem like such a big deal, if you're not a programmer, but take it from me, it's huge.  It's a big fat hairy deal.  Given the complexities of KSP (specifically, the immense design freedom that players have in slapping together a rocket any which way), I expect that right there is easily a harder problem than the whole rest of BetterBurnTime put together.

It's not an insurmountable problem-- I could have gone down that road with BBT if I'd wanted to-- but it's a big, labor-intensive feature with a ton of edge cases, which would require a lot of coding and huge amounts of testing.  That's why I didn't even bother trying it-- I simply didn't feel like committing to that amount of effort, and consciously chose not to solve that problem.

The fact that Squad's solving that problem, where I'm not, means that they're going to have to contend with all kinds of complexities that I don't.  (For example, xenon has a different flow model than LFO does.  LF engines other than the LV-N have a different flow model than LFO does.  I wouldn't be that surprised if it turns out that their code has some sort of weakness around fuel-flow modeling, or something, which might trigger this problem.  If that's the case, then it makes sense that my own code wouldn't encounter it, since I don't try to model fuel flow at all.)

Moral of the story:  Solving harder problems is great.  But it's also... well... harder.