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

[renejant]

@snark i was wondering if there is a new version coming out soon™ ?

[Snark]

2 hours ago, renejant said:

@snark i was wondering if there is a new version coming out soon™ ?

Well, probably not anytime soon, to be honest.

I mean, it's not like I've decided definitively "no" or anything.  It's just that, when I'm modding, my proclivity can probably best be described as Frustration Driven Development™, and I've basically got my frustration cleaned up at this point. 

I'm a problem solver, not a creator.  I mod the game because I find something in the gameplay to be personally inconvenient, so I set out to fix that...  and for me, once the problem is solved, it's solved, and I tend not to be strongly motivated to tinker with it further unless something new comes up.

In the case of this mod, it's been seven years since I first released it, and I've got thousands of hours of KSP under my belt since then, so at this point the rough edges have all pretty much been sanded off, as far as my own gameplay is concerned.  If there were some important "missing feature" that I really cared about, I probably would have already added it by now.  And since KSP development itself is pretty much done at this point, it's not as though I've got any new changes in the game for which the mod needs updating.

That's not to say that there aren't some nifty features that could be added, and I've had a few possibilities in mind for a long time.  Atmospheric suicide burn times (as @dtondo mentioned) would be one such example.  Having more accurate vacuum suicide burn times-- which actually project trajectory and the terrain ahead of the ship, so as to be substantially more accurate, would be another.  The problem is, any idea that's really cool and wouldn't be a massive undertaking to implement (and/or risky as to how well it would work), I've pretty much already done.  Those remaining items tend to be complicated, risky, and (in my own gameplay) not all that necessary for me.

(Plus, with KSP2 looming closer on the horizon, my motivation to spend more time developing KSP mods has been waning; I expect that once KSP2 arrives, I'll probably jump into that without a backward glance, and my original KSP will just gather dust.  So I have this sense that any modding I do now will become obsolete and unused-- by me, anyway-- within a few months, so I'm less motivated.)

Anyway, I'm sorry I couldn't be more helpful. 

[renejant]

ok then i can know what to expect.... ill update the version file myself by hand for the time being, seeing the mod still functions properly... 

[se5a]

I'm trying to figure out how to calculate exactly when a burn for a maneuver should start, ie more accurate than "burn time / 2" .

iirc better burn time used to do this before KSP stock eventually added it, could you point me to either the code or math for doing this?

(own project/interest)

Edited August 31, 2022 by se5a

[Snark]

On 8/31/2022 at 5:35 AM, se5a said:

I'm trying to figure out how to calculate exactly when a burn for a maneuver should start, ie more accurate than "burn time / 2" .

That's... not really a thing.  What do you mean, "more accurate"?  It's exactly accurate no matter when you start it:  it starts exactly when you tell it to.

The only thing that an aid can tell you is "how long the burn will take", and that can be more or less accurate.  The old stock burn-time indicator was very inaccurate, which is why I wrote BetterBurnTime.  Then they came out with a new stock indicator that is accurate, so I removed that feature of BBT.

"Should I split the difference 50/50?  When should I start?"  That's your call, nobody else's.  BetterBurnTime has never done that.  The stock navball has never done that.

The old stock indicator had a hard-coded assumption of a 50/50 split.  BetterBurnTime was the same way.  The new-and-improved stock indicator assumes a 50/50 split by default, but has a setting that allows you to change that to whatever other percentage split you want-- but it doesn't tell you what percentage to use, that's backwards.  You tell it.

So, the short answer to your question is:

• No, BetterBurnTime has never done this
• Nor has the stock indicator
• There's no math for deciding this because "more accurate" isn't really a defined thing, here
• Basically everyone just does a 50/50 split, because that's simplest and it doesn't actually matter much anyway , as long as the burn isn't really long
• If the burn is really long, that's going to be inaccurate no matter what you do-- better to split into multiple burns, e.g. periapsis kicking

If you want to look at code for making automated decisions about burns, I'd suggest having a look at whatever MechJeb does, but since I've never used it myself, I'm in no position to vouch for how sophisticated it is (or isn't) about this sort of thing.

[Xt007]

20 minutes ago, Snark said:

That's... not really a thing.  What do you mean, "more accurate"?  It's exactly accurate no matter when you start it:  it starts exactly when you tell it to.

The only thing that an aid can tell you is "how long the burn will take", and that can be more or less accurate.  The old stock burn-time indicator was very inaccurate, which is why I wrote BetterBurnTime.  Then they came out with a new stock indicator that is accurate, so I removed that feature of BBT.

"Should I split the difference 50/50?  When should I start?"  That's your call, nobody else's.  BetterBurnTime has never done that.  The stock navball has never done that.

The old stock indicator had a hard-coded assumption of a 50/50 split.  BetterBurnTime was the same way.  The new-and-improved stock indicator assumes a 50/50 split by default, but has a setting that allows you to change that to whatever other percentage split you want-- but it doesn't tell you what percentage to use, that's backwards.  You tell it.

So, the short answer to your question is:

• No, BetterBurnTime has never done this
• Nor has the stock indicator
• There's no math for deciding this because "more accurate" isn't really a defined thing, here
• Basically everyone just does a 50/50 split, because that's simplest and it doesn't actually matter much anyway , as long as the burn isn't really long
• If the burn is really long, that's going to be inaccurate no matter what you do-- better to split into multiple burns, e.g. periapsis kicking

If you want to look at code for making automated decisions about burns, I'd suggest having a look at whatever MechJeb does, but since I've never used it myself, I'm in no position to vouch for how sophisticated it is (or isn't) about this sort of thing.

Agreed, mechjeb also does 50/50 burn start time.  Simple explanation without going into vectors is you need to start the burn halfway before the total length of the burn to balance out your change in direction with your change in speed to end the burn at the right direction and speed.

Edited September 1, 2022 by Xt007

[se5a]

I was under the impression that you needed to start a bit earlier than 50/50 due to higher t/w at the end of the burn than at the start.

I swear I remember a mod that took that into account. maybe it was another mod, maybe I'm misremembering.

Edited September 2, 2022 by se5a

[Snark]

3 hours ago, se5a said:

you needed to start

Define "needed".  Needed this to accomplish ... what, exactly?

Also, note that the new stock indicator's percentage is based on dV and not time.  If you leave it set to the default "50%", that means "50% of dV before the node, and 50% afterwards".  If it's a 1000 m/s burn that will take 1 minute total, the stock indicator (set to 50%) will give you a burn start time that will burn 500 m/s (and not 30 seconds) before the node time.

Which sounds to me like what you want?

[se5a]

Ah yes, half the dV, should have realized that myself. Thanks, that's what I needed.

Edited September 2, 2022 by se5a

[Bizobinator]

Hello! I'm loving the mod!

I was wondering: is there any way to make this work with Kerbal R&D? It's a mod that lets you spend science to upgrade various aspects of in-game parts. I've noticed that the calculations seem to be using the stock/unimproved parameters of my upgraded engines. Would that be something KR&D would need to address?

Either way, I'm loving this mod ^_^. Thank you so much for making it!

[Snark]

On 10/2/2022 at 10:27 AM, Bizobinator said:

Hello! I'm loving the mod!

I was wondering: is there any way to make this work with Kerbal R&D? It's a mod that lets you spend science to upgrade various aspects of in-game parts. I've noticed that the calculations seem to be using the stock/unimproved parameters of my upgraded engines. Would that be something KR&D would need to address?

Either way, I'm loving this mod ^_^. Thank you so much for making it!

Thanks, glad you're liking it

I have no idea what's going on here-- there are several possibilities.

One question:  This discrepancy you're observing (where the stock/unmodified numbers are displayed):  Is this something that affects BetterBurnTime only, or does it affect the stock burn time as well?

To be clear:

• The stock burn time is what's displayed for maneuver nodes.
• The BetterBurnTime display is there for target intercept, time to impact.

There may or may not be something that Kerbal R&D would need to address... and there may or may not be something that BetterBurnTime needs to address.  Hard to say for sure, yet.  The above question should hopefully narrow that down a bit. 

The BetterBurnTime code that does these calculations is located here.  It relies on ModuleEngines.ThrustLimit() and ModuleEngines.realIsp for calculating the numbers.  If Kerbal R&D is doing something to the engine that changes the thrust and/or Isp, but is somehow not updating the above two quantities, then that would explain this discrepancy.

Whether fixing  the discrepancy would require an update on KR&D or BBT remains to be seen.

[Siphon]

Not sure if I am missing something obvious here but I can't seem to find a way to modify the scale of the UI

[Snark]

On 4/22/2023 at 9:43 PM, Siphon said:

Not sure if I am missing something obvious here but I can't seem to find a way to modify the scale of the UI

Nope, there isn't one.  A Unity UI programmer, I am not.  The UI that the mod adds just basically "clones" an existing piece of UI, and doesn't do whatever-it-might-need-to-do to respect UI scaling, because frankly I have no clue how to do so and don't have the many hours of spare time to investigate by trial-and-error.

Once upon a time, many moons ago, someone pointed out the UI scaling issue, and I spent a day or two delving into it and trying to play around with the various UI transform objects I could find, and nothing seemed to work, so I just gave up.  If anyone ever solves the problem and can present me with the correct, bug-tested code on a platter, then I'd be happy to look into incorporating it; but until and unless that happens, I don't have the time or energy to investigate the matter further myself.