NathanKell

As always but ESPECIALLY this time it is vital you follow the installation instructions for both this (if you haven't switched to PP yet) and Real Fuels v5 when upgrading. Files have moved. Changelog: v9 =\/= *Final pre-Procedural Parts release *Moved RF tanks over to RF mod. Will no longer clutter partlist *Deprecate non-superstretchy tanks (available to old craft but hidden in part list) *Support RF v6 *Fix heatProduction for SRBs when using DRE *Add Version Checker (Majiir / Ferram) *Add "utilization" factor: essentially a hack to allow you to copy real rockets. Fat short tanks should have lower utilization; long tall tanks should have higher. Example values: Titan II lower stage: 0.87. Saturn V lower stage: 0.8. Titan II upper stage: 0.7. Atlas D through I: ~0.85. ***NOTE: you MUST rescale the tank slightly after changing utilization or the volume won't update. After that, you can scale it back.*** In combination with the latest RealFuels v5, tank volume errors on rescaling are fixed!

SpacedInvader: Yeah, also, I haven't edited the first post in forever (i.e. since v2 or so); it makes things sound much more scary than they are. As always but ESPECIALLY this time it is vital you follow the installation instructions for both Stretchy v9 (if you haven't switched to PP yet) and this when upgrading. Files have moved. Changelog v5 = \/ *Moved RF-related Stretchy parts to RF. *Add back missing HTP, N2O entries *Speed improvements from Ferram (thanks!) *ModuleEnginesFX support *Firespitter tanks don't change basemass now. *Fixed volume problems when rescaling StretchyTanks *Fixed ModuleHybridEngine (used for, e.g. the bi/trimodal NTRs). *Added Version Checker (Majiir, Ferram): RF will now warn you when run on a different version of KSP. *Added Starwaster's fixes to NTRs and to the HeatPump *taniwha: add support for resource/mass updates

Wut. I think you mean centimeters? 75m is...taller than most rockets. Productive point: don't stress over facecount. For 99% of KSP players (sorry Ferram! ) GPU is underutilized and CPU is the bottleneck. As long as the collision mesh is low-poly, should be fine.

Nope, *any* vessel that is not the current vessel gets deleted if: *pressure is >0.01 (aka lower than 25km) and *not landed/splashed. What you may be thinking of is the fact that if there's no core aboard, condition (2) sometimes doesn't hold, i.e. it gets deleted even if safely landed/splashed.

HoneyFox, I'm wondering if the numbers need to be tweaked some, maybe? I know Apollo used a "few second" RCS burn to settle fuel prior to SPS ignition, and that's 4x490N thrusters settling ~18 tons of fuel (out of 29 tons of craft, or 44 counting LM) in a few seconds. That certainly doesn't happen with EI. On the other hand, if we make propellants *too* susceptible to acceleration, then drag will make it very hard to light lower-altitude upper stages.

Update this mod and update Real Fuels.

Sternjaeger, Nadel, Saber: Stretchy Conic (press b a few times to get desired curvature). Swift, Viper: Firespitter nose intake. Attacker, Dart: Firespitter oblong tail. Falcon: Stretchy Conic tank + rescaled and repainted Rocket Nose Cone (as 340kg warhead in RftS pack) Schwable: proc fairing interstage with egg sides, 340kg warhead nose (see above). Sometimes I add a Communotron 16 (unextended) to the nose when using a Stretchy conic or the FS tail; it looks like a pitot tube and it closes the node to avoid open-node drag.

AIES has some larger static panels. Fusty's Station Parts mod has a large static one too.

Some miscellaneous stuff I've built over the last few months. Some may or may not appear later in Reaching for the Stars. VAB: SPH:

I haven't looked into it yet, but that sounds totally doable. Just adding an action that's VAB-only that switches to next config. No idea about the generator issue then. Weird.

Hodo: what you posted is the info dump showing the original values for various paremeters. What I pasted under that PQSCity { KEYname = IslandAirfield repositionRadiusOffset = 40 } is what you should add to the cfg, just under the original PQSCity {} node.

Two known issues. 1. Can't add/remove < 1E-5 units of an ALL_VESSEL resource (it always fails.) This was "added" in 0.23, likely as a fix for the new way jets handle lowering intakeAir. 2. ModuleGenerator is broken, especially under warp.

Good news for me, since I rename them all anyway in RftS. Nice rework, btw! I like this one better.

Ah, gotcha. Thanks!

It is the default, yes. Having physics disabled is useful for very-low-mass parts as otherwise they wobble a ton (which is particularly bad when you have a heavy engine on a cubic strut attached to a heavy tank). Note that IIRC everything with module = Strut also has its mass ignored inflight.

Huh. Weird, that problem usually arises because Windows locks down Program Files. rbray: here's a clearer picture. Any ideas?

Did you try using the code snippet I supplied?

That's pretty much what TR is *designed* to do... What you can't do with TR is replace textures loaded from GameData, IIRC.

True Incompetence: Thanks! Regarding 1: weird! Never seen that happen before. Modlist? Regarding 2: I haven't looked into it that much; I don't offhand know why it's doing that. One thing you can do is keep the cursor above the altitude readout (where the recover button appears) and keep click; eventually you'll click right when the recover button appears for a millisecond, and it'll recover. Alttabmatt: Never heard of that. Modlist? Output_log.txt from after that happening?

It's not that terrain is smoothed out by design; it's that with the maximum possible resolution heightmap each pixel is about 5km x 5km. In the current pre-release (see Aazard's post above) you can see some decent attempts at getting PQS working better. But please, please feel free to tweak more! I just played with them enough to get something better, not something perfect/right. Other planets can have the settings too, but not all planets have the same PQSMods. Krag's suggested (and offered code for) going to a generic PQSMod data loader, which will make things much better (and easier to set PQSMod data for arbitrary planets). So if you see that Duna has PQSMod_SimplexHeightAbsolute or whatever you can just copy-paste the node (and the PQS {} block around it) to Duna's node and edit that.

SpacedInvader: KIDS still doesn't quite work with RF. For now what I suggest you do is apply KIDS "manually"--that is, remove KIDS, and then open RealSettings.cfg (in the RealFuels folder) and for each key = 0 n or key = 1 n line, cut n to 1/3. i.e. TLISP0 { key = 0 286 key = 1 100 } becomes TLISP0 { key = 0 95.3 key = 1 33.3 } That said, how much of a "proper release" do you need for RSS? It's been game-stable for months, and now features the correct textures and heightmaps for Earth and most planets in the solar system. I mean, KSP *itself* is in alpha; don't be dissauded by the ALPHA in the RSS thread title. HoneyFox: there's a prerelease a page or so back Here: https://www.dropbox.com/s/brn9mxzvc82x4i2/RealFuels_v4_4_pre2.zip Scripto23: they should only be lighter than default for cryogenic fuels. They should be heavier for non-cryogenic fuels. Starwaster: you're thinking of balloon tanks. Camacha: What does your script do?

rbray: I'm getting a weird cloud issue, where clouds seem to stop along a rectangular edge (occurs only at certain altitudes). This seems possibly related to the "fade out" thing. I've been messing with detail distance and rim power/falloff to try to get them working better with RSS (and to minimize fadeout, since with RSS a *giant* area fades out). Relevant: shader_floats { falloffPower = 2 falloffScale = 300 detailDistance = 0.005 minimumLight = 0.15 } underside_shader_floats { falloffPower = 1.8 falloffScale = 1000 detailDistance = 0.01 minimumLight = 0.5 }

Oh, right. Steam version in Program Files?

Really cool craft, folks! I'll have to post a few of mine too... The dV map is accurate if and only if you use FAR. Note that the dV for reaching Earth orbit assumes, I think, a non-equatorial launch and decent gravity losses; if you're launching from the equator and have a high thrust ascent, you may be able to get under 9km/sec total dV expended. And of course if you're not using FAR, add another km/sec or two of "soupodynamics" drag losses.

Excellent job on these!