[1.3.0] Inline Ballutes [IB] (v1.2.8) [30.05.2017]

[riocrokite]

Interestingly enough, with Deadly Reentry installed ballutes start to overheat above 60km in Kerbin's atmosphere. I couldn't find the source of the issue.

do you play with FAR or stock aero?

Note: Deadly Reentry no longer interferes with chutes. Both stock chutes and Real Chutes have adopted their own implementations of punishing deployments at unsafe speeds. The above warning still applies except you don't get to blame Deadly Reentry about it.

* Deadly Reentry no longer implements reentry heating. Instead it tweaks parameters to make stock reentry deadlier.

Inline Ballute stock config was balanced so you're barely able to reenter Kerbin atmosphere. Since Deadly Reentry does not change parachute stats and instead increases heating issues with stock atmosphere the only way to counteract this is to increase chuteEmissivity and/or maximumSkinTemp stats.

Edited September 21, 2015 by riocrokite

[cttw]

CKAN please.

[Enceos]

do you play with FAR or stock aero?

Inline Ballute stock config was balanced so you're barely able to reenter Kerbin atmosphere. Since Deadly Reentry does not change parachute stats and instead increases heating issues with stock atmosphere the only way to counteract this is to increase chuteEmissivity and/or maximumSkinTemp stats.

I'll do some testing today to see what skin temp values are good for DeadlyReentry. Looks like we'll need another config for DRE support. Haven't tested in stock yet, what is the optimal altitude range for ballute operation during Kerbin reentry without DRE before they start to burn?

[riocrokite]

I'll do some testing today to see what skin temp values are good for DeadlyReentry. Looks like we'll need another config for DRE support. Haven't tested in stock yet, what is the optimal altitude range for ballute operation during Kerbin reentry without DRE before they start to burn?

yah, I guess the mod will module manager config with something like :AFTER[DeadlyReentry] { [new values] }

For Kerbin reentry I tested only for the scenario that you reenter from 70km orbit with minimal angle of reentry.

Other thing is that I had to reduce drag area of ballute to accomodate it's lower drag than parachute (since there's I think no option to change ModuleParachute drag). This means that ballute has effectively 1/3 surface area that it should have for heating calculations (not to mention different shape ).

So I guess that tweaking (lowering) values like:

machHeatMultBase = 0.5 // = 1.0

machHeatMultScalar = 1.25 // = 1.75

machHeatMultPow = 1.2 // = 1.5

might resolve overheating issues as well.

Those values are used to compute mach heat multiplier that is then taken to compute parachute heating.

(I guess I could increase a value of convectiveCoefficient 3 times to compensate less ballute area but it is taken from the vessel parameters so cannot be set to not affect all vessel stats).

Edited September 21, 2015 by riocrokite

[Starwaster]

I'll do some testing today to see what skin temp values are good for DeadlyReentry. Looks like we'll need another config for DRE support. Haven't tested in stock yet, what is the optimal altitude range for ballute operation during Kerbin reentry without DRE before they start to burn?

Test in stock first. Can't stress that enough.

Also, hope you understand that DRE only affects the part and not the chute once deployed. We don't touch that anymore

Edit: Also, unless the part itself has to be exposed to the reentry shockwave, you don't really have to do anything to its thermal properties. (speaking strictly of part thermals, not chute thermals). If the part is meant to survive when exposed then increase its skinThermalMass or part thermalMass. Possibly add a heat shield to it or change its skin thermals to match what I did with space planes.

If your problems are only with the chute itself then it's highly unlikely that DRE is the cause (for reasons already stated here and quoted above)

Edited September 21, 2015 by Starwaster

[riocrokite]

Test in stock first. Can't stress that enough.

Also, hope you understand that DRE only affects the part and not the chute once deployed. We don't touch that anymore

Edit: Also, unless the part itself has to be exposed to the reentry shockwave, you don't really have to do anything to its thermal properties. (speaking strictly of part thermals, not chute thermals). If the part is meant to survive when exposed then increase its skinThermalMass or part thermalMass. Possibly add a heat shield to it or change its skin thermals to match what I did with space planes.

If your problems are only with the chute itself then it's highly unlikely that DRE is the cause (for reasons already stated here and quoted above)

Yah, stock and DRE overheating should be the same. From what I see DRE adds damage to part if it's overheated thus reducing some of it's stats. However it shouldn't change heating factor itself.

[Starwaster]

Yah, stock and DRE overheating should be the same. From what I see DRE adds damage to part if it's overheated thus reducing some of it's stats. However it shouldn't change heating factor itself.

That part's not actually functional ATM. The way that works is that if part.temperature > part.maxTemp * 0.8 then the part is basically on fire and taking damage, which reduces certain other attributes. It didn't properly get updated for 1.0. Right now, a part's internal temperature is almost never adversely affected so it doesn't 'catch fire'.

But you're right, it won't affect your situation at all.

I'm going to take this for a spin both in stock and DRE today and see what's happening.

[Enceos]

@Starwaster

I've been doing some extensive tests today, spent almost 5 hours tweaking values up and down and testing.

On reentry ballute skin temperature spikes to a number around 2450K so I changed the skinMaxTemp value to 2600, the case itself doesn't heat up much if occluded from below so the best value is 1600K for the maxTemp. I felt that part didn't heat up fast enough, so these values changed the picture for the better:

skinSkinConductionMult = 0.003

skinInternalConductionMult = 0.003

In the ModuleParachute I changed the chuteMaxTemp to match the skinMaxTemp = 2600.

The drag of the ballute is good enough currently.

I noticed that drag is affected only by semiDeployedDrag and fullyDeployedDrag from the ModuleParachute.

The values in ModuleDragModifier are probably for the case itself, they didn't affect the drag of the deployed ballute at all, even with some drastic numbers.

In real life Ballutes are designed to withstand even 7km/s reentries, but not more than 4G deceleration load. My current config currently allows high velocity reentry but doesn't punish for G overload. Is there any way to change that?

Below is the code of the most successful config so far.

PART
{
    name = InlineBallute250
    module = Part
    author = Riocrokite, Enceos


scale = 1


MODEL
{
    model = KermangeddonIndustries/InlineBallutes/Ballute250
    scale = 1.25,1.25,1.25
}


scale = 1.25
rescaleFactor = 1




    node_stack_bottom = 0.0, -0.71, 0.0, 0.0, -1.0, 0.0, 2
    node_stack_top = 0.0, 0.71, 0.0, 0.0,  1.0, 0.0, 2




    sound_parachute_open = activate
    TechRequired = landing
    entryCost = 17000
    cost = 2000
    category = Utility
    subcategory = 0
    title = Inline 'big lunch' Ballute (2.5m)
    description =  When it was first launched it gathered policemen from the area. Bill wonders to this day - why. Big Lunch is a 2.5m inline toroidal ballute version. Good for slowing down rockets in upper atmosphere and as a source for squeeky voice (lots of helium inside). Rating: good for vessels up to 30 tons.


    attachRules = 1,0,1,0,0
    mass = 2
    dragModelType = default
    angularDrag = 1
    crashTolerance = 12
    maxTemp = 1600 // = 3100
    emissiveConstant = 0.7
    breakingForce = 200
    breakingTorque = 100
    bodyLiftMultiplier = 0
    stageOffset = -1
    fuelCrossFeed = True
    skinSkinConductionMult = 0.003       // = 1
    skinInternalConductionMult = 0.003   // = 1
      skinMaxTemp = 2600             // = -1 
    bulkheadProfiles = size2




    MODULE
    {
        name = ModuleParachute
        invertCanopy = true
        autoCutSpeed = 1
        capName = cap
        canopyName = canopy
        semiDeployedAnimation = semiDeploy
        fullyDeployedAnimation = fullDeploy
        stowedDrag = 0.22
        semiDeployedDrag = 500
        fullyDeployedDrag = 500
        minAirPressureToOpen = 0.000001
        clampMinAirPressure = 0.000001
        deployAltitude = 10000
        deploymentSpeed = 0.12
        semiDeploymentSpeed = 0.5
        chuteMaxTemp = 2600
        chuteThermalMassPerArea = 0.2
        chuteEmissivity = 2.4
    }


    MODULE
    {
        name = ModuleDragModifier
        dragCubeName = SEMIDEPLOYED
        dragModifier = 0.6
    }

    MODULE
    {
        name = ModuleDragModifier
        dragCubeName = DEPLOYED
        dragModifier = 0.6
    }


    MODULE
    {
        name = ModuleConductionMultiplier
        modifiedConductionFactor = 0.001
        convectionFluxThreshold = 3000
    }


}

Also I'm having a strange NRE spam in the VAB when taking ballutes from the catalog:

NullReferenceException: Object reference not set to an instance of an object
  at ModuleParachute.SetConvectiveStats () [0x00000] in <filename unknown>:0 
  at ModuleParachute.FixedUpdate () [0x00000] in <filename unknown>:0

It stops after a vessel was launched or reverted back to VAB.

Edited September 21, 2015 by Enceos

[linuxgurugamer]

Looks very interesting. Kudos on your being featured on Mod Monday.

I'm going to keep an eye on this, but since I already have nearly 120 mods installed, I'm going to hold off a bit until either 1.1 is released or I find some mods I can remove.

[Starwaster]

@Starwaster

I've been doing some extensive tests today, spent almost 5 hours tweaking values up and down and testing.

On reentry ballute skin temperature spikes to a number around 2450K so I changed the skinMaxTemp value to 2600, the case itself doesn't heat up much if occluded from below so the best value is 1600K for the maxTemp. I felt that part didn't heat up fast enough, so these values changed the picture for the better:

skinSkinConductionMult = 0.003

skinInternalConductionMult = 0.003

In the ModuleParachute I changed the chuteMaxTemp to match the skinMaxTemp = 2600.

The drag of the ballute is good enough currently.

I noticed that drag is affected only by semiDeployedDrag and fullyDeployedDrag from the ModuleParachute.

The values in ModuleDragModifier are probably for the case itself, they didn't affect the drag of the deployed ballute at all, even with some drastic numbers.

In real life Ballutes are designed to withstand even 7km/s reentries, but not more than 4G deceleration load. My current config currently allows high velocity reentry but doesn't punish for G overload. Is there any way to change that?

Below is the code of the most successful config so far.

Also I'm having a strange NRE spam in the VAB when taking ballutes from the catalog:

NullReferenceException: Object reference not set to an instance of an object
  at ModuleParachute.SetConvectiveStats () [0x00000] in <filename unknown>:0 
  at ModuleParachute.FixedUpdate () [0x00000] in <filename unknown>:0

It stops after a vessel was launched or reverted back to VAB.

Ugh, emmissive shouldn't be set so high... more than 0.8 - 0.85 should be enough and anything over than 1 is unrealistic. (so is 1 itself; that's a perfect blackbody). It's probably not a huge deal though, but fair warning, the potential is there to break thermal physics since the formulae are based on real physics.

The error you're getting is a stock issue. You'll even get it on stock chutes.

Edit: Suggestion. If you make a DRE specific config, manually add ModuleAeroReentry with leaveTemp = true in it.

MODULE
{
	name = ModuleAeroReentry
	leaveTemp = True
}

Currently that's not actually necessary for skin temps, but somewhere down the line, DRE will do the same thing for skin temps that it does for internal temps which is to sanitize them, so best be prepared. (leaveTemp is basically telling DRE that you understand the consequences of really high max temps and that you know what you're doing and to leave my temps alone)

Edited September 22, 2015 by Starwaster

[Enceos]

Ugh, emmissive shouldn't be set so high... more than 0.8 - 0.85 should be enough and anything over than 1 is unrealistic. (so is 1 itself; that's a perfect blackbody). It's probably not a huge deal though, but fair warning, the potential is there to break thermal physics since the formulae are based on real physics.

Actually I'm not sure this chuteEmissivity line did anything at all. There's no such variable in the ModuleParachute that I can find.

Looks very interesting. Kudos on your being featured on Mod Monday.

I'm going to keep an eye on this, but since I already have nearly 120 mods installed, I'm going to hold off a bit until either 1.1 is released or I find some mods I can remove.

Inline ballutes is not actually a mod, but two part models and one texture which use all the stock modules. So it's only a 3Mb addition to your GameData. You can delete some unnecessary normals or resize the stock texture of the stock Ladder Telescopic Bays, for example, (6Mb waste) to squeeze in the ballutes. I'm running 136 mods currently on Windows By resizing Squad textures I've reduced my GameData folder by 50 Mb. By resizing unnecessarily big textures of other mods I won another 400Mb, so whenever I happen to encounter a rare game crash - it's not because of RAM issues.

Edited September 22, 2015 by Enceos

[riocrokite]

Actually I'm not sure this chuteEmissivity line did anything at all. There's no such variable in the ModuleParachute that I can find.

Yes, there is; default = 0.2. It is taken to calculate parachute cooling (along with areaDeployed and invThermalMass).

Ugh, emmissive shouldn't be set so high... more than 0.8 - 0.85.

Yah, however to somehow cheat static drag and other parachute parameters in ModuleParachute one has to increase other values to account for increased heat emission/radiation and less heating per given area

@Starwaster

I've been doing some extensive tests today, spent almost 5 hours tweaking values up and down and testing.

On reentry ballute skin temperature spikes to a number around 2450K so I changed the skinMaxTemp value to 2600, the case itself doesn't heat up much if occluded from below so the best value is 1600K for the maxTemp. I felt that part didn't heat up fast enough, so these values changed the picture for the better:

skinSkinConductionMult = 0.003

skinInternalConductionMult = 0.003

In the ModuleParachute I changed the chuteMaxTemp to match the skinMaxTemp = 2600.

The drag of the ballute is good enough currently.

I noticed that drag is affected only by semiDeployedDrag and fullyDeployedDrag from the ModuleParachute.

In real life Ballutes are designed to withstand even 7km/s reentries, but not more than 4G deceleration load. My current config currently allows high velocity reentry but doesn't punish for G overload. Is there any way to change that?

Thx for testing Enceos,

Yah, semiDeployedDrag and fullyDeployedDrag seems to be the only thing that can affect it.

Considering max skin temperature, I would like to keep it somehow real. Zylon max temperature in reallife is about 650C. So increasing it to 1400 is already a stretch for the needs of stock KSP ParachuteModule. However 2450C for thin material is way too much.

In real life ballutes are considered for slowing down crafts only in thin atmospheres like Mars, Titan or just aerobraking in very top layers of atmopshere like Neptun or Saturn (orbiters). They wouldn't survive Kerbin/Laythe reentry. You can browse Miriam-2 tests, it was only tested for upper Earth atmosphere, not for all descent profile (I'm sure it would burn:)).

Thus the main usage in Kerbol system should be Duna aerobrake and aerocapture. Since there aren't any other planets with a thin atmosphere in stock Ballutes shouldn't be able to do much more. Hence my values of 1400-1600 max temp. Also note that this works relatively well with FAR.

All in all, if anything I would rather increase emissivity further so the stagnation max temperature would be lower (below 1000C) than increase max skin temperature further.

Also I would keep skinSkin and skinInternal conduction as low as possible since a ballute shouldn't heat internals of the part nor transfer its temperature to other parts' skins.

edit:

I'll do some testing with stock FAR and DRE soonish, for now I need to move my other projects. Moreover I prefer to wait a bit longer and gather feedback from more people before making final appropriations in part configs.

Edited September 22, 2015 by riocrokite

[genericeventhandler]

I've been playing with this over the weekend, I've managed to do a fast re-entry from mun using ballutes to slow down.

However one small problem.

using stock areo.

• mk1 command pod + small parachute
  
• inline balute of appropriate size
  
• heat shield to protect for re-entry.
  
• Put the biggest solid fuel booster underneath with fins.
  

Light it up and point 90 degrees at 65 degress (SURF mode in mechjeb)

The ballute never makes it to space it blows up due to heating before getting to orbit, taking the stack with it.

[Enceos]

Considering max skin temperature, I would like to keep it somehow real. Zylon max temperature in reallife is about 650C. So increasing it to 1400 is already a stretch for the needs of stock KSP ParachuteModule. However 2450C for thin material is way too much.

The problem is KSP does a very very poor job simulating chute thermals. You will get around 2200-2400K skin temperature both during 2km/s reentry and during 7km/s reentry. Temperature kicks in immediately after ballute is deployed at 68km Kerbin altitude and persists until your vertical speed goes positive again, be it at 60 km or 45km altitude. The other big problem is viability of the ballutes with close to real life stats. In real life celestial bodies are much bigger and a probe with a ballute would have like 10-20x more time aerobraking in upper atmosphere than a similar probe in KSP. This means if you didn't get yourself an aerocapture on the first try, you're out.

The configs I pushed you on Github are trying to bring close to real life result to the end user.

Stock KSP ModuleParachute wasn't really designed with temperatures in mind but rather velocities.

The best solution lies not in the thermals tweaking field. There's another crucial characteristic ballutes have, they can sustain only about 3.5 - 4G deceleration, high G deceleration also assumes temperature. I don't know if we can do this with RealChute, but if we could somehow force the ballutes tear/burn when the deceleration reaches above 4G, then we'll have a true 100% accurate behavior. Wrong and bad idea.

I've been playing with this over the weekend, I've managed to do a fast re-entry from mun using ballutes to slow down.

However one small problem.

using stock areo.

• mk1 command pod + small parachute
  
• inline balute of appropriate size
  
• heat shield to protect for re-entry.
  
• Put the biggest solid fuel booster underneath with fins.
  

Light it up and point 90 degrees at 65 degress (SURF mode in mechjeb)

The ballute never makes it to space it blows up due to heating before getting to orbit, taking the stack with it.

Current ballute configs have very low themal values, until the next mod update replace them temporarily with these:

DOWNLOAD NEW BALLUTE THERMAL CONFIGS

Edited September 22, 2015 by Enceos

[ABZB]

I made a MM patch for RealChute. You could include it in a separate config file in your folder (I am about to test it, so it is possible that is has some bug not yet caught). I do not know what the specific heat should be, so I left it as in the example:

MATERIAL:NEEDS[RealChute]
{
	name = Zylon
	description = Much stronger and resistant to heat than Kevlar however prone to sunlight radiation thus for one time use.
	areaDensity = 0.0002278  // 70% heavier than nylon and x2 to account for toroidal shape
	dragCoefficient = 0.20 // to account for ballute shape compared to parachute
	areaCost = 0.24 // hard to get and expensive
	maxTemp = 1600   // decrease it if you feel it's too op
	specificHeat = 25600 // so it doesn't heat like crazy
	emissivity = 0.7 // good dispersion of heat
}

//Sample config for Ballute250.cfg. Delete everything with '//' (ModuleParachute and ModuleDragModifier) and add RealChuteModule.
//For other ballutes just change preDeployedDiameter and deployedDiameter values to those from commented section of ModuleParachute.
@PART[InlineBallute*]:NEEDS[RealChute]
{
	MODULE
	{
		name = RealChuteModule
		caseMass = #$/../mass$
		@caseMass *= .5 //caseMass of 1 in example is one half mass of 2.5 meter part. assuming this is desired relative mass of casemass.
		timer = 0
		mustGoDown = false
		cutSpeed = 1
		spareChutes = 5

		PARACHUTE
		{     
			ParachuteType = Drag
			material = Zylon
			preDeployedDiameter = #$/../../MODULE[ModuleParachute]/preDeployedDiameter$ // diameter taken from preDeployedDiameter commented value in ModuleParachute
			deployedDiameter = #$/../../MODULE[ModuleParachute]/deployedDiameter$   // diameter taken from deployedDiameter commented value in ModuleParachute
			minIsPressure = true
			minPressure = 0.0000001
			deploymentAlt = 120000
			minDeployment = 120000
			cutAlt = -1
			preDeploymentSpeed = 1
			deploymentSpeed = 4
			preDeploymentAnimation = semiDeploy
			deploymentAnimation = fullDeploy
			parachuteName = canopy
			capName = cap
		}
	}
	!MODULE[ModuleParachute]{}
	!MODULE[ModuleDragModifier]{}
	!MODULE[ModuleDragModifier]{}
}

[Enceos]

I made a MM patch for RealChute. You could include it in a separate config file in your folder (I am about to test it, so it is possible that is has some bug not yet caught). I do not know what the specific heat should be, so I left it as in the example:

You're just in time ABZB, thank you very much. I was just starting to write this config myself.

[ABZB]

You're just in time ABZB, thank you very much. I was just starting to write this config myself.

excellent.

[riocrokite]

The best solution lies not in the thermals tweaking field. There's another crucial characteristic ballutes have, they can sustain only about 3.5 - 4G deceleration, high G deceleration also assumes temperature. I don't know if we can do this with RealChute, but if we could somehow force the ballutes tear/burn when the deceleration reaches above 4G, then we'll have a true 100% accurate behavior.

yah, well I guess with small stock planet diameters and realtively substantial weight + unnatural heating of ballutes it would be good if they could be used to aerobraking from higher speeds. Let's try this and see whether it's not too op.

I made a MM patch for RealChute. You could include it in a separate config file in your folder (I am about to test it, so it is possible that is has some bug not yet caught). I do not know what the specific heat should be, so I left it as in the example:

Thx for a patch ABZB, let me know whether it works so I guess it might be included in next version.

[ABZB]

yah, well I guess with small stock planet diameters and realtively substantial weight + unnatural heating of ballutes it would be good if they could be used to aerobraking from higher speeds. Let's try this and see whether it's not too op.

Thx for a patch ABZB, let me know whether it works so I guess it might be included in next version.

The updated thermal cfgs. from the previous page seem to have the

	machHeatMultBase = 0.5       // = 1.0
		machHeatMultScalar = 1.25    // = 1.75
		machHeatMultPow = 1.2        // = 1.5

		preDeployedDiameter = 19.36	//58.66
		deployedDiameter = 19.36	//58.66

removed, so the formulaic version I posted does not work with them. I will re-write to explicitly mandate diameters per part for now.

- - - Updated - - -

MATERIAL:NEEDS[RealChute]
{
	name = Zylon
	description = Much stronger and resistant to heat than Kevlar however prone to sunlight radiation thus for one time use.
	areaDensity = 0.0002278  // 70% heavier than nylon and x2 to account for toroidal shape
	dragCoefficient = 0.20 // to account for ballute shape compared to parachute
	areaCost = 0.24 // hard to get and expensive
	maxTemp = 1600   // decrease it if you feel it's too op
	specificHeat = 2500 // so it doesn't heat like crazy
	emissivity = 0.7 // good dispersion of heat
}

//Sample config for Ballute250.cfg. Delete everything with '//' (ModuleParachute and ModuleDragModifier) and add RealChuteModule.
//For other ballutes just change preDeployedDiameter and deployedDiameter values to those from commented section of ModuleParachute.
@PART[InlineBallute*]:NEEDS[RealChute]
{
	MODULE
	{
		name = RealChuteModule
		caseMass = #$/../mass$
		@caseMass *= .5 //caseMass of 1 in example is one half mass of 2.5 meter part. assuming this is desired relative mass of casemass.
		timer = 0
		mustGoDown = false
		cutSpeed = 1
		spareChutes = 5

		PARACHUTE
		{     
			ParachuteType = Drag
			material = Zylon

			// If preDeployedDiameter & deployedDiameter are present in base configs, then uncomment the following and delete the specific configs on the bottom.
			//preDeployedDiameter = #$/../../MODULE[ModuleParachute]/preDeployedDiameter$
			//deployedDiameter = #$/../../MODULE[ModuleParachute]/deployedDiameter$
			//@preDeployedDiameter *= 3.030524468
			//@deployedDiameter *= 3.030524468 //conversion between uncommented and commented value in example config

			minIsPressure = true
			minPressure = 0.0000001
			deploymentAlt = 120000
			minDeployment = 120000
			cutAlt = -1
			preDeploymentSpeed = 1
			deploymentSpeed = 4
			preDeploymentAnimation = semiDeploy
			deploymentAnimation = fullDeploy
			parachuteName = canopy
			capName = cap
		}
	}
	!MODULE[ModuleParachute]{}
	!MODULE[ModuleDragModifier]{}
	!MODULE[ModuleDragModifier]{}
}

@PART[InlineBallute125]
{
	@MODULE[RealChuteModule]
	{
		@PARACHUTE
		{
			preDeployedDiameter = 29.32
			deployedDiameter = 29.32
		}
}

@PART[InlineBallute250]
{
	@MODULE[RealChuteModule]
	{
		@PARACHUTE
		{
			preDeployedDiameter = 58.66
			deployedDiameter = 58.66
		}
}


@PART[InlineBallute375]
{
	@MODULE[RealChuteModule]
	{
		@PARACHUTE
		{
			preDeployedDiameter = 111
			deployedDiameter = 111
		}
}



@PART[InlineBallute500]
{
	@MODULE[RealChuteModule]
	{
		@PARACHUTE
		{
			preDeployedDiameter = 147
			deployedDiameter = 147
		}
}

EDIT: I'll throw a pull request on github, if that is more convenient.

[Starwaster]

The best solution lies not in the thermals tweaking field. There's another crucial characteristic ballutes have, they can sustain only about 3.5 - 4G deceleration, high G deceleration also assumes temperature. I don't know if we can do this with RealChute, but if we could somehow force the ballutes tear/burn when the deceleration reaches above 4G, then we'll have a true 100% accurate behavior.

4g sounds kinda low. What's the source of the data and what size payload is it decelerating? I've seen figures as high as 7g peak, but that wasn't a failure point, just the peak deceleration. Payload mass unknown. (that would be the main determining factor for failure. Lower mass payload and you can sustain quite a bit of g-force before the ballute fails)

[Enceos]

4g sounds kinda low. What's the source of the data and what size payload is it decelerating? I've seen figures as high as 7g peak, but that wasn't a failure point, just the peak deceleration. Payload mass unknown. (that would be the main determining factor for failure. Lower mass payload and you can sustain quite a bit of g-force before the ballute fails)

Yeah, I probably messed up the formula. Talking about the ballute drag, this is the aerocapture interface of a probe at Mars.

So a good ballute should be able to slow a spacecraft down to aerocapture before a substantial heat kicks in on the first attempt. If at lowest point ballute is cut the probe will skip off into space, if not cut, the probe should decelerate to suborbital trajectory.

I'm tweaking current values to at least get an aerocapture orbit with high Apoapsis. The target velocities are 6.5km/s Eve encounter and 4.7km/s Kerbin return.

There's a good document with ballute simulations for Mars: https://engineering.purdue.edu/~alexeenk/papers/AAS2007_Mars_ballute.pdf - I'm still chewing it.

Meanwhile I found that chuteMaxTemp from the ModuleParachute doesn't do much at all. I lowered it to 50K and still no impact on ballute temps.

Edited September 22, 2015 by Enceos

[Starwaster]

Meanwhile I found that chuteMaxTemp from the ModuleParachute doesn't do much at all. I lowered it to 50K and still no impact on ballute temps.

that's probably because of all the other things you guys are changing in the configuration. If you lower chuteMaxTemp to 50k (which I'm still not understanding why you would) and the ballute doesn't burn up, then that means the ballute's temperature (not the PART temperature, the chute temp) did not go above 50k.

If I had to guess at a singular cause then I'd say that it's because its emissive is 2.4. Basically it's emission coefficient is 2.4 times that of a black body radiator.

[Enceos]

that's probably because of all the other things you guys are changing in the configuration. If you lower chuteMaxTemp to 50k (which I'm still not understanding why you would) and the ballute doesn't burn up, then that means the ballute's temperature (not the PART temperature, the chute temp) did not go above 50k.

If I had to guess at a singular cause then I'd say that it's because its emissive is 2.4. Basically it's emission coefficient is 2.4 times that of a black body radiator.

I'm tweaking the configs posted on the previous page. I deleted the emissive line there.

[ABZB]

Thx for a patch ABZB, let me know whether it works so I guess it might be included in next version.

Found & fixed a missing field in my RealChute node. I have submitted a second pull request to your github with the update.

[riocrokite]

I've merged pull requests.

So I guess ballutes can now be used for Kerbin/Laythe aerobraking too:)

Edited September 23, 2015 by riocrokite