NathanKell

I find that interesting, since 1.0 has had pretty much the _lowest_ drag. 1.0 had drag rather lower than FAR for blunt things, and a bit lower for tapered things. 1.0.2 had drag like FAR for blunt things, and way way more than FAR for tapered things. 1.0.3 has a bit lower drag than FAR overall, but blunt things are properly draggy compared to tapered things--it's about on par with FAR back in the .22 era, before FAR started applying more drag high up, let alone nuFAR with transonic wave drag.

You can just have CKAN link to your current dropbox storage. Just post in the CKAN thread in Tools and Apps, or hop on #ckan on espernet, and they'll help you out.

Cool! The KR-2L is clearly the J-2X and the Mammoth is clearly 4x SSME, and the Twin Boar is clearly the Pyrios booster. Other than that KSP doesn't really do analogues, excepting perhaps the OMS. So you're on your own there. RF 10.4 supports tweakscale btw if you want to try that.

Parts are set at the ambient temperature unmodified by sun/latitude upon creation, is why. They then heat or cool to the actual ambient temperature.

It's actually more modeled on the Von Braun shuttle / ferry rocket. (There's a model from Fantastic Plastics, actually.)

merkmuds: Realism Overhaul makes parts real. That involves totally changing their scale or even what they look like, and it certainly involves the real LVs being built out of different combinations of parts. You can't expect non-RO craft to work in RO. RO does include craft files for the FASA craft (Mercury, Gemini, Apollo...)

Thank you for catching that. I had uploaded the wrong file. PSA TO CKAN USERS: Please uninstall and reinstall RealFuels 10.4. You got the wrong archive due to my messing up.

Ambient temperature at KSC at mid-day is about 305C. It's the equator, after all. The thermometer part doesn't measure the outside temperature, it just reports the part temperature. That's why it's confusing.

You might like http://forum.kerbalspaceprogram.com/threads/117141-1-0-AeroGUI

In my experience OSX's limit for KSP is in practice <3GB, even though in theory it's supposed to be a full 4GB (unlike KSP-win32 where in theory and in practice it's ~3.4 GB). You combine a ~2900MB limit with the texture issue, and yeah, you can hit that stock.

Awesome!

Changelog for v10.4. Update for KSP 1.0.4. Ullage and limited ignitions now included, works like EngineIgnitor though the module configuration is different. If you set EI configs in your ModuleEngineConfigs CONFIG nodes, however, those will be read just fine by RF. Spaceplane part volumes and tank types tweaked for better utility. TweakScale support for engines.

Recompiled for KSP 1.0.4.

Renegade, your personal theory is in fact totally correct. Unity 4.x has a known bug where D3D9 on PC (and, sadly, the OSX/OpenGL version too) keep a shadow copy of all textures in system RAM even after they've been uploaded to VRAM, even if you explicitly tell Unity not to (as KSP does). The Windows OpenGL client does not have that bug. That's why you get ram savings, and why adding more parts barely increases ram footprint.

Combustion chamber burn-through? Oh yes. But engines are rated at a given chamber pressure, so they're not expected to overheat at all.

If you right-click at a desired spot and choose add key, you'll get the value there, I think.

Might want to look here: http://www.grc.nasa.gov/WWW/K-12/rocket/ienzl.html Also http://www.propulsion-analysis.com/docs/papers.htm

Daveroski: Nope, ablation works more or less like a standard exponential-rate chemical reaction: slow to start, speeds up fast in the middle, rate of climb slows after a certain point. There are very definitely "peak" ablation rates that thermal protection systems (and reentry corridors) have to be designed around. Let me give you an example: Mercury had approximately 250lb of ablator, IIRC. Only "a few pounds" were used on reentry. The peak skin temperature of the heat shield was around 2700F. Had the descent been all that much steeper, the shield probably would have locally burned through, despite having tons of ablator remaining. This is one reason why lifting reentries are so useful: while the total heat load is larger, the peak heating rate is much lower, which means temperatures can be kept low and much heat reradiated.

I suggest flying an ascent with Mechjeb's Ascent Stats window open. That will break down your losses to gravity, drag, and cosine (steering), and tell you the total delta V expended. It's really a necessity for optimizing ascents. Your drag losses will almost certainly be below 500m/s, while gravity losses are in the 1000m/s range. (2000m/s orbit in SRF, plus 1000 from gravity, plus 500 from drag, =3500 expended. But drag will probably be more like 200 or less).

Note that safe speeds will vary a lot with atmospheric density, so higher speeds are safer on Duna (and vice versa on Eve).

I'd be very surprised if pressure rather than density is used. Also, craft shape appears to have an influence, more tapered craft start the transition later.

#1 sounds fine, sure! #2...RF doesn't currently support insulation or a way to get around analytic thermal. I hope to work on that at some point before too long. Right now best you can do is use tank type Cryogenic, and turn down skin<>internal conductivity (since 1.0.4 stock also has skin/internal temperature divide).

And the repo is now OK again folks. Sorry, should have posted earlier. Ven, one note: Trying the latest in the repo, I really miss the engine models from the current release, I find the new (in the repo) "bands" atop the engine to be rather large and jarring compared to the rest of the thrust frame, I miss the much more skeletal look you had before.

I suggest getting a copy from 1.0.4 archive, then deleting the one in your KSP folder and launching KSP (to regenerate it), then diffing the two.

Going by the cfg, the spike isn't instantaneous (it starts at reference value 100 [which seems to be some product of speed and density) and is fully 100x at reference value 200). You can try varying those settings--changing the 200 to 400, say, or decreasing the multiplier--but part of the problem is that 2km/sec is so slow, and drag so high, that a lower multiplier than 100 (and a longer ramp-up) ends up making even incredibly steep descents survivable.