Squadcast Summary 6/26/15

[FlowerChild]

Listen to yourself for a moment man. Seriously, say that sentence right there out loud. You're saying that the total available change in velocity is a much more complex "concept" than the change in velocity required for a single maneuver. As if adding two numbers is somehow a seriously tough thing for players to grasp.

At worst it's a poor choice of words, but regardless, calculating the operational range of a car is far more complex than the distance to destination, much the same way that knowing you have to change your velocity by 100 m/s to complete a maneuver is far simpler than calculating how much delta-V your rocket has remaining.

Why bother with a confusing number that people will want to subtract from another number when there is already a magnitude indicator?

Again, for the same reason that knowing distance to destination in a car is valuable despite not knowing operational range: it gives you a basis of comparison that you can use relative to other distances upon which to base your own guesstimates of whether you can get there on a tank of gas or not.

I am the rare guy that plays exclusively and extensively without a deltaV indicator man, and the concept of removing the deltaV readout on maneuver nodes to somehow "match" strikes me as absolutely silly. That indicator is plenty useful to me without the other number, and I in no way feel it detracts from my enjoyment of the game in the way an indicator for remaining deltaV would.

[Superfluous J]

deltaV indicator man

I can't help but imagine this as a superhero.

[Wallygator]

At worst it's a poor choice of words, but regardless, calculating the operational range of a car is far more complex than the distance to destination, much the same way that knowing you have to change your velocity by 100 m/s to complete a maneuver is far simpler than calculating how much delta-V your rocket has remaining.

Again, for the same reason that knowing distance to destination in a car is valuable despite not knowing operational range: it gives you a basis of comparison that you can use relative to other distances upon which to base your own guesstimates of whether you can get there on a tank of gas or not.

I am the rare guy that plays exclusively and extensively without a deltaV indicator man, and the concept of removing the deltaV readout on maneuver nodes to somehow "match" strikes me as absolutely silly. That indicator is plenty useful to me without the other number, and I in no way feel it detracts from my enjoyment of the game in the way an indicator for remaining deltaV would.

I drove a car with a broken fuel gauge once. Just once. The signs telling me how far it was to the next exit were useless.

Your logic and argument make absolutely no sense to me. Sorry.

[pandaman]

The first official Asteroid Day. Tuesday June 30th 2015.

Seems suitably important (and relevant) for a space fight game, and it just so happens it's next week too.

[FlowerChild]

I drove a car with a broken fuel gauge once. Just once. The signs telling me how far it was to the next exit were useless.

Your logic and argument make absolutely no sense to me. Sorry.

Why? I wouldn't want to play KSP without a fuel gauge either, nor does the fuel gauge in your car provide the range of your vehicle (just a vague sense of it based on previous experience). It's actually the equivalent of what we have already displayed in KSP in terms of fuel remaining without knowing distance to destination divided by miles per gallon with the current weight in the car adjusted over time to account for decreasing mass as fuel is expended while taking into account you're carrying additional fuel in a trailer that you'll unhitch once it's consumed as a precise number

Edited June 27, 2015 by FlowerChild

[DMagic]

Why bother with a confusing number that people will want to subtract from another number when there is already a magnitude indicator?

I mean, I can understand some of the other arguments, like uncertainty and chance for failure, but basic addition and subtraction is a very poor argument.

I agree. I understand why they chose to use delta-V as the magnitude for maneuver nodes (arbitrary units wouldn't make much sense and a percentage scale wouldn't give any point of comparison), it's just the obvious choice, but it makes little sense to provide such a value with no context.

If someone doesn't want to use a delta-V indicator that's fine, don't use it if they add it. Guess work (it might be educated guess work, but it's still guess work) is fine when you're just tooling around the Kerbin system and there isn't much of a penalty for screwing up, but once you get further away I think it becomes a problem.

Of course, KSP doesn't offer any indication of how much delta-V is required to get anywhere, so you could argue that a delta-V indicator by itself doesn't provide much value, but such information is readily available, even if it can't be found directly in-game.

Why? I wouldn't want to play KSP without a fuel gauge either, nor does the fuel gauge in your car provide the range of your vehicle (just a vague sense of it based on previous experience). It's actually the equivalent of what we have already displayed in KSP in terms of fuel remaining without knowing distance to destination divided by miles per gallon with the current weight in the car adjusted over time to account for decreasing mass as fuel is expended while taking into account you're carrying additional fuel in a trailer that you'll unhitch once it's consumed as a precise number

Huh? A car is a poor analogy for a vessel in KSP. You could come up with some scenario where you are sequentially dropping mass out of the car, or carrying an enormous amount of fuel, but during normal driving a car is a relatively consistent object where the fuel accounts for maybe 5% of the total mass. That has nothing to do with KSP's fuel gauge, which, given the almost infinite variety of vessels possible and how rapidly each vessel can change, provides only limited information.

Edited June 27, 2015 by DMagic

[regex]

At worst it's a poor choice of words, but regardless, calculating the operational range of a car is far more complex than the distance to destination, much the same way that knowing you have to change your velocity by 100 m/s to complete a maneuver is far simpler than calculating how much delta-V your rocket has remaining.

At best it's a poor choice of words, sorry. You mentioned nothing about calculation in the post I quoted, you talked about the "concept". And calculating delta-V is as simple as calculating the number of miles your car can go on a given amount of gas, they're both simple math (although, as has been rightfully pointed out in the past, the calculus required to find the simple math in the delta-V equation was pretty rugged). Certainly the player can do that for themselves, but that's no reason not to include it in the game.

Argue uncertainty and chance for failure, or something else, don't argue against basic addition and subtraction from a total.

Again, for the same reason that knowing distance to destination in a car is valuable despite not knowing operational range: it gives you a basis of comparison that you can use relative to other distances upon which to base your own guesstimates of whether you can get there on a tank of gas or not.

Estimating a trip for the car I drive every day and know the ins and outs of is much different than doing the same for a craft I slapped together for some dumb part test contract. Personally, I build a new craft and lifter pretty much every time I launch, aside from maybe a reliable crew shuttle or something, so a delta-V indicator is invaluable to avoid countless, needless testing or tabbing out to a spreasheet or something. It's a convenience, and a really good one at that.

[FlowerChild]

If someone doesn't want to use a delta-V indicator that's fine, don't use it if they add it. Guess work (it might be educated guess work, but it's still guess work) is fine when you're just tooling around the Kerbin system and there isn't much of a penalty for screwing up, but once you get further away I think it becomes a problem.

I think you're at least vaguely familiar with my mod man, and likely know that it increases the difficulty of just about everything in the game. Vehicles are way higher mass, ISP and thrust for most engines is reduced significantly, way more equipment is needed on board a vessel to keep it operational, and things often get so big that orbital assembly becomes more or less a requirement. Despite that, and despite it involving ships like this (and nothing on this vehicle is decorative):

Despite that, I've been to and landed on every body in the game under those conditions, and all without using a deltaV indicator. I can say with certainty that there's nothing in the game so difficult that it requires one.

I personally enjoy the guestimation and the mental stimulation that it provides in-flight. I enjoy the slow process of trial and error involved in building reliable lifters as a game progresses. And yes, if Squad adds such an indicator, I'll likely just mod it out, so whatever happens with it I'm fine.

However, I do think it's a shame that new players will be deprived of the potential of enjoying the game in the same way that I do by being given that information by default. I do not think it's in any way required and there's a unique brand of fun to be found in not using it.

Argue uncertainty and chance for failure, or something else, don't argue against basic addition and subtraction from a total.

I do argue each of those things, and yet I still maintain that it's perfectly reasonable to know the range to destination in a car without knowing your operational range, whereas you seem to think they're inherently linked in some way where you can't possibly display one without the other.

And yes, in hindsight, I'd say they're even completely different concepts, and by the same logic, that deltaV for a vessel, and deltaV for a maneuver are different concepts as well. They may happen to appear on opposite sides of an equation, just like distance and range do for a car, but that does not make them inherently the same thing.

Edited June 27, 2015 by FlowerChild

[regex]

And yes, in hindsight, I'd say they're even completely different concepts, and by the same logic, that deltaV for a vessel, and deltaV for a maneuver are different concepts as well. They may happen to appear on opposite sides of an equation, just like distance and range do for a car, but that does not make them inherently the same thing.

They both represent changes in velocity, the only difference is that one is the current required fraction and the other is the total available. There is no difference in "concept" between them. The same applies to a car, you can subtract the distance you've travelled from your operational range to arrive at the current available range. What you're saying is "this fuel gauge is enough for me, it should be enough for you" where I'm saying "the game should do me the courtesy of translating that fuel gauge to the other symbology it uses."

[FlowerChild]

They both represent changes in velocity, the only difference is that one is the current required fraction and the other is the total available. There is no difference in "concept" between them. The same applies to a car, you can subtract the distance you've travelled from your operational range to arrive at the current available range.

I think we're likely devolving into semantics with this particular point when we're both clear on what the other is saying. Whether distance between points and operational range are the same "concept" or whether they're just measured in the same units is likely debatable, and we also likely won't achieve anything at all by trying to convince each other of our particular viewpoint on it.

What you're saying is "this fuel gauge is enough for me, it should be enough for you" where I'm saying "the game should do me the courtesy of translating that fuel gauge to the other symbology it uses."

I'm NOT saying it should be enough for you. Who knows, if I played RSS in particular, I might be singing a different tune (but then I wouldn't object to just modding in a deltaV indicator to that end either).

All I'm saying is that I personally don't want it and prefer it be left out by default. Right now you're modding it in and want it by default, whereas I don't want it by default and will likely mod it out if that's the case. We also both seem to think that new players should be presented with a level of information that reflects how each of us enjoys playing the game.

That's the extent of it.

Edited June 28, 2015 by FlowerChild

[NecroBones]

That's the thing, dV is the single most important and sensible measure for what your vehicle can do in space, and what magnitude of a maneuver you're performing.

But I also get how complicated it is to predict how a person will use their stages (and docking ports) to figure out what the total dV for the vehicle is. Engineer and Mechjeb do a pretty good job, but they fail completely if you use very creative staging or do everything with docking ports.

This is why all I'm asking for is current stage dV, based on what fuel is currently accessible to the currently active engines. Even this is slightly complicated because you have to take into account any variation of ISP and overall fuel rate for the engines, and which ones are sharing tanks and which aren't. But at least you can stop there, without trying to predict staging, and then just display a number.

[Tarmenius]

"If anyone can guess what important event is coming up next week.. then you are.. probably very close to something."

The conjunction of Jupiter and Venus is supposed to occur on July 1, so perhaps Jool, Eve and Duna will be visible from Kerbin?

[DuoDex]

Flowerchild, I have seen you questioning Squad's rebalancing of aero recently.

Every game company EVER has released patches, fixes, and changes after release. Why should Squad be different?

Your own mod continually goes under changes. It's the same with Squad - they didn't get it right the first time, so they are trying again until they do. Saying they shouldn't is just silly.

[rkman]

Every game company EVER has released patches, fixes, and changes after release. Why should Squad be different?

The number of patches in a given amount of time does matter.

Four patches in 2 months is quite a lot. Sure, the large number of KSP patches is necessary - because the game still has many issues.

It is one thing to fix bugs that are new in the final version, but in KSP many of the issues are long-standing bugs that were not fixed in the final release.

Also not many game company release patches that include major features and fixes to those features.

Max has actually said after 1.0 that they will now work on properly finishing the game - in other words: Squad agrees that the released version was not finished.

[Streetwind]

*Squad releases few patches*

- The forum: "OMG Squad start fixing the game already!"

*Squad releases lots of patches*

- The forum: "OMG Squad stop breaking the game already!"

This, folks, is the reason why game developers throttle back community interaction as the community grows and the game ages. Both of these things add nothing but pure noise to the signal-to-noise ratio, and the noise level remains constant regardless of which action the developer takes.

If Squad knows what's good for them, they'll ignore this noise to the best of their ability.

[FlowerChild]

Flowerchild, I have seen you questioning Squad's rebalancing of aero recently.

More precisely, I've been questioning why these things weren't sorted before release, and given that they weren't, why Squad hasn't taken the time to properly rectify that situation post release and is instead playing ping-pong with the balance of the game through a series of patches that seem to be entirely reactionary rather than involving any clear design direction.

I also do not think we've seen the last of it. Had I felt that were the case with 1.03/4/5, I might have grumbled about how getting mass to orbit is being trivialized, but that likely would have been the extent of it, because I would have at least felt that what we got would have been a consistent base moving forward.

Every game company EVER has released patches, fixes, and changes after release. Why should Squad be different?

Sure. Most games however do not change the fundamental rules of play repeatedly post release. There's a big difference between that and tweaks to refine balance or pure bug fixes. So, I will return your question and ask why would Squad be any different?

Your own mod continually goes under changes. It's the same with Squad - they didn't get it right the first time, so they are trying again until they do. Saying they shouldn't is just silly.

My mod is in a continual state of development. I've never claimed it to be finished/in a release state. I am also not producing it commercially, nor do I consider players of my mod to be paying customers, nor do I have a professional staff at my disposal in working on it.

It's a silly analogy at best.

Edited June 29, 2015 by FlowerChild

[DuoDex]

-snip-

I do not know where this idea that 1.0 is 'a finished product' came from. No one at Squad has said it is, and has been already pointed out in thread, Max has said that they will begin finishing the game after 1.0.

Give me one 'fundamental rule of n play' that has changed post 1.0.

And finally, your mod is in the 'Releases' section of the forums. Evidently, you think it is ready for release. The other points are null and void - Squad has no obligation to do what you want just because that's how you feel it should be done because 'they are producing it commercially' or because 'they have a professional staff'.

[Ignath]

I do not know where this idea that 1.0 is 'a finished product' came from. No one at Squad has said it is, and has been already pointed out in thread, Max has said that they will begin finishing the game after 1.0.

The problem with this whole argument is that SQUAD (and by extension the mods on their forum) have a different definition of "1.0" than a majority of the rest of the gaming universe. Generally, from the inception of games, 1.0 has meant that the final game had been pressed and it had gone "gold" so-to-speak (in other words, 'a finished product').

SQUAD, on the other hand, now claims that 1.0 just means "all the features Harv originally wanted in the game"; which is a fundamental change to the definition of 1.0. Many of us were trying to bring this point forward when the decision was made to call the last update 1.0; but SQUAD thought that their definition of 1.0 would work and that people would accept it...it really hasn't and has caused a lot of angst on the forums lately. I agree that 1.0 is just a number, but it's a MEANINGFUL number in software development, you just can't change peoples opinions on that by changing your own definition of it...

[DuoDex]

I understand that people think that 1.0 is something more than 'just a number', but all it really should mean (as Squad have said) is 'what Harv wanted in the game'.

[Ignath]

I understand that people think that 1.0 is something more than 'just a number', but all it really should mean (as Squad have said) is 'what Harv wanted in the game'.

Agreed, but as I said...you can't just have 1 company change the definition of what '1.0' means ( just for their game ) and expect not to see some backlash, misunderstanding and anger when people come to find out that SQUAD has changed their definition of 1.0 and it no longer means 'a finished product' but now means ( to KSP only ) 'what Harv wanted in the game originally'. People who have played games since way back in the Atari, TANDY, 5 1/2" to 3.25" floppy, Apple 2e, etc... days know 1.0 to mean 'finished'. SQUAD changing their definition of 1.0 isn't going to change the decades of assumptions and expectations toward what that means.

[monstah]

At worst it's a poor choice of words, but regardless, calculating the operational range of a car is far more complex than the distance to destination, much the same way that knowing you have to change your velocity by 100 m/s to complete a maneuver is far simpler than calculating how much delta-V your rocket has remaining.

Dude, it's not. My gas meter is broken. I fill my tank when I've driven around 500km because I know that's how much it can handle, plus a safe margin. It is not rocket science to know how long your fuel is worth for.

And yes, I know I should fix my gas meter. I should in fact get a new car 'cause it's falling apart, but that's a whole other story.

Now, the way I see it, of all the reasons not to have a DV indicator, the prize for dumbest just has to go to "we couldn't figure a nice UI for it". Like... really? You know, where it says "Parts: x, Mass: y", in the engineer's report? Pro tip: "DV: z" just below it will not break your UI.

- - - Updated - - -

I drove a car with a broken fuel gauge once. Just once. The signs telling me how far it was to the next exit were useless.

Your logic and argument make absolutely no sense to me. Sorry.

Heh, didn't read that before I posted.

I'm driving like that for quite a while. It's bad, am I'm not proud of it.

Why? I wouldn't want to play KSP without a fuel gauge either, nor does the fuel gauge in your car provide the range of your vehicle (just a vague sense of it based on previous experience). It's actually the equivalent of what we have already displayed in KSP in terms of fuel remaining without knowing distance to destination divided by miles per gallon with the current weight in the car adjusted over time to account for decreasing mass as fuel is expended while taking into account you're carrying additional fuel in a trailer that you'll unhitch once it's consumed as a precise number

As above. Your logic and argument make absolutely no sente so me, too. A car may be a poor analogy for a rocket, but a number is a number is a number. What's that number by the manouver? Delta V needed. How much do I have? Not telling you.

Giving players a new way to fail to account for all the ways RL rockets fail and KSP rockets don't? Well, how about this: RL rockets are made by teams of top-notch engineers with hundreds of millions of dollars and decades of research. KSP rockets are built by dudes and dudettes in their spare time. Some of whom are in school. And they just want to play a game.

Edited June 29, 2015 by monstah
italics instead of bold sound less agressive

[J.Random]

I understand that people think that 1.0 is something more than 'just a number', but all it really should mean (as Squad have said) is 'what Harv wanted in the game'.

You can't have your cake and eat it too (I like russian version better: "climb the spruce without scratching your ass"). You can't just change the description of Alpha/Beta/Release stages as you wish when it suits you. You can't remove the EA label and expect customers to be as forgiving as when your product had it. If you're promoting the software product as "Released", I'm expecting a proper, "Release" quality. What, users should be satisfied with "Release" which is kinda "Beta" (feature complete, "what Harv wanted") but not finished yet? "We're still working on it" is not even an excuse, it's an insult.

[basic.syntax]

The original post that HarvesteR replied to has a lot more words on the definition of alpha/beta, and the software development shift toward continuous update.

Other products in the history of software development have simply stopped development and moved on to the next thing, when a founder declared it was "done." (They might start work on a massive overhaul of the original product, with so many changes that they call it "v2.0" and sell it separately. If they are feeling generous, they might include a rebate / discount for purchasers of the first version.) Believing that you have been insulted, and how you react to that belief, is up to the person reading the words. I don't feel insulted, and am grateful that Squad continues working on KSP & look forward to what they come up with, next.

[zhollett]

Well, how about this: RL rockets are made by teams of top-notch engineers with hundreds of millions of dollars and decades of research. KSP rockets are built by dudes and dudettes in their spare time. Some of whom are in school. And they just want to play a game.

I think this is were the core of the discussion lies.

One of the first things I do upon a new release is look for an updated version of KER.

If there were no mod for that, I would make an excel spreadsheet which did that calculation for me, because I just simply want to know how many deltaVees I have left compared to where I want to go.

FlowerChild, you are making those calculations in your head and you love doing that. I don't make those calculations in my head, because I don't love doing that.

New players are not being deprived of an experience of guess work, explosions and fuel concerns because there will be and are still issues for new players, regardless of how much information you give them. Its another data-point useful to everyone. I can't honestly see why you would mod out a "DeltaV:# m/s".

Why do you want the game to tell you how much your total rocket weighs? I mean, you know the weight of the individual parts, so you can just add those up in your head too... right? Then you can use the ISP, Max fuel drain, Thrust, Mass calculation all without computer aid. <-- that statement was purposefully ridiculous, merely used to show a more extreme example of the same thing.

[J.Random]

The original post that HarvesteR replied to has a lot more words on the definition of alpha/beta, and the software development shift toward continuous update.

Other products in the history of software development have simply stopped development and moved on to the next thing, when a founder declared it was "done." (They might start work on a massive overhaul of the original product, with so many changes that they call it "v2.0" and sell it separately. If they are feeling generous, they might include a rebate / discount for purchasers of the first version.) Believing that you have been insulted, and how you react to that belief, is up to the person reading the words. I don't feel insulted, and am grateful that Squad continues working on KSP & look forward to what they come up with, next.

"Continuous update" argument is irrelevant. It's the same production cycle, there are the same phases, they just repeat for every Update/Upgrade release. There's still alpha for the version 1.234.567, there's Beta (feature freeze), there's Release Candidate, there's Release. There's DA (Directed Availability, "Experimentals" for Squad) and GA (General Audience Availability) release substages. Instead of "product beta phase", there's "specific version beta phase". Even if Squad doesn't like terminology, they shouldn't use it incorrectly anyway. Again, "can't have your cake and eat it too".

The comparison to "other products" is incorrect. This isn't [Arrogant Person] Olympics, after all. It's unfortunate that some companies can afford to claim an incomplete product as "finished" and get away with it but I hope it's not for long. Voting with a wallet is a legitimate answer to such practice, I see more and more examples of it in the last years, and I see a support for it from distribution platforms (Steam will only be the first, mark my words).

Edited June 29, 2015 by J.Random