RealChute
RealChute copied to clipboard
ChrisViral
EVA Parachutes
@StupidChris has expressed interest in allowing Kerbals on EVA to deploy personal parachutes, to allow skydiving or bailout from stricken vessels.
At present, we'll focus on manual chute deployment, although an automatic bailout systems or even ejector seats could be possible in the future.
Typical use case
- Kerbal goes on EVA
- Right-clicking on the command pod allows the active Kerbal to grab a parachute pack ("Get Personal Parachute"), which appears as an orange backpack
- Kerbal manually lets go of hatch ladder and falls away from vessel
- Parachute manually triggered ("Deploy Personal Parachute")
- Parachute canopy and risers are auto-cut after landing, or manually ("Cut Personal Parachute")
- Kerbal can then manually discard parachute backpack ("Discard Parachute Harness")
Personal Parachute - Specifications
- Pilot-main combo
- 7.24m diameter circular main canopy
- 6 m/s landing speed (2 m/s is more realistic but too slow; Kerbals are probably okay with rough landings)
- One model with one full-deployment animation (no reefing) that plays uninterrupted
- t = 0s: Pilot chute appears, fully inflated
- t = 2s: Pilot chute pulls main canopy and risers out; pilot chute disappears
- t = 4s: Main chute canopy fully inflated
- Main chute risers will converge on a single point from the backpack
- Having the risers converge on two points would look more realistic, but because KSP cannot simulate proper rope physics, parachute transforms always pivot around a single point
- New combined textures with separate areas for pilot and main canopies
- RC_canopy_EVA.png: white pilot + main (default, "civilian")
- RC_canopy_EVA_mil.png: white pilot + "military" green main (military variant)
Parachute Backpack - Specifications
- Fits on Kerbal model
- Consists of a main chute backpack that partially covers the Kerbal jetpack, a spare chute bag in front of the chest
- The existing harness on the Kerbal EVA/IVA suit model will suffice.
Notes
- There shouldn't be a dedicated parachute container part in the VAB/SPH part list; instead, a ModuleManager patch should just add the chute container PartModule directly to crewed pods
- Some crewed pods should not include chute containers (e.g. FusTek)
- A Kerbal can only grab one backpack at a time (but can discard the current one and grab another one until the pod's chute container runs out)
- Transferring parachutes between Kerbals/vessels is probably too complicated
- Each parachute pack should come with two sets of pilot/main parachutes (one primary, one spare)
- If the primary set is cut whilst the Kerbal is falling, the user should be able to manually trigger the spare
- Maybe a simple counter for number of chutes remaining will suffice
- The number of spare chutes cannot be changed (for obvious reasons)
@sumghai's TODO list:
- [x] model_RC_canopy_EVA.mu: combined pilot/main EVA parachute model
- [x] RC_chute_EVA_full_deploy: a single animation consisting of pilot chute appearing, pulling out main chute, then disappearing before main chute canopy inflates
- [x] RC_canopy_EVA.png: white pilot + main (default, "civilian")
- [x] RC_canopy_EVA_mil.png: white pilot + "military" green main (military variant)
- [x] model_RC_backpack_EVA.mu: primary and spare parachute backpack for Kerbal EVA model
- [x] RC_backpack_EVA.png: KSP orange backpack textures
- [ ] ~~RC_hide_jetpack.png: 1x1 px transparent texture used to hide Kerbal EVA jetpack mesh(es)~~ (Not needed, will be generated procedually)
In the future, I could also do different chute canopy shapes / accompanying textures (e.g. T-11 "square" military personal parachute, parafoil parachutes)
Few notes from myself:
- Transferring parachutes is actually kind of planned, Kerbals will be able to move spare canopies from the pod to the parachute case to repack them eventually, or from pod to pod if wanted.
- For now, I would think having a spare chute is not necessary, as the parachute won't be programmed to potentially fail, In the eventuality this is added further down the road we could reconsider this stand.
- You are much more organized than I am :P
@StupidChris:
Few notes from myself:
- Transferring parachutes is actually kind of planned, Kerbals will be able to move spare canopies from the pod to the parachute case to repack them eventually, or from pod to pod if wanted.
Oh okay, I see.
I'm wondering if there is way (in the current version or otherwise) to optionally disable repacking.
- For now, I would think having a spare chute is not necessary, as the parachute won't be programmed to potentially fail, In the eventuality this is added further down the road we could reconsider this stand.
Aye.
I'll keep the chest bag anyway, in preparation for this eventuality.
- You are much more organized than I am :P
Haha, not really :P
I'm wondering if there is way (in the current version or otherwise) to optionally disable repacking.
Yes, by setting the number of spare chutes to zero :P
But don't worry about it, the EVA chutes will be handled by a completely different module.
@StupidChris:
Yes, by setting the number of spare chutes to zero :P
Ah, I think I've done that for SDHI already :)
But don't worry about it, the EVA chutes will be handled by a completely different module.
Sounds good.
Just uploaded preliminary models and textures (b063ca6) - if I've done this correctly, the animation name is RC_chute_EVA_full_deploy. The default texture should be RC_canopy_EVA.png, while the mil one is an alternative texture.
Because I can't test this in KSP on my shitty laptop, could you please test that the animation meets your requirements? Thanks.
Also, in order to make the backpack, I'll need to somehow figure out the dimensions of the Kerbal torso and jetpack, as well as extract the default orange suit textures.
I can't test it yet as the EVA chute module simply doesn't exist curently. I could probably slap it on some generic part and just run the animation to see, but that'll require a dummy module, and I'm not sure I have the time to write that before the end of the week, I'll see about it.
Thanks though, textures look good!
Though I have a question: Given the canopy textures are being repeated, instead of creating one that wraps all the way around the chute, could the texture simply be the pattern once and then have it tile up on the rest of the canopy? That would save memory space. RealChute is not hungry on that, but knowing KSP the more we could save the better.
@StupidChris:
I can't test it yet as the EVA chute module simply doesn't exist curently. I could probably slap it on some generic part and just run the animation to see, but that'll require a dummy module, and I'm not sure I have the time to write that before the end of the week, I'll see about it.
Thanks though, textures look good!
You could probably use the standard RealChute part module for a quick test, although obviously you won't need to specify the predeployment animation (since there's only one full-deployment animation).
Happy to help, as always :)
Though I have a question: Given the canopy textures are being repeated, instead of creating one that wraps all the way around the chute, could the texture simply be the pattern once and then have it tile up on the rest of the canopy? That would save memory space. RealChute is not hungry on that, but knowing KSP the more we could save the better.
Good question - I thought about that back when I made the first batch of RealChute models.
My reasoning for ultimately opting for the full canopy was to allow people to put logos / advertising text on custom chute canopy textures (see issue #13).
Okay, here's another question for you.
I've managed (through various means) get a model of a Kerbal into Blender. Here, I've applied IVA suit textures, for reasons which will become clear shortly:
I've always imagined that a Kerbalnaut abandoning a spacecraft with a parachute would have orange suits, just like the Advanced Crew Escape Suits worn by real Shuttle astronauts:
Notice how the parachute backpacks are also orange.
As such, my intention is to make the parachute packs the same color and texture as the Kerbal orange IVA suits.
The front spare chute bag is easy, but the rear primary chute bag may interfere with the Kerbal's jetback. I've heard it was possible to hide parts of the Kerbal mesh (such as eyes and helmets) through plugins, so I'm wondering if it would be feasible to hide the jetpack when a Kerbal is equipped with a bailout chute backpack.
Thoughts?
You could probably use the standard RealChute part module for a quick test, although obviously you won't need to specify the predeployment animation (since there's only one full-deployment animation).
I'm not sure that would work, if theres no animation of the given name it might cause errors which would break the module.
I've heard it was possible to hide parts of the Kerbal mesh (such as eyes and helmets) through plugins, so I'm wondering if it would be feasible to hide the jetpack when a Kerbal is equipped with a bailout chute backpack.
Sure, by dumping all the transform names of the EVA model to the log I could find which to hide, but that might have secondary effects like preventing the jetpack to correctly work if some of the trust transforms are hidden too. My reccomendation is simply to make it slightly bigger than the EVA jetpack so that the jetpack is completely englobed in the parachute packing, that way it'll be hidden from view. Not giving it a collider would allow the jetpack to work normally too.
Okies, I see.
I'll do what I can to make the primary chute backpack bigger and encapsulating the jetback.
After examining the Kerbal jetpack a bit more, I've found that it was far too big to be covered up with the main parachute backpack (the jetpack is even larger than the Kerbal's own torso).
I think the best I can do is to the backup chute chest bag - we'll just have to accept the chute sprouting out of the jetpack.
How about making it smaller so there is a chute back pack for those with texture replacer whose kerbals spawn in their IVA suit in atmos?
Sent from my ASUS MeMO Pad
Robin Chang [email protected] wrote:
After examining the Kerbal jetpack a bit more, I've found that it was far too big to be covered up with the main parachute backpack (the jetpack is even larger than the Kerbal's own torso).
I think the best I can do is to the backup chute chest bag - we'll just have to accept the chute sprouting out of the jetpack.
— Reply to this email directly or view it on GitHub.
... I'm currently thinking I could just change the texture of the jetpack to a transparent one. I'll have to experiment with that.
@StupidChris:
... I'm currently thinking I could just change the texture of the jetpack to a transparent one. I'll have to experiment with that.
When I get home today, I'll get you a full list of all the meshes* assocated with the jetpack
*The jetpack has separate meshes for the jetpack base, the two fuel tanks, and all the tiny tiny thrusters. My ripped model apparently doesn't account for the jetpack control joysticks, though.
Oh I can do that easily, it would take a few minutes for me to output it to the log. Besides I need to access the transforms anyway.
@StupidChris:
Oh I can do that easily, it would take a few minutes for me to output it to the log. Besides I need to access the transforms anyway.
Ah, I see!
Righto, so I'll make the parachute backpack + spare chute chest bag as originally planned, and I'll modify my final model depending on the results from your experimentation.
Do do suppose it would be a simple task of disabling/enabling the mesh render on said parts?
I think setting the textures to a transparent one would be simpler and easier.
Okies.
A 1x1 px transparent PNG should be very easy to do. Lemme update my TODO list.
You don't even need to do it, I can create one procedurally by code, no need to load it externally :P
So...
I have good news. Turns out turning "off" the jetpack does not change it's behaviour at all. I outputted the whole transform tree to the log and I can target what I need easily. I didn't turn off the armrests, nor the trusters. If I did, the thrust would appear to come out of nowhere. What I suggest is that the parachute backpack should basically replace the jetpack. And we'll pretend that the backpack has jetpack properties :P
@StupidChris:
What I suggest is that the parachute backpack should basically replace the jetpack. And we'll pretend that the backpack has jetpack properties :P
Okies, I'll get on the main backpack this weekend - so far I've got the rough geometry of the reserve chute chest bag in place.
@sumghai All good. Other than that, I was about to test the chute model that you sent me the other day, buuuut I'm going to need the transform name, just like I needed it for the regular parachutes :P
@StupidChris:
I was about to test the chute model that you sent me the other day, buuuut I'm going to need the transform name, just like I needed it for the regular parachutes :P
I suddenly realised I had introduced a complication into the EVA parachute model.
Currently, model_RC_canopy_EVA contains two meshes, main_chute and pilot_chute. Due to the way I've done the animation, pilot_chute is independent of main_chute, which means the chute hanging/pivoting feature in RealChutes may end up being a bit wonky.
If I make pilot_chute a child of main_chute, that should fix the problem.
tl;dr - use main_chute as the transform. I'll upload the fixed model in a moment.
I've also encountered a hiccup with the primary chute backpack model, but more on that later this weekend.
@sumghai I suddenly realised I had introduced a complication into the EVA parachute model.
Currently, model_RC_canopy_EVA contains two meshes, main_chute and pilot_chute. Due to the way I've done the animation, pilot_chute is independent of main_chute, which means the chute /hanging pivoting feature in RealChutes may end up being a bit wonky.
If I make pilot_chute a child of main_chute, that should fix the problem.
tl;dr - use main_chute as the transform. I'll upload the fixed model in a moment.
Figured it out myself haha haha
Used the same tool I used to get the Kerbal tranforms, and found that out, both are separate children of the main mesh. Better make the pilot a child, yes.
I've also encountered a hiccup with the primary chute backpack model, but more on that later this weekend.
Aye, I'll be waiting on you for this.
@sumghai Alright after testing , the animation and textures look awesome the only thing I would like to request is for the pilot perhaps to appear folded too and open up before pulling the main chute out? Just a thought, because right now it seems to just appear suddenly fully deployed, pulling the main out. I don't know how doable this is for you, but I'll trust youre judgement :) Else looks awesome as always!
The reason the pilot appears as fully deployed at the start is because I assumed that it is small enough to inflate very, very quickly (probably even via pyrotechnics). I could give it a faux canopy inflation animation, but given my prior point, I doubt that would be necessary.
Also, I've updated the model (c0fd4fc) to fix the chute transforms. I tried making pilot_chute a child of main_chute, but it did weird things with the scaling I used for the animation. In the end, I put main_chute and pilot_chute under a new eva_chute_trans transform, so that the pivoting feature will work properly.
You can also safely ignore the dummy_ignore transform, since that is a hack to prevent Unity from doing stupid things to Blender models that have only one top-level object.
It's not about the rotation, but mostly about hiding/showing the canopies. I was actually considering having an hasPilot field to potentially give a different wriggling to the pilot chute if one is present, but for that I still needed it to be a child of the main rotating transform. Putting the main chute and the pilot both under a generic transform will do the trick for sure, thanks! And no worries, much thanks :)
p.s. @sumghai, mind pushing new changes to the 2.0 dev branch if you have more models/textures to add? Had to do some git whackyness to get to copy your commit to the branch. Not a big problem, but theres no reason to have the hasssle if you can push to the dev branch. You should probably just fork the dev branch and do your updates there and then send PRs, that might be easier.