Properly working burn time indicator

[Gaarst]

Title. Broken since whenever manoeuvres were added, and already solved by several modders.

I'm genuinely surprised this isn't brought up more often. A reminder now and then is necessary it seems.

Edited May 12, 2017 by Gaarst

[Waxing_Kibbous]

This is a pretty important fix, I can't imagine playing without better burn time. I remember when I first started playing this was a big source of confusion and frustration.

[Pthigrivi]

Yeah seriously how is this still a thing?

[regex]

I endorse this message.

[qzgy]

Yes, please fix the burn time indicator. Code has been made, showing better burn times are possible.

[passinglurker]

I support this

[NSEP]

Better and more precise burns are my dreams, my orbits are always of by at least 25KM

[Alshain]

I don't understand how this hasn't been fixed yet.

[DeltaDizzy]

If i don't use better burn time, it's mechjeb's fault.

[HebaruSan]

Is it on the bugtracker?

[IncongruousGoat]

1 hour ago, HebaruSan said:

Is it on the bugtracker?

I don't think it qualifies as a bug, since the current burn time indicator isn't an unintended result of code. The implementation itself is just... crude. I would say that Squad hasn't improved the indicator because they're afraid they can't make it accurate enough (think drop tanks, staging mid-burn), but the current state of the indicator throws that theory out the window.

I'm frankly very surprised no dev has, at any point throughout KSP's development, taken a couple of hours to sit down and work out a better burn time indicator. There must be some complication I'm not thinking of, but nothing comes to mind.

[HebaruSan]

14 minutes ago, IncongruousGoat said:

I don't think it qualifies as a bug

But is it on the bugtracker? The bugtracker is not limited to bugs only---there's a Feedback option you can use instead. That's the only means available to us to put things on SQUAD's radar. Otherwise they either don't know it's important to anyone or they might even forget it entirely.

[Blaarkies]

56 minutes ago, IncongruousGoat said:

...they're afraid they can't make it accurate enough (think drop tanks, staging mid-burn), but the current state of the indicator throws that theory out the window.

Better burn time doesn't account for droptanks either, but we are ok with that. Even the landing indicator is not a suicide burn measure, but we KSP players find a way 

[The Flying Kerbal]

Burn times can be a right pain.

My rather crude fix for this is to hit F5, fire up the engine(s) until I get a readout telling me how long the burn will take, then hit F9 and revert back to the game before going through this rigmarole.

It's not perfect... it doesn't help if I have to stage mid burn for example, but it does help in a number of situations, such as if the entire burn is being made with a previously unfired engine or I've switched vessels.  It's not really the answer though and it would be nice if this issue was fixed at some stage.

[Streetwind]

Yeah, honestly, just stockify BetterBurnTime and call it a day... if @Snark approves, anyway  

[DualDesertEagle]

Seriously, that issue is still there today??? I'm still stuck with 1.02 so I can't check for myself, but if this problem is STILL THERE x-hundred versions ahead of mine then it's about effin' time it gets fixed! I'm looking towards re-buying the game after all so I'm up to date at least for a short period of time (should my problem occurr again) and by the time I can finally do that (still waiting for refunds of my never-arrived gaming PC) I'd like to see this fixed!

[rudi1291]

6 hours ago, HebaruSan said:

Is it on the bugtracker?

Yes. Several times, but this seems to be the oldest (and probably the only one on the main tracker) http://bugs.kerbalspaceprogram.com/issues/1456

And i agree that its a issue. The current implementation just makes accurate burns very hard to do....

Edited May 23, 2017 by rudi1291

[Alshain]

4 hours ago, Streetwind said:

Yeah, honestly, just stockify BetterBurnTime and call it a day... if @Snark approves, anyway  

No offense to Snark, but I would prefer the Kerbal Engineer math applied to the stock GUI.  Better Burn Time is a good mod but it is more crude than KER.  Engineer is accurate across stages with different engines, as long as you aren't asleep at the keyboard and stage at the proper time.  Due to human response time it's maybe a second or two off but that's not enough to matter really.  Meanwhile BBT just gives you notice that it doesn't really know because you don't have enough dV in the current stage. This is better than nothing but the math can be done to calculate how much time will be on the remaining dV in the stage and then progress to the next stage and calculate the remaining time using that engine.

[regex]

46 minutes ago, Alshain said:

This is better than nothing but the math can be done to calculate how much time will be on the remaining dV in the stage and then progress to the next stage and calculate the remaining time using that engine.

This requires a proper delta-V calculator (actually the iterator that makes it work) which is why we're not likely to ever see it in the game.

Edited May 23, 2017 by regex

[Alshain]

6 minutes ago, regex said:

This requires a proper delta-V calculator (actually the iterator that makes it work) which is why we're not likely to ever see it in the game.

I don't think it's that impossible to happen.  Whether it's on the screen or not delta V is being calculated somewhere in the game.

Edited May 23, 2017 by Alshain

[John FX]

I for one am not surprised that @SQUAD have not fixed a long standing bug in the stock game which would affect every player that uses a manoeuvrer node (100%?) but are trying to get us excited about a localisation update which will likely introduce bugs and a paid DLC which contains elements which should have been designed into the stock game from the start.

After years of introducing features which have the minimum effort put in to make the feature function, the users asking for a properly fleshed out well coded feature might be too much bother.

This is a danger when using placeholders in your software, after a while you regard that as an appropriate amount of work for a feature when it is not and real features require much more work than placeholders. Sometimes you just think `nobody has complained about the placeholder for a while, maybe we could just keep it like that?"

[Snark]

On 5/12/2017 at 7:42 PM, Pthigrivi said:

Yeah seriously how is this still a thing?

Treating this as a rhetorical question:  +1, I'm totally with you (and the other posters above) on this one.  Would love to see a better burn-time indicator in the stock game.

Treating it as an actually serious "why" question:  Probably because it's actually a significantly big chunk of work to do it well, so it just never got high enough up the priority list for Squad to bump some other feature to make it happen.  Calculating burn times is a lot more complicated than you probably think.

9 hours ago, IncongruousGoat said:

I'm frankly very surprised no dev has, at any point throughout KSP's development, taken a couple of hours to sit down and work out a better burn time indicator.

^ Tip:  It's a lot more than a "couple of hours". 

9 hours ago, IncongruousGoat said:

There must be some complication I'm not thinking of, but nothing comes to mind.

Lots.  I mean, astonishingly lots.  When I first set out to write BetterBurnTime, I was thinking pretty much the same as most people probably do:  "Well, this is stupid.  It's a simple piece of math, it ought to be a trivial fix."

I should just take an hour and write a mod to Do It Right™.  Heck, I'm a physics major, I already know the math, it should just be a simple coding job, right?

Well... yes, it's doable, but it took a lot more time than I expected, because there are a whole lot of issues that don't leap out at you until you go to actually code it.  Here's a post in the BetterBurnTime thread where I describe some of the complexities that reared their ugly heads, for anyone who may be interested.

And that's for the simple case, where (as I do in BBT) one chooses to completely ignore all staging and fuel-flow limitations.  If  you want to try to incorporate those, too (as KER does-- note Alshain's post above), then it really gets complicated (another BBT thread post discussing this).

Not that I'm defending the lack of a decent burn time indicator in the stock game.  I would love to have a better one.  Just... it's a significant chunk of work that includes non-trivial design choices, and doing it would involve making tradeoffs with all the other things also demanding the devs' attention.  So, having been a professional software engineer for a good long while and having seen the kind of ingredients that go into this peculiar sausage we call "software", it's not totally surprising to me that it could have kinda fallen by the wayside.  Regrettable, yes.  Surprising, no.

5 hours ago, Streetwind said:

Yeah, honestly, just stockify BetterBurnTime and call it a day... if @Snark approves, anyway

...and I'll assume from the tongue-smiley that the above is at least half-joking.  To be clear to anyone reading:  taking actual BBT code (or KER code, or any other mod code) for the stock game would probably be a bad decision, in terms of software development.  Mod code is not the same thing as core-product code; it's almost never the right choice to try to integrate a mod's code (unless it was written by the game developer in the first place, and specifically designed for later inclusion).  And in any case, if you were to want to integrate something... frankly, BBT's not a great poster child.  It was one of the first mods I wrote, when I was very new to KSP coding, and I did a lot of things that were kind of... awkward... simply because I didn't know any better.  I tidied up some of that stuff later on, as I learned more of the nuts and bolts of how KSP mods work; but there are other warts that are baked into the mod's DNA and aren't easily changed now.  If I had it all to do over again, it would be written more elegantly from scratch.  (And, speaking as a software developer, it still wouldn't be a good idea to try to just move it into the stock game.)

1 hour ago, Alshain said:

This is better than nothing but the math can be done to calculate how much time will be on the remaining dV in the stage and then progress to the next stage and calculate the remaining time using that engine.

Staging and fuel flow are really, really hard.  (Discussion here.) It's a big part of why KER is such a gargantuan, complex mod (easily at least ten times the code of BBT, which is itself non-trivial).  It's why BBT doesn't even try.  It's why having a delta-V calculator in the stock game has also been an elusive goal.

Again, not impossible, just... a really big design & coding job.

34 minutes ago, regex said:

This requires a proper delta-V calculator (actually the iterator that makes it work) which is why we're not likely to ever see it in the game.

^ Gotta say I tend agree with regex here.  Mainly because it appears (with the announcement of "Making History") that Squad is shifting resources away from core game development and seems likely to focus their time on expansions, going forward.  They're a business, they gotta pay the bills-- and at this point, I suspect that packing more big, expensive-to-develop features into the core game, for free, is unlikely to generate any revenue for them.  So at this point, alas, it's probably the right business decision for them not to.

Would love to be wrong about that, of course. 

28 minutes ago, Alshain said:

I don't think it's that impossible to happen.

Not impossible, but I suspect it's really unlikely, for the above reasons.

28 minutes ago, Alshain said:

Whether it's on the screen or not delta V is being calculated somewhere in the game.

Pretty sure it's not.  At all.  Even slightly.

I've seen no evidence in the game to indicate this, and I've also seen nothing in any of the modder-accessible APIs that I've tinkered with (and I've done that a lot, in the course of writing BBT).

Certainly there's nothing in the stock game that would require this-- the only reason to have calculations like that would be for displaying them to the user, for the user's convenience.

The game itself doesn't need any delta-V calculations.  Engines define their Isp and their fuel consumption rate.  You turn on the throttle, acceleration is applied as per thrust, fuel drains out.  When the fuel's all gone, the engine stops thrusting.  There's no concept of "calculate net delta V" there anywhere.

[kerbinorbiter]

that would be good however ill lead you with the equation

Max accelaration = Mass/Max thrust

burn duration =  Max Accelaration* Node deltaV 

burn time = Burn duration devided by 2

[Snark]

37 minutes ago, kerbinorbiter said:

that would be good however ill lead you with the equation

Max accelaration = Mass/Max thrust

burn duration =  Max Accelaration* Node deltaV 

burn time = Burn duration devided by 2

Which is exactly what the stock burn-time indicator (that everyone hates, which is what this thread is about) already does.

You're right, that's simple and quick.  Which is presumably why it got done that way.  But it has lots of problems with it-- see discussion in my post above.

[Gaarst]

30 minutes ago, kerbinorbiter said:

that would be good however ill lead you with the equation

Max accelaration = Mass/Max thrust

burn duration =  Max Accelaration* Node deltaV 

burn time = Burn duration devided by 2

If it was this simple it wouldn't be an issue.

 

@Snark I can understand that it's not a trivial piece of coding, but you and other modders (I don't who wrote the original KER dV/burn time calculator, which was probably refined anyway) did it in their free time. Squad should be able to do it themselves*. Polishing may not be the best decision from a business point of view, but I think the "it's too complex" excuse is not valid in this case (except when people claim it's just a couple operations).

Hopefully, after 1.3 and the expansion, 1.4 will be a polishing update solving these issues (yet another thing 1.4 (and all previous versions before they were released) needs to be).

 

* Plus, as opposed to modders, they have the possibility to change existing bits of code to (perhaps) make the task easier.

Edited May 23, 2017 by Gaarst