NathanKell

A request: please disable the resource switching (but leave the mesh switching enabled) in the presence of a ModuleFuelTanks module?

camlost: the RAPIER is a SABRE with the serial number filed off. I'd suggest treating it like one. Just smaller/lower thrust than the big B9 SABREs since it's 1.25m.

Beale: basically, whatever license you select is ok. The main point is, a license lets you control what happens to your work. If you don't want anyone doing anything, or want full control, you can use "all rights reserved." If you don't mind people using your work as a basis, as long as they give credit and release their own derivatives under an equally-open license, you can do the common CC-BY-SA license. BY means any rereleases and derivative work must credit you; SA means share-alike: any of those must retain the same "give credit to original author, allow derivative works" stipulations. If you further don't want people to make money from your work, you can add "non-commerical" (the CC-BY-NC-SA license).

Hmm. Ok, then I'd suggest using Procedural Parts, as that probably supports what you want (and is the replacement for Stretchy).

While I fully support your not including anything you'd rather not (and it's just config edits anyway, since visually they were quite similar) the F-1A was operational by the end of the 60s. There just weren't any new-build Saturn Vs to stick it on. Also, that pic is from "NASA/USAF Advanced Development Program (ADP) Aerospike Engine" from this page. I don't think it's the J-2T, but maybe the ADP AE was developed from it?

Let us assume you use ATM (and therefore TGA textures will be compressed; stock KSP has an issue where they won't). Let us also ignore anything except textures, since models take up next to no memory, and cfgs even less. All textures in GameData will be loaded by KSP, and converted to DXT1 (if they are 3-channel RGB) or DXT5 (if they are 4-channel RGBA). The only exception are textures flagged as normal maps; these will be left uncompressed. DXT1 has a compression ratio of 6:1. DXT5 has a ratio of 4:1. That means that a 1024x1024 DXT1 texture will take about 512KB of memory, and a DXT5 of the same resolution will take 1MB. Note that this has very little relation to size on disk. MBMs are uncompressed on disk, so they will take up 1/6 or 1/4 their disk space in memory. PNGs, by contrast, can have much higher compression ratios than DXT; a 200KB PNG might end up taking 1MB of memory.

This is awesome stuff! Thanks! And, as awesome as RPM is, I like that there's a screen-free IVA, since I plan to use this stuff for RftS. Quick question: what's the license on these parts?

The aerospike from NovaPunch2 is a much better fit for the J-2T-2*0K IMO. The J-2T line as you can see here were toroidal (hence T) plug-nozzle aerospikes, not full "spiky" ones like Squad's.

Does the tweaked fuel return on launch or something?

ThorBeorn: yeah, I have reached the point where I can no longer load all parts at all times. This is one reason SXT is awesome, though, since it reuses existing textures and thus has a minimal footprint. I'll check the LR88-4. Thanks!

SpacedInvader: a good rule of thumb is to divide dV evenly between stages. However, that holds only when the Isp is similar across stages. If your upper is hydrolox, it makes sense to make it proportionally larger (like 3:2 or even 2:1, although the latter implies a long burntime). As with all these things, if you want a good starting point, try replicating real launchers. Make each stage as heavy as it should be (adding ballast if necessary), give it the appropriate fuel and thrust, and see how it works. There's little reason other than flavor to go with any approach except the one that seems easiest / preferable to you. I like variety, so I generally try all sorts of approaches (apogee kick solids, low-TWR long-burn hydrolox, high-thrust hydrocarbon, etc). pingopete: cool. I'll also check on the gray stuff. griffin247: recall that RSS is the real solar system. You don't have to ask KSPers when you need information; you can google information about real rocket science. For instance, Wikipedia's DeltaV tables.

Probably fine. KSP is very much CPU-limited, due to physics and to dynamic terrain being CPU-side.

combat squirrel: yes. Open ATM's config file (in the ATM folder) and find the line scale = 2 Change it to scale = 1 That will keep some of aggressive's scaling, but not all, and should have much less reduction in visual fidelity than normal aggressive, while still freeing more RAM than basic.

Yes. The next version of PP and Real Fuels with be in much better sync, and the next version of RPL will integrate much better with PP.

Yeah, CoM is *way* too far forward of AC. Move the fore wings forward, or add ballast near the tail.

Why would that be? Since Soyuz's sea level TWR is about 1.38, it's perfectly in the range.

SpacedInvader: Falcon 9 v1.1 has the highest upper stage starting TWR I'm aware of (for LF rockets), at 0.92. Proton comes close at 0.86. Delta II, Delta IV, and Atlas V all have around 0.25 starting TWR, but they're optimized for GTOs. You probably want to start somewhere around 0.5-0.7, as you say, depending on how high your lower stage is lofting you, how much dV your upper stage must make up, and how high a final (or parking) orbit you want. The lower the orbit, the larger the proportion of dV is in the stage, the higher a TWR you'll need (really, that is to say, the shorter the amount of time you'll have). When you circularize after apogee, i.e. into a lower orbit, you must then burn radial to lower your apogee; that's part of the circularization process (accelerate to orbital velocity + counteract gravity, rather than traditional circularization where you just do the former). And yes, you'll have to make your lower stage loft you higher. However, this can still be more efficient (or at least cheaper! Since tanks and fuel are cheap, and engines are expensive) than investing in a higher-thrust upper stage, even one that would lead to a lesser expenditure of dV. You have essentially three "good" options for your orbital stage. 1. Super-high-TWR solids that fire at apogee (Juno I/II, most all-solid launchers, etc.). 2. Medium-thrust liquid stage that circularizes at apogee (or shortly after). TWR as you say. 3. Low-thrust liquid stage that circularizes well after initial apogee (needs to be lofted higher by lower stage(s), and spend time burning at >0 pitch after apogee). #1 is best when you don't have reliable startable engines or good upper-stage guidance ("point level to earth, light fuse at apogee" is much easier for 1950s tech). #2 is best for LEO, especially low parking orbits prior to other things occurring. #3 is best for GTO, but can be used for LEO missions as well (probably not as efficient, although perhaps as above cheaper, than #2). But for GTO, your payload mass is less, you get lofted, if not higher, certainly with a higher initial velocity from your lower stage, so 0.25 TWR makes sense. #4 is high-thrust liquid upper. It's like a solid impersonating a liquid, IMO. You have to treat it more like a solid: don't fire it until you know it won't finish the burn until after apogee. pingopete: I will check the ocean-gray thing, which I haven't seen. But EVE Overhaul *does* mess with specularity, and removes normal maps and the blue ramp shading at the world's edge. Also, nothing past Overhaul-8 works right with RSS, and even -8 doesn't work if "wrap" is on in RSS. rbray is aware. As for launch sites: no icons are being displayed on the planet in tracking center? There are no buttons on the upper right screen edge for it?

xandalis: Upload your output log (NOT ksp.log) to dropbox or something. Windows: KSP_win\KSP_Data\output_log.txt Mac OSX: Open Console, on the left side of the window there is a menu that says 'files'. Scroll down the list and find the Unity drop down, under Unity there will be Player.log Aka Files>~/Library/Logs>Unity>Player.log Linux: ~/.config/unity3d/Squad/Kerbal\ Space\ Program/Player.log Lord Aurelius: huh. That's weird. I'd suggest taking this convo to the RSS thread, since this is for Realism Overhaul (which patches parts) not RSS. No idea at this point, but if you ask over there maybe someone can confirm?

With ModuleManager?

SXT is required for the three resized intakes. As I hope the readme made clear, RftS uses parts from those packs to do things; it's not setting out to support every thing in those packs. I do plan to expand RftSEngines though to support some SXT engines, also HGR and blackheart's work. Britain needs some LUV.

Well. There is a class of solid meant to be fired *at* apogee, like Juno's cluster of Baby Sergeants. Final TWR about 50 on those.

SpacedInvader: whoops, forum outage. 1.14 is *very* high. Consider actual rockets from real life: Atlas's SEC has a starting TWR of like 0.3! That's low for LEO but fine for GTO. Most start at about0.5 to 0.7 or so. Even something with an abnormally high upper stage TWR, like Titan II, is only 0.9 or so. If you want to keep using a stage with that high a TWR, you'll lose a bit of efficiency, but you still can. Just...don't engage it immediately after staging away your boost stage. Wait until time to apogee hits about a minute less than your stage runtime. Basically, ideally you want your stage to burn out precisely at apogee, but recall that burning even horizontal will extend time to apogee, so you want to start burning when there's more stage time remaining than time to apogee remaining. manni01: Try the FAQ in the wiki, linked in first post.

Good luck! Don't even need ALT+D+R for that, DRE enables temperature display on all parts by default.

technogeeky said they'll get it working better. (And SCANSat does actual mapping, it doesn't reveal some kind of premade map, so it does work, the issue is just it takes forever).

Oh, there definitely needs to be support for scale in MODEL nodes. And it's probably best to support scale-in-MODEL-node+rescaleFactor-not-1.0 stuff. I'm just saying there's *other* reasons why the latter is dangerous.