FlowerChild

How is the relative measure provided by a fuel gauge any more informative? All it indicates is how much you have left relative to how much is there when it's full. It often times doesn't even display any kind of units to give you an indication of what volume is actually remaining (which is information that KSP currently provides beyond that). Still quite useful, as is knowing your distance to destination. I use the car analogy, but there are many similar precedents in various games over the years that have made this kind of limited information approach rather common. I think Lunar Lander may have even given you your velocity relative to the ground but your remaining fuel was just an abstract gauge, and whether it be space games, ground based games, flight games, or even character-based survival games (You're displaying how many calories this can of beans contains but my hunger bar is an abstract gauge! AAAAHHHH! ), a separation between the level of information you have about what you're trying to achieve vs what your vehicle is capable of is quite common. KSP isn't at all an exception in that regard other than it's about *somewhat* realistic space flight, and people consider space to be hard or something. DeltaV (for a maneuver) is simply the change in velocity required between your current velocity and your desired (much like the distance you need to travel in a car is just the difference between your current position and desired). There's nothing particularly complicated about it, and it's entirely useful information in comparing the relative cost of various maneuvers and getting a feel for how well different vessels perform in completing particular maneuvers without needing to know your deltaV remaining for it to have meaning. It essentially amounts to "I want to go that much faster in that direction", which I consider to be a separate level of information from knowing how much capacity your vessel has for performing such changes overall. I use it all the time and I'm glad it's there in the format it is, despite not using a deltaV remaining indicator. I think the "magic" comes down entirely to what level of information players find to be more fun, and what Squad considers to be the most fun for players overall (and probably what they consider to be most approachable for new players as well). That's all highly subjective of course, but speaking in a general sense I think partial information like this, especially about desired outcome vs. vehicle capability, has been used in many games before to help create tension and increase the possibility of failure to create interesting scenarios that the player might not run into otherwise.

In a game? I wouldn't launch a real rocket without knowing its deltaV either. Launching a few green cartoon characters into space in a game where pretty much everything is made simpler than the consensus reality and just winging it is an entirely viable option? Why not? The point I was trying to make with that analogy is that knowing the distance your vehicle needs to travel (which is roughly equivalent to the deltaV of a maneuver once you're outside of atmosphere) is useful information regardless of whether you know the range of your vehicle or not (roughly equivalent to the deltaV a vessel has remaining). I do not feel the argument that because one is displayed the other must be as well to be at all convincing as a result. Again...amusing, but not in any way convincing. I am one of those rare guys that represents any form of opposition to using a deltaV indicator (for myself...really don't care what others do), and what I'm saying is that particular argument does nothing to sway me at all, and I doubt it would sway anyone else either. The inclusion of one piece of information (deltaV of a maneuver) in no way necessitates the inclusion of the other (deltaV remaining) as the "not telling" argument would imply. Again man, I consider the *level* of information provided to be an integral part of a game's design. Reducing that to absurdities does nothing to strengthen your argument, just like me saying something like "if the game provides so much information that it devolves into a series of 'press foo button now' prompts, how does that still qualify as a game?" wouldn't strengthen mine (Dragon's Lair and Guitar Hero aside ). Put another way, I think too little information makes for a crappy game. Too much information makes for a crappy game. It's highly doubtful that anyone would argue for no or total (as in: god like) information in any game, so somewhere in between lays a sweet spot for any particular game that maximizes enjoyment, and that may vary from individual to individual. I think the differences in perception over where that sweet spot lays is essentially what this debate comes down to, and not much else. There are definitely valid points to your side of the debate that have their own merits, but I think if I'm saying anything, it's that going to extremes like this in trying to put across the point really doesn't help in making a convincing argument. Rather, it just further entrenches people on my side of things due to having rather absurd arguments thrown our way.

Driver gets into car, and says "I need to drive 200 miles!" Car says: I have half a tank of gas. Driver gets out, slams door, and vows to never drive again. The above is exactly what I hear when I see the above argument made. Personally, I find it amusing, but entirely unconvincing.

Oh, I'll just mod it out (or not, we'll see as like I said, I'm not even certain I care that much anymore), so I'm really not worried about it personally. I'm also not a fan of excessive options in games either, so I'm perfectly happy with Squad making a decision on it and sticking to it as "the way to play". If I want something to be different, I'm more than capable of changing it myself, and I sincerely doubt many people would use such an option anyways, as I know I'm in a very tiny minority in playing this way. Yup, I can certainly hear that. For me, I enjoy the iterative process of developing a series of increasingly more powerful launchers over the course of a game and as I tackle harder tasks. I do use trial and error, yes, but the number of mistakes I make is actually relatively low due to that incremental approach. It's not like I just start up a new game and decide "ok...off to Eeloo I go" The mistakes do make things interesting when they do occur though

I'd say that's a fairly major thing though, and running out of fuel has lead to many of the best scenarios that have occurred within my own games. Like back in 0.9 I ran into a situation where a crewed vessel ran out of fuel while performing a burn to return from the Mun. Resulted in an periapsis that swung close by Kerbin, but didn't contact the atmosphere. Was playing with limited life support, so they were essentially doomed. Wound up putting together a rescue mission that managed to intercept them while they swung past, transfer them to a fresh capsule, and then deorbit it, in what was probably one of the most epic experiences I've had in the game, and it's not an isolated incident either. I'd say that many of my best experiences in the game have resulted from running out of fuel due to my guestimates being off. Yes, to make things harder...while still not using a deltaV readout. I'm not saying that everyone should play as intended. I do find it odd however that a moderator would essentially be dismissing a player's views on how they enjoy the game as being "needlessly complicated" when it represents how the game was originally designed. And I'd say the same to everyone that was told it was impossible to play the game without, probably before they even had a chance to learn to play without that info, or to determine if they enjoyed it more that way. Sorry, I'm a habitual editor, and I missed yours too apparently

Interesting standpoint given I've been playing the game as it was designed, and as repeatedly stated as the design intent by Squad. That stance may be changing now (or shortly), but it definitely wasn't the case in the past. IMO, it's not about complicating things as much as it is about playing how I personally enjoy things more. I enjoy a seat of the pants approach to most games, whether that involves driving a car, flying a plane, or putting something into orbit, and I've never found something to be so difficult in KSP that it would require additional information to make the task easier.

Yeah...sorry. Went into soapbox mode as the perceived "need" for such information, and how new players are almost inevitably told they absolutely must have it, has always driven me a bit nuts

And I can go everywhere without it...and without a spreadsheet...and without performing any calculations at all other than stuff like energy or life support consumed over time vs total carried. That's not an argument against a deltaV display being integrated into stock. At this point I don't think I really care either way. It is an argument however against the assumption that it's in any way necessary in order to play the game and do everything in it. It's really not. For reference, I'll link my first ever post to these forums where I specifically stated I didn't want anything that provided additional information or gameplay aids: http://forum.kerbalspaceprogram.com/threads/40162-Looking-to-start-installing-mods-to-provide-a-*deeper*-gameplay-experience Didn't stop people from trying to ram the "need" for them down my throat however I stuck to that in these past two years with a couple of minor exceptions like PreciseNode and Waypoint Manager that I feel make up for deficiencies in the stock interface. Interface nuisances aside I personally find stock KSP to be extremely easy to play, and that was true when I started playing as well. The last thing I've ever wanted were tools to make it even easier like a deltaV readout.

Where did you find the toilet in KSC? Is it a unique biome for science experiments?

As you wish man. We've argued this subject before and while we are of similar opinions on many topics, are obviously of vastly different ones on this one, and it's one of the rare instances where I strongly agree with one of Squad's design decisions in not having a deltaV indicator in the first place. I've actually taken them sticking to their guns on that point as a sign of hope for a long time now, in not always caving to community pressure, but sometimes adhering to a design vision. To me, the degree of information you present to the player is an integral part of a game's design. So, you say "common sense", I say "gameplay squashing", we go back and forth ad nauseum and eventually give up trying. May as well just cut to the chase It should be noted that in these discussions of ours I haven't really been arguing against the inclusion of a deltaV indicator overall. Just some of the individual points you've been making for them, which I don't think are particularly strong, the realism argument and "two sides of the same equation so you may as well rip out the existing deltaV for maneuvers indicator" included. I do think that a valid debate could be had over this on the degree of information that the player should have access to and what makes for a more fun experience overall. Yeah, I do agree that the class mechanic is weak at present and doesn't bring much to the table. I think it *can* become something interesting with time but will require a lot more work, and probably entirely new gameplay mechanisms (like the engineer class makes a lot more sense in the context of something like KAS...but not stock). Ultimately, I do like the idea of incentivizing multi-man missions through specialized roles, but I really don't think that's where stock is at, at present. IMO, there's some good to the base idea, but the current execution is lacking. I also think that without some kind of downside for multi-man missions (life support requirements or such), it all winds up being fairly meaningless as you could just stuff a few more clowns into the car anyways.

If that's the first thing you want to know about the future from a time traveler, may I suggest you may be playing a tad too much KSP?

Whether or not a rocket designer would have that information available in the consensus reality, is ultimately a realism argument man, and as you yourself pointed out recently, those are often just wrappers for an attempt to make things easier (as this one is). Also, I can see why they'd tie it to skills so as not to force this information down the player's throat in the early game when it is least required. Personally, I'm happy that they're tying it to the engineer skill as that will likely make the deltaV indicator all the easier to mod out entirely

You sure about the assertion there was a forced update on Steam for this? I see no record of it being installed, nor is an update appearing in my Steam download queue. Just rebooted Steam to be sure, and still see nothing related to this.

Ah, gotcha. Yeah, that just wouldn't be feasible in BTSM (which is pretty much all I play) given that you're usually operating under tight time constraints for energy and/or life support for the rendezvous, hence why I thought that you must be burning like crazy at some point to catch up to the CM, and hence why I'm so keen on having a better way of plotting my initial trajectory through Waypoint Manager

I appreciate that man, and I appreciate the attempts to explain (sorry I didn't notice the response for a few days). Unfortunately, I've had the exact opposite experience where I find the additional complications introduced by the new heat system due to separating the skin temperature (especially the additional separation of the exposed and unexposed portions in atmo) actually make it MUCH more difficult to balance and less predictable than the old pre-1.0 DR or the 1.02 heat system, and as you know, I have pretty extensive experience working with both. I still view it as an entirely unnecessary complication to what was a system that was working very well (the 1.02 one) with a few relatively minor tweaks (mainly a global thermal mass reduction). I actually liked that one quite a bit, while finding the new one to be an overcomplicated (and quite buggy) mess that really adds nothing to the game that's perceptible to the player (well...beyond parts randomly exploding for no apparent reason). The more I work with it (and I've been doing so quite a bit since 1.03/4 came out last week), the more that impression is reinforced. I really do appreciate the attempts to explain it, but yeah, you're right in that for now I still have no idea why any of this occurred

Oddly, I have the exact opposite impression and think that 1.04 is actually the worst of the bunch. The new heat system in particular seems to have a number of bugs with randomly fluctuating temperatures, randomly exploding parts, and using timewarp during reentry seems to have become a non-option as it radically changes the behavior of the system. So yeah, if anything I consider it to be a step backwards from 1.02 in that at least its behavior was fairly consistent and predictable. I think I'm developing a Pavlovian response to say "oh oh" every time Squad announces they're adding a new features to these hot-fixes

Yeah, I hadn't edited them at all at that point (I do use that menu to turn on debug info though so there's always the possibility a miss-click did something), and changes done through ModuleManager don't get saved to the file, so I haven't had it occur since I started making those either. Anyways, just mentioned it as something to keep in the back of your mind if you happen to run into related support requests. I have no proof, and can not reproduce, so it's really nothing more than a suspicion on my part.

Hehe...yeah, that tends to decrease the efficiency of your rendezvous just a tad I've become somewhat skilled at guestimating the direction based on the compass headings on the nav-ball, but still will sometimes wind up flipping the desired heading 180 degrees in a real "doh!" moment that I only notice once the trajectory is established enough to show up on the map. Just occurred to me earlier that Waypoint Manager provides a much better way that is likely less prone to error

The stock interface involves clicking on pod hatches to get it to work, so it's a little inconsistent/tough to notice if you don't know about it in advance.

Actually, it wound up making reentry more deadly, but unfairly so Due to the 0.5 density exponent making the atmosphere effectively denser higher up in 1.04, reverting that to 1 without reverting the corresponding values in heating caused there to be an atmosphere band around 20Km or so where the aero thought the atmo was less dense than heating, meaning you'd heat up like crazy without slowing down sufficiently to compensate. Was like hitting a brick wall under most circumstances where things would heat up so much so quickly that they'd just instantly explode. I've since made a number of further adjustments to get the two working well together for BTSM, but it's no longer really something I can post as a straight revert to 1.02 aero/heat, as the heating system has changed sufficiently between the two that I don't think that's really possible anymore (at least not without writing a custom flight integrator). There also seems to be a number of bugs in the new heating system (particularly where time warp is involved, but I've also noticed a lot of other fidgety behavior that doesn't seem at all right) that further complicate matters.

Just noticed this. If you're in map view when a vessel splashes down, good times result: EDIT: Above screenshot is modded, but I verified with stock install as well: It's strictly a visual thing, so probably no harm done, but probably not intended either

Just came up with another use-case for Waypoint Manager that I wanted to share: You know when you're launching a lander from the surface of a celestial body and despite having it targeted, you're uncertain of the direction the vessel you wish to dock with is in, and which way it's going on the nav ball? I'm talking about stuff like pulling an Apollo style Munar rendezvous with the CM. Well, it just occurred to me you go into map view and plop down a waypoint with WM along the path of travel of the CM, and then use that as a navigation aid to guide your launch trajectory. Too cool. Definitely going to give it a try on my next landing

I'll 2nd PreciseNode as being a huge boon as the stock maneuver nodes are a huge pain to deal with. I play a very mod-light install myself (despite being a modder). The ones I always play with are: -PreciseNode. -Chatterer: no added functionality but HUGE added ambiance during flight. -Waypoint Manager: probably only needed if you play career mode, but also extremely useful for just plotting navigation points on the surface of Kerbin to tell you important stuff like where KSC is

Yup, exactly. I deleted my file at one point because the values had gone all wonky (including the disappearing affects previously mentioned), and let it regenerate. It took me awhile to realize I was essentially playing with completely different physics than what's normally in stock I can't confirm this part yet, and have no steps to reproduce, but it might be worth keeping in mind for your further support adventures that I have a sneaking suspicion there may be something in the game that causes the file to become corrupt. I've been running periodic diffs on the original to make sure that isn't happening, but have yet to be able to reproduce it.

I've been watching the debug displays for thermal during reentries, and I've seen large variances depending on whether timewarp is enabled or not, including a couple of hundred degrees in skin temperature that would instantly appear, disappear, and then reappear as I toggled timewarp on, off, and then back on. I actually came to look through this forum to see if others were experiencing similar issues, as I think the new heating system may not be behaving in the same manner with timewarp enabled as with it off.