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

[Snark]

5 hours ago, HebaruSan said:

Just curious, how does that misfeature cause problems for BBT?

...simmering rage... must... control... fist... of... death...

Sorry, that's a perfectly reasonable question and it's not your fault that I'm still bitter about it.

Enraged technobabble rant inserted in spoiler section.  Warning: incoming wall of text.  Recommend handling with tongs and an asbestos apron.

Spoiler

5 hours ago, HebaruSan said:

If I recall previous posts, you're checking for null and then using functions or properties on the object, as per normal practice, and the null check is failing to protect you from null reference errors.

Correct.

5 hours ago, HebaruSan said:

But that means their overloaded operator must be returning false in some cases where the system operator would be returning true, right? ... How does their wrapper object create the possibility to return false when the reference is actually null?

No.  It's the exact other way around.  Their overloaded operator is returning true ("this is null") when it actually isn't null.

The insanely evil, horribly wrong-headed, indefensibly idiotic decision that's as dumb as a bag of hammers is this one:

5 hours ago, HebaruSan said:

true when that operator is false but their object's internal state is destroyed

^ This.  This pestilent little *&#*@er right there.  This is the source of misery.

Why is it misery?  Because in a sane world, if I check that "x == null" is false, it should always be false forever and ever until and unless I tell it to set x = null sometime.  But they've now created a world in which I check "x == null" and it's false now, but true later, which no programmer would ever expect.

TL;DR:  EVERY PROGRAMMER IN THE HISTORY OF THE UNIVERSE ASSUMES THAT "x == null" IS A CONSTANT.  Don't change that invariant unless you hate programmers and want to make them cry.

I'll take an extended example to show just how asinine that design "feature" of Unity is:

Let's say I'm designing a Foo object, and it happens to have the behavior that sometimes it's in a good, usable state, and other times it's in a bad, unusable state, and if you try to do something with it when it's in the bad state, it will blow up by throwing an exception.  How do I model this?

Well, a simple and obvious way to do this, assuming that I'm not either evil or certifiably insane, would be to do something like this:

class Foo {
    public bool IsUsable { get; }
    public void DoSomething() throws ImNotUsableException; // don't call if not IsUsable!
}

Easy, right?  It makes client code that uses a Foo nice and simple.  I can do something like this:

Foo myFoo = GetAFooFromSomewhere();
if (myFoo == null) { HandleError(); return; } // because that would be bad
// ...later...
if (myFoo.IsUsable) myFoo.DoSomething();

Nice and simple.  I just make sure, everywhere in my code, that I always check the IsUsable property before I call DoSomething().

Note also how easy it is for someone to program against this.  Let's suppose they don't know anything about Foo semantics, they don't know how GetAFooFromSomewhere() works, they don't know how Foo objects behave.  It's still really easy to figure out how to write the above code.  "Well, I don't know how GetAFooFromSomewhere works or whether it might return null, so I'll check that, just in case.  OK, not null. Now how do I use a Foo?  Let's list the methods.  Oh look, it has an IsUsable method.  I wonder how that works?  <brief pause to google it>  Oh, okay, it's part of the contract that I need to call that each time before I call DoSomething, or it'll throw."

Easy-peasy.  The code writes itself.

Now let's suppose that you're a nasty evil person who wants to wreak misery upon this wretched world.  So you decide not to design Foo that way, because it would be too easy and people would be able to figure out how to use it, and obviously we can't have that.  So instead you design Foo like this:

class Foo {
    public void DoSomething();
}

...But wait, I hear you cry.  Where's the "is usable" state?  I guess it means it's always usable, right?

Wrong!  HA!  Gotcha!  You've fallen into my clever trap.  <brief pause for evil chuckle>  No, there's still this "usability" state, but now it's a private hidden thing.  Instead, we've overridden operator==.  So that whenever the object is in its unusable state, "== null" will return true (even though the object is not actually null), and if you try to call DoSomething while it's in that state, you get a NullReferenceException.

So here's your hapless programmer trying to use the festering pile of unadulterated bug dung that is your maleficent API:

Foo myFoo = GetAFooFromSomewhere();
if (myFoo == null) { HandleError(); return; } // because that would be bad
// ...later...
myFoo.DoSomething(); // this throws NullReferenceException

...at which point the victim programmer is thinking "what the hell?  How can that be?  I already checked myFoo to make it be null, how can it be null now?"

The answer, of course, being that:

• myFoo is not actually null
• You think it's null because the API has carefully been designed to lie to you and tell you that myFoo is null, when it isn't
• More to the point, when you earlier checked to make sure it wasn't null, the API was implicitly lying to you by letting you believe that you had checked an invariant and were therefore safe

What they want you to do is to have to say this everywhere:

if (myFoo != null) myFoo.DoSomething();

...every time you use it, even if you already checked whether myFoo was null, because it can change from supposedly "not being null" to supposedly "being null" when you haven't assigned it or done anything.

Moral of the story:

1. In general, don't ever overload operator== unless you have a really good reason to do so, because people don't expect it and it will flummox them.
2. There are very, very few good reasons.  If you think you have a good reason, you're probably wrong.
3. What Unity did here was not a really good reason.  It was, in fact, a horrible, rage-inducing reason.

Okay rant done.

In any case, since none of this has anything to do with BetterBurnTime per se, I'd suggest taking the discussion to the plug-in development forum (for example, the "why am I getting NullReferenceException?" thread that I linked to above).  I'd kinda like to keep this thread for discussing BetterBurnTime itself, if possible. 

[HebaruSan]

23 minutes ago, Snark said:

(for example, the "why am I getting NullReferenceException?" thread that I linked to above).  I'd kinda like to keep this thread for discussing BetterBurnTime itself, if possible. 

That one seems to be in the locked-down 1.1 forum, but fair enough. I may take a follow-up question or two to a PM if I remember.

[Snark]

Hi all,

I've released v1.4.2 of BetterBurnTime.  This is a minor update that addresses a couple of items:

• The countdown indicator now has customizable intervals for "hiding the dots."  See the documentation on the SpaceDock page for details; skip to the very end of the page, the new setting is called CountdownTimes.  Thanks to @Gen. Jack D. Ripper for this excellent suggestion!
• A fix to eliminate those pesky NullReferenceExceptions that were cropping up from time to time.

Enjoy!

[Superfluous J]

Most people probably don't do this (I rarely do myself) but BetterBunTime doesn't seem to recognize SRBs as engines, and predicts a burn time of n/a when you've set up a node with them.

Great mod, BTW. I consider it a must-have.

[Snark]

3 hours ago, 5thHorseman said:

Most people probably don't do this (I rarely do myself) but BetterBunTime doesn't seem to recognize SRBs as engines, and predicts a burn time of n/a when you've set up a node with them.

Great mod, BTW. I consider it a must-have.

I can see how this would seem a bit odd to a user, but it's actually by design.

BetterBurnTime bases its calculations on active engines only.  If I've got a Mainsail and a Terrier, and the Terrier is active but the Mainsail isn't, then the burn time will be based on the Terrier only.  (This is why the main post for the mod calls out the caveat that it doesn't take staging into account.)

So if you think about it a little, you'll see why this is problematic with SRBs.    If you haven't fired them yet... they're not active engines.  Therefore, as far as BetterBurnTime is concerned, they don't exist.  It deliberately ignores them completely.  BetterBurnTime has no way of knowing when and if you are planning to activate those SRBs in the future (for example, it doesn't know that you're planning on using them in your upcoming burn), so it therefore doesn't include them in its calculations.

The moment you trigger the SRBs, then it will tell you the expected burn time.  Yes, I realize that's too late to be useful to you, but it's all the mod can do-- it only calculates based on current state, and doesn't try to guess future intentions.

[Superfluous J]

13 minutes ago, Snark said:

it's actually by design.

Aha, I see. That does make sense. And as I said it's an edge case. Early career with cheap probes, I sometimes use an SRB to circularize to save cash on the lifter but other than that SRBs aren't exactly made for that

[meyerweb]

A question for you, @Snark: can you detail a little bit more how the `CountdownText` and `CountdownTimes` values interact?  For example:

    <string name="CountdownText">● ● ● • • • • · · · · ·</string>
    <string name="CountdownTimes">1, 2, 3, 5, 10, 15</string>

I count 12 symbols in the text value, but only 6 numbers for times.  How do they go together?

Also, suppose I wanted to have the big dots count down from 5 to 1, the middle dots from 24 to 6 by threes, and the small dots from 60 to 25 by fives.  How would I set that up?

[Snark]

9 minutes ago, meyerweb said:

A question for you, @Snark: can you detail a little bit more how the `CountdownText` and `CountdownTimes` values interact?  For example:

    <string name="CountdownText">● ● ● • • • • · · · · ·</string>
    <string name="CountdownTimes">1, 2, 3, 5, 10, 15</string>

I count 12 symbols in the text value, but only 6 numbers for times.  How do they go together?

The program internally needs there to be as many times as there are dots in the text.  Twelve dots, so it needs twelve times.

If the number of times actually supplied in CountdownTimes is less than that, then the program will "fill in" more times by doubling each one after that.  Thus, in the above example, the program will "fill in" the missing times as 30, 60, 120, 240, 480, 960.

So let's consider your example:

25 minutes ago, meyerweb said:

Also, suppose I wanted to have the big dots count down from 5 to 1, the middle dots from 24 to 6 by threes, and the small dots from 60 to 25 by fives.  How would I set that up?

To get the countdown times that you want, you'd do this:

<string name="CountdownTimes">1, 2, 3, 4, 5, 6, 9, 12, 15, 18, 21, 24, 25, 30, 35, 40, 45, 50, 55, 60</string>

There's a bit of a "hiccup" at 24-25, since there's only a one-second gap there, but that's how you specified it above. 

Okay, now that you've specified CountdownTimes thus, you need to support it with an appropriate CountdownText.  Again, following your specification, it would look like this:

<string name="CountdownText">● ● ● ● ● • • • • • • • · · · · · · · ·</string>

Does that make sense?

[meyerweb]

Perfectly clear, @Snark!  (Not that I would expect otherwise from you.)  Many, many thanks.  I foresee Unicode hackery in my future.

[sidfu]

found something new. seems that it has issues with real fuels. if the fuel is unstable on engine it givves a n/a but the isssue i had is even after getting the fuel stable to fire the engine it stayed n/a and also the countdown dots never moved. there was no error in log so u know

[Trann]

Very cool and immersive mod!  Subscribed!

 

Silly suggestion: build *up* countdown dots (to a max of 10-30, or until the burn starts/there's a change in delta-V/fuel) when you miss your burn.  

[Superfluous J]

I just experienced for the first time how awesome the rendezvous timer was. Well done.

I don't know if this is doable, but in my mind this could also be used as a docking timer, if you allowed it to go down to the meter (and likely decimeter) and kept it up when it would normally go away. I don't know if it would cause any problems or be too inaccurate and jumpy (as math fights physics when you turn ships and fire RCS) but it'd be pretty convenient.

Edited May 8, 2016 by 5thHorseman

[Snark]

6 hours ago, 5thHorseman said:

I don't know if this is doable, but in my mind this could also be used as a docking timer, if you allowed it to go down to the meter (and likely decimeter) and kept it up when it would normally go away. I don't know if it would cause any problems or be too inaccurate and jumpy (as math fights physics when you turn ships and fire RCS) but it'd be pretty convenient.

It probably would work pretty well, actually.  Wouldn't be all that complex to code, either, I think.

The devil's in the details, though, and as is so often the case with a simple-sounding idea, there are a lot of UX issues to iron out:

• When to show it.  This is an issue because the mod has no way of knowing that you intend to dock, and showing this info when you're not actually going to dock would be really annoying and distracting.
  • Only if you have a docking port targeted?
  • Or when you have any ship targeted that has a docking port on it?
  • Only if your control-from point is a docking port?  Or don't care?
• What information to show.
  • Unlike rendezvous or landing, where a user only cares about one number (basically, "how far am I" in distance or time), docking is much more complex.
  • User cares about distance, and lateral error, and direction of lateral error,and two crafts' orientation,
  • Trying to show all of that with text would be information overload. But picking out just one bit of info has the risk of being misleading (e.g. saying "you're five seconds from docking" when your orientation is completely wrong)
• The right tool for the right job.
  • Goodness knows that KSP could certainly use a docking aid.
  • However, docking is much better suited (IMHO) to a graphical tool rather than a text display.
  • There are already good mods out there for lining up docking... I think they do a much better job than BBT could.  BBT's a neat mod, if I do say so myself ... but I don't think it's really the best tool for this particular job.

Put all that together, and I'm not super inclined to add this feature, at least not any time soon.

If I had to guess what's the next significant enhancement that I'd add to BetterBurnTime, I'd guess it might be a more-accurate time-to-impact indicator that actually projects trajectory rather than just using the elevation directly under the ship at the moment.  That might be a while, though-- I haven't gone through to work out how complex and/or computation-intensive it would be, and I've got some other irons in the fire that I'm actively working on at the moment.

The other thing I'd love to do is to make BetterBurnTime a little more friendly to planets with atmospheres.  For example, would love to have an impact estimation (even a very rough one) for landing on Duna.  That's another thing I'd have to spend some time thinking through, though-- the vagaries of atmospheric interaction do tend to cause inaccurate/jumpy problems.

[Superfluous J]

2 hours ago, Snark said:

The devil's in the details, though

It always is

Some context: I was using this last night and I use NavHud, which shows me the alignment and direction to target, and of course the game shows distance. Mostly all I wanted was "distance at intercept" and "time to intercept". They're not always just a simple equation of distance/speed, especially if you're a good distance apart. I don't think it'd be distracting to just leave up what's already there for rendezvous, but change the text to read in meters if you're under 0.1km. I don't know the exact considerations you look for to display rendezvous information but I imagine you have upper and lower bounds for things, and simply removing one of those bounds could be all that's necessary.

Whichever way you go, thanks for considering my idea.

[Superfluous J]

A viewer suggested I post my personal tweak to the display on BetterBurnTime, so here goes:

    <string name="CountdownText">1 2 3 4 5 ● ● ● • • · ·</string>
    <string name="CountdownTimes">1, 2, 3, 4, 5, 7, 10, 15</string>

The big change is that the last 5 seconds are actually numbers instead of dots. For some reason that works far better for me when watching the countdown.

[Gordon Dry]

A suggestion for better compatibility with MechJeb2:

 

[Gordon Dry]

Could this mod "remember" the stats of the last burn as long as the same engine(s) are active (not staged away) and the last used tank(s) still got fuel (no matter if stable or not) to show the estimated burn whatsoever?

This is because often it's just better (and MJ does exactly so) not to start burning at T - 0 but that the node is in the middle of the burn.

When I know how long the burn needs to be I can say from what time on the fuel has to be stable and just RCS forward to make it so.

For example, the burn time is (will be when shown) 2min 30s so I can assume MJ will fire up the engine(s) at T - 1m 15s, so I start RCS forward at T - 1m 25s to get the fuel stable prior to firing up.

Is it also possible to get the information from MJ when it wants to start burning to just help out in ullage-dependant situations? (either recognize if ullage is a subject at all or do it right away).
So either add a second countdown shown in brackets behind the "Node in T - Xm, Ss" that points to when the burn begins
and/or
Start manual RCS forward for 12s at 10s before the burn begins.

------

This post

suggests a "RCS ullage burn function" - exactly what's needed.

I tried to fiddle around with small radial attachable engines that are no subject to ullage themselves, have no or a high ignition limit and can be run by "conventional" fuel (like LqdHydrogen/LqdOxygen  ) and I found this one in my part list:
SpaceY "Dibamus" RCS/OMS Thrust Block

Okay, it's RCS and also staged as engines, but uses stock MonoPropellant and if staged together with the ullage-problematic engine(s) it eats up MonoPropellant all the time - a no go.

[Alshain]

On 5/2/2016 at 1:51 PM, Snark said:

The program internally needs there to be as many times as there are dots in the text.  Twelve dots, so it needs twelve times.

If the number of times actually supplied in CountdownTimes is less than that, then the program will "fill in" more times by doubling each one after that.  Thus, in the above example, the program will "fill in" the missing times as 30, 60, 120, 240, 480, 960.

So let's consider your example:

To get the countdown times that you want, you'd do this:

<string name="CountdownTimes">1, 2, 3, 4, 5, 6, 9, 12, 15, 18, 21, 24, 25, 30, 35, 40, 45, 50, 55, 60</string>

There's a bit of a "hiccup" at 24-25, since there's only a one-second gap there, but that's how you specified it above. 

Okay, now that you've specified CountdownTimes thus, you need to support it with an appropriate CountdownText.  Again, following your specification, it would look like this:

<string name="CountdownText">● ● ● ● ● • • • • • • • · · · · · · · ·</string>

Does that make sense?

Is there not  way to tell you the flat time to burn, like Kerbal Engineer does (like a half burn time)?  I love the way this tucks away neatly next to the NavBall, I was hoping to be able to shorten my Engineer HUD list a bit.

Edited May 19, 2016 by Alshain

[Snark]

2 hours ago, Gordon Dry said:

Could this mod "remember" the stats of the last burn as long as the same engine(s) are active (not staged away) and the last used tank(s) still got fuel (no matter if stable or not) to show the estimated burn whatsoever?

<long and helpfully specific explanation>

Short answer is "no, and it's not going to, because <long list of reasons>."  But if all you want is "some kind of indication that it's 10 seconds before you start the burn," then BetterBurnTime actually already has that. 

First, a bit of background, to explain to any readers who don't understand what you're talking about.  (And also to make sure that I'm correctly understanding what you're asking for and why.  I think I do, but I could be wrong.)

Spoiler

I assume you're running some "realism" mod (or combination of mods), such as Realism Overhaul, Real Fuels, or the like.  I don't know which one(s), because I've never run any such mods myself, but I occasionally hang around folks who do and I think I get the general gist.  One of the things you're interested in is ullage, which is a realism thing that happens to rockets in zero-gravity environments.  The concept doesn't exist in stock KSP, but is added via a realism mod.  The basic idea is this:  you have a rocket with a partly-full fuel tank, and it's floating in zero gee, so the interior of the tank is this slushy, foamy, blobby mix of liquid fuel and gaseous bubbles, which doesn't play nice with trying to pump liquid fuel through fuel ducts to an engine at a nice uniform rate.  So when they want to start firing the main engine, they first fire a small "ullage motor" (using RCS or similar) to provide a small amount of "gravity" from acceleration, to "settle" the fuel and make it puddle in the "bottom" of the tank, i.e. separate out the liquid from the gas, so that it's nicely pumpable.

In practical game terms, when you're running a mod that includes this concept, what this means is:  when you want to start your burn, you can't just start the burn.  A little while before you start the real burn, you need to activate your ullage motor to give the fuel some time to settle before you can turn on the main engine.  What you're asking for is the ability to somehow account for that in BetterBurnTime so that it can tell you when to do that.

So:  Am I correctly understanding that what you want is a visual indication that "your burn starts in 10 seconds"?

If that's all you want, it's pretty easy to do.  BetterBurnTime already has a countdown timer for starting the burn.  By default, it looks like this:

...and also by default, it has certain time intervals for those dots.  However, both the text displayed for the dots, and the time intervals for them, are customizable via the config file.  If you look just a few posts above this one, you'll see a question by meyerweb about how to set this up, with a detailed response from me.

So suppose what you really want is not a countdown to when to start the burn, but rather a countdown for when to start your ullage motor, followed by a countdown to the actual burn.  Well, if your ullage burn is always 10 seconds, you can do this by just reconfiguring the countdown timer.

The default config for this normally looks like this:

<string name="CountdownText">● ● ● • • • • · · · · ·</string>
<string name="CountdownTimes">1, 2, 3, 5, 10, 15</string>

To make it be "countdown to ullage, then countdown to burn," you can just change it to something like this:

<string name="CountdownText">● ● ● • | ● ● ● • • • • · · · · ·</string>
<string name="CountdownTimes">1, 2, 3, 5, 10, 11, 12, 13, 15, 20, 25, 40, 70, 130, 250</string>

...the "|" marks the ullage motor.  You'll get a countdown like before, then the last three big dots before the | will be a 3-2-1 countdown, then | to start the ullage motor, then the remaining few dots will countdown the last ten seconds to the actual burn.

Does that get you what you want?

8 minutes ago, Alshain said:

Is there not  way to tell you the flat time to burn, like Kerbal Engineer does (like a half burn time)?  I love the way this tucks away neatly next to the NavBall, I was hoping to be able to shorten my Engineer HUD list a bit.

Want to make sure I correctly understand what you're asking.  Is the idea that what you would like is, a "time until burn start" indicator which just shows seconds (or minutes/seconds, or whatever) as numbers, instead of having a graphic row of dots?

In other words, you'd like to have the option to replace the row-of-dots countdown timer with a numeric timer, such that when it gets to zero is when you start the burn?

If so:  The answer is, no, you can't do that with BBT right now.  However, that's not a bad idea, and actually wouldn't be too hard to add, and you're not the first person to ask about that.  Can you confirm that's what you want?  Maybe it's time for me to do another minor version update. 

 

[Alshain]

9 minutes ago, Snark said:

Want to make sure I correctly understand what you're asking.  Is the idea that what you would like is, a "time until burn start" indicator which just shows seconds (or minutes/seconds, or whatever) as numbers, instead of having a graphic row of dots?

In other words, you'd like to have the option to replace the row-of-dots countdown timer with a numeric timer, such that when it gets to zero is when you start the burn?

If so:  The answer is, no, you can't do that with BBT right now.  However, that's not a bad idea, and actually wouldn't be too hard to add, and you're not the first person to ask about that.  Can you confirm that's what you want?  Maybe it's time for me to do another minor version update. 

 

Precisely, Kerbal engineer already does this (though in testing BBT, I found it appears to be bugged) it's basically a countdown timer to Time to Node - 0.5 * Burn Duration (I think KER is a little more precise than that though, it takes other items into account, like fuel mass reduction during the burn).  I can just keep using KER if it gets fixed, it's just my KER HUD is so long, and I'm always looking for ways to shorten it and make it less distracting and more stock alike ;).  This mod will help me get rid of a few items even with out that.

Edited May 19, 2016 by Alshain

[Snark]

1 minute ago, Alshain said:

Precisely, Kerbal engineer already does this (though in testing BBT, I found it appears to be bugged) it's basically a countdown timer to Time to Node - 0.5 * Burn Duration.  I can just keep using KER if it gets fixed, it's just my KER HUD is so long, and I'm always looking for ways to shorten it and make it less distracting and more stock alike ;).  This mod will help me get rid of a few items even with out that.

OK, you've convinced me.  Makes sense as a user option.  The default will still be the row-of-dots, since that's how I like to play ... but I can add an option to the config file to change it to numeric, perhaps with a format string in case someone wants a more explicit "Start burn in __" indicator or a shorter "B-___" indicator, or the like.

[Alshain]

2 minutes ago, Snark said:

OK, you've convinced me.  Makes sense as a user option.  The default will still be the row-of-dots, since that's how I like to play ... but I can add an option to the config file to change it to numeric, perhaps with a format string in case someone wants a more explicit "Start burn in __" indicator or a shorter "B-___" indicator, or the like.

Nice, I'll keep an eye out, and thank you very much.

[Gordon Dry]

1 hour ago, Snark said:

Does that get you what you want?

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.

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?
And if not, could this be made possible my communicating MJ to BBT internally?

[Snark]

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!

[Superfluous J]

Looks like it'll be

<string name="CountdownText">T -{0}</string>

for me. :)