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

[sumghai]

oooo

/me frantically checks for updated download.

Whoops, almost forgot to upload it! Hang a sec...

EDIT: Updated DEV download to add Adapter (finalized) and Service Module (WIP).

Edited September 11, 2013 by sumghai

[Moon Goddess]

Awesome, You're great as always.

[sumghai]

Progress Report, 14 September 2013

Finished texturing the Service Module. And yes, I remembered to update the DEV zip in the first post with the new download

Fig 7 - SDHI Service Module - Final Testing

---

With the major bits done, here's my plans for the remaining parts before I officially release it as R1.0:

- Fairings: Will eject sidewards to expose the small-diameter propulsion segment (as well as any doodads folks may have attached to its surface).

- Docking Ports with built-in parachutes: The ports themselves will be straightforward, but I'm hoping to figure out how to do a 2 drogue->3 pilot/main deployment scheme.

- Aero shroud Basically an inverted decoupler with a very big skirt that covers the Mk1-2 Pod

ASIDE:

I made an interesting discovery while Googling for reference images this week - turns out that according to NASA's official Twitter account for the Orion MPCV, there's not much visual difference between the original NASA 606/607 and the ESA ATV-style service modules (other than slightly different RCS thruster arrangements, different main engine nozzle sizes and circular vs rectangular PV solar panels). As can be seen clearly in my latest progress screenshots, I've taken a liking to the ATV-style panels, which can already be depicted with the stock solar panels.

[czokletmuss]

I love all your mods sumghai but the amount of work you spend to polish the little details and create great development posts (which should be a role model for all the modders) makes your threads probably the most interesting to read in the Add-on Development. Thank you.

[cy-one]

Hey, just found and already liking it

Is there a reason the "snap to center" on the service module isn't centered on the thinner part? That would be great.

[Mihara]

- Docking Ports with built-in parachutes: The ports themselves will be straightforward, but I'm hoping to figure out how to do a 2 drogue->3 pilot/main deployment scheme.

I suspect that might not work with stock parachute module, or rather, will only work if you very specifically tune it's configuration for Kerbin and no other atmosphere, it's kind of finicky.

I had some amusing problems while welding a docking port/parachute/light part, ModuleLight conflicted with ModuleParachute, light would be stuck on. BobCat's Orion has the 2 drogue/3 main deployment scheme, and I have cracked quite a few capsules against the ground -- it didn't slow enough and impacted the ground at 50 m/s even though the main chutes were open. I was convinced it just doesn't work, before I noticed that in his video, he makes sure to cut the drogues before deploying the main chutes, and then lands safely.

That leads me to believe there's a similar module conflict between two instances of ModuleParachute, which causes the parameters only from the drogues to apply even when the main chute is already open. The only workaround I can think of right now is to tune autoCutSpeed on the drogues so that at the point main parachutes would be open, drogues would auto-cut, and that would be dependent on a specific atmosphere.

[MOARdV]

I had some amusing problems while welding a docking port/parachute/light part, ModuleLight conflicted with ModuleParachute, light would be stuck on. BobCat's Orion has the 2 drogue/3 main deployment scheme, and I have cracked quite a few capsules against the ground -- it didn't slow enough and impacted the ground at 50 m/s even though the main chutes were open. I was convinced it just doesn't work, before I noticed that in his video, he makes sure to cut the drogues before deploying the main chutes, and then lands safely.

I ran into the same problem. I ended up removing the drogue module from the config, and using radial drogue 'chutes. Maybe a better approach would be to have a stackable drogue parachute ring that mounts to the command pod, and then a docking port with the standard 'chute that stacks on top of it.

[Moon Goddess]

I've found a small problem.

I like this design because it keeps the solar and RCS behind fairings, so they're not exposed to liftoff.

However, when configured for flight, RCS behind the fairing is not balanced

The RCS has to go on the outer ring to be balanced

I think the service module needs a touch more weight for balance (mass not gameplay) reasons.

[Mihara]

I think the service module needs a touch more weight for balance (mass not gameplay) reasons.

What it needs is a CoMOffset = 0,0,-something option in the config file instead to pull it's own center of mass further down instead, IMHO.

[MOARdV]

What it needs is a CoMOffset = 0,0,-something option in the config file instead to pull it's own center of mass further down instead, IMHO.

I've been using the KerbCom Avionics to deal with imbalanced service module configurations like this. It's been phenomenal at keeping the nose from pitching during RCS translation (which is all I use RCS for most flights).

[sumghai]

- Docking Ports with built-in parachutes: The ports themselves will be straightforward, but I'm hoping to figure out how to do a 2 drogue->3 pilot/main deployment scheme.

I suspect that might not work with stock parachute module, or rather, will only work if you very specifically tune it's configuration for Kerbin and no other atmosphere, it's kind of finicky.

I had some amusing problems while welding a docking port/parachute/light part, ModuleLight conflicted with ModuleParachute, light would be stuck on. BobCat's Orion has the 2 drogue/3 main deployment scheme, and I have cracked quite a few capsules against the ground -- it didn't slow enough and impacted the ground at 50 m/s even though the main chutes were open. I was convinced it just doesn't work, before I noticed that in his video, he makes sure to cut the drogues before deploying the main chutes, and then lands safely.

That leads me to believe there's a similar module conflict between two instances of ModuleParachute, which causes the parameters only from the drogues to apply even when the main chute is already open. The only workaround I can think of right now is to tune autoCutSpeed on the drogues so that at the point main parachutes would be open, drogues would auto-cut, and that would be dependent on a specific atmosphere.

I ran into the same problem. I ended up removing the drogue module from the config, and using radial drogue 'chutes. Maybe a better approach would be to have a stackable drogue parachute ring that mounts to the command pod, and then a docking port with the standard 'chute that stacks on top of it.

Thirded - I experimented with BobCat's Orion and noticed this effect as well.

Ideally, I'd like to keep the visual accuracy of having the drogue/main system while simplifying deployment (i.e. stage once and forget). Since the docking port / parachute combo is intended for use primarily in return-to-Kerbin scenarios, I think the best bet would be to have two ModuleParachutes definitions and auto-cut the drogues on mains deployment.

Landing on other planets with atmospheres (e.g. Duna, Laythe) would probably require stock chutes and Bahamuto Dynamics' Command Pod Propulsion system (if only the latter had a conformal heat shield on the bottom as well...).

I've found a small problem.

I like this design because it keeps the solar and RCS behind fairings, so they're not exposed to liftoff.

However, when configured for flight, RCS behind the fairing is not balanced

-snip-

The RCS has to go on the outer ring to be balanced

I think the service module needs a touch more weight for balance (mass not gameplay) reasons.

What it needs is a CoMOffset = 0,0,-something option in the config file instead to pull it's own center of mass further down instead, IMHO.

I think it would be more sensible to opt for the CoMOffset option (like in my FusTek Karmony series), since the outer avionics rings should technically be very light compared to the rest of the service module. If someone could play around with my configs and figure out a good CoMOffset config, that'd be much appreciated.

Edited September 15, 2013 by sumghai

[Archer]

I personally use your heat shield attached to Bahamuto's Module it works like a charm, but only looks passable. Otherwise the parts look awesome!

[sumghai]

Progress Report, 17 September 2013

KW Rocketry-style interstage fairings for the Service Module added, plus a few texture tweaks here and there. As usual, see first post for download link.

Fig 8 - SDHI Service Module Fairings - Final Testing

The styling of the inner faces was closely inspired by similar surfaces in the petals of the stock Shielded Clamp-O-Tron docking ports, and may or may not one day become the basis for a SDHI/stockalike-theme replacement for KW Rocketry fairings.

[Mihara]

I think it would be more sensible to opt for the CoMOffset option (like in my FusTek Karmony series), since the outer avionics rings should technically be very light compared to the rest of the service module. If someone could play around with my configs and figure out a good CoMOffset config, that'd be much appreciated.

The obvious CoMOffset = 0.0, -0.675, 0.0 does not actually bring the center of mass far enough down because the pod itself is so very massive, and that using my welded docking port/parachute/light combo, which would be lighter than three side-mounted parachutes.

I got a much more sensible result (Center of mass of the complete system close to the center of the SM, empty center of mass drifting forward not too far forward)with CoMOffset = 0, -1, 0. Heavier engines than LV909 (i.e. LV-N) pull it down further, but it's still within the body of the SM itself.

For the record, my parachute/port/light weld:

PART
{

// --- general parameters ---
name = JSI_dockport_parachute
module = Part
author = NovaSilisko / Mihara

// --- asset parameters ---

MODEL {
	model = Squad/Parts/Utility/dockingPort2/model
	texture = Squad/Parts/Utility/dockingPort2/model000
	position	=	0.0, 0.0, 0.0
	rotation	= 	0.0, 0.0, 0.0
	scale		=	1.0, 1.0, 1.0
}	

MODEL {
	model = Squad/Parts/Utility/parachuteLarge/model
	texture = Squad/Parts/Utility/parachuteLarge/model000
	position	=	0.0, 0.0, 0.0
	rotation	= 	180.0, 0.0, 0.0
	scale		=	1.0, 1.0, 1.0
}

MODEL
{
   model = Squad/Parts/Utility/spotLight1/model
   texture = model000, Squad/Parts/Utility/spotLight1/model000
   texture = model001, Squad/Parts/Utility/spotLight1/model001
   position = 0, 0, -0.645
   scale = 0.4, 0.4, 0.4
   rotation = 164, 180, 0
}

scale = 1
rescaleFactor = 1

// --- node definitions ---
// definition format is Position X, Position Y, Position Z, Up X, Up Y, Up Z, size

// docking port nodes are
//node_stack_top = 0.0, 0.2828832, 0.0, 0.0, 1.0, 0.0, 1
//node_stack_bottom = 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 1

// So the resulting nodes are...
node_stack_top = 0.0, 0.2828832, 0.0, 0.0, 1.0, 0.0, 1
node_stack_bottom = 0.0, -0.12, 0.0, 0.0, 1.0, 0.0, 0

// --- FX definitions ---
sound_parachute_open = activate

// --- editor parameters ---
cost = 1000
category = Utility
subcategory = 0
title = Clamp-o-Tron Parachute
manufacturer = Junk Systems Inc.
description = This a Clamp-o-Tron with an integrated parachute is specifically designed for use with Mk1-2 capsule and should be sufficient to slow it's descent. Hopefully. Also includes a small light as a bonus to help with docking in the dark. NOTICE: Docking light needs to be manually added to the correct action group.

// attachment rules: stack, srfAttach, allowStack, allowSrfAttach, allowCollision
attachRules = 1,0,1,0,1

// --- standard part parameters ---
mass = 0.35
dragModelType = default
angularDrag = 3
crashTolerance = 12
maxTemp = 3100


breakingForce = 100
breakingTorque = 50

stageOffset = -1

MODULE
{
	name = ModuleDockingNode
	referenceAttachNode = top
	nodeType = size1
}

MODULE
{
  	name = ModuleParachute
	invertCanopy = true
	autoCutSpeed = 0.5
	capName = cap
	canopyName = canopy
	semiDeployedAnimation = semiDeployLarge
	fullyDeployedAnimation = fullyDeployLarge
	stowedDrag = 0.22
	semiDeployedDrag = 1
	fullyDeployedDrag = 500
	minAirPressureToOpen = 0.01
	deployAltitude = 500
	deploymentSpeed = 1
	semiDeploymentSpeed = 1	
}

MODULE
{
	//name = FSanimateGeneric
	name = ModuleAnimateGeneric
	animationName = LightAnimation
	startEventGUIName = Lights on
	endEventGUIName = Lights off
	toggleActionName = Toggle light
}

}

[Moon Goddess]

Looking so good,

Launch Cover next I guess, I don't think I've seen anyone else make a launch cover. So awesome. I hope you make it a decoupler that can be staged so I can have it and the LES seperate as a stage rather than action group.

[sumghai]

The obvious CoMOffset = 0.0, -0.675, 0.0 does not actually bring the center of mass far enough down because the pod itself is so very massive, and that using my welded docking port/parachute/light combo, which would be lighter than three side-mounted parachutes.

I got a much more sensible result (Center of mass of the complete system close to the center of the SM, empty center of mass drifting forward not too far forward)with CoMOffset = 0, -1, 0. Heavier engines than LV909 (i.e. LV-N) pull it down further, but it's still within the body of the SM itself.

I haven't played with the CoMOffset value in detail, but I've updated my dev download to include CoMOffset = 0, -1, 0 in the Service Module CFG.

For the record, my parachute/port/light weld:

-snip-

Looks interesting - the Clamp-o-tron version probably won't have any lights, while the FusTek IACBM will.

Looking so good,

Launch Cover next I guess, I don't think I've seen anyone else make a launch cover. So awesome. I hope you make it a decoupler that can be staged so I can have it and the LES seperate as a stage rather than action group.

StarShine Industries has made a boost protective cover, but I believe I can aim for a ogive shape, with the top truncated to allow folks to separately-stage their LES rockets as well.

And yes, the boost cover will function like a normal staged decoupler.

[Mihara]

Looks interesting - the Clamp-o-tron version probably won't have any lights, while the FusTek IACBM will.

While I can always weld a light on in the same manner, I can't help but wonder why?

StarShine Industries has made a boost protective cover, but I believe I can aim for a ogive shape, with the top truncated to allow folks to separately-stage their LES rockets as well.

I tried the StarShine cover/tower. Despite repeated attempts, using it with the capsule with a docking port/parachute combo on it and adjusting the node to fit does not work well, it fails to separate and sometimes damages the capsule.

[sumghai]

Looks interesting - the Clamp-o-tron version probably won't have any lights, while the FusTek IACBM will.

While I can always weld a light on in the same manner, I can't help but wonder why?

Well, the stock ports don't have lights, and I would have prefered some form of consistency.

I suppose I could concede, though.

I tried the StarShine cover/tower. Despite repeated attempts, using it with the capsule with a docking port/parachute combo on it and adjusting the node to fit does not work well, it fails to separate and sometimes damages the capsule.

Hmm...perhaps it's the way he did his colliders. I for one definitely have a few tricks up my sleeve, though, so rest assured that you won't experience similar problems with mine.

[Mihara]

Well, the stock ports don't have lights, and I would have prefered some form of consistency.

I suppose I could concede, though.

It's either a light built in, or a stock light mounted onto the capsule, which won't fit under the cover.... well, that, or just don't dock in the dark, I guess.

[Sapphire]

Well, the stock ports don't have lights, and I would have prefered some form of consistency.

I suppose I could concede, though.

You could always take one of the stock light models, resize it to be super tiny, then mount them around the rim of the docking port model.

[Kerbal01]

Do you have plans to make a one for the MK 1 pod?

[sumghai]

It's either a light built in, or a stock light mounted onto the capsule, which won't fit under the cover.... well, that, or just don't dock in the dark, I guess.

You could always take one of the stock light models, resize it to be super tiny, then mount them around the rim of the docking port model.

I think the best bet would be to model my own stockalike light fixtures for the Clamp-o-tron variant.

Do you have plans to make a one for the MK 1 pod?

Probably not.

[NoMrBond]

What about using an emissive texture to give it some docking/aligning lights that don't cast light but can still been seen in the dark?

[sumghai]

What about using an emissive texture to give it some docking/aligning lights that don't cast light but can still been seen in the dark?

Doable, but emissives alone would not provide sufficient illumination for night-time docking.

[Moon Goddess]

Looking sexy!

And the underside of the lip edge is a great place to mount an antenna.