[1.12.3+] RealChute Parachute Systems v1.4.9.5 | 20/10/24

[Guest]

Wait, so you included unique sound files for all the packs? That's quite a lot of sounds. Of course, if they aren't unique, why not just direct the MM files to use a single, common sound effect?

[stupid_chris]

Wait, so you included unique sound files for all the packs? That's quite a lot of sounds. Of course, if they aren't unique, why not just direct the MM files to use a single, common sound effect?

Did you read what I linked? You currently cannot do this.

The only way to add custom sounds in KSP is this way:

For each part cfg file, you need to create a new folder in the same folder this config is, named exactly like the cfg is, and put a folder inside this folder and name it "Sounds". Then inside of this, you put your sounds, and they must all begin with "sound_", followed by whatever you like. It's not to be fancy, it's really the only known way to do it since .20

That means yes, each part file has it's own sounds, although it's always the same sound. I can't do it any other way. As I mentioned quite a few times in this thread already, hopefully the new FXGroups in .23 will fix this.

[DragonEG]

Just updated to 0.3.1 and immediately found a bug:

Pre-deployed chute on in-atmosphere hyper-speeds flies faster than ship. Or something like this.

Screenshot of the case:

Mods: a lot of, FAR and DR included (without FAR you probably need to drop from surface of the Mun to achieve such speed).

Way to recreate:

1) Build a rocket with just a capsule, solid fuel booster and 0.625m Main Chute

2) Launch vertically

3) Arm parachute at apoapsis (far above the atmosphere)

4) Wait until it deploys (40Km, ~1640 m/s)

5) Wait futher until chute starts to show some atmospherics FX (around 25Km, ~1660 m/s)

6) Watch in horror as your chute suddenly rotates around your ship and goes for the surface upside-down

7) ...

8) When speed decrease to a reasonable value - chute returns to normal position above vessel

[stupid_chris]

Just updated to 0.3.1 and immediately found a bug:

Pre-deployed chute on in-atmosphere hyper-speeds flies faster than ship. Or something like this.

-snip-

Could you please try to repplicate this without FAR? I'd rather make sure it's not a compatibility problem and really a problem with the plugin. I know for sure that in stock, a pod and a booster doesn't get you out of the atmosphere for sure. I haven't experienced such an issue in my testing. Also, did the parachute invert orientations slowly or as a whole block?

EDIT: Okay, I didn't try it and I'm seeing a few NullRefs in my log, investigating.

Edited December 7, 2013 by stupid_chris

[DragonEG]

Could you please try to repplicate this without FAR? I'd rather make sure it's not a compatibility problem and really a problem with the plugin. I know for sure that in stock, a pod and a booster doesn't get you out of the atmosphere for sure. I haven't experienced such an issue in my testing. Also, did the parachute invert orientations slowly or as a whole block?

EDIT: Okay, I didn't try it and I'm seeing a few NullRefs in my log, investigating.

OK, i'll try it without FAR. Obviously i'll just need some MORE boosters to achieve such speed.

Parachute invert orientation slowly. Sorry, i can't record a video.

Fresh KSP instance, only RealChute installed...

...a-a-and here it go again:

Way to repeat:

1-2) Same as before, but use 4 Boosters with decouplers, like this:

3) This is enough to achieve apoapsis around 1.4Mm.

4-5) Deployment speed: ~2700 m/s, so you will immediately get "we're burning!" FX...

6) And chute goes in reverse until around 600m/s it returns to normal.

Edited December 7, 2013 by DragonEG

[scottholio]

There seems to be a problem with the configs for Bargain Rocketry, the rustic parachute is tiny when deploys, small enough to fit in its case. It still works though.

On another note, I think the full size parachutes look really awesome. I really hope you keep them that way .

Cheers

[stupid_chris]

OK, i'll try it without FAR. Obviously i'll just need some MORE boosters to achieve such speed.

Parachute invert orientation slowly. Sorry, i can't record a video.

Fresh KSP instance, only RealChute installed...

...a-a-and here it go again:

Way to repeat:

1-2) Same as before, but use 4 Boosters with decouplers, like this:

3) This is enough to achieve apoapsis around 1.4Mm.

4-5) Deployment speed: ~2700 m/s, so you will immediately get "we're burning!" FX...

6) And chute goes in reverse until around 600m/s it returns to normal.

Yeah I have an idea what it could be. I was previously using "-this.vessel.srf_velocity" as a drag vector to orient the chutes. I changed to the part velocity for this update to minimalize wonkiness with localized drag. I'm guessing that part velocity is taken according to velocity in space, and that this disregard Krakensbane which affects the frame. I added the frame velocity and it seems to work well now, I'm not getting this over here. This is mostly aesthetics, so I'll wait a little before updating.

There seems to be a problem with the configs for Bargain Rocketry, the rustic parachute is tiny when deploys, small enough to fit in its case. It still works though.

On another note, I think the full size parachutes look really awesome. I really hope you keep them that way .

Cheers

I'll take a look, thanks. EDIT: turns out it's the same misterious issue as the FASA chutes. Weird.

Edited December 8, 2013 by stupid_chris

[scorchdestroya]

For some reason, on the SDHI docking ports only the main chute works, the drogue and it's cover don't deploy. Am I the only only one getting this problem?

[DasBananenbrot]

For some reason, on the SDHI docking ports only the main chute works, the drogue and it's cover don't deploy. Am I the only only one getting this problem?

No you are not the only one. As said one or two pages before the new 0.3 update for RealChute broke compatibility with SDHI Mod parachute. We have to wait for sumghai to update his mod...

[sumghai]

For some reason, on the SDHI docking ports only the main chute works, the drogue and it's cover don't deploy. Am I the only only one getting this problem?

No you are not the only one. As said one or two pages before the new 0.3 update for RealChute broke compatibility with SDHI Mod parachute. We have to wait for sumghai to update his mod...

SDHI SMS has just been updated to V1.5.

[DasBananenbrot]

SDHI SMS has just been updated to V1.5.

Well, that is what I call good timing

[therealcrow999]

I finally got to test the SDHI 1.5. The chutes are awesome. The little chutes came out and I was worried what to do to make the regular chutes to come out, I was about to cut them loose and then the main chutes came out on their own. A tear at that moment dropped out of Jeb's large eye and he said thank you!

[Zander]

I have 2 of each chute in my part menu. they appear to be completely identical

[stupid_chris]

I have 2 of each chute in my part menu. they appear to be completely identical

Are you sure you are not seeing the 1.25m and 0.625m chutes?

[Zander]

Are you sure you are not seeing the 1.25m and 0.625m chutes?

Yes i have 2 sets of 1.25 and 2 sets of .625 as well as 2 sets of radial chutes.

[stupid_chris]

Yes i have 2 sets of 1.25 and 2 sets of .625 as well as 2 sets of radial chutes.

Then you probably have dupplicates in your GameData folder, either you copied it twice or you didn't overwrite it when updating. The download does not have two sets of parts. Just go ahead and delete half of them

[Mihara]

I'm aware of that, but for now, that would bloat the download terribly because of an extremely high amount of .wav files for the sounds. The way it currently works, each part cfg file needs it's own folder with the .wav files, as is explained here. Although the MM files won't affect anything, all the sound files will be loaded. Until there's a fix on that side from KSP, I would rather not include all those files in the main download. Downloading a few extra files isn't that hard, it'll have to do for now I fear.

Do they have to be .wav files? Because I'm pretty sure GameDatabase makes no distinction between various sound formats after they are loaded, and compressing them to ogg would make it much less of a problem, as well as reduce memory consumption.

[stupid_chris]

Do they have to be .wav files? Because I'm pretty sure GameDatabase makes no distinction between various sound formats after they are loaded, and compressing them to ogg would make it much less of a problem, as well as reduce memory consumption.

I can compress them to .ogg, but I would rather wait for the new FX groups who are right around the corner with .23 before doing anything.

[ZobrAA]

I have a srtange bug with "Parachutes no create drag from the very area where they originate from. This means a chute on the side will hang realistically without a CoM offset" on my custom welded chute.

So, here my custom welded chute, made on basis of SDHI_ParaDock_1_ClampOTron:

PART
{
name = ZobrA_SumDum_Chute4DockPort
module = Part
author = sumghai / ZobrA


// --- asset parameters ---
MODEL {
	model = SDHI/Service Module System/Parts/SDHI_ParaDock_1_ClampOTron/model
	scale 		=	1.007, 1.0, 1.007
	position	=	0.0, -0.1, 0.0 //0.48
	rotation	= 	0.0, 180.0, 0.0
}

MODEL {
	model = Squad/Parts/Structural/structuralMiniNode/model
	scale 		=	1.0, 1.0, 1.0
	position	=	0.0, -0.1823258, 0.0 //0.48 
	rotation	= 	0.0, 0.0, 0.0
}

rescaleFactor = 1

node_stack_bottom = 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0



cost = 560
category = Utility
subcategory = 0
title = Chute4DockPort
manufacturer = Sum Dum Heavy Industries
description = Wishing to expand assortment of it's products Sum Dum Heavy Industries released parachute of the revolutionary design for exclusive integration with Mk1-2-Z Command Pod.

attachRules = 1,0,1,0,1

mass = 0.150
dragModelType = default
maximum_drag = 0.0
minimum_drag = 0.0
angularDrag = 0.0
crashTolerance = 100
maxTemp = 1700 //3400 its for DR

breakingForce = 200
breakingTorque = 200



MODULE
{
	name = ModuleLight
	lightName = spotlight
	useAnimationDim = true
	lightBrightenSpeed = 2.5
	lightDimSpeed = 2.5
	resourceAmount = 0.16
	animationName = SDHI_ParaDock_1_Lights
	useResources = true
}

	MODULE
	{
		name = RealChuteModule
		material = Nylon
		caseMass = 0.2
		timer = 0
		mustGoDown = true
		cutSpeed = 0.5
		spareChutes = 5
		secondaryChute = true

		// Main chutes
		capName = chute_cover_mains
		parachuteName = canopy_main
		preDeploymentAnimation = SDHI_ParaDock_1_main_semi_deploy
		deploymentAnimation = SDHI_ParaDock_1_main_full_deploy
		preDeployedDiameter = 3
		deployedDiameter = 55
		minIsPressure = false
		minDeployment = 1500
		deploymentAlt = 700
		cutAlt = -1
		preDeploymentSpeed = 2
		deploymentSpeed = 6

		// Drogue chutes
		secCapName = chute_cover_drogue
		secParachuteName = canopy_drogue
		secPreDeploymentAnimation = SDHI_ParaDock_1_drogue_semi_deploy
		secDeploymentAnimation = SDHI_ParaDock_1_drogue_full_deploy
		secPreDeployedDiameter = 5
		secDeployedDiameter = 10
		secMinIsPressure = false
		secMinDeployment = 40000
		secDeploymentAlt = 7000
		secCutAlt = 2000
		secPreDeploymentSpeed = 1
		secDeploymentSpeed = 4
	}

}

I'm using it for my custom Mk1-2 pod, welded with dockport and heatshied. It is pretty much the same as SDHI_ParaDock_1_ClampOTron, but it behaves wrong:

And for comparison stock Mk1-2pod + SDHI_ParaDock_1_ClampOTron:

What can it be?

[stupid_chris]

Okay, at first I was as confused as you, but after creating this config and opening it in game, I know what is not working properly. Well actually it's working exactly as intended.

The plugin will find the position of the parachute. However, the force is applied on the part, not on the whole vessel. And in this case, your part's origin is below where the parachute is attached. This is why it has less effect, because the force is applied more "on top" of the part and has less lateral effect.

Normal case where the part origin is on the same level as the parachute

Your case, were the part origin is below the parachute

Here, in black is the pod, in yellow the parachute case, in red the part's origin, in blue the force applied by the parachute, and in green the relative force applied on the part.

This is all just normal physics being applied here.

[Starwaster]

I'm assuming pressure isn't dynamic pressure?

Any chance we might see that in the future, at least when FAR is installed alongside?

[stupid_chris]

I'm assuming pressure isn't dynamic pressure?

Any chance we might see that in the future, at least when FAR is installed alongside?

To be honest the difference would be minimal. The equation is pretty simple, q = rho * v². I can see to implement it in further updates, however I would have to see how the game reacts to it.

[ZobrAA]

Okay, at first I was as confused as you, but after creating this config and opening it in game, I know what is not working properly. Well actually it's working exactly as intended.

The plugin will find the position of the parachute. However, the force is applied on the part, not on the whole vessel. And in this case, your part's origin is below where the parachute is attached. This is why it has less effect, because the force is applied more "on top" of the part and has less lateral effect.

Normal case where the part origin is on the same level as the parachute

Your case, were the part origin is below the parachute

Here, in black is the pod, in yellow the parachute case, in red the part's origin, in blue the force applied by the parachute, and in green the relative force applied on the part.

This is all just normal physics being applied here.

Thx for explanation, Chris! Now I think I've got it.

But in my case this is bad anyway... Because I NEED that chute position for perfect seamless look. I was trying to compensate that effect by shifting CoM upwards, but it seems your plugin deals with real pivot of the model, not the CoM.

Even shifting CoM of a capsule didn't change anything T_T

Edited December 9, 2013 by ZobrAA

[stupid_chris]

What the plugin does is that instead of applying the force generated by the parachute on the origin of the part, it applies it exactly at the origin of the parachute, but on the part. Shifting the CoM of the pod won't do much, because the force is still applied relatively to the part's origin. What you might want to do is shift the CoM of the part upwards to counteract the low origin.

I'll try and see if I can instead apply the force on the whole vessel, but I can't guarantee it will work.

Edited December 9, 2013 by stupid_chris

[ZobrAA]

What the plugin does is that instead of applying the force generated by the parachute on the origin of the part, it applies it exactly at the origin of the parachute, but on the part.

Oh! Now I finally get _exactly_ what you've been talking, sorry for slowpoking -_-"

I'll try and see if I can instead apply the force on the whole vessel, but I can't guarantee it will work.

I'll be very-very-very-very appreciated! Theoretically this is possible, as game always know where is CoM of the vessel you can cast a line from vessel CoM to chutes origin point and apply drag force in that direction ...I hope I do not disgrace myself because of this hypothesis, cause I'm not a programmer at all

Also, what if I weld chute directly into the pod? Theoretically will it apply force correctly since they become one part?

Edited December 9, 2013 by ZobrAA