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

[sumghai]

6 minutes ago, StevieC said:

From first-hand experience, the target is in the correct position if you just put this in the .cfg file just before the actual model of the docking-port itself, no need to enter any coordinates, it'll already be in the right place.

	MODEL
	{
		model = FederalProductions/Parts/DockingTarget/COAS_Target
		position = 0,0.19,0
		scale = 1,1,1
		rotation = 0,0,0
	}

All it needs is the conditionals to detect the presence or absence of the docking-target plugin.

Try this with ModuleManager and alternating between installing and removing the Docking Target mod*:

@PART[SDHI_ParaDock_1_ClampOTron]:NEEDS[FederalProductions] {
	MODEL
	{
		model = FederalProductions/Parts/DockingTarget/COAS_Target
		position = 0,0.19,0
		scale = 1,1,1
		rotation = 0,0,0
	}
}

*I don't think it's a plugin per se, but rather, a CFG file that tells ModuleManager to weld a custom model to the stock docking ports.
 

2 minutes ago, Starwaster said:

Hmmmm. I didn't do it as a pull request; rather as a file edit...

Strange. It still hasn't shown up yet.

[sumghai]

14 minutes ago, Starwaster said:

Anyway, question: How do you feel about starting with the LES RCS starting in the disabled state? Downside is that an action group needs to be set up to toggle them, presumably the abort key. On the other hand, the downside of leaving them enabled by default (as they are now) is that they could be used up by the time the player actually has to abort, if his RCS is on.

My updated building instructions on the wiki requires players to manually disable the LES steering thrusters in the VAB, and then re-enable it using the Abort action group

[StevieC]

Created a file named SDHI_SMS_MMPatch_DockingTarget.cfg, copypasted sumghai's cfg sample-code, and threw it into the MM_configs folder. Worked fine with Docking Target installed. Now starting the game without docking target installed to check if that works too. If it does work, that'll be a perfect little touch for the 3.1 release! Finished testing the LES and it works like a charm. Okay I just finished getting into orbit and that docking target .cfg patch works perfectly. Now to test the heat-shield. I decided for now to wait until morning to try a free-return trajectory 'round the Mün (it's almost half-past midnight where I live) but will do a simple re-entry from Low Kerbin orbit now to test the heat-shield that way before I go to bed.

Edited February 12, 2016 by StevieC
Free Return Trajectory test delayed

[Starwaster]

5 hours ago, sumghai said:

Try this with ModuleManager and alternating between installing and removing the Docking Target mod*:

@PART[SDHI_ParaDock_1_ClampOTron]:NEEDS[FederalProductions] {
	MODEL
	{
		model = FederalProductions/Parts/DockingTarget/COAS_Target
		position = 0,0.19,0
		scale = 1,1,1
		rotation = 0,0,0
	}
}

*I don't think it's a plugin per se, but rather, a CFG file that tells ModuleManager to weld a custom model to the stock docking ports.
 

Strange. It still hasn't shown up yet.

Ah ok, that's apparently because I forgot how to Github. Should be there now 

[sumghai]

Okay folks, I've managed to sneak in a few last-minute fixes/features before tomorrow's release:

- @Starwaster's heat shield tweaks for KSP 1.0.5; cursory testing of an aerobraked reentry with 20 km periapsis results in <100 out of 800 ablator consumption.

- Support for @tg626's Docking Target mod, via a patch that only applies if his mod is installed concurrently with SDHI

- Finally, a fix to the (long-standing) bug where the umbilical port retrofit on the Mk1-2 Pod could be toggled outside the VAB/SPH, courtesy of a new stock feature implemented by @NathanKell for KSP 1.0.5; the ability to have animations only toggleable within the VAB/SPH will open up new possibilities for modders to make VAB-configurable parts.

[Starwaster]

3 hours ago, sumghai said:

- Finally, a fix to the (long-standing) bug where the umbilical port retrofit on the Mk1-2 Pod could be toggled outside the VAB/SPH, courtesy of a new stock feature implemented by @NathanKell for KSP 1.0.5; the ability to have animations only toggleable within the VAB/SPH will open up new possibilities for modders to make VAB-configurable parts.

Did you see my line item note about actionAvailable? If it's set to true, then you can bind the toggle action and still be able to toggle the umbilical on and off in flight mode.

[StevieC]

Okay, On re-entry with a Kerbin periapsis of 35 km on a free-return trajectory 'round the Mün, the SDHI heat-shield is completely depleted of ablative slightly before I reach Kerbin periapsis, so the numbers controlling the speed at which ablative gets consumed need tweaking because the stock heat-shield has the same amount of ablative (800 units) and lasts me all the way to the ground with a comfortable amount to spare. but I posted this BEFORE reading sumghai's latest post, was reporting on the heat-shield of the version I had downloaded last night. Will try the new heat-shield now.

Edited February 12, 2016 by StevieC

[Starwaster]

43 minutes ago, StevieC said:

Okay, On re-entry with a Kerbin periapsis of 35 km on a free-return trajectory 'round the Mün, the SDHI heat-shield is completely depleted of ablative slightly before I reach Kerbin periapsis, so the numbers controlling the speed at which ablative gets consumed need tweaking because the stock heat-shield has the same amount of ablative (800 units) and lasts me all the way to the ground with a comfortable amount to spare. but I posted this BEFORE reading sumghai's latest post, was reporting on the heat-shield of the version I had downloaded last night. Will try the new heat-shield now.

Yeah, try the NEW heat shield and then decide whether to suggest tweaking it..... just a suggestion

[StevieC]

one thing i WILL suggest now, however, is increasing the service module's capacity for monopropellant. Right now it stores less monoprop than the Mk1-2 capsule itself!

[sumghai]

9 hours ago, Starwaster said:

Did you see my line item note about actionAvailable? If it's set to true, then you can bind the toggle action and still be able to toggle the umbilical on and off in flight mode.

Yup - see my edit and comment on line 22 of the final version of the patch:

https://github.com/sumghai/SDHI_ServiceModuleSystem/blob/master/GameData/SDHI/Service%20Module%20System/Parts/MM_configs/SDHI_SMS_MMPatch_Mk1-2Pod_umbilical.cfg

1 hour ago, StevieC said:

one thing i WILL suggest now, however, is increasing the service module's capacity for monopropellant. Right now it stores less monoprop than the Mk1-2 capsule itself!

I'll consider it for the next update.

[sumghai]

V3.1 released - see first post for download link

3.1 - 13 February 2016
---------------------------

WARNING: This is a craft and save-breaking update; it is recommended you abort / recover existing SDHI craft before installing this update

Changes / Fixes:
 - Compatibility Patch for KSP 1.0.5
 - A dedicated Launch Escape System (LES) is now included in the parts pack
    - The LES runs on Solid Fuel, and is capable of lifting a Mk 1-2 Pod, heat shield and Pod Boost Protective Cover up to 2.0 km in altitude, making pad aborts viable compared to the stock LES
    - The LES also includes built-in RCS thrusters that are powered by its own independent Solid Fuel reserve, allowing mid-abort course corrections
 - Added support for tg626's Docking Target mod, which adds a cosmetic docking alignment target mesh to all Clamp-O-Tron docking ports
 - Dropped support for HotRockets! plugin
    - The plugin is currently not compatible/updated for KSP 1.0.5
    - The fairingless LV-909 engine will now only have stock engine FX
 - Dropped support for Klockheed Martian Special Parts plugin
    - The plugin is no longer being maintained
    - The Heat Shield's flotation collar no longer works
 - Mk1-2 Pod Aeroshroud jettison motor thrustTransforms relocated to the sides of the shroud
    - The thrustTransforms were previously located under the skirt of the shroud itself, which would overheat nearby parts such as the Service Module and Heat Shield
    - Shroud texture modified to include jettison motor nozzles and warning label decals
 - Mk 1-2 Pod Umbilical Port no longer toggleable outside VAB/SPH editor scene
    - This long-standing bug was fixed with the introduction of scene-specific animation toggling in KSP 1.0.5 (courtesy of SQUAD developer NathanKell)
 - Rebalanced part costs to be in line with stock parts (courtesy Kerbas-ad-astra)
    - Avionics Ring now has higher entry/per part cost, lower mass and adjusted CoM offset
    - Service Module now has higher entry/per part cost, lower mass and adjusted CoM offset
    - Service Module Adapter now has lower entry/per part cost, lower mass and lower breaking force/torque
 - SDHI Heat Shield characteristics updated for KSP 1.0.5's thermal model
 - Side fairings and Mk1-2 Pod Aeroshroud colliders reworked using convex rather than concave meshes
 - Side fairings now decouple from the Service Module itself rather than the Service Module Adapter
 - The Service Module and Avionics Ring now have built-in support for MechJeb and RemoteTech
 - The Service Module and Avionics Ring decoupler will wait until the umbilical has fully extended before releasing the Mk1-2 Pod

Bugs/Known Issues
 - Part testing contracts are generated in Career Mode
    - This not intended behaviour, since the SDHI SMS is intended to be tested as a complete assembled stack rather than in piecemeal
    - A future update might include a proper contract for testing the SDHI SMS

As always, big thanks to all those who contributed tweaks and bugfixes for this release.

[StevieC]

be sure to report the update to CKAN too, please

[sumghai]

Just now, StevieC said:

be sure to report the update to CKAN too, please

CKAN folks accepted my pull request one hour ago.

[StevieC]

ahh, there we go. Took a while to show up on CKAN for me as being 1.0.5 compatible but it's there now

[Bomoo]

Hey, so I'm trying to rebuild the full SDHI kit from scratch for the first time since updating, and I'm noticing that the service module fairings are now attached to the actual service module instead of the base. Could I ask why you made that change? Gotta say I liked the flexibility of them being mounted to the base. Maybe it's just my bad habit of preferring to perform my gravity turn "sideways" rather than by tilting "back."

Edit: Also, they appear to have an unfortunate tendency to explode on decouple rather than floating away. This may very well be fixed in a more recent version of the files than I'm running with. And I just noticed you officially pushed an updat to 1.05. Maaaaybe I should download that.

Edit2: Nope, they still appear to be going kablooey.

Edited February 13, 2016 by Bomoo

[sumghai]

7 hours ago, Bomoo said:

Hey, so I'm trying to rebuild the full SDHI kit from scratch for the first time since updating, and I'm noticing that the service module fairings are now attached to the actual service module instead of the base. Could I ask why you made that change? Gotta say I liked the flexibility of them being mounted to the base. Maybe it's just my bad habit of preferring to perform my gravity turn "sideways" rather than by tilting "back."

AFAIK, decouplers in 1.0.5 now appear to act along the center of mass of both the base and the decoupled part - the adapter's CoM is much lower than the fairings' CoM, causing them to eject upwards by default. After spending hours trying to tune the decoupling vector, I decided it was just easier to rework the fairings to decouple from the SM, whose CoM is more or less in line with the fairings.

7 hours ago, Bomoo said:

Edit: Also, they appear to have an unfortunate tendency to explode on decouple rather than floating away. This may very well be fixed in a more recent version of the files than I'm running with. And I just noticed you officially pushed an updat to 1.05. Maaaaybe I should download that.

Edit2: Nope, they still appear to be going kablooey.

Make sure you have the latest version of AnimatedDecouplers plugin installed, as it contains a number of fixes and code refactoring.

Also, I tend to only decouple the side fairings once in orbit, and they work beautifully without colliding or exploding

 

[Bomoo]

Decoupled at 73km, though during ascent, and they still went kablooey. But yeah, sorry to hear the messed with they messed with decouplers in 1.05. Sounds like a real pain in the neck, though I do appreciate you trying to make it work. Trying again, yeah, they appear to decouple more or less normally once I was in orbit. Getting to work on that Kessler syndrome!

[sumghai]

58 minutes ago, Bomoo said:

Decoupled at 73km, though during ascent, and they still went kablooey. But yeah, sorry to hear the messed with they messed with decouplers in 1.05. Sounds like a real pain in the neck, though I do appreciate you trying to make it work. Trying again, yeah, they appear to decouple more or less normally once I was in orbit. Getting to work on that Kessler syndrome!

You definitely shouldn't be decoupling during ascent.

[Bomoo]

14 minutes ago, sumghai said:

You definitely shouldn't be decoupling during ascent.

Yeh, I'll have to start doing it on the coast to Ap for the circularization burn. They appear to separate cleanly if the craft isn't under acceleration or in atmosphere.

[Efour]

I think you can add RealPlume config for LV909 noFairing.

I've made myself and used, like this : 

@PART[SDHI_Rockomax_LV-909_NoFairing]:FOR[RealPlume]:NEEDS[SmokeScreen] // RD-0105 / 0109
{
    PLUME
    {
        name = Hypergolic-OMS-White
        transformName = thrustTransform
        localRotation = 0,0,0
        localPosition = 0,0,-0.45
        fixedScale = 1.4
        energy = 1
        speed = 1.44
    }
    @PLUME[Hypergolic-OMS-White]:NEEDS[!VenStockRevamp]
    {
        @localPosition = 0,0,-0.55
    }
    @MODULE[ModuleEngines*]
    {
        @name = ModuleEnginesFX
        %powerEffectName = Hypergolic-OMS-White
    }
}
 

copied from realplume stock config mod.

[sumghai]

50 minutes ago, Efour said:

I think you can add RealPlume config for LV909 noFairing.

I've made myself and used, like this : 

@PART[SDHI_Rockomax_LV-909_NoFairing]:FOR[RealPlume]:NEEDS[SmokeScreen] // RD-0105 / 0109
{
    PLUME
    {
        name = Hypergolic-OMS-White
        transformName = thrustTransform
        localRotation = 0,0,0
        localPosition = 0,0,-0.45
        fixedScale = 1.4
        energy = 1
        speed = 1.44
    }
    @PLUME[Hypergolic-OMS-White]:NEEDS[!VenStockRevamp]
    {
        @localPosition = 0,0,-0.55
    }
    @MODULE[ModuleEngines*]
    {
        @name = ModuleEnginesFX
        %powerEffectName = Hypergolic-OMS-White
    }
}
 

copied from realplume stock config mod.

Could I please see a screenshot of this working in-game on the SDHI SMS LV-909?

[RocketSquid]

How gamebreaking is this update? Does it only affect certain parts? I ask because the only SDHI parts currently on any of my vessels are Avionics rings, shields, and docking ports, no actual service modules, BPCs, decouplers or fairings.

[sumghai]

13 minutes ago, RocketSquid said:

How gamebreaking is this update? Does it only affect certain parts? I ask because the only SDHI parts currently on any of my vessels are Avionics rings, shields, and docking ports, no actual service modules, BPCs, decouplers or fairings.

Based on your situation, you're unlikely to be affect by the changes. Still, do try to recover vessels using these (if possible) before updating.

[RocketSquid]

2 minutes ago, sumghai said:

Based on your situation, you're unlikely to be affect by the changes. Still, do try to recover vessels using these (if possible) before updating.

I have one that's stranded in orbit, so recovery isn't much of an option. The other is meant to be a museum piece, and its only SDHI part is a parachute clamp-o-tron, which I assume I can temporarily remove with KIS.

[sumghai]

21 minutes ago, RocketSquid said:

I have one that's stranded in orbit, so recovery isn't much of an option. The other is meant to be a museum piece, and its only SDHI part is a parachute clamp-o-tron, which I assume I can temporarily remove with KIS.

Best thing to do here is to back up your save, and proceed with the update directly. If nothing breaks, then you should be good to go.