parts [1.10.x] SDHI Service Module System (V4.0.4 / 11 October 2020)

[FireFaced]

The service module is SDHI. If you mean the ATV trunk, it was from Tantares.

Yeah, I know it's from SDHI, but there is no umbilical. How did you get it without the umbilical?

[Bomoo]

Yeah, I know it's from SDHI, but there is no umbilical. How did you get it without the umbilical?

The umbilical was only added in version 2.0. This was the 1.9 service module.

[FireFaced]

Oh. That explains it.

[Akira_R]

Aside from the aero issues the rest of the pack has no problems with 1.0 correct?

I ask only because as long as everything else is fine then using this with nuFAR shouldn't cause any issues whatsoever.

[sumghai]

Hmmmmm. Would it be instead conceivable to take a step back, scrap the current implementation of the pod cover/side fairings, and rebuild an analogous functionality with aerofairings? Not sure if this is doable, but mostly shooting ideas out here.

I thought about that as well, but after examining the stock procedural fairings, I've determines that ultimately, any fairings (stock or mod) will need to use ModuleCargoBay for atmo drag occlusion - including SDHI AeroFairings.

The key question right now is whether it is possible to not use an animation to trigger the change in ModuleCargoBay's drag occlusion on decoupling (rather than an animation). An idea I had was to write a helper plugin PartModule that would listen for a change in the state of ModuleDecoupler/ModuleJettison/ModuleAnchoredDecoupler, trigger a dummy animation module state change, and make ModuleCargoBay listen to said dummy.

Maybe have KSP's aerodynamics mark the boost cover as an adapter, I don't know about the side fairings though.

So, how would one "mark" the boost cover as an adapter?

Why not treat the side fairings like a multi-part engine faring? Even if in the VAB we see it as a single part, there's nothing to say that they cant be animated like the current payload fairings, and just disappear after unloading right?

Not sure if ModuleJettison is automatically handled by stock aero drag occlusion.

Aside from the aero issues the rest of the pack has no problems with 1.0 correct?

I ask only because as long as everything else is fine then using this with nuFAR shouldn't cause any issues whatsoever.

I was hoping to get the aero issues sorted out first, before having you guys run rigorous testing on all aspects of the add-on (including dependencies/supported plugins)

[FireFaced]

I thought about that as well, but after examining the stock procedural fairings, I've determines that ultimately, any fairings (stock or mod) will need to use ModuleCargoBay for atmo drag occlusion - including SDHI AeroFairings.

The key question right now is whether it is possible to not use an animation to trigger the change in ModuleCargoBay's drag occlusion on decoupling (rather than an animation). An idea I had was to write a helper plugin PartModule that would listen for a change in the state of ModuleDecoupler/ModuleJettison/ModuleAnchoredDecoupler, trigger a dummy animation module state change, and make ModuleCargoBay listen to said dummy.

So, how would one "mark" the boost cover as an adapter?

Not sure if ModuleJettison is automatically handled by stock aero drag occlusion.

I was hoping to get the aero issues sorted out first, before having you guys run rigorous testing on all aspects of the add-on (including dependencies/supported plugins)

Look at the properties of an adapter and see if there are any modules that make the aerodynamics treat it differently.

EDIT: I didn't find modules, but I did find a "DRAG_CUBE" section. Perhaps that makes the aero treat it properly

Edited May 6, 2015 by FireFaced

[sumghai]

Look at the properties of an adapter and see if there are any modules that make aero treat it differently.

Could you do me a favour and look up that info for me? I'm away from my dev laptop right now.

[FireFaced]

Could you do me a favour and look up that info for me? I'm away from my dev laptop right now.

Check my edited post.

[sumghai]

Check my edited post.

So the question is, assuming that a DRAG_CUBE is applied to the pod cover, does jettisoning said pod cover effect the proper changes to drag occlusion on the pod?

Idea for you guys:

- Strip out the tentative ModuleCargoBay implementation from the pod cover CFG

- Delete the part database file that autogenerates drag cubes for all part

- Reload the pod cover into the game (which rebuilds the part database with new values)

- Go back to the part database file and find the DRAG_CUBE entry for the pod cover

- Copy and paste that DRAG_CUBE component into the pod cover CFG

- Restart the game

- Test to see if the pod cover now properly occludes drag on the pod/docking port/items attached to the pod, when the pod cover is secured

- Test to see drag is restored on the pod/docking port/items attached to the pod, when the pod cover is jettisoned

EDIT: Just realized that the DRAG_CUBE values need to be edited to ensure that the part is treated as hollow in the bottom (-Y) direction. I'm personally unsure how to do that, however.

EDIT: Ignore that part. NathanKell noted that it wouldn't work.

Edited May 6, 2015 by sumghai

[sharpspoonful]

EDIT: Just realized that the DRAG_CUBE values need to be edited to ensure that the part is treated as hollow in the bottom (-Y) direction. I'm personally unsure how to do that, however.

Out of curiosity, why? The pod cover is either wholly filled with a capsule (and could be considered a solid entity), or decoupled and treated as debris. Is it important to the function of DRAG_CUBE that it have a -y axis?

[sumghai]

Out of curiosity, why? The pod cover is either wholly filled with a capsule (and could be considered a solid entity), or decoupled and treated as debris. Is it important to the function of DRAG_CUBE that it have a -y axis?

Actually, never mind that - NathanKell just told me in IRC that wouldn't work either, because it can only handle directly-stacked parts.

---

Okay, new plan - I've made a request for that ModuleDecoupler-to-ModuleCargoBay listener plugin here.

Intrepid plugin authors - I will be forever in your debt if you guys could devise a working implementation

[Bomoo]

So idea/request: 3.75m mounting hardware? I was imagining a less ghetto version of this:

What do you think? If/when non-stock fairings become viable, I mean.

[sumghai]

So idea/request: 3.75m mounting hardware? I was imagining a less ghetto version of this:

http://images.akamai.steamusercontent.com/ugc/534018874973339749/D07F2602C3E2CA337AA71B3BCBA52BF4156F8D05/

What do you think? If/when non-stock fairings become viable, I mean.

I'll think about it, although the last time I checked, the tapered adapter portion was for the Interim Cryogenic Propulsion Stage, while the Service Module still has the 2.5m-esque straight interstage:

[Bomoo]

I'll think about it, although the last time I checked, the tapered adapter portion was for the Interim Cryogenic Propulsion Stage, while the Service Module still has the 2.5m-esque straight interstage:

Hm, good point.

Edit: Actually looks pretty legit.

Edited May 8, 2015 by Bomoo

[VenomousRequiem]

It seems like the new aero is causing you a lot of stress, so I'm here to wish you good luck, and to hope that you do well!

[sumghai]

It seems like the new aero is causing you a lot of stress, so I'm here to wish you good luck, and to hope that you do well!

Aye, much appreciated

---

Okay folks, new item on the GitHub WIP build test agenda:

KSP 1.0 enforces stricter stack attachment node orientation definitions, and SDHI SMS has already been updated accordingly. One (nice) consequence is that this also resolves the issue of thin parts (w.g. heat shield, Avionics Ring) flickering/wobbling/bouncing when attempting to snap them together in the VAB/SPH, as well as now ensuring that people don't attach the heat shield to the pod with the wrong node.

After consulting with Starwaster, it looks like I can drop support for NodeResizer, and revert the stack node sizes on those parts to 2 in order to increase joint strength via KJE.

Could you guys please test the latest commit with the dependencies plus KJE, and post back with your results? Thanks in advance.

[taniel0401]

Hello, has anybody tried this with the new FAR?

[DianonForce]

I play with it in FAR and DRE, but i must change the Heatshild to work with DRE. It seams that the new DRE serching for a difrent module so it dosn't modify the current heatshild correct to work with DRE correctly.

Because of a now fixed bug in FAR i was thinking that the fairings are broken and made a Adapterring with stock precedual fairings if anyone intrested in, i think they will work under stock atmosphere as well.

[sumghai]

I play with it in FAR and DRE, but i must change the Heatshild to work with DRE. It seams that the new DRE serching for a difrent module so it dosn't modify the current heatshild correct to work with DRE correctly.

Looks like you've been using v2.4.

The development version on GitHub (and the upcoming v2.5) has already been updated to use the new thermal system for stock and DRE 7.x.

Because of a now fixed bug in FAR i was thinking that the fairings are broken and made a Adapterring with stock precedual fairings if anyone intrested in, i think they will work under stock atmosphere as well.

I'm waiting on Starwaster to look into fixing the fairings and pod cover for stock aero, so please be patient.

[FireFaced]

You should look into the source of Procedural Fairings, it has non-stock-type fairings, so it might work for the side fairings.

[sumghai]

You should look into the source of Procedural Fairings, it has non-stock-type fairings, so it might work for the side fairings.

I'm fairly adamant about not using Procedural Fairings.

My respects to e-dog, but the service module fairings are not intended to be tweakable/customisable.

[FireFaced]

I'm fairly adamant about not using Procedural Fairings.

My respects to e-dog, but the service module fairings are not intended to be tweakable/customisable.

I meant look into its shielding mechanism.

[sumghai]

I meant look into its shielding mechanism.

https://github.com/e-dog/ProceduralFairings/blob/master/Source/FairingShielding.cs

It appears to use bespoke PartModules for shape generation, which then internally modifies aero drag occlusion behaviour - given that the code was primarily written for procedural fairings in mind, it's not really applicable to fixed-shape fairings.

I've already spoken with Starwaster, and we're looking at an easier and more robust approach of using the existing stock ModuleCargoBay for aero drag occlusion, in conjunction with a smaller "helper" plugin that tells ModuleCargoBay to update its occlusion state when a fairing panel's decoupler is fired.

[FireFaced]

https://github.com/e-dog/ProceduralFairings/blob/master/Source/FairingShielding.cs

It appears to use bespoke PartModules for shape generation, which then internally modifies aero drag occlusion behaviour - given that the code was primarily written for procedural fairings in mind, it's not really applicable to fixed-shape fairings.

I've already spoken with Starwaster, and we're looking at an easier and more robust approach of using the existing stock ModuleCargoBay for aero drag occlusion, in conjunction with a smaller "helper" plugin that tells ModuleCargoBay to update its occlusion state when a fairing panel's decoupler is fired.

That's unfortunate. Anyways, good luck!

[DianonForce]

I don't know why but i have extrem problems with DRE and the last masterbranch from github.

Installed mods are:

AnimatedDecouplers

DeadlyReentry

FASA Launch Clamps and Towers

Ferram-Aerospace-Research

ModuleManager-2.6.3

SDHI_ServiceModuleSystem

The Heatshield loses Ablator from launch to 20km high (ca 800/1000 left), and on reentry it dosn't loses any ablator, don't even get hot (6.8K). Instead the Dockingport gets hotter and hotter during reentry until it explodes. Any Idea why this happens?

For testing i have used the heatshield come with DRE. they dosn't loses any ablator during liftoff and losing only on reentry, but the dockingport still gets hotter untill it explodes.

Edited May 19, 2015 by DianonForce