NathanKell

hsp is the mass specific heat of the resource, in kJ/tonne-K.

Released or not, its engines sure as heck haven't been upgraded. Heck, they still include curves that don't exist anymore in 1.0. Let alone taking advantage of 1.0's new curves to approximate prop performance.

Nope, if you're not using an AJE-patched prop, you're using a rocket engine with a whirly bit on the front. Propellers are not rocket engines, and without AJE, all you can make are rocket engines*. *kinda no longer true in 1.0, but nobody's used 1.0's tools to make prop engines yet.

I would have, yes.

Put mathematically, drag = 0 for each cube face: .dot = dot(cube normal, velocity) .drag += getdragvalue(dot, mach) * face.area * face.dragcoefficient where getdragvalue will return an interpolated value between tip to surf if dot >=0, or between surf and tail if dot < 0, multiplied by the mach multiplier drag cube. (i.e. if the dot is 0.5, then that face is midway between tip and surf for drag curve purposes)

Joints are still very wobbly in KSP, especially a light part between a heavy SRB and heavy tank. My guess is the thrust from the SRB causes the decoupler's joints to wobble.

Fel, you're going to have to actually look into stuff to back that up, because I'm sure not seeing it anywhere. Indeed, the problem as Claw and I have described is exactly the reverse: tapered and blunt aren't treated differently enough.

Moved to General Add-On Affairs.

Ah, gotcha. Keep on doing awesome data work then. :]

AeroGUI will calculate your instantaneous terminal velocity.

I tend to judge books by their authors. I explained why ferram wrote that mod; that he added thrust-correction later was awesome and useful, and I get that's why some people used the mod before 1.0, but that sure as heck wasn't why KIDS was built nor was it its author's "primary feature" even if that was it for you.

Just a friendly note: if you're using a propeller engine that isn't patched by AJE, you're going to get a rocket engine with a spinny bit, not a propeller, and it's probably tuned for 0.90's soup. So don't be surprised if you get whack performance.

RSS is switching to Kopernicus because: 1. RSS started life as a hack, and thus is a bear to maintain. 2. RSS can't add planets, it can only change existing ones. 3. RSS doesn't work on 1.0 without major surgery, and I'd rather invest that time in improving a mod that's fuller-featured, does stuff the "right" way, and (thus) works on 1.0. In other news: #HypeTricycle

Sure! And apologies to everyone for forgetting about this, Padishar put in a PR and then I got busy in Kopernicus/RSS >.>

Good start! Don't be scared of polies, KSP is anything but GPU-limited, and a few thousand (heck, a few dozen thousand) faces isn't a problem, as long as your mesh collider is suitably low-rez. Building off what's been said so far, I'd basically encourage you to add more specific detail, going off the OP's pics it looks a bit like an 'impression' of an engine as it were--"this doughnut represents a pump, this cylinder represents a generator, this cone represents an exhaust"--rather than the high-jagged way those things tend to look in real life.

You'll want to use a constant atmosphereCurve, a nearly linear atmCurve, and a velCurve that starts at 1.0 and drops down to about 0.05 at mach 1.0.

I'd call the primary function of KIDS that which its name describes, Kerbal Isp Difficulty Scaler. (I don't see "thrust" in the name.) Remember, KIDS was created the last time there was a "FAR is le too EZ! Becuz dV too small!" thread pileon, and ferram said "kids plz" and made KIDS.

Correct, nothing about the atmsophere changed 1.0 to 1.0.1, just the drag multipliers. Part of the increased density in .90 was that density was linear with pressure rather than computed from pressure and temperature (and temperature during the day on the equator in 1.0+ is...rather warmer than baseline, that's why your curves don't meet at sea level). If you go north until sea level temperature is 288K, then sea level density should be 1.225 again. As to the main topic, as cool as the research is, simply measuring current velocity isn't really going to get you terminal velocity. You need to calculate current drag and current weight and then calculate what your instantaneous TV is for those.

In the VAB, a part's axes are Y+ = up, X is left/right, and Z is in/out (dorsal/ventral). In the SPH, the main axis (Y) is forward/back rather than up/down. Yes, partDB entries are autogenerated. And it's pretty simple to fix up a hollow part, you just replace the first two numbers in each of the Y+ and Y- tuples with numbers from a non-hollow part of the same diameter. Body lift takes the drag area without the mach multiplier and then multiplies again by dot and then evaluates the body lift curves from Physics.cfg (using sin(AoA) to that facing, and mach).

lift force (kN) = (for each wing/surface/etc) deflectionLiftCoeff * lift.Evaluate(sin(AoA)) * liftMach.Evaluate(Mach number) * globalLiftMultiplier * Q. Thus Cl = that * 1000 / Q / (sum of deflectionLiftCoeff) * 3.52 (since deflectionLiftCoeff of 1 approximately equals 3.52m^2).

It's density (in atmospheres) not pressure, btw. The sweet spot on the TRJ's curves are Mach 3 (max multiplier, 5.8) and density = 0.045 (curve) * 1.225 = 0.055 kg/m^3. (about 18-19km). Above that, you start to run out of air to combust, so if you keep climbing (and staying at Mach 3) eventually you'll have so little air density your jet will flame out. Ceiling depends on lift too of course, as well as drag: you want the minimum drag possible, which may mean more wings so you fly at a lower AoA.

Moved to addon development, where this sort of thing goes.

start therma and full thermal control when the white aeroFX start and finish changing to orange. They're mach numbers. The exponent is the exponent to velocity used in aeroFX for effect strength (3 is the same as the exponent used for velocity in convective heating). thermalMaxIntegrationWarp is the maximum warp rate at which thermodynamics are integrated (i.e. changed a little bit each frame). Beyond that, the resting temperature of the vessel is solved analytically by getting the sum of all fluxes except outgoing radiation and solving for the temperature where outgoing radiation balances them. solarLuminosityAtHome describes the solar flux (in W) in Kerbin orbit. It's used for solar heating and solar panel power generation. solarInsolationAtHome describes how much solar flux is lost when you're at 1.225kg/m^3 atmosphere density with the sun directly overhead (i.e. you get 85% flux at sea level at noon at the equator). Convection is heat gain or loss from the fluid medium in which the vessel lies--gain or loss because you might cool if you're hotter, or on reentry gain heat...Two methods of convection are used: Newtonian convection, where the flux is equal to (external temperature - part temperature) * coefficient, and mach convection, where teh flux is proportional to density ^ convectionDensityExponent * velocity ^ convectionVelocityExponent * convectionFactor. The coefficient for Newtonian convection is based on density times newtonianConvectionFactorBase plus velocity ^NewtonianVelocityExponent, all times newtonianConvectionFactorTotal. If the part is splashed, convectionFactorSplashed is used instead. The area used for convection starts as the radiative area (i.e. full wetted area) and then lerps down to just the exposed cross-sectional area. The lerping starts at fullToCrossSectionLerpStart and ends at fullToCrossSectionLerpEnd . fullConvectionAreaMin is added to the mach value first. However, it looks like a sign error, and it should have been subtracted instead; for that reason change it from 0.2 to -0.2. Convection lerps between netonian and mach convection using machConvectionStart and machConvectionEnd. However, it's not linear, instead it's machConvectionExponent (default cubic) interpolation, i.e. the interpolation values is ((mach - machConvectionStart) / (machConvectionEnd - machConvectionStart) ) ^ machConvectionExponent. spaceTemperature is the temperature of background radiation in space, so nothing will ever be colder than this. partEmissivityExponent is the exponent used in black-body radiation (4 is the real life value). conductionFactor is a multiplier to part-part conduction (which is also modified by the product of the two parts' heatConductivity fields, and by the minimum of the facing area between the parts). internalHeatProductionFactor is a multiplier to heat production from engines (an engine creates heatProduction * thrust / maxThrust / flowMultiplier * part.thermalMass * internalHeatProductionFactor watts of heat). aerodynamicHeatProductionFactor is a multiplier to velocity used when figuring out shock temperature ('external temperature'). I suggest you not give up so easily.

White Owl: it's a multiplier to the drag you get from wings. Wing drag = deflectionLiftCoeff * drag.evaluate(sin(angle of attack)) * dragmach.evaluate(mach) * liftDragMultiplier where the drag and dragmach curves are from the set of lifting curves the wing uses (probably Default) in physics.cfg.

(Moved back to main support for visibility.) Intended: intakes, like everything else, use the new dragcube system, so the drag value set by (and displayed by) the intake module (set based on closed/open, or intake rate) is completely ignored.