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

[Anth]

Oh. Cool. Got it. Thank you.

[DomiKamu]

Hi Snark,

I'm testing BetterBurnTime v1.9.1 against KSP v1.7.0, I have ton of exceptions generated while landing (using MechJeb 2 Dev #883 - landing autopilot / after "Pick target on map") on the Mun:

Recurent line is:

[ERR 11:15:24.956] [BetterBurnTime] (NullReferenceException) Object reference not set to an instance of an object:   at BetterBurnTime.GeosyncTracker.RefreshTarget (.Vessel vessel) [0x00000] in <filename unknown>:0
  at BetterBurnTime.GeosyncTracker.Refresh () [0x00000] in <filename unknown>:0
  at BetterBurnTime.GeosyncTracker.LateUpdate () [0x00000] in <filename unknown>:0

This is my KSP.log: https://www.dropbox.com/s/wdmei0uith5kskt/KSP.log?dl=0

Edited May 4, 2019 by DomiKamu

[Snark]

3 hours ago, DomiKamu said:

I'm testing BetterBurnTime v1.9.1 against KSP v1.7.0, I have ton of exceptions generated while landing (using MechJeb 2 Dev #883 - landing autopilot / after "Pick target on map") on the Mun:

Aha.  I think I see what's going on, and it's easily fixed.  Short answer is that you've run into an edge case that I didn't anticipate, and which I didn't encounter since I never run MechJeb.  I'll get a fix out when I can.  Thanks for reporting!

Technobabble with internal programming details, for the curious, in a spoiler.

Spoiler

Most of KSP's C# API is implemented in terms of classes, but there are few places where it uses interfaces.  Targets are one of these.  If you have a ship, and you target something... well, the game lets you target vessels, but also lets you target celestial bodies.

Vessel and CelestialBody are completely different classes with completely different properties, though they do share some properties in common (e.g. they both have an orbit, for example).  So, put yourself int he developers' shoes.  I've got the Vessel class, and I need it to be able to target something, and that target might be either of two completely different things... how do I write my target-handling code so that it works equally well whether the target happens to be a vessel or a celestial body?

The simple and (to any programmer) obvious solution is to use an interface, which is what KSP does.  It has ITargetable.  The classes Vessel and CelestialBody both implement this interface.  All perfectly nice and normal.

So, where BBT ran afoul, here, is that I'm an idiot and committed one of the cardinal sins of programming-- cannot believe I did that, I guess I must have been tired that day.    What I did was... I made assumptions about which classes might implement an interface.  There's some code in BetterBurnTime for the geosynchrony tracker that I introduced in BBT 1.9, which basically goes like this:  "Okay, I need to get my target... okay got it.  It's an ITargetable, and I know that the only two things that implement that are Vessel and CelestialBody, and each of those have an "orbit" property, so I'll just get that and use it."

Well, the highlighted bit above is a wholly unwarranted assumption, and is a classic mistake that noob programmers make.   If you have a reference to an interface, you are not allowed to make any assumptions about the class that may be implementing that interface.  Specifically, do not assume that you know all the classes that might be implementing it, because you don't.  That's the whole point of interfaces.

My assumption worked fine in the stock game... but it looks as though MechJeb must be (quite legitimately) including some new thing that implements ITargetable, I'm guessing it's that "target on map" thing.  And that new targetable thing happens not to have an orbit of its own, so calling ITarget.GetOrbit() on it returns null.

Which is all well and good and should have been no problem, except that I am, as previously mentioned, an idiot, and I just blithely assumed (when I shouldn't have) that ITarget.GetOrbit() will never return null.  (I assumed that because it applied to all the implementations of ITargetable that I knew of.)  So I rely on that, thus the NullReferenceException spew.

The good news is that the problem is easily fixed, just a line or two of code.  I simply check whether the target's orbit is null first (duh!), and then do stuff with it only if it's not null.

 

[DomiKamu]

1 minute ago, Snark said:

Aha.  I think I see what's going on, and it's easily fixed.  Short answer is that you've run into an edge case that I didn't anticipate, and which I didn't encounter since I never run MechJeb.  I'll get a fix out when I can.  Thanks for reporting!

Technobabble with internal programming details, for the curious, in a spoiler.

  Hide contents

Most of KSP's C# API is implemented in terms of classes, but there are few places where it uses interfaces.  Targets are one of these.  If you have a ship, and you target something... well, the game lets you target vessels, but also lets you target celestial bodies.

Vessel and CelestialBody are completely different classes with completely different properties, though they do share some properties in common (e.g. they both have an orbit, for example).  So, put yourself int he developers' shoes.  I've got the Vessel class, and I need it to be able to target something, and that target might be either of two completely different things... how do I write my target-handling code so that it works equally well whether the target happens to be a vessel or a celestial body?

The simple and (to any programmer) obvious solution is to use an interface, which is what KSP does.  It has ITargetable.  The classes Vessel and CelestialBody both implement this interface.  All perfectly nice and normal.

So, where BBT ran afoul, here, is that I'm an idiot and committed one of the cardinal sins of programming-- cannot believe I did that, I guess I must have been tired that day.    What I did was... I made assumptions about which classes might implement an interface.  There's some code in BetterBurnTime for the geosynchrony tracker that I introduced in BBT 1.9, which basically goes like this:  "Okay, I need to get my target... okay got it.  It's an ITargetable, and I know that the only two things that implement that are Vessel and CelestialBody, and each of those have an "orbit" property, so I'll just get that and use it.

 

You're welcome! Be sure BBT stays a great mod! Thanks (merci in French - my language).

[Cyrious]

I seem to have run into an issue where the Countdown Text (the pips, i also tried editing the config to text according to the instructions) bits do not show when approaching a maneuver node.  I'm not sure if its a bug with the mod itself or it having an issue with other mods/squad's code instead.

The mod itself IS working, I've seen the Geosync, time to entry interface and SRB burn time indicators, but not the one that's arguably the most useful, the pips themselves. Looking at the log doesn't show any errors (so far as I can see) of the mod spazzing out or otherwise glitching, so I dunno what is going on.

Any ideas?

[DStaal]

23 minutes ago, Cyrious said:

I seem to have run into an issue where the Countdown Text (the pips, i also tried editing the config to text according to the instructions) bits do not show when approaching a maneuver node.  I'm not sure if its a bug with the mod itself or it having an issue with other mods/squad's code instead.

The mod itself IS working, I've seen the Geosync, time to entry interface and SRB burn time indicators, but not the one that's arguably the most useful, the pips themselves. Looking at the log doesn't show any errors (so far as I can see) of the mod spazzing out or otherwise glitching, so I dunno what is going on.

Any ideas?

Intentionally removed so as not to conflict with Squad's implementation.

[Cyrious]

12 minutes ago, DStaal said:

Intentionally removed so as not to conflict with Squad's implementation.

Huh. Ok then, is there a setting somewhere to turn them back on, or is this a "code's not there anymore, you're SOL" type deal?

Welp, found the setting, got the countdown back. Still liked the pips though. Maybe a future version of the mod can override the stock countdown text with them.

Edited May 22, 2019 by Cyrious

[pejmany]

Does anyone know how to get the countdown back?

[Snark]

18 hours ago, pejmany said:

Does anyone know how to get the countdown back?

It's still there, for target rendezvous.  For maneuver node burns, though, it's not a thing anymore. I removed the feature because KSP now provides a stock burn indicator that does essentially the same thing.

[Sarxis]

This is a great mod for those of us not using Mechjeb at the mooment.  I bought the DLCs and did a fresh start/install of KSP and wanted to keep things more stock in the game now that the devs have implemented some niceties (Maneuver Planner) into the UI.  

 

Big thanks!

[jpinard]

Because I'm stupid, how does this differ from the implementation the latest version + DLC that stock KSP added?

Thanks

[RealKerbal3x]

25 minutes ago, jpinard said:

Because I'm stupid, how does this differ from the implementation the latest version + DLC that stock KSP added?

Thanks 

This mod used to improve the old stock burn time display, which was inadequate to say the least. Then in version 1.5, SQUAD implemented a much-improved version of the burn time display, obviating BBT's version. The reason that BBT is still around is because it provides some other burn indicators for different situations that the stock game still doesn't have.

Oh and by the way, 1.7.x and Breaking Ground haven't introduced anything that duplicates anything in Better Burn Time, so it's unaffected.

[jpinard]

OK thanks for explaining!

[psychonaut25]

I'm having a rather unique problem ever since I updated to from KSP 1.3.1 to 1.7.3 recently.  I updated to the most recent version of Better Burn Time, and began to experience a weird symptom during rendezvous.

Just as I reach my closest approach to my target craft, the target craft's orbit changes dramatically, to more-or-less match the orbit of the current vessel, thereby reducing our relative velocity to close to zero.  My closest approach is also altered, and usually lengthened by several kilometers.

I can't confirm that this is a problem with Better Burn Time, but I have a suspicion that it is, because it always seems to happen as soon as those final three dots to the right of my navball vanish.

Does anybody else have any experience with this problem, or a solution?

Demo Video 1
Demo Video 2

KSP.log

On another note... I read the main post which points out that after 1.5, the navball functionality was improved for maneuver nodes, and so the extra functionality from Better Burn Time was removed.  Pardon the noob question, but... I don't notice the difference in navball functionality when timing maneuver burns, could anybody enlighten me on that?

Edited September 16, 2019 by psychonaut25
Updated log file link and added video demonstration

[Snark]

12 hours ago, psychonaut25 said:

Does anybody else have any experience with this problem, or a solution?

Thank you for reporting-- really nice that you went the extra mile to capture videos in addition to posting a log. 

However, in the absence of a "smoking gun" for further corroboration, I have to say that I believe it's physically impossible for BetterBurnTime to be causing this issue.

The reason is that BetterBurnTime does not have any actual physical effect on any game state whatsoever.  It reads data (about the current ship, and about the target).  It performs its own calculations on the data that it has gathered, and it displays some information in text UI.  But it doesn't affect anything.  There's not a single line of code anywhere in BetterBurnTime, not one, that affects any game state whatsoever, other than the text UI where it outputs its information.  It shouldn't be physically possible for it to cause a problem like this, any more than turning your kitchen sink on and off should be able to affect your car's gas mileage.  They're just not connected.

There's also the fact that BBT has had many thousands of users for several years, and if this were a problem with BBT, it seems likely that someone would have run into it before now.  It's also worth noting that the target-intercept code hasn't been touched at all in years, certainly since long before 1.7.3 came out two months ago, which also would tend to suggest that this is not where the problem lies.

Can you reproduce this problem with all other mods uninstalled, such that you're running only BBT and nothing else at all?

• If you can, then that would be a useful data point, and a copy of a stock-except-for-BBT savegame, where the problem consistently and reproducibly happens, would be necessary to have even a chance of starting to investigate.
• If you can't (which is what I'm guessing will be the case, for the reasons described above), then that would pretty much be a "smoking gun" that points squarely at some other mod being the problem.  In which case you'd need to do some process-of-elimination to figure out which mod it is, and then go inquire in that mod's thread.

12 hours ago, psychonaut25 said:

On another note... I read the main post which points out that after 1.5, the navball functionality was improved for maneuver nodes, and so the extra functionality from Better Burn Time was removed.  Pardon the noob question, but... I don't notice the difference in navball functionality when timing maneuver burns, could anybody enlighten me on that?

BBT used to provide two bits of functionality that helped with maneuver nodes:

1. A more-accurate and more-reliable burn duration indicator (the stock game had one, but it was inaccurate and often just "N/A")
2. A countdown indicator of when to start the burn (the stock game didn't have this at all, forcing the player to do math every time).

Both of these have since been addressed in the stock game, which is why I removed it from BBT:

• Issue #1 is implicit-- they simply made the burn-duration indicator more accurate and reliable, removing the need for BBT to try to tinker with that, and no action on your part is required.
• Issue #2 is now provided in stock by some additional UI, just below the burn-duration indicator, that shows when to start the burn.

However, for reasons that absolutely baffle me, the way they choose to implement #2 is not only optional (why would anyone not want this?), but is actually turned off by default (why?!), and is also really undiscoverable, meaning that most players don't even see it and are completely unaware of its existence, which utterly perplexes me since it's such a crucial piece of information.  I'm sure they had their reasons for burying it like this, given how brilliant and useful it is, but I've never been able to understand what those reasons might be.

Anyway, you have to turn it on.  I'm not in front of my KSP computer right now so I don't remember exactly where it is, but basically you go rummage around in the game settings, and somewhere there's a check box with a name that's something like "Show Extended Burn Info" or "Show Advanced Burn Info" or something like that.  (There's also a slider for "what percentage of my dV do I want to do before the burn point", which defaults to 50% which is the reasonable choice and I see no reason why you'd want to tinker with that, but I mention it here because when your eyeballs are hunting around for the checkbox, knowing that it'll be next to a slider might help you to spot it.)

I think, IIRC, it'll be under UI options rather than settings for a particular savegame, because I think after you set it once, it applies to all your games (present and future) and you never have to tinker with it again.

[Thiagobs]

About @psychonaut25's issue, I have experienced the same orbit-matching issue WITHOUT BetterBurnTime...

I have preliminary traced it to "Docking Camera KURS" mod, which psychonaut25 also have installed.

Curiously, that mod shouldn't mess up with orbital info either, but another user have also reported the same issue on KURS thread.

Removing that mod solves the issue, but I have half a mind that it may be more complex than just KURS and it may be some odd interaction between mods, but I haven't tested it yet

Approaching the target craft in timewarp will prevent that issue and works as a workaround (trick is to be in timewarp when the physics kick in at 2.1 meters)

[psychonaut25]

9 hours ago, Snark said:

However, for reasons that absolutely baffle me, the way they choose to implement #2 is not only optional (why would anyone not want this?), but is actually turned off by default (why?!), and is also really undiscoverable, meaning that most players don't even see it and are completely unaware of its existence, which utterly perplexes me since it's such a crucial piece of information.  I'm sure they had their reasons for burying it like this, given how brilliant and useful it is, but I've never been able to understand what those reasons might be.

Anyway, you have to turn it on.  I'm not in front of my KSP computer right now so I don't remember exactly where it is, but basically you go rummage around in the game settings, and somewhere there's a check box with a name that's something like "Show Extended Burn Info" or "Show Advanced Burn Info" or something like that.  (There's also a slider for "what percentage of my dV do I want to do before the burn point", which defaults to 50% which is the reasonable choice and I see no reason why you'd want to tinker with that, but I mention it here because when your eyeballs are hunting around for the checkbox, knowing that it'll be next to a slider might help you to spot it.)

I think, IIRC, it'll be under UI options rather than settings for a particular savegame, because I think after you set it once, it applies to all your games (present and future) and you never have to tinker with it again.

I found it!  It's actually in the settings for my savegame, but I only have one, so I'm okay with that.  But it's extremely helpful, so I really appreciate you pointing that out!  Thanks for such detailed help on that.

4 hours ago, Thiagobs said:

About @psychonaut25's issue, I have experienced the same orbit-matching issue WITHOUT BetterBurnTime...

I have preliminary traced it to "Docking Camera KURS" mod, which psychonaut25 also have installed.

Curiously, that mod shouldn't mess up with orbital info either, but another user have also reported the same issue on KURS thread.

Removing that mod solves the issue, but I have half a mind that it may be more complex than just KURS and it may be some odd interaction between mods, but I haven't tested it yet

Approaching the target craft in timewarp will prevent that issue and works as a workaround (trick is to be in timewarp when the physics kick in at 2.1 meters)

Well I'll be damned... yep, I removed Docking Camera KURS and it looks like the problem has been resolved!  Thank you so much for pointing that out!

[Snark]

Hi gang,

Just a note that I've released BetterBurnTime v1.10.  No new features, just a compatibility update for KSP 1.8.

[New Horizons]

I tryied to ask before, but my post is not here anymore... 

Do some of you too have the bug, that a custom time warp is not permanent, after you clicked on it? I always have to rechoose it after a scene change - playing with JNSQ here.

[Jognt]

19 minutes ago, New Horizons said:

I tryied to ask before, but my post is not here anymore... 

Do some of you too have the bug, that a custom time warp is not permanent, after you clicked on it? I always have to rechoose it after a scene change - playing with JNSQ here.

This is the BetterBurnTime thread, I’m assuming you wanted to comment in the BetterTimeWarp thread.  

To answer your question though: yes, I have to select warps every scene. 

[New Horizons]

My mistake, better double check wich "Better" thread to open.  

[Atlas Gaming]

Just had to say this is one of thous TOTALLY INDISPENSABLE mods once you use it for a while. Thanks for creating it!

[DomiKamu]

Hi, too bad (since some releases I presume) the countdown by using dots seems disabled (for node maneuvers), yep too bad because the effect was nice, and useful (IMO).

Thanks (again) however about this great mod - always in my list!

Edited December 16, 2019 by DomiKamu
Fixed English faults

[RealKerbal3x]

9 hours ago, DomiKamu said:

Hi, too bad (since some releases I presume) the countdown by using dots seems disabled (for node maneuvers), yep too bad because the effect was nice, and useful (IMO).

Thanks (again) however about this great mod - always in my list!

I believe that feature was removed because in version 1.5 SQUAD added a stock version, which meant that it was no longer necessary in BBT.

[ThePatsch78]

Hi Snark!

Some time ago you answered to a bug report (NRE, getOrbit()):

On 5/4/2019 at 2:50 PM, Snark said:

Aha.  I think I see what's going on, and it's easily fixed.  Short answer is that you've run into an edge case that I didn't anticipate, and which I didn't encounter since I never run MechJeb.  I'll get a fix out when I can.  Thanks for reporting!

Technobabble with internal programming details, for the curious, in a spoiler.

But unfortunately the only BBT version containing the fix is for KSP 1.8. My plan was to fork it, revert the latest commit and add the fix taken from your 1.8 commit and kinda re release it. I was trying to figure out the rules for that and found your "paper" about forking and maintaining an actively supported mod in the Kopernicus thread and you know what: I gave up that plan for reasons. 

So may I ask you to recompile BBT containing that fix against 1.7.3?

Kind regards and thanks in advance

PatSch

Edited January 24, 2020 by ThePatsch78