How Do The New Parachutes Work?

[Beale]

It's black magic, I'm sure.

A couple of examples:

So note:

• Parachutes are adding horizontal velocity, producing a gliding effect.
  
• Parachutes not slowing the capsule down nearly enough.
  
• Parachutes creating mystery "torque" on deploy.
  

What I'm doing.

• Parachute config values a pulled from stock chutes
  
• All tests, the capsule deploys parachute at 9000m travelling straight downwards
  
• Some parachutes I've made seem to work fine, others: the pictures above.
  

Sorry for such a borderline rant post, but I just cannot seem to figure out the new mechanics.

Example config.

PART
{

name = Spica_Parachute_A
module = Part
author = Tantares

MODEL
{
   model = Tantares/Parts/GEMINI/Spica_Parachute_A/model
   texture = Spica_Crew_A_psd , Tantares/Parts/GEMINI/Spica_Crew_A/Spica_Crew_A_psd
}
scale = 1

node_stack_bottom = 0.0, -0.143, 0.0, 0.0, -1.0, 0.0, 0
node_stack_top    = 0.0,  0.143, 0.0, 0.0, 1.0, 0.0, 0
bulkheadProfiles = size0

sound_parachute_open = activate
sound_parachute_single = deploy

TechRequired = survivability
entryCost = 2000
cost = 600

category     = Utility
subcategory  = 0
title        = G-143A Orientation Parachute
manufacturer = Tantares Space Technologies
description  = A parachute with a built in RCS system, to finer control re-entry orientation.
attachRules = 1,0,1,1,0

mass = 0.16

dragModelType  = default
maximum_drag   = 0.20
minimum_drag   = 0.15
angularDrag    = 2
crashTolerance = 10
maxTemp        = 2000
fuelCrossFeed = False

stageOffset = -1

MODULE
{
  	name = ModuleParachute
	semiDeployedAnimation = Spica_Parachute_A_Semi
	fullyDeployedAnimation = Spica_Parachute_A_Full
	invertCanopy = false
	autoCutSpeed = 0.5
	capName = Cap
	canopyName = Spica_Parachute_A_Canopy
	stowedDrag = 0.22
	semiDeployedDrag = 1
	fullyDeployedDrag = 500
	minAirPressureToOpen = 0.01
	deployAltitude = 2300
	deploymentSpeed = 1
	semiDeploymentSpeed = 1	
}

MODULE
{
    name = ModuleDecouple
    isOmniDecoupler = false
    ejectionForce = 250
}

MODULE
{
	name = ModuleRCS
	thrusterTransformName = monoTransform
	thrusterPower = 1
	resourceName = MonoPropellant
	atmosphereCurve
 	{
   	 key = 0 240
  	 key = 1 100
 	}
}

	MODULE
	{
		name = ModuleDragModifier
		dragCubeName = SEMIDEPLOYED
		dragModifier = 13
	}
	MODULE
	{
		name = ModuleDragModifier
		dragCubeName = DEPLOYED
		dragModifier = 50
	}


}

[Ven]

I think that your parachutes PartDatabase.cfg entry is a bit wonky, I had the same problem with my Parachute-Docking combo port, and after a bit trial and error, I deleted the PartDatabase.cfg (just inside your KSP folder) to force KSP to recalculate all the parts drag cubes. After that, the problem wen't away for me.

hopefully that solves your problem.

[Beale]

I think that your parachutes PartDatabase.cfg entry is a bit wonky, I had the same problem with my Parachute-Docking combo port, and after a bit trial and error, I deleted the PartDatabase.cfg (just inside your KSP folder) to force KSP to recalculate all the parts drag cubes. After that, the problem wen't away for me.

hopefully that solves your problem.

Thanks for the info!

I'll give it a try

Edit: Appears to have done the trick, many thanks!

Edited May 2, 2015 by Beale

[Tiberion]

I am having zero luck converting my Novapunch chutes into functioning parts for 1.0.x - they seem to animate and deploy correctly as long as they're oriented right in Unity, but as soon as physics kick in they apply weird directional drag, spin around and then explode due to aero forces and heating - if you deploy directly into fullDeploy mode (say under 500m) then it'll sort of jitter wildly and then fling the pod in some direction when it explodes.

We tried endless things last night to solve it without luck. If you have a working chute can you post its setup in Unity. Also, how do you animate it?

To try to solve your horizontal drift issue, try flipping the direction your chute is oriented to locally (make the canopy point +Z locally then add 90 degrees rotation in Unity to make it look right) - Mine seem to deploy in the right direction now, they just don't behave properly afterwards.

Edited May 2, 2015 by Tiberion

[Beale]

I am having zero luck converting my Novapunch chutes into functioning parts for 1.0.x - they seem to animate and deploy correctly as long as they're oriented right in Unity, but as soon as physics kick in they apply weird directional drag, spin around and then explode due to aero forces and heating - if you deploy directly into fullDeploy mode (say under 500m) then it'll sort of jitter wildly and then fling the pod in some direction when it explodes.

We tried endless things last night to solve it without luck. If you have a working chute can you post its setup in Unity. Also, how do you animate it?

To try to solve your horizontal drift issue, try flipping the direction your chute is oriented to locally (make the canopy point +Z locally then add 90 degrees rotation in Unity to make it look right) - Mine seem to deploy in the right direction now, they just don't behave properly afterwards.

Still no luck, I experience much the same problem, sorry!

I too animate Z+ if that helps.

Perhaps someone who worked on the new aero can chime in?

Seriously one of the most frustrating issues at the moment.

Whenever the drag-cube database gets rebuilt, it is getting rebuilt wrong for my parachute parts, or perhaps more likely I've made my parachute parts wrong somehow.

[Shadowmage]

I can confirm that this is mostly (all?) caused by incorrect drag_cube entries in the PartDatabase file;

I too have a Command Module with built in parachutes that simply ceased to function in 1.0+. Adding the drag_cube modules to the part didn't help by itself.

After reading this thread during investigation, I decided to look in the PartDatabase.cfg file.

Drag cube is listed as 'procedural=true' for my part in question; there are not multiple entries for stowed/semideployed/deployed as there are for the other parachutes. After copying over the drag cube entry from one of the stock parachutes, my part functions... approximately correctly (well, it now slows down the descent properly, and doesn't seem to throw any odd movement vectors in there, but the drag is still way off compared to 0.90)

Does anyone know what these drag cubes are supposed to represent, how to calculate one manually, or how to force the game to properly calculate them?

Edit:

Further browsing brought me to: http://forum.kerbalspaceprogram.com/threads/118847-Tech-Tree-ID-strings , where it is pointed out that drag-cubes can be manually specified in the part config file. And indeed there several stock parts with drag cube overrides in the part .cfg.

Several stock parts have multiple drag-cube entries in the PartDatabase.cfg file, -without- multiple overrides in their part.cfg file. They also do not seem to have any additional colliders/bounding boxes when the .mu is imported into blender. I have a feeling that those parts have new custom bounding boxes or such created in unity to define these custom drag cube properties (tags/layers/naming convention)(which may not be supported by the .mu importer yet). May need to wait for some dev response to know what is up on the part-tools/proper way of doing things.

Additionally, I can note that in the PartDatabase.cfg there is an A and B drag-cube entry for each part with an animation; these cubes seem to roughly correspond with the size of the part at each animation state. Parts with -multiple- animations get drag-cubes listed only as 'procedural=true'; I'm guessing this tells the game engine to recalculate the drag-cube based on the current combination of animation states. Here is where the problem will likely be for any mod-added parachutes at the current time--without knowing how to specify the custom drag-cube overrides in the model, these will likely all default to 'procedural=true' due to multiple animations; the default procedurally calculated drag-boxes are nowhere near appropriate for parachute-like drag, and are not named appropriately for the drag-cube-modifier module to take effect properly.

Each drag-cube entry has a name (first param), followed by 24 comma separated values. As near as I can tell, these value are broken into 8 groups of 3, representing the 3-dimensional coordinates for the corners of a bounding box. Makes sense for something called a 'drag-cube'. I'm still working over the conversion of these values into the bounding box, and how it relates to the part orientation and dimensions.

I did notice for stock parachutes that the drag cube seemed to be offset quite a bit on the X+ axis (if X is the first coordinate given...still working on that...), up to 100 units for the larger parachute.

--going to import some of these .mu models into blender, and map their drag cubes over top of them, to see how they correspond to model-space. This should hopefully give enough information to specify some custom drag-cubes that -work-, with further tweaking in the part.cfg through the drag-cube multiplier stats.

-- further edit:

A quick plotting in blender of one of these 'cubes' (as 8 groups of 3, each a 3-d coordinate), fails to make any sense as a geometric shape. I cannot seem to make any sense out of the numbers given, in any kind of coordinate addressing system that I am familiar with.

Now the question is back to, how to manually calculate one (or three in the case of a parachute?)

Edited May 3, 2015 by Shadowmage

[Gristle]

Some drag cube info here. Nothing concerning parachutes but StupidChris does define what the values are. http://forum.kerbalspaceprogram.com/threads/118362-Drag-cubes

[raidernick]

To stop the parachute gliding add this to the part config: bodyLiftMultiplier = 0, delete the partdatabase file after changing this. You'll notice all stock chutes have this value.

Edited May 3, 2015 by raidernick

[Gristle]

To stop the parachute gliding add this to the part config: bodyLiftMultiplier = 0, delete the partdatabase file after changing this. You'll notice all stock chutes have this value.

Nice! - confirmed this worked for me.

[Shadowmage]

Thanks for the additional links and info. That explanation of drag cubes -should- give me enough to create some custom ones for my parachutes.

I wonder if I could get the game to properly calculate my parachute drag-cubes automatically if I removed all-other animations from the part? The stock parachutes seem to have theirs calculated automatically, but mine will only ever say 'procedural=true' whenever I let stock calculate it (likely due to the multiple animations, some of which are not related to the parachute; none of the other animations interfere with geometry though).

From the linked thread:

Each drag cube entry contains a name and 8 sets of 3 numbers. The first 6 sets are the projection of the part as onto a plane for each of the six faces of a cube. The last 2 sets are unknown. In each of the first six sets of values, the first number represents the area (w/h), the second the drag coefficient, and the third is the depth. They are listed in X+, X-, Y+, Y-, Z+, Z- order as far as I'm aware.

Drag Coefficient stuff: http://en.wikipedia.org/wiki/Drag_coefficient

Knowing this, I'll be working through some of the drag-cube stuff today, figuring out the best way to manually specify drag cube(s) for custom parachutes; will post up whatever information I can find/figure out. I will likely start by comparing some stock values to see how they 'look', and do some trial and error from there to find how each value effects the outcome. Some real, hard, info on how this stuff should be properly calculated would be much appreciated if anyone can find it.

[Cocox]

How do I make an MM patch to add "bodyLiftMultiplier = 0" to all parachute parts?

[Shadowmage]

Stock parachutes (and those from other mod authors) should already have that line in them. You should only need to add that to any custom parachutes that you personally create.

(Sorry, I have no experience with ModuleManager, so cannot tell you how to do the patch=\)

[NathanKell]

@PART[*]:HAS[@MODULE[ModuleParachute]]

{

%bodyLiftMultiplier = 0

}

[Beale]

To stop the parachute gliding add this to the part config: bodyLiftMultiplier = 0, delete the partdatabase file after changing this. You'll notice all stock chutes have this value.

Fantastic, that's fixed it!

Many thanks raidernick!

[Shadowmage]

I found how to get the game to auto-calculate the drag cube for a part with non-parachute related (or really any) animations.... comment them out of the part config, and reload the PartDatabase.cfg. It will them properly calculate the parachute drag cubes and insert those values into the PartDatabase.cfg.

Now the problem I'm coming across is that the method for custom-specifying a drag-cube in the part config file is not fully implemented/does not work for multiple named cubes. All three named cubes get inserted into the PartDatabase.cfg, but instead of starting with cube = DEPLOYED, etc... they start with DEPLOYED = DEPLOYED, and are not registered/loaded properly as far as the parachute module is concerned. I examined the stock pieces that have drag cube overrides in the part.cfg file, and they have the same bug/issue in the PartDatabase.cfg file; their drag cubes are started with 'Default = Default', rather than the proper 'cube = Default'.

So for now, I've removed the extra animations from my part (some cabin light emissive stuff....), so that the game auto-calculates the drag cubes properly, I can use the parachute drag-cube-multiplier modules, and possibly be able to release my parts one day.

I suppose I should probably report this find to the KSP Bug Tracker?