NathanKell

Nice work! Just a note, in 1.0 Kerbin's atmosphere doesn't have a fixed scaleheight; instead it appears to follow an 80% standard model of Earth's atmosphere up to about 65km, after which it trails off. (80% as in 8km on Kerbin == 10km on Earth, etc).

The command pods have ~40% the surface area of their real life "counterparts"--the Mk1 is a Mercury analog (~1t mass with a chute and shield) and yet 1.2m in diameter not 1.9, and the Mk1-2 is an Apollo analog (~5t kitted out) and yet ~2.4m not 3.9m in diameter. 63% the diameter means ~40% the surface area means ~40% the drag means ~18.5% faster terminal velocity. Terminal velocity is based only on the Cd*S, mass, and air density. It has literally nothing to do with how high the atmosphere is, so can we all please leave that aside for the moment? (And note, it's 80%, not 66% or 60%--go ahead and compare 8km on Kerbin and 10km on Earth). Terminal velocity for the pods, even in 1.0.2, is a bit low. However, drag for planes is way too high. This doesn't mean "find some average drag" it means change how Cd is calculated so that pod Cds stay about the same but plane Cds go down. One thing to do this would be to add an exponent to Cd, so Cd < 1.0 gets lower (and the lower it starts as, i..e the more streamlined the part is, the more it would get lowered by the exponent).

Thanks, rhoark!

Brotoro: the hsps looked close to NTO and AZ50 for me, and the Isps match staged NTO/AZ50 pretty well*, so... *Not that we have examples, but there's lots of staged NTO/UDMH examples and AZ50 would be just a bit better.

Not to pick on you in particular since I've seen a lot of people do it, but...once again, static thrust isn't maximum thrust. The number you're quoting is the static thrust: it's the thrust at sea level on a standard day. It is most certainly not the thrust at Mach 1 at sea level, nor is it the thrust at Mach 2 a bunch of kilometers up.

I don't disagree in the slightest that drag is too high for planes. I do disagree that it's too high for capsules, and I challenge you to compare capsule terminal velocities in KSP 1.0.2 stock, and KSP 0.90 with FAR. At sea level, since the atmosphere up high changed.

In 1.0+ they're clearly modeled as verniers, to be used on lower stages to increase control authority, and in particular when you have only one main engine on the stage and want some roll authority (ignoring magicTorque from pods/cores/etc). The 1B as vernier for the .625 and 1.25m engines, the 24-77 as vernier for the 1.25 and 2.5, and the Mk55 as vernier for 2.5 and 3.75 engines. Though even 8 degrees of gimbal is not as much as real verniers have, it's rather a lot in KSP terms. If you want the equivalent in vacuum, you're probably better off with some RCS ports and a bit of monoprop for roll....

Sorry, I meant ResourcesGeneric. Oops. :]

I wasn't aware that heatshields actually reduced the density or velocity of air hitting them...I thought they just radiated heat well, and further cooled from ablation.

Apollo SPS: Redstone engine (about 5ft long). One of these had 4x the thrust of the other. Guess which. EDIT Oh and Krakenfour, I really don't get what your post was about. Looks like...an addon part maker decided to change how models were referenced for her/his 1.0 release of the mod? Again, MODEL was introduced in .20, though Squad parts don't use it often. Did you miss all the hoopla over 'welding parts' the last two years?

Even on airless bodies, ascent dV is highly sensitive to TWR (or rather, gravity losses are sensitive to ascent time). So your numbers were already ballpark. Indeed, due to drag, things even out a bit at the high-TWR range for aired bodies.

Almost nothing runs stoich, though; US engines usually run fuel-rich, both open and closed-cycle (the famous kerolox engines were about 2.25:1, hydrolox at ~5.5 or 6 to 1), whereas the Russians run ox-rich for their open-cycle engines and very ox-rich for closed.

Where there is much less heat. Heat is the limiting factor, not drag. Jet thrust is broadly proportional to dynamic pressure, so outside of heat (and excess intake drag) there isn't much difference between low and high in terms of max speeds. You need to make sure your airframe doesn't melt and your compressor doesn't melt, which means sprints speeds far higher than sustained speeds, and tighter thermal limits below 50,000ft.

The NTR has always had a higher (relative) TWR than other engines, as Renegrade points out. Indeed, the old NTR had about spot-on TWR for a 60s NTR, whereas the other engines have not just 1/3 to 1/6th, but more like 1/4 to 1/8th the TWR of even 1960s counterparts. As for what LF and Oxy are, I suggest you look at their specific heats in Resources.cfg. The new Isps make sense for those specific heats (max of 295-300 staged).

nope, conduction is for part-part conduction. The part's convectivity constant (see the shock cone intake's part cfg for an example) is a multiplier to convective flux.

1. Whatever a part's stats are when the game finishing loading, that's what stats it will have always, either on new vessels or on saved vessels, except 2. Any data marked persistent will be kept on parts, for example resource quantities (so if you change a part's amount and maxAmount of a resource, that won't change any of that part in ships in your save or in .craft files). 3. The same applies to module data: any data that isn't persistent will use the new values (and any removed modules will be gone, and any new modules will be added), but any persistent data will be loaded from sfs/craft, except 4. If a module changes name (i.e. old antenna module to RT2 antenna module) the old info is lost and the new info is entirely default, so e.g. antennas may return to being not-extended.

New to 0.20 you mean. (0.20 added MODEL node support.) As for nerfing--the Poodle and LV-909 produce 20% more thrust than they used to, and the Poodle masses less than it did to boot. The KR-2L maintains its 2000kN max thrust. Not sure where you're seeing nerfs. Now, their sea level thrust did go down, but that only affects the first few km on Kerbin.

How do you know the units are L? If they're L, they sure don't use much of the tank...

Lift during reentry allows two things: 1. Lowered G and max heating flux (though same total heat load, just takes longer) 2. Controlled landing site. Here's a video on how it works: Orientation always matters. Half the drag when Q = 5 is still half the drag when Q = 20,000. Pressure, up until about 68km, is an 80% Earth atmosphere (i.e. 40km on Kerbin is 50km on Earth). Temperature uses the same model, except that latitude and day/night affects temperature (though differently in different atmosphere layers). Density uses the atmospheric molar mass and pressure and temperature. Drag is 0.5 * density * velocity^2 * area * coefficient of drag. The last two terms come from the drag cubes and the drag curves.

I have a modest proposal. Why don't you open a wing file, change its dragModel from none to default, and then remove the ModuleLiftingSurface MODULE. Try that, instead of talking about how wings are ~~dragchutes~~. See whether they actually produce less drag.

Aero: 1.0.2 is spot on for blunt objects, but too draggy for pointed ones. This can't be fixed by just changing drag multipliers, the part's own drag coefficient (for each cube face) needs to be modified, say with an exponent in the range of 1-2 (testing will show what's correct). Once that's done, lift can get lowered again (to keep L/D constant for planes). Wing drag can also come down then to keep proportional, although wing drag at 0 alpha should come up (and wing drag at high alpha should come down, in relative terms). Thermal: In order to get back a somewhat challenging reentry, the convectionVelocityExponent needs to go up higher than 3, and the convectionFactor go down. However, to keep Eve survivable, the heat shield ablator's hsp needs buffing.

And watch as you have half the drag of FAR.

Actually, as of 1.0, the "intake drag" shown in the right-click menu is utterly meaningless. Intakes, like everything else except wings, use cube drag now, so changing part.maximum_drag (as the intake drag does) does absolutely nothing to the drag the part actually crates. So closing intakes does nothing other than shutting the resource intake off. It doesn't change drag at all. Convective heating is related to drag only so far as it's related to velocity; the quicker you slow down, the lower your total heat load. This means that if you can find a way to slow down faster without increasing your convective surface area, you'll get less heat. Compare a pod (entering rear first) and a Mk1 cockpit (entering nose-first). Both have the same cross-sectional area, but the cockpit stays faster longer (and even has more surface area) and thus will take on way, way more heat.

Correct. RSS-the-plugin is being replaced by Kopernicus, and there's reason enough why people on stock Kerbin would want KSCSwitcher (and KCT). Sorry, forgot to ping you about that, because yeah, it's very relevant to KCT... :\

Note: the only exception is if you need read/write access to the texture ingame (as in, for example, EVE's cloud mask, where access to pixels is needed to determine where to spawn clouds). In that case, stock KSP offers no support for keeping DDS textures readable, and thus you must load them in another fashion (as png, or using DDSLoader, or manually using the new DDS code).