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

[Snark]

12 minutes ago, Murdabenne said:

My 2 cents worth - please don't take it as me telling anyone what to do, but accept it as an answer I found handy and am putting out here for you to see as an alternative.

I appreciate that you're trying to be helpful.  However, see my earlier post on the topic re: not budging.  Also re:  my assurances.  Also re:  done with this topic and moving on.  Thank you for your understanding.  Next topic?

[Murdabenne]

24 minutes ago, Snark said:

I appreciate that you're trying to be helpful.  However, see my earlier post on the topic re: not budging.  Also re:  my assurances.  Also re:  done with this topic and moving on.  Thank you for your understanding.  Next topic?

Next topic? OK:  Thanks for updating this!  I find it useful and it allows me to have more fun in a more precise manner :-) 

[richfiles]

2 hours ago, Snark said:

Okay, that sounds pretty reasonable, I expect I can slip that in to an update.

Basically, I've got a set of numbers to expose, along with a boolean "is / isn't valid" flag-- e.g. "time to impact" is only valid if I actually have a time to impact, and so forth.  Perhaps I could just pick a convention that any one that's not applicable will have a value of NaN.  Makes things simple.

**Unholy girly noises emanating from a dude** 
SO MUCH thanks! I look forward to it, and yes, I absolutely will share pics (vids) when I get to the point I can build it and actually make it work.

[fourfa]

Does BBT update it's "est. burn" if you throttle down?  I'm trying to fly an Apollo-style Mun landing with a single continuous burn with varying throttle, and it seems to stay fixed on the full-throttle estimate.

[DStaal]

14 minutes ago, fourfa said:

Does BBT update it's "est. burn" if you throttle down?  I'm trying to fly an Apollo-style Mun landing with a single continuous burn with varying throttle, and it seems to stay fixed on the full-throttle estimate.

If I understand correctly, it will update the amount of burn you need - but it always assumes a full throttle burn.  It's hard for the code to guess what the human at the keyboard will do with the throttle, after all.  (And in the simple case of 'we aren't burning yet, when do we need to start?', it knows you'll change the throttle.)  So it assumes a full-throttle burn.  If you're doing something else, assume you'll need to burn longer.

[Blackline]

With all the currently ongoing space x Booster return to launch missions: is atmosphere support planned for bbt?

[Snark]

14 hours ago, fourfa said:

Does BBT update it's "est. burn" if you throttle down?  I'm trying to fly an Apollo-style Mun landing with a single continuous burn with varying throttle, and it seems to stay fixed on the full-throttle estimate.

No.  It entirely bases its estimate on the premise that you'll be full-throttle.  This is by design, and won't change, ever.

I can see how that might be handy, but the problem there is that doing such a thing would essentially be asking the mod to predict what you're going to do in the future ("I plan on leaving the throttle the way it is"), which it can't do.  So instead of trying to predict what you will do (which it can't), it just predicts what you can do (which it can)-- i.e. assume full throttle.

Trying to do something like that would result in all sorts of weird problems.  It means that "N/A" would come back if you're not burning, or if your current burn level is less than local gravity.  ("How long will it take me at my current throttle setting?  Infinity!")  It would mean that the number would bounce wildly up and down any time you touched your throttle.

That doesn't necessarily mean it's useless when coming down under partial throttle. As you descend to the surface, you can see two numbers:  time to impact, and estimated burn time.  Time to impact gradually increases or decreases at varying rates as you thrust.  Time to burn also gradually counts down, as you thrust.  By increasing or decreasing throttle, you can make one or the other of these count down faster than the other, so as long as they both reach zero at about the same time, you're good.

Anyway, that's as good as it's gonna get. 

14 hours ago, DStaal said:

If I understand correctly, it will update the amount of burn you need - but it always assumes a full throttle burn.  It's hard for the code to guess what the human at the keyboard will do with the throttle, after all.  (And in the simple case of 'we aren't burning yet, when do we need to start?', it knows you'll change the throttle.)  So it assumes a full-throttle burn.  If you're doing something else, assume you'll need to burn longer.

^ Yes, this, exactly.

3 hours ago, Blackline said:

With all the currently ongoing space x Booster return to launch missions: is atmosphere support planned for bbt?

I'd like to do something, eventually, but it's a tricky problem and would take a lot of work, so it's likely to be a while.

The two main scenarios where this may be handy:

• A "ballistic" landing, where the air doesn't make a huge amount of difference and the principle is pretty close to a vacuum landing.  Example:  SpaceX style booster landing.  Landing on Duna without parachutes.
• A "drag" landing, where you're descending on parachutes or something and want to time your retro-thrust to cushion the landing (a lot of Duna landings are like this).

The reason it's hard is that aero forces fluctuate a lot (e.g. just descending under a parachute), the aero force that the game reports bounces up and down a lot.  I actually originally set out to have BBT handle aero from the start, and implemented it... but the numbers were so fluctuating and crappy that it was a case of "feature that works badly is worse than no feature at all", so I yanked it until such time as I could figure out how to make it work well enough to be useful (e.g. do a sliding-window time average of aero force, or something).

[Snark]

Hi folks,

I've released v1.5.1 of BetterBurnTime.  Changes in this version:

• Fixes a bug that caused BBT to spam NullReferenceExceptions to the log when impact-tracking if there's a kerbal in a command chair.  (Thanks to @brusura for pointing this out, sorry it took so long to get around to fixing it.)
• Adds a new API class to export the data that BetterBurnTime calculates in a way that other mods can have access to it.  (Thanks to @richfiles for requesting, and @stibbons for clarifying.)

The new data-access class is called, perhaps unimaginatively, BetterBurnTimeData.  It exposes the following bits of information:

• What "mode" is it currently in?  i.e. info about what?  One of:  Maneuver, Impact, Rendezvous, None.
• Burn time.
• dV needed.
• Time until event (maneuver node, impact, or closest approach).
• A boolean warning flag indicating "insufficient fuel" or not.

Mods wishing to use this class can take either a "hard" or a "soft" dependency.

A "hard" dependency is where the 3rd-party mod has an actual assembly reference to BetterBurnTime.dll (such that the other mod won't even load unless BBT is present).  Such mods can access this class via the static property BetterBurnTimeData.Current, and then programmatically access the fields directly.

A "soft" dependency is where the 3rd-party mod treats BBT as an optional requirement, and detects it at run-time.  The code for such mods isn't quite as simple as the hard-dependency case, but it's still pretty straightforward.  I've included a sample code file, BetterBurnTimeDataExample.cs, in the github repository for the mod.  You're welcome to use that as a starting point, if you like.  It demonstrates how to get data out of BBT as a "soft dependency" via BetterBurnTimeData.  (The example simply pulls the data every two seconds and writes the data to the log file.)

Enjoy!

[stibbons]

38 minutes ago, Snark said:

l've included a sample code file, BetterBurnTimeDataExample.cs, in the github repository for the mod.

Love your work.

(and I've started using this mod since we talked about it, looking forward to pulling some of this data in to my own displays some time soon as well) 

Edited October 19, 2016 by stibbons

[richfiles]

I've not gotten back into playing, with the release of 1.2 (or 1.1, LOL  ), but that's only because I want to finish my controller and dive head first into gameplay with it. BBT will definitely be a permanent fixture for my mod list though!

Edited October 19, 2016 by richfiles

[monstah]

8 hours ago, richfiles said:

I've not gotten back into playing, with the release of 1.2 

I hadn't played for quite some time (1.1 in particular was a buzzkill to me), but I'm having a great time on 1.2!

I share the feeling, tho, I started a simple controller some months ago, and abandoned it. I was using telemachus + python, but I think I'll switch to KRPC instead.

Aaaaand this thread is about neither. Sorry for my digression...

Anyway, the latest update doesn't affect me much yet, but this mod is gold  

[brusura]

spacedock seems to be still down following the ddos attack maybe, could you please add a backup download link?

[Rafael acevedo]

Thanks for a great Mod.   I will like to give you kudos as it is one of those mods that had taught me how to fly more accurately in the stock game, something that only a few mods do.

[StahnAileron]

On ‎10‎/‎15‎/‎2016 at 11:41 AM, Snark said:

I'd like to do something, eventually, but it's a tricky problem and would take a lot of work, so it's likely to be a while.

The two main scenarios where this may be handy:

• A "ballistic" landing, where the air doesn't make a huge amount of difference and the principle is pretty close to a vacuum landing.  Example:  SpaceX style booster landing.  Landing on Duna without parachutes.
• A "drag" landing, where you're descending on parachutes or something and want to time your retro-thrust to cushion the landing (a lot of Duna landings are like this).

The reason it's hard is that aero forces fluctuate a lot (e.g. just descending under a parachute), the aero force that the game reports bounces up and down a lot.  I actually originally set out to have BBT handle aero from the start, and implemented it... but the numbers were so fluctuating and crappy that it was a case of "feature that works badly is worse than no feature at all", so I yanked it until such time as I could figure out how to make it work well enough to be useful (e.g. do a sliding-window time average of aero force, or something).

I'm not pushing for this (landing manually isn't something I attempt often, anyway), but could you latch into something like the Trajectories mod to help with atmospheric calculations for time to impact? (Or use come of the code?)

Though I don't know if it would be worth the trouble since even trajectories doesn't take into account AoA on the fly (AoA predictions is done via slider presets.) By default I think it uses an AoA of zero (always prograde, though I don't recall whether that's atmo or orbital prograde... Yeah, complex, huh?) Still, if you plan on continuing, I figure the math for atmo effect predictions you'd need are sorta served by Trajectories.

[Farix]

1 hour ago, brusura said:

spacedock seems to be still down following the ddos attack maybe, could you please add a backup download link?

It's always a good idea to have multiple ways to download a mod, least we have another KerbalStuff. I also know that some of us prefer not to use or support SpaceDock. Since there is a GitHub repository for the source code and they have more robust servers to begin with, why not add releases there as well?

Edited October 22, 2016 by Farix

[fourfa]

Potential feature request to consider?  I've been building tiny probes for comm network lately, with only monoprop and a Place Anywhere thruster for propulsion.   Very few mods support RCS-only ships (RCS Build Aid does a give dV readout in VAB), but most frustrating of all is having to save, do the burn slowly to completion to find out how long it will take, reload, do the math then finally trigger the burn.  Don't know if this is within the scope of the mod or not.  Thanks!

[Snark]

On 10/22/2016 at 7:06 AM, Farix said:

Since there is a GitHub repository for the source code and they have more robust servers to begin with, why not add releases there as well?

Gosh, that's a great idea.  I wonder, why didn't I think of that? 

I generally prefer that people download from SpaceDock rather than github, if possible, which is why I don't go out of my way to publicize the github download.  (It's not hidden or anything-- it's right there, a top-level folder clearly labeled "release" in the github repository, which is directly linked from this thread's OP.)  The reason why, as a mod author, I prefer that folks use SpaceDock where possible:  it provides really nice feedback (see the "stats" graph) that lets me see how many people are downloading, which is nice to know (helps me gauge demand).  github, by contrast, has no such visibility at all-- I can't tell whether the number of downloads is zero or a million.

 

On 10/22/2016 at 6:58 AM, StahnAileron said:

I'm not pushing for this (landing manually isn't something I attempt often, anyway), but could you latch into something like the Trajectories mod to help with atmospheric calculations for time to impact? (Or use come of the code?)

Though I don't know if it would be worth the trouble since even trajectories doesn't take into account AoA on the fly (AoA predictions is done via slider presets.) By default I think it uses an AoA of zero (always prograde, though I don't recall whether that's atmo or orbital prograde... Yeah, complex, huh?) Still, if you plan on continuing, I figure the math for atmo effect predictions you'd need are sorta served by Trajectories.

No, am not going to directly tie into Trajectories (or any other mod).  My mods are generally standalone, with minimal dependencies, and I prefer to keep them that way, for various reasons which for the sake of brevity I won't go into here.

Also, BetterBurnTime isn't a navigational aid.  It's a "can I burn" and "how long do I burn" tool.  That's it.  Doing what Trajectories does is a lot more complex, and I would never, ever, under any circumstances even dream of trying to give you any information about getting down to the surface from orbit.  If-and-when I do ever add atmospheric functionality to BetterBurnTime, it'll be focused on that crucial last minute-or-two before impact landing.

In short:  there's very little overlap between what Trajectories does and what BetterBurnTime may someday do.  Trajectories is primarily concerned with "from orbit until almost-at-the-surface"; BBT is concerned with "from almost-at-the-surface until touchdown."  So not a lot of help there.

 

On 10/22/2016 at 10:23 AM, fourfa said:

Potential feature request to consider?  I've been building tiny probes for comm network lately, with only monoprop and a Place Anywhere thruster for propulsion.   Very few mods support RCS-only ships (RCS Build Aid does a give dV readout in VAB), but most frustrating of all is having to save, do the burn slowly to completion to find out how long it will take, reload, do the math then finally trigger the burn.  Don't know if this is within the scope of the mod or not.  Thanks!

Yup, that's not supported in BetterBurnTime, and it's pretty much in the "ain't gonna happen" category-- sorry.  It's not a bad idea, and thank you for proposing it; but there are a couple of good reasons why BBT does't support RCS:

First, it would be a large and complicated chunk of code.  There's a lot of complexity there, would have to deduce the placement of RCS thrusters, look at their multi-nozzle configuration, deduce which amounts which nozzles of each thruster is going to fire when they're not lined up perfectly (which requires reverse-engineering Squad's algorithms), etc.  Given how big and complex it would be, I'm loath to take on such a large project for the under-1% use case that people actually want to do this.

(I'm also kind of curious what's your reason for doing this-- I'm having trouble coming up with a monoprop-tank-and-linear-thruster-port scenario that wouldn't be better served by an Oscar + Ant.)

Second,  it would make matters worse for 99% use case of folks who don't use RCS as part of their burn.  If BBT were set up to "assume that RCS will be used, if available", then the burn times posted would be off, because they'd be assuming that people are using their RCS, too, which is generally not the case.

So, that particular feature's probably not on the table.

[fourfa]

Makes sense, thanks for the explanation

[StahnAileron]

8 hours ago, Snark said:

No, am not going to directly tie into Trajectories (or any other mod).  My mods are generally standalone, with minimal dependencies, and I prefer to keep them that way, for various reasons which for the sake of brevity I won't go into here.

Also, BetterBurnTime isn't a navigational aid.  It's a "can I burn" and "how long do I burn" tool.  That's it.  Doing what Trajectories does is a lot more complex, and I would never, ever, under any circumstances even dream of trying to give you any information about getting down to the surface from orbit.  If-and-when I do ever add atmospheric functionality to BetterBurnTime, it'll be focused on that crucial last minute-or-two before impact landing.

In short:  there's very little overlap between what Trajectories does and what BetterBurnTime may someday do.  Trajectories is primarily concerned with "from orbit until almost-at-the-surface"; BBT is concerned with "from almost-at-the-surface until touchdown."  So not a lot of help there.

I wasn't implying that at all. I meant just using Trajectories' atmo math to help calculate that last minute (suicide) burn for landing on atmospheric bodies like it tries to do on vacuum bodies. I recall someone asked for that capability and you stating atmo effects complicating the matter. I figure something like Trajectories, which does the atmo calculations, could help. I wasn't talking along the lines of making a combination Trajectories/BBT-style mod (at least in terms of what a user sees). Wouldn't Trajectories' math help you figure out WHEN that last 1-2 minutes prior to impact landing starts in an atmosphere? (<<< This is my main point if I wasn't clear enough before...)

Sidenote: Actually... I think the Landertron Mod has some "when do I burn?" code to activate its retro rockets at the right moment. Dunno if it'd help you.

[Mechtech]

cross-posting from the Kopernicus thread- Better Burn Time's current version isn't playing nice with the latest Kopernicus build, causing infinite-black-loading-screen on loading a save. if what I'm seeing in the kopernicus logs is correct, something about how Better Burn Time gets planet data for its calcs is bollexing the kopernicus system generator. enclosed are both a Koperincus log file (I picked Kerbin, it seemed like the thing to do) and the KSP.log from a glitched startup.

Linky

this is the actual error, along with the line directly above BTW:

[LOG 15:46:55]: Parsing Target barycenter in (Kopernicus.Configuration.Body) as (Kopernicus.NumericParser`1[System.Boolean])
[LOG 15:46:55]: Exception Was Recorded: Could not load type 'System.Runtime.CompilerServices.ExtensionAttribute' from assembly 'BetterBurnTime'.
  at (wrapper managed-to-native) System.MonoCustomAttrs:GetCustomAttributesInternal (System.Reflection.ICustomAttributeProvider,System.Type,bool)
  at System.MonoCustomAttrs.GetCustomAttributesBase (ICustomAttributeProvider obj, System.Type attributeType) [0x00000] in <filename unknown>:0 
  at System.MonoCustomAttrs.GetCustomAttributes (ICustomAttributeProvider obj, System.Type attributeType, Boolean inherit) [0x00000] in <filename unknown>:0 
  at System.MonoType.GetCustomAttributes (System.Type attributeType, Boolean inherit) [0x00000] in <filename unknown>:0 
  at Kopernicus.Parser.LoadExternalParserTargets (.ConfigNode node, System.String modName, Boolean getChilds) [0x00000] in <filename unknown>:0 
  at Kopernicus.Configuration.Body.Kopernicus.IParserEventSubscriber.PostApply (.ConfigNode node) [0x00000] in <filename unknown>:0 
  at Kopernicus.Parser.LoadObjectFromConfigurationNode (System.Object o, .ConfigNode node, System.String modName, Boolean getChilds) [0x00000] in <filename unknown>:0 
  at Kopernicus.Configuration.Loader.Kopernicus.IParserEventSubscriber.PostApply (.ConfigNode node) [0x00000] in <filename unknown>:0 

hope that helps.

[Snark]

20 hours ago, Mechtech said:

cross-posting from the Kopernicus thread- Better Burn Time's current version isn't playing nice with the latest Kopernicus build, causing infinite-black-loading-screen on loading a save.

Yup.  That's a Kopernicus bug that has nothing to do with BetterBurnTime at all; basically, Kopernicus is iterating through all installed mods, and barfing when it comes to the first one that happens not to <do some esoteric thing that Kopernicus is erroneously expecting>.  The fact that it's stubbing its toe on BetterBurnTime probably has more to do with the mod starting with a "B" and being one of the first ones encountered, than anything specific about BBT.  Folks have encountered the same problem with other mods, too.

The good news is that Thomas P. has already released a Kopernicus hotfix that addresses the issue, so it's all good now. 

Anyway, thanks for the quick diligence, even though it turned out that the culprit wasn't BBT!

[DMagic]

@Snark I sympathize about GitHub's terrible release stats, but the info is available. You get either get directly from the GitHub API (search for download_count), or download a browser extension to show the data. Of course, you have to make a GitHub release for that to work, I'm not sure the info is available for just downloading files directly from the repo.

[Snark]

2 minutes ago, DMagic said:

@Snark I sympathize about GitHub's terrible release stats, but the info is available. You get either get directly from the GitHub API (search for download_count), or download a browser extension to show the data. Of course, you have to make a GitHub release for that to work, I'm not sure the info is available for just downloading files directly from the repo.

Yup, can't be bothered.  Plus, it's not just the total count... SpaceDock actually gives me a graph of downloads-per-day, by version, which is super important.

SpaceDock's simply far more convenient for me as a mod author, which is why I do it that way.

[Snark]

Hi all,

I've released v1.5.2 of BetterBurnTime. This is a very minor update with no new features, just a couple of small bug fixes:

• Fix a bug that spams an error message "Parent of RectTransform is being set with parent property." when the mod starts up. (Thanks to @DMagic for catching!)
• Fix NRE that happens sometimes when switching to a vessel that already has a maneuver node set.

Enjoy!

[EDIT] BROKEN VERSION, DO NOT USE.  Hilarity will ensue (see justifiably confused posts from users below).

Edited December 15, 2016 by Snark
sigh.

[MK3424]

Anyone else having this graphical bug? (navball) It only shows up when you're close to a target...