FlowerChild

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

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.

I can confirm this. Deleting the file and letting it regenerate not only turns off reentry visual effects, but also results in radically different values for some of the other entries. You're not just playing without visuals, the aero and heating will also be different. I think your best bet is to try to redownload the original file. If you don't mind editing and replacing the contents of physics.cfg yourself, this is what a fresh 1.04 download from Steam has in that file (I backed it up as I run periodic tests on my own to make sure it hasn't been corrupted during my modding): dragMultiplier = 8 dragCubeMultiplier = 0.1 angularDragMultiplier = 2 liftMultiplier = 0.036 liftDragMultiplier = 0.015 bodyLiftMultiplier = 18 aeroFXScalar = 1 aeroFXDensityExponent = 0.75 aeroFXStartThermalFX = 2 aeroFXFullThermalFX = 3.5 aeroFXExponent = 3.0 thermalMaxIntegrationWarp = 100 spaceTemperature = 4 solarLuminosityAtHome = 1360 solarInsolationAtHome = 0.15 convectionDensityExponent = 0.5 convectionVelocityExponent = 3.0 convectionFactorSplashed = 5000 fullConvectionAreaMin = -0.2 fullToCrossSectionLerpStart = 0.8 fullToCrossSectionLerpEnd = 1.5 machConvectionStart = 2 machConvectionEnd = 4.0 machConvectionExponent = 3 turbulentConvectionStart = 100 turbulentConvectionEnd = 200 turbulentConvectionMult = 100 machTemperatureScalar = 21 machTemperatureVelocityExponent = 0.75 partEmissivityExponent = 4 radiationFactor = 1 convectionFactor = 6 newtonianConvectionFactorBase = 8.14 newtonianConvectionFactorTotal = 4.0 newtonianDensityExponent = 0.5 newtonianVelocityExponent = 1.0 conductionFactor = 20 internalHeatProductionFactor = 0.025 aerodynamicHeatProductionFactor = 1.0 standardSpecificHeatCapacity = 800 skinSkinConductionFactor = 0.06 skinInteralConductionFactor = 0.4 shieldedConductionFactor = 0.01 DRAG_TIP { key = 0 1 0 0 key = 25 1 0 0 } DRAG_SURFACE { key = 0 0.02 0 0 key = 0.85 0.02 0 0 key = 0.9 0.0152439 -0.07942077 -0.07942077 key = 1.1 0.0025 -0.005279571 -0.001936768 key = 2 0.002083333 -2.314833E-05 -2.314833E-05 key = 5 0.003333333 -0.000180556 -0.000180556 key = 25 0.001428571 -7.14286E-05 0 } DRAG_TAIL { key = 0 1 0 0 key = 0.85 1 0 0 key = 1.1 0.25 -0.02215106 -0.02487721 key = 1.4 0.22 -0.03391732 -0.03391732 key = 5 0.15 -0.001198566 -0.001198566 key = 25 0.14 0 0 } DRAG_MULTIPLIER { key = 0 0.5 0 0 key = 0.85 0.5 0 0 key = 1.1 1.3 0 -0.008100224 key = 2 0.7 -0.1104858 -0.1104858 key = 5 0.6 0 0 key = 10 0.85 0.02198264 0.02198264 key = 14 0.9 0.007694946 0.007694946 key = 25 0.95 0 0 } DRAG_CD { key = 0.05 0.0025 0.15 0.15 key = 0.15 0.0225 0.3 0.3 key = 0.25 0.0625 0.5 0.5 key = 0.35 0.1225 0.7 0.7 key = 0.45 0.2025 0.9 0.9 key = 0.55 0.3025 1.1 1.1 key = 0.65 0.4225 1.3 1.3 key = 0.75 0.5625 1.5 1.5 key = 0.8 0.66 2.3775 2.3775 key = 0.85 0.8 2.733777 2.733777 key = 0.9 0.89 1.1 1.1 key = 1 1 1 1 } LIFTING_SURFACE_CURVES { LIFTING_SURFACE { name = Default lift { key = 0 0 0 1.965926 key = 0.258819 0.5114774 1.990092 1.905806 key = 0.5 0.9026583 0.7074468 -0.7074468 key = 0.7071068 0.5926583 -2.087948 -1.990095 key = 1 0 -2.014386 -2.014386 } liftMach { key = 0 1 0 0 key = 0.3 0.5 -1.671345 -0.8273422 key = 1 0.125 -0.0005291355 -0.02625772 key = 5 0.0625 0 0 key = 25 0.05 0 0 } drag { key = 0 0.01 0 0 key = 0.3420201 0.06 0.1750731 0.1750731 key = 0.5 0.24 2.60928 2.60928 key = 0.7071068 1.7 3.349777 3.349777 key = 1 2.4 1.387938 0 } dragMach { key = 0 0.35 0 -0.8463008 key = 0.15 0.125 0 0 key = 0.9 0.275 0.541598 0.541598 key = 1.1 0.75 0 0 key = 1.4 0.4 -0.3626955 -0.3626955 key = 1.6 0.35 -0.1545923 -0.1545923 key = 2 0.3 -0.09013031 -0.09013031 key = 5 0.22 0 0 key = 25 0.3 0.0006807274 0 } } LIFTING_SURFACE { name = BodyLift lift { key = 0 0 0 1.975376 key = 0.309017 0.5877852 1.565065 1.565065 key = 0.5877852 0.9510565 0.735902 0.735902 key = 0.7071068 1 0 0 key = 0.8910065 0.809017 -2.70827 -2.70827 key = 1 0 -11.06124 0 } liftMach { key = 0.3 0.167 0 0 key = 0.8 0.167 0 -0.3904104 key = 1 0.125 -0.0005291355 -0.02625772 key = 5 0.0625 0 0 key = 25 0.05 0 0 } drag { key = 0 0 0 0 } dragMach { key = 0 0 0 0 } } LIFTING_SURFACE { name = SpeedBrake lift { key = 0 0 0 0 } liftMach { key = 0 0 0 0 } drag { key = 0 0.01 0 0 key = 0.3420201 0.06 0.1750731 0.1750731 key = 0.5 0.24 2.60928 2.60928 key = 0.7071068 1.7 3.349777 3.349777 key = 1 2.4 1.387938 0 } dragMach { key = 0 0.35 0 -0.8463008 key = 0.15 0.125 0 0 key = 0.9 0.275 0.541598 0.541598 key = 1.1 0.75 0 0 key = 1.4 0.4 -0.3626955 -0.3626955 key = 1.6 0.35 -0.1545923 -0.1545923 key = 2 0.3 -0.09013031 -0.09013031 key = 5 0.22 0 0 key = 25 0.3 0.0006807274 0 } } }

Yeah, I agree the multiple shields/orbital assembly would be an extreme investment that's probably not worth it in terms of the time you'd have to spend as a player. I was just wondering if there was something I was missing with regards to the efficiency of a single shield (which you could always encase in a fairing for the trip up) vs. the fuel required for an equivalent maneuver at destination. I've also been fooling around with "folding" designs as of late due to the new aero which might present another alternative to full orbital assembly in cases where you require more than one shield. Stuff like this: Which I've been using with my mod due to the low-tech solar panels in it being a real pain to use. It's a lot less time consuming to perform a few docking maneuvers to rearrange parts in a single vessel than to perform multiple intercepts with multiple vessels. You'd also need that to lift the shield as well too though, which is why I think it largely comes down to which winds up weighing more (for a single shield design anyways).

I find this to be an interesting point, but is the weight in fuel to ditch 2000 m/s really less than that of a heatshield for your average vessel? Like, the wiki lists the mass of the largest 3.75m heatshield to be 2.8 tons, while a T-400 fuel tank is at 2.2 tons. As a rough guestimate, let's consider those roughly equal (or throw in another T-100 tank on top to even things out more), and I really can't think of many vessels that would be big enough to warrant a 3.75m heatshield, yet wouldn't weigh enough that they could produce 2000 m/s deltaV off a T-400. The way I'm looking at things, you'd have to transport that mass to Jool either way to make use of it, so it essentially all comes down to what is heavier: the fuel required for an equivalent burn or the shield for the aerobrake.

I love the premature release and the rapid series of radical game changing patches that followed. What? Wrong thread?