I wonder why Squad doesn't want to give us a dV and TWR readout

[Hysterrics]

6 hours ago, Padishar said:

I'd like to think that people would read the thread before posting opinions that directly contradict Squad staff...

Regardless, I'd prefer it stayed out because that in it's own is also my opinion.

I'm sure I'll get lynched just by saying this, but whatever.

[pandaman]

11 minutes ago, Sequinox said:

Regardless, I'd prefer it stayed out because that in it's own is also my opinion.

I'm sure I'll get lynched just by saying this, but whatever.

Every opinion is a valid one.  The problems arise when we forget to respect that.

I happen to disagree with you, as it is a feature I think should be included,  but even then I would ideally want it optional for those that don't

[Hcube]

12 hours ago, 5thHorseman said:

To answer your subject line: No.

I can feel the debate progressing forwards

[r_rolo1]

Well, while I agree with the devs and the modders in this thread that a reliable dV meter is not exactly the easy task some people think it is, I do not believe that is the whole story. Unreliable gauges are not exactly uncommon IRL ( say the fuel gauge on almost all cars is dreadfully innacurate when the tank is either too full or too empty ) because , for better or worse a unreliable gauge is most of the times better than no gauge. In fact we have another unreliable gauge in game, one that spits out crazy numbers when it does not simply drop a N/A on you: the burn time ( and before you say that is a completely diferent cup of tea, notice that the modder responsible by the Better Burn Times mod said in this thread that the burn time was also whoefully complicated to get right due to the  issue of edge cases  ) ... and yet the same dev team that had no issues dropping a burn time that works correctly maybe 80% of the times ( and that never warns you that the time it shows might actually be a bad one, mind that ) is shy of making a even moderately unreliable dV meter ...

My take on this is that the main reason we don't have a dV meter nowadays is mostly "historical" : I think it is public knowledge that Harv original idea for the game required very little use for dV meter ( or in fact, any gauges besides the ones that we have in the flight/map UI ) and that Harv was initially extremely resistant to the idea of showing much of numbers in the UI. I think the devs only realized they needed to start showing numbers in the UI when planets came out and we had the absurd situation of having to put protactors against the screen to even have a chance of having a interplanetary travel and so they were forced to actually spit out the manouver nodes, that ,as a lot of people pointed out, make very little sense without a dV meter of some kind ... so I believe that the devs intended to add a dV meter somewhere after that. The issue is that IMHO they understimated the magnitude of the work behind making one and due to that, they simply focused on stuff that looked harder/ more important to do in the next updates. This obviously untill 1.0 came out and they actually looked on doing a dV meter seriously , just to discover that it was far more complicated than they thought it was, and as they had so much to do for 1.0, well, the schmelta-Vee thing could wait

And now, that we are going to the consoles, the task of making a dV meter apparently got again the back seat, but this time is more likely to be just because they want to make it right and know that they can't make one for the consoles release...

P.S. Most of the above is speculative, but I think that the above is the most likely scenario, given the tidbits of intel that I gathered around during the years KSP has been around. Take it with as much salt you want.... 

[micr0wave]

the more i read, the more i like my idea of having a readout (in F3 for example) that shows how much dV you've used.

It leaves room for trial&error but still gives a better approximation than wild guesses, those who hunger for more numbers will get the mods for that anyway, and It's probably pretty easy to implement since the game already knows that number.

[Superfluous J]

3 hours ago, Hcube said:

I can feel the debate progressing forwards

In my defense, when I posted that the subject line was "Am I the only one who wants a dV readout" or something like that. Considering how often it comes up, I didn't really feel the need to elaborate.

[Waxing_Kibbous]

All we really need are more lady Kerbals: http://www.npr.org/2016/04/05/473099967/meet-the-rocket-girls-the-women-who-charted-the-course-to-space

[Hysterrics]

5 hours ago, pandaman said:

Every opinion is a valid one.  The problems arise when we forget to respect that.

I happen to disagree with you, as it is a feature I think should be included,  but even then I would ideally want it optional for those that don't

Thanks. I completely agree with your last statement, There are mods for it and it's easier to mod it in that mod it out.

[Blaarkies]

@r_rolo1 Thats some good concrete logic, if one is OK but the other is not, then why do we see numbers only for some situations? Why do we see any numbers at all, shouldn't Isp and Mass values be described with "Light / medium / Heavy" or a "green / yellow / red" rating in a progress bar? 

I get the lego design, it is cool, intuitive, easy to grasp. We use numbers because it is easier to compare parts to each other:
Total mass? -> Look at the same number on a few different parts.
Can engine lift this rocket? -> Look at two different numbers, the engine thrust should be greater than the Total mass.
How far can this ship take go? -> Look at three different numbers. Engine Isp, total mass and fuel mass.

The first two examples are given figures calculated for the player, but why is the 3rd example(dv) "too much number" to display?
Yes you can launch successfully without checking your TWR, but in map view->craft info you have a current "Max Accel." readout. Just to have a current stage dv readout there would be so awesome without defying the "visible numbers" rule anymore than MaxAccel already does.

[78stonewobble]

On ‎31‎-‎03‎-‎2016 at 6:24 PM, regex said:

I keep arguing this point and no one listens, they all think it's a trivial problem to solve and that not much iteration goes into it, or that players will simply ignore the issues of craft complexity (one of the great things about KSP) instead of spouting off on the forums if something doesn't work correctly.

Delta-V calculations for KSP are a very complex problem and you simply can't slip it into "production" software without being absolutely sure that the majority of edge cases are solved for to avoid the inevitable cries of Squad not doing their job right.  Either that or you accept it as mod code where maintaining a high turnover of code and version is acceptable.

I don't think anyone knowledgeable said it would be easy.

The difficulty of doing it, whatever that may be... must be weighed against the necessity of it, whatever that may be.  

 

[juanml82]

If it's complicated, they can purchase KER or Mechjeb. It will be wrong in corner cases, but that should be expected.

I think the devs are still thinking the games in the terms of Harv's initial inception: a simple 2.5D game which grew to a 3D game. Have we ever seen a Squadcast about a mission to Jool, Eeloo or a return trip from Eve's surface?

Those things can't easily be done, or done at all, using only the stock tools. Which makes me think Squad thinks of KSP as a game in which you can fly custom planes across a deserted landscape and, at best, drop a rocket off the Mun and return it. More complex missions like sending fleets to another planets or handling several missions happening during the same game timeframe (ie, send a ship to Minmus while you have another heading for Duna and a third one mining a Dresteroid) isn't something they support or encourage.

[pandaman]

2 minutes ago, juanml82 said:

If it's complicated, they can purchase KER or Mechjeb. It will be wrong in corner cases, but that should be expected.

That's not a practical option for reasons given earlier in this thread.

[Stoney3K]

13 minutes ago, pandaman said:

That's not a practical option for reasons given earlier in this thread.

If you mean license concerns: If a mod gets purchased by SQUAD the license bets are off. Previous versions of the mod may still be licensed under the original mod license (or fork into a "community" mod with said license) but the purchased code can be under proprietary license, since the original modder, and consequently SQUAD, retain the rights to modify the license of that mod at any time.

A copyleft license on a mod does not mean that any possible future versions of that mod are locked into that license, neither does it enforce that license on SQUAD if they decide to purchase code from a mod. They would become the rights owners, and hence, have the rights to relicense the mod under any terms they see fit.

Were SQUAD to incorporate code of said mod into KSP without any further negotiation with the rights owner (the modder) it would be a different matter since SQUAD would be bound by the license terms like any other derivative mod.

"Purchasing" a mod and incorporating it into stock KSP is perfectly possible, if the mod does not depend on any other mod(s) with licenses that disallow it and the mod owner agrees with it.

[Padishar]

1 hour ago, Stoney3K said:

since the original modder, and consequently SQUAD, retain the rights to modify the license of that mod at any time.

It has all been said in this thread already but since people don't bother to read it and keep repeating the same incorrect arguments, I'll say it again...

This is true for a project that only has a single author or where all the contributors have explicitly reassigned copyright of the code to a single person/body.  Otherwise, the consent of all the contributors that have retained their copyright must be acquired before a GPL licensed project can be relicensed.

In any case, it isn't just the license issues.  All of the mods that calculate deltaV have limitations that lots of people would consider unacceptable in a stock feature, they are also implemented in ways that may not be very suitable for the particular way that Squad want to present the feature and they could, almost certainly, be written in considerably simpler ways if integrated into the core game.  It really would be much better for Squad to write their own and it would make sense to share as much code with the rework to the resource flow mechanisms that is (currently) planned for the version after 1.1.

[pandaman]

1 hour ago, Stoney3K said:

If you mean license concerns: If a mod gets purchased by SQUAD the license bets are off. Previous versions of the mod may still be licensed under the original mod license (or fork into a "community" mod with said license) but the purchased code can be under proprietary license, since the original modder, and consequently SQUAD, retain the rights to modify the license of that mod at any time.

A copyleft license on a mod does not mean that any possible future versions of that mod are locked into that license, neither does it enforce that license on SQUAD if they decide to purchase code from a mod. They would become the rights owners, and hence, have the rights to relicense the mod under any terms they see fit.

Were SQUAD to incorporate code of said mod into KSP without any further negotiation with the rights owner (the modder) it would be a different matter since SQUAD would be bound by the license terms like any other derivative mod.

"Purchasing" a mod and incorporating it into stock KSP is perfectly possible, if the mod does not depend on any other mod(s) with licenses that disallow it and the mod owner agrees with it.

That may well be the case, but there are reasons given earlier in the thread, by people who know far better than I do, that indicate that this may not be very straightforward in this case.

And licensing is not the only issue, the complexity of the code required and the expectations of 'production' quality code over mod code.  Again, stated by people who actually DO know what they are talking about.

I don't want to be nagative, and I would like to see this in stock too, but we all have to be realistic and let Squad provide this in the way they consider best for the game as and when they can.

In the meantime we will just have to 'tolerate' the excellent mods that do provide that information.

Ah,   ninja'd by one of the guys that knows what he's talking about 

[juanml82]

1 hour ago, Padishar said:

In any case, it isn't just the license issues.  All of the mods that calculate deltaV have limitations that lots of people would consider unacceptable in a stock feature, they are also implemented in ways that may not be very suitable for the particular way that Squad want to present the feature and they could, almost certainly, be written in considerably simpler ways if integrated into the core game.  It really would be much better for Squad to write their own and it would make sense to share as much code with the rework to the resource flow mechanisms that is (currently) planned for the version after 1.1.

Regarding limitations, we already have inaccurate stock burn times, so I feel a dV readout that fails if you have retrorockets it's perfectly acceptable. Or, at least, it's of a similar quality than the node burn time calculator

[TaintedLion]

Maybe Squad thinks mods like KER already have it covered, so there is no real need for a stock version?

[Padishar]

5 minutes ago, TaintedLion said:

Maybe Squad thinks mods like KER already have it covered, so there is no real need for a stock version?

Please don't post speculation that has previously been directly stated as being false earlier in the thread...

 

[78stonewobble]

15 hours ago, juanml82 said:

If it's complicated, they can purchase KER or Mechjeb. It will be wrong in corner cases, but that should be expected.

I think the devs are still thinking the games in the terms of Harv's initial inception: a simple 2.5D game which grew to a 3D game. Have we ever seen a Squadcast about a mission to Jool, Eeloo or a return trip from Eve's surface?

Those things can't easily be done, or done at all, using only the stock tools. Which makes me think Squad thinks of KSP as a game in which you can fly custom planes across a deserted landscape and, at best, drop a rocket off the Mun and return it. More complex missions like sending fleets to another planets or handling several missions happening during the same game timeframe (ie, send a ship to Minmus while you have another heading for Duna and a third one mining a Dresteroid) isn't something they support or encourage.

Just my personal oppinion on that last section.

With a complete stock game... The difficulty between the "beginning" and the "end" of a game, as you describe it there... Is a pretty darn tall cliff wall...

I think the game deserves the tools to make that wall a more smoothe hill. To let more players do more AND experience more in the game. And I think it deserves it in stock.

...

Yes, I know that some people are able to successfully grand tour the whole game in 1 ship in stock with starting parts and taping over the navball and navigate after the  background texture stars, but I don't think KSP, of all games, should be designed around these extraordinary players.

The playerbase has an average and it has outliers in both directions. The game should try to cater to as many players as possible... that means both sides of that average.

I think the challenges section proves, that it is possible... to make this game as arbitrarily hard on yourself... as people want it to be, by choosing not to use xyz...

I think the game deserves more choice at the lower end... where people can choose to use xyz... and get to the end game.

...

That's why I think some tools should be in the stock game... Then we can haggle back and forth

...

PS: I think I half wanted to make the point... that it's easier to choose to not use something that's allready there... than it is to choose something which isn't there... Unless you go the mod route. In which case you have to be lucky that there is a mod for it and the mod is up to date, don't mess up other mods and so forth and so forth. I love mods, because they give people lots of choice in making ksp into what they want... but they aren't allways as easy as we would like them to be.

 

[Enceos]

Meanwhile Mr. Malah makes another dV readout mod which integrates beautifully with the stock engineer's report:

Edited April 9, 2016 by Enceos

[ArgenTum]

A whole thread of a delta-v readout!!! I want in!

I have skimmed the thread, read NathanKells posts, but not every single post, just so that you know. Just want to have my say how I think it should be done.

1. I think a delta-v readout in flight and in VAB are two different things, and I would say that the game doesn't need an in flight readout (but I'm not against it), but i seriously needs a readout in the VAB. That way you would have some guidance while building the spaceship, but still leave some room for error while in flight, which for me makes good gameplay IMHO. And, probably would be slightly easier (=less hard) to code.

2. A VAB delta-v readout for me is top priority, before fiddling more with the contracts, or implementing the new radar range or any graphics upgrades. A delta-v readout is the single one feature that is needed for a complete game, IMHO (for reasons other have stated above, about accessibility and that this is after all a game, you really shouldn't have to do a lot of research online or calculations with pen and paper or to install a mod to be able to play it (I'm sure there are those who thinks it is playable under any of those conditions, but for me it's really not. I have installed KER, but I really don't like to use mods, for many different reasons.)

3. The delta-v readout in VAB should look very much like KER does today, because KER is really good. But in stock it probably should come with a warning from Wernher ("Remember that the delta-v readout is far from perfect, but Gene (or whoever) kept nagging us about showing at least some basic readout for the most basic designs, because he got bored of all the Kerbals stranded in space when the fuel ran out." That way, it would be explained in game that it is a basic help, not an advanced tool to give a delta-v readout for every possible and impossible contraption.

4. The ability for this KER-like readout to calculate TWR, performance of different engines at different altitudes etc would depend on the experiments performed by the player. Haven't measured the gravity on Mun? Then you can't use the readout to calculate TWR for Mun. No readout in high and low atmosphere of its composition? Then you can't pull the slider and find out how your jets/engines will perform. This probably would need a re-balance in the tech-tree so you unlock the most helpful science parts early on, but it would in my opinion make for a really, really good game play.

[Kosmognome]

3 hours ago, Enceos said:

Meanwhile Mr. Malah makes another dV readout mod which integrates beautifully with the stock engineer's report:

Can you provide a link to the mod? I love it!

[eddiew]

3 hours ago, Enceos said:

Meanwhile Mr. Malah makes another dV readout mod which integrates beautifully with the stock engineer's report:

I would also like to know details of this mod... there's something to be said for only knowing dv before you launch and having to keep track of your staging to be aware of it after that

[ModZero]

On 3 April 2016 at 6:51 PM, Rocket In My Pocket said:

A space simulation game with no Delta V/TWR readout makes about as much sense as:

• A racing game with no speedometer/rpm
• A football game with no score display
• An RPG where you don't know what level you are
• An FPS with no ammo counter
• An RTS with no display for collected resources or population cap
• A sims game with no "needs and wants" meters
• A fighting game with no health bars

I could go on...and on...and on...

• The only car game I've ever paid attention to my speedometer is ETS. At there are plenty racing games that don't show you the speedometer,
• this is a silly comparison,
• this is a silly comparison, and levels are terrible RPG design that has to go,
• this is a commonly toyed with idea, it tends to increase tension quite nicely, also, that's closer to your fuel amounts
• no, that's fuel amounts,
• those tend to be pretty much magic, and are nothing like dV,
• health bars are a silly idea and have to go, and are also more similar to fuel amounts.

And, finally, pretty sure you're trying to argue that KSP is unplayable and nobody ever made orbit in stock.

Also what regex and anyone else with the faintest idea here wrote. It's relatively easy for a human to calculate the dV rocket they see, mostly because the human actually understands the rocket — basically does a lot of heuristics of the "this goes before that" and "this counteracts this" and "this engine works in this special way" kinds without even paying full attention to it. dV calculators don't get that benefit.

Edited April 9, 2016 by ModZero

[Foxster]

3 hours ago, Enceos said:

Meanwhile Mr. Malah makes another dV readout mod which integrates beautifully with the stock engineer's report:

No, no, they can't have because according to some who have posted in this thread this is all but impossible.