NathanKell

Have you looked at the MechJeb thread recently? Or clicked on the author's name and checked last activity? I'd say sarbian is pretty active.

If you want to play around, grab the distribution/GameData/Kopernicus folder from KSP-RO/Kopernicus/revertBranch and grab regex's KSCSwitcher and grab KSP-RO/RealSolarSystem Thanks everyone.

nuFAR has much larger body lift and body drag than oldFAR did (in part because the shape of parts is finally correctly recognized, not just assumed to be conic frustums), so you need much more control authority to counteract aero forces on unstable vessels.

That looks basically right, although that means that at roughly 6km on Kerbin (where density ~= 0.35, so /1.225 it ~=0.3) you'll also get a multiplier of 0.18. atmChangeFlow has nothing to do with oxygen. However, you will need to create a ModuleResourceIntake that does not check for oxygen and creates a resource that your engine uses (intakeAir as collected by the stock intakes, well, the stock intakes check for oxygen).

ALIVE! Hurrah!

Great start!

Ingame? Or is that from reading the cfg file? (heatProduction is scaled by part mass in use).

The mod with comets is Alternis Kerbol.

http://forum.kerbalspaceprogram.com/threads/70881-0-25-Orbit-Manipulator-Series

CoL isn't actually meaningful though. Stability comes from the aerodynamic center being behind the center of mass, and that (obviously) takes drag into account as well. Think of a finless rocket. It either will or will not be stable, depending on the distribution of drag and mass. And yet by definition it has no CoL. Now think of a rocket with some fins at the back, but a giant bulbous fairing at the front. CoL will be in the back, but it won't be stable, because the torque from drag when it's off-prograde will outweigh the torque from lift.

It's far from impossible to have on-rails thrust, Orbit Manipulator has done it for over a year...

Gfurst: thanks! Lack's SXT comes with the fuselage parts, then I wrote Realism Overhaul configs for the size and mass to be correct and an AJE config for the IO-550 to be correct. The wings are B9 proc wings (download from the Addon Dev forum, then go to the last page in the thread for Crzyrndm's patch). I've actually made a bunch of replicas, stretching back to .24. They were to tune engine performance so I could figure out how all these creations would perform. I have yet to try anything but the Bonanza with nuFAR however, and AJE props aren't quite all there in 1.0 yet.

As promised, albeit delayed, here is a guide on how to make airbreathing engines in KSP 1.0+. What's Changed A number of things have changed for airbreathers in 1.0. First of all, velocityCurve is dead and gone. ModuleEngines (and ModuleEnginesFX, which now derives from ModuleEngines) don't support it. Second, the Isp bug relating to air has been fixed. Third, airbreathers now have fuel flow (and thus thrust) proportional to density and mach, and use two new curves, atmCurve and velCurve and three new boolean variables (atmChangeFlow, useAtmCurve, useVelCurve) to tune that. Fourth, four new number variables are supported for tuning performance, machLimit and machHeatMult, flameoutBar, and CLAMP. All this means that airbreathing engines can be simulated much more realistically in KSP 1.0, but making them takes a bit more work. FloatCurves It's worth noting that, if you didn't know, FloatCurves are a wrapper for AnimationCurves, which are Unity's way of implementing cubic bezier splines. FloatCurves can come in two forms: key = x y, and key = x y in out. The first mode makes Unity calculate the tangents itself, in the latter mode you specify the tangents. Please see here for more details on FloatCurves (though note that any reference to 'velocityCurve' is obsolete). Parameter Overview atmChangeFlow. The key thing to use, and that tells KSP your engine is an airbreather, is atmChangeFlow. If false, then atmospheric density has no bearing on thrust (i.e. you're no longer an airbreather). It defaults to false. ignoreForIsp. Next, the PROPELLANT nodes have a new option. You'll see that for IntakeAir, stock airbreathers have `ignoreForIsp = True` set. That means that, properly, the mass of the air you're breathing in is ignored for Isp calculations. In .90 and earlier, KSP included that number, which meant that airbreathers (with a 1:15 ratio of fuel to air) had 16x the Isp they said they did. Always use `ignoreForIsp = True` when using IntakeAir or any other generated resource, unless no other resource has a density. You'll have to leave it out if you're making an electric propeller; in that case, Isp will describe the mass flow of the engine rather than the mass flow of the fuel used. useAtmCurve and the atmCurve. If atmChangeFlow is specified but useAtmCurve is false, then flow will be linearly proportional to density (1x flow at sea level, declining as density declines). If true, then the curve is used, which relates density (in kg/m^3 divided by 1.225, so 1.0 at sea level) to the flow multiplier: the x (time) value of the curve is the atmospheric density/1.225, and the y (value) value of the curve is the flow multiplier. All stock airbreathers use the curve to better control thrust at altitude. If you're designing a jet engine you probably want a curve somewhere between the basic jet engine and the turboramjet; if you're designing a scramjet, you probably want the flow to start at 0 and then go up once you get to operating altitude, so something like key = 1 0, key = 0.5 0.1, key = 0.1 1.0, key = 0 0. If you're designing a propeller aircraft, you want the curve to be much flatter, only slightly better than linear in the 4+km region and tapering off to nothing by 12km. useVelCurve and the velCurve. The velCurve relates mach number to flow multiplier, so the x (time) value is mach, and the y (value) value is flow multiplier. For high-bypass turbofans, you want a fairly linear decline from 1.0 at Mach 0 to 0 at Mach 1.05 or so. For turbojets and low-bypass turbofans, you want a roughly quadratic gain in flow past Mach 0.5, peaking somewhere around Mach 1.5 and going down to nothing by Mach 3. For afterburning jets, the peak should be Mach 2 to Mach 3, tapering off past Mach 4 or so, and for ramjets they won't have any flow until Mach 0.3 or so then climb slowly with the peak up past Mach 3, and the tapering off to nothing shouldn't be until Mach 5 (perhaps slightly past Mach 5, though Mach 5 is where ramjets usually die off). Special engines (like the combined-cycle RAPIER, which is a SABRE basically) may have slightly different parameters, and turboramjets (i.e. a turbojet + ramjet combo, like the stock TRJ) will perform like turbojets with afterburners under Mach 2, and then blending into ramjet behavior past Mach 2. Scramjets, well, there really isn't any unclassified data on them, but we know they don't work at all until past Mach 5, and really only work at high altitude, and if you're lucky they might give you some thrust in the Mach 5 - Mach 10 range. Propellers should have nearly the same curve as low-bypass turbofans do, starting at 1 and declinging rapidly, although they will still produce some thrust past Mach 1, just not very much (a multiplier of 0.1, tapering off to 0 by Mach 4, say). Note that their decline isn't very linear, and should fall somewhat slowly until Mach 0.6 or so, after which it falls rapidly until Mach 1. machLimit and machHeatMult. These control the limit beyond which the engine starts producing extra heat; the extra heat produced is a multiplier to heatProduction, calculated as 1 + (mach - machLimit) * machHeatMult. flameoutBar and CLAMP. These control how flameouts occurs. When the combined flow multiplier (product of atmCurve and velCurve) is below flameoutBar, the engine will flame out because "air combustion failed". The minimum flow multiplier will never go below CLAMP (to avoid a divide by zero error). You probably never need to touch CLAMP, but if you want a lower flameout bar than 7% (0.07) you can specify it.

Uh, with new aero they actually should have the correct deflectionLiftCoeff and they'll fly fine (correct meaning "area in m^2 / 3.52"). I mean, sure, if they don't then fly fine try changing things (or, y'know, lowering mass---let's recall biplanes gross about 0.8t, not multi tonnes). But I think they'll fly fine.

Correct, KSP does not process background resource changes. Some mods like TACLS (and IIRC the new stock ISRU) will calculate time-since-you-were-last-here and produce/consume resources all at once based on that time, but for as-time-passes background you need a mod like Background Processing.

Here's some actual numbers, using the Beech Bonanza as reference. S = 16.815m^2 Cd0 = 0.0192 Mass at Vmax = 998kg downforce = 998*9.80665 lift = 998*9.80665 = 9787N 93.88m/s Vmax Cl = 9787 / (.5 * 1.225 * 93.88^2 * 16.815) Cl = 0.108 AR = 6.2 Cdi = 0.108^2 / (pi * e * AR) Cdi ~= 0.0006 Cd at Vmax ~= 0.0199 Drag force = 0.5 * 1.225 * 93.88^2 * 0.0199 * 16.815 = 1806.4N Ingame, the Cd is about 1.3x as high as it should be at Vmax and Cl is more like 1.72x as high as it should be. That leads me to believe that subsonic, M<0.3 drag should be about .8x what it is now, and lift should be about 0.58x what it is now. Note that for testing I removed the wing landing gear to not have excess drag on the wings. Pics are from .90 and oldfar, too lazy to upload a new album, but the numbers cited above are from nuFAR Fenno. S is correct, cross-section is as correct as I can make it.

That is a very short and fat rocket, with two very draggy things (the nose itself, and that very abrupt diameter change) quite high up. I'm not at all surprised it's highly unstable.

Since Kopernicus is what RSS, too, will use, you chose wisely.

It's also worth noting that the given mass specific heats for LF and OX are now pretty close to something Hydrazine-y (Aerozine 50?) and NTO. And the Isps work out too. The ratio is all wrong of course, though (11:9, should be something like 1.8:1) and the densities are equal (they should be something like .00725 and .0045), but if you think of the tank as a single mass, it almost makes sense now.

Ven's Stock Revamp has used non-destructive MM patching for, like, 3 months now.

It's been two weeks, so here's the update. Nearly there.

CKAN should also be able to find the old versions. Speaking of 1.0 however--it's been two weeks, and so here's the update. Nearly there.

If you change those values you have to delete PartDatabase.cfg (in your root KSP folder) and launch KSP to force KSP to recreate it. Those ModuleDragModifier values are baked into PartDatabase.cfg on creation, so if you change them, you have to recreate it.

Locked by request.

Also, it doesn't occlude all the drag. When two parts are connected by stacknodes, the area of occlusion is the minimum of the facing areas, and that's applied only to the appropriate faces of the cube, too. Example: an Oscar on top of an FL-T800. The bottom of the Oscar would be completely occluded (result: 0 area for the down face of the cube). The top face of the FL-T800 would have one quarter of its area occluded. And that's it.