Jump to content

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


sumghai

Recommended Posts

Ok, it looks like that works nicely.

Anyway, so hopefully it was just a notepad corruption that caused my little error before. Just to be sure, if I wanted to allow it to decouple on staging, I just need to change

MODULE
{
name = ModuleAnimatedDecoupler
ejectionForce = 200
explosiveNodeID = top
staged = false
animationName = SDHI_Umbilical
}

so that staged = true, right?

Link to comment
Share on other sites

Ok, it looks like that works nicely.

Anyway, so hopefully it was just a notepad corruption that caused my little error before. Just to be sure, if I wanted to allow it to decouple on staging, I just need to change

MODULE
{
name = ModuleAnimatedDecoupler
ejectionForce = 200
explosiveNodeID = top
staged = false
animationName = SDHI_Umbilical
}

so that staged = true, right?

I believe that's the edit you should make, although I really wouldn't recommend staging the Service Module-Heatshield decoupler, for obvious in-flight safety reasons.

Link to comment
Share on other sites

Ok, I've got another wierd bug, all of a sudden all my SMS SMs spontaneously decouple when loaded. It had been working fine all day, I didn't change anything and then in a middle of a mission...boom!

I just had a sudden bad thought about this... I wonder if there's a problem in AnimatedDecoupler's logic.... my code is only supposed to detect decoupling and not decouple on its own but because I'm extending Squad's code, I'm wondering if a certain part of the base decoupler works differently than I thought and is maybe interpreting something I'm doing as a desire to decouple. ...

Link to comment
Share on other sites

I just had a sudden bad thought about this... I wonder if there's a problem in AnimatedDecoupler's logic.... my code is only supposed to detect decoupling and not decouple on its own but because I'm extending Squad's code, I'm wondering if a certain part of the base decoupler works differently than I thought and is maybe interpreting something I'm doing as a desire to decouple. ...

(I've left an issue report on the AnimatedDecouplers repo, but maybe you're watching this thread more.)

I wonder if part of the issue might be a packaging goof. I've been trying to apply AnimatedDecouplers to Zero-Point Inline Fairings to get them to properly shield their contents, but I get lines like "ModuleAnimatedDecoupler: Animations not found" when I think I shouldn't (if I understand your code's logic correctly, it should be skipping that check if I don't supply an animation name), and other things. Are you sure the release zip contains the most up-to-date DLL?

Link to comment
Share on other sites

yeah, I know you mentioned that in the OP, and I do understand why you did that, but for me the risk of accidental staging is minimal, so I'd rather have it behave like every other ship I have.

Since you're binding SM decouple to Abort anyway, I like to use that when setting up for final re-entry. In either case you're pressing one button (no right-clicking) except it's far less likely to activate through an accident on your part.

Link to comment
Share on other sites

(I've left an issue report on the AnimatedDecouplers repo, but maybe you're watching this thread more.)

I wonder if part of the issue might be a packaging goof. I've been trying to apply AnimatedDecouplers to Zero-Point Inline Fairings to get them to properly shield their contents, but I get lines like "ModuleAnimatedDecoupler: Animations not found" when I think I shouldn't (if I understand your code's logic correctly, it should be skipping that check if I don't supply an animation name), and other things. Are you sure the release zip contains the most up-to-date DLL?

No, it should not be getting to that point in the code if the animationName is blank but it's harmless because all it's trying to do there is find an animation to play.

I think the reason it gets there is because animationName is never equal to a blank string if animationName is not supplied. Instead, animationName would be null.

I'll fix that in the next update, which will be soon. As soon as I'm finished making sure that it's not doing anything that might be interpreted by KSP as 'I should decouple this part'

Link to comment
Share on other sites

Pad Abort Testing

-LES pulls the pod to the side as advertised.

-Pod cover decouple works normally but separation motor does not fire.

-Main chute deploys normally.

-Main chute does get cut when the pod contacts the ground safely.

First Stage Abort Testing

-The LES does NOT pull the pod to the side while SAS is active, and the pod ends up smashing back into the rocket. (This is why I like to add the pod's "deactivate torque" to the Abort action group.)

-Pod cover decouple works normally but separation motor does not fire.

-Drogue chute is deployed.

-Drogue chute cuts and main chute deploys shortly afterwards normally.

-Main chute does get cut when the pod contacts the ground safely.

Low Kerbin Orbit (LKO) Flight Testing

-Solar arrays, RCS blocks, and the docking port are showing 0.00 drag on the launch pad.

-Solar arrays, RCS blocks, and the docking port are showing unoccluded drag in flight.

At this point the rocket kept flipping so I had to add stabilizer fins to proceed further. Even that didn't help much, however, possibly because of the drag of the unoccluded parts under the fairing.

Also I'd like to add the SDHI heat shield is showing as totally black, as I reported earlier. I used only the download links provided in sumghai's PM onto a 100% fresh install of KSP.

http://steamcommunity.com/sharedfiles/filedetails/?id=454553682

http://steamcommunity.com/sharedfiles/filedetails/?id=454553715

http://steamcommunity.com/sharedfiles/filedetails/?id=454553748

http://steamcommunity.com/sharedfiles/filedetails/?id=454553781

http://steamcommunity.com/sharedfiles/filedetails/?id=454553943

http://steamcommunity.com/sharedfiles/filedetails/?id=454553980

Edited by Bomoo
Link to comment
Share on other sites

I'm getting pretty much the same behavior in my tests, except in my pad abort test the LES did not give it enough altitude to deploy the 'chutes fully (fortunately it also didn't give it enough altitude to destroy the CM on impact).

As I mentioned before, the LES doesn't appear to fire rockets on jettison, I am jettisoning it during the coast phase, so I know it should be able to boost free. I'm not seeing any rocket effects or hearing any engine sounds, either, which tells me they're not firing for some reason.

I also noticed that for some reason only one of the SM fairings is being jettisoned, either on staging or if I assign them to an action group, I have to jettison the other manually.

Edited by Capt. Hunt
Link to comment
Share on other sites

TO ALL: (just in case it gets buried below and missed)

Please go get version 1.1.1 of Animated Decouplers. Just updated it.

Pad Abort Testing

Low Kerbin Orbit (LKO) Flight Testing

-Solar arrays, RCS blocks, and the docking port are showing 0.00 drag on the launch pad.

-Solar arrays, RCS blocks, and the docking port are showing unoccluded drag in flight.

At this point the rocket kept flipping so I had to add stabilizer fins to proceed further. Even that didn't help much, however, possibly because of the drag of the unoccluded parts under the fairing.

Also I'd like to add the SDHI heat shield is showing as totally black, as I reported earlier. I used only the download links provided in sumghai's PM onto a 100% fresh install of KSP.

http://steamcommunity.com/sharedfiles/filedetails/?id=454553682

http://steamcommunity.com/sharedfiles/filedetails/?id=454553715

http://steamcommunity.com/sharedfiles/filedetails/?id=454553748

http://steamcommunity.com/sharedfiles/filedetails/?id=454553781

http://steamcommunity.com/sharedfiles/filedetails/?id=454553943

http://steamcommunity.com/sharedfiles/filedetails/?id=454553980

Please grab the latest Animated Decouplers (I just now updated it again) and re-test drag.

* Also, caveat: testing for 0 drag is not reliable. Test for cD and drag vector. Uninitialized they are 0. Pad drag will probably be 0 even unoccluded. In-flight, if they started shielded and then were shielded after they will freeze at their last updated values. (not that that applies to us; just a little FYI)

If you still notice problems, please find your ModuleManager.ConfigCache and submit it here as you would a log file.

I'm getting pretty much the same behavior in my tests, except in my pad abort test the LES did not give it enough altitude to deploy the 'chutes fully (fortunately it also didn't give it enough altitude to destroy the CM on impact).

As I mentioned before, the LES doesn't appear to fire rockets on jettison, I am jettisoning it during the coast phase, so I know it should be able to boost free. I'm not seeing any rocket effects or hearing any engine sounds, either, which tells me they're not firing for some reason.

I also noticed that for some reason only one of the SM fairings is being jettisoned, either on staging or if I assign them to an action group, I have to jettison the other manually.

I think the LES problem is two-fold. IRL, Apollo LES propelled the command module to an altitude of 2.8km. (almost 3km!!!) while I notice an altitude of about 700m which seems to be barely high enough to safely deploy using the stock chutes. I had forgotten to install Real Chute; which I think imparts less drag while disreefing.

The other half of that problem is that Apollo deployed its drogue chutes first which had faster deployment than the mains. (the drogue chute on the SDHI docking ports won't deploy at such low altitudes; that's just the way they're designed - both stock chutes and Real Chute chutes).

So I think the real question there is.... is it an SDHI issue? To be solved in the SDHI parts pack? If not, then it's a player issue and players should add an extra drogue chute designed to open at low altitudes and it will be up to the player to properly deploy it. when aborting. it could maybe be mounted directly to the boost cover)

On the other hand, if it's treated as an SDHI issue then one or both of the following solutions may do the trick.

1) increase LES (stock and KSPX) solid fuel 4x. That should provide the altitude required for successful chute deployment. boost cover rockets probably need to be more powerful if this is done. (to account for the added mass in the tower)

2) Redesign the chutes as necessary to ensure that the drogue chute will still deploy at LES apoapsis and the main chute shortly after. (i.e. design to allow for drogue chute deployment as low as 2km with main chute shortly thereafter)

On the subject of fairings not decoupling: that sounds like you set their action groups before enabling symmetrical placement. Action groups won't update all symmetrical counterparts if the group was created before enabling symmetry mode. Groups have to be created (or recreated) after symmetrical placement

Edited by Starwaster
Link to comment
Share on other sites

Okies, I've updated the V3.0 test procedure document with the following changes:

- AnimatedDecoupler version updated to 1.1.1 Starwaster

- Instead of checking for drag values, look for non-zero Cd and drag vectors instead Starwaster

- SAS activation not needed for First Stage Abort Testing, to allow LES to pull pod aside during abort* Bomoo

*Back in 0.90, I had JSI Sensible Pumps installed, so after abort, the engines on my lifter rockets automatically cut out; In Bomoo's case, his lifter rocket engines continued to run after decouplnig, so it should be expected (although unintended) that the rocket and the decoupled pod collide into each other. Perhaps deactivate torque for the pod should be part of standard assembly instructions in the future.

I think the LES problem is two-fold. IRL, Apollo LES propelled the command module to an altitude of 2.8km. (almost 3km!!!) while I notice an altitude of about 700m which seems to be barely high enough to safely deploy using the stock chutes. I had forgotten to install Real Chute; which I think imparts less drag while disreefing.

The other half of that problem is that Apollo deployed its drogue chutes first which had faster deployment than the mains. (the drogue chute on the SDHI docking ports won't deploy at such low altitudes; that's just the way they're designed - both stock chutes and Real Chute chutes).

So I think the real question there is.... is it an SDHI issue? To be solved in the SDHI parts pack? If not, then it's a player issue and players should add an extra drogue chute designed to open at low altitudes and it will be up to the player to properly deploy it. when aborting. it could maybe be mounted directly to the boost cover)

On the other hand, if it's treated as an SDHI issue then one or both of the following solutions may do the trick.

1) increase LES (stock and KSPX) solid fuel 4x. That should provide the altitude required for successful chute deployment. boost cover rockets probably need to be more powerful if this is done. (to account for the added mass in the tower)

2) Redesign the chutes as necessary to ensure that the drogue chute will still deploy at LES apoapsis and the main chute shortly after. (i.e. design to allow for drogue chute deployment as low as 2km with main chute shortly thereafter)

I think the simplest option would be for SDHI to come with a patch that increases the solid fuel capacity of the stock and KSPX LESes to 4x. Or better yet, SDHI can provide its own LES system (possibly also with solid-fuel powered RCS thrusters).

The parachute setup was optimized for typical LKO or Mun/Minimus return flights, and I agree that the LES altitude is certainly lacking.

Link to comment
Share on other sites

Low Kerbin Orbit (LKO) Flight Testing (cont.)

-Solar arrays, RCS blocks, and docking port all have a 0.00 Cd on launch pad, and a non-zero Cd when fairings jettisoned via hotkey. (What IS Cd, out of curiosity?)

-LES, pod cover, and side fairings jettison as expected during normal staging.

-Solar arrays, RCS blocks, and docking port all have a zero Cd and 0 vector values before fairing jettison, and non zero drag vectors and Cd after fairing jettison above 70km.

A small question about the pod cover's separation motors. Are they meant to pull it slightly away to one side, or is that an accident of gravity/atmospheric drag?

-Pod separates cleanly. (though the decoupling sound effect did not fire for me. Tested on launchpad, sound does not appear to be firing.)

-Umbilical does move out of the way.

-44 ablator was consumed in reentering from a 120x120km orbit to a 15km Pe. (however the pod did not appear to fly straight down the retrograde vector)

-Drogue chutes deploy normally.

-Drogue chutes cut at ~2000m and main chutes deployed immediately afterwards normally.

-Main chutes cut upon contact with the surface. (water in my case)

http://steamcommunity.com/sharedfiles/filedetails/?id=454675764

http://steamcommunity.com/sharedfiles/filedetails/?id=454675810

http://steamcommunity.com/sharedfiles/filedetails/?id=454675312

http://steamcommunity.com/sharedfiles/filedetails/?id=454675357

http://steamcommunity.com/sharedfiles/filedetails/?id=454675400

http://steamcommunity.com/sharedfiles/filedetails/?id=454675421

Edited by Bomoo
Link to comment
Share on other sites

... (What IS Cd, out of curiosity?)

Cd is short for Drag coefficient.

You may have noticed that since KSP 1.0 there is a panel with the debug menu (Mod-F12), Physics/DragProfile. That is actually showing some of what the Cd is based upon, based on aspect angle and mach speed KSP uses with normal parts, and is actually from the Physics.cfg file in root.

Edited by diomedea
Link to comment
Share on other sites

Cd is short for Drag coefficient.

You may have noticed that since KSP 1.0 there is a panel with the debug menu (Mod-F12), Physics/DragProfile. That is actually showing some of what the Cd is based upon, based on aspect angle and mach speed KSP uses with normal parts, and is actually from the Physics.cfg file in root.

Today I learned something. Thanks!

Link to comment
Share on other sites

A small question about the pod cover's separation motors. Are they meant to pull it slightly away to one side, or is that an accident of gravity/atmospheric drag?

Should be an accident of gravity/atmo drag.

Back in V1.0, I did consider making the behaviour intentional by offsetting thrust transforms, but I decided that pulling it up vertically better supports generic use cases - for instance, some crazy builder might have the SDHI CSM stack surrounded by tall asparagus boosters, and a sideways-moving pod on abort might collide with said boosters.

-Pod separates cleanly. (though the decoupling sound effect did not fire for me. Tested on launchpad, sound does not appear to be firing.)

I suspect effect nodes must've changed again for 0.90/1.0.x. I'll need to check.

Oh, and thanks for the explaination dio - you beat me to the punch.

Link to comment
Share on other sites

<snip>

On the subject of fairings not decoupling: that sounds like you set their action groups before enabling symmetrical placement. Action groups won't update all symmetrical counterparts if the group was created before enabling symmetry mode. Groups have to be created (or recreated) after symmetrical placement

Actually, that was my first thought, so I added them as two separate pieces without symmetry and put both in as separate entries in the action group and got the same result.

By the way, as part of my abort procedure I have the action group set to automatically cut all engines when I abort.

Edited by Capt. Hunt
Link to comment
Share on other sites

-44 ablator was consumed in reentering from a 120x120km orbit to a 15km Pe. (however the pod did not appear to fly straight down the retrograde vector)

I don't think that ablator consumption or other reentry matters should be considered, at least not at this time given the current state of thermodynamics in stock KSP.

The situation as it stands now with stock is that you could configure that shield with 0 ablator and probably come through a 120km orbit just fine. If that's inadequate for anyone, it pretty much boils down to either Deadly Reentry or wait for the stock situation to change. (which it will and SDHI behavior vis a vis stock reentry should evaluated at that time)

Link to comment
Share on other sites

ok, for once I have a positive report,

I downloaded the update to animated decouplers and now everything seems to be working fine. I just did one launch, so I haven't replicated the results yet, but everything seems to be nominal.

When triggered by action group the LES and BPC jettisoned completely, with all LES/BPC rockets firing, next when I released the fairings (also by action group) they both separated cleanly.

By the way, all indications are that the occlusion is working, I even got an onscreen warning when mechjeb tried to deploy the solar panels before I separated the fairings (whereas before they would poke through.)

Edit:

I ran a series of test flights, including several aborts, everything still seems to be nominal in both staged mode and action groups, except for not getting enough altitude off a pad abort. I'm sure increasing the LES fuel supply will help that.

Edited by Capt. Hunt
Link to comment
Share on other sites

Yeah, the previous values for charMin / charMax work with DRE but not with stock. (Even though they share the same source)

right now I'm trying increased amounts of solid fuel for the LES. 4x is way too much so trying less.

Edit: Ok, I myself am having inconsistent results when decoupling the aeroshroud where it doesn't stop shielding the payload. Nobody else is having a problem in that area...?

Edit #2: Abort tip: A procedure I devised is to extend the flaps on your fins when aborting. It'll stabilize your lifter stage and exert a little drag on it and help keep it away from your pod. (obviously only works if it's a control surface). Works in stock and should work in FAR too.

Edit #3: Found out why the aeroshroud was (sometimes) not ceasing to shield the pod et al. I was decoupling from the docking port. The shroud only updates the cargo bay when its own decouple function has fired. So, known issue: Always use the shroud's decoupler function. (at least until I fix that; but there's probably not really a reason to do what I was doing)

Edited by Starwaster
Link to comment
Share on other sites

right now I'm trying increased amounts of solid fuel for the LES. 4x is way too much so trying less.

Would a target altitude of 2.2~2.5 km be decent?

Edit: Ok, I myself am having inconsistent results when decoupling the aeroshroud where it doesn't stop shielding the payload. Nobody else is having a problem in that area...?
Edit #3: Found out why the aeroshroud was (sometimes) not ceasing to shield the pod et al. I was decoupling from the docking port. The shroud only updates the cargo bay when its own decouple function has fired. So, known issue: Always use the shroud's decoupler function. (at least until I fix that; but there's probably not really a reason to do what I was doing)

Yeah, I've always used the decoupler from the pod cover itself.

I'll probably need to update the assembly instructions with this reminder as well.

Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...