Why isn't delta-v exposed in Stock (yet)?

[OHara]

10 hours ago, Laie said:

This topic isn't new... the last time I recall where someone from Squad bothered to step in and give a reply, it was that they were afraid of sometimes getting it wrong.

That might be the answer (to the question in the title of this thread).  I see speculation in the forum that this is the reason schmelta-vee didn't appear in 1.0 in 2015 but could not find anything direct from Squad.  It is easy to imagine that programmers started on it and got hung up on edge cases.

Looking through the threads for mods KER and Basic-deltaV, there are not too many complaints about miscalculation, more questions clarifying the interface.. The modders never[*] needed the "just a mod" excuse. (* I know, dangerous to make an absolute statement regarding such a long-discussed mod.)   KER did need the excuse "need time to figure out internals" with the new fuel-flow in KSP version 1.2.

6 hours ago, sevenperforce said:

What if you have a single stage that has two different propellant types in parallel? The most efficient thing to do is burn your lower-ISP propellant up first, of course. But if you designed your stage with two different propellant types, you probably had a reason for doing so, one which involved using specific propellants at specific times, which will make your stage's propellant usage (and thus its total dV) lower than the most efficient case. The stock dV meter has no knowledge of when or how you will do this, of course. If it aims for the worst-case scenario, it'll be wildly wrong; if it aims for the best-case scenario, it'll be wildly wrong. Either way, it doesn't work.

That is the situation, though, where dV calculations go from tedious to interesting for the player. 

Several times I have rearranged staging or disabled engines to show KER how I'm using some stages, and let KER do the tedious part for me.   If the in-game dV calculation is obviously simplistic, following the principle of least surprise, then the player can use it as a tool for the interesting cases.

[LameLefty]

5 hours ago, HebaruSan said:

Makes me wish I had finished my American Kerbal Engineer patch:

Why do you have "MPH" as your unit of measure for dV? To an American engineer, "feet per second" would be a much better measure. Ditto for your absurd units of mass. Decimal "pounds-mass" (*) would be perfectly understandable and eminently easier to code. (**)

 

(*)DISCLAIMER: Yes, I'm aware of the absurdity of "pounds-mass" but having earned my aerospace engineering degree in a US college in the 80's, and having wrestled with the ridiculousness of the "slug" as a unit if mass, I think I should get a pass here. (**) I'm also aware your patch idea is generally supposed to be a joke. 

[Gargamel]

5 hours ago, GoSlash27 said:

 

wumpus,

 The math gets a little more complicated, but not terribly so. spreadsheets work for parallel staging schemes just as well as asparagus or series.

Best,
-Slashy

 

I like to fly my ascent profiles to a set max of 20 m/s/s.  So my boosters are increasing their TWR as they burn , and the main engine throttles back to maintain that acceleration rate.  I can't imagine the spreadsheets for this one.  My calculus is 25 years too rusty. 

@HebaruSan That's gorgeous.  And people don't understand the problems with the imperial system.... sigh....

@everybody in this thread:  I'm really impressed to see this thing go 5 pages, with people on polar opposites of opinions, yet everybody has shown a "Yeah I can get behind that idea" attitude, even if they don't agree with it.  Some very educational posts here.  Nominate this one for TOTM. 

[Superfluous J]

47 minutes ago, Gargamel said:

I'm really impressed to see this thing go 5 pages, with people on polar opposites of opinions, yet everybody has shown a "Yeah I can get behind that idea" attitude, even if they don't agree with it.  Some very educational posts here.  Nominate this one for TOTM.

Hear, hear. Nice change after the recent popular threads around here.

I'm not a programmer but I wonder how easy it would be to detect these edge cases and for them display a number with a star, and a hover tooltip or something that says "You're doing something here I don't understand, so this number may not actually be all that helpful. Proceed with caution!"

[Ace in Space]

55 minutes ago, 5thHorseman said:

I'm not a programmer but I wonder how easy it would be to detect these edge cases and for them display a number with a star, and a hover tooltip or something that says "You're doing something here I don't understand, so this number may not actually be all that helpful. Proceed with caution!"

Speaking as a programmer:

You can never detect all the edge cases. You can probably come close if you set "I don't know what you're doing" as the default state and then only show things if you've established that you do know what they're doing... but some edge cases would probably slip through under one of the "good" categories.

[GoSlash27]

1 hour ago, Gargamel said:

I like to fly my ascent profiles to a set max of 20 m/s/s.  So my boosters are increasing their TWR as they burn , and the main engine throttles back to maintain that acceleration rate.  I can't imagine the spreadsheets for this one.  My calculus is 25 years too rusty. 

Gargamel,

 The problem, at least with my pedestrian spreadsheet skills, is that I can only predict results for relatively simple cases. "If I want a single stage with a known payload, a desired DV, under specified conditions, and a desired minimum acceleration, what would it look like if I used this engine?" I can solve that problem with a spreadsheet because there are only 28 engines in the game. I can solve it for all engines simultaneously, then compare and contrast the results for all engines and pick the stage design that best suits my needs. It's a very powerful engineering tool because it's telling me what I should be building instead of merely modeling what I have already built.

 If I move into more complicated staging arrangements with multiple engines firing simultaneously, the possible combinations become infinite and I am no longer able to predict a single best case. All I can do is model the behavior of a single design, which is what MJ does. In that case, MJ is superior. It can predict how a specific stage will perform based on what I have assembled in the VAB in real time, requiring no inputs from the user other than building the rocket. Sometimes it will get it wrong, but no more wrong than any other method...

 I can still have spreadsheets that mimic what MJ does, but they are less efficient because I am forced to effectively build the stage twice; once in the VAB and once in the spreadsheet.

In the case of your problem, I have to constrain myself to the condition of the pilot not throttling back the LF&O engine until after staging. I "throttle" the SRBs to provide acceleration limits by having them burn out at predetermined times. No spreadsheet (or mod for that matter) can predict how a rocket will behave if the throttle setting is altered after launch.

Best,
-Slashy

 

 

[TheFlyingKerman]

 I sort of understand the difficulty calculating the delta-v of a ship perfectly. How about just adding a simple calculator,  not so different from calculating by hand? Say one enters the engine(s) used, how much fuel is available, and at what environment they are being used (Space of ASL of Kerbin, Eve...). The calculator reads out the dry mass from the design and displays the delta-v, assuming all engines burn at the same time at max thrust.

[severedsolo]

@GoSlash27 Your spreadsheet sounds interesting. Sounds similar to the Rocket Design Calculator (which I'll admit to using sometimes when my limited imagination cant design a lifter to get the abomination I'm trying to launch to orbit), Don't suppose you'd share it?

[NoXion]

Being able to tell how much delta-V a rocket has made me better at rocket design. I'm not too bothered by the lack of such a readout in stock because I'm more than happy to use mods, but this idea that having less information somehow makes one a better rocket designer just makes absolutely no sense in my experience.

[Just Jim]

Quite simply, I don't want KER in my game... sorry. I would only support something like this if it came with an off/on setting, so it wouldn't ruin my fun.

I much prefer just doing it the hard way... or using one of Slashy's spreadsheets. 

[Spartwo]

1 minute ago, Just Jim said:

Quite simply, I don't want KER in my game... sorry. I would only support something like this if it came with an off/on setting, so it wouldn't ruin my fun.

I much prefer just doing it the hard way... or using one of Slashy's spreadsheets. 

That on/off setting should toggle the d/v meter in maneuver nodes too.

[Just Jim]

1 minute ago, Spartwo said:

That on/off setting should toggle the d/v meter in maneuver nodes too.

Yes... I can see this. Agreed.

[GoSlash27]

11 hours ago, severedsolo said:

@GoSlash27 Your spreadsheet sounds interesting. Sounds similar to the Rocket Design Calculator (which I'll admit to using sometimes when my limited imagination cant design a lifter to get the abomination I'm trying to launch to orbit), Don't suppose you'd share it?

severedsolo,

 I have a tutorial floating around explaining the math behind the spreadsheet.

https://forum.kerbalspaceprogram.com/index.php?/topic/122722-how-to-mathematically-design-stages/&tab=comments#comment-2221326

All you have to do is run through this process for all engines simultaneously. You would have a global input panel to input the DV, payload, reference body, parent body, and max/ min atmospheric density.

 You then solve for a single engine type, and copy/paste for other engines. I recommend doing the crunching on another page so as not to clutter the UI.
 The answers can then be displayed for all engine types on the UI page.

Just plug in what you want to do in the yellow boxes, and the results are displayed below.

I really prefer to teach others how to do the math instead of putting copies of my spreadsheets out there for a whole laundry list of reasons, but this should help get you started.

Best,
-Slashy

[MR L A]

On 12/03/2018 at 3:41 PM, dlrk said:

They choose not to, for some unfathomable reason.

Because they aren't essential. At all.

The lack of KER or KAC is much more unfathomable, especially considering they're both a lot easier to implement. 

Also your comment about "if a modder can do it, why not Squad" seems a little condescending towards Ferram4 and modders in general. You seem to be implying that there hasn't been a hellish amount of work put into FAR and that it is somehow easy to create AND that Ferram4 is not a highly talented and patient modder. Besides, FAR is an improvement on something KSP already has and, as it stands, neither KER nor KAC have ANY stock equivalents. 

[dlrk]

Just now, MR L A said:

Also your comment about "if a modder can do it, why not Squad" seems a little condescending towards Ferram4 and modders in general. You seem to be implying that there hasn't been a hellish amount of work put into FAR and that it is somehow easy to create AND that Ferram4 is not a highly talented and patient modder. Besides, FAR is an improvement on something KSP already has and, as it stands, neither KER nor KAC have ANY stock equivalents. 

Uh, you've got that totally backwards. It's incredibly impressive what Ferram4 et al have done. The point I was making is that Ferram4, for example, has proven that any claim Squad may make that realistic aerodynamics are impossible is wrong, like their previous claim that a realistically sized solar system is impossible.

Implement KER is, IMO, just as good as implementing MJ (given the reticence of Squad to include a true autopilot). It just didn't occur to me as an example because I haven't used it in a while.

At the bottom line, at least something like KER should be implemented.