Squad on the recent Aero changes

[White Owl]

Terminal velocity for the pods, even in 1.0.2, is a bit low. However, drag for planes is way too high. This doesn't mean "find some average drag" it means change how Cd is calculated so that pod Cds stay about the same but plane Cds go down. One thing to do this would be to add an exponent to Cd, so Cd < 1.0 gets lower (and the lower it starts as, i..e the more streamlined the part is, the more it would get lowered by the exponent).

NathanKell, might you be able and willing to explain what exactly the liftDragMultiplier value in physics.cfg does?

[CodedThreat]

well, that's because that's what people were doing when arguing for a less dragy atmosphere at the beginning of the thread. People would go over how atmosphere should be changed because IRL planes can reach mach speeds easily while at the same time disregarding the unrealistic terminal velocities of pods.

Ahh, so just picking and choosing which points to bring up to make their point, while ignoring the rest. Yea, that sounds like the internet.

Also, I do not think it is exactly easy to reach mach speeds in a plane IRL. IIRC it was kinda a big deal when they did it the first time and even today, the planes that can do, only do it quite high in the atmosphere, are quite small compared to 737s and 747s and are super engineered and streamlined to hit those speeds . And you do not see F-22 raptors hitting mach 1 before they even reach the end of the runway (exactly what you could do in 1.0). Seems silly.

Oh and I love RCS build aid, so helpful, wish it was stock! And I know it works in 1.0 but would love to see an official updated release.

Cheers

[Fire-Dragon-DoL]

Any of you stumbled upon the lovely contract "600-800 m/s at 5000-8000 m"? That was one of the worst experience I faced. I had to build a 12-boosters capsule (literally was a capsule + part to test + 12 boosters), marked as a one star, my capsule was almost exploding

[Scoundrel]

Any of you stumbled upon the lovely contract "600-800 m/s at 5000-8000 m"? That was one of the worst experience I faced. I had to build a 12-boosters capsule (literally was a capsule + part to test + 12 boosters), marked as a one star, my capsule was almost exploding

I have a rocket plane for those ones. Originally built for those contracts that require a reading/report ABOVE a certain altitude (I really should have read those contracts more carefully before I accepted), it's basically a plane with a pair of jet engines flanking a rocket or srb depending on the ridiculousness of the contract... a side note: it happens to also work really well as a low-speed rover due to the broad undercarriage which was originally designed to be really easy to land on rough terrain. If you're interested, I'll be posting it in the rocket builder's forum later in a few days.

As for the aerodynamics stuff, I think I am in agreement with NathenKell. The C_D for the pods is too low for a blunt body object, and Squad's response has been to increase drag across the board rather than correct the physics for it. To confirm my hypothesis I decided to accumulate some empirical evidence rather than rely on anecdotal bias.

My experiments centered around the Mk1-2 Command Pod, the idea being to measure differences in apoapsii between different pod orientations, as well as final velocity impacting into the ocean, again with the pods oriented both upwards and pointing straight down.

To educate myself a little on the subject, I used this NASA document on the Apollo CM as a reference for what I should expect in terms of proper blunt-body physics. Some further research led me to conclude that the Mk1-2 Command Pod with its truncated 70° cone¹ and 1:4 meplat² should have a C_D of about 0.50-0.65 (significantly less with a nosecone) nose forward, and a C_D of around 1.17 blunt end forward.

I opted for a 3 part rocket consisting of the mk 1-2 Command Pod atop a rockomax 2.5m decoupler and a fully fueled Twin Boar booster, and did 5 launches of each orientation (staging the upper stage as soon as the lower stage ran out of fuel to avoid the booster striking the pod on the way down) - my control was the same launch vehicle (2.5m decoupler atop a Twin Boar booster) but with an RC-L01 beneath a X200-8 fuel tank with its oxidizer reduced to 264 to bring the mass of the upper stage to 4.1tons (similar to the 4.12 tons of the Mk1-2 pod). The results revealed the following:

control yielded a typical apoapsis of 634,014m (got pizza sauce and black olive on the paper I was recording peak v on so data, um, corrupted)

pod oriented pointy end up yielded a typical apoapsis of 848,138m (peak v eyeballed at 2477.5m/s)

pod oriented blunt end up yielded a typical apoapsis of 724,825m (peak v eyeballed at 2389.7m/s)

So there is an effect, but only a dv difference of less than 100m/s, which is suspect IMHO.

Experiments trying to get the pod to re-enter nose down have all failed (the CoM causes the pod to automatically flip), but I noticed that pods that re-enter nose down and flip have a lower velocity when they impact the water (195 base down, 178.4 nose down attempt, the control was 147³). This led me to suspect that the greatest amount of drag a pod generates is when it is sideways (this should not be so, as the pod's sideways C_D should only be about 0.8)... so I built the exact same rocket with the pod sideways to verify.

The results were quite revealing.

First of all, the amount of drag the pod generates sideways is enough to reduce the Twin Boar's upwards acceleration from 4g to 2.25g in the transonic regime (300-350m/s) - it could have reduced it more, but the amount of drag was so high that it kept flipping the rocket before I could confirm no matter how much I fiddled with placing the pod to compensate for it! In comparison, pointy end up reduced the transsonic acceleration to 3.25g, the blunt end only as low as 3g, and the control was eyeballed at 2.8-2.9g.

A few crude tests with the Mk1 pod resulted in similar behaviour, but I was unable to create a proper experiment due to an unexpected short in the laboratory logistical chain (I ran out of beer ).

In summary, I tentatively submit that the command pods have a significantly greater drag sideways than they do blunt end forward, and that, as of 1.0.2, the difference between nose-up/nose-down orientation isn't particularly significant with regards to drag.

I encourage others to confirm my results with their own experiments.

1. I have tried to avoid using technical terms where possible for the sake of discussion.

2. Sorry, I come from a background in ballistics and couldn't remember what the flat part of a truncated cone was called. The meplat is the flat part at the very front of a bullet.

3. Before people point out that the control was a superior blunt body, a cone edge first has a lower C_D than a cylinder that has a lw ratio of 0.5:1 (it would have a C_D approaching 2.0 whereas the pod should have a C_D of about 1.17), so the control merely verifies that the aerodynamics are roughly functioning as they should.

IMHO, I feel it is safe to conclude that if Squad were to correct their blunt-body physics then they wouldn't need to increase the drag to such high levels across the board to compensate.

Edit: So i just discovered Graphotron 2000 and may recreate the experiments if there's enough interest... and if I remember to restock the laboratory.

Edited May 9, 2015 by Scoundrel
Stumbled across Graphotron 2000

[mikegarrison]

The most drag doing sideways. That's pretty wild.

When you are going up, you have a rocket body behind you, right? That has a big effect on drag, not having a huge separated region behind the body. I think you have to treat the aerodynamics of the capsule by itself as completely different than the aerodynamics of the capsule as the nose of a rocket.

[Scoundrel]

I think you have to treat the aerodynamics of the capsule by itself as completely different than the aerodynamics of the capsule as the nose of a rocket.

I did when I measured the capsule's velocity from reentry. It was how I discovered that capsules have more drag sideways than any other direction. Also, with a control, I can determine its drag like an ogive on a bullet... within reason. But you are correct. I may redo this experiment later by altering the pod's configs to make the CoM neutral so that it could be pointed downwards or sideways to verify my suspicion.

I blame my not thinking of that on the lack of beer.

[Roflcopterkklol]

I did when I measured the capsule's velocity from reentry. It was how I discovered that capsules have more drag sideways than any other direction. Also, with a control, I can determine its drag like an ogive on a bullet... within reason. But you are correct. I may redo this experiment later by altering the pod's configs to make the CoM neutral so that it could be pointed downwards or sideways to verify my suspicion.

I blame my not thinking of that on the lack of beer.

Forgive me if i am wrong on this but the drag models for all the parts are hexagons and triangles no?

[luizopiloto]

well... at what speed an meteor strikes the ground in RL?

Now test it in KSP with this new aero... Stop complaining about capsules coming from high orbit and steep angles hitting the ground at high speed... do the reentry at the right angle to loose speed...

Ps:

Scott Manley told them that the pods did not slow down as enough; drag was upped to compensate

As a result, lift and other values were tweaked.

why all this faith in Scott Manley? he works for NASA, ESA, etc?

should we change KSP name to SMSP?

Edited May 9, 2015 by luizopiloto

[Kuu Lightwing]

Meteor doesn't strike the ground. Small meteorites do, but not very fast. Large meteorites can hit very hard, but they ARE large. And space capsules are different from meteorites.

Also, Scott Manley knows a lot about spaceflight and it's a good idea to listen to him.

[m4v]

well... at what speed an meteor strikes the ground in RL?

Now test it in KSP with this new aero... Stop complaining about capsules coming from high orbit and steep angles hitting the ground at high speed... do the reentry at the right angle to loose speed...

...as it was pointed out several times, terminal velocity is independent of the re-entry profile.

Edited May 9, 2015 by m4v

[luizopiloto]

Also, Scott Manley knows a lot about spaceflight and it's a good idea to listen to him.

Why not ask someone from NASA who plays KSP? I`m pretty sure they can help... again...

- - - Updated - - -

...as it was pointed out several times, terminal velocity is independent of the re-entry profile.

ok... so coming from a high angle... with less atmosphere to break you up will have the same effect of a lower angle, with more atmosphere between you and the ground...

[Kuu Lightwing]

The main problem with the steep reentries IRL is not that you won't slow down to terminal velocity. It's that you'll do it too fast, and you won't like. AFAIR the worst was Soyuz 7K-T No.39 - 21.3g, and that wasn't even stuff like lunar orbit. Don't worry about terminal velocity, due to how fast drag scales with speed, it WILL slow you to terminal velocity. You just don't want it to happen too fast.

[luizopiloto]

no... you will desintegrate before reaching terminal velocity... or the ground... all depends of material/density of the object...

Edited May 9, 2015 by luizopiloto

[Fuzzy Dunlop]

The main problem with the steep reentries IRL is not that you won't slow down to terminal velocity. It's that you'll do it too fast, and you won't like. AFAIR the worst was Soyuz 7K-T No.39 - 21.3g, and that wasn't even stuff like lunar orbit. Don't worry about terminal velocity, due to how fast drag scales with speed, it WILL slow you to terminal velocity. You just don't want it to happen too fast.

That depends very much on the mass/drag ratio. Most meteorites on less than 8 tonnes will slow to terminal velocity, but larger ones won't. An empty V2's terminal velocity is roughly 400 m/s but it they impacted twice as fast. Though you would expect most real life most pods would always slow to terminal velocity given that much denser meteorites do.

[sephirotic]

Same F-104 replica test on 0.25 with FAR.

400m/s with a 60kn engine.

Putting a 120kn rocket engine wasn´t enough to push to 450m/s which was our target, I got only about 420m/s at sea level.

But yeah, FAR is still much better than the stock aero model, I just hope Ferram keeps updating it.

Whoever says that the 1.0.2 drag is fine, is either an inexperienced player witch never used FAR, or is too blind to see their own contradiction bias in favor of squad's questionable decision.

Ideally we would have Squad to make up with Ferram and consult with him.

Edited May 9, 2015 by sephirotic

[Kuu Lightwing]

No, thanks. FAR is cool and realistic, but having RUDs because I touched the controls at wrong speed just isn't fun. BTW, have you tested it with 1.0.2 FAR? It doesn't feel much different, aside from those "nice" RUDs for no apparent reason.

[sephirotic]

No, thanks. FAR is cool and realistic, but having RUDs because I touched the controls at wrong speed just isn't fun. BTW, have you tested it with 1.0.2 FAR? It doesn't feel much different, aside from those "nice" RUDs for no apparent reason.

Yeah, because doing a 145g turn on stock model is not reallistic but is FUN! Come on. While I do think the g-limit of FAR is a little bit conservative for desintegrating vessels, it Never was really a problem for me with FAR, Get a joystick. Otherwise you'll have to play on "easy" mode. Ow, wait, FAR doesn´t have that, so It would be better to get good instead. Sorry, couldn´t resist it.

Haven´t tried FAR on 1.0.2, just saw that it was updated.

FAR is not perfect either, it's independent control for surfaces is not very good IMHO, and rudders/yaw stability don´t see to work properly, stock 1.0 model rudders felt more natural to me. I will install it and do some more tests to see if there is any difference.

Edited May 9, 2015 by sephirotic

[Kuu Lightwing]

While you respond to people like that (about FAR), FAR won't work as stock aero.

[Jouni]

Whoever says that the 1.0.2 drag is fine, is either an inexperienced player witch never used FAR, or is too blind to see their own contradiction bias in favor of squad's questionable decision.

The problem is with the parts (or actually with how KSP determines the drag coefficients of the parts), not with drag.

The plane you built has a Mk1 cockpit at its nose. If we look at PartDatabase.cfg, we find the following:

PART
{
	url = Squad/Parts/Command/mk1Cockpit/mk1Cockpit/Mark1Cockpit
	DRAG_CUBE
	{
		cube = Default, 1.823583,0.7348939,0.8693516, 1.823583,0.7353885,0.9128191, 1.263023,0.2716523,2.393878, 1.263023,0.9475985,0.3517535, 2.053816,0.7649878,0.7245554, 2.053816,0.7311577,0.7189386, -4.053116E-06,0.9747789,-0.00202769, 1.383462,2.291587,1.23226
	}
}

Claw has figured out the meaning of most of the numbers. The first six groups of three numbers each represent the faces of the drag cube. The numbers are area of the cross section, drag coefficient, and the depth of the face. The third and the fourth faces are the front (1.263023,0.2716523,2.393878) and the rear (1.263023,0.9475985,0.3517535) of the cockpit; the difference in the drag coefficients is only 3.5x. Apparently the cockpit isn't as streamlined as it appears.

[NathanKell]

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.

[sephirotic]

The problem is with the parts (or actually with how KSP determines the drag coefficients of the parts), not with drag.

The plane you built has a Mk1 cockpit at its nose. If we look at PartDatabase.cfg, we find the following:

PART
{
	url = Squad/Parts/Command/mk1Cockpit/mk1Cockpit/Mark1Cockpit
	DRAG_CUBE
	{
		cube = Default, 1.823583,0.7348939,0.8693516, 1.823583,0.7353885,0.9128191, 1.263023,0.2716523,2.393878, 1.263023,0.9475985,0.3517535, 2.053816,0.7649878,0.7245554, 2.053816,0.7311577,0.7189386, -4.053116E-06,0.9747789,-0.00202769, 1.383462,2.291587,1.23226
	}
}

Claw has figured out the meaning of most of the numbers. The first six groups of three numbers each represent the faces of the drag cube. The numbers are area of the cross section, drag coefficient, and the depth of the face. The third and the fourth faces are the front (1.263023,0.2716523,2.393878) and the rear (1.263023,0.9475985,0.3517535) of the cockpit; the difference in the drag coefficients is only 3.5x. Apparently the cockpit isn't as streamlined as it appears.

Yeah, I already figured that the problem goes deeper than just tweaking some parameters.

[m4v]

But yeah, FAR is still much better than the stock aero model, I just hope Ferram keeps updating it.

Whoever says that the 1.0.2 drag is fine, is either an inexperienced player witch never used FAR, or is too blind to see their own contradiction bias in favor of squad's questionable decision.

Drag in 1.0.2 isn't fine, but neither it was in 1.0, and between the two I prefer 1.0.2. Is awesome that there's a mod that caters your tastes and is top quality, isn't? Now let me choice to play KSP with stock aero.

[ArcFurnace]

The problem is with the parts (or actually with how KSP determines the drag coefficients of the parts), not with drag.

The plane you built has a Mk1 cockpit at its nose. If we look at PartDatabase.cfg, we find the following:

PART
{
    url = Squad/Parts/Command/mk1Cockpit/mk1Cockpit/Mark1Cockpit
    DRAG_CUBE
    {
        cube = Default, 1.823583,0.7348939,0.8693516, 1.823583,0.7353885,0.9128191, 1.263023,0.2716523,2.393878, 1.263023,0.9475985,0.3517535, 2.053816,0.7649878,0.7245554, 2.053816,0.7311577,0.7189386, -4.053116E-06,0.9747789,-0.00202769, 1.383462,2.291587,1.23226
    }
}

Claw has figured out the meaning of most of the numbers. The first six groups of three numbers each represent the faces of the drag cube. The numbers are area of the cross section, drag coefficient, and the depth of the face. The third and the fourth faces are the front (1.263023,0.2716523,2.393878) and the rear (1.263023,0.9475985,0.3517535) of the cockpit; the difference in the drag coefficients is only 3.5x. Apparently the cockpit isn't as streamlined as it appears.

So, reading Claw's post there, 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.

My other comment is that, currently, reentry heating doesn't do much due to craft slowing down rapidly enough that nothing overheats (I had a craft turn out to be reentry-unstable and flip so that all the parachutes were facing forward, but it made it through the atmosphere just fine). This doesn't seem right, but there's more than one way to adjust things so that heat shields are necessary.

[NoPanShabuShabu]

well... at what speed an meteor strikes the ground in RL?

Now test it in KSP with this new aero... Stop complaining about capsules coming from high orbit and steep angles hitting the ground at high speed... do the reentry at the right angle to loose speed...

Ps:

why all this faith in Scott Manley? he works for NASA, ESA, etc?

should we change KSP name to SMSP?

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.

[Sky_walker]

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.

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".

Edited May 9, 2015 by Sky_walker