[WIP] Sum Dum Heavy Industries Service Module System (Stockalike)

[sorcerymon]

sumghai, would you consider making a decoupler part for this without the service module?

[ZobrAA]

Here is some home welded stuff using ideas of sumghai and Mihara Thanx you both!

Javascript is disabled. View full album

Javascript is disabled. View full album

Edited September 24, 2013 by ZobrAA

[sumghai]

sumghai, would you consider making a decoupler part for this without the service module?

Possibly - in which case, it would be just the avionics rings area with the battery and reaction wheel.

---

Progress Report, 24 September 2013

Boost Protective Cover (Aeroshroud) has been finalized and included in the download in the first post:

Fig 9 - SDHI Mk1-2 Aeroshroud - Final Testing

The shroud is designed as an aerodynamic protective cover for the Mk1-2 Pod during launch - it is sized such that it can accommodate the pod, a standard Clamp-o-tron at the top and any radial parachutes/sensors/infodrives/accessories on the side. There are no windows since real aeroshrouds don't have them*.

I found that a decoupler module alone did not prove sufficient force for ejection in the atmosphere, or ejected it not far from the pod as to cause them to collide when parachutes were deployed. No improvement was gained from simply increasing the decoupling force (in fact, the increase shock force often destroyed docking ports), and so I opted to add a set of solid rocket motors to kick the ejected shroud far away.

As requested, the aeroshroud is by default stageable (i.e. both the decoupler and jettison solid rocket motors will fire concurrently). If the shroud is to be triggered via action groups, both functions should be manually mapped to the action key.

Next Up: Docking Ports with built-in parachutes (Clamp-o-tron and FusTek IACBM); these would be sized to have the equivalent effective thickness to a standard Clamp-o-tron.

*Technically, the Apollo CM Boost Protective Cover did have its own windows, but they were situated over the hatch, so the crew were still reliant on instruments only until after LES/Shroud ejection @ 20~30s after second stage ignition

[Moon Goddess]

Amazing as always!

Thank you for all your hard work....

I have to ask, have you given any thoughts to lander parts...

My Service Module looks so nice now but the MEM docked to it is ugly.

[sumghai]

I have to ask, have you given any thoughts to lander parts...

My Service Module looks so nice now but the MEM docked to it is ugly.

I don't yet have any definite plans for lander parts, but it is a possibility.

At the very least, I want to make a variant of the stock Mk2 Lander can that can hold three rather than two Kerbals (probably only entails an external texture change and modifying the internal to add an extra seat - the IVA suggests there's still some room).

I might also consider a possible collab with Bahamuto Dynamics, if only to get a heat shield installed on the bottom of his trunk unit. Such a combo would work well for landing on Duna and Laythe.

[TimothyC]

I very much enjoy this mod and thank you for making it.

[czokletmuss]

(awesome stuff)

Great, great, great as always! Thanks for all the good work you do sumghai, there are a lot of people who really likes your parts me included. However I can't help myself but to ask - what are you planning to do after the SM is finished?

[sumghai]

However I can't help myself but to ask - what are you planning to do after the SM is finished?

As soon as the Service Module pack is finished and released, I'm going to completely revamp the FusTek Station Parts Expansion - I'll write about this later today in the dev thread for the latter.

[Moon Goddess]

As soon as the Service Module pack is finished and released, I'm going to completely revamp the FusTek Station Parts Expansion - I'll write about this later today in the dev thread for the latter.

No IVA's yet?

[Zaran]

Not had a chance to play with this yet but from what I see in the thread this looks perfect for what I was looking for.

I get so fed up of having my 3man pods service module the size of a small moon to fit everything in.

[Mihara]

For some bizarre reason, Mechjeb won't autostage a stage if aeroshroud is in it.

[Gryphorim]

Is there any chance of moving the fairing for the heatshield to the heatshield model, so we can use any decoupler with it?

[czokletmuss]

As soon as the Service Module pack is finished and released, I'm going to completely revamp the FusTek Station Parts Expansion - I'll write about this later today in the dev thread for the latter.

Now that sounds interesting; I'm waiting for moar news than

[MOARdV]

For some bizarre reason, Mechjeb won't autostage a stage if aeroshroud is in it.

I had that happen this morning, too.

[MOARdV]

I had that happen this morning, too.

FYI: Kerbal Engineer Redux doesn't recognize radial engines attached to the service module. Commenting out the decoupler module in the SM makes KER happy. MechJeb doesn't have this problem, which tells me it's a bug in KER. I'll go report it over on that thread (assuming it's not a dead project - I haven't checked in a while).

[sumghai]

For some bizarre reason, Mechjeb won't autostage a stage if aeroshroud is in it.

I had that happen this morning, too.

That's unusual.

I just tested my MPCV right now with MechJeb autostaging, and the shroud still fires automatically at second stage ignition.

Is there any chance of moving the fairing for the heatshield to the heatshield model, so we can use any decoupler with it?

I'll probably just make an avionics ring-only decoupler that fits the heat shield.

[sumghai]

Progress Report, 25 September 2013

Started thinking about how to implement the first of the two parachute-equipped docking ports.

As the part is supposed to be a variant of the standard Clamp-O-Tron with a handful of cosmetic (plus a couple of functional) modifications added, I will be using MODEL{} node references to simply re-use the existing in-game model. This also allows me to mostly reuse node and other definitions in the CFG.

I spent a good part of last night searching the 'net for as much info I could find regarding the Orion MPCV parachute, and here's what I've uncovered so far:

- The real-life Orion Capsule Parachute Assembly System (CPAS) consists of two drogue and three pilot/main parachutes, where the former slows down the capsule after atmospheric re-entry and ensures that it is oriented the right way up, before the latter are deployed to attain the final touchdown speed; the tiny pilot chutes help pull the mains out properly.

- In its stowed state, the individual components of CPAS are arranged around the docking ring at the apex of the capsule in six sectors (reference 1, reference 2, reference 3)

- During actual deployment, it appears that both the drogues and the mains share the same attachment point - a location offset to one side of the docking ring, opposite to the direction of travel of the falling capsule:

I've also examined BobCat's Orion MPCV in more detail, particularly his rendention of the CPAS/docking port part:

- His CPAS has tiny caps on its tapered surface to release the chutes; I understand he was trying to properly denote which opened caps correspond to which released chutes, but given the size and shape of the actual chutes in their packed states, I feel the caps are too small for the rapidly-expanding parachutes to pass through.

- His model also has each of the three main chutes anchored independently, compared to the real CPAS where all chutes (both drogues and mains) share a common attachment point.

- Finally, as it stands, using his CPAS is quite tricky - either one has to carefully time the cutting of the drogues to when the mains deploy, or the game incorrectly uses the drogue's drag values for the mains and causes the capsule to come down too fast; however, I've managed a workaround by reordering his CFGs to define the drogue first and then the mains, so that when the mains deploy after the drogues, the correct drag values and auto-cut speeds are used for a safe landing.

By gathering all these observations, I've devised an exceptionally crude and not-dinki di aussie conceptual diagram for my own stockalike CPAS based around the Clamp-O-Tron:

Fig 10 - (WIP) SDHI Clamp-O-Tron Parachute Variant - Concept

Unlike the real Orion CPAS, I will be arranging the parachutes over four quarters instead of six sectors, since that's just the way the stock Clamp-O-Tron texture seems to work. The outer protective caps for the parachute compartments would also be split into four quarters, to be jettisoned when their corresponding parachutes are released.

In addition to supporting the cap quarters, the structural ribs will have docking spotlights built into them - the ribs and lights will be modelled with a small indent where the parachute lines would be laid.

ASIDE: In case you were wondering how I managed get stock parts into Blender, I used taniwha's excellent Blender .mu import/export addon.

[Nibb31]

I'm not sure if it's a good idea to have two parachutes in the same part. This is similar to what BobCat did with his MPCV. Ideally, you want to cut the drogue when you deploy the main. One of the problems is that it's hard to set up the part actions in the VAB because both the drogue and main have the same labels "Deploy" and "Cut Chute". Also, I find that it tends to sometimes start deployed on the pad.

[sumghai]

I'm not sure if it's a good idea to have two parachutes in the same part. This is similar to what BobCat did with his MPCV. Ideally, you want to cut the drogue when you deploy the main. One of the problems is that it's hard to set up the part actions in the VAB because both the drogue and main have the same labels "Deploy" and "Cut Chute". Also, I find that it tends to sometimes start deployed on the pad.

As I said in my previous post, I hacked up BobCat's CFG so that the drogue more or less will be automatically cut around the speed at which the mains would deploy. I may have to play around with values, but it's definitely doable without mucking with action groups.

I've never had chutes deploy by themselves on the pad, and even then that is only possible if someone had deliberately put the parachute in the wrong stage.

[ouion]

look the SLS

[sumghai]

Progress Report, 29 September 2013

Added the first of the two Docking Port / Parachute combos, a variant of the standard Clamp-O-Tron:

Fig 11 - SDHI Clamp-O-Tron Parachute Variant - (Mostly) Final

As mentioned previously, this part simply reuses the existing stock KSP Clamp-O-Tron docking port and adds various bits and pieces to it such as the docking lights and the two parachutes. I had a ball of a time modelling and texturing all the bits under the parachute caps, especially the mortar launchers that fire the drogues and pilot chutes (remember, folks, parachutes usually don't deploy by themselves).

The notches in the ribs (or longerons) are where the ropes for the parachutes can be laid in without otherwise being jammed against the ribs and the caps.

I'm not 100% happy with the autocut for the drogue (probably a side effect of having two ModuleParachutes), and the pod doesn't realistically hang at an angle under the parachute riser attachment pivot - but at least the riser isn't coming out of the top of the docking port, and all landings are now easily 100% survivable (I'm looking at you, BobCat).

Baring some further parachute parameter optimization tweaks by members of the community, I think I can call this done - as usual, the download in the first post has been updated.

Next Up: The FusTek IACBM variant with parachutes for use with my station parts, and then an official release

[Mihara]

I was worried for a while as it accelerated well over 50m/s, but yes, the double parachute system does work. Congratulations.

I wonder what happens if I bungle it and drop it on a mountain though, this needs testing...

P.S. All of this reminds me strongly of Space Brothers and the whole drama-about-parachutes arc.

P.P.S. Also, the light stops working after the parachutes deploy. I'm not sure that's fixable, though...

Edited September 29, 2013 by Mihara

[BlazingAngel665]

This pack is pretty freakin sexy. That parachute clamp-o-tron combo is the coolest new part I have seen in KSP in a very long time.

[sumghai]

I wonder what happens if I bungle it and drop it on a mountain though, this needs testing...

At one stage I did try the "useAGL = true" parameter in my CFG - while it worked well to compensate for the actual ground level, it also had the tendency to consider the sea floor as "ground level" as well. In the end I omitted the parameter to ensure safe landing in the vast majority of cases (i.e. the ocean and relatively flat land)

P.S. All of this reminds me strongly of Space Brothers and the whole drama-about-parachutes arc.

I'm quite familiar with the manga too - makes me wonder if there is a Pico Norton equivalent in the Kerbal universe.

P.P.S. Also, the light stops working after the parachutes deploy. I'm not sure that's fixable, though...

Probably because the various animated PartModules are interlinked in some convoluted manner (recall the KOSMOS Balka Solar Wing fiasco a few months back that CBBP ultimately fixed).

[betaking]

The fairing for LES is interesting, could be a bit better in my opinion. IDK, just doesn't fit very well with the LES from KSPX... but its better than nothing. In any case, perhaps, you could make a heatshield that has like one of the automatic-style interstages (such as the stock engines.). Sorry I don't mean to insult or be annoying/begging.