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

[Kerbas_ad_astra]

I've flown a few little jets with Stock Drag Fix with no issues. If I start having trouble with spaceplanes, I'll let you know, but I don't expect any. What it should mean is that, as "resource drag" is zeroed out, airplanes will have higher top speeds and thus peak altitudes, and not much else different.

[Eskandare]

I have a problem with my stations magically accelerating for no reason. It grips onto docking ports or anything that ts radially attached. There is No NRE or NaN recorded in fact KSP thinks it's running normally. SDF is the last thing loaded before the effect happens.

[GreatGreengGoo]

I love this. I also found FAR to difficult for me. While I appreciate the complexity and hard work put into the mod, I just couldnt get the hang of it. Its an awesome mod, its just not for me. Because I suck . This mod has been what I have been looking for. A reason to at least put nose cones your your stuff. Now if only fairings and cargo bays would work with this it would be perfect.

[Andrewmacor]

I have a problem with my stations magically accelerating for no reason. It grips onto docking ports or anything that ts radially attached. There is No NRE or NaN recorded in fact KSP thinks it's running normally. SDF is the last thing loaded before the effect happens.

I had a problem like that without the stuff not undocking, but the accelerating was fixed when I updated Kerbal Joint reinforcement, Check if out that might be it. But about the Undocking problem I've had that for a little while even when I used to play stock so just try it

BTW if anybody knows a fix for undocking problems please pass it over, because it sucks to get out and do the save file thing over and over.

[rynak]

For those of you, having issues with reaching orbit becoming too easy.... be it with SDF, NEAR or FAR.... all those aero mods are best complemented with KIDS (so yes, ironically the best complement to SDF, is a plugin by ferram). KIDS lets you globally scale thrust and isp with a few simple sliders, so you can globally adjust engine ratings as you want them.

[Starwaster]

I have a problem with my stations magically accelerating for no reason. It grips onto docking ports or anything that ts radially attached. There is No NRE or NaN recorded in fact KSP thinks it's running normally. SDF is the last thing loaded before the effect happens.

Sorry to hear about that but it's definitely coincidence and not causality.

I love this. I also found FAR to difficult for me. While I appreciate the complexity and hard work put into the mod, I just couldnt get the hang of it. Its an awesome mod, its just not for me. Because I suck . This mod has been what I have been looking for. A reason to at least put nose cones your your stuff. Now if only fairings and cargo bays would work with this it would be perfect.

Fairings: Eventually. Can't say when.

Cargo Bays: How about right now?

Create a file named SDF_CargoBays.cfg in your StockDragFix folder. Copy the spoilerified code below into that file. Save it.

(only covers Mk2 & Mk3 cargo bays for now. More will be added later when this config is officially added to SDF)

@PART[mk2CargoBayS]
{
MODULE
{
name = ModuleCargoBay
DeployModuleIndex = 0
closedPosition = 1.0
}
}
@PART[mk2CargoBayL]
{
MODULE
{
name = ModuleCargoBay
DeployModuleIndex = 0
closedPosition = 1.0
}
}
@PART[mk3CargoBayS]
{
MODULE
{
name = ModuleCargoBay
DeployModuleIndex = 0
closedPosition = 1.0
}
}
@PART[mk3CargoBayL]
{
MODULE
{
name = ModuleCargoBay
DeployModuleIndex = 0
closedPosition = 1.0
}
}

Please note that this relies on stock KSP code that is NOT actually a part of SDF. It's an undocumented and unused PartModule that was added in KSP 0.25 that sets a field named ShieldedFromAirstream. If that field is set to True then the part is ignored for drag.

I haven't found any bugs when using it, but if any are found they will almost certainly be outside my ability to fix as this is KSP's own code.

Another noteworthy piece of information is that this will also work with Deadly Reentry. Deadly Reentry checks .ShieldedFromAirstream and ignores the part for heating if it is set to True. This config would even work without SDF because it's pure stock.

FINALLY: Big Caveat! (forgot to add this)

Using this config will almost certainly confuse MechJeb. I'm pretty sure MJ2 does not check the ShieldedFromAirstream field at all when calculating drag and it will confuse the Landing Guidance / Autopilot.

BTW if anybody knows a fix for undocking problems please pass it over, because it sucks to get out and do the save file thing over and over.

Known issue. Check the support threads; I'm pretty sure it got stickied, or if not then that thread will be near the top because it is commented in semi-frequently.

Edited January 18, 2015 by Starwaster

[chrisl]

I'm using a spaceplane built on the mk2 body. I've got both SDF and DE (amongst other mods). I'm starting from a stable 80km orbit. What is a survivable reentry angle? My ladder (needed so I can do eva and closed during reentry) keeps burning up and I've lost winglets, and even the cockpit on various reentry attempts. I'll keep plugging away trying to find a survivable reentry angle but if anyone has a suggestion, that would be great.

EDIT: Could you use something similar to the "ShieldedFromAirstream" code on the ladders?

Edited January 18, 2015 by chrisl

[Starwaster]

I'm using a spaceplane built on the mk2 body. I've got both SDF and DE (amongst other mods). I'm starting from a stable 80km orbit. What is a survivable reentry angle? My ladder (needed so I can do eva and closed during reentry) keeps burning up and I've lost winglets, and even the cockpit on various reentry attempts. I'll keep plugging away trying to find a survivable reentry angle but if anyone has a suggestion, that would be great.

EDIT: Could you use something similar to the "ShieldedFromAirstream" code on the ladders?

Maybe.... I'll take a look at it.

[Galane]

So with the right mods you can play Kerbal Space Program with your KIDS NEAR HOME.

[chrisl]

The SDF_CargoBay config doesn't seem to work. At least not on the Mk3 bays. I'm testing a Mk3 spaceplane that has a small and medium cargo bay (I did update the cfg to include the "mk3CargoBayM", module). I've got a Communotron32 (from RemoteTech) and I'm using Deadly Reentry. The Communotron is installed inside the cargobay. Just before take off, I activate the antenna and close the cargo bay doors. Then fire the engines and about 2/3 down the runway there's a small explosion and my antenna is gone.

[Starwaster]

The SDF_CargoBay config doesn't seem to work. At least not on the Mk3 bays. I'm testing a Mk3 spaceplane that has a small and medium cargo bay (I did update the cfg to include the "mk3CargoBayM", module). I've got a Communotron32 (from RemoteTech) and I'm using Deadly Reentry. The Communotron is installed inside the cargobay. Just before take off, I activate the antenna and close the cargo bay doors. Then fire the engines and about 2/3 down the runway there's a small explosion and my antenna is gone.

That's not enough information to go on.

Did you press F3 to see what the destruction message was?

output_log.txt would be nice.

But I'm going to have to say that RemoteTech itself that decided that the part had to be destroyed and it's up to the RT developers to decide that the cargo bay module that is in KSP can dictate what is shielded.

Edit: Had to go take garbage out and prepare the cats for a cold night.

So then:

The aforementioned cargo bay module. This is what it does:

It negates stock drag because KSP's own code checks parts to see if the cargo bay module shielded them. (there's a property on the parts that is set and checked)

Deadly Reentry also checks that property because I added code to Deadly Reentry that does so. If the property is read as True then Deadly Reentry will not apply its reentry heating to the part.

And that's it. I am unaware of any other mods that look at that property at all. It's an easy enough check but it's up to the individual developer to implement.

(FYI, solar panels do not. They get broken if deployed in cargo bays too if they are the breakable kind)

Edited January 20, 2015 by Starwaster

[Galane]

I found a problem. The CFG file included with Stock Drag Fix doesn't have the right type of line endings for Windows. Open with Notepad and it's all on one line with inverse 0 characters appearing where the lines are supposed to break.

Open with Wordpad and save and that gets fixed. Can't show the problem here because when pasting the file's contents into the post box it interprets those characters as line breaks and displays as intended instead of as it actually is.

I've run into this same issue with some other mods where a critical text file isn't processed properly because of not using the right type of line breaks.

Now that I've run the CFG through Wordpad I need to test it to see if it works.

[Starwaster]

I found a problem. The CFG file included with Stock Drag Fix doesn't have the right type of line endings for Windows. Open with Notepad and it's all on one line with inverse 0 characters appearing where the lines are supposed to break.

Open with Wordpad and save and that gets fixed. Can't show the problem here because when pasting the file's contents into the post box it interprets those characters as line breaks and displays as intended instead of as it actually is.

I've run into this same issue with some other mods where a critical text file isn't processed properly because of not using the right type of line breaks.

Now that I've run the CFG through Wordpad I need to test it to see if it works.

Sorry, but that's a non-issue.

The game parses the files just fine.

Stop using Notepad and use Notepad++ instead.

http://notepad-plus-plus.org/download

[Galane]

This is what I get in the log, and after the last line here it quits logging.

AddonLoader: Instantiating addon 'StockDragFix' from assembly 'StockDragFix'

(Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49)

noseCone switched to CONIC Drag Model

(Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49)

noseConeAdapter switched to CONIC Drag Model

(Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49)

rocketNoseCone switched to CONIC Drag Model

(Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49)

standardNoseCone switched to CONIC Drag Model

(Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49)

avionicsNoseCone switched to CONIC Drag Model

(Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49)

shockConeIntake switched to CONIC Drag Model

(Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49)

HighlightingSystem : Edge Highlighting requires AA to work!

(Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49)

Note that it's enabling conic drag model despite the cfg having enableConicDragTypes = false

I just did a couple of test flights after running the cfg through Wordpad to fix the line breaks and now the log doesn't quit. Still can't land with MechJeb with SDF.

Still has the switched to CONIC Drag Model lines in the (now normal 2 megabyte + log).

[chrisl]

That's not enough information to go on.

Did you press F3 to see what the destruction message was?

output_log.txt would be nice.

But I'm going to have to say that RemoteTech itself that decided that the part had to be destroyed and it's up to the RT developers to decide that the cargo bay module that is in KSP can dictate what is shielded.

Edit: Had to go take garbage out and prepare the cats for a cold night.

So then:

The aforementioned cargo bay module. This is what it does:

It negates stock drag because KSP's own code checks parts to see if the cargo bay module shielded them. (there's a property on the parts that is set and checked)

Deadly Reentry also checks that property because I added code to Deadly Reentry that does so. If the property is read as True then Deadly Reentry will not apply its reentry heating to the part.

And that's it. I am unaware of any other mods that look at that property at all. It's an easy enough check but it's up to the individual developer to implement.

(FYI, solar panels do not. They get broken if deployed in cargo bays too if they are the breakable kind)

I'll run a few more tests and see what I can come up with.

Something else I encountered. On this same flight, on the back wall of the cargo hold I had a Universal Storage Quadcore and four wedges, plus some radial batteries and radial monopropellant tanks. Flight lifts off and climbs and increases speed steadily. At about 25km I'm pushing 1200m/s which is a bit fast but my climb rate is near 200m/s so I figure I'm going to be okay (using deadly reentry on hard at that point). All of a sudden I get the flame graphics and a split second later my four RAPIER engines skip a beat, theres an explosion, then the RAPIER's kick in again and the flight continues without further complication. I didn't know about F3 to see the destruction message so I do a visual check and I can't find anything missing, though I don't want to open the cargohold at nearly 30km and 1500m/s so I figure whatever it is wasn't critical and I'll figure it out once I'm in orbit. Anyway, I finish climbing in airbreather mode and at about 42km (with RAPIER's all but asphyxiated) and 1800m/s I toggle to closed cycle and finish putting my plane into 80km orbit. However, as I'm preparing for the circulization burn, four little objects float away from my ship. I zoom in and find that they are the four Universal Storage wedges that have floated through my ship. I complete the orbit burn and open up the cargo hold. Only thing missing is the Universal Storage quad core (which I didn't see float off) and the four wedges (which I did). I can only assume that the core burned up but since it was inside the closed cargohold for the entire flight, I'm not exactly sure how that happened. Unfortunately, I'm also not sure if it's a Squad issue, something with SDF or the cargohold config, or if it's Deadly Reentry. Or none of the above, even. The US stuff has pretty low heat thresholds. Is it possible the module the core was attached to heated up enough to pass that heat to the quadcore?

[rynak]

Sorry, but that's a non-issue.

The game parses the files just fine.

Stop using Notepad and use Notepad++ instead.

http://notepad-plus-plus.org/download

Or use notepad2, if you prefer to keep things almost as simple as windows notepad.

[Starwaster]

I'll run a few more tests and see what I can come up with.

Something else I encountered. On this same flight, on the back wall of the cargo hold I had a Universal Storage Quadcore and four wedges, plus some radial batteries and radial monopropellant tanks. Flight lifts off and climbs and increases speed steadily. At about 25km I'm pushing 1200m/s which is a bit fast but my climb rate is near 200m/s so I figure I'm going to be okay (using deadly reentry on hard at that point). All of a sudden I get the flame graphics and a split second later my four RAPIER engines skip a beat, theres an explosion, then the RAPIER's kick in again and the flight continues without further complication. I didn't know about F3 to see the destruction message so I do a visual check and I can't find anything missing, though I don't want to open the cargohold at nearly 30km and 1500m/s so I figure whatever it is wasn't critical and I'll figure it out once I'm in orbit. Anyway, I finish climbing in airbreather mode and at about 42km (with RAPIER's all but asphyxiated) and 1800m/s I toggle to closed cycle and finish putting my plane into 80km orbit. However, as I'm preparing for the circulization burn, four little objects float away from my ship. I zoom in and find that they are the four Universal Storage wedges that have floated through my ship. I complete the orbit burn and open up the cargo hold. Only thing missing is the Universal Storage quad core (which I didn't see float off) and the four wedges (which I did). I can only assume that the core burned up but since it was inside the closed cargohold for the entire flight, I'm not exactly sure how that happened. Unfortunately, I'm also not sure if it's a Squad issue, something with SDF or the cargohold config, or if it's Deadly Reentry. Or none of the above, even. The US stuff has pretty low heat thresholds. Is it possible the module the core was attached to heated up enough to pass that heat to the quadcore?

I have no idea. Need to see a picture of the craft to get some idea of where things were situated prior to the explosion.

[chrisl]

I have no idea. Need to see a picture of the craft to get some idea of where things were situated prior to the explosion.

Ran the flight again and hit F3 just after the explosion. It was definitely the Communotron:

[00:00:12]: Communotron 32 was ripped off by strong airflow.

[00:00:13]: Communotron 32 collided into the surface.

But if it's up to each modder to make use of the "ShieldedFromAirstream" thing, then you're right. This is likely something that the RemoteTech developers would have to address. I mistakenly thought that if SDF blocked the airstream from anything mounted inside the cargohold, it would also protect things that would otherwise normally be ripped off.

As for the exploding quadcore, here's a shot of the inside of the cargo hold looking at the tail section. The Quadcore is actually attached to the back of the cargo hold while the other radial pieces are attached to the actual tail section, which the 2nd shot shows.

[rynak]

I'm not sure if your specific example is a reasonable one: AFAIK, in RT antennae can only rip off, if they're deployed. Now, deploying an antenna in the cargohold seems a bit like a cheat, to circumvent the gameplay restrictions of parts, which RT put there on purpose. If i'm right thus far, the RT devs have no reason to address this "issue".

But ignoring your example, this is of course a valid issue. The problem for people like starwaster is, if it is even worth the effort to do anything about it now, when the next KSP version may or may not address this aspect automatically.

[Starwaster]

I'm not sure if your specific example is a reasonable one: AFAIK, in RT antennae can only rip off, if they're deployed. Now, deploying an antenna in the cargohold seems a bit like a cheat, to circumvent the gameplay restrictions of parts, which RT put there on purpose. If i'm right thus far, the RT devs have no reason to address this "issue".

But ignoring your example, this is of course a valid issue. The problem for people like starwaster is, if it is even worth the effort to do anything about it now, when the next KSP version may or may not address this aspect automatically.

As far as the antenna goes, nothing I or Squad do would stop RT's code from deciding to rip that antenna off so it doesn't even come down to 'is it worth the effort'.

@chrisl, I don't know what to tell you about that part. In flight, open the DRE menu and click Debug Menu. Then right click the core and see what it says for shockwave AFTER you've gone supersonic. That's about when the shockwave starts getting hotter than ambient.

If the part is exposed to the shockwave then you'll see a shockwave temperature.

If the part is considered shielded by DRE's internal code then it'll say 'Shielded'.

If it's been marked as shielded by the cargo bay then it will say 'Shielded (stock)' (you need the 6.5.0 beta version of DRE to see that, otherwise it just displays 'shielded' without qualifier)

[Starwaster]

In other news I've discovered that the commonly believed notion that stock drag is based on mass is incorrect... KSP simply applies the same amount of drag to every part and does it as an acceleration instead of as a force. HarvesteR said as much (vaguely) but nobody seemed to pay it any attention. (ForceMode.Acceleration)

This also means that the premise behind SDF is wrong as well. But I didn't realize that because SDF works. It just works for different reasons than I was thinking.

[rynak]

In other news I've discovered that the commonly believed notion that stock drag is based on mass is incorrect... KSP simply applies the same amount of drag to every part and does it as an acceleration instead of as a force. HarvesteR said as much (vaguely) but nobody seemed to pay it any attention. (ForceMode.Acceleration)

This also means that the premise behind SDF is wrong as well. But I didn't realize that because SDF works. It just works for different reasons than I was thinking.

Umm, this seems broken in so many ways... where do i even start? I suppose the relevant part vars are minimum_drag, maximum_drag and angular_drag? If yes, those indeed are the same for almost any part. So basically, using larger parts produces less drag, than using smaller ones?

If the above is correct, does SDF affect this in any way? If yes, how?

[Crzyrndm]

In other news I've discovered that the commonly believed notion that stock drag is based on mass is incorrect... KSP simply applies the same amount of drag to every part and does it as an acceleration instead of as a force. HarvesteR said as much (vaguely) but nobody seemed to pay it any attention. (ForceMode.Acceleration)

Well technically, if the same acceleration is used for every part, the equivalent force does depend on mass (F = ma. Equivalent force being the force that would have been required to generate said acceleration)

I could ofcourse be totally mis-understanding here

[Starwaster]

Well technically, if the same acceleration is used for every part, the equivalent force does depend on mass (F = ma. Equivalent force being the force that would have been required to generate said acceleration)

I could ofcourse be totally mis-understanding here

Yes, you're misunderstanding. Drag is actually being applied the same way you would apply gravity, which is independent of mass.

The commonly held belief is that this is the equation being used for KSP drag:

Now, read up on Unity3D ForceMode

This is what's being used to apply drag 'force': (this was actually mentioned by HarvesteR recently)

http://docs.unity3d.com/ScriptReference/ForceMode.Acceleration.html

Instead of this:

http://docs.unity3d.com/ScriptReference/ForceMode.Force.html

IRL, drag is a force measured in newtons where 1N equals 1kg being moved 1 meter, right? That's ForceMode.Force. If it massed 2kg then the object only moves half a meter.

ForceMode.Acceleration just applies that as distance. The 2kg object would move 1 meter with 1N.

Now let's say that as a result of our drag equation above we have a 10kg part generating 10N of drag.

With ForceMode.Acceleration it is decelerated by 10 meters.

With ForceMode.Force it would only decelerate 1 meter because its own 10kg mass counteracted the drag force of of 10 Newtons.

[Crzyrndm]

So you're saying the calculated drag force from quoted drag equation is being directly applied as an acceleration (F = a)? (the acceleration is not computed directly in order to make it constant over all parts and avoid the complications to the player varying forces cause)

Edited January 22, 2015 by Crzyrndm