Jump to content

[1.12.X] RealChute Parachute Systems v1.4.8.3 | 24/01/21

stupid_chris

By stupid_chris
in KSP1 Mod Releases

 Share

Recommended Posts

stupid_chris

stupid_chris

Posted
  • Author
Posted
exactly does the "Part GUI resize updates canopy size" preference do? Is it correct that it changes the canopy size on pressing "next size" and "previous size" in the context menu in early career mode? Does it change it corresponding to the size change of the case or does it just "actualize" the canopy's size to fit the mass of the ship?

It adjusts the canopy diameter to the ship mass, etc. Basically it does an "apply" whenever you resize the size of the case.

How do RealChute's module for the Squad chutes interact with TweakScale? Does TweakScale only change the case size or also the canopy size?

Tweakscale sure doesn't touch the canopies.

Link to comment
Share on other sites
sumghai

sumghai

Posted
Posted
With regards to EVA parachutes, I'm wondering if it would be possible to have ejector seats (as an optional extra).

As always, I can make the models and textures, but I'll probably need some help with thrust transforms and particle effects ;)

That sounds out of my range, but I'll think of it :) I was hoping on you too for the container parts :P Don't know what exactly I want to see, but I'll let you know when I come to this.
I can help with thrust transforms and maybe particle effects (though I haven't done them before so I'd have to learn them)

EVA Parachutes

- My personal preference is that the primary form of EVA parachute storage should be included in crew pods themselves (via MM patch). It makes sense that Kerbals would want easy access to EVA chutes.

- Custom EVA patchute storage containers should be small, surface attached boxes that are optionally attached by users onto vessels like blister packs. Stack containers of 0.625/1.25/2.5m diameter fuselages seem to be overkill.

Ejector Seats

- Starwaster, I look forward to working with you on this as well :)

- My main concern for ejector seats is specifying the direction the (seated) Kerbal will be ejected out of the cockpit. I don't think we should use the airlock collider transform, since that varies wildly between pods and may result in inconsistent ejection behaviour.

(I have two possible ideas, but I fear they won't be pretty:

- the first requires me to make, for each stock and add-on pod, dummy model files containing an "ejection direction" transform; RealChute will apply MM patches that rebuilds each and every pod to include the invisible model containing this transform

- the second method uses two additional parameters in the new ejection PartModule (3D position and direction vector) to manually specify the "ejection direction" transform; I think this is nicer because I won't have to make dummy models for every single pod out there, while pod makers can simply experiment with values to find the right one for their pods)

- In addition to the previous point, I've noted that a potential ejector seat system might need additional logic to determine situations where ejector seat deployment is unsafe e.g. if the cockpit is upside down relative to the ground, obstruction above the cockpit like helicopter rotors

- Ejector seats should only be limited to cockpits that have an actual bubble canopy. Spacecraft crew pods will probably just have a climb-out-and-let-go-bailout-with-chute feature without the seat.

Link to comment
Share on other sites
stupid_chris

stupid_chris

Posted
  • Author
Posted
EVA Parachutes

- My personal preference is that the primary form of EVA parachute storage should be included in crew pods themselves (via MM patch). It makes sense that Kerbals would want easy access to EVA chutes.

- Custom EVA patchute storage containers should be small, surface attached boxes that are optionally attached by users onto vessels like blister packs. Stack containers of 0.625/1.25/2.5m diameter fuselages seem to be overkill.

Ejector Seats

- Starwaster, I look forward to working with you on this as well :)

- My main concern for ejector seats is specifying the direction the (seated) Kerbal will be ejected out of the cockpit. I don't think we should use the airlock collider transform, since that varies wildly between pods and may result in inconsistent ejection behaviour.

(I have two possible ideas, but I fear they won't be pretty:

- the first requires me to make, for each stock and add-on pod, dummy model files containing an "ejection direction" transform; RealChute will apply MM patches that rebuilds each and every pod to include the invisible model containing this transform

- the second method uses two additional parameters in the new ejection PartModule (3D position and direction vector) to manually specify the "ejection direction" transform; I think this is nicer because I won't have to make dummy models for every single pod out there, while pod makers can simply experiment with values to find the right one for their pods)

- In addition to the previous point, I've noted that a potential ejector seat system might need additional logic to determine situations where ejector seat deployment is unsafe e.g. if the cockpit is upside down relative to the ground, obstruction above the cockpit like helicopter rotors

- Ejector seats should only be limited to cockpits that have an actual bubble canopy. Spacecraft crew pods will probably just have a climb-out-and-let-go-bailout-with-chute feature without the seat.

Code wise, the edjector seat does sound a little complex to be honest, and sounds like a lil more complex to past onto mods. I'll think of something, but I think that would perhaps fit better as a standalone mod :P

Link to comment
Share on other sites
rynak

rynak

Posted
Posted

A plugin that begins with the prefix "real" is probably not the best place to raise this opinion but:

I think all the detail with regards to ejector seats isn't worth all the hassle - just teleport the kerbal to an initial offset, and give him an initial velocity and vector - if that's possible.

Link to comment
Share on other sites
sumghai

sumghai

Posted
Posted
A plugin that begins with the prefix "real" is probably not the best place to raise this opinion but:

I think all the detail with regards to ejector seats isn't worth all the hassle - just teleport the kerbal to an initial offset, and give him an initial velocity and vector - if that's possible.

The question I pondered with my proposal was - what would this initial offset / velocity be? It most certainly cannot be the same for every pod, since command pods come in all shapes and sizes, and what might work for the Mk1-2 Pod might not work for the ALCOR lander pod, for instance.

But yes, ejector seats should probably be put on the back burner for now.

Link to comment
Share on other sites
rynak

rynak

Posted
Posted (edited)

For the offset - to be safe without knowing too much about the pod, it would have to be quite significant... perhaps 4m up from the center of the part. Doubt we'll see 8m fuselages anytime soon. One ugly bug i could immediatelly think of is.... what if that spot is already used by another part? That should almost never happen, but is a possibility. Just killing the kerbal in that case of course would work, but for this you'd need to be able to detect this.

What seems more a problem to me is just where "up" is.... think weird designs that do not have the exit at the top. EDIT: Can you detect the hatch, and use it to calculate a vector from the center?

Edited by rynak
Link to comment
Share on other sites
sumghai

sumghai

Posted
Posted
For the offset - to be safe without knowing too much about the pod, it would have to be quite significant... perhaps 4m up from the center of the part. Doubt we'll see 8m fuselages anytime soon. One ugly bug i could immediatelly think of is.... what if that spot is already used by another part? That should almost never happen, but is a possibility. Just killing the kerbal in that case of course would work, but for this you'd need to be able to detect this.

What seems more a problem to me is just where "up" is.... think weird designs that do not have the exit at the top. EDIT: Can you detect the hatch, and use it to calculate a vector from the center?

I pointed out in a previous post that detecting a pod's airlock collider (where the Kerbal spawns when exiting the hatch) and using that to determine the ejection transform is not reliable, because not all airlock colliders are configured sensibly for all pods.

The more I think of this, the more I prefer the idea of two comma-delimited variables to define the position and vector for ejection. The reason I bought this up for RealChutes was because I envisioned ejector seats as a subset of the standard EVA bailout feature, and if it were packaged into its own add-on, it would needlessly duplicate RealChute functionality.


MODULE {
        name = RealChuteBailout
        storedChutes = 3
        ejectorSeatModel = path/to/ejectorseat/model   [B]// optional variable, defaults to false (in which case ejector seat functionality is disabled, and the Kerbal simply falls off the hatch with the bailout EVA chute)[/B]
        ejectionStartPosition = 1.0, 1.0, 0.0         [B] // optional variable, the starting position in meters relative to the pod's own orientation that the Kerbal in the ejector seat will spawn[/B]
        ejectionVector = 0.0, 1.0, 0.0                 [B]// optional variable, the direction the Kerbal in the ejector seat will fly out[/B]
        ejectionForce = 100                            [B]// self-explanatory[/B]
        ejectionObstructionCheck = 20                  [B]// optional variable, the minimum distance in meters from ejectionStartPosition along ejectionVector that must not be obstructed by terrain or other parts before ejection is allowed, defaults to false (in which case the Kerbal will get ejected even if there is an obstruction)[/B]

        (other parameters for determining chute diameter, deployment speeds, the usual, yada yada... stupid_chris knows what these are)
}


Link to comment
Share on other sites
Astraph

Astraph

Posted
Posted

I'm encountering quite a gamebreaking bug; parachutes simply disappear from part list in VAB/SPH and the ones installed on craft cannot be deployed/repacked/staged/tweaked in VAB/SPH. Has anyone seen this problem before?

Link to comment
Share on other sites
stupid_chris

stupid_chris

Posted
  • Author
Posted
I'm encountering quite a gamebreaking bug; parachutes simply disappear from part list in VAB/SPH and the ones installed on craft cannot be deployed/repacked/staged/tweaked in VAB/SPH. Has anyone seen this problem before?

Sounds like someone is playing on Windows64bit

Link to comment
Share on other sites
Nitrous Oxide

Nitrous Oxide

Posted
Posted

Hmm, might be a silly question, but how does the auto-sizing of parachutes work (ie when you set a desired touchdown speed)? Does it go by stage mass or the total of the craft? I'm using KCT which handles stage recovery if there's a parachute, so I tend to recover just about everything I can (less build time after, more money back, etc). The thing is, I don't really want to use chutes that will weigh more than I absolutely need... am I going to have to get the mass of each stage separately and set the chutes manually? I've noticed that the auto setting is always bringing me down slower than I set, so I'd like to know how this works. Thanks. :)

Link to comment
Share on other sites
Starwaster

Starwaster

Posted
Posted
Hmm, might be a silly question, but how does the auto-sizing of parachutes work (ie when you set a desired touchdown speed)? Does it go by stage mass or the total of the craft? I'm using KCT which handles stage recovery if there's a parachute, so I tend to recover just about everything I can (less build time after, more money back, etc). The thing is, I don't really want to use chutes that will weigh more than I absolutely need... am I going to have to get the mass of each stage separately and set the chutes manually? I've noticed that the auto setting is always bringing me down slower than I set, so I'd like to know how this works. Thanks. :)

It's the mass of the entire craft that you have sitting there in the VAB or SPH.

Create your booster separately and put a chute on it then configure the chute. Use dry weight (if you're sure it's going to be dry which it should be)

Save the booster as a subassembly.

Link to comment
Share on other sites
stupid_chris

stupid_chris

Posted
  • Author
Posted
Hmm, might be a silly question, but how does the auto-sizing of parachutes work (ie when you set a desired touchdown speed)? Does it go by stage mass or the total of the craft? I'm using KCT which handles stage recovery if there's a parachute, so I tend to recover just about everything I can (less build time after, more money back, etc). The thing is, I don't really want to use chutes that will weigh more than I absolutely need... am I going to have to get the mass of each stage separately and set the chutes manually? I've noticed that the auto setting is always bringing me down slower than I set, so I'd like to know how this works. Thanks. :)

Starwaster is right, it uses the full mass of the current vessel in the VAB, dry or wet depending on what option you select. Either You create the booster separately and adjust it, either you enter the mass manually. Then again, parachutes don't have that much mass, you shouldn't be saving more than 0.1-0.2t

Link to comment
Share on other sites
Alshain

Alshain

Posted
Posted
The question I pondered with my proposal was - what would this initial offset / velocity be? It most certainly cannot be the same for every pod, since command pods come in all shapes and sizes, and what might work for the Mk1-2 Pod might not work for the ALCOR lander pod, for instance.

But yes, ejector seats should probably be put on the back burner for now.

You might take a look at how Vanguard Technologies did it. It didn't have seats, it just ejected the Kerbal, but the parachutes were not as sophisticated as RC.

Meanwhile, can anyone help me with a config for this addon as a drag chute on the tail part?

Link to comment
Share on other sites
Mecripp

Mecripp

Posted
Posted (edited)
You might take a look at how Vanguard Technologies did it. It didn't have seats, it just ejected the Kerbal, but the parachutes were not as sophisticated as RC.

Meanwhile, can anyone help me with a config for this addon as a drag chute on the tail part?

Did you try something like 

@PART[B9_Shuttle_TailWing]
{

	maximum_drag = 0.32
	@cost = 500
	@mass = 0.08

	!MODULE[ModuleParachute]{}

	MODULE
	{
		name = RealChuteModule
		caseMass = 0.08
		timer = 0
		mustGoDown = false
		cutSpeed = 0.5
		spareChutes = 5

		PARACHUTE
		{
			material = Kevlar
			preDeployedDiameter = 5
			deployedDiameter = 10
			minIsPressure = true
			minPressure = 0.007
			deploymentAlt = 2500
			cutAlt = -1
			preDeploymentSpeed = 1
			deploymentSpeed = 4
			preDeploymentAnimation = semiDeployLarge
			deploymentAnimation = fullyDeployLarge
			parachuteName = canopy
			capName = cap
		}
	}

	MODULE
	{
		name = ProceduralChute
		textureLibrary = StockReplacement
		currentCanopies = Main chute
	}

	EFFECTS
	{
		rcpredeploy
		{
			AUDIO
			{
				channel = Ship
				clip = sound_parachute_open
				volume = 1
			}
		}

		rcdeploy
		{
			AUDIO
			{
				channel = Ship
				clip = sound_parachute_single
				volume = 1
			}
		}

		rccut
		{
			AUDIO
			{
				channel = Ship
				clip = RealChute/Sounds/sound_parachute_cut
				volume = 1
			}
		}

		rcrepack
		{
			AUDIO
			{
				channel = Ship
				clip = RealChute/Sounds/sound_parachute_repack
				volume = 1
			}
		}
	}
}

O Like this one better maybe 

@PART[B9_Shuttle_TailWing]
{

	maximum_drag = 0.32
	@mass = 0.08
	!sound_parachute_open

	!MODULE[ModuleParachute]{}

	MODULE
	{
		name = RealChuteModule
		caseMass = 0.08
		timer = 0
		mustGoDown = false
		cutSpeed = 5
		spareChutes = 5

		PARACHUTE
		{
			material = Silk
			preDeployedDiameter = 1
			deployedDiameter = 7
			minIsPressure = false
			minPressure = 250
			deploymentAlt = 100
			cutAlt = -1
			preDeploymentSpeed = 1
			deploymentSpeed = 3
			preDeploymentAnimation = para_half
			deploymentAnimation = para_full
			parachuteName = canopy
			capName = cap
		}
	}

	EFFECTS
	{
		rcpredeploy
		{
			AUDIO
			{
				channel = Ship
				clip = sound_parachute_open
				volume = 1
			}
		}

		rcdeploy
		{
			AUDIO
			{
				channel = Ship
				clip = sound_parachute_single
				volume = 1
			}
		}

		rccut
		{
			AUDIO
			{
				channel = Ship
				clip = RealChute/Sounds/sound_parachute_cut
				volume = 1
			}
		}

		rcrepack
		{
			AUDIO
			{
				channel = Ship
				clip = RealChute/Sounds/sound_parachute_repack
				volume = 1
			}
		}
	}
}

- - - Updated - - -

And wasn't there patch to get realchutes to work with the American Pack keep getting null errors and the rcs on the docking port are running in vab ?

Edited by Mecripp2
Link to comment
Share on other sites
Drew Kerman

Drew Kerman

Posted
Posted

I would like to request some additional chute information be displayed in the right-click window for kOS users:

Chute status: packed -> armed -> pre-deployed -> deployed -> cut

Chute pre-deploy height

Chute deploy height

The last two can be hard-coded in kOS now, and checks can be made of the right-click menu to see when the Arm button changes to Cut in order to tell when the chute has at least been pre-deployed, but having the above information would make programs much more flexible

Link to comment
Share on other sites
igor_perusco

igor_perusco

Posted
Posted

Hello, i really love your mod.

I have a suggestion (i'm sorry if this has been suggested before and i did not catch it).

The auto-cut feature as it is makes it very hard to land a top heavy craft safely. The chute cuts when touching the ground and if the craft is not upright or on a slope it tips over and slams the ground. I would very much like it if we could delay the auto-cutting by a configurable amount, to ease the craft down to a horizontal position before cutting.

A wider range for the auto cut speed would be a nice feature too, to be able rig a drogue to cut when near the 150m/s range and allow the craft to coast down at terminal velocity on it's own.

Link to comment
Share on other sites
stupid_chris

stupid_chris

Posted
  • Author
Posted
I would like to request some additional chute information be displayed in the right-click window for kOS users:

Chute status: packed -> armed -> pre-deployed -> deployed -> cut

Chute pre-deploy height

Chute deploy height

The last two can be hard-coded in kOS now, and checks can be made of the right-click menu to see when the Arm button changes to Cut in order to tell when the chute has at least been pre-deployed, but having the above information would make programs much more flexible

For the first: sure.

Unfortunately that's not possible, because this is not part dependant, but parachute dependant. There is no upper limit to the amount of parachutes that can be on a part, and I can't procedurally create right click information on a part, and since I can't really create ten of them in *case* they might come in handy and since it would clog extremely fast, I can't. You're gonna have to keep it with the hard coding if that works.

Link to comment
Share on other sites
Drew Kerman

Drew Kerman

Posted
Posted
Unfortunately that's not possible, because this is not part dependant, but parachute dependant. There is no upper limit to the amount of parachutes that can be on a part...

Ah, true I hadn't considered the fact that people can configure their own types of parachute parts with various chutes and stuff.

Which also reminds me about drogue/main chute parts - would it be possible for the chute state to read packed -> armed -> [drogue] -> pre-deployed -> deployed -> cut ?

Link to comment
Share on other sites
Astraph

Astraph

Posted
Posted
Sounds like someone is playing on Windows64bit

Nope, 32bit with ATM and OpenGL. I dropped 64bit as soon as I upgraded my laptop to a full-fledged PC. Module Manager is up to date. I've currently dropped RealChutes due to this bug, but would like to install it back for those fancy double drogue-normal chutes. Any idea what might be the reason?

Link to comment
Share on other sites
stupid_chris

stupid_chris

Posted
  • Author
Posted
Nope, 32bit with ATM and OpenGL. I dropped 64bit as soon as I upgraded my laptop to a full-fledged PC. Module Manager is up to date. I've currently dropped RealChutes due to this bug, but would like to install it back for those fancy double drogue-normal chutes. Any idea what might be the reason?

Either you were on a Win64bit build of the game, either you were using an outdated version of the mod on a newer version of the game/newer version of the mod on an older version of the mod. At least it's the best I can guess without having any other information.

Link to comment
Share on other sites
This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
 Share
Go to topic listing
×
×
  • Create New...