NathanKell

If you saved as much from air-launching in KSP as you did in real life, you'd need... wait for it, amazing savings! ... ... 4200m/s. Yeah, that 300m/s is totally worth air-launching for.

Shania_L: Squad decided to hardcode those values for now; changing them breaks the Addon Posting Rules as written.

I don't think HyperEdit's changes are permanent, but I might be misrecalling.

Holy smokes that's awesome!

And even then, IIRC that won't move anything already attached to them; you'll need to move the attached parts yourself.

The stack trace tells all: onShipModified is being fired at a time when RCSBuildAid does not expect it to be fired, and thus freaks. (RF fires it whenever fuel level or engine config is changed, and that may be during *loading* of a vessel, not just once editor is fully loaded). Suggest you add checks to your onShipModified method to make sure you're not throwing.

# means has-key-of-this-name (#title[foo]) ~ means does not have the key (~breakingForce[]) @ means has node of this name (i.e. @MODULE[foo]) ! means does not have a node of this name (!Model[])

Bindings might have changed just enough to not screw things obviously.

Seems relevant: http://forum.kerbalspaceprogram.com/threads/109956-Volumetric-ring-system-Rings-with-EVE

Wright-Curtiss H-27 Starship (Apr 1936): With the future of the "hyper engine" looking doubtful in the early 1930s, and bombers outperforming many of the hunters then in service, the USAF let a contract asking for radical proposals. Wright-Curtiss, despite being the oldest of the United States's aircraft manufactures, maintained a reputation for innovation and the futuristic-looking Starship was their answer to the challenge. The Thunderbird was also accepted into service under the aegis of that contract, though it was only ever deemed a stopgap, given the compromises it made in armor and armament to achieve its speed. The Starship made no compromises whatsoever in any of those realms: if one engine would not be powerful enough, then two would be used on a highly-streamlined aircraft little larger than most singles. However, being the first aircraft to truly run into compressibility effects--before aeronautical experts knew what they were--meant the Starship had a long and difficult path to operational capability and the C variant. At its introduction in 1936 it was by far the fastest hunter in the world at 423mph, and when reengined for the finally-mature hypers it could keep pace with most newer hunters, though with its early-30s aerodynamics it was no longer the fastest. H-27C: 12522lb dry, 15873lb loaded, 2x1520HP, 423mph, 1x 20mm cannon, 4x .50cal MG. H-27E (1938): 12853lb dry, 17416lb loaded, 2x1920HP, 460mph, 2x 30mm and 3x 20mm cannon. H-27C in bare-metal finish, 1937. H-27E prior to transport to southern France during the Intervention, 1939

Watch the to see Mu talk about the terrain.Procedural means "the mesh is not created outside the game and then loaded, it's created by the game." It says nothing about whether that mesh is randomly generated, or (as is the case with KSP) pseudo-randomly generated from a fixed seed. In particular, while much of the planetary (moonetary?) terrain is created based of noise functions and fractals, that doesn't mean it's random or that it will ever change. If your function is (add three, output, multiply by four, output, divide by seven, output) and you give it the same input (seed) it will always give you the same outputs. The only way terrain will appear to change is if you change your terrain detail settings in the game graphics options, and that's not because the height the terrain should be changes, but because with a lower (or higher) resolution mesh created, the appearance may change. Quick example: Think of the planet in 2D. It's a circle. However, you have to make it into a polygon for the game to render it. At low terrain detail, it's an octagon; at high detail, it's a 12-gon. That means that for any given point on the (2D) surface, what was once angled at low detail may be flat at high detail--but that's not because the underlying terrain (the circle) changed, just the resolution at which it is represented and thus the final product you see. The old "changing ocean detail in the settings.cfg file" trick, to speed up performance--you know how that changes apparent sea level? Sea level doesn't change, but the number of polygons used to, which means /\ becomes _ near you, and so the area near you is flatter (and thus lower). EDIT: to follow up, if you are at PQS level, everything is procedural. Just because the mesh is created procedurally from a static heightmap as well as some seeded noise functions doesn't mean it's any less procedural. Only when you get high enough and KSP switches to 'scaled space' view of the body do you instead get a static mesh with a static texture.

mr_trousers: that's a...really good point. Oops. rundmcarlson: Please follow this guide. Hallebumba: the same.

Shaun: yes, that's with Proc Parts. Three of them, as I recall, for the fuselage, plus two for the fore and aft cones attached to the canopy. Then proc wings for all wing surfaces.

v0.23 - Arbos: update RS-68A node. - Set costs for B9 Procedural Wings. - Fix Proc Parts (they are now no longer shown as non-RP-0). - Hide unsupported VSR engine duplicates. - Tweak how non-RP0 tagging is shown.

No, FAR does not "respect" the physicsless flag. Nothing should, especially since the making of the 3.75m decoupler (all 3-odd tons of it) physicsless is the source of full crashes. The real issue with FAR is open nodes, however: if you use cubic struts, make sure you put antennas on any open nodes.

You're going to need to do the following to get accurate performance: 1. Use AJE to get real jet performance 2. Match wing area (main wing ONLY, disconnect the rest, then go to FAR->Stability->Calculate to get area) and then put it all back together and calc again to get Cd to try to match. 3. Match atmospheric density (3000m on Kerbin is *not* 3000m on Earth, it's more like 5000m). Emphasis on Point 2, especially the latter half. Do *not* expect Cd0 to just magically match if you're clipping god knows what. EDIT: Actually, even bigger emphasis on point 1. Without AJE, "jets" in KSP are just rockets that magically use air as fuel. They are not jets, and will not perform as such. This is E.28-inspired, and with a detuned Welland performs about right in RSS (so altitudes do match).

Great to see this in Releases!

Why yes, indeed they do fly.

To convert to 10x Kerbol pretty much the only change would be swapping the city lights mask (main.dds) for a Kerbin-based mask... Well, and removing the EarthSurface and EarthColor textures obvs, and any other bodies'.

chrisl: Astronautix is good for this. As for the Atlas boattail, we'll look into it, it's supposed to unlock in the same node as the fuel tanks and engines.

You installed "FAR to Real life". That means you now need a rocket as powerful as real life to get into orbit. That means a rocket that, without KIDS, would give you 9.5km/sec of delta V. With KIDS set to that preset, see how much delta V your rocket has. If it has less than 3500m/s, you are not going to space today.

Glad this all got sorted out! Moved to Add-On Releases now that, well, it's a release.

That sounds most interesting...

Tidus Klein: that sounds like you have too high a TWR. What is your min and max TWR for each stage, and their burn times?

Make sure you have Smokescreen installed and that there are Smokescreen_* folders inside RealismOverhaul...