[0.90] Stock Drag Fix - Mar 19, 2015 (BETA UPDATE)

[Galane]

I had to do some refitting on a heavy booster that stages kerbodyne tanks off the tops of asparagus stacks. The reduced drag allows so much more speed in the lower atmo that not even several 200% tweakscaled separatrons could pull the empty tanks up and away.

So I surface attached two small diameter Stretchy SRBs to each plus a pair of off center scaled up separatrons to ensure they don't just fly straight ahead. Set the thrust of the SRBs wayyy up so the burn time is only 4 seconds. That really gets them out of the way and keeps the parts count down.

One odd thing though. The booster never hits terminal velocity, not even while the large stock SRBs are burning, so MechJeb never throttles back. Yet I was able to get to a 180KM orbit with my heavy Eve lander on top with nearly a full ThunderMaximus 288 tank instead or a 100KM or lower orbit with only about 1/2 a tank left.

SDF's effect on landing on Kerbin and Eve with MechJeb. It 'goes long' on the initial high deorbit burn then flips the ship to aim the nose retrograde and down to do a long correction burn to get the predicted landing to the specified target.

It appears to be running the stock drag values to do the deorbit burn yet is able to adapt for getting it wrong. Might want to pack more fuel for landing on bodies with atmosphere. (Note to self, test unmanned Eve lander with 50% fuel load for descent to see if it will need more.)

[Starwaster]

I had to do some refitting on a heavy booster that stages kerbodyne tanks off the tops of asparagus stacks. The reduced drag allows so much more speed in the lower atmo that not even several 200% tweakscaled separatrons could pull the empty tanks up and away.

So I surface attached two small diameter Stretchy SRBs to each plus a pair of off center scaled up separatrons to ensure they don't just fly straight ahead. Set the thrust of the SRBs wayyy up so the burn time is only 4 seconds. That really gets them out of the way and keeps the parts count down.

One odd thing though. The booster never hits terminal velocity, not even while the large stock SRBs are burning, so MechJeb never throttles back. Yet I was able to get to a 180KM orbit with my heavy Eve lander on top with nearly a full ThunderMaximus 288 tank instead or a 100KM or lower orbit with only about 1/2 a tank left.

SDF's effect on landing on Kerbin and Eve with MechJeb. It 'goes long' on the initial high deorbit burn then flips the ship to aim the nose retrograde and down to do a long correction burn to get the predicted landing to the specified target.

It appears to be running the stock drag values to do the deorbit burn yet is able to adapt for getting it wrong. Might want to pack more fuel for landing on bodies with atmosphere. (Note to self, test unmanned Eve lander with 50% fuel load for descent to see if it will need more.)

If you're jettisoning in the lower atmosphere (or even lower upper) think about using parachutes. Either alone or in conjunction with sepratrons. I've often done that even with stock drag. Put them on the side away from your core stage and part way up towards the center of mass. (the closer it is to CoM, the faster and greater the amount of rotation so don't put it too close or it'll swing up too sharp and smack your core rocket)

Terminal velocity: It's not unusual not to hit terminal velocity. Unless you've got a TWR of about 6+ (maybe less) you're going to be chasing terminal velocity the whole way, except maybe in the lower atmosphere. Also though, about MechJeb and terminal velocity, it's been reported relatively recently in the MJ forum that MJ only counts vertical velocity when calculating terminal? I don't know if that's really true, but it is something to be aware of. If it is true it limits the usefulness of TV limiting. (hah.)

About MechJeb looking at 'stock drag' values, there's no way it's doing that, barring some hitherto unknown bug whereby a part would report its original drag instead of current drag.

[Galane]

I've made several heavy boosters with enough SRBs in the first stage to hit TV with little or even no thrust soon after liftoff from the liquid fuel engines. Saves plenty on fuel.

With SDF they accelerate faster yet MechJeb isn't throttling back at all - but I don't get the white shockwave effect. Without SDF and without using MechJeb's TV limit I get shockwave effect, heating if it's a real extreme launch vehicle, and waste tons of fuel in the lower atmosphere.

Whatever goes on, SDF = more efficient launches without all the niggling tedious realism of using FAR and that's a good thing.

[Guest]

A note on MechJeb and terminal velocity: if you deactivate the terminal velocity option prior to launch then activate it around 10~15 seconds into ascent, MechJeb will throttle back if necessary. I'm not sure why this works. But after a fair bit of fiddling with different booster configurations, this appears to produce consistent results. Note that the throttle compensation is decidedly less than with stock drag and shorter in duration, which makes sense.

[Capt Snuggler]

This mod is a great improvement over stock! more of bug fix than a mod, as 'wet mass' drag calculation is clearly an oversight by the devs.

Keeps the stock aero feel but corrects weird aircraft behavior. no more bizarre craft flip outs during re-entry. I would always transfer fuel forwards not realizing this was actually increasing the nose drag and the likelihood of a flip.

now craft behave much more naturally and predictably.

there is still more to be done to truly correct stock aerodynamics, but this is really great improvement. thank you.

Edited September 13, 2014 by Capt Snuggler

[Starwaster]

This mod is a great improvement over stock! more of bug fix than a mod, as 'wet mass' drag calculation is clearly an oversight by the devs.

You know, the thing of it is though, to get wet mass in code you have to do this: part.mass + part.GetResourceMass()

So it strikes me as a pretty willful thing to have done. Someone, somewhere in this world actually thought it was a good idea to involve the total resource mass in this affair.... just on the off chance that things weren't as bad as they could be

[Capt Snuggler]

You know, the thing of it is though, to get wet mass in code you have to do this: part.mass + part.GetResourceMass()

So it strikes me as a pretty willful thing to have done. Someone, somewhere in this world actually thought it was a good idea to involve the total resource mass in this affair.... just on the off chance that things weren't as bad as they could be

lol what thought process does a person go through? maybe it was copy/pasted from somewhere else and no one noticed it? gravity code perhaps (I no programmer )

I guess its kinda hard to notice at first glance. the resource drag effect is kind of masked by gravity and inertia. it looks weird but you don't know why. its even harder to spot the screwy behavior under normal vertical launch conditions too.

[Starwaster]

One effect is that everything has the same terminal velocity. The increased drag exactly offsets inertia such that two identical tanks which should have the same drag except one is full so its inertia should overcome drag and it should fall faster than an empty one.

That has a big impact on reentry. Now it's a little harder slowing a large tank full of fuel. (You know, the one you needed to take off again )

[Tahib]

Does this work in 0.25?

[Starwaster]

Does this work in 0.25?

Yes, this is still currently functional as is. A proper recompile will happen sometime in the next day or so.

[GavinZac]

Very clever solution. Very odd that someone at Squad purposefully added fuel weight to drag. I hope it's not a difficulty balance issue. I'll give it a go and see but all reports seem good so far!

[Andrew Hansen]

Very odd that someone at Squad purposefully added fuel weight to drag.

It used to be that when you hit the atmosphere at super high velocities in very early versions of KSP, different parts had different values for drag, and would often collide into each other and cause explosions. I think they made most parts have equal drag values to stop that from happening.

[NathanKell]

But that's just the point: Parts *don't* have equal drag values. With the coefficient of drag constant, drag will be *purely* proportional to mass and atmospheric density and the square of velocity. If they wanted parts to have the same drag, then an empty and a full fuel tank would have the same drag, but they don't.

[Starwaster]

But that's just the point: Parts *don't* have equal drag values. With the coefficient of drag constant, drag will be *purely* proportional to mass and atmospheric density and the square of velocity. If they wanted parts to have the same drag, then an empty and a full fuel tank would have the same drag, but they don't.

But they both will have the same amount of inertia and their terminal velocities will be the same. Put them side by side with the same starting velocity and they'll fall at the same rate even though the full tank should fall faster. That's probably why he thinks their drag is the same.

[MartGonzo]

This looks interesting, are there any compatibility issues with this and deadly reentry?

also I'm guessing it's not compatible with tweakscale if I change part sizes?

[Starwaster]

This looks interesting, are there any compatibility issues with this and deadly reentry?

also I'm guessing it's not compatible with tweakscale if I change part sizes?

I play with both this and Deadly Reentry and they're just fine together.

Tweak Scale shouldn't really be a problem either. The mod still performs its primary goal of eliminating drag caused by resource mass. Parts tweaked to larger sizes will have more drag than smaller sizes which is more or less offset by the increase in mass. In the end it balances itself out naturally.

I wouldn't worry about it.

[MartGonzo]

I play with both this and Deadly Reentry and they're just fine together.

Tweak Scale shouldn't really be a problem either. The mod still performs its primary goal of eliminating drag caused by resource mass. Parts tweaked to larger sizes will have more drag than smaller sizes which is more or less offset by the increase in mass. In the end it balances itself out naturally.

I wouldn't worry about it.

That's great, I'll give it a go

thanks Starwaster

[drtedastro]

Hello Starwaster, just checking to see if you have made the 'new' re-compile yet.

thanks

[Starwaster]

Hello Starwaster, just checking to see if you have made the 'new' re-compile yet.

thanks

Soon...........

[drtedastro]

no problem'o....

just wanted to make sure I had not missed it.....

cheers.

[Starwaster]

http://www.curse.com/ksp-mods/kerbal/222057-stock-drag-fix

SDF 1.1 Change log:

Update for KSP 0.90

- Recompiled for KSP 0.90

- Optimization changes:

- Removed unnecessary checks and computations

- Moved dragScale sanity check to main SDF class. (one time execution)

- Fed some turkey sammich to Cleopatra, The Feral Cat

Edited December 16, 2014 by Starwaster

[Ignath]

Any chance we could get this put up on gitHub or even KerbalStuff so it can be added to the CKAN mod manager? If it already is, apologies.

[Starwaster]

Any chance we could get this put up on gitHub or even KerbalStuff so it can be added to the CKAN mod manager? If it already is, apologies.

I'll see about a GitHub release. Is there something I have to do for CKAN specifically?

Edit:

https://github.com/Starwaster/StockDragFix/releases/tag/1.1

Edited December 16, 2014 by Starwaster

[Ignath]

I'll see about a GitHub release. Is there something I have to do for CKAN specifically?

Edit:

https://github.com/Starwaster/StockDragFix/releases/tag/1.1

I believe CKAN just needed a download link that doesn't point directly to Curse (I seem to recall from the CKAN thread that Curse won't open up their API/download links so CKAN can't point to the .zip for download).

Information on setting your mod up for CKAN can be found in the thread. You can do it (as the modder) or someone else can do it for you I believe. All the information on how to set up your mod with CKAN can be found here:

https://github.com/KSP-CKAN/CKAN/wiki/Adding-a-mod-to-the-CKAN

It's easiest from Kerbal Stuff, but not much harder to do from gitHub.

Also, thanks so much for the quick response to my request! +Rep

[pacbard]

I'll set up the netkan file for you if you want. I think that the github link will be enough for ckan to even automatically index future updates.

Edit:

This netkan file works just fine:

{

"spec_version" : 1,

"identifier" : "StockDragFix",

"$kref" : "#/ckan/github/Starwaster/StockDragFix",

"name" : "Stock Drag Fix",

"abstract" : "Fixes aerodynamic issues without breaking compatibility",

"license" : "CC-BY-SA-4.0",

"ksp_version" : "0.90",

"resources" : {

"homepage" : "http://forum.kerbalspaceprogram.com/threads/84978",

"repository" : "https://github.com/Starwaster/StockDragFix",

}

}

If it is ok with the author, I can even take care of the pull request to netkan's repo.

Edited December 16, 2014 by pacbard
Add resources to netkan file