NathanKell

Yet as it happens, that's what provides roll control for single-engine open-cycle engine stages. So they should get thrust transforms (and indeed nozzle transforms so they can gimbal) anyway.

The pod (and attached things) will orient so the center of pressure is directly behind the center of mass along the line of velocity. This means that if the center of mass is offset sideways, you'll line up at an angle.

Yes, when you attach an Oscar-B to an LV-N it totally heats up slower than a 2.5m tank attached to an LV-N. Don't confuse the fact that engine heatproduction is scaled by thermal mass (for mod backwards compatability, one assumes) with anything about the actual thermal system. Otherwise you just look silly.

@PART[*]:HAS[@MODULE[ModuleParachute]] { %bodyLiftMultiplier = 0 }

the first six triplets are X+, X-, Y+, Y-, Z+, Z- faces of the cube. The numbers are area, drag coefficient, and depth of widest point from the frontmost point at that angle. The nextr triplet is the bounds center, the final is the bounds extents.

For the record: Drag was incredibly low in 1.0, something like 1/2 to 1/4 FAR's. 1.0.2 has FAR-level drag for blunt objects down low, has lower than FAR above 14km, but does have considerably more drag than FAR does for streamlined planes when down low and than FAR used to in the transonic (with proper area ruling in nuFAR, the latter may or may not be true anymore).

Drag was incredibly low in 1.0, something like 1/2 to 1/4 FAR's. 1.0.2 has FAR-level drag for blunt objects down low, has lower than FAR above 14km, but does have considerably more drag than FAR does for streamlined planes when down low and than FAR used to in the transonic (with proper area ruling in nuFAR, the latter may or may not be true anymore).

Correct. 10char

The last tab, with its save and load buttons, belies this answer.

I can add IAS to AeroGUI if you want; it's already got mach and EAS and a bunch of other stuff... http://forum.kerbalspaceprogram.com/threads/117141-1-0-AeroGUI-v1-0-28-Apr

News to me there isn't a new version in development. What ever gave you that idea?

v4.0 * Update to KSP 1.0. * Speed improvements. (Death to foreach! Don't recalculate values!) * Removed EFFECTS support for now (doesn't work). * Easy integration with TestFlight. * Added useLever, tunable precision mode thrust, tweaked EPSILON support.

Yep, inheriting from ModuleEngines and overriding (or hiding/replacing) methods is your best bet.

I would suggest using this as the curve: atmosphereCurve { key = 0 340 -50 -73.71224 key = 1 290 -21.23404 -21.23404 key = 5 230 -10.54119 -10.54119 key = 10 170 -13.59091 -13.59091 key = 20 0.001 } The point of an aerospike is to be "nearly optimal" everywhere, for its chamber pressure. So since the Mammoth is the "bestest SL engine evar!" at 295, the aerospike is pretty darn good at 290. In vacuum, the best have 345 or 350, so the spike gets 340. So far so good. But you're right that it looks like with the jump up in vacuum Isp (to account for ~things changing~) the curvature below 1 atm got wonky. So that fix restores what appears to be the intended curvature.

I would rather the takeaway Squad gets from this "keep trying to improve things" rather than "anything you do will cause a backlash." Because the answer to "stop changing things!" isn't a better aero model. It's not having the new aero model at all, going back to the soup.

Rickenbacker: it displays TAS. Old Foxboy: Uh, I think we're talking past each other. Because dynamic pressure is quite literally rho * v^2, and you'll note the mach curves are pretty quadratic This means there's rough proportionality with IAS, although again it's not linear (in particular, the density curve is a curve, not a line, and each engine's compressor handles escalating mach differently).

Awesome writeup! One nitpick: torque isn't a way to make your rocket statically stable, it's a way to make it do what you want. There's a difference. (And indeed, too much stability can be bad too--makes it harder to turn)

0235: except for wing aspect ratio and wing sweep, pretty much all of it does now. Dihedral/anhedral works properly, CoL above/below CoM, etc.

I'm well aware of that. What I am saying however is that you appear to have missed one of the big changes in KSP 1.0--namely, that thrust changes with Isp, not fuel flow--and thus if you were going by the cfg files alone in either case you are missing significant details. Which you would have seen, had you examined the parts ingame, where the editor info window clearly shows both the sea level thrust and the vacuum thrust (neither of which changed going 1.0 to 1.0.x). You need to consider the engine's performance throughout its used range when determining delta V--that is, for lifters, probably getting weighted-average Isp from sea level though about 0.05atm tops, and for vacuum engines only vacuum isp. If TWR figures into your usefulness calculations, then you need to calculate TWRs the same way (weighted average of sea level and vacuum thrust). That said, given those results I'm really glad the change in 1.0.1 was made, to make maxThrust again the true max thrust, not the sea level thrust, because it will hopefully reduce similar confusion in future.

The mass is no longer concentrated on the outlet. Check it out ingame or examine the cfg, an offset was added. And no, the J58 is actually much weaker than the TRJ. 150kN vs 180kN static thrust doesn't tell the whole story; our TRJ reaches a higher peak thrust and provides useful thrust at faster speeds than ([best guesses at) the J58's performance. And that's not counting the fact that the TRJ's Isp is about 10x higher. Basically, KSP jets have about 2-3x the TWR real jets have, and about 10x the Isp. Compare that to KSP rocket engines, which have 1/8 the TWR of real ones and about the same Isp.

Sahadara: Always has, AFAIK.

What happens when you try to Show GUI for that engine, or go to action group editor mode and click on the engine?

If you want unintended but nonetheless 1.0 behavior, you can change machConvectionExponent from 3 to 1, too. That's what it was in 1.0.

Sounds like just using "PartDatabase.cfg" instead of KSPUtils.ApplicationRootPath + "\PartDatabase.cfg" or something...which might be intended behavior, you never know.

Thrust values did not change at all. You're just not accounting for the difference in thrust between sea level and vacuum. Except the aerospike (which got 5 more seconds vac Isp), the only thing that changed 1.0 to 1.0.1 was that maxThrust is now given in terms of vacuum thrust instead of sea level thrust. If you actually look at the ratings ingame, where it states vacuum and sea level thrust, you'll see that nothing changed. The only change was behind the scenes. Since you think the thrusts did change, I'm guessing you did your original calculations based off the cfg, and thus missed changes in thrust as air pressure changes. I would beg you to redo your calculations, this time keeping in mind that Isp at a given pressure matters for thrust.