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

[Capt. Hunt]

TBH, I like the idea of the umbilical on the bottom better then it obstructing the ladder or the RCS, but maybe you could try rotating it a little bit further then on Orion, into that empty space below the window.

Edited August 2, 2018 by Capt. Hunt

[sumghai]

On 8/2/2018 at 10:48 AM, Drew Kerman said:

gotcha. That detail is definitely nice. I think the fact that it can be toggled on/off though makes the point of where the umbilical hookup goes a bit moot, since anyone who would want to put it over the ladder could just rotate the adapter there and hide the port mesh while anyone who wanted a visible interface could show the port mesh and rotate the adapter over to that

Well, neither umbilical nor CMA are supposed to be axially rotated, so it's an either/or decision.

On 8/2/2018 at 11:23 AM, Drakenex said:

agreed! Just match the pod design.

On 8/2/2018 at 3:22 PM, Capt. Hunt said:

TBH, I like the idea of the umbilical on the bottom better then it obstructing the ladder or the RCS, but maybe you could try rotating it a little bit further then on Orion, into that empty space below the window.

If I rotated it further to under the viewport, that would actually put the umbilical on the port (left) side of the pod, which would end up looking asymmetrical.

Progress Report, 3 August 2018

I finally decided to put the umbilical on the ventral (bottom) side of the pod.

I managed to slim the umbilical swing arm down to make the whole stack more aerodynamic like the real Orion MPCV, although I wasn't able to make it completely flush due to the thin wall of the Crew Module Adapter (and a desire to keep the thickness of the umbilical plausible to accommodate the imaginary plumbing and wiring). I also still need to refine the umbilical interface model on the pod.

 

[Drew Kerman]

5 hours ago, sumghai said:

Well, neither umbilical nor CMA are supposed to be axially rotated, so it's an either/or decision.

ok, not sure what the final texturing will be like it's just from the rough models shown it seemed like it should be possible to do so without really affecting anything. But if that makes the texturing not line up properly that could be an issue

[Capt. Hunt]

11 hours ago, sumghai said:

Well, neither umbilical nor CMA are supposed to be axially rotated, so it's an either/or decision.

If I rotated it further to under the viewport, that would actually put the umbilical on the port (left) side of the pod, which would end up looking asymmetrical.

Progress Report, 3 August 2018

I finally decided to put the umbilical on the ventral (bottom) side of the pod.

I managed to slim the umbilical swing arm down to make the whole stack more aerodynamic like the real Orion MPCV, although I wasn't able to make it completely flush due to the thin wall of the Crew Module Adapter (and a desire to keep the thickness of the umbilical plausible to accommodate the imaginary plumbing and wiring). I also still need to refine the umbilical interface model on the pod.

 

yeah, it looks good there

[sumghai]

Progress Report, 12 August 2018

I refined the model for the toggleable umbilical interface on the Mk1-3 Pod, with actual meshes instead of normal maps for faux data and fluid connectors.

Both the pod and umbilical arm interfaces share the same UV mapping, which ensures both will have consistent textures.

Over the next couple of days, I began splitting the models out into individual parts, starting with the CMA and SM Trunk. As explained previously, the CMA part can be used on its own as a decoupler compatible with the SDHI Heat Shield, or combined with the Trunk model to make the Service Module part.

Toggling the umbilical interface on the Mk1-3 Pod still works the same as in earlier versions:

As always, the decoupler for the CMA and full SM is not stageable, primarily to prevent users accidentally decoupling their crew pod without executing a proper re-entry burn first.

The LF/LOX variant O-10 engine built into the SM can be staged and activated normally. It uses the same FX as the original stock monoprop O-10, but has thrust characteristics equivalent to the LV-909.

The decoupler behaviour is perfectly consistent across both the CMA and full SM, with the pod now ejecting straight out without the dreaded lurching-to-the-side shenanigans reported by users in earlier versions.

Opinions and Feedback Needed!

I'm thinking of revising the featureset for the CMA and SM, with the intention of the CMA being strictly a decoupler due to its unusual shape and low internal volume. I also would like to encourage the use of RCS instead of Reaction Wheels for attitude control.

What do you guys think of the following?:

Crew Module Adapter (CMA)

• (Animated) Decoupler
• Battery
• SAS ?
• Reaction Wheel
• Fuel Cell

Service Module

• (Animated) Decoupler
• Monoprop (100 units)
• Battery (200 EC)
• LF/LOX (360/440 units)
• SAS ?
• Reaction Wheel
• Fuel Cell
• Engine (LF/LOX variant of O-10)

[Capt. Hunt]

the only thing I'd suggest would be to retain the probe core in the CMA, so it still functions as an avionics/guidance package.

[Drew Kerman]

1 hour ago, sumghai said:

I also would like to encourage the use of RCS instead of Reaction Wheels for attitude control.

I'm down with that

[sumghai]

31 minutes ago, Capt. Hunt said:

the only thing I'd suggest would be to retain the probe core in the CMA, so it still functions as an avionics/guidance package.

I don't think the old Avionics Ring, the new CMA or any iteration of the Service Module actually had a probe core or ModuleCommand.

To clarify, are you instead suggesting I keep the SAS feature and not the Reaction Wheels?

1 hour ago, sumghai said:

I also would like to encourage the use of RCS instead of Reaction Wheels for attitude control.

11 minutes ago, Drew Kerman said:

I'm down with that

Noted!

[Starwaster]

On 8/1/2018 at 4:39 AM, sumghai said:

Progress Report, 1 August 2018

While blocking out the rest of the parts, I explored the possibility of making the Service Module Fairings a stack-mounted part much like the stock fairings, to make it more intuitive when a player builds a SDHI SMS stack - basically, during normal staging, the side fairings would get ejected first, followed by the LAS/BPC, before the Service Module finally separates from the SM Adapter - this more closely resembles the real-life Orion MPCV's mission profile.

Another advantage would be that the fairing panels would, like their stock counter parts, float and "ghost" away to allow players to continue surface-attaching parts to the Service Module.

My main concern, however, is that I'm not sure if it is even technically possible to define fixed-sized fairings with stock PartModules. Considering how generous Starwaster was in developing the AnimatedDecouplers plugin, I don't fancy the notion of asking him for yet another bespoke PartModule.

 

The other issue I'm having is the umbilical interface that goes between the Crew Module Adapter and Mk1-3 pod:

• In SDHI SMS V1, the umbilical was located on the dorsal (top) side of the Mk1-2 pod, but this would interfere with the new Mk1-3 pod's airlock and ladder.
• The real-life Orion MPCV's umbilical is actually offset on an angle from the dorsal side of the Orion crew pod, but this would interfere with the new Mk1-3 pod's RCS thrusters
• The only other location I can think of to keep the entire SMS stack visually symmetrical would be the ventral (bottom/belly) side of the Mk1-3 pod; this is the least accurate option

 

So yeah, I'm kinda stuck here. Thoughts and feedback on both these issues would be greatly appreciated!

The umbilical should be placed ventral regardless of whether or not it's Orion accurate. It's not like either the Mk 1-2 or 1-3 pod were particularly accurate to begin with and that's ok.

Not sure I understand the issue with the fairing; are you asking if it's possible for the stock procedural fairing to limit its size? If so, yes; you can keep it from going over a given diameter. I don't think you can restrict it to ONLY that diameter; I think it will always be possible to taper it, but it's better not to restrict the player anyway.

[sumghai]

6 hours ago, Starwaster said:

The umbilical should be placed ventral regardless of whether or not it's Orion accurate. It's not like either the Mk 1-2 or 1-3 pod were particularly accurate to begin with and that's ok.

Ayup, that was the consensus.

6 hours ago, Starwaster said:

Not sure I understand the issue with the fairing; are you asking if it's possible for the stock procedural fairing to limit its size? If so, yes; you can keep it from going over a given diameter. I don't think you can restrict it to ONLY that diameter; I think it will always be possible to taper it, but it's better not to restrict the player anyway.

Apologies, I should have been a bit more clearer - at the time, I was asking if the stock procedural fairings could be made to be of fixed size, diameter, length and shape, so that I can implement the Service Module side fairings in a similar manner to the stock fairings (float-away ghosting and all). Given what I've learn now, it looks like it won't do what I'm looking for.

In the meantime, no progress report just yet, but I'm currently investigating how to revamp the Boost Protect Cover and Launch Abort system - I've been quite impressed with how SSTU uses switch-mode engines to control both the LAS Abort and Jettison motors, although I'm not sure if this would be too complicated for most users.

[davidy12]

Really cannot wait to have this back. 

[sumghai]

Progress Report, 19 August 2018

Based on the feedback I received, I finalized the featureset for the CMA and SM:

Crew Module Adapter (CMA)

• (Animated) Decoupler
• SAS (all features unlocked)

Service Module

• (Animated) Decoupler
• SAS (all features unlocked)
• Fuel Cell
• Battery (200 EC)
• Monoprop (100 units)
• LF/LOX (360/440 units)
• Engine (LF/LOX variant of O-10)

The next two parts I tackled were the Boost Protect Cover and Launch Abort System.

The hatch cover for the BPC has been repositioned to line up with the hatch location on the Mk1-3 Pod, and I've added some extra detailing to the door like the (opaque) viewport and curved sliding rail-style hinges. As usual, a closed BPC hatch intentionally obstructs the pod's EVA hatch, preventing Kerbals from getting squished between the pod and the BPC fairing walls.

As for the Launch Abort System, I took a page out of Shadowmage's SSTULabs mod and implemented a dual-mode solid fuel rocket motor system using the stock MultiModeEngine PartModule :

• The default staging action fires the Jettison Motors to pull the BPC away from the Mk1-3 Pod during normal staging
• Assuming the user sets up their Action Groups correctly, triggering the Abort AG would instead fire the Abort Motors to pull the pod away from the rest of the disintegrating rocket; another AG would then be used to switch the motor back to fire the Jettison Motor and discard the BPC

Both rocket motors and the Attitude Control Motor RCS thrusters have independent solid fuel reserves, so that activating one does not prevent the use of the other(s) later.

And here's a demonstration of the Multi-mode Engine switching for the Jettison and Abort Motors:

Next up - figuring out how to do the SM Adapter and side fairings

[sumghai]

Progress Report, 21 August 2018

The last two parts were the Spacecraft Adapter and the Service Module Fairings.

The Spacecraft Adapter (formerly the Service Module Adapter) now has a solid skirt instead of a truss-like structure, as this more closely resembles its real-life counter part. I added extra faux details like mounting tabs for the side fairings and mechanical latches to release the Service Module from the rest of the lifter rocket:

As for the Service Module Fairings, I ultimately decided to continue to implement them as standard jettisonable parts with built-in decouplers, just like in previous versions of SDHI SMS. The only difference is that I now use NODE{} definitions and custom transforms, so that they precisely line up with each other without gaps and will not unpredictably explode when decoupling.

I really like how the panels very slowly tumble backwards after decoupling, just like in the real-life Orion MPCV:

[StevieC]

personally I prefer reaction wheels for pitch/roll/yaw control to conserve monoprop for use on translational maneuvers but that's just me. I also plan to hold onto the old SDHI parts (which seem to work fine for me in KSP 1.4.5) to use with the Mk1-2 pod until a good IVA is available for the Mk1-3 pod to allow for all-IVA flying a-la ALCOR

[Kerbart]

58 minutes ago, StevieC said:

personally I prefer reaction wheels for pitch/roll/yaw control to conserve monoprop for use on translational maneuvers but that's just me. I also plan to hold onto the old SDHI parts (which seem to work fine for me in KSP 1.4.5) to use with the Mk1-2 pod until a good IVA is available for the Mk1-3 pod to allow for all-IVA flying a-la ALCOR

I also prefer engines that don’t use propellant, or at least have an I_sp of over 10,000. However, that’s not always realistic. I will admit that I happily use monoprop only for translations like you. But it’s not very realistic. KSP’s magic giro’s can do everything, but in reality (for something that fits in Orion, size & weight-wise) the best they can do for something that big is stabilizing it, not rotating it.

There’s merit in having parts that are intended to make things look more real, make them act more real as well.

 

 

[sumghai]

Perhaps I'll re-add Reaction Wheels to the CMA and SM, and let players optionally disable them to suit their playstyles.

[StevieC]

Much appreciated, @sumghai

[sumghai]

Okay folks, I've uploaded my current progress so far to GitHub, so if you don't mind the garish placeholder colors and sparse third-party add-on support, here's the download link:

https://github.com/sumghai/SDHI_ServiceModuleSystem/archive/58f96cf14f349c963613391e158b28c674d20573.zip

(Disclaimer - This is super dooper experimental, not even a prerelease. Use at own risk)

Progress Report, 23 August 2018

Taking a break from modelling and texturing, I spent the last couple of days setting up localization.

There are two dictionary files for the default US English language:

• GameData\SDHI\Agencies\localization_sdhi_en-us.cfg defines the Agency/Manufacturer for SDHI
• GameData\SDHI\Service Module System\Localization\localization_sdhi_sms_en-us.cfg defines the part names, descriptions, search filter tags and UI button labels for SDHI SMS itself

Splitting the localization files up this way allows me to reuse the agency localization file for my other SDHI mod(s) like the Strobe-O-Matic, without worrying about different SDHI mods fighting over who gets to define the manufacturer.

As a native (Traditional) Chinese speaker, I'm looking into also preparing Simplified Chinese dictionary files for the official release of the V4 revamp. Some thoughts:

• Sum Dum Heavy Industries is obviously a facetious pun on "some dumb", but the joke would fall over flat in Chinese. So instead, I'm going to go for a soundalike translation, and add the English abbreviation at the end i.e. 尚当重工业株式會社 (SDHI)
• The company description includes the fictional country of Honko Co-prosperity Union, with Honko similarly being a facetious mispronunciation of Zhongguo (lit. "Middle Kingdom", i.e. China). Obviously, Honko isn't actually China, so the soundalike translation would instead be the 洪国共荣联盟.

Right now, I'm back to tuning my LAS and parachutes, trying to get a good set of values that works for both normal splashdowns and pad aborts. My current problem is that I either allow my LAS to have a stupidly OP performance by pulling the pod way above the normal drogue deployment altitude, or I have the LAS pull the pod to a more realistic Kerbal-scaled pad abort altitude but can only deploy the mains (resulting in mains parachutes clipping through the forward bay cover).

I've made a feature request for RealChutes to support multiple parachute caps, and I'm waiting to hear back from @Starwaster or @stupid_chris

[drtedastro]

thanks for all of your great work.

I look forward to checking this out and getting it into my various setups.

much enjoyment has come from your work.

Cheers, and again, thank you.

[StevieC]

I will sorely miss the truss version of the service-module adaptor. My preferred solar panels actually needed me to roll the service-module adaptor 90 degrees so that the gaps in the truss would line up with, and provide room for, the folded solar panels until I could unfurl them. While I understand the truth of this XKCD comic, it still pains me a little.

P. S.: to @sumghai's credit, it's not as severe as this issue someone raised on github

Edited August 24, 2018 by StevieC
added a touch more wry humour as apology for all the whining I've been doing in this thread.

[mostlydave]

Overall the github pre-prerelease is working pretty well for me. Are you looking for feedback on it yet?

[sumghai]

8 hours ago, mostlydave said:

Overall the github pre-prerelease is working pretty well for me. Are you looking for feedback on it yet?

Feel free to provide feedback for the pre-prerelease in this thread!

Obviously, I can't promise to fix/change everything, but I'll at least take into account everyone's opinions.

[mostlydave]

Only bug I have noticed is that the heat shield seems to sit on the surface of water without sinking, holding itself and the command pod above water.

 

Overall I like the new models and can't wait to see the rest of the textures, keep up the great work! 

[drtedastro]

i just noticed the same.

 

[sumghai]

6 hours ago, mostlydave said:

Only bug I have noticed is that the heat shield seems to sit on the surface of water without sinking, holding itself and the command pod above water.

3 hours ago, drtedastro said:

i just noticed the same.

That's odd.

I tried reproducing your issue on a stripped-down stock game, with both the SDHI and the stock 2.5m heat shield. The water level intersects the geometric center of both heat shields, so the pod isn't being suspended above water in my case.

What terrain/graphics settings are you guys using? Do you have any environmental mods (EVE, Scatterer) installed?