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

[Snark]

5 hours ago, Errol said:

Thank you for the detailed explanations.

And thank you for the feature request, even if I ended up having to say "no".  One of the things I've learned, since becoming a modder, is that folks use my mods in ways I hadn't anticipated.  There are a lot of features I've added because some user said "gee, I sure wish it could <do thing>"-- and it was a great idea, and it simply hadn't occurred to me, and it was easy to add.  So... to you, and to anyone else using any of my mods:  if you'd like a feature, speak up!  I can't promise I'll add it, but I can promise I'll read it, and if the answer is "no" I'll have a good explanation why. 

2 hours ago, TheRagingIrishman said:

Also, if you don't want aim camera or autostruts, why don't you turn off advanced tweakables?

Off-topic rant that has nothing to do with BBT in spoiler section.

Spoiler

Because I freaking can't, that's why.  It's throwing the baby out with the bathwater.  There are some features that I have to have, and Squad has chosen to put them in the "advanced" bucket.  So either I need to have them turned on, and have all my menus cluttered with useless stuff, or else have them turned off, and have vital functions removed.

In general, I'm really not a fan of the "advanced tweakables" option.  (That's putting it mildly-- I hate it-- but I try to be polite.)  I think it's a terrible way to organize features.

I can sorta-kinda see the motivation ("don't overwhelm newbies with complicated options!") ... but a simple binary switch is simply not good enough.  I don't see the features as "advanced" or "basic"-- they're just, well, a grab bag of features.  Some of them are absolute must-haves for me.  Others are as useless to me as fish bicycles.  And whether they're useful or not has nothing whatsoever to do with being "advanced"; there's zero correlation.    There's no good answer for me, the way the game is currently set up.

There are several ways the game could improve this state of affairs, from my perspective:

• Better option customization.  Don't just give me a binary one-size-fits-all "advanced tweakables" option.  Give me the options of "off", "on", or "custom"-- and when custom is selected, give me a bunch of checkboxes saying which ones I want.
• For the love of Mike, organize the darn PAW.  Don't just take all the buttons and slap 'em up there in no particular order and all look alike with no visual "landmarks" to keep them separate.  Lots of things you could do here.  For example, put it in sections so that logically related groups of controls are next to each other, separated from other groups by horizontal-line separators or something.  Maybe make the sections collapsible with a little +/- button, and the game remembers which sections are collapsed, so that if I don't like the "Silly Useless Controls" section, I can just click the "-" button and it collapses and stays that way for every single PAW on that part type forever (or until I choose to open it again), and it's out of my face.
• Get rid of UI that isn't.  Got a landing leg on your craft?  It has autostrut turned on and locked.  As in, you can't actually change it to anything.  So... if I can't actually adjust the autostrut setting, why the dickens are you polluting my PAW with a button that basically seems to have no purpose other than "neener neener, clicking me does nothing".  Of course, I never use autostrut anyway because I hate the feature, so I'd like all the autostrut buttons gone, personally.  But if there's one that can't actually do anything, good grief.
• Figure out ways to move stuff out of the PAW.  This one really grinds my gears.  The PAW is supposed to be about the part itself.  There should be exactly as many buttons on it as there are functions on the part I can access-- no more.  Don't just use it as a dumping ground for stuff you haven't figured out how to handle better.  For example, in my world, "Aim Camera Here" really doesn't belong there, because it's not about the part-- it's about the camera.  So have some other way in the game UI.  For example, some subtle/small button added to one of the on-screen UIs (maybe the useless docking control UI down at bottom left), so that when you click it, you can then click on whichever part you want to focus the camera on, or something.  Anything to get that darn button out of the PAW where it has no business being.

As you can tell, the whole topic is a really sore one for me, which is why I'm uncharacteristically ranting and spraying spittle in the above diatribe.  Just to be clear:  I'm really not as pompous and self-righteous as I appear in the above paragraphs.  I'm not calling anyone stupid for implementing any of the above features.  And I recognize that other users have very different usage patterns than I do, and there may very well be people out there who love the "aim camera here" button and use it all the time-- never mind that I have never, ever, even once, used it on purpose.  (Plenty of times I've hit the damn thing accidentally.)

So my rage here is not that anybody is "wrong", or that I think everyone should play KSP like I do.  Just that... this aspect of the game is infuriating to me-- not least because it's on every single popup on every single part, forever, which means I get it in my face literally dozens of times even in a fairly short play session.   There's no escape.  (It's not like, for example, the useless "docking UI" at bottom left, because in that case, I can simply train my eyeballs not to see it, and I just ignore it and pretend it's not there.)

I have absolutely no recourse, there's no way to make the game do what I want.  In general, I think the game's done a brilliant job with its interaction model, and this is one of the few "holes" I've seen, which is why it draws my especial wrath.

 

[TheRagingIrishman]

good rant @Snark

[Errol]

This may be out of scope for this mod, but I'm posting here as it branches off if earlier discussion here. 

 

Trying to think of ways work around the limitations of throttle vs minThrust. Does anyone know if it is possible to change the minThrust value of an engine during the game either with something that is in game or a mod? Or if it would be possible to set more then one minThrust? The best would be if you could have the minThrust for the engine be specified by the mm patch, and then have a small plugin set it to zero when the throttle is also set to zero. If this small bit of functionality was available, then BBT might be able to work with my throttle restrictor patch (and there would be no need for the defaultactiongroups patch, as the 'x' key would function to stop your engines again), since as I understand it BBT cares about the thrust limited maxThrust value, not the last actual thrust produced, or the minThrust value (which really just sets the zero point of the throttle on the engine's thrust curve). Also, this would not change the behavior of BBT on existing games and games that do not use my throttle restrictor patch, as all the stock engines have minThrust set to zero anyway (meaning this is their natural state anyway), so changing that value to what it already is should have any adverse affects, right?

EDIT: This does raise the possible extra edge case of "what if a player wants an engine that doesn't shut down at zero throttle for gameplay/balance purposes"....to which I would reply that this hypothetical small plugin could have a flag added to part .cfgs via MM that would cause it to disable itself for those engines.

To be clear, @Snark, the minThrust is seperate from the throttle limiter in the PAW. The minThrust actually changes how the throttle behaves, so an engine with a min thrust other then zero will still have a full range of the throttle slider (0 - 100%), reaching minimum thrust level when the throttle reaches zero. 

Edited June 12, 2017 by Errol

[Snark]

10 hours ago, Errol said:

To be clear, @Snark, the minThrust is seperate from the throttle limiter in the PAW. The minThrust actually changes how the throttle behaves, so an engine with a min thrust other then zero will still have a full range of the throttle slider (0 - 100%), reaching minimum thrust level when the throttle reaches zero.

Yup, I'm aware of it.  I vaguely recall that the issue has come up before, I think it was with regard to Realism Overhaul, which includes engines that have nonzero minimum thrust.  It's been a while now, so memory is a little fuzzy, but I think the resolution was basically "yeah, BBT doesn't play nice with RO".  Or, more to the point, "BBT doesn't play nice with the way that RO requires players to interact with the engines."  Which is essentially the same problem as yours.

[KerbMav]

Exclamation: There it is!

Sidenote: Regarding the time to impact on bodies with an atmosphere - why not display the time to impact as usual and indicate that it is an estimation disregarding atmospheric drag?

[DStaal]

13 minutes ago, KerbMav said:

Exclamation: There it is!

Sidenote: Regarding the time to impact on bodies with an atmosphere - why not display the time to impact as usual and indicate that it is an estimation disregarding atmospheric drag?

How would you indicate it was an estimation?

[Snark]

2 hours ago, KerbMav said:

why not display the time to impact as usual and indicate that it is an estimation disregarding atmospheric drag?

Mainly because it would be wildly inaccurate in a lot of cases, and I'd prefer to show no number at all rather than a badly misleading one.

I've considered the possibility of setting some sort of maximum threshold (i.e. allowing showing it if the surface pressure is below some critical level), so you could use it on Duna-like planets.  Am a little gun-shy of using it even there, though.  I'm seriously allergic to the possibility of misleading people.

1 hour ago, DStaal said:

How would you indicate it was an estimation?

That part, I'm not too worried about.  If I wanted to go ahead with something like that, I could figure out some way to work it into the formatting of the estimate string (add asterisks, or "est.", or something).

[KerbMav]

8 minutes ago, Snark said:

Mainly because it would be wildly inaccurate in a lot of cases, and I'd prefer to show no number at all rather than a badly misleading one.

I've considered the possibility of setting some sort of maximum threshold (i.e. allowing showing it if the surface pressure is below some critical level), so you could use it on Duna-like planets.  Am a little gun-shy of using it even there, though.  I'm seriously allergic to the possibility of misleading people.

That part, I'm not too worried about.  If I wanted to go ahead with something like that, I could figure out some way to work it into the formatting of the estimate string (add asterisks, or "est.", or something).

Make it a config file setting for the inner circle only ...

[Snark]

39 minutes ago, KerbMav said:

Make it a config file setting for the inner circle only ...

Yes, that is indeed an option I've considered.

 

On a tangentially related note, one idea that has recently occurred to me, that would be pretty easy to add and, I suspect, could be useful:  add an enhancement to the impact tracker so that it gives you a reentry warning.  That is, if you're in space, and you're approaching a body that has an atmosphere, and your periapsis would take you inside the atmosphere, it could give you a warning similar to the impact tracker, something like this:

Atmosphere in 39s

...you get the idea.  Hitting atmosphere isn't as big a deal as hitting rock, of course ... and if you're only grazing the outer fringes of the atmosphere, you may not care all that much.  And, unlike hitting the surface, you've got no reason to particularly want to hit zero velocity relative to the atmosphere when you hit it, so it certainly wouldn't have a burn time indicator for this, ever.

But I've had situations where I'm en route to reentry, and I like to have an idea of how much time I have before things start getting toasty and draggy (e.g. I've got some last-minute EVA work to do, or I'm considering when to start retracting solar panels and radiators and things, etc.)

Another example of a potential BBT enhancement would be "time to periapsis" or "time to apoapsis" (which of course you already have in the map view, but not in flight), perhaps with a burn time indicator for "burn time to capture" (if you're on an escape trajectory), and/or "burn time to circularize".  Would need to sort out priorities here (for example, if you're doing a flyby of a planet, you likely care about both the time-to-capture and time-to-circularize).

It bears some thinking about.  It's the old struggle of convenience versus clutter-- a lot of these things are stuff you can easily do in stock with a maneuver node, so adding complexity with a mod like BBT may not be the right answer.  Balanced against, "gosh, if I have a time-to-circularize indicator when I'm on a suborbital trajectory and Ap is still ahead of me, then I don't have to use a maneuver node for that," which could be convenient on basically every launch to LKO ever.

Anyway, no promises here (either for "whether" or "when"), just giving a glimpse into some of the thoughts percolating in the ol' noggin. 

[Loren Pechtel]

2 minutes ago, Snark said:

But I've had situations where I'm en route to reentry, and I like to have an idea of how much time I have before things start getting toasty and draggy (e.g. I've got some last-minute EVA work to do, or I'm considering when to start retracting solar panels and radiators and things, etc.)

Maybe if you're hitting really hot but so long as the entry angle is low I've found it's perfectly acceptable to wait on the solar panels until I actually hit the atmosphere.  The outer fringes won't break them.  I've never hit atmosphere with anything but conformal radiators so I can't say how vulnerable they are.

[Snark]

5 minutes ago, Loren Pechtel said:

Maybe if you're hitting really hot but so long as the entry angle is low I've found it's perfectly acceptable to wait on the solar panels until I actually hit the atmosphere.  The outer fringes won't break them.  I've never hit atmosphere with anything but conformal radiators so I can't say how vulnerable they are.

Sure, but it can be nice to know when atmosphere would start.  If you've got no maneuver node set and there's no indicator at all there, it might be handy to know when you're hitting atmosphere.  If nothing else, it gives you an indicator in flight view that you will be hitting atmosphere, which could be a handy milestone if you're adjusting trajectory.

[Kerbart]

If it's inaccurate due to things like terrain elevation and pitch (I vaguely remember this being one of the issues) then there's not a lot to be done, I think.

If it's inaccurate due to making assumptions (atmospheric density, etc), then there's probably a lower and upper limit, and you could say "impact in 5-12s?"

Just guessing here.

[Snark]

7 minutes ago, Kerbart said:

If it's inaccurate due to things like terrain elevation and pitch (I vaguely remember this being one of the issues) then there's not a lot to be done, I think.

You're talking about the impact tracker here (i.e. back to @KerbMav's original request above).

That type of inaccuracy has nothing to do with atmosphere per se-- it's present on vacuum worlds as well, since BBT just looks at the height of the terrain of wherever the ship happens to be located at the moment.

It actually is fixable, it's just a helluva lot of work.  Basically, what I'd need to do is, instead of just simplistically grabbing the current terrain elevation under the ship as I currently do, I'd instead need to do a bunch of calculations to project the trajectory ahead of the ship and work out where it intersects the terrain.  It's non-trivial, not least because it's a "numeric" brute-force calculation (i.e. requires doing repeated iterative checks and then zeroing in on a solution), which means it would have to be coded in a way that avoids tanking performance by sucking up the CPU.  Doable, yes.  And I'd really like to have that functionality.  But it's a pretty tall order, which is why I haven't gotten around to doing it even though I've been thinking about it for well over a year.  My mental calculation of "how much work would I have to do" compared with "how much benefit would it add", balanced against "how busy am I, IRL" just hasn't pushed me over the tipping point.

12 minutes ago, Kerbart said:

If it's inaccurate due to making assumptions (atmospheric density, etc), then there's probably a lower and upper limit, and you could say "impact in 5-12s?"

Nope, because there's no way I could guarantee accuracy-- I don't even have any valid grounds for deciding where to draw those limits.  Atmospheric drag & lift are hard.

[DStaal]

Time to atmosphere sounds fun - and is often something that I wish I could check easier.  It's rarely something that I need to know exactly - but it's often something I need to have general knowledge of, and there's not a good way to do that at the moment.

Time to apoapsis and time to periapsis I don't see a need for here.  There are several other mods that can provide that with convenient and fairly minimal UI (I have it in an KER HUD, for instance - though I know MechJeb has something as well, and I think VOID has something, and there are probably others).  The 'burn to circularize' vs. 'burn to capture' is also one where to me the obvious solution is 'put in a maneuver node for what you want' - and then BBT already handles it for you.  The time to apoapsis in a launch (that is, while on a suborbital trajectory) could be a good special case however.  (Though I'll admit I use GravityTurn, which handles it for you - including putting a maneuver node in to circularize.)

[KerbMav]

@Snark @Padishar @cybutek

Reading your ideas for the future makes me think that you might want to join forces with the KER team, as many things are already present there, just at different locations on the screen (e.g. time to atmosphere) and lots of things might complement quite nicely (e.g. your better burn times) - KER also has an impact timer, and since it can show the slope of the terrain, I think it might also account for terrain regarding impacting mountains while flying horizontally, but I am unsure atm.

[Loren Pechtel]

1 hour ago, Snark said:

Sure, but it can be nice to know when atmosphere would start.  If you've got no maneuver node set and there's no indicator at all there, it might be handy to know when you're hitting atmosphere.  If nothing else, it gives you an indicator in flight view that you will be hitting atmosphere, which could be a handy milestone if you're adjusting trajectory.

Yeah, it would still have some use--I don't think hitting the atmosphere while doing a spacewalk would be a good idea!  (I have had a Kerbal in a command seat while dabbling in the edges of the atmosphere, though--works fine.)

[Snark]

2 hours ago, DStaal said:

Time to apoapsis and time to periapsis I don't see a need for here.  There are several other mods that can provide that with convenient and fairly minimal UI (I have it in an KER HUD, for instance - though I know MechJeb has something as well, and I think VOID has something, and there are probably others).

Yup.  No need to reinvent the wheel.  Bearing in mind that I don't run any of those mods myself, and never will, and they have a very different design philosophy from BBT.   So my main decision point for whether to add something like that is "would I use it in my own game", and for periapsis / apoapsis, the answer is generally no, since maneuver nodes do the trick.

I thought of the time-to-atmosphere bit because that's a thing that I actually find myself wanting to know from time to time-- it would actually be useful to me, occasionally, in my own gameplay.  And it's a thing that's not easily handled with a maneuver node or other stock feature.

1 hour ago, Loren Pechtel said:

Yeah, it would still have some use--I don't think hitting the atmosphere while doing a spacewalk would be a good idea!

It may or may not be a problem.  Totally depends on the situation.  For example, being outside when you're about to hit Jool's atmosphere would be a very, very bad idea, because you're going many km/sec and you'll get fried very fast, even in the upper atmosphere.  But Duna?  No problem, assuming you're not going interplanetary speeds, because orbital velocity is only 800 m/s or so.  Or:  are you talking about spacewalking and floating around, or are you hanging on to a ladder?  The former case needs to care about atmospheric drag, the other doesn't (much).  And so forth.

So there will be a lot of scenarios where the user doesn't care much, but there will be other scenarios where they do.  So if there's this empty "time until event" spot right next to the navball that gets routinely used for maneuver nodes, rendezvous, impact, etc., and it's otherwise empty, why not show time until atmosphere. 

 

[Beetlecat]

On 6/11/2017 at 8:48 PM, Snark said:

Off-topic rant that has nothing to do with BBT in spoiler section.

Further off-off topic:

Your rant has gone into my brain as a mod-idea-germination. Wayyyy out of my league, but could attempting at hacking an overlay/circumvention of the right-click part displays to do just that? Allow selective re-ordering and visibility toggles? Maybe something like Part Commander.

</return to thread>

[Snark]

Hi gang,

Welcome to the experimental pre-release of BetterBurnTime 1.6.  New feature:  atmosphere tracking.  Details below, but the TL;DR is that it gives you an indication of when you're about to enter or exit atmosphere.

It's not on SpaceDock; you can get it via [EDIT: Link removed, I've shipped 1.6 now for real. Please use that.  Here's the release announcement. Thanks!]

FAQ:

What's the deal with this "experimental" thing?

I'm doing things just a little differently than I've done up to now.  Previously, I'd just make a new version, test it myself until I decide it's good, then release it and that's that.  If there are bugs, release a minor patch or two.

The problem is that as BBT becomes more complex and adds features, the number of possible interactions go up, making it harder for me to test it exhaustively all by myself.  Also, as it has gained in popularity, a lot more users are impacted if I ship a lemon-- it's in the thousands!  (I really want to avoid another occurrence of something like the BetterBurnTime 1.5.2 debacle.)

So I've decided to do an "experimental pre-release" instead.  It's just like a regular release, but I'm not updating the CKAN version or pushing it to SpaceDock.  I'm just announcing it here, and providing a github link so people who are interested can grab it.  I'll give it some time, say a week or two, to "bake"-- during this interval, hopefully enough people are using it (by choice) that they'll find any really glaring bugs, and/or deliver useful feedback about the design.  I may release updated builds incorporating feedback, we'll see how it goes.  When things seem to have reasonably stabilized, I'll make it "official" and release through the usual channels.

Is it safe to use?

It's as safe as any of my releases are.    I've done my usual poking and prodding at it before releasing.  Doesn't mean there aren't any bugs, but there aren't any that I know about at the moment.  "Experimental" here doesn't mean "riskier than Snark's usual releases".

Basically, my intention is that this is "release quality"-- I just want to give folks who choose to try it out (and be on the leading edge) a chance to do so for a while, before I shove it down thousands of people's throats by pushing it to SpaceDock (which will update CKAN).

So if you're one of the small minority of BBT users who are actually reading this, please try it out.  You'll be doing me (and thousands of CKAN users) a favor.  Many thanks.

What's the new feature all about?

It just shows a little indicator (see screenshot above) when you'll soon be entering or exiting atmosphere.  It's configurable via config.xml.  You can turn the feature completely off, if you don't care for it.  It also has config settings for "max time to atmosphere exit" and "max time to atmosphere entry", controlling how far in advance the indicator should show up.  (It defaults to 15 minutes to entry and 5 minutes to exit.)

Note that the "time to atmosphere exit" is necessarily approximate, because it does not take drag into account at all when projecting your trajectory-- it just assumes a ballistic path.  This will be pretty accurate if you're very high up in the atmosphere where drag is minimal, but if you're hitting suborbital speeds while still deep in the soup, it'll be off quite a bit to start with.

Note that unlike the maneuver-node, impact, and closest-approach trackers, there's no "burn time" displayed.  That's because there's generally no particular reason why someone would especially want to do a burn right at atmosphere transition.  Therefore, no burn time display, and no countdown dots.  It's simply a time display until the transition into or out of the atmosphere.

Where can I download it?

Right here! 

[EDIT: Link removed, I've shipped 1.6 now for real. Please use that.  Here's the release announcement. Thanks!]

 

I found a bug, or I have a design suggestion.  What do I do?

Best thing to do is just post it here for discussion.  I check this thread regularly.  I really appreciate any feedback I can get!

Enjoy!

[Rodger]

I'm getting NRE spam with the exp version when I launch a craft, only BBT installed.

https://www.dropbox.com/s/q0x56o7gb2mglwa/BBTKSP.log.zip?dl=0

[Human Person]

Wow. Why haven't I installed this earlier? I new this mod existed, but I kept estimating those things and doing rough calculations in my head. Now, I finally have a mod for this. 

[KerbMav]

52 minutes ago, Rodger said:

I'm getting NRE spam with the exp version when I launch a craft, only BBT installed.

https://www.dropbox.com/s/q0x56o7gb2mglwa/BBTKSP.log.zip?dl=0

To give the usual answer: What version of KSP and mod do you use?

[Rodger]

1.3 on mac, and with the experimental version Snark posted just above my post.

[Snark]

8 hours ago, Rodger said:

I'm getting NRE spam with the exp version when I launch a craft, only BBT installed.

https://www.dropbox.com/s/q0x56o7gb2mglwa/BBTKSP.log.zip?dl=0

Woot!  Ladies and gents, we have our first bug report for 1.6.X01! 

Thanks for reporting-- will definitely take a look.  IRL has me occupied at the moment, so it'll be a day or two before I can investigate, but thank you!

[Gordon Dry]

In my heavily modded install I've not seen any exception yet...