Why does changing focus zero out burn times?

[Pthigrivi]

This has been an annoyance so long I'd almost stopped noticing it, but why do you have to throttle all the way up for KSP to calculate burn times in maneuver nodes? Shouldnt it know/assume you will be firing at full throttle and base the burn time on that? Even weirder, it gives burn time estimates after you throttle, and then forgets them if you leave and come back to your ship. 

Maybe there's a mod that fixes this. Since I started playing like 5 years ago I just do a calibration burn every time. Seems crazy we have to do that. 

Edited December 9, 2017 by Pthigrivi

[stibbons]

4 minutes ago, Pthigrivi said:

Maybe there's a mod that fixes this.

That mod would be Better Burn Time. 

If you read through @Snark's comments in that thread, you'll find they have a fair bit to say (as usual  ) about the problems with trying to calculate decent burn times, and some speculation on why the game currently behaves the way it does.

 

Edited December 9, 2017 by stibbons

[Pthigrivi]

There it is! Im off to read the thread, but it really seems like much of this should be stock. We need this and basic dV way more than we need new parts. (Also KAC, precise node, docking port allignment... )

Edited December 9, 2017 by Pthigrivi

[Spricigo]

1 hour ago, Pthigrivi said:

 We need this and basic dV way more than we need new parts.

That is why I have a lot of mods and very few extra parts.

[Snark]

4 hours ago, Pthigrivi said:

This has been an annoyance so long I'd almost stopped noticing it, but why do you have to throttle all the way up for KSP to calculate burn times in maneuver nodes? Shouldnt it know/assume you will be firing at full throttle and base the burn time on that?

Yep, it bugged me too, which is why I wrote BetterBurnTime. 

FWIW:  I suspect that the reason that the stock indicator isn't better than it is, is that this is a surprisingly hard problem.  When I set out to write BetterBurnTime, I thought (naively) "well, this is so simple, I mean obviously you just do such-and-such.  I'll write a mod, it'll be quick and easy!"

Well, it turns out that it... wasn't.  Lots more discussion about this here and here, but what it boils down to is that "this is a problem which seems simple, but is actually a lot harder than you'd think."  It's a lot of code.

That doesn't mean that they couldn't make it better in stock-- I mean, hell, if I can write BetterBurnTime, certainly they could do a better job than me.  Rather, I suspect it's simply one of those things they never got around to doing, because it would be a large investment of effort for a (relatively) small return, and other stuff was higher priority.

4 hours ago, Pthigrivi said:

Even weirder, it gives burn time estimates after you throttle, and then forgets them if you leave and come back to your ship.

Actually, I think this is the one aspect of the stock burn indicator that I think would be trivially easy for them to fix, if they wanted to.  The important thing to understand about the stock indicator is that it's not predictive, it's historical.  BetterBurnTime works by analyzing the ship and predicting what it can do.  The stock indicator doesn't do that at all.  All it does is remember "how much did the ship accelerate the last time it burned" and then just does simple math with that number.  That's why you get N/A until you bump the throttle.

This aspect where it "forgets" if you leave and come back to the ship:  that's really simple.  It means that they don't store the "last burn acceleration" with the ship when it gets saved.  That would be an easy thing to fix, if they wanted to.  Whether it would be a good idea or not, I dunno.  I can think of occasions in which it could actually be kinda misleading and/or distracting, in a way that would generate more bug reports and unhappy players than if they just left it alone.

Anyway, just my two cents. 

[Spricigo]

11 hours ago, Snark said:

That doesn't mean that they couldn't make it better in stock-- I mean, hell, if I can write BetterBurnTime, certainly they could do a better job than me. 

A point can be made that they don't even need to make it better. The could just contact you and try a license agreement.

[Snark]

8 hours ago, Spricigo said:

A point can be made that they don't even need to make it better. The could just contact you and try a license agreement.

Oh my goodness, heavens no.  Not even vaguely.  That would never happen because (speaking both as a KSP mod author and as a professional software engineer, here) it would be a really, really bad idea from Squad's perspective.

A fairly common type of discussion that pops up in the forum from time to time is of the form "Mod X should be stock."  And there's nothing wrong with that, but it's important to understand what that means.  Because when one says a mod "should be stock", there are two completely different ways to interpret that statement, with completely different implications.  One of those ways is sensible.  The other is not.

Here's what makes sense to say:

"I love the functionality of this mod.  The stock game should have functionality like this.  I wish that Squad would implement a feature just like this mod.  They should spend the same amount of time, money, and resources that they'd spend to implement any new game features.  Yes, it will take them weeks or months-- far longer than a mod author would take to bang out something similar, of course, since shippable code has to play by much harsher rules than mod code and therefore has a harder problem to solve.  And it means that they'll have to give up other features that they would have implemented instead, because they're spending time on this thing.  But I'm fine with that, because I really really want behavior like this mod in the stock game."

Here's what makes absolutely no sense at all to say:

"What's the big deal?  This is great, and the functionality is already here!  I don't see why Squad is so slow to add new features. Hell, a single guy can bang out this mod in a couple of weeks!  They must be incompetent or slow or something.  Anyway, they don't need to write it because it's already written.  They should just buy or license the mod from the mod author, perhaps sand off a rough edge or two, and just stick the actual mod code into the stock game!"

And yet, even though that second statement is completely nonsensical... I hear it all the time on the forum, such as just now.  But it simply makes no sense.

So... why does it make no sense?  And if it's such a bad idea, why do intelligent, reasonable forum members keep bringing it up?

Welllllll... I honestly can't say I blame you or anyone else on the forum for suggesting this, if they're someone who doesn't do this for a living.  There are good reasons why that second idea is a bad one; but they're reasons that aren't obvious to the layperson.  After all, the mod looks great, right?  And it does exactly what we want, right?  And it's right there, right?  And it's really easy to put it in-- look, I just unstalled it in a couple of minutes, it's just a matter of copying a couple of files into my GameData folder!  So why not just do it?  Easy-peasy, right?  Just make it so that when I buy the game, it just inserts that same thing there!

That all sounds completely reasonable and obvious, and I can't blame anyone for thinking that.  The problem is, software engineering doesn't work that way.  To write code... and test it... and ship it... and sell it... and support it... and maintain it...  well, those are just a few of the things that a company like Squad has to worry about, and all of them are absolutely vital, and all of them take time and energy from trained professionals.  And most of these things are completely invisible to the customer, i.e. players like you and me.

And the very idea of "take some mod somewhere and just bung its code into the stock game" would cause nightmares for an awful lot of those invisible disciplines.  I could blather on for pages and pages about the technical specifics of it, but I'm guessing that those specifics would be boring to anyone who's not a software engineer.  (And to anyone who is a software engineer, you know it already.) 

But I can summarize it down like this:

Trying to actually take a mod and put it into the game is essentially trying to fit a square peg into a round hole.  It doesn't fit.  Yes, as with anything, with enough effort you could make it fit.  Get out your sander, sand off those edges, put lots of effort into making everything line up so that the peg fits into the hole.  Sure, it can be done.  But it's not easy and it takes a lot of work, and it's highly likely to cause other problems which in turn require more work.  So much work, in fact, that it's a much better idea just to create a new peg from scratch that's designed to fit the hole, than to try to take an existing one and reshape it to fit.  The reason people keep thinking it's easy and keep suggesting "why not just license the mod and put it in" is because they vastly underestimate the work needed to reshape the peg to fit into the hole.  It's not their fault-- they simply can't see that the peg and the hole are very different shapes, because for anyone who doesn't do this for a living, most of the shape differences are invisible.

Or, to summarize the summary:   Mods ≠ shippable code. 

(By the way, in the above rant, I'm specifically talking about plug-ins, i.e. mods that change game behavior via code.  If you're talking about a parts pack, the calculus is very different.  It would be much, much easier for a company to buy/license a set of parts and integrate those into the game, if they were so inclined.  So to anyone who's thinking about the "but what about all the Mk2 parts from Spaceplane Plus" discussion:  it's apples and oranges. Not the same kind of situation at all.)

[stibbons]

12 hours ago, Snark said:

Mods ≠ shippable code.

I'm pretty sure I can count the number of plugin mods that have >0 test coverage on one hand.

[NSEP]

This bothers me sometimes and i do think it has to be fixed. Glad betterburntime exists.

Also, wouldn't it be nice for KSP to calculate the best time to start the burn and put that in the countdown too? I usually wait till t-half the total burn time.

[Corona688]

On 12/9/2017 at 9:15 AM, Pthigrivi said:

This has been an annoyance so long I'd almost stopped noticing it, but why do you have to throttle all the way up for KSP to calculate burn times in maneuver nodes?

Because it calculates burn-times -- and everything else - from the raw acceleration of your ship, not the layout of your engines.

This makes it somewhat idiot-proof in a blunt way.  You don't need 13 control toggles to tell it whether you want to estimate main engines, RCS thrust, or aerobraking.

It doesn't give a fig about your control PoV, either, which all too often makes it the first indicator of faulty controls.  I'd hate to lose that.

On 12/9/2017 at 9:15 AM, Pthigrivi said:

Even weirder, it gives burn time estimates after you throttle, and then forgets them if you leave and come back to your ship.

Probably related to control PoV changes.

[Pthigrivi]

All good info. Thanks, guys. I still tend to think its worth patching something like this for smoother, more intuitive play. Its another one like dV, seems like a really critical piece of the gameplay that's been left out, but I do get that its more complicated than it immediately appears. God, console folks, how do you live?

[Pthigrivi]

I'll also add Better Burn Time is brilliant. Thanks, @Snark!