Squad on the recent Aero changes

[luizopiloto]

Scott Manley pointed out something that was going to affect gameplay. Players were going to get their Kerbals killed doing completely routine things and get frustrated. It's perfectly reasonable to heed his advice on that. How to best "fix" the problem is another question entirely.

frustration are the things we now have to do to make an useful spaceplane... because just getting to orbit is not enough as many ppl thinks... it`s a bit harder now... not so funny as before...

[DoToH]

it seems the major reason why the air feels so "soupy" is that pointy shapes (nosecones and such) that OUGHT to cut through the air easily are actually modeled as being much more drag-inducing - and since the majority of drag comes from the front face of the craft, this makes drag seem excessive overall.

This^^

My other comment is that, currently, reentry heating doesn't do much due to craft slowing down rapidly enough that nothing overheats.

Reentry speeds are much slower than IRL because of the scaled down kerbol system. RL pods (and shuttles) have heat shields. Devs said they want reentry to be possible without heatshield from LKO if done with the correct profile.

IMO, balancing reentry is more about balancing part heat tolerance and heat system than aero, having in mind not real life performance or tolerances, but the final result and gameplay they want (heatshields needed for hard aerobraking or steep reentry profiles).

Scott Manley pointed out something that was going to affect gameplay. Players were going to get their Kerbals killed doing completely routine things and get frustrated. It's perfectly reasonable to heed his advice on that. How to best "fix" the problem is another question entirely.

While it's perfectly reasonable to heed his advice on that, it's perfectly reasonable to expect some testing about consecuences to other gameplay mechanics, such as reentry heat and excesive lift.

[NoPanShabuShabu]

Players get frustrated with many things. Forgetting about solar panels, forgetting about engines, forgetting about this or that.

IMHO as long as something makes a logical sense and is an implementation of realistic process - "frustration" shouldn't really be used as a counter-argument. Otherwise we'd still sit in garbage pre-1.0 aerodynamics, cause each time discussion about them sparked - there was someone popping up to say something about his "frustrations".

I guess you missed the "completely routine" part. A Mk 1 dropping from a dead stop at 5000m should not result in it going over 250 m/s and still accelerating as you near the ground. This is the game's mechanics frustrating a player, not their own mistakes.

[White Owl]

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.

Thank you very much. The other lift and drag values seemed straightforward, but I can think of a few different things liftDrag might have meant.

So at first glance, it would appear that increasing that value while also increasing global drag would be a large part of the unexpected difficulties for spaceplanes. Winged vehicles had their drag increased twice, while rockets and capsules had their drag increased only once. Pile on top of that difficulty the increased lift  increased twice for planes with mk2 lifting body fuselages  which has effects that can subjectively feel a whole lot like even more drag. No wonder capsules fly okay but planes are having problems.

[luizopiloto]

I guess you missed the "completely routine" part. A Mk 1 dropping from a dead stop at 5000m should not result in it going over 250 m/s and still accelerating as you near the ground. This is the game's mechanics frustrating a player, not their own mistakes.

No... This is the POD cfg don't giving the right drag values...

this is my complain about 1.x versions... aerodynamic is really good for a game, but the parts configs aren't well made... engines are not well balanced for it also...

so... instead of reviewing each part, squad changed the global aerodynamic values... unbalancing parts even more, but in another way...

[NoPanShabuShabu]

While it's perfectly reasonable to heed his advice on that, it's perfectly reasonable to expect some testing about consecuences to other gameplay mechanics, such as reentry heat and excesive lift.

Which was what the part where I said the "best fix" was still a question addressed. The OP's idea that heeding the advice of Scott Manley on a subject was akin to making it SCSP (Scott Manley Space Program) was what I was objecting to.

[luizopiloto]

Which was what the part where I said the "best fix" was still a question addressed. The OP's idea that heeding the advice of Scott Manley on a subject was akin to making it SCSP (Scott Manley Space Program) was what I was objecting to.

But I have to say... The community had to flip the forum upside down to save the round-8. Scott Manley just made a comment to make a big change on how aerodynamics behave.something Devs worked for months to achieve

[NoPanShabuShabu]

But I have to say... The community had to flip the forum upside down to save the round-8. Scott Manley just made a comment to make a big change on how aerodynamics behave.something Devs worked for months to achieve

And you have evidence that the community "had" to do anything more than politely request that that change not be made? There is also a big difference between making a change which will affect some players (possibly even a majority, though I doubt that) where they will have to come up with some other way to add 10 units of fuel, and a near game breaker.

And if you doubt that this is a near game breaker, you should try out using 1.0.0 drag & lift values and not opening a chute really early. Without the broken "open that chute while there's still flames" mechanic, this is a near death experience.

[luizopiloto]

And if you doubt that this is a near game breaker, you should try out using 1.0.0 drag & lift values and not opening a chute really early. Without the broken "open that chute while there's still flames" mechanic, this is a near death experience.

Say for yourself... I did an apollo mission to Mun, did the reentry from a free return trajectory, at the right angle, the heat shield did it's job... and I had to open parachute only at 5000m... and I wasted a lot of fuel, because the engies was overpowered and got everything to orbit with sufficient Dv to reach Eeloo...

And even more... my spaceplane was able to reenter w/o giving a flame while mantainning 30 degree AoA

Edited May 9, 2015 by luizopiloto

[DoToH]

The OP's idea that heeding the advice of Scott Manley on a subject was akin to making it SCSP (Scott Manley Space Program) was what I was objecting to.

I think we can safely assume some sarcasm in the OP.

Also, if changes to aero were made only because of Scott Manley's advice..... well... I hope it is not true (and I'd love to be sure about it).

- - - Updated - - -

Without the broken "open that chute while there's still flames" mechanic, this is a near death experience.

Nope. I'm playing 1.0, didn't upgrade to 1.0.1.Career mode with permadeath active. I've unlocked the tech tree and only lost one kerbal (launch failure - staging). I never open chutes over 5000 m. In 1.0, you can do a Mun flyby, free return trajectory, reentry and land without heatshield. Not easy, but not very hard either.

Edited May 9, 2015 by DoToH

[Jouni]

No... This is the POD cfg don't giving the right drag values...

this is my complain about 1.x versions... aerodynamic is really good for a game, but the parts configs aren't well made... engines are not well balanced for it also...

so... instead of reviewing each part, squad changed the global aerodynamic values... unbalancing parts even more, but in another way...

The overall drag increase was the right choice, but it wasn't enough to fix the entire problem. If you look at PartDatabase.cfg, you'll see that the drag coefficients of blunt objects are about right. If they fall too fast, the global aerodynamic values are at fault, not part properties.

The drag coefficients of streamlined objects, on the other hand, are too high. Fixing that will probably require changes to the code that determines the drag coefficients, based on the shape of the object.

[DoToH]

The overall drag increase was the right choice, but it wasn't enough to fix the entire problem.

The overall drag increase was not the right choice. It fixed pod terminal speeds, but broke some other aspects. Now, a pod doesn't fall too fast, but a Mk2 cockpit alone can reentry and glide to land safely.

After reading some posts here (posted by people smarter tham me), I think the underlying problem is the difference between coefficients of streamlined objects and coefficients of blunt objects. That problem is still there.

Increasing or decreasing drag and lift will not solve the issue.

- - - Updated - - -

Fixing that will probably require changes to the code that determines the drag coefficients, based on the shape of the object.

Totally agree, but is the only way to fix it

[foxkill2342]

Ksp is not out of Beta in my opinion. If the Devs still can't agree on a critical game element that affects how ships are built, the game isn't complete. 1.0 was supposed to be based on extensive testing. Stop messing with the game to the extent that makes previously built ships unusable.

[Fel]

The overall drag increase was not the right choice. It fixed pod terminal speeds, but broke some other aspects. Now, a pod doesn't fall too fast, but a Mk2 cockpit alone can reentry and glide to land safely.

After reading some posts here (posted by people smarter tham me), I think the underlying problem is the difference between coefficients of streamlined objects and coefficients of blunt objects. That problem is still there.

The bit about how much drag parts face is mostly just whining (since partdatabase is generated by the game instead of being fixed values). The real problem is that KSP's parts aren't calculated for a given atmosphere and hence squad gets weirdness when trying to convert to an actual aero.

See, those generated values take a look at the model to create a simplistic cubic representation and apply further drag tweaks from the part.cfg; but since KSP only modeled LIKE something, instead of calculated it, introducing realistic drag creates chaos. The pods being designed LIKE real pods, but not calculated to fall at a specific terminal velocity hence requiring a specific mass / cross-sectional-area ratio... don't fall right. The nose cones being designed LIKE nose cones, but not with a specific differential-cross-sectional-area in mind to help obtain a specific speed, don't operate correctly.

Squad's tweaking of aero rather than fixing parts is exasperating problems that the "rule of cool" created.

*To explain a little more directly. Pods are a combination of a nose-cone and a flat surface. Due to the pods being designed "like but not actually" you have to make certain the flat surface has enough drag to slow down to a specific terminal velocity while the "nose" cuts likely more arbitrary bit of drag. These tweaks are likely done in code and create "weirdness" like noses not losing enough drag in order to get more drag to the pod's base and sides.

Edited May 10, 2015 by Fel

[basic.syntax]

Mu singles out Scott in his comments, but he also said "a lot of the streamers." The un-named others probably weren't explaining their difficulties, as well as Scott did.

Twitch video archive, available here (link). The Aero comments start around 13m 50s.

If some folks are interested in detailed quotes, and what else Squad talked about after the Aero stuff, check my sig

[NathanKell]

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.

[Jouni]

The overall drag increase was not the right choice. It fixed pod terminal speeds, but broke some other aspects. Now, a pod doesn't fall too fast, but a Mk2 cockpit alone can reentry and glide to land safely.

It's easier to think this as a simulation issue instead of a gameplay issue. Let's forget KSP. Let's forget the gameplay. Let's forget that objects even have shapes. We just have objects with speed, cross-sectional area, and drag coefficient. If we know the properties of the atmosphere, we'll also know how much drag the objects will face.

That's something that was broken in KSP 1.0. Object faced less drag than they should have, based on their drag coefficients. The simulation was broken, because it didn't do what it was supposed to do. The only way to fix this fundamental issue was to increase the global drag multiplier, which Squad did in the 1.0.1. patch. It was a necessary but insufficient step towards fixing the drag issues.

Right now we're in a situation, where drag works more or less correctly for a given drag coefficient, but the link between shapes and drag coefficients is still broken. That's something Squad has to fix next.

("Broken" is probably too strong word for the situation. We just have some issues with aerodynamics, which players can work around, while waiting for Squad to deal with the issues.)

[Rithsom]

The only thing that I think needs to be changed is the drag of the wings and the thrust of the turboramjets and RAPIERs. The 1.0.1 and 1.0.2 patches simply increased the drag of the wings to make planes slower, but you can still go rediculously fast as long as the craft has no or very few wing parts. The overpowered thrust of the jet engines is what needed to be nerfed.

I love flying fast in the lower atmosphere, but 1000 kn seems like a bit too much thrust for a single 1.25m jet engine.

Edited May 10, 2015 by Rthsom

[DoToH]

Object faced less drag than they should have, based on their drag coefficients. The simulation was broken, because it didn't do what it was supposed to do. The only way to fix this fundamental issue was to increase the global drag multiplier, which Squad did in the 1.0.1. patch. It was a necessary but insufficient step towards fixing the drag issues..

But now, objects face more drag than they should, because of their drag coefficients. The simulation is broken, because it doesn't do what it is suppossed to do. The only way to create this issue was to increase the global drag multiplier, which Squad did in the 1.0.1. patch. It was a premature and insufficient step towards fixing the drag issues..

If tapered and blunt aren't treated differently enough, as NathanKell said (and I agree), increasing the global drag multiplier doesn't solve the issue. It moves the issue to streamlined parts, instead of blunt ones.

[Jouni]

But now, objects face more drag than they should, because of their drag coefficients. The simulation is broken, because it doesn't do what it is suppossed to do. The only way to create this issue was to increase the global drag multiplier, which Squad did in the 1.0.1. patch. It was a premature and insufficient step towards fixing the drag issues..

Assume that the drag simulation consists of two subsystems. Subsystem A derives some statistics from the shape of the object, while subsystem B applies drag according to those statistics.

In 1.0, both A and B were broken. Subsystem A didn't differentiate blunt and streamlined shapes clearly enough, while subsystem B applied too little drag. The errors canceled each other out for some shapes, while other shapes faced too little drag.

In 1.0.1, Squad fixed subsystem B. Because subsystem A is still broken, some shapes now face too much drag, while the simulation works correctly for other shapes.

The situation looks superficially similar in both 1.0 and 1.0.1/1.0.2: drag works correctly for some shapes and is wrong for other shapes. The difference comes from why drag works correctly when it works correctly. In 1.0, the correct behavior was incidental. Drag only worked correctly, when both subsystems produced wrong results. In 1.0.1/1.0.2, the correct behavior is correct for the right reasons. If subsystem A handles an object correctly, subsystem B will also work correctly for that object. That's why the global drag increase was a step to the right direction.

[DoToH]

Assume that the drag simulation consists of two subsystems. Subsystem A derives some statistics from the shape of the object, while subsystem B applies drag according to those statistics.

In 1.0, both A and B were broken. Subsystem A didn't differentiate blunt and streamlined shapes clearly enough, while subsystem B applied too little drag. The errors canceled each other out for some shapes, while other shapes faced too little drag.

In 1.0.1, Squad fixed subsystem B. Because subsystem A is still broken, some shapes now face too much drag, while the simulation works correctly for other shapes.

The situation looks superficially similar in both 1.0 and 1.0.1/1.0.2: drag works correctly for some shapes and is wrong for other shapes. The difference comes from why drag works correctly when it works correctly. In 1.0, the correct behavior was incidental. Drag only worked correctly, when both subsystems produced wrong results. In 1.0.1/1.0.2, the correct behavior is correct for the right reasons. If subsystem A handles an object correctly, subsystem B will also work correctly for that object. That's why the global drag increase was a step to the right direction.

Ok. Partially agree with that.

My point is still there: If subsystem B performs calculations based on data obtained from subsystem A is advisable to fix subsystem A BEFORE trying to tweak subsystem B values, because you're using WRONG input values for your testing. You might have to tweak subsystem B AGAIN after fixing subsystem A, because you've fixed susbsystems in the wrong order.

This will lead us to:

1.0.3 -> fix for subsystem A.

1.0.4 -> fixes and tweaks for subsystem B to adapt to new subsystem A.

It could have been like this:

1.0.1 & 2 -> Fix for subsystem A

1.0.3 -> fix and tweak subsystem B

And that's why I think 1.0.1 was a mistake, premature and poorly tested. Releasing a hotfix because of incorrect aero behaviour and not fixing aero behaviour is, IMO useless.

They should have waited until they had fixes for BOTH subsystems.

[luizopiloto]

Mu singles out Scott in his comments, but he also said "a lot of the streamers." The un-named others probably weren't explaining their difficulties, as well as Scott did.

Twitch video archive, available here (link). The Aero comments start around 13m 50s.

If some folks are interested in detailed quotes, and what else Squad talked about after the Aero stuff, check my sig

We cannot take all streamers opinions in account... Because:

Some of them fix instability problems spamming SaS modules.

Others tries to fix a bad reentry profile deploying parachutes at hypersonic speeds.

Some of them just build planes and trow them into something...

I can use my fingers to count the streamers that actually knows how to build, fly and land crafts w/o exploiting the game...

Edited May 10, 2015 by luizopiloto