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

[speedwaystar]

yowser. i had actually detached and reattached parts in my previous test. this time i built the stack from scratch, and the LES took the service module with it (through the capsule).

before staging

after first stage (pod shroud and LES)

O_O

[sumghai]

14 hours ago, speedwaystar said:

yowser. i had actually detached and reattached parts in my previous test. this time i built the stack from scratch, and the LES took the service module with it (through the capsule).

before staging

after first stage (pod shroud and LES)

O_O

That is definitely not meant to happen.

Can you provide the in-flight log by pressing the F3 menu?

[Starwaster]

Animated Decouplers update

https://github.com/Starwaster/AnimatedDecouplers/releases/latest

[Kerbas_ad_astra]

I think you're missing the download itself -- the DLL in the "source" download is months old.

[Starwaster]

3 hours ago, Kerbas_ad_astra said:

I think you're missing the download itself -- the DLL in the "source" download is months old.

Fixed the missing download. Fixed the dll in the repository too, though honestly that wasn't supposed to be there to begin with so it might go away in the future.

[sumghai]

Just tested AD 1.3.0, @Starwaster - works fine on my test setup. Thanks again!

[sumghai]

I'm aiming to push v3.1 out this weekend.

The update has been QA tested to my satisfaction, but I will be dropping support for a couple of optional add-ons:

 - HotRockets! hasn't been updated for KSP 1.0.5, and cursory tests of the last known release ends up completely removing the stock engine FXs without replacing them with the custom ones. I've decided it wasn't worth spending any more time investigating this.

 - Klockheed Martian Special Parts was abandoned by its maintainer under less-than-cordial circumstances, and its restrictive licensing terms prevents it from being updated/redistributed. The heat shield's flotation collar will thus be disabled.

In the meantime, I'll be spending the rest of this week updating documentation and screenshots.

[dlrk]

Could the flotation collar be replaced with RoverDude's flotation devices?

[sumghai]

13 minutes ago, dlrk said:

Could the flotation collar be replaced with RoverDude's flotation devices?

AFAIK, his flotation plugin doesn't support automatic deployment on splashdown, and I'm not sure if it modifies buoyancy based on animation state either.

[speedwaystar]

On 2/3/2016 at 3:36 AM, sumghai said:

That is definitely not meant to happen.

Can you provide the in-flight log by pressing the F3 menu?

maybe RealHeat is to blame. i'll try without it

EDIT: yep, it was RealHeat. problem solved.

Edited February 9, 2016 by speedwaystar

[sharpspoonful]

14 hours ago, sumghai said:

I'm aiming to push v3.1 out this weekend.

The update has been QA tested to my satisfaction, but I will be dropping support for a couple of optional add-ons:

 - HotRockets! hasn't been updated for KSP 1.0.5, and cursory tests of the last known release ends up completely removing the stock engine FXs without replacing them with the custom ones. I've decided it wasn't worth spending any more time investigating this.

 - Klockheed Martian Special Parts was abandoned by its maintainer under less-than-cordial circumstances, and its restrictive licensing terms prevents it from being updated/redistributed. The heat shield's flotation collar will thus be disabled.

In the meantime, I'll be spending the rest of this week updating documentation and screenshots.

WOOT!

[StevieC]

Figured out why the center of mass was too far forward on the Command+Service Module. The master branch on GitHub has the service module's mass set at 1.1 with a center-of-mass offset of -0.2 where v3.0.1 had the mass of the service module set to 2.2 with an offset of -1.0

[sumghai]

29 minutes ago, StevieC said:

Figured out why the center of mass was too far forward on the Command+Service Module. The master branch on GitHub has the service module's mass set at 1.1 with a center-of-mass offset of -0.2 where v3.0.1 had the mass of the service module set to 2.2 with an offset of -1.0

Would you like me to revert to the values used in v3.0.1?

EDIT: The change in mass/CoMoffset was done by @Kerbas_ad_astra to bring the Service Module in line with stock parts, as per this pull request. I myself haven't had any issues with the new values, but you may want to speak to @Kerbas_ad_astra about this if they concern you.

[StevieC]

S'okay I decided I could just manually tweak them back myself for the time being.

[Kerbas_ad_astra]

I reduced the mass because, as it was, the service module was heavier than the equivalent mass of fuel tanks, reaction wheels, and fuel cells by about a ton.  I moved the center of mass forward because the old CoMOffset had the center of mass sitting in empty space, behind the physical service module part.  It could maybe be slid about 10-20 cm further down without being too silly, but ultimately, blame Squad for making their command pods so ridiculously heavy. 

You're right that you'll need RCS ports on the command module itself to get pure translation, but that's the case for Orion as well (it has a heavier pod and lighter service module than Apollo).  With the boost protective cover, you won't have to worry about them causing drag or getting cooked.

[sumghai]

39 minutes ago, Kerbas_ad_astra said:

I reduced the mass because, as it was, the service module was heavier than the equivalent mass of fuel tanks, reaction wheels, and fuel cells by about a ton.  I moved the center of mass forward because the old CoMOffset had the center of mass sitting in empty space, behind the physical service module part.  It could maybe be slid about 10-20 cm further down without being too silly, but ultimately, blame Squad for making their command pods so ridiculously heavy. 

You're right that you'll need RCS ports on the command module itself to get pure translation, but that's the case for Orion as well (it has a heavier pod and lighter service module than Apollo).  With the boost protective cover, you won't have to worry about them causing drag or getting cooked.

Further to this, I might be able to weld some RCS thrustTransforms to the Mk1-2 Pod itself via an MM patch - but that's probably a little outside the scope of the SMS pack.

[Starwaster]

No

49 minutes ago, Kerbas_ad_astra said:

You're right that you'll need RCS ports on the command module itself to get pure translation, but that's the case for Orion as well (it has a heavier pod and lighter service module than Apollo).  

Those RCS on the Orion CM are for reentry only. Just like Apollo

[Kerbas_ad_astra]

20 hours ago, Starwaster said:

No

Those RCS on the Orion CM are for reentry only. Just like Apollo

That so?  In that case, @StevieC, what NASA does is set up their controller to do some more complicated balancing: when a set of thrusters fires to push the capsule, other thrusters fire to compensate for the torque (given that the Orion capsule weighs almost as much as the service module itself, there's no way that those RCS thrusters are perfectly balanced around the CoM, especially as fuel is consumed over the course of the mission).  Observe my horrible paint skills:

I don't think KSP's control system can do this.  I seldom build pods with unbalanced RCS thrusters, but the times when I have, my recollection is that I thrust to (for example) the side, which imparts a torque, which the SAS then tries to compensate for, which usually sets up more linear forces, and so on.  Given that the Orion controller only has to deal with one thruster configuration (with some limited variations to account for thruster failures, keep-out zones, etc.), and KSP has to deal with arbitrary arrangements (for which it is impossible to guarantee in general that a set of thruster throttle levels can be generated to produce pure torque or pure rotation in the appropriate axis -- though as I say this, I'm already getting an idea for setting up a big matrix to find a solution if it exists), I don't blame Squad for this one.

[StevieC]

My point is that the way things are in the current (pre-release) build of SDHI SvcModule, the service module's mass is barely more than one QUARTER that of the Mk 1-2 command-pod.

 

[Kerbas_ad_astra]

That's the dry mass.  When full of fuel and attached to an engine, the service module's total mass comes to 6 tons, which is about the same (proportionally) as the Orion service module compared to its capsule.  If the service module were much heavier, it wouldn't be worth using -- we'd be better off building our own out of a discrete decoupler, fuel tank, fuel cell, RCS tanks, and reaction wheel.

[Starwaster]

@sumghai

@Kerbas_ad_astra

@StevieC

My first, gut reaction was that StevieC is right and that slashing the service module's mass was a bad move. But before I said anything I wanted to be able to suggest an alternative so I started looking at numbers and... 1.1 tons isn't too unreasonable. Might even be a tad more than it should be.

I was looking at Apollo numbers and and Orion's service module is actually about the same diameter until it widens at the front to accommodate the larger crew module. And it's about half the length of the Apollo SM which is about twice as heavy. (not including engine mass, the basic cylinder with partitions and shelves was a little under two tons)

That still leaves us in the position of having a final vehicle that's too top heavy. Maybe instead (or in addition to?) we should think about cutting the mass of the Mark 1-2 Pod?

Edited February 11, 2016 by Starwaster

[sumghai]

6 minutes ago, Starwaster said:

My first, gut reaction was that StevieC is right and that slashing the service module's mass was a bad move. But before I said anything I wanted to be able to suggest an alternative so I started looking at numbers and... 1.1 tons isn't too unreasonable. Might even be a tad more than it should be.

I was looking at Apollo numbers and and Orion's service module is actually about the same diameter until it widens at the front to accommodate the larger crew module. And it's about half the length of the Apollo SM which is about twice as heavy. (not including engine mass, the basic cylinder with partitions and shelves was a little under two tons)

That still leaves us in the position of having a final vehicle that's too top heavy. Maybe instead (or in addition to?) we should think about cutting the mass of the Mark 1-2 Pod?

I have mixed feelings about patching the Mk1-2 Pod to have lower mass.

On one hand, if a user has multiple vessels, some using SDHI SMS and others not, then the latter ones may become unbalanced. OTOH, there are a significant number of non-SMS users who already agree the Mk 1-2 Pod is too heavy anyway.

Whatever decision you guys come up with, please get it in to me soon, as v3.1 is due to be released this weekend.

[Starwaster]

44 minutes ago, sumghai said:

I have mixed feelings about patching the Mk1-2 Pod to have lower mass.

On one hand, if a user has multiple vessels, some using SDHI SMS and others not, then the latter ones may become unbalanced. OTOH, there are a significant number of non-SMS users who already agree the Mk 1-2 Pod is too heavy anyway.

Whatever decision you guys come up with, please get it in to me soon, as v3.1 is due to be released this weekend.

For proper balancing, the service module (total assembly SM + engine, etc) needs 50% more mass than the CM assembly (port + CM + shield) . By that criteria, currently, the CM is 1.7 tons overweight with the added mass of port + shield. So it either needs that mass shaved off of CM or the SM needs additional mass added ... I don't think moving its CoM back further would help.... I'll play with it some and maybe wheN Kerbas reads this maybe he'll think of something else....?

[StevieC]

Part of the problem is that there's no really convenient place to put RCS thrusters on the Mk 1-2 pod itself. If there were, then I wouldn't need to bend over backwards to try to put all the RCS thrusters on the 1.875m diameter part of the SDHI service-module. That's why the whole 'center-of-gravity-is-too-far-forward' thing is such an issue for me.

However, @sumghai has said that he designed the SDHI service module to allow players to position RCS thrusters as they see fit. The center-of-mass being so far forward of the service module basically renders that impossible, hence my complaint.

[StevieC]

16 hours ago, Starwaster said:

For proper balancing, the service module (total assembly SM + engine, etc) needs 50% more mass than the CM assembly (port + CM + shield) . By that criteria, currently, the CM is 1.7 tons overweight with the added mass of port + shield. So it either needs that mass shaved off of CM or the SM needs additional mass added ... I don't think moving its CoM back further would help.... I'll play with it some and maybe wheN Kerbas reads this maybe he'll think of something else....?

Here is the result with my test of switching the service module back to weigh 1.1 tons dry, and shaving 1.7 tons off the mass of the command module.

Centr of Mass is still a little bit too far forward (don't worry about the torque shown in KER, that's a result of the instruments and such I attached to the sides of the service  module.

Edited February 11, 2016 by StevieC
Adding in screenshot showing results of my test