Claw

Slashy, if you care (since it was mostly for you): http://forum.kerbalspaceprogram.com/threads/119108-Overhauls-for-1-0?p=2182068#post2182068 Cheers, ~Claw

I cut this quote from another thread, but since I plan on really diving in, I thought it best to post this in here. *cracks knuckles* Okay, lets see if I can do this thing...This is talking about wings only. Drag cubes and how they apply to other parts is a whole 'nother topic. Real Life: This is the venerable V^2 (V-squared) lift model. It's important to note here that this is a pure aero discussion. Inertia and rigid body interactions are not considered. Factors inherent in flying, and not specified by the model itself: Rho (Density) - Comes from your flight regime, and is looked up in KSP through a curved value to approximate an Earth atmosphere. Velocity - Comes from your flight regime, and is used on a per-part basis, vice the whole craft. So, in fact, a plane that starts to yaw in flight produces ever so slightly more lift for the wing moving forward as compared to the one moving backward. One of the outcomes of this is that planes in KSP can simulate spins under the right conditions. Factors inherent in design, and specified within KSP: Cl (Coefficient) - As noted in the slide, real life Cl is a complex interaction of events. This is the meat of KSP's aeromodel calculations, and is discussed heavily below. S (Wing Area) - KSP uses deflectionLiftCoefficient here. That is why deflectionLiftCoefficient is dependent on the part's physical surface area (but not thickness). So wings of equal surface area should have similar deflectionLiftCoefficient values. So, because deflectionLiftCoefficient is normalized to the wing's surface area, and all stock wings use the same Cl model, it results in consistent behavior for the "lego" style wings. Build a "lego wing" that sums up to 5 Lift Rating and it will act the same as a single wing that has 5 Lift Rating (from an aero model standpoint). How does KSP build off of this equation is probably the root of what is being asked. The KSP model is as straight forward as "remove variable X and replace with Y". However, variable Y is actually a function (or series of functions). KSP Coefficient of Lift Calculation So Cl is really the piece that needs to be expanded upon. I know drag is what you are asking about, but at the basic level, lift and drag both use the same sort of calculation methodology. Since you say you understand Lift calculations, I'm going to re-explain all that to reinforce it, then discuss drag in a moment. First, lets take a look at Porkjet's Delta Wing (delta.cfg) guts, pasted below...I've highlighted the relevant bits. PART { name = deltaWing module = Part author = Porkjet rescaleFactor = 1 node_attach = 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 1 CoLOffset = -1.2, 0.4, 0 CoPOffset = -1.2, 0.4, 0 TechRequired = aerodynamicSystems entryCost = 6400 cost = 600 category = Aero subcategory = 0 title = Delta Wing manufacturer = C7 Aerospace Division description = Standard Delta configuration wings. These wings provide high lift and a stable center of gravity for your everyday lifting needs. attachRules = 0,1,0,1,1 mass = 0.2 thermalMassModifier = 8.0 // heatConductivity = 0.06 // half default emissiveConstant = 0.95 [COLOR="#0000FF"]dragModelType = none[/COLOR] [COLOR="#FF0000"] maximum_drag = 0.02 minimum_drag = 0.02[/COLOR] [COLOR="#0000FF"]angularDrag = 2[/COLOR] crashTolerance = 15 maxTemp = 2400 explosionPotential = 0.1 fuelCrossFeed = True bulkheadProfiles = srf MODEL { model = Squad/Parts/Aero/wings/delta } MODULE { name = ModuleLiftingSurface [COLOR="#FFA500"]useInternalDragModel = True deflectionLiftCoeff = 2.0[/COLOR] [COLOR="#FF0000"] dragAtMaxAoA = 0.6 dragAtMinAoA = 0.0[/COLOR] } } The Red highlight is what was used in pre-1.0 KSP, and is now the "spherical model." This info has zero applicability in KSP 1.0.X aero. And to be complete, I don't know that any meaningful testing has been done to ensure that the old "spherical model" still uses this properly. I've seen zero posts from people on the forum who might still be using it (not to say that people aren't). The dragAtMaxAOA and dragAtMinAoA is unused in 1.0.X KSP aero. The Blue highlight is info that was used in pre-1.0 KSP, and is still used but isn't strictly for lifting surfaces. The angular drag is really more of a rigid body thing (for all parts, vice specific for wings). "dragModelType = none" turns off the drag cubes for wings, whereas other parts specify "dragModelType = cube". It's entirely possible to have both drag cubes and wing lift/drag models active at the same time. Although that's likely to yield poor results... The Orange highlight are the parts that are relevant for calculation of the lift and drag values. deflectionLiftCoeff is the same old variable it was in 0.90 KSP aero, just used as a scalar now (akin to Wing Surface Area -> S). useInternalDragModel specifies which of the Lift/Drag (AoA/Mach) curves to use from the Physics.cfg. This allows lifting surfaces to all use the ModuleLiftingSurface module, but can specify a different set of curves (Ignore this for now). And here are the relevant pieces from physics.cfg which have to do with lifting surfaces (so lift and drag for the lifting surface). This is the default set of curves, which is used for wings and control surfaces. [COLOR="#0000FF"]liftMultiplier = 0.036[/COLOR] [COLOR="#008000"]liftDragMultiplier = 0.015[/COLOR] ... LIFTING_SURFACE_CURVES { LIFTING_SURFACE { [COLOR="#FF0000"]name = Default[/COLOR] [COLOR="#0000FF"] lift { key = 0 0 0 1.965926 key = 0.258819 0.5114774 1.990092 1.905806 key = 0.5 0.9026583 0.7074468 -0.7074468 key = 0.7071068 0.5926583 -2.087948 -1.990095 key = 1 0 -2.014386 -2.014386 } liftMach { key = 0 1 0 0 key = 0.3 0.5 -1.671345 -0.8273422 key = 1 0.125 -0.0005291355 -0.02625772 key = 5 0.0625 0 0 key = 25 0.05 0 0 }[/COLOR] [COLOR="#008000"] drag { key = 0 0.01 0 0 key = 0.3420201 0.06 0.1750731 0.1750731 key = 0.5 0.24 2.60928 2.60928 key = 0.7071068 1.7 3.349777 3.349777 key = 1 2.4 1.387938 0 } dragMach { key = 0 0.35 0 -0.8463008 key = 0.15 0.125 0 0 key = 0.9 0.275 0.541598 0.541598 key = 1.1 0.75 0 0 key = 1.4 0.4 -0.3626955 -0.3626955 key = 1.6 0.35 -0.1545923 -0.1545923 key = 2 0.3 -0.09013031 -0.09013031 key = 5 0.22 0 0 key = 25 0.3 0.0006807274 0 }[/COLOR] } For each part (lift and drag) there are global multipliers and two curves: Cx(AoA) and Cx(Mach). So lets look at Lift first, and all it's relevant bits. There's: liftMultiplier - Specified as a global tweakable value (in the Debug menu). Acts as a straight scalar for the whole model. lift (a float curve) - Specified how much to scale the lift force as a function of AoA. AoA is used as an index into the float curve, which returns a value. That returned value is used to scale the model. liftMach (a float curve) - Species how much to scale the lift force as a function of airspeed. Mach is used as an index into the float curve, which returns a value. That returned value is used to scale the model. How does this really tie together. Well, recall that we are expanding Cl from the basic aero V^2 model. Cl ends up being a product of several look-up values, specifically lift and liftMach, while the liftMultiplier is a static scalar. ----> Cl = liftMultiplier(Constant) * lift(AoA) * liftMach(Mach) Why are they set up this way? LiftMultiplier is needed to tweak the whole model up or down for changes. It makes model adjustment much easier on a global scale, vice including it in all the other curves and math. Lift(AoA) is needed so that wings actually act like what you would expect wings to act like. Pull back on the stick, you get more lift. This is just like a "real life" Cl curve. LiftMach is the tricky one. It's really needed because the game consists of a series of lego parts all stuck together. So rather than trying to determine wing sweep, aspect ratios, and other things, the game simply uses this lookup curve. Now we delve into Philosophy The default LiftMach, or Cl(Mach) curve, generally scales lift UP as the craft goes slower, and scales lift DOWN as the craft goes faster. There's a variety of reasons for this, but the end result is that if you fly glider like planes at slow speeds, they fly like gliders. If you fly space planes or supersonic jets, they fly like supersonic jets. The pitfall to this is as I've stated elsewhere, you can create things that are "unrealistic" and you aren't bound by true physics. This is the sticking point that seems to upset most people. "You worked so hard to create a real model, then do something like this." Well, we can debate about that all day, but rather than get drawn off onto that tangent, accept that this is the reality of KSP's aero model, and abuse it accordingly. Recall that KSP is a game about building what ever you want. So this becomes a bit of a compromise. Players who want to build realistic designs are rewarded with mostly realistic behavior (from a game that focuses on space flight). While players who want to build wacky stuff can (for the most part) still get away with it. i.e. You want to build a sandwich stack of wings? You still can. Don't want to do that? Then simply don't do it. The user has a choice in the matter. MODERATOR WARNING: Do not drag this thread off into a realism debate. This thread is about the nuts and bolts of KSP's aero model, not about the philosophy. If you want to discuss philosophy of aero modeling, go here. Drag, You Promised Me Drag! So lets start off with this again... Factors inherent in flying, and not specified by the model itself are still Rho (Density) and Velocity (V). Cd is calculated in exactly the same way as Cl, except that it uses the drag curves instead of the lift curves. The area in this slide is listed as A vice S, but in either case the game still uses coefficientLiftRating in the same way as described above. Recall that coefficientLiftRating is based on the wing's physical surface area (but not thickness). The one notable exception with the wing-drag model vice the wing-lift model is the following, from Physics.cfg: liftDragMultiplier = 0.015 This simply acts like another global modifier, which scales the coefficientLiftRating. This allows global adjustment to "how much drag per lift" is generated. I think I'm done, my fingers hurt. Cheers, ~Claw

It appears StockPlusController.zip was corrupted in the upload. Should be working now, same release. Thanks for letting me know. Cheers, ~Claw

You are very welcome. It's just a small text file, so that doesn't sound right. Which link did you use? The drop box or the Git? Cheers, -Claw

Well, static thrust for the jet engines is greatly reduced. I don't know about KER, but I know MJ doesn't really give good TWR for jet engines. I'm not sure what it's using for a baseline, but that might be the issue you're running into. KER might think you're putting out more thrust that what's actually coming out. Unfortunately VTOLs did indeed take a big hit because of this. Also, the CoM location on jet engines is problematic for VTOL craft. I haven't built a lot of VTOLs in 1.0, so hopefully someone with more recent experience will stumble in, but I have also found VTOL craft harder to work with in 1.0. It might be worth simply spamming jet engines all over and seeing if you can get it to lift off. Just to make sure there isn't something up with your mounting technique or some other phantom thing in the way of the engines. Cheers, ~Claw

This is a quick fix (because I already put the infrastructure in place), but I probably won't push out an update soon (at least not just for this). But because you asked so nicely (and qualified your request), have this in the mean time. Replace the existing ModuleGimbalFix.cfg in your folder, and you can modify the values listed in the .cfg. Those will be the new default, but be advised that it will not change any existing .craft or ships in flight. Thanks again for being understanding, and I'm glad to hear that it's working nicely for you. Also, thanks for the <3 Thank you so much. That certainly doesn't look right, and could possibly be my fault. I'll try to look into this soon. Please let me know if it becomes a bigger issue elsewhere. Cheers, ~Claw

It may or may not, but I wouldn't say that it's directly applicable without just going and actually doing the test in FAR. FAR does aero modeling quite a bit differently.

The Center of Lift is too close to the Center of Mass. Generally you want the CoL a bit behind the CoM. As for lawndarty behavior, that might be due to insufficient pitch authority. Overall you could fix this by adding a tail, or shift the wings back some and add a canard. There are other ways though, that's just the most straight forward. Also, you may want to consider a vertical stabilizer on back (vertical fin) to help with yaw control. You might experience some issues later with yaw stability, especially as you start to ramp up speed (assuming that's a spaceplane). Cheers, -Claw

This might be partially my fault, but you might want to take the subject of intake testing into a new thread, to not completely hijack the thread about wings.

There is actually a checkbox selection in the debug menu for drag, with regards to physicsless parts. Two Options for Drag: -Drag is applied at the physicsless part = just like it sounds -Drag is applied to the parent = The physicsless part calculates it's drag, then applies the resulting force to the parent. It does not pass up a drag coefficient. Physicsless parts used to be largely ignored by the physics engine. That's not really the case anymore, so the name is a bit of a misnomer. On the topic of unloading parts in the cargo bay... While I'm not trying to get hung up on terminology, unload has a specific meaning in the internals of KSP. It's technically impossible to send only part of a craft on-rails, pakced, or unloaded within the current construct of the game's code. That would result in instant ship-shredding kraken attacks. What is more practical, would be full deletion of those parts from the scene, and replacing them by adding a "dummy load" of mass, resources, ect. to the cargo bay itself. However, there would be a lot of problems with that, and a lot of assumptions that would need to be made (which may or may not be true). It's an interesting concept though, so might be worth thinking about in some form.

This is highly important. A ship with lots of things hanging off it, like a bunch of flat drop tanks hanging on the sides, is going to require a lot more dV to get to orbit. So I know you're looking for a ballpark number to design for, but also realize that the design itself is going to matter a great deal. Cheers, -Claw

It's also important to remember that a new player managed to fix his plane in his own way with your help. Don't forget to recognize that. Nice job on the little science bird, TheStuff...and welcome to the forums! Cheers, -Claw

This is exactly the kind of stuff that's awesome about this community. Great job on discussing and exploring the game, finding what works within the game, and then sharing that with everyone. I wish we had more of this. Cheers, -Claw I'd actually be interested in seeing this test. Based on my knowledge of the system, it shouldn't make any difference.

Hmm... Well, maybe think about heat this way. Instead of thinking of "temperature" think of it as Energy. When an object passes through the atmosphere at high speed, the friction from the air passes energy into the object. Each object also radiates energy away. The rate that it adds energy is a matter of how fast that object is moving (i.e. more friction). The amount of energy that radiates off is more of a function of temperature differental between the object and the surroundings. So, if you have an object that's passing through the atmosphere really fast, it heats up because it can't shed energy as fast as it's gaining it. Ablator works on the same principle. It can only ablate so quickly, and hence can only shed energy so quickly...which is faster than shedding energy by pure radiation, but is still a finite rate. So, if you come in too steep, the heat shield can't shed energy fast enough to prevent an excessive energy build up. This is also true in real life. If you've ever seen Apollo 13, there's a piece in there with news commentary showing a basketball and baseball , representing the Earth and the Moon. The commentator states that the capsule has to hit a reentry wedge as thick as a piece of paper. To shallow and the craft skips off and away. To steep and it'll burn up. Is that fun in KSP? Not wholly. KSP actually has a bit bigger of a window than that, but turns out that sub-orbitals can be dangerous if they come straight back down from too high up. The artificially small-kerbin size also means it has an equally small atmosphere. So the atmospheric density ramps up quicker than in real life, which doesn't allow as much time for the capsule to slow down and prevent excess energy buildup. Well, heat shields aren't always required for one main reason...KSP parts have a slightly high heat tolerance. The reason being because you can use those parts on all manner of vessels, including planes. Because of the lego style of building, having lower temperature tolerant parts would make space planes nearly impossible, due to the amount of time they spend in the atmosphere while heading to space. Now, all that being said, KSP is still a video game subject to game balance. So I'm not trying to be dismissive of your feedback, but trying to first explain real world physics. I also used to do the "launch straight up to 250km+ and obtain science" in my career games. That doesn't work as well anymore, especially early game. Even if the pod survives the heat, it often doesn't slow down fast enough to prevent impact. I'll give your profile a poke and see. I can't guess off hand what the safe reentry speeds are, but I see that you're hypersonic at 15/16km, which is pretty fast. The steep angle isn't giving much time for the ablator or energy to shed. Cheers, ~Claw

Q is dynamic pressure.

Depends on where you're at. Could you post a pic? Thanks, ~Claw

Good luck to both of you! Fengist, Any chance of also listing me in the Laythe category? Or will I need to do it again? Thanks, -Claw

Yes indeed. You could also hire all the applicants on the list, and it will repopulate (by leaving and coming back), but that's rather expensive. Cheers, -Claw

Okay. I'll take it more as a piece of balance feedback to look at. So, in that regard, can you provide a clearer picture of your craft (for replication) and a description of your orbit/reentry? That makes it easier to give it a try on my end to see what you are seeing. Also, balancing heat shields window is hard on Kerbin, because using up all (or most) of the ablator on a Kerbin reentry means a lot of difficulty landing somewhere like Eve. Cheers, -Claw

Yep. You can fix him as described here: http://forum.kerbalspaceprogram.com/threads/75586 I've also created an add-on fix for this if you are interested, which you can link to in my signature. Cheers, -Claw

I have seen this and I know what you are talking about. Some planes I have that fly under phys warp also behave like someone kicks the wing every so often. I haven't yet figured out where those behaviors come from, but it probably is some sort of inaccuracy buildup with the increased time steps. Perhaps another way to test that would be to increase the physics timestep in the settings menu.

It's actually because there are situations where the clamp ends up thinking it is in flight, and doesn't get packed properly. Failed packing resets it back to it's relative position near the craft in flight and ensuing collisions, which is probably why the decouplers work. It's not exactly that it thinks the clamp is connected. It's just returning it to the vicinity, which usually results in a collision. And no, KSP assumes the launch clamp can't leave the ground, which is why there are no later checks. Cheers, -Claw

I agree that it looks like you are simply coming in to steep, and the heat shield isn't able to ablate fast enough. Ther aero forces statement is interesting also, but it doesn't look like you've reached that level yet. You can confirm which is happening using the F3 flight log (if you haven't already). Cheers, -Claw

I suppose I should caveat my experience a little. Also, I agree with the interplanetery vs. In orbit comments. Heating is non-linear. Meaning if you double the speed, you get more than double the heat, but higher temps also bleed off faster. Anyway, I suppose it's possible to survive reentry (since I don't have reason to suspect people are lying). I have to say that I haven't tried reentry with a bare kerbal in a while, so perhaps there is a way (such as helmet first). I think their helmets are a separate collider, so possibly the helmet has a high tem capacity (i.e. possibly infinite)....and with the way the heat system works, you could thermally shield the kerbal's body behind the head. Although the helmet is not a separate part, so I am not very confident about that statement without trying it first hand. So perhaps those who state reentry is possible, can you provide some more specifics? I can say for certain, that I have had kerbals insta-poof when going EVA during an interplanetery return aerobrake at the extreme edge of the atmosphere (I mean at or above 69km edge of the atmosphere). But it's been a while since I tried a space-marine style Jeb level reentry. Cheers, -Claw

Assuming you restarted KSP (possibly your computer) and it's still happening...try it with a fresh save and see if it's still doing it. If not, then something might be broken in your save. If it's still doing it, then we'll need more info. You can check the sticky in this forum (Bug Report Guide) which will tell you where that info is. Also, welcome to the forums! Cheers, -Claw