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

[Snark]

What it does

• When the ship is in vacuum and on a collision course with the ground, it will automatically show time-to-impact, and the estimated burn time to kill your velocity at ground level.
• When the ship is in orbit and has an upcoming rendezvous with a target ship, it will automatically show time-to-closest-approach, and the estimated burn time to match velocity to the target.
• When the ship is on a course to enter or exit atmosphere in the next few minutes, shows time until the transition.
• For closest-approach, it shows a countdown indicator to tell you when to start your burn.
• When the ship's orbital period is close to geosynchronous, shows a time-delta-from-geosynchronous display, to make it easy to set up synchronous orbit.
• When the ship has a target and its orbital period is close to the target's, shows a time-delta-from-target-synchronous display, to make it easy to synchronize orbits.
• SRBs display their burn time. It's shown on the part tooltip in the vehicle editor, as well as on the part's right-click menu in the editor and in flight.

What this means for landing on vacuum worlds:

• No more messing around with ground-level maneuver nodes to figure out when to start your retro-burn.

What this means for target rendezvous:

• If you can set up a rendezvous that will take you within 10 km of the target, you'll see an estimated time-until-closest-approach, and an estimated burn time to match velocity with the target.

What this means for setting up communications networks:

• It's really easy to set up synchronous satellites (either geosynchronous, or synchronous with each other).

Download from SpaceDock
License: CC-BY-NC-ND 4.0
Source code

Notes

The "countdown" indicator
For closest-approach, the mod displays a "countdown" indicator. This is a little row of green dots, immediately below the estimated burn time. This row of dots counts down until it's time to start your burn: when the last dot disappears, start the burn.

The display is logarithmic.  The last three (biggest, leftmost) dots are in seconds:  3, 2, 1, go.  After the first three dots, it's 5 seconds, 10 seconds, 15 seconds, then it doubles for each dot after that.

Note: No countdown indicator is currently shown for the "time to impact" indicator; this is because "when should I start?" is more complex, depending on a lot of factors including your descent angle, TWR, etc.  This feature may eventually be added, but until then, you're on your own.

If you don't like this indicator, you can do any of the following (see mod page on SpaceDock for details):

• Customize its appearance
• Make it numeric rather than graphic (e.g. "Start burn in 43s" or "Burn-43s" or however you like)
• Turn it off completely

 

The "insufficient fuel" warning

Normally, the mod displays estimated burn time like this (48 seconds in this example):
Est. Burn: 48s
If the mod decides that you don't have enough dV to do the specified burn, it will display the time like this instead:
Est. Burn: (~48s)
Note that it won't do this if you have the "infinite fuel" cheat turned on (since then you always have enough dV!)

The time-to-impact indicator
Under the right circumstances, the mod will display a "time until impact" indicator (instead of "time until maneuver"), along with an estimated burn time which is how long your engine would need to kill your velocity at ground level.

All of the following conditions must be met for this indicator to be displayed:

• The impact tracker isn't disabled via settings (see "Settings", below)
• The planet/moon whose SoI you're in has no atmosphere.  (Someday I may release an update to enable the impact indicator when it's in atmosphere, but not right now.  It gets ugly and would significantly complicate the calculations.)
• You're on a trajectory that intersects the surface.
• You're falling by at least 2 m/s.
• The time of impact is no more than 120 seconds away (though you can tweak this with settings, see below).

Note that the time-to-impact is based on the assumption that you don't do a retro-burn and just coast to your doom.  So if you're figuring out "when do I start my retro-burn to land," you'll generally want to wait a little bit after the point at which time-to-impact equals estimated burn time.

 

The time-to-closest-approach indicator

Under the right circumstances, the mod will display a "time until closest approach" indicator (instead of "time until maneuver"), along with an estimated burn time to match velocity with the target.

All of the following conditions must be met for this indicator to be displayed:

• The approach tracker isn't disabled via settings (see "Settings", below)
• You don't have a maneuver node set
• The impact tracker (see above) isn't displaying time-to-impact
• You have a target, which is a vessel (e.g. not a planet)
• Neither you nor your target is landed
• You have an upcoming approach within 10 km distance
• The closest approach is no more than 15 minutes from now
• You're not within 200 meters of the target and going under 10 m/s, or within 400 meters and going under 1 m/s

To slow your craft to a halt when it's close to the target, you should start your burn when the time-until-closest-approach is about half of the estimated burn time shown.

 

The time-to-atmosphere indicator

If you're imminently about to enter or exit atmosphere, it shows time remaining.

• The atmosphere tracker only shows time until transition (there's no burn time or countdown dots).
• Note that for time-until-exit, it assumes a ballistic trajectory and makes no attempt whatsoever to account for drag.
• There are config options for this feature in config.xml. If you don't like the default behavior, you can adjust how far ahead of time it displays the warning, or turn the feature off completely if you prefer.

 

The synchrony tracker

If you're in orbit, and you're reasonably close to being in synchronous orbit around the current celestial body, the mod will display a "geosynchrony tracker" that shows how close you are to perfect geosync.

The tracker displays a time delta (positive or negative) showing how far off your current orbital period is from perfect geosynchrony. It shows hours/minutes/seconds until you get within 10 seconds, then switches to milliseconds display. (The transition point is configurable, see below.)

If you're in orbit and you have a target, then you get a "target synchrony" indicator, that works the same as the geosynchrony one, but shows time delta relative to target rather than relative to the celestial body's rotation period.

This makes it easy to put satellites in synchronous orbit. If the value is negative, thrust ; if positive, thrust . Goal is to get as close to zero as possible, for synchronous orbit.

All of the following conditions must be met for this indicator to be displayed:

• No other tracker is currently active.
• You're in a stable orbit (e.g. not suborbital or escaping).
• The period of your current orbit is within 5% of the current celestial body's rotation period (this is configurable, see below).
• Your ship has been "idle" (defined as, no throttle and no control inputs) for less than 10 seconds (this is configurable, see below).

In addition, this tracker also supports an override key that allows manually forcing it to display, even if the above conditions aren't met, as long as no other tracker is active. By default, the override key is the right Ctrl key (this can be changed via config). Also, by default, the override is only active while you're actually holding the key down; however, there's a config setting that lets you make it "sticky" (i.e. press once to turn on, press a second time to turn off).

When the override key is active and you're not currently in a stable orbit, it will just say gsync ~.  If the override key is active and geosynchronous orbit is actually impossible for the current celestial body (because the needed altitude would be outside the SoI), then it will say gsync X.  (These are only shown when the override is active, since if it isn't, in this case the tracker's not shown at all.)

See the "How to configure" section below for a list of these configuration settings.

 

The SRB burn-time indicator

SRBs display their burn time, in the following places:

• On the tooltip in the parts pane in the editor
• On the part's right-click menu (in the editor)
• On the part's right-click menu (in flight)

(Note that the burn time calculation takes thrust limiter into account.)

 

Caveats

A few things to know about how the mod works. Summary presented here; please see the README for full details.

• It doesn't know about staging. It assumes that all fuel will be consumed by your current stage. Therefore, the burn time estimate and dV warning indicator may be inaccurate if you're going to be staging in the middle of the burn. (After you stage, though, it will immediately update itself.)
• It doesn't know about fuel flow. It assumes that all your fuel will be available to all your engines throughout the burn. Therefore, if any of your engines are going to run dry before others during the burn, the time estimate will be optimistic. (After the engines run dry, though, it will immediately update itself.)
• It ignores electrical supply, so make sure your ion engine has enough power.
• Time to impact is very simplistic. It looks at the elevation directly under the ship, and at your current vertical speed.  It corrects for the acceleration of gravity, but nothing else.  This means that if you're flying over rough terrain, the time-to-impact indicator will be irregular (it will suddenly get shorter when you're flying over an ascending slope, or longer when you're flying over a descending slope).  If you're hurtling horizontally and about to smack into the side of a mountain range looming up in front of you, the mod has no clue.  Be warned.
• The time-to-impact estimate takes into account your current velocity and the acceleration of gravity, and that's it.  It deliberately does not take into account the acceleration of your engines, if you're firing them.  It's an estimate of "how long would I take to smash into the ground if I turned off all my engines."  So when you're retro-burning to land, the actual time to reach the ground will be longer than the displayed estimate, depending on things such as your TWR, throttle setting, angle of approach, etc.  So if you want to time your burn so that you reach zero velocity right when you get to ground level, you'll need to wait a little bit past the point where the estimated time to impact equals the estimated burn time.

 

How to configure

After the first time you run KSP with the mod installed, there will be a configuration file located at under this location in your KSP folder, which you can edit to adjust settings:

GameData/BetterBurnTime/PluginData/BetterBurnTime/config.xml

Specific settings listed in spoiler.

Spoiler

• UseSimpleAcceleration: By default, this is set to 0, meaning that the mod will use complex acceleration in its calculations.  If you set it to 1, then you will force the mod to use simple acceleration for all its calculations all the time.
• OverrideKey: Defaults to "right ctrl". Sets which key is used to toggle BetterBurnTime's "override" behavior (e.g. for geosynchrony tracker). See Unity documentation for allowable values.
• StickyOverride: Defaults to 0, meaning that the override key is only active while you're holding it down. Set to 1 if you want it to be "press once to turn on, press a second time to turn off".
• ShowImpactTracker: By default, this is set to 1.  If you set it to 0, then you will disable the "time to impact" display.
• MaxTimeToImpact: This is the maximum time, in seconds, that the impact tracker will predict a collision with terrain.  By default, it's 120 (two minutes). You can raise or lower this.  (Has no effect if ShowImpactTracker is set to 0, since then all impact tracking is turned off.)
• ShowClosestApproachTracker: By default, this is set to 1. If you set it to 0, then you will disable the "time until closest approach" display.
• MaxTimeUntilEncounter: This is the maximum time, in seconds, that the closest-approach tracker will predict a closest approach. By default, it's 900 (fifteen minutes).
• MaxClosestApproachDistanceKm: This is the maximum distance, in kilometers, that a closest approach can be for the closest-approach tracker to show a prediction. By default, it's 10 km.
• MinTargetDistanceMeters: The target must be at least this many meters away from your ship for the closest-approach tracker to show a prediction. By default, it's 200 meters.
• ShowAtmosphereTransition:  Defaults to 1. Set to 0 if you don't want to show the atmosphere transition tracker.
• MaxTimeToAtmosphereExit: Max seconds beforehand to display the atmosphere exit warning.  Defaults to 300.
• MaxTimeToAtmosphereEntry: Max seconds beforehand to display the atmosphere entry warning.  Defaults to 900.
• GeosyncPrecisionLimit: Defaults to 0.05, i.e. 5%. This is how close to geosynchronous you need to be before the geosynchrony tracker is displayed (if the override key is inactive). Set to zero if you want to disable the geosync tracker entirely.
• GeosyncIdleTimeout: Defaults to 10 (seconds).  If the ship has been idle for more than this many seconds, the geosynchrony tracker is hidden (if the override key is inactive).
• GeosyncLabel: Defaults to "gsync". This is the text of the label used on the geosync tracker.
• TargetsyncLabel: Defaults to "tsync". This is the text of the label used on the target-sync tracker.
• GeosyncSecondsTransition: Defaults to 10 (seconds). If the geosync-error time displayed is fewer than this many seconds, the display switches to milliseconds.
• FormatSeconds, etc.: Various entries named "Format" are used for formatting the time display. You can edit these to change the way time is displayed. See the .NET numeric formatting rules for details.
• CountdownText: This string is used for displaying the "countdown" indicator. You can customize this to suit yourself, just be sure to separate the "pips" with whitespace.
  • To make it display a numeric value rather than a graphic string of "pips", just include "{0}" in the string. For example: "Start burn in {0}"
  • To turn off the countdown indicator completely, set this to an empty string.
• CountdownTimes: This string is a comma-delimited list of threshold times (in seconds) for displaying the number of pips in the countdown indicator. (Ignored if you're using a numeric countdown.)

 

A historical note

The original impetus for this mod was actually something that no longer is part of the mod! Before KSP 1.5, the stock burn-time indicator for maneuver nodes was... suboptimal. It had a variety of shortcomings that made it less useful than it could have been.

BetterBurnTime was originally created to address those shortcomings and make the navball's burn-time indicator "just work better". That was the original purpose; that was originally the only thing that the mod did.

Over time, I added some additional handy functions-- the landing, rendezvous, and atmosphere-transition information.

Then, KSP 1.5 drastically improved the stock navball, and basically did all the improvements that BetterBurnTime was originally created to do. Yay! So that's stock now, which means I removed that functionality from BetterBurnTime after KSP 1.5.

However, the additional functions are still convenient, and still not in stock, so those remain-- and are now what BetterBurnTime is about, since its original purpose (maneuver nodes) has become moot.

If you're running a pre-1.5 version of KSP and want better navball functionality, you can run BetterBurnTime 1.6.1 and get the enhanced maneuver-node functionality.

 

Acknowledgments

Thanks to @FullMetalMachinist for the excellent suggestion of using a row of dots to show the countdown-to-start-burn.  Ask and ye shall receive!  Thanks also to @Gen. Jack D. Ripper for usability suggestions on the countdown timer's appearance.

[kivech]

Nice, downloading now.

[HoloYolo]

Take my rep! Finally, an accurate way to see burn times!

[Hotaru]

Cool, that's always bugged me about the stock indicator. Will definitely give this mod a try, thanks!

[Waxing_Kibbous]

Wow, you're a hero for this. I'm liking this trend of micro-mods Snark :D

[Kerbart]

Funny, I was just thinking about this today. “What if I plug in the dv into the rocket equation with the current mass as the starting point, then I know the mass at the end of the burn, and the difference is divided by the fuel flow. I'd get the burn time fairly accurate, every time”

I'm clueless about making mods, so thanks for reading my mind.

Edited December 25, 2015 by Kerbart
Removed forum migration ickies

[Snark]

On 11/21/2015 at 7:31 PM, Waxing_Kibbous said:

Wow, you're a hero for this. I'm liking this trend of micro-mods Snark

Thanks.

I'm a big fan of KISS. I'm also a big fan of minimalist mods that are unintrusive to gameplay experience and avoid adding UI complexity or taking screen real estate. This mod probably has the highest ratio of "hours spent coding/debugging per pixel affected" of anything I've worked on.

My own personal micro-mod hero is the author of Navball Docking Alignment Indicator:

Aside from the incredible usefulness of the mod, I love its Zen-like simplicity. Zero UI to futz with. Zero screen real estate. It just adds a little icon to the navball, automatically, and only when it's needed. Hats off. That is the ideal I strive for.

Just for comparison, I like this far more than the other popular docking aid I see referenced a lot, NavyFish's Docking Port Alignment Indicator, because the latter adds UI and takes up screen space. I find it interesting that the one I don't like is four times more popular in terms of download count than the one I like, no idea why.

Anyway, thank you, it's nice to feel appreciated!

(Update, May 2016:  Fixed formatting, and replaced broken links to now-defunct hosting site.  Went in and updated it because someone just quoted this post in the thread.)

[Snark]

On 11/22/2015 at 4:38 PM, Kerbart said:

Funny, I was just thinking about this today. “What if I plug in the dv into the rocket equation with the current mass as the starting point, then I know the mass at the end of the burn, and the difference is divided by the fuel flow. I'd get the burn time fairly accurate, every time”

That was pretty much my own thought process, too. This has bugged me since I first started playing KSP. It seemed like such a simple thing to fix; I mean, heck, it's not rocket sci-- Oh. Well, okay, but it's not that complicated, thought I.

Anyway, once I started diving into the details, it was a bit more complicated than I had anticipated, mainly because the problem seems so simple that it's easy to miss the edge cases, of which there turn out to be lots.

Here are the edge cases I ran up against, and what I do about them:

• What if not enough fuel? Do the "real" calculation for the fueled part of the burn, then assume constant acceleration (at the empty mass) for the remainder.
• What if propellants are mismatched (e.g. running out of O before LF)? Figure out how much burn time is available for each one and pick the shortest.
• What if the engines aren't all pointing in the same direction? Take the vector sum of their thrusts when computing acceleration.
• What if the engines have different Isp from each other? Combine them appropriately.
• What about staging? Don't try to predict it, just publish a caveat.
• What about fuel flow causing one engine to run dry before others? Ditto.
• What about electricity? Just ignore it.
• What if the "infinite fuel" cheat is on? Dumb it down to simple constant acceleration.
• What about thrust limiters? Deal with 'em.
• ...that's all I can remember off the top of my head, but you get the idea.

 

On 11/22/2015 at 4:38 PM, Kerbart said:

I'm clueless about making mods, so thanks for reading my mind.

Heh, quite welcome.

FYI: as long as you know programming and C#, it turns out that modding KSP is ridiculously easy. Why the dickens didn't I start this sooner? Never took the plunge until a week ago, on the assumption that the learning curve would be really time-consuming. Turns out to be easy to jump right in. And my goodness, Visual Studio is even free to download these days. (When the heck did that happen?) I was very pleasantly surprised. It's a combination of Squad making a very mod-friendly design (kudos for that!), and .NET's being really nice to program with. Just start a new C# library, add a reference to the KSP assembly and Unity, and you're off to the races.

Edited February 24, 2016 by Snark
fixed formatting for compatibility with new forum software

[bgeery]

Kerbal Engineer has no problem calculating with staging needed mid-burn, so hopefully you can add that feature to your mod as well. Still, a big improvement over the stock functionality.

[DMagic]

[quote name='bgeery']Kerbal Engineer has no problem calculating with staging needed mid-burn, so hopefully you can add that feature to your mod as well. Still, a big improvement over the stock functionality.[/QUOTE]

That's because Engineer has an extremely complex fuel flow simulation running. So it can figure out how much dV you have in each stage, how many engines in each stage, etc...

[Snark]

On 11/21/2015 at 5:25 PM, bgeery said:

Kerbal Engineer has no problem calculating with staging needed mid-burn, so hopefully you can add that feature to your mod as well. Still, a big improvement over the stock functionality.

I was wondering how long it would be until someone mentioned KER.

Yes, it's possible to do that. I thought about it, I'd love to handle it. However, having thought it through, I made a conscious decision not to, and that decision is unlikely to change.

First things first: KER is a very big, complex mod. Go look at its GitHub repository sometime... then go compare it to my own mod, which lives in a teeny-tiny fraction of the amount of code and has no UI at all. KER is at least 10 times the size of my mod, it's a massive tour de force. Not gonna try to compete with that. I have not the slightest intention of trying to solve the problems that KER does. It's already been there and done that, no need to reinvent the wheel.

Also: The staging problem is non-trivial. It's a massive jump in complexity. What you have in your head is undoubtedly the simple case of "I have one engine below one tank, and then a decoupler above that, and then another engine with another tank." That would be simple to code. But KSP allows building rockets in all kinds of ways, and by the time you add fuel flow paths through ducts and so on and so forth, it becomes quite complex.

Solving that one problem is something I could do. However, not only has KER already solved it, but I would spend considerably more time on it that on the entire rest of the mod put together. It would be a lot of effort expended to handle one particular scenario... and I have other mods I'd rather write in the meantime.

Plus, there's a philosophical issue here: Once you start introducing staging and such, it starts to get into the realm of uncertainty that a mod can't resolve without UI to get input from the player. For example, suppose there are some drop tanks... do you know when the player intends to drop them? It won't necessarily be right when they run out of fuel. Maybe the player wants to tote those empty tanks to Mun orbit to fill them up before heading off to Eeloo.

One way to solve that problem is to go the route of KER, which has not only a lot of logic under the hood, but also tons of UI. The player can make lots of decisions and tell the mod what to do.

However, I don't want to do that. I like (and therefore want to write) mods that have the bare minimum of UI-- none, if possible. I've deliberately designed this mod so that it doesn't require any interaction at all: you just install it and it silently and automatically makes your game experience better. That does mean that any decision point that would require player input is going to be an issue. I choose to deal with that by not dealing with it: I deliberately limit the scope of the mod to only solve problems for which there is one obvious correct answer.

If the player wants something fancier, then there's KER happily waiting for them.

[Kerbart]

[quote name='Snark'](...)
Here are the edge cases I ran up against, and what I do about them:
[LIST]
[*]...
[*]...
[*]...that's all I can remember off the top of my head, but you get the idea.
[/LIST]
(...)[/QUOTE]

That's a lot more than I would think of. As mentioned in other posts, yes, you can build some that takes [I]every[/I] case into consideration and rebuild half of KER, but even with the "no staging" (and that would add an amount of complexity I'd rather not think of) this is already [I]way[/I] more accurate than the stock indicator.

As for the simplicity of modding... I guess I'll have to try it one day. For now I'm happy as a pig in the mud writing scripts for kRPC. :)

[Waxing_Kibbous]

I may be imagining things, but I noticed when throttling an engine down via right-click on the engine the est. burn time increased accordingly, nice that that works as planned. This is a good mod for beginners IMO, one of my early frustrations was the lack of a burn time readout which seemed to happen on a pretty regular basis. I agree with the KER comparison, this is a nice simple readout that's good for many cases.

[bgeery]

[quote name='DMagic']That's because Engineer has an extremely complex fuel flow simulation running. So it can figure out how much dV you have in each stage, how many engines in each stage, etc...[/QUOTE]Maybe you can get the numbers from Engineer if it's installed and just display them? Or perhaps use the code yourself in your mod (it's licensed GNU v3); why reinvent the wheel? Anyway, just thinking out loud.

PS: didn't see your longer reply until after I replied. Edited November 22, 2015 by bgeery

[Snark]

[quote name='Waxing_Kibbous']I may be imagining things, but I noticed when throttling an engine down via right-click on the engine the est. burn time increased accordingly, nice that that works as planned. This is a good mod for beginners IMO, one of my early frustrations was the lack of a burn time readout which seemed to happen on a pretty regular basis. I agree with the KER comparison, this is a nice simple readout that's good for many cases.[/QUOTE]

If you mean throttling by adjusting the thrust limiter on the engine: yes, it handles that! :)

I had fun during my testing by building a pushmi-pullyu ship that was basically just a fuel tank with a Terrier at each end, pointing in opposite directions. Set one of them to, say, 50% with the thrust limiter, then have fun watching the burn time shoot up and down as I slide the other one above and below 50%.

[X40c]

Does this support more complicated modded engines, like the ones from KSPI? The one thing the vanilla brurntime indicator had going for it, was that it could sometimes give you an inkling about engines that MechJeb or Engineer weren't able to.

[Snark]

[quote name='X40c']Does this support more complicated modded engines, like the ones from KSPI? The one thing the vanilla brurntime indicator had going for it, was that it could sometimes give you an inkling about engines that MechJeb or Engineer weren't able to.[/QUOTE]

The mod has no custom support for any mod, and I have never run KSPI, so I don't know the answer without knowing something about how their engines work.

That said, I wrote it as generically as possible. It queries the ship for all its engines, asks the engines about their propellant requirements, scans the ship for a tally of how much of those propellants are on board. Any engine that works basically like a stock engine does ("I have a thrust amount, I have an ISP, I require the following propellants carried on board in order to work") ought to be fine.

Though if KER and MechJeb stub their toes, that would be a pretty tough act to follow.

What's so special about the engines in KSPI?

[X40c]

[quote name='Snark']The mod has no custom support for any mod, and I have never run KSPI, so I don't know the answer without knowing something about how their engines work.

That said, I wrote it as generically as possible. It queries the ship for all its engines, asks the engines about their propellant requirements, scans the ship for a tally of how much of those propellants are on board. Any engine that works basically like a stock engine does ("I have a thrust amount, I have an ISP, I require the following propellants carried on board in order to work") ought to be fine.

Though if KER and MechJeb stub their toes, that would be a pretty tough act to follow.

What's so special about the engines in KSPI?[/QUOTE]

Variable thrust and ISP (e.g. lower thrust = higher ISP and vice versa), engine's that provide near-infinite amount of dV at low thrust as long as they're powered and of course the whole power system that I don't really expect to be accounted for. There's also stuff like soot buildup and what not.

[Snark]

[quote name='X40c']Variable thrust and ISP (e.g. lower thrust = higher ISP and vice versa), engine's that provide near-infinite amount of dV at low thrust as long as they're powered and of course the whole power system that I don't really expect to be accounted for. There's also stuff like soot buildup and what not.[/QUOTE]

Well, it depends how it's implemented. BetterBurnTime has no idea about variable Isp. It just asks the engine "what's your Isp?" and goes with that. So depending on how the KSPI engines are implemented and how they answer the question, it might give a wild overestimate or a wild underestimate about the available dV.

That said: even in the worst case scenario where it's terrible, I wrote the mod with a config option (see the README) that tells it to just turn off all dV checking and do a simple burn time calculation based on "time = dV / acceleration", the same way the stock game models it. So if you turn on that option, you won't get the extra dV goodness, but at least you'll still have something that works better than the stock game (i.e. it gets rid of that darn "N/A").

[Geschosskopf]

OH FRABJOUS DAY! Thank you Mr. Snark :). This will make doing flotillas SO much easier. No more need to bump the throttles prior to doing a burn node created months in advance :).

[m4ti140]

This should be stock. In fact it should be included in stock bug fixes as well. This is effectively a fix for a serious bug that's been present in KSP for aeons.

[Black-Talon]

Just discovered this mod and I'm going to give it a try.

I'm curious about something you might know...I have run into times when the burn actually takes much longer than predicted by the stock estimate that I cannot explain. These are long burns (3 to 4 minutes) with smaller, low thrust, engines (stock engines though, assuming I remember this right). Nothing that's obvious to me is impacting them. I'm locked onto the maneuver node and burn full throttle for 3 minutes only to discover that another 2 minutes of burn is now expected. No stages or other changes are occurring during the burn. It just slowly doesn't perform at the expectations of the estimate.

I haven't been able to think up an explanation for this. Given you've spent some time wrapping your mind around the flaws of the stock Burn Time Indicator, I thought you might have an idea that I have over looked? I'll let you know if I experience this with your mod, and under what conditions. Otherwise I'm optimistic that it is a thing of the past!

As I think about this previous experience I wonder... does this mod do any correction based on actual performance over the last 5 seconds or so? Or is it strictly calculated from the numbers reported? Perhaps my problem was that for whatever reason, the engine just isn't performing as it's stats would indicate it should. Still wish I knew why.

[Kerbart]

5 minutes ago, Black-Talon said:

As I think about this previous experience I wonder... does this mod do any correction based on actual performance over the last 5 seconds or so? Or is it strictly calculated from the numbers reported? Perhaps my problem was that for whatever reason, the engine just isn't performing as it's stats would indicate it should. Still wish I knew why.

The mod takes the I_sp of the engines used and the fuel consumption, and plugs that into the rocket equation (DV = I_sp×g×ln^m_wet⁄_{m_dry}), so you get (based on the current "wet" mass) the "dry" mass required for the DV needed. The difference is the amount of propellant to be used; that's divided by the mass flow of the propellant and that gets you the time.

 

[Black-Talon]

As I suspected. Makes sense, uses the right numbers.

If my craft is messing up those numbers, perhaps by having the engines crooked, impeded thrust, or perhaps even other bugs that create wasted thrust, my estimate will of course be wrong.

If I see it again I'll try to figure out what's going on for real. Thanks!

[Snark]

Hi all, just posted v1.1.  The main change is that I've added an estimated time-of-impact for when you're approaching the surface of a vacuum world, accompanied by an estimated burn time for killing your velocity at the surface.  It comes with some caveats (see the description in the main thread post), but hopefully it should be helpful for landing on the Mun or other places that don't have an atmosphere.  No more messing around with a ground-level maneuver node to figure out when to start your suicide burn.   Anyway, let me know what you think.