NathanKell

Please follow the guidelines in the READ FIRST sticky.

They do work as tangents, but the value stored is a slope (since the x-displacement is fixed). Hence "per se". Though I don't mean to quibble about terminology, so I'll shut up now. Felbourn, to follow on you can indeed compile it as a partmodule, add it to a dummy part, and that way use it ingame. HoneyFox also has an ingame floatcurve editor, in Tweakable Parameters.

Unless anyone has a strong objection, I will move this to Tools and Applications, since it is not the sort of thing that can be done by plugin*, and we're currently talking about out-of-game tools. *You would literally have to reload KSP, even if you could get it to reload assemblies, which you can't really do now. So it's not something that a plugin itself could do, or, if it could, there would not be a point.

Alas there's no easy way to know, sorry. It's basically just 1. The stock heat shields that come with DRE 2. Any heat shields that are part of packs listed as "supported" in the OP. Proc Parts' heatshields are not supported.

What Starwaster is saying is that DeadlyReentry does not modify ambient temperature. It adds heating when in an atmosphere, based on the (incorrect) assumption that that atmosphere is Earthlike. What it does not do, and what RSS can do, is modify the curves that govern ambient temperature; these are ingame variables called temperatureCurves (same format as an atmosphereCurve or any other floatcurve / animationcurve). However, RealHeat (forthcoming) will try to model solar flux.

raidernick: great to see the release! I am *so* using this. What did you think about what I mentioned re: Pioneer 3/4 btw? Every reference I've seen says the probe was covered in gold film, which was *then* painted black-white, so it should be gold-black and gold-white, rather than white and gold. Gunter's page (which I trust a *heck* of a lot more than, say, wikipedia) has a pic showing that. Also, I really do need to make (or ask someone to make) a new solar panel plugin that supports rings of panels...

It's a known issue with doing that. The only fix thus far proposed was to leave Kerbin in two places in the orbits list (i.e. not remove it from the sun's list of orbiting bodies) but that causes its own problems.

looks like you could use @MODULE[TESTModule] { @examplevalue ^= :$:; value4: } (the docs explain more the ^= feature (reg. exp.))

Thankfully, someone has.

Nope. Not hilarious. People are scarily cavalier with their kerbals as it is; making KSP into more of a blood sport does not fit with the notionally family-friendly aspect. Levelord: um, no. Unless what you were really arguing was "it's a major bug, but Harv et al have bigger fish to fry right now" which...does not seem at all to be what you were arguing.

Nope, it's rbray's ground-up rewrite of EVE. I.e. an overhaul of it. It just happens to work a lot better with RSS than 7.x did.

No, I mean the releases in the root of the repo. Go here, click appropriate KSP version (x64), click view raw to download.

This is very true, but it cuts *all* ways. For that reason, it seems it is not a useful argument on any side. We simply don't have information, and we should never assume there is a Silent Majority on anyone's side.

I suggest you use EVE Overhaul (download the release from root of the Overhaul branch of EVE on github). 7.x has serious issues. You can also check out pingopete's RVE thread in Dev, although that hasn't been updated recently, waiting on rbray doing more work on Overhaul.

My pleasure!

nothing to override; just use public void FixedUpdate

Thanks so much! Looking awesome!

Excellent! Here's the actual math behind how Unity/KSP evaluates tangents. Indeed they are not tangents per se, but slopes (which depend on the displacement in both x and y between keys). Oh also, MuMech CurveEd, so you can edit ingame. http://svn.mumech.com/KSP/trunk/MuMechLib/FloatCurveEditor.cs

OnFixedUpdate is run by KSP, only when the part is active (and only works on PartModule-derived classes). FixedUpdate is run by Unity, always.

Reichtangle: I'd suggest giving yourself a one-request-a-week quota.

Yep. I'm even a contributor on that project (although I've done little other than chat and answer questions so far because ~time~) and it will be the plugin-successor to RSS; RSS will become only a config and what little bits of its own plugin Kopernicus doesn't implement. Ralathon: Sorry, I got nuthin; I'll try landing over Arabia when I get a chance. Can anyone else confirm/deny?

1. Thrust correction takes 6 lines of code, across three modules (2 per module in ModuleEngines, ModuleEnginesFX, and ModuleRCS). They break down as: 1 line to change the thrust to thrust * realIsp / atmosphereCurve.Evaluate(0), done before fuel is requested. 1 line to change the GetInfo display to show both sea level and vacuum thrust in the VAB/SPH The thing is, though, that it *does* change how upper stage engines (LV-909, LV-N, etc) behave at sea level quite severely (for instance, LV-N loses three quarters of its thrust), and therefore in the eyes of the devs probably requires some balancing work, which might well be the actual reason why Harv's response above is the one it is, since changing six lines of code is not exactly a timesink. 2. The legacyAtmosphere model that Kerbin and other planets use works as follows: atmospheric pressure = e^(-height / scaleHeight), times a multiplier (1.0 for Kerbin), where height and scaleHeight are both in km. It is clamped to 0 when the result of the exponential (e^x) drops below 0.00001. The variation from sea level to cutoff is entirely smooth; don't be fooled by the gauge displayed in the GUI with its bands, it's just a gauge. You can use a mod like graphotron to plot it. What you might be thinking of is temperature, which does have bands in real life. As for why people fly the pitch programs (aka not-gravity-turns) they do? Because 1. It's best to get out of the souposphere as quickly as possible, so fly straight up. 2. Since drag does not depend on surface area or orientation, turning your rocket off-axis so it's no longer streamlined doesn't actually increase drag, so there's no reason other than steering loss to make as sharp a turn as you can. However, I'm pretty sure you'll find a gradual turn starting at about 7-8km will be more efficient (although slightly harder to fly, the third reason people don't). In fact, if you dig through the challenges in the Challenge forum, you'll find that those pitch programs are the most fuel-efficient in the stock atmosphere. EDIT: As for g0, it's off by a factor of 0.1%, not 10x. The correct value, used everywhere else in KSP, is 9.81 (technically 9.80665, but KSP rounds). However, only for engines, 9.82 is used. The only effect that has is to make engines ever so slightly more efficient than their Isp says they should be (since Isp, when given in seconds, is exhaust velocity divided by g0). It has nothing to do with planet size (????) or bouyancy; the latter issue appears to be that masses are not converted from tonnes to kilograms for the buoyancy calculations.

Just popping in to say--keep being awesome! Love the stuff you're doing.

My understanding is that's what camlost is working on right now (while still somewhat busy in RL). AJE will more or less hold constant, since the changes I've been making to the propeller model makes more sense as a different mod, as does ferram's rewriting of the jet code. So expect to see a thread from ferram and me in the dev forum at some point soon, and more info from camlost on SJE/BJE/whatever.

"Capsule drop" Which your rockets are shaped nothing like. Let's recall that FAR and NEAR are *all about* having shape *matter*.