Inline Ballutes Update thread

[linuxgurugamer]

user @riocrokite made a very nice mod based on real technology called Inline Ballutes, a cross between a balloon and a parachute.  Original thread is here: https://forum.kerbalspaceprogram.com/index.php?/topic/121162-130-inline-ballutes-ib-v128-30052017/&

Please go here for the release:

I'm in the process of adopting and updating this, and rather than clutter  up the old thread, I've set up this thread to track any development issues

 

Sample usage: Duna aerocapture and aerobraking, Kerbin reentry for reusable stages etc.

Dependencies:

• If using stock aero = none.
• If using FAR: 
  • Module Manager by Sarbian
  • RealChute by stupid_chris

Suggested mods:

• RealChute by stupid_chris -  Config for RealChute is already included in the mod.
• RealHeat (RO branch) by NathanKell - brings the shock heat in the upper atmosphere to more realistic levels. Recommended especially for people that use Kerbol rescale mods (i.e. kscale2 / 64k).  Note that this isn't yet available for 1.4+

License:

License: CC-4.0-BY-NC-SA

Edited December 15, 2019 by linuxgurugamer

[Critter79606]

Linux, the link to realchutes and realheat aren't up to date.  

Here is the realchute new link 

 

I've not been able to find a new link for realheat though.

Thank for taking yet another mod.  When do you sleep? 

Also, I don't know if it's still an issue, but I quit using this because of a bug I couldn't figure out in 1.3.x.  When trying to change the default value for deployment it snapped to parachute values (min/max slider values).  When you get far enough give me a yell and be glad to help do some testing.

[KSPrynk]

Did some test runs on version 1.2.9.2.  No major anomalies so far.

1.25m BALLUTE BASELINE: Coming into Duna (w Stock Atmo) from Apoaps of 47,122.7km, 17t craft, 2.5m dia craft (with a couple CL4 relay antenna on sides), 1.25m ballute.  Ballute opens at 50km; entry speed 1,272m/s relative to orbit.

Aimed for 29.0km Periaps, shaved Apoaps down to 2,946km (Ike orbit), without temp warnings.

Aimed for 25.0km Periaps, shaved Apoaps down to 1,086km, without temp warnings.

Aimed for 20.0km Periaps, shaved down to sub-orbital, with 60% temp warning on the ballute only.

2.5m BALLUTE:  Coming into Duna (w Stock Atmo) from Apoaps of 47,122.7km, 34.7t craft, 3.75m dia craft, 2.5m ballute.  Ballute opens at 50km; entry speed 1,272m/s relative to orbit.  Aimed for 25.0km Periaps, shaved Apoaps down to 285km, without temp warnings.

Coming into Duna (w Stock Atmo) from Apoaps of 47,122.7km, 70.2t (double previous mass, since ballute should be 2x wider than 1.25m version, 4x area) craft, 3.75m dia craft, 2.5m ballute.  Ballute opens at 50km; entry speed 1,272m/s relative to orbit.  Aimed for 25.0km Periaps, shaved Apoaps down to 2,059km, without temp warnings.

3.75m BALLUTE: Coming into Duna (w Stock Atmo) from Apoaps of 47,122.7km, 158.1t (2.25x previous mass, since ballute should be 1.5x wider, 2.25x area) craft, 5m dia craft, 3.75m ballute.  Ballute opens at 50km; entry speed 1,272m/s relative to orbit.  Aimed for 25.0km Periaps, shaved Apoaps down to 1,268km, without temp warnings.

5m BALLUTE: Coming into Duna (w Stock Atmo) from Apoaps of 47,122.7km, 280t (4x previous 2.5m ballute craft mass, since ballute should be 2x wider, 4x area) craft, 5m dia craft, 5m ballute.  Ballute opens at 50km; entry speed 1,272m/s relative to orbit.  Aimed for 25.0km Periaps, shaved Apoaps down to 1,561km, without temp warnings.

THE LITTLE GUY: Coming into Duna (w Stock Atmo) from Apoaps of 47,122.7km, 8.55t craft (I forgot to follow my squaring rule), 1.875m dia craft, 0.625m ballute.  Ballute opens at 50km; entry speed 1,272m/s relative to orbit.  Aimed for 25.0km Periaps, shaved Apoaps down to 933km, without temp warnings.

SUMMARY: I think the recommended vehicle masses need to reflect mass scaling with the AREA of the ballute, not the diameter.  I was not being as consistent as I could be in my vehicle aspect ratios (length:diameter), but following the area scaling with square of diameter rule seemed to get me closer than simple linear scaling of the mass to diameter.

Duna is probably the easiest test case.  I may try Kerbin and Eve some other night, but parking myself in a chair is taking a toll....

EDIT: BTW, I reverted to dropping from edge of SOI again.  Tried building interplanetary insertions with the MH mission builder, but it wouldn't save all my settings (I think that's a bug) and I don't know if it can preview a capture.

Edited April 13, 2018 by KSPrynk

[linuxgurugamer]

10 hours ago, KSPrynk said:

think the recommended vehicle masses need to reflect mass scaling with the AREA of the ballute, not the diameter. 

Could you write that up in a presentable format for a new OP which I’ll make when I do a full release?

[DerGolgo]

1st of all:
PRAISE BE @linuxgurugamer!!! Thank you, thank you, thank you, thank you!!!!
The Ballute is my most favorite reentry implement!

2nd of all:
Great thanks for doing to this mod what must be done to keep it working!

3rd of all:
I will not presume to say what this mod needs.
But I've only just managed to get 1.4.2 to start up for the first time (it took a full 24 hours to boot up, I swear ...), and the 1.25m ballute was the first thing I tried out. Not for balluting, mind, but for crew transferring.
As I had mentioned it in the last (original?) thread, what would make me clap like a circus seal would be a Ballute with a CLS passable center. Doesn't have to be annular (though that would fit the shape of the deployed Ballute, and might make me jump up and down, also). But could I plonk a Clamp-O-Tron on the end of my Ballute, all on the nose of my spacecraft, so that my crew could crawl through the docked nose, while giving me a Ballute for reentry. I would be very, very, very happy.

[linuxgurugamer]

21 minutes ago, DerGolgo said:

1st of all:
PRAISE BE @linuxgurugamer!!! Thank you, thank you, thank you, thank you!!!!
The Ballute is my most favorite reentry implement!

2nd of all:
Great thanks for doing to this mod what must be done to keep it working!

3rd of all:
I will not presume to say what this mod needs.
But I've only just managed to get 1.4.2 to start up for the first time (it took a full 24 hours to boot up, I swear ...), and the 1.25m ballute was the first thing I tried out. Not for balluting, mind, but for crew transferring.
As I had mentioned it in the last (original?) thread, what would make me clap like a circus seal would be a Ballute with a CLS passable center. Doesn't have to be annular (though that would fit the shape of the deployed Ballute, and might make me jump up and down, also). But could I plonk a Clamp-O-Tron on the end of my Ballute, all on the nose of my spacecraft, so that my crew could crawl through the docked nose, while giving me a Ballute for reentry. I would be very, very, very happy.

Well, I suppose it could be done, but it doesn't make sense.  The material for the Ballutes need space, they have a lot more material (which is denser and needs more volume than) a parachute.

I'm not doing any models, so if you are looking for a new model, I'm afraid you may be disappointed.

[DerGolgo]

No worries, mon.
I thought that, looking at the model of the case after deployment, and at the icons in the VAB, that the annular ballute might fold around a passable center-section.
But, at this point, this is your mod, you're in charge, obviously.

[KSPrynk]

13 hours ago, linuxgurugamer said:

Could you write that up in a presentable format for a new OP which I’ll make when I do a full release?

So here's a problem.  I checked out the config files and, assuming the Fully Deployed Diameters are used for drag calculations, they're not actually following a square with diameter rule.  In fact, the 0.625m module has the same deployed diameter as the 1.25m one.  But they're also not following a linear rule either.  It almost seems like the smaller modules are being gamed to have more drag than square-rule would suggest.  If the parachute-style drag model is being used - and if that model assumes a fully filled circle - this may be an attempt to account for the "doughnut" having a "hole".  This sort of makes sense, but I don't know why the 0.625m module would be the same as the 1.25m.  OTOH, there was some discussion in the old thread about accounting for the area that the vessel blocked, but I don't know if that was implemented (or how); again, it may have been gamed.

I probably should do a few test runs of the 0.625m and 1.25m individually, with the same vessel mass, and minimal vessel cross-section.  If it comes out the same, then the 0.625m may be bugged.

Edited April 14, 2018 by KSPrynk

[KSPrynk]

Testing 1.25m vs 0.625m ballute module drag

Coming into Kerbin Stock Atmo from edge of SOI at 82,717.7km Apoaps, with 10.145t, 1.25m dia craft (basically a stack of two FL-T800s, with a Spark on the bottom), with 1.25m and 0.625m ballutes.

TEST 1A: Aimed for 55km Periaps, popped 1.25m ballute, shaved Apoaps down to 32,649.6km, with temp meters on parts going halfway to the red.

TEST 2A: Aimed for 55km Periaps (3,234m/s at entry, relative to orbit), popped 0.625m ballute, shaved Apoaps down to 36,758.2km, with temp meters on parts going halfway to the red.

TEST 3A: Aimed for 55km Periaps (3,234m/s at entry, relative to orbit), popped 1.25m AND 0.625m ballute, shaved Apoaps down to 29,411.9km, with temp meters on parts going halfway to the red.

For repeatability...

TEST 1B: Aimed for 55km Periaps, popped 1.25m ballute, shaved Apoaps down to 32,511.4km, with temp meters on parts going halfway to the red.

TEST 2B: Aimed for 55km Periaps, popped 0.625m ballute, shaved Apoaps down to 36,762.9km, with temp meters on parts going halfway to the red.

TEST 3B: Aimed for 55km Periaps (3,234m/s at entry, relative to orbit), popped 1.25m AND 0.625m ballute, shaved Apoaps down to 29,320.1km, with temp meters on parts going halfway to the red.

CONCLUSION: The 0.625m module seems to have lower performance than the 1.25m module, as expected.  So it would seem the Fully Deployed Diameter is not the only factor.  The 0.625m may be a little gamed, compared to the bigger one, but without fully understanding the variables, and the logic behind some of the values set, I’m not prepared to second guess the last author.

I think it’s safe to say the mod isn’t broken.  The history discussion notes that the real life concept was aimed at thin-atmo Mars aerocaptures, and I think there was talk of some follow-on tweaking to at least make it useful for a Kerbin return (capture to a highly elliptical orbit, inside Minmus, isn’t bad).  Without a better gameplan to evaluate, and a deep dive into the math, I’d probably leave the original author’s FAQs, with a note about the 0.625m being suggested for up to 10t craft.

[Transformatron]

A day ago Elon Musk said they would be attempting 2nd stage F9 recovery with ballutes.  I have tried using them but they don't appear to make a difference.  Could this work for successful 2nd stage re-entry with 2.7 tones using 1.25 ballute?

[linuxgurugamer]

9 hours ago, Transformatron said:

A day ago Elon Musk said they would be attempting 2nd stage F9 recovery with ballutes.  I have tried using them but they don't appear to make a difference.  Could this work for successful 2nd stage re-entry with 2.7 tones using 1.25 ballute?

No idea.  This is a game. SpaceX is real life.

Ballutes are real, so why not sit back and see what the real rocket scientists do

[KSPrynk]

On 4/16/2018 at 9:51 PM, Transformatron said:

A day ago Elon Musk said they would be attempting 2nd stage F9 recovery with ballutes.  I have tried using them but they don't appear to make a difference.  Could this work for successful 2nd stage re-entry with 2.7 tones using 1.25 ballute?

I wouldn't expect a ballute by itself would take you all the way to landing.  My understanding of the 2nd stage recovery problem is the entry velocities are just too high.  I'm guessing there'd have to be a significant amount of fuel reserved for the traditional SpaceX 1st stage re-entry burn.  A ballute might be enough to slow things down enough to not have to do the re-entry burn.  What I really want to know is, when Musk said "party balloon", did he mean a drag device or an inflatable heat shield?

Musk also alluded to the "bouncy castle" for recovery.  Given that he's trying to recover fairings by steerable parafoils, I wouldn't be surprised if the 2nd stage isn't recovered the same way.  I think "bouncy castle" was the original fairing recovery idea, before they went to giant net.

When I do first stage recoveries via FMRS, I let MechJeb take the wheel and hit the recovery button when I contact water.  What's interesting is how MJ also typically does an entry burn to keep heating manageable, and then coasts until the landing burn.

@linuxgurugamer, were you waiting on further testing before putting this back on the Add-on Releases thread?  I'm trying to pace my KSP habit for the 1.4.3 update....

[linuxgurugamer]

I have to do some updates to the parts, hopefully will have that done tpmorrow

[Pappystein]

Hey All,  First LGG THANKS for reviving this!   I know it SORT of worked before but 1.2 kind of messed with a lot of it's performance and it seemed to never work well after that.

Those of you commenting on Falcon9 Recovery with Ballutes... Remember the most produced ballute to date is an inverted Pyramid with 4 triangular "air intakes" on the straight sides, NOT a floaty-doughnut.     These are used on the Mk82-AIR, Mk83-AIR and Mk84-AIR bomb.  AIR is the part of the designation used to denote the ballute is installed.   F-16.Net and other modern combat flight sim sites have lots of photos of them... Mostly being dropped by F-16 Fighting Falcons and F-111 Aardvarks but also carried by other aircraft.     These were used instead of the much more widely known SNAKEYE retard kit because of weight and size constraints.  A ballute would slow a bomb 90ish% of what a Snakeye kit could at a significant reduction in carried weight and cost for a bomb of 2000lbs in size.   you COULD put Air-brakes on a Falcon 9's upper stage to recover it... It would JUST be too heavy to be efficient.

Edited April 19, 2018 by Pappystein

[Critter79606]

 Hi  @linuxgurugamer, this is what I was talking about with the weirdness of the ballute control window.

It starts out with the min pressure at 1E-06, and the altitude at 100000.  If you move the min pressure, it goes to the correct 0-0.75, but if you move the Altitude, it changes to a max of 5000.

Also, do you think there is any way to get a staging option to cut the ballute?  I'd like to be able to stage cutting it and then deploy the final parachute without a right click.

I just tried an orbit, and the small ballute worked great in flight!

Thanks!

[linuxgurugamer]

1 hour ago, Critter79606 said:

It starts out with the min pressure at 1E-06, and the altitude at 100000.  If you move the min pressure, it goes to the correct 0-0.75, but if you move the Altitude, it changes to a max of 5000.

 

The Ballutes are treated as if they are parachutes, so the same limitations which apply to the parachute apply here.

I've adjusted the min pressure to be 0.01, that seems to eliminate the funny stuff with it.

The altitude is because the max altitude for a parachute is hard-coded to be 5000m (nearly 15 miles high)

And, without coding, I can't have staging cut the lines

[linuxgurugamer]

On 4/12/2018 at 7:18 PM, Critter79606 said:

Linux, the link to realchutes and realheat aren't up to date.  

Here is the realchute new link 

 

I've not been able to find a new link for realheat though.

Thank for taking yet another mod.  When do you sleep? 

Also, I don't know if it's still an issue, but I quit using this because of a bug I couldn't figure out in 1.3.x.  When trying to change the default value for deployment it snapped to parachute values (min/max slider values).  When you get far enough give me a yell and be glad to help do some testing.

I've updated the OP with the correct links

[Snark]

Moving to Add-on Development.

(Rationale:  Plug-in Development Help and Support is for questions and answers about how to write code for KSP mods, e.g. "Hey, I want the game to <do thing>, how do I do that?"  If a thread's about the development of a specific mod, e.g. for the mod author to provide updates, then it belongs in Add-on Development; that's what that forum is for.)

[Hacki]

With FAR and RealChutes installed, all the parts have identical masses and stats. 

 

I think the fault lies in \KermangeddonIndustries\InlineBallutes\Patches\RealChute.cfg 

I get 5 module manager errors on starting the game from that file too:

[LOG 19:55:02.208] [ModuleManager] Applying update KermangeddonIndustries/InlineBallutes/Patches/RealChute/@PART[InlineBallute*] to KermangeddonIndustries/InlineBallutes/Ballute062/PART
[ERR 19:55:02.208] [ModuleManager] Error - Cannot parse variable search when inserting new key caseMass = #$/../mass$

[LOG 19:55:02.208] [ModuleManager] Applying update KermangeddonIndustries/InlineBallutes/Patches/RealChute/@PART[InlineBallute*] to KermangeddonIndustries/InlineBallutes/Ballute125/PART
[ERR 19:55:02.208] [ModuleManager] Error - Cannot parse variable search when inserting new key caseMass = #$/../mass$

[LOG 19:55:02.208] [ModuleManager] Applying update KermangeddonIndustries/InlineBallutes/Patches/RealChute/@PART[InlineBallute*] to KermangeddonIndustries/InlineBallutes/Ballute250/PART
[ERR 19:55:02.208] [ModuleManager] Error - Cannot parse variable search when inserting new key caseMass = #$/../mass$

[LOG 19:55:02.208] [ModuleManager] Applying update KermangeddonIndustries/InlineBallutes/Patches/RealChute/@PART[InlineBallute*] to KermangeddonIndustries/InlineBallutes/Ballute375/PART
[ERR 19:55:02.208] [ModuleManager] Error - Cannot parse variable search when inserting new key caseMass = #$/../mass$

[LOG 19:55:02.208] [ModuleManager] Applying update KermangeddonIndustries/InlineBallutes/Patches/RealChute/@PART[InlineBallute*] to KermangeddonIndustries/InlineBallutes/Ballute500/PART
[ERR 19:55:02.208] [ModuleManager] Error - Cannot parse variable search when inserting new key caseMass = #$/../mass$

 

Furthermore; and this is not a bug in Inline ballutes, but while i'm at it i might as well mention it.. 

The upper size limit for the chutes is the highest number you can enter in the dialog:

 

I edited the cfg to this which seems to work as originally intended: 

MATERIAL
{
	name = ZylonBallute
	description = Much stronger and resistant to heat than Kevlar however prone to sunlight radiation thus is only one time use.
	areaDensity = 0.0002278
	dragCoefficient = 0.20
	areaCost = 0.24
	maxTemp = 1100
	specificHeat = 25600
	emissivity = 600
}

@PART[InlineBallute*]:NEEDS[RealChute]:BEFORE[FerramAerospaceResearch]
{
	MODULE
	{
		name = RealChuteModule
		timer = 0
		mustGoDown = false
		cutSpeed = 1
		spareChutes = 3
		@category = none

		PARACHUTE
		{
			ParachuteType = Drag
			material = ZylonBallute
		
			// 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
			preDeployedDiameter = 29.32
			deployedDiameter = 29.32
			minIsPressure = true
			minPressure = 0.0000001
			deploymentAlt = 120000
			minDeployment = 120000
			cutAlt = -1
			preDeploymentSpeed = 1
			deploymentSpeed = 4
			preDeploymentAnimation = semiDeploy
			deploymentAnimation = fullDeploy
			parachuteName = canopy
			capName = cap
		}
	}

	MODULE
	{
		name = ProceduralChute
	}
	
	!MODULE[ModuleParachute]{}
	!MODULE[ModuleDragModifier]{}
	!MODULE[ModuleDragModifier]{}
}

@PART[InlineBallute062]:NEEDS[RealChute]:BEFORE[FerramAerospaceResearch]
{
	caseMass = #$/../mass$
	@caseMass *= .82 //caseMass of 1 in example is one half mass of 2.5 meter part. assuming this is desired relative mass of casemass.

	@MODULE[RealChuteModule]
	{
		@PARACHUTE
		{

			@preDeployedDiameter = 14.66
			@deployedDiameter = 14.66
		}
	}
}


@PART[InlineBallute125]:NEEDS[RealChute]:BEFORE[FerramAerospaceResearch]
{
	caseMass = #$/../mass$
	@caseMass *= .82 //caseMass of 1 in example is one half mass of 2.5 meter part. assuming this is desired relative mass of casemass.

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

@PART[InlineBallute250]:NEEDS[RealChute]:BEFORE[FerramAerospaceResearch]
{
	caseMass = #$/../mass$
	@caseMass *= .82 //caseMass of 1 in example is one half mass of 2.5 meter part. assuming this is desired relative mass of casemass.

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


@PART[InlineBallute375]:NEEDS[RealChute]:BEFORE[FerramAerospaceResearch]
{
caseMass = #$/../mass$
	@caseMass *= .82 //caseMass of 1 in example is one half mass of 2.5 meter part. assuming this is desired relative mass of casemass.

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



@PART[InlineBallute500]:NEEDS[RealChute]:BEFORE[FerramAerospaceResearch]
{
	caseMass = #$/../mass$
	@caseMass *= .82 //caseMass of 1 in example is one half mass of 2.5 meter part. assuming this is desired relative mass of casemass.

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

 

 

[linuxgurugamer]

1 hour ago, Hacki said:

Furthermore; and this is not a bug in Inline ballutes, but while i'm at it i might as well mention it.. 

 The upper size limit for the chutes is the highest number you can enter in the dialog

Not really understanding, the picture is too small.

Are you saying that the upper size limit should be higher for these?

I'll merge the config changes, thanks

 

[Hacki]

I'm saying there is no upper size limit. I can manually enter 9999999999 as a deployment diameter for all parachutes, resulting in a part weighing 17,000,000,000,000,000 tons 

I think thats more likely a bug in RealChute itself, but that mod seems to be out of a maintainer as well.

Edited May 3, 2018 by Hacki

[linuxgurugamer]

2 hours ago, Hacki said:

I'm saying there is no upper size limit. I can manually enter 9999999999 as a deployment diameter for all parachutes, resulting in a part weighing 17,000,000,000,000,000 tons 

I think thats more likely a bug in RealChute itself, but that mod seems to be out of a maintainer as well.

I suggest that you go to the RealChute thread, where the mod is fully supported by @stupid_chris

He is around, was last on the forums on Saturday.  The mod works fine on 1.4.3, so if you found a bug with it, then  you need to contact him.  Posting on this thread is mostly useless when talking about a different mod.

Anyway, thanks for the fix for the patch 

[Fraktal]

Something that came up today. I had this mod installed for over a year, but never actually used it. Today, I suddenly had my rockets not behaving the way they should and when I looked into the reason, I discovered that CKAN installed FAR earlier today without my knowledge - and when I try uninstalling FAR, CKAN insists on also uninstalling Inline Ballutes and lists FAR as "Requires" rather than "Depends". Not a single mod I have installed is listed as dependent on FAR, only Inline Ballutes.

I apologize if it's only me who's out of the loop, but since when did FAR become a compulsory dependence for this mod rather than optional? It wasn't listed as compulsory yesterday.

[linuxgurugamer]

1 hour ago, Fraktal said:

Something that came up today. I had this mod installed for over a year, but never actually used it. Today, I suddenly had my rockets not behaving the way they should and when I looked into the reason, I discovered that CKAN installed FAR earlier today without my knowledge - and when I try uninstalling FAR, CKAN insists on also uninstalling Inline Ballutes and lists FAR as "Requires" rather than "Depends". Not a single mod I have installed is listed as dependent on FAR, only Inline Ballutes.

I apologize if it's only me who's out of the loop, but since when did FAR become a compulsory dependence for this mod rather than optional? It wasn't listed as compulsory yesterday.

It shouldnt be, Ive opened an issue about it.

[linuxgurugamer]

2 hours ago, Fraktal said:

Something that came up today. I had this mod installed for over a year, but never actually used it. Today, I suddenly had my rockets not behaving the way they should and when I looked into the reason, I discovered that CKAN installed FAR earlier today without my knowledge - and when I try uninstalling FAR, CKAN insists on also uninstalling Inline Ballutes and lists FAR as "Requires" rather than "Depends". Not a single mod I have installed is listed as dependent on FAR, only Inline Ballutes.

I apologize if it's only me who's out of the loop, but since when did FAR become a compulsory dependence for this mod rather than optional? It wasn't listed as compulsory yesterday.

It's been fixed, refresh your CKAN and the problem should be fixed