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

[sumghai]

Ablator appears to work now as of 1.01. Shot a test pod into a 168km x 172km orbit, came back down with a standard 30km Pe and only lost I think 21 ablator resource out of 800. They sure build them tough on Kerbin. Will test less ideal re-entry trajectories to see if it gives the heat shield more of a challenge, but yes, they appear to have fixed it.

Edit: I guess 1.02, not .01. The current version as of right now.

Sounds good! I've just pushed a new commit to GitHub with a tentative implementation of stock re-entry shielding.

I'm trying to figure out how to do conditional support for DRE (i.e. if DRE is installed, the stock re-entry shielding PartModules should get stripped out and replaced with their DRE equivalents). Suffice to say, I should not be using :FINAL for this patch

It would also be nice to tune the SDHI heat shield's ModuleAblator to lose less Ablator compared with the stock counterpart, to fit with the narrative that SDHI heat shields are superior in quality / performance.

[Bomoo]

It would also be nice to tune the SDHI heat shield's ModuleAblator to lose less Ablator compared with the stock counterpart, to fit with the narrative that SDHI heat shields are superior in quality / performance.

You could simply give them, say, 1000 ablator resource instead of 800?

[sumghai]

You could simply give them, say, 1000 ablator resource instead of 800?

Well, I suspect increasing the amount of Ablator increases overall mass.

I was thinking more in terms of tuning ModuleAblator to reduce various consumption rates, etc.

[Capt. Hunt]

Edit: ninja'ed

[johnsonwax]

I was thinking more in terms of tuning ModuleAblator to reduce various consumption rates, etc.

Alternatively you could have the heat shield dissipate a little bit of heat relative to stock and it would then consume less as a normal function of the thermo model.

[sumghai]

Alternatively you could have the heat shield dissipate a little bit of heat relative to stock and it would then consume less as a normal function of the thermo model.

Sounds like a plan!

I'm not 100% familiar with ModuleAblator's full set of parameters, so any pointers would be appreciated.

[Capt. Hunt]

Ok, I tried a few different reentry profiles with the new version and the heat shield still does not appear to be ablating. I know the reentry heating should be working because my parachute deployed and burned up on a particularly violent reentry (free-return from the mun with trajectory intersecting Kerbin so it wouldn't aerobrake).

BTW, you may want to check the realchute settings, I just hit arm so they would deploy automatically.

Edited May 2, 2015 by Capt. Hunt

[johnsonwax]

This thread should help quite a bit.

There looks like a few variables you could look to tweak. I'm guessing that it has an emissiveConstant of 0.4 (the rate at which it radiates heat away) which could be increased slightly, which would cause it to absorb heat slightly slower, so it would take longer to hit ablation temp, so it would ablate later, and slightly slower. You could similarly increase thermalMassModifier so that it can simply absorb more energy - the more it can absorb the more slowly it would increase in temp. But it doesn't emit so the former approach would cool down faster than a normal heat shield, while the latter would hold onto the heat longer than normal.

There's a few parameters in the ablator module that might help, but it's possible that it's a zero sum function. You could reduce the conductivity, but that would just cause the non-ablative part to overheat and fail. If you lowered the lossCons, you similarly wouldn't boil off ablator fast enough, and again that may cause the part to overheat. The tempThresh probably just determines at what temp it should start boiling off, so that's probably not useful. pyrolysisLossFactor might dictate how much heat a given amount of ablator removes, which would make the ablator more efficient per unit.

Might need to do some hyperediting and trial and error. Throw one of the temp monitoring mods on there so you can see what happens between runs.

[sumghai]

BTW, you may want to check the realchute settings, I just hit arm so they would deploy automatically.

Could you please clarify what you mean by this?

This thread should help quite a bit.

There looks like a few variables you could look to tweak. I'm guessing that it has an emissiveConstant of 0.4 (the rate at which it radiates heat away) which could be increased slightly, which would cause it to absorb heat slightly slower, so it would take longer to hit ablation temp, so it would ablate later, and slightly slower. You could similarly increase thermalMassModifier so that it can simply absorb more energy - the more it can absorb the more slowly it would increase in temp. But it doesn't emit so the former approach would cool down faster than a normal heat shield, while the latter would hold onto the heat longer than normal.

To save everyone some time, I consulted similar values for stock parts and applied them to SDHI.

There's a few parameters in the ablator module that might help, but it's possible that it's a zero sum function. You could reduce the conductivity, but that would just cause the non-ablative part to overheat and fail. If you lowered the lossCons, you similarly wouldn't boil off ablator fast enough, and again that may cause the part to overheat. The tempThresh probably just determines at what temp it should start boiling off, so that's probably not useful. pyrolysisLossFactor might dictate how much heat a given amount of ablator removes, which would make the ablator more efficient per unit.

I'll have to touch base with RoverDude on this.

Might need to do some hyperediting and trial and error. Throw one of the temp monitoring mods on there so you can see what happens between runs.

I'll have to rely on you guys for this one, given my present inability to run the game on my outdated laptop.

[Starwaster]

Apologies if I missed comments regarding this: What I'm a little concerned about is Animated Decouplers. It doesn't seem that starwasher's been updating it for 9 months (if it ain't broke don't fix it?). From what I can tell messing around with your service module update it does seem to be working in 1.0 (take that with a big grain of salt I've only done like 3 tests). So good news I guess?

Is AD a "requirement" or a "optional" ?

Has anyone come up with a MM patch to give the SDHI heat shield the same alblator properties as the stock 2.5? I think that would be a lovely temp fix for the moment, even with 1.0.2 the stock heat shields are not burning off much of the ablator materiel at all.

It will probably work though I haven't been able to get to testing it yet because of Deadly Reentry

It's just an extension of the stock decoupler that has some animation code and nothing that I was depending on in decouplers seems to have changed. Animation is straightforward. But as soon as I can get to it I will compile the source against the new KSP binaries

And, on the subject of not having been updated; it was last updated for 0.90 - in spite of what the last update date is given as.

Edited May 2, 2015 by Starwaster

[Bomoo]

Well, I suspect increasing the amount of Ablator increases overall mass.

I was thinking more in terms of tuning ModuleAblator to reduce various consumption rates, etc.

100 ablator resource appears to have a mass of 0.1t, so 0.8t of ablator for the stock heat shield. Your solution is more ideal than the one I suggested, I agree, but an extra fraction of a ton isn't crippling if it turns out it's not workable.

[MOARdV]

Might need to do some hyperediting and trial and error. Throw one of the temp monitoring mods on there so you can see what happens between runs.

Instead of a mod, use the debug menu (alt-f12) and select to show thermal debug info in the right-click menu. There's a plethora of info, including temperature and fluxes. I've been doing that to figure out why a heat shield I'm tweaking from another mod likewise doesn't burn on re-entry.

[Capt. Hunt]

Could you please clarify what you mean by this?

Now that I think about it that was probably just because of the reentry trajectory, it opened fine on a more gentle reentry, never mind.

[sumghai]

Okies, pushed another couple of commits to the dev build on GitHub - mainly some housekeeping, including adding a proper ModuleManager hook for Deadly Reentry so that it actually detects if DRE is installed before deciding whether to replace the stock ModuleAblator with DRE's ModuleHeatShield.

I still need to fine-tune ModuleAblator, though, as well as deal with the aero changes for the side fairings and such like.

[johnsonwax]

Ok, experimentation complete. Well, complete enough...

I started by tweaking lossConst. Increasing this from 20 to 50 resulted in the ablator starting to boil off at a lower temp (about 770), keeping the max heatshield temp lower (max around 950), and slightly increasing the amount of ablator used (about 10%). I think this simply sets the temp at which the ablator starts to boil off, but doesn't change the effectiveness of the ablator.

I moved on to pyrolysisLossFactor, and decreasing it from 10000 to 5000 caused the ablator to start to boil off at the same temp (around 850) but increased the max temp of the heat shield (max 1100 - above the failure temp of some surrounding parts) and increased the amount of ablator used by 80%. Increasing the value to 20000 has the opposite effect, started boiling at 850 as before, max temp of only 950 and ended up using only half of the stock values. So this value determines how much heat energy a given amount of ablator removes. This is what you want to change if you are after 'high quality ablator' - increase the stock value from 10000 as appropriate. I think 20000 would make for a VERY durable heat shield. 15000 might be a better middle ground.

[sumghai]

Okay, got some rather bad news regarding the fairings and boost protective cover:

• Multipart (i.e. not fully enclosed) fairings do not work right now. They would need a plugin to work.
  
• The only drag occlusion is stack occlusion. Take a boost protective cover as an example. If the boost cover is mounted *directly* atop the pod, it will occlude the pod's drag; if you mount a docking port first, then the cover, you'll get essentially doubled drag (near full cross-sectional area from the pod since only the top bit is occluded by the docking port, then the same for the cover.)
  

Although many third-party add-ons using the old multipart fairing system would also be equally affected, I still don't like the idea of making SDHI SMS dependent on yet another required plugin (as if continued confusion by users between dependencies and supported add-ons isn't bad enough).

EDIT:

Ok, experimentation complete. Well, complete enough...

I started by tweaking lossConst. Increasing this from 20 to 50 resulted in the ablator starting to boil off at a lower temp (about 770), keeping the max heatshield temp lower (max around 950), and slightly increasing the amount of ablator used (about 10%). I think this simply sets the temp at which the ablator starts to boil off, but doesn't change the effectiveness of the ablator.

I moved on to pyrolysisLossFactor, and decreasing it from 10000 to 5000 caused the ablator to start to boil off at the same temp (around 850) but increased the max temp of the heat shield (max 1100 - above the failure temp of some surrounding parts) and increased the amount of ablator used by 80%. Increasing the value to 20000 has the opposite effect, started boiling at 850 as before, max temp of only 950 and ended up using only half of the stock values. So this value determines how much heat energy a given amount of ablator removes. This is what you want to change if you are after 'high quality ablator' - increase the stock value from 10000 as appropriate. I think 20000 would make for a VERY durable heat shield. 15000 might be a better middle ground.

Ah, much appreciated! I'll push a new commit in just a tick.

I'll make sure you're given due credit for this

[johnsonwax]

I don't need credit. You're doing the real hard work here and I'm more than adequately compensated by being able to use your parts.

[Starwaster]

Okay, got some rather bad news regarding the fairings and boost protective cover:

Although many third-party add-ons using the old multipart fairing system would also be equally affected, I still don't like the idea of making SDHI SMS dependent on yet another required plugin (as if continued confusion by users between dependencies and supported add-ons isn't bad enough).

Untested idea: Use the stock ModuleCargoBay. Add that to the boast cover. Make sure that DeployModuleIndex is set to the ordinal position of the animation module that closes the hatch. (i.e. if the animation module is the first one then DeployModuleIndex = 0. If second then =1)

That worked for KWR's petal adapter pre 1.0

MODULE
{
	name = ModuleCargoBay
	DeployModuleIndex = 0
	closedPosition = 0
	lookupRadius = 0.75
}

[Bomoo]

Although many third-party add-ons using the old multipart fairing system would also be equally affected, I still don't like the idea of making SDHI SMS dependent on yet another required plugin (as if continued confusion by users between dependencies and supported add-ons isn't bad enough).

[Ford6]

A slightly more fiddly installation is a one-time inconvenience that, if you ask me, it isn't worth sacrificing functionality to.

I'll agree with this.

[sumghai]

Untested idea: Use the stock ModuleCargoBay. Add that to the boast cover. Make sure that DeployModuleIndex is set to the ordinal position of the animation module that closes the hatch. (i.e. if the animation module is the first one then DeployModuleIndex = 0. If second then =1)

That worked for KWR's petal adapter pre 1.0

MODULE
{
    name = ModuleCargoBay
    DeployModuleIndex = 0
    closedPosition = 0
    lookupRadius = 0.75
}

How well would that handle the situation described by NathanKell, where the Boost Protect Cover sits on top of a SDHI ParaDock that, in turn, is stacked on a pod? Would it actually occlude both the docking port and the pod, or only the docking port?

Well, here's the thing: if the plugin you describe is the only way for people to create viable fairing mods, it's going to be in wide use. Not quite Firespitter wide, but I anticipate anyone wanting to create fairings will be requiring it as a dependency. More niche than Firespitter, but I'd argue probably less niche than some of this mod's other dependencies. Personally, I don't see the problem with adding one more if it allows you to do what you want with the mod. A slightly more fiddly installation is a one-time inconvenience that, if you ask me, it isn't worth sacrificing functionality to.

I'll agree with this.

Roger that. Still, it'd be nice with the stock drag system offered some support for multipart fairings.

ASIDE: The proposed SDHI AeroFairings will use a custom plugin somehow interfaced with the stock drag system.

[johnsonwax]

Alternatively, you could partner up with one or more of the other widely distributed plugins and get them to extend to cover your needs. I have KSPAPI all over my system, for example, and firespitter as mentioned. I can see some benefits to fewer but more widely distribute plugins especially when we hit these major breakage points. So long as its under a license and hosted in github that others can pick up the project if the devs take a break, that's a pretty clean setup. We've certainly had these kinds of community comings-together in the past.

[sumghai]

Alternatively, you could partner up with one or more of the other widely distributed plugins and get them to extend to cover your needs. I have KSPAPI all over my system, for example, and firespitter as mentioned. I can see some benefits to fewer but more widely distribute plugins especially when we hit these major breakage points. So long as its under a license and hosted in github that others can pick up the project if the devs take a break, that's a pretty clean setup. We've certainly had these kinds of community comings-together in the past.

I suppose my general concern regarding dependencies stems from frequently receiving less-than-diplomatic PMs from various people:

- One group generally complains that I have too many dependencies in general

- The other group tends to confuse actual dependencies with add-ons I merely provide additional/optional support for

I've repeatedly and patiently explained to both groups that:

- In order for my parts to have actual functionality and not just be "dumb" fuel tanks or crew pods, they need to have certain PartModules that aren't present in the stock game. Whilst most of the first group are placated by this response, a subset then complains that I should just write my own plugin to handle everything and include it in my part pack - they fail to recognize that I'm not a plugin author, and that if I directly bundled copies of other people's plugin like how B9 Aerospace does it, it tends to lead to grief when the plugin themselves are updated whilst I'm bundling obsolete versions.

- As for the other group, I would have to repeatedly redirect them to the OPs of my various release threads, as well as attempt to explain the difference between dependencies and merely supported add-ons.

(I also get harassed by people for not hosting exclusively on KerbalStuff, but that's another story)

Ultimately, whilst I like to make add-ons with cool and fun features for my personal enjoyment as well as for sharing with you guys, I partially sympathize with these complainers - more dependencies mean more potential points of failure, weakest link(s) in the chain etc.

I think that certain features such as texture switching and glass cockpit displays should be remain as third-party plugins, but other ones such as multiple concurrent animations per part (already stock), transparent pod windows and modder/user friendly methods of handling aerodynamics for multipart fairings / cargo bays / boost protect covers should be present in the core game.

Apologies for the rant

[johnsonwax]

No apologies needed.

My suggestion for the community plug-in approach is a recognition of these things, thinking that perhaps if we could change the culture from 'person A is wholly responsible for all of these things working or not working' which is probably how snjo etc. feels, to 'these things are managed by a group of people', at the very least it would keep that kind of energy not so much directed at individuals and perhaps would help everyone feel like this isn't a job (for no pay, no less). I think it's a positive sign that Roverdude has stopped distributing MM with his mod. It's still a dependency but it's now clearly one the user is responsible for tracking down. Now if we can get CKAN working a bit more smoothly...

All easy for me to say, I'm not a plug-in developer either, but just a thought. And by disaggregating the ownership from individuals, it might make it easier for Squad to pull these into the game.

[sumghai]

My suggestion for the community plug-in approach is a recognition of these things, thinking that perhaps if we could change the culture from 'person A is wholly responsible for all of these things working or not working' which is probably how snjo etc. feels, to 'these things are managed by a group of people', at the very least it would keep that kind of energy not so much directed at individuals and perhaps would help everyone feel like this isn't a job (for no pay, no less). I think it's a positive sign that Roverdude has stopped distributing MM with his mod. It's still a dependency but it's now clearly one the user is responsible for tracking down. Now if we can get CKAN working a bit more smoothly...

All easy for me to say, I'm not a plug-in developer either, but just a thought. And by disaggregating the ownership from individuals, it might make it easier for Squad to pull these into the game.

Yeah, that would be ideal - a group of folks contributing to various plugin projects with the goal of demonstrating features that could be candidates for inclusion into the core game API.

Starwaster - I just touched base with NathanKell on your suggestion, and unfortunately, that wouldn't work. Whilst a custom plugin isn't ideal, at least most other fairing mods will require it anyway (at least, until SQUAD decides to integrate it into their core game), and so I should get less flak regarding dependencies in this particular case.