Should KSP have a Delta-V readout?

[AlamoVampire]

To whomever said you are not getting beyond kerbins soi with out a dv read out, look at my signature. Those ribbons represent various SOIs in ksp. I went to each without knowing my dv. Moho to eeloo . Manned to moho, duna, jool, eeloo, mun and minmus with probes to all bodies. That all being said, its almost beyond unfathomable basic information readouts are not stock. 

[Superfluous J]

13 hours ago, blorgon said:

I think the most satisfying trial-and-error aspect of the game is tweaking your design to meet certain mission specifications and personal goals, not wondering whether you'll have enough fuel to even get there.

If you're curious why I "Like"d your post, it was for this nugget.

As well said as I've ever seen it.

[r_rolo1]

20 hours ago, Plusck said:

Burn time estimates are often wrong because the previous burn was at reduced thrust. However it's a self-correcting system that ends up being more-or-less right within seconds. A dv calculation that is "stock" and supposed to be correct, but which only ends up being correct when you drop the last stage two years (game-time) down the road is going to get people - especially the noobs that you're trying to help - quite upset.

And I'm not saying there aren't unforgivable bugs in KSP as it is (such as, specifically, constant recalculations of orbits compounding rounding errors) - but within the limitations of the SOI system the orbital mechanics themselves are perfectly correct.

All I'm saying is (a) you don't need it to start with and (b) it gets increasingly wrong as you adopt more sophisticated strategies, so therefore it doesn't ever comply with the basic premise of what stock is supposed to be about. It's mod territory and rightly so (imho).

Well, on your a) ... well, I definitely don't need it, but I also don't really need manouver nodes, burn times, close aproach markers or even SoI change signaling since I learned the game before any of those things were even in the game at all ( and people earlier than me don't even need map view, since they learned the game when they had to do math to know they were in orbit  ). Other people mileage might not be as long as mine or yours, mind that  and OFC, not needing a thing is not the same as having that thing not being a plus

On your b) ... well, that is pretty much why I brought the burn time to the fray. As you said , the burn time calculator uses the max thrust of your map session to calculate your burn time ( that alone is problematic by itself, because it does not save the time to burn if I get out of map  session and go to the VAB or something, but that is not my point here ). That brings errors everytime your burn is made at diferent thrust than max session thrust, as you point, but ,unlike you assume the errors do not self correct ( they would only self correct if your thurst either flatlines at max thurst or if your thrust is ever increasing 100% of the times, hardly a certainty ). I also must point out that the game burn time is also increasingly not assuredely correct as your ship increases in complexity ( besides more engines being a source of more variable thrust levels, more parts normally also normally means more losses to mechanical deformations of the ship ), effects that are not taken in account in the stock burn time meter ... not mentioning that it doesn't care if you will have to actually stage in between the burn

My point in here is that it was SQUAD that lowered the bar in what is to be expected in terms of quality for stock. You can't drop something like the stock burn timer, that gives almost always bad answers and it gets worse with more complicated ships, leave it there basically unchanged for years, and then be all prude and saying that you don't want to make ( in case of the devs ) or want to have ( for the rest of the mortals ) a stock dV meter because you don't want to put in game a possibly inacurate dV meter that can get more complicated ships wrong. That is incoherent at best .

 

Edited May 22, 2016 by r_rolo1
you !=they :P

[Plusck]

21 hours ago, 5thHorseman said:

If you're curious why I "Like"d your post

Also curious why you would "like" a post that starts as a rant against other members of the forum generally and ends with personal insult.

11 hours ago, r_rolo1 said:

Well, on your a) ... well, I definitely don't need it, but I also don't really need manouver nodes, burn times, close aproach markers or even SoI change signaling since I learned the game before any of those things were even in the game at all ( and people earlier than me don't even need map view, since they learned the game when they had to do math to know they were in orbit  ). Other people mileage might not be as long as mine or yours, mind that  and OFC, not needing a thing is not the same as having that thing not being a plus

On your b) ... well, that is pretty much why I brought the burn time to the fray. As you said , the burn time calculator uses the max thrust of your map session to calculate your burn time ( that alone is problematic by itself, because it does not save the time to burn if I get out of map  session and go to the VAB or something, but that is not my point here ). That brings errors everytime your burn is made at diferent thrust than max session thrust, as you point, but ,unlike you assume the errors do not self correct ( they would only self correct if your thurst either flatlines at max thurst or if your thrust is ever increasing 100% of the times, hardly a certainty ). I also must point out that the game burn time is also increasingly not assuredely correct as your ship increases in complexity ( besides more engines being a source of more variable thrust levels, more parts normally also normally means more losses to mechanical deformations of the ship ), effects that are not taken in account in the stock burn time meter ... not mentioning that it doesn't care if you will have to actually stage in between the burn

My point in here is that it was SQUAD that lowered the bar in what is to be expected in terms of quality for stock. You can't drop something like the stock burn timer, that gives almost always bad answers and it gets worse with more complicated ships, leave it there basically unchanged for years, and then be all prude and saying that you don't want to make ( in case of the devs ) or want to have ( for the rest of the mortals ) a stock dV meter because you don't want to put in game a possibly inacurate dV meter that can get more complicated ships wrong. That is incoherent at best .

I didn't expect any real discussion of my point (a) about not needing it to start with. A new player - or any player for that matter - starting in career mode has a number of objectives for which delta-v is largely irrelevant. At the same time (for obvious reasons) a delta-v readout at this stage is most likely to be 100% accurate... barring unorthodox build strategies (such as explosive staging without using decouplers). So sure, it could be a plus.

For point (b) about it never being accurate (or more precisely, almost never being accurate and often being completely wrong, especially at the build stage), I don't see where there is any controversy in that observation.

I understand your comparison with burn time, but burn time is only ever an instantaneous measurement. I haven't looked at the code for Snark's better burn time mod to see how it does it (and therefore why the stock calculation is wrong), but I would assume that burn time is merely taking the last known value for acceleration and dividing the node's total by that value. That's what I mean by instantaneous: it doesn't pretend to measure anything about the ship as a whole, future TWR or anything like that.

Still, if you look into it more, burn time also indicates potential problems with a stock dv measurement. If you have KER's vessel window open, it gives current TWR and max acceleration at any given point in time. Divide your node's total by acceleration and you have a measurement of burn time, and KER usefully gives you "time to node burn" using those same figures.

However, that value can be completely wrong. To take a very basic and obvious example (with apologies for this being 1.0.5, but I've booted off an incompatible OS here):

Spoiler

KER thinks it'll require a 10s burn to execute this node, because it thinks I have an acceleration of 22 m/s. It also thinks I have a dv of 3800 m/s. It's obviously wrong.

The stock burn time, however, is more-or-less correct to think it'll require 5 minutes to execute the node, because it uses the last known value of actual acceleration. It therefore doesn't matter how oddly built the craft is: it indicates the real situation, right now, not a hypothetical value which assumes standard ship construction.

So while the stock burn timer obviously has its flaws, it doesn't fall for the logical flaw that KER (and I assume MechJeb) does.

And that same logical failing is bound to affect a potential stock dv readout.

To be really meaningful and helpful a dv readout has to indicate a value for each stage, but I suppose it could also just be a total. Whichever option is chosen, however, to be workable it has to either make assumptions about how a craft is built (which is the easy way, with little CPU overhead, like KER and MechJeb do it), or calculate the actual thrust by applying a physics model to the build (which would be a huge additional CPU load in the VAB/SPH), which basically leaves no real choice.

Therefore, a stock dv readout would be simple, correct and understandable for a simple and very standard craft. However, it would be wrong for any slightly odd build for all of the same reasons KER and MJ are wrong, and for the same reasons that stock burn time isn't.

[Padishar]

1 hour ago, Plusck said:

Also curious why you would "like" a post that starts as a rant against other members of the forum generally and ends with personal insult.

Actually, the way I read it is that it starts with several rhetorical questions (a long way from a "rant") about some other members of the forum who happen to be behaving in ways that don't make any logical sense and I can't see any personal insults, to you or any other member.

2 hours ago, Plusck said:

For point (b) about it never being accurate (or more precisely, almost never being accurate and often being completely wrong, especially at the build stage), I don't see where there is any controversy in that observation.

There is controversy because most users of KER/MJ manage to use it fine with considerably complex vessels and, when they do have an issue with it, they get advice on how to get it to give more useful results.

2 hours ago, Plusck said:

Divide your node's total by acceleration and you have a measurement of burn time, and KER usefully gives you "time to node burn" using those same figures.

However, that value can be completely wrong. To take a very basic and obvious example

First, you are describing how the stock burn time works, not the KER one.  The KER one uses the per-stage deltaV and burn time calculations to work out the burn time for a node.  As for your "very basic and obvious example", you have two opposed active engines and are obviously running with the "vectored thrust calculation" setting turned off so it is assuming the engines are all pointing in the same direction.  Try learning how to use your tools before claiming they don't work...

1 hour ago, Plusck said:

Divide your node's total by acceleration and you have a measurement of burn time, and KER usefully gives you "time to node burn" using those same figures.

As said above, this isn't how KER works.

2 hours ago, Plusck said:

So while the stock burn timer obviously has its flaws, it doesn't fall for the logical flaw that KER (and I assume MechJeb) does.

The logical flaw you are referring to is your own due to not using the tools correctly.

2 hours ago, Plusck said:

Therefore, a stock dv readout would be simple, correct and understandable for a simple and very standard craft. However, it would be wrong for any slightly odd build for all of the same reasons KER and MJ are wrong, and for the same reasons that stock burn time isn't.

You are making conclusions based on faulty premises.  You appear to be the sort of person who is convinced they know enough about a subject to make definite conclusions about it but, in reality, your level of knowledge is far below the required level.

[Plusck]

1 minute ago, Padishar said:

...You appear to be the sort of person who is convinced they know enough about a subject to make definite conclusions about it but, in reality, your level of knowledge is far below the required level.

Again, I don't see the point of the insults and gratuitous rudeness.

[Padishar]

49 minutes ago, Plusck said:

Again, I don't see the point of the insults and gratuitous rudeness.

There's nothing of the sort in my post and I resent the implication.

[KrazyKrl]

Yes we need a dV readout, this is rocket science. IMO not having a dV readout is against the spirit of KSP... as KSP is a game about rocketry and space travel.

 

On 5/21/2016 at 4:45 PM, Red Iron Crown said:

I should really write a tutorial on how to work around KER/MJ giving inaccurate numbers for complex mission profiles. It certainly can be worked around, by "simulating" the mission in the VAB through tweaking fuel tanks and connecting/disconnecting modules.

(-Snip-)

This would be amazing if your experience could be rolled into the KSPedia. "Our Kerbal engineers designed this calculator to help with vehicle design, but the computer might get confused sometimes with complex craft; here's some of their workarounds."

[r_rolo1]

14 hours ago, Plusck said:

For point (b) about it never being accurate (or more precisely, almost never being accurate and often being completely wrong, especially at the build stage), I don't see where there is any controversy in that observation.

I understand your comparison with burn time, but burn time is only ever an instantaneous measurement. I haven't looked at the code for Snark's better burn time mod to see how it does it (and therefore why the stock calculation is wrong), but I would assume that burn time is merely taking the last known value for acceleration and dividing the node's total by that value. That's what I mean by instantaneous: it doesn't pretend to measure anything about the ship as a whole, future TWR or anything like that.

Well, I described succintly what stock burn time does in the post you quoted, but I can obviously do it in more detail ...

First of all, you are half wrong, since the stock burn time is not necessarily a instantaneous measurement and it does not  use the current acceleration. What it does is to get the maximum acceleration you got in your current map session since your last staging event and use that for the burn time calculation. So the value the stock burn time is only right if you're at your max thurst all the time and will only self correct if your thrust is increasing ( if you don't believe me , just boot the game and decrease your thrust after creating a manouver node  ).

In other words, the current stock burn time, unlike you state, assumes stuff about your ship in the future: it assumes that you'll not stage during the burn and it assumes that you'll never decrease your thrust in between staging events. Those are quite heavy assumptions and the reason I brought it to this discussion. It was SQUAD that defined the level of what is to be expected in terms of gauge quality by doing the quite hacky burn time meter we have since manouver nodes exist and it is somewhat intelectually dishonest to pretend we have some kind of high quality bar for a dV meter when both devs and players have been OK with a low quality gauge elsewhere.that shares pretty much all the same potential issues a stock dV meter could have :/

[Gaarst]

15 hours ago, Plusck said:

I understand your comparison with burn time, but burn time is only ever an instantaneous measurement. I haven't looked at the code for Snark's better burn time mod to see how it does it (and therefore why the stock calculation is wrong), but I would assume that burn time is merely taking the last known value for acceleration and dividing the node's total by that value. That's what I mean by instantaneous: it doesn't pretend to measure anything about the ship as a whole, future TWR or anything like that.

Still, if you look into it more, burn time also indicates potential problems with a stock dv measurement. If you have KER's vessel window open, it gives current TWR and max acceleration at any given point in time. Divide your node's total by acceleration and you have a measurement of burn time, and KER usefully gives you "time to node burn" using those same figures.

This is just wrong, and somewhat insulting to the makers of these mods.

KER and BBT calculate burn time by taking into account the mass loss and acceleration of the craft. Which is exactly what the stock game doesn't do.

If you don't account for mass loss, the burn time you will get will be wrong, and this is especially important for "full stage" burns, ie: emptying a whole stage doing the burn, causing the TWR to more than double over the burn. Note that KER also accounts for the dV in the next stage if your current stage does not pack enough dV.

[Superfluous J]

17 hours ago, Plusck said:

Also curious why you would "like" a post that starts as a rant against other members of the forum generally and ends with personal insult.

I'll (mostly) leave this alone but I will say I pretty much agree with @Padishar's reply to it.

17 hours ago, Plusck said:

burn time is merely taking the last known value for acceleration and dividing the node's total by that value

I believe you are correct about this for stock, and this is why the stock burn time will - except in the extremely rare case where you stage midway through the burn so as to lower your TWR just the exact right amount to correct reality to the otherwise incorrect burn time value.

By your reasoning, stock should remove that timer, because it's almost guaranteed to be wrong. As are maneuver node predictions. They're never exactly correct, so get rid of them. Right? That's the argument you're making here.

I apologize if you take this as a personal insult. It's not. It's a thought-out response.

[Plusck]

 

 

10 hours ago, 5thHorseman said:

I'll (mostly) leave this alone but I will say I pretty much agree with @Padishar's reply to it.

I believe you are correct about this for stock, and this is why the stock burn time will - except in the extremely rare case where you stage midway through the burn so as to lower your TWR just the exact right amount to correct reality to the otherwise incorrect burn time value.

By your reasoning, stock should remove that timer, because it's almost guaranteed to be wrong. As are maneuver node predictions. They're never exactly correct, so get rid of them. Right? That's the argument you're making here.

I apologize if you take this as a personal insult. It's not. It's a thought-out response.

I don't see how what you wrote could possibly be taken as being insulting or rude. If you think I'm wrong about something, you say so and tell me why. You're not dressing it up in internet smack-down tough-talk, rant or anything else. So it is obviously fine. And I will do my utmost to respond in kind.

Still, if I tack a "get over yourself" to the end of my post it becomes instantly insulting, and I am finding it hard to see how you or Padishar don't see that. Maybe it's not a phrase you use for the express purpose of being insulting wherever you grew up.

But anyway, that's by the bye and largely irrelevant now.

 

We got a little side-tracked onto the stock burn time thing. While I fully agree that the stock burn time indicator could be a lot better, as I said it is a self-correcting thing. It isn't a perfect science but IMHO it does correspond to the basic KSP approach: you fire your engines, see that it pushes you with a given force in a given direction then extrapolate from that to work out your burn time.

KSP is, of course, a lot more accurate than that behind the scenes, but it seems to me that the whole point in stock game is to keep all of that behind the scenes. The huge and major concession to this principle is maneuvre nodes and intercept markers: when you plot a node it shows an exact orbit and not a fuzzy probability cone; if you have two orbits intersecting and 0.1km distance to target in 2 hours, then you will be 0.1km from your target in 2 hours (as long as you stay on rails).

My point about a stock dv readout being guaranteed to be wrong (except in very simple cases) was originally meant with reference to the big areas where KER (probably also MJ, but I think I've already been very clear about not having tried it) gets it very wrong. Staging with docking ports is the most glaring example. Drop-tanks was another glaring example in 1.0.5 but I haven't yet built anything which recreates the error in 1.1, so maybe it's been fixed.

So, as you rightly pointed out, there are things that are shown as being precise numbers even when they aren't, such as nodes and burn time. My point is not that anything like that should not be in stock, but that I see no need for stock to include any more of these "given as accurate but not really" elements than the absolute minimum. Maneuvre node predictions are absolutely necessary to make the game playable for going any further than the Mun. I don't think I need to spell out exactly why an estimated burn time is needed to play the game properly. Therefore I'm most definitely not arguing that they should be removed from stock. However, a dv readout is a list of numbers given as accurate, but which for a number of reasons will not be exactly accurate or even wholly wrong, and is not a necessary addition to be able to play the game.

Now obviously a dv readout becomes massively useful in the later game, but you need to use workarounds to get the right numbers in complex craft - adding temporary decouplers or fuel lines, or hiving off parts of the build while you manually switch Rapier mode, or whatever. And again, I really see no need for stock to add yet another element which needs workarounds to give the right result.

And - to come back to the burn time analogy - when KER or Snark's better burn time mod does give the right result, it's because they're running a relatively complex simulation of your craft. You're in a sim, running a sim on top of it. This is another point that I made several posts ago: it's either simple and probably wrong, or complex which means more CPU overhead. And therefore, again, I think that that qualifies it as being something for mods rather than stock.

 

14 hours ago, Gaarst said:

This is just wrong, and somewhat insulting to the makers of these mods.

KER and BBT calculate burn time by taking into account the mass loss and acceleration of the craft. Which is exactly what the stock game doesn't do.

If you don't account for mass loss, the burn time you will get will be wrong, and this is especially important for "full stage" burns, ie: emptying a whole stage doing the burn, causing the TWR to more than double over the burn. Note that KER also accounts for the dV in the next stage if your current stage does not pack enough dV.

The first bit you highlighted appears to be confirmed as more-or-less correct since I was talking about stock burn time (if you read the whole phrase, i was using "burn time" to mean stock and adding qualifiers whenever I was referring to the mods). As for the second part, I never made the slightest inference about Snark's BBT because I hadn't looked at it (and I said as much); having now read the blurb on the tin, it sounds like BBT does exactly as you say, which is great but means making assumptions and (like I said in the paragraph just before your post) means effectively tacking a sim on top of a sim. Regarding KER, it isn't very clear to me what it's doing. Enabling the thust vector simulation option certainly seems to force a more complicated sim that does what you describe, but with the option disabled (which I think is default and, in any event, has always been the case for me since I never build craft with engines facing in different directions) I got some odd results that I've only just had time to check again. I clearly misinterpreted the original results but the correct interpretation, while confirming what you say here, exposes further appoximations and limitations of the system.

Spoiler

You see here, KER appears to be simulating the stage as a whole. Thrust vectoring simulation is off (don't need it since only one engine running), but "Node burn time" assumes both engines are running.

1m25s later - stock burn time was out by about 20s. KER would have been accurate if it had realised that one of the engines wasn't running.

Switching on thrust vector simulation for KER in the VAB doesn't improve this result - until you start thrust-limiting the inactive engine.

So therefore - without meaning any insult to KER's developers since it is a mod and therefore makes no claim to be intuitive oreven useful in ordinary gameplay - KER cannot cope with one of the basic player tactics of shutting down engines unless you also limit thrust to 0% on that engine.

But still, this is all beside the point. KER and BBT give you the option to turn off some of their accuracy enhancements (and why would they do that if it isn't an admission that it can go wrong?), or make assumptions about how a craft is constructed. @Snark goes to great lengths to explain how his mod works and its limitations, which is great. KER makes zero effort to describe its processes and has no sort of manual other than a 120+ page forum thread and a changelog, plus the odd aggressive "learn how to use the tool" comments by one of its creators in here.

So, absolutely no insult possible about the creator of the BBT mod. Creators of the other mod can cherry-pick and misinterpret my comments as they see fit.

15 hours ago, r_rolo1 said:

Well, I described succintly what stock burn time does in the post you quoted, but I can obviously do it in more detail ...

First of all, you are half wrong, since the stock burn time is not necessarily a instantaneous measurement and it does not  use the current acceleration. What it does is to get the maximum acceleration you got in your current map session since your last staging event and use that for the burn time calculation. So the value the stock burn time is only right if you're at your max thurst all the time and will only self correct if your thrust is increasing ( if you don't believe me , just boot the game and decrease your thrust after creating a manouver node  ).

In other words, the current stock burn time, unlike you state, assumes stuff about your ship in the future: it assumes that you'll not stage during the burn and it assumes that you'll never decrease your thrust in between staging events. Those are quite heavy assumptions and the reason I brought it to this discussion. It was SQUAD that defined the level of what is to be expected in terms of gauge quality by doing the quite hacky burn time meter we have since manouver nodes exist and it is somewhat intelectually dishonest to pretend we have some kind of high quality bar for a dV meter when both devs and players have been OK with a low quality gauge elsewhere.that shares pretty much all the same potential issues a stock dV meter could have :/

I'm aware that stock burn time doesn't work too well at less than full thrust.

However you too are half-right (or should I say half-wrong? ). In that extremely simplistic example that I gave of a ship with opposing engines, disabling one engine and running at full thrust for a second gave a result very similar to what KER's estimate would have been if it had recognised the deactivated engine. Activating the engine and reduing thrust to 95% and giving another second's max thust bumped up the stock burn time estimate to several minutes. All this was without going back to KSC.

Therefore, a reduction in the "real" max thust of the ship does indeed cause the stock estimate to revise upwards. Therefore you're wrong saying that it "will only self correct if your thrust is increasing". However, I'm perfectly prepared to accept that odd results happen if you start throttling down.

I'm not trying to say stock burn time is great. That would be pointless and a bit daft. I was saying that it doesn't fall into the logical trap of making assumptions about how the ship is built, which can be wholly wrong.

I don't think it is fair to say that stock "assumes stuff about your ship in the future". There is a big logical difference between making no assumption and assuming things will not change. Do we "assume" that the sun will rise tomorrow or simply make no assumption whatsoever about the possible disappearance of the sun or halting of the earth's rotation? I'd go for the latter, personally. So for me stock makes no assumption whatsoever about your craft.

As for whether it might be "somewhat intelectually dishonest to pretend we have some kind of high quality bar for a dV meter", I couldn't disagree more. I have been extremely clear here that I have nothing at all against a dv readout, even a buggy and occasionally wrong one. I also have nothing against a better burn time indicator. The big difference is that the stock burn time indicator doesn't ever pretend to be wholly accurate. The fact that it always indicates nothing before you start up the engines when loading physics for a craft is a pretty huge signal to the player that it's an estimate. The fact that it then takes a while to settle for a number (with one of the in-game tutorials spelling out the fact that you need max thrust for a second for this purpose) is a further sign. I doubt that many new players really believe it to be precise, especially if they know they'll have to stage during the burn.  The limitations of the tool are self-evident. 

However, I don't see how a dv readout would be useful without purporting to be accurate, unless it gave a single figure in km/s for the whole build. That last option would have advanced players sneering at it, while still requiring all of the detailed calculations underpinning KER or MJ to get to that fuzzy number - in other words a complete waste of coding time and sim calculations. To be useful, the readout has to be per-stage which brings us back to the whole question of where to put all that information, and how to deal with the fact that it can be much less accurate than it appears. To analogize: you can't produce a detailed quote for a job with each item accurate to the dollar, then give a total that's "+/- $500" without specifying where that "+/-" comes from.

 

So to close off this inordinately long post, I still vote no to a dv readout in stock, for the exact reasons I gave in my first post. Civil dicourse has led me to correct a few of my later developments on the subject but have also exposed a further area (deactivating engines) where the mods get it wrong. Some mod authors are upfront about the limitations, others aggressively defensive. Irrespective of the reasons why they are inaccurate, the fact is that they are and that it is far from obvious and intuitive to work around their limitations. Therefore adding it to stock would add bugs and confuse noobs. A mod comes with an implied caveat emptor which covers precisely this sort of issue, so a mod it should remain.

[Padishar]

31 minutes ago, Plusck said:

plus the odd aggressive "learn how to use the tool" comments by one of its creators in here.

You have a very strange definition of the word aggressive.

KER usually calculates stages as they appear in the staging list.  When the currently active engines are not consistent with the staging (i.e. you have enabled or disabled any engine) then it calculates an extra "stage" using the currently active engines burning until they run out of fuel and then continues with the normal staging process.  There does appear to be a bug with the burn time, possibly because it isn't using this extra stage in its calculations or possibly because of something more involved.  I play very little KSP compared to most of the users of KER, I generally don't need to time burn starts with the extra accuracy that KERs calculations are supposed to give and I generally don't use vessels whose staging is set up in any way that is likely to cause problems for KER.  Now that I am aware of the issue it will be investigated (in the fullness of time) and probably fixed.

[Snark]

17 minutes ago, Plusck said:

But still, this is all beside the point. KER and BBT give you the option to turn off some of their accuracy enhancements (and why would they do that if it isn't an admission that it can go wrong?), or make assumptions about how a craft is constructed. @Snark goes to great lengths to explain how his mod works and its limitations, which is great. KER makes zero effort to describe its processes and has no sort of manual other than a 120+ page forum thread and a changelog, plus the odd aggressive "learn how to use the tool" comments by one of its creators in here.

So, absolutely no insult possible about the creator of the BBT mod. Creators of the other mod can cherry-pick and misinterpret my comments as they see fit.

Just wanted to hop in here, since the topic of BBT / KER came up, and responsiveness, and so forth.  Moderately long rant in spoiler section below, the gist of which is:  "Cut the KER guys some slack, they've got a harder problem than I do."

Spoiler

It's true that I put a lot of effort into explaining exactly how my mod works.  There are a couple of reasons behind that:

• Ego.  I'm proud of my own cleverness and like to share about it. 
• Self-defense.  The more effort I put into explaining it up front, the less effort I'll need later to soothe ruffled feathers from disappointed users who run into an unexpected limitation.

But my doing so is only because it's possible, which is not the case for KER.

Both reasons boil down to the fact that BBT is, at heart, a really simple mod that does one very simple thing.  Yes, it has complicated code behind it, but the interaction is simple:  "how much time to burn?"  Because it's so simple, I can explain it.  And even that extreme level of simplicity leads to a pretty darn long explanation in the mod's thread.  (Plus there's a third reason, which is that I'm an incredibly verbose person who likes the sound of his own voice and likes to write a lot.  But that's just me, and it would be unreasonable to expect anyone else to necessarily be like that.  I'm an outlier.)  And very few users get confused by it, precisely because what it does is so simple.

KER's a different beast entirely.

I have no association with KER, have never used it, have never followed its forum thread.  But I can say this:  KER is huge.  It's at least an order of magnitude more complex than BBT.  It does a lot.  It's not just that the internal code is complex:  what it does is complex, unlike BBT.  If you wanted to try to document KER to the same degree that I've done BBT, you'd have a freakin' tome.  Given the huge amount of effort to produce KER, I really don't expect that level of documentation from anybody.

Furthermore, KER not just a more complicated critter... it has an enormously huger player base.  I've been surprised and gratified at how popular BBT has turned out to be (it's by far my most popular mod)... but KER is vastly more so.  By a conservative estimate, it has roughly 1.37 bazillion times the user base that BBT does.  Look at the length of its forum thread.  BBT may be kinda popular these days, but it's still small enough that its forum thread can go weeks without anyone posting there, and I can personally and individually answer every single fan's every question, at length.  That's simply not possible with KER.  KER has a lot more users.  And each individual user is a lot more "expensive" to the authors, in terms of support requirements, simply because KER is so much more complex and it's therefore easier to run into confusion.

It's also been around a lot longer, and I'm sure the authors have run into plenty of really irritating users who really are schmucks who can't be bothered to try to figure things out for themselves.  I've never been in the position of having written a mod that big or that stupendously popular, so I can't say first-hand, but I imagine that such an environment would be a trifle wearing after a time.

So I have no idea what tone the KER authors take with their "public"... but whatever it is, I'd be inclined to cut 'em some slack.

 

48 minutes ago, Plusck said:

...have also exposed a further area (deactivating engines) where the mods get it wrong. ...Irrespective of the reasons why they are inaccurate, the fact is that they are and that it is far from obvious and intuitive to work around their limitations. Therefore adding it to stock would add bugs and confuse noobs. A mod comes with an implied caveat emptor which covers precisely this sort of issue, so a mod it should remain.

And this pretty much sums up my own take on it, with the addendum that it would be an expensive enough feature to add, that I'd rather the devs spent that time working on something else that gives more bang for the buck.  Seems like mod territory to me.

I'm not religious about it, and can totally understand the perspective of the folks who want a dV readout, so I won't be drawn into any arguments.  But my own two cents is that I don't think it belongs in stock.

[Superfluous J]

1 hour ago, Plusck said:

a dv readout is a list of numbers given as accurate, but which for a number of reasons will not be exactly accurate or even wholly wrong, and is not a necessary addition to be able to play the game

This right here is where you and I fundamentally disagree. dV numbers are as important to a successful space program as a toaster is to making toast.

EDIT:

And I'm going to bed right now so won't be able to reply when someone says "You can make toast without a toaster." So let me reply to that one now.

That's the point. You can, but it's a huge pain in the thing the filter here will probably turn into "donkey."

Edited May 24, 2016 by 5thHorseman

[Plusck]

1 minute ago, Padishar said:

You have a very strange definition of the word aggressive.

KER usually calculates stages as they appear in the staging list.  When the currently active engines are not consistent with the staging (i.e. you have enabled or disabled any engine) then it calculates an extra "stage" using the currently active engines burning until they run out of fuel and then continues with the normal staging process.  There does appear to be a bug with the burn time, possibly because it isn't using this extra stage in its calculations or possibly because of something more involved.  I play very little KSP compared to most of the users of KER, I generally don't need to time burn starts with the extra accuracy that KERs calculations are supposed to give and I generally don't use vessels whose staging is set up in any way that is likely to cause problems for KER.  Now that I am aware of the issue it will be investigated (in the fullness of time) and probably fixed.

Try learning to speak English before criticising people's choice of words.

I jest, though. I accept you don't think your post was aggressive or insulting. Please accept that I did, especially since it followed on from another poster who was most definitely trying to be insulting.

I also think there was some misunderstanding about my initial posts in here. I was not ever "complaining" about KER not working. I was forced to give ever more detailed examples of where things go wrong since some people appeared to be denying that there was ever a problem. I made a mistake about one of those examples and in relation to how KER's burn time indicator worked and that's where you jumped in.

And that example with the deactivated engine was in 1.0.5 - which I used simply because I was on the wrong OS the other day (Snow Leopard) and couldn't load up 1.1, and so I just used the same savegame for simplicity today.

The problem may have been fixed by now (as, I think, the dv issue with non-engine-bearing droptanks has). If it hasn't, I also noticed that the "Node dv" value varied as I varied the thrust limiter on the deactivated engine, so clearly it is based off the same calculation as the burn time. Again this is not a criticism or even a bug-fix request. If anything, it is merely a demonstration of the inherent difficulties that you run into if you try to produce this sort of data, which is all I was trying to say in the first place anyway.

And seriously, I was just kidding with that "try learning to do X before criticising Y" comment, it was just too good to pass up on the opportunity... ; )

1 minute ago, 5thHorseman said:

This right here is where you and I fundamentally disagree. dV numbers are as important to a successful space program as a toaster is to making toast.

The poll results are pretty clear about what most people think. I personally think my reasons are good reasons to keep it off stock, or completely rethink the question and presentation before considering it for stock, but I don't expect to convince many people (anyone?) who thinks otherwise. I'm also most definitely not trying to tell anyone how to play the game (well, actually I would advise a noob to stay off mods to start with, but that's another subject).

Indeed, dv numbers are essential for playing the game after a certain level. At the moment we have a choice between using a toaster (KER), grill (Excel) or open fireplace (paper and pencil)...

23 minutes ago, 5thHorseman said:

And I'm going to bed right now so won't be able to reply when someone says "You can make toast without a toaster." So let me reply to that one now.

That's the point. You can, but it's a huge pain in the thing the filter here will probably turn into "donkey."

Damn, didn't see this before pressing reply. Sorry to be so predictable :/

[Wjolcz]

On 5/21/2016 at 8:12 PM, blorgon said:

Missions are time-consuming. I'd be willing to bet that on even a Mun landing, a new player would get discouraged enough after playing for 20 minutes and discovering they can't get back off the Mun. I've had my fair share of times I spent hours getting somewhere and messed up because I didn't have enough fuel. If I weren't an utter space-nut, I'd have dropped this game in a heartbeat back in 2013 when I first started playing. The learning curve for non-science/engineering-oriented peoples is VERY steep. A delta-V readout would make it LESS steep. Get over yourself.

Same here.

[cfds]

@Plusck: Is your example not the classical case of "garbage in, garbage out"? KER deltaV readout is correct enough for most cases (and probably more correct than most of the displays in the engineer report).

I see no problem providing a display of the deltaV a rocket will provide assuming no Isp variances (be it throttling, disabling engines, changes in atmospheric pressure or designed cosine losses).
 

[Kerbonaut257]

I cannot even imagine why there is such large debate about this.

 

Kerbals DO have scientists. They DO understand calculations, masses, and thrust. The stock games gives you precise amounts for thrust, weight, and even ISP. If the kerbals can calculate ISP, surely they can figure out how must burn time you're going to get from an engine. (and from using this, along with start mass/end mass and the thrust of the engine, you get dV)

 

There's absolutely no reason not to have dV in the stock game. Any argument against it is obscure and grasps at straws. It's a useful feature for spacecraft. A new player doesn't need to know it, but they also won't be harmed by knowing it. It's not that confusing. It could be introduced in a tutorial just like manouever nodes.

 

Edited May 25, 2016 by Kerbonaut257

[herbal space program]

Although I certainly don't think it would wreck the game to have such a thing, I feel like the introduction of tweakable tanks and the mass readout in the engineer's report has made calculating it yourself in the VAB/SPH so easy that I really don't miss it that much. For the sorts of missions I'm doing, I like to keep  logs of dV expended/remaining at various points, so even if it were available I'd probably just keep using my spreadsheet anyway.  OTOH, way back before you couldn't get your full/empty masses in a matter of seconds, it really was a drag not having one!

Edited May 25, 2016 by herbal space program

[John FX]

Personally I tried playing EVE Online a long time ago and got bored with needing a spreadsheet to play a game. I`d rather not repeat the experience.

I support information readouts for the player.

To those who do not want them I suggest they be optional. If you truly don`t want them *you* don`t have to have them but don`t stop the rest of us having them...

[eberkain]

I was going to play the game with no mods at all, and I just can't get past the fact that there is no Delta-V estimation or TWR value for each stage.   The game is basically just trial and error with no real information to base your changes on.   More fuel, less fuel, more engines, less weight, SRBs vs Liquid...  i mean, there are so many different variables to play with when constructing a rocket, its ridiculously hard to try and get something accomplished without getting some kind of little feedback for what change your adjustments made.  I just want a strait answer for what the reason is for not including this information in the base game?

[Superfluous J]

It's really hard to get perfect, and if it's not perfect more people will complain about it being not perfect, than complain now about it being non-existent.

[Gilbershaft]

I may be wrong but I vaguely remember it being something about not wanting to make the game to easy. I'd bet that it will end up in the game sometime in the next year or so. I mean, correct me if I'm wrong but its not like Delta-V is not already in the game, its just on the back end and not displayed to the user. 

[kcs123]

I think it is pointless to discuss about this topic because it is already planed to include dV readings in stock game. If you can trust post in common suggestion thread.

Probably threre is good reason why it is not already included in game. like more important bugs to squeeze out before adding new feature in game. Just have to be patient until it become part of stock game and use MJ or KER mod until then.