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

[Bomoo]

I may have an idea - although I no longer have the source Blender files for the V1.9 version (i.e. the one without the umbilical), I can try re-downloading V1.9 from the GitHub archives and re-importing its Service Module .MU model to see how I did the colliders back then.

No promises that this will be the magic bullet, though.

Now, I've noticed the clampless version has its own trunk attachment idiosyncracies, but only at very small areas where the surface doodads will appear to snap at an inclined angle. However, I'd argue these are less severe than a big fat dead zone right across the trunk's primo attachment real estate band in the lower middle.

And because of reasons, ATV sexiness (Feat. SDHI SM)

Edited May 23, 2015 by Bomoo

[Synthesis]

Indeed, you can sort of "weasel" your way around the attachment zone. I'm trying to figure out the parachute fairing issue through CFG editing, just because I really want that abort option.

[Z3R0_0NL1N3]

I really want to see this compatable with Ven's Stock Revamp! I love the Revamped Mk1-2 pod (it has built-in RCS thrusters!) but I also cannot live without this mod. I hope it gets updated soon, and I hope it gets an option for Ven's. Pleeeeeease!

[mreadshaw]

And because of reasons, ATV sexiness (Feat. SDHI SM)

What mod is that ATV from? Looks great.

[sumghai]

Now, I've noticed the clampless version has its own trunk attachment idiosyncracies, but only at very small areas where the surface doodads will appear to snap at an inclined angle. However, I'd argue these are less severe than a big fat dead zone right across the trunk's primo attachment real estate band in the lower middle.

Noted.

I've just pushed another commit to GitHub. This time, based on reverse-engineering of the v1.9 Service Module I've taken out the ring of convex colliders around the upper avionics ring and replaced it with a single non-convex collider.

My understanding is that non-convex colliders will still allow the Service Module to be grabbable in the VAB/SPH and other parts to be surface attached to it, but this will mean that a discarded Service Module falling to the ground might not interact with the terrain properly (i.e. sinking halfway when hitting the ground rather than exploding). I'm hoping this is an acceptable compromise.

But anyways, please check that there are no more surface attachment oddities with this commit.

This is really heading into head-desking territory.

I really want to see this compatable with Ven's Stock Revamp! I love the Revamped Mk1-2 pod (it has built-in RCS thrusters!) but I also cannot live without this mod. I hope it gets updated soon, and I hope it gets an option for Ven's. Pleeeeeease!

The last time I checked, Ven's Stock Revamp interferes with SDHI SMS as the former tries to force some sort of automatic shroud near the base of the command pod and/or the heat shield. You'll have to take it up with Ven to see if he can make an exception for when SDHI is installed..

[Starwaster]

My understanding is that non-convex colliders will still allow the Service Module to be grabbable in the VAB/SPH and other parts to be surface attached to it, but this will mean that a discarded Service Module falling to the ground might not interact with the terrain properly (i.e. sinking halfway when hitting the ground rather than exploding). I'm hoping this is an acceptable compromise.

The only current limitation that I am aware of is when two concave colliders meet, they will not interact. A concave collider and a convex collider will (mostly) work just fine. A concave collider will work with the terrain just fine as well. Objects inside of a concave object tend not to collide with the inner surface.

I've tested with a fairly complex shape and it worked well aside from my Kerbal not colliding with the interior, but it wasn't a big deal.

HOWEVER. I have read somewhere (can't find the article; will try to find it) that concave colliders have changed in Unity 5 and don't interact with with anything properly. I have no idea how true that is. It might be totally false. Or it might represent trouble down the road. But we've got time before it becomes an issue, IF it becomes an issue.

[Exposure]

HOWEVER. I have read somewhere (can't find the article; will try to find it) that concave colliders have changed in Unity 5 and don't interact with with anything properly. I have no idea how true that is. It might be totally false. Or it might represent trouble down the road. But we've got time before it becomes an issue, IF it becomes an issue.

You're thinking of the recent devnotes, specifically Harvester's section:

One thing I didn’t expect would be a problem though, was a small but far-reaching change: Rigidbodies using Mesh colliders would previously collide just fine with other rigidbody mesh colliders, as long as one of them was a convex mesh. This is no longer the case. Now, if you have two rigidbody objects, both mesh colliders have to be convex. At first glance, this seemed fine, as all our parts are already convex, and the terrain isn’t a rigidbody object, so it can still have a con-convex mesh. So all is good then… except asteroids.

[Bomoo]

Noted.

I've just pushed another commit to GitHub. This time, based on reverse-engineering of the v1.9 Service Module I've taken out the ring of convex colliders around the upper avionics ring and replaced it with a single non-convex collider.

My understanding is that non-convex colliders will still allow the Service Module to be grabbable in the VAB/SPH and other parts to be surface attached to it, but this will mean that a discarded Service Module falling to the ground might not interact with the terrain properly (i.e. sinking halfway when hitting the ground rather than exploding). I'm hoping this is an acceptable compromise.

But anyways, please check that there are no more surface attachment oddities with this commit.

Works like a dream! Same spots of weirdness as the clampless version near the top and bottom bands of the trunk, but the primo real estate works as expected (which is what's important).

P.S. Ground collision seems fine. Yes it clips a bit, but how often do are you focusing on the service module when it faceplants into the ground? You're more likely to be focused on the crew pod, I think. Besides, the trunk should be burning up in the atmosphere long before it hits the ground.

- - - Updated - - -

What mod is that ATV from? Looks great.

Oh that's just the storage bay from Kerbal Inventory System. Not really meant or suitable for an ATV cargo compartment, but KSP is about nothing if not improvisation. AFAIK the only stockalike ATV cargo compartments out there are from Tantares, not counting WIPs like FusTek.

Edited May 24, 2015 by Bomoo

[sumghai]

Works like a dream! Same spots of weirdness as the clampless version near the top and bottom bands of the trunk, but the primo real estate works as expected (which is what's important).

Do the decoupler and umbilical animations work fine in this version of the model?

I might also need to see some screenshots showing surface attachment of parts in the top, middle and bottom of the propulsion trunk - I know it's highly unlikely I'll be able to fix that, but I want to at least see how bad it is.

P.S. Ground collision seems fine. Yes it clips a bit, but how often do are you focusing on the service module when it faceplants into the ground? You're more likely to be focused on the crew pod, I think. Besides, the trunk should be burning up in the atmosphere long before it hits the ground.

Haha, I guess I was being a bit pedantic back in V1.9~V2.0 - I was doing some pad abort tests by deliberately damaging or destroying selected components of my lifter rocket in-flight, and while the pods landed safely in all cases, I found that the SM would survive falls in excess of 2~3 km.

Of course, you do have a point in that most of the time, lifter rocket ascents will be successful, and the SM pretty much consistently burn up in the atmosphere during re-entry long after the fact.

[Bomoo]

And you might laugh at this, but I spotted a slight misalignment you may or may not want to spend time straightening. Up to you, man. It's so minor that it's barely worth mentioning. It's fine on the other side.

- - - Updated - - -

Do the decoupler and umbilical animations work fine in this version of the model?

I might also need to see some screenshots showing surface attachment of parts in the top, middle and bottom of the propulsion trunk - I know it's highly unlikely I'll be able to fix that, but I want to at least see how bad it is.

Decoupler and umbilical animations work perfectly as far as I'm seeing. Surface attachment on the avionics ring itself is totally fine, and I'm attaching screenshots of the two small patches of weirdness. I'll add that both patches are very small to the point of being negligible, and can be built around without any difficulty. The top one could even be negated, I bet, by rotating the part 90 degrees; haven't thought to try it because of how narrow the band was. Turns out it can't but, again, it's so narrow that you shouldn't experience any problems sticking things either above or below it. It might even serve you as a useful alignment tool.

Edited May 24, 2015 by Bomoo

[sumghai]

And you might laugh at this, but I spotted a slight misalignment you may or may not want to spend time straightening. Up to you, man. It's so minor that it's barely worth mentioning. It's fine on the other side.

http://images.akamai.steamusercontent.com/ugc/534020142367404218/711503413437DC8BB319FC7D89D4CDDDF679DF9E/

That line looks like it's off by a pixel or two - I'll get to it tomorrow night, but that should be an easy fix.

Decoupler and umbilical animations work perfectly as far as I'm seeing. Surface attachment on the avionics ring itself is totally fine, and I'm attaching screenshots of the two small patches of weirdness. I'll add that both patches are very small to the point of being negligible, and can be built around without any difficulty. The top one could even be negated, I bet, by rotating the part 90 degrees; haven't thought to try it because of how narrow the band was. Turns out it can't but, again, it's so narrow that you shouldn't experience any problems sticking things either above or below it. It might even serve you as a useful alignment tool.

http://images.akamai.steamusercontent.com/ugc/534020142367431945/35FF9491856794A41D1326B76D22F103494F6A2D/

http://images.akamai.steamusercontent.com/ugc/534020142367432152/AC7E23BDF305DA416812B91D194D86E5F355D425/

Yeah, those look like really edges cases.

At any rate, I'm glad that surface attachment for the main part of the propulsion trunk is working properly again now, so I can finally properly put that issue to rest.

TODO:

- Fixing stock aero drag occlusion for the pod cover and Service Module fairings

- Dependency checking (I'll write up a proper test procedure for this)

[Bomoo]

And I don't know if this is intentional or not, but I noticed I was able to toggle the umbilical graphic while in flight, on the Mk1-2 pod. Should it not be toggleable only in the VAB? Not exactly a huge problem either way, of course.

[Synthesis]

Noted.

I've just pushed another commit to GitHub. This time, based on reverse-engineering of the v1.9 Service Module I've taken out the ring of convex colliders around the upper avionics ring and replaced it with a single non-convex collider.

My understanding is that non-convex colliders will still allow the Service Module to be grabbable in the VAB/SPH and other parts to be surface attached to it, but this will mean that a discarded Service Module falling to the ground might not interact with the terrain properly (i.e. sinking halfway when hitting the ground rather than exploding). I'm hoping this is an acceptable compromise.

But anyways, please check that there are no more surface attachment oddities with this commit.

This is really heading into head-desking territory.

http://i.imgur.com/2t7A4JJ.png

The last time I checked, Ven's Stock Revamp interferes with SDHI SMS as the former tries to force some sort of automatic shroud near the base of the command pod and/or the heat shield. You'll have to take it up with Ven to see if he can make an exception for when SDHI is installed..

Just wanted to add, yes, the new model fixes the collision issue in the VAB. Hurrah!

Back to experimenting with the parachute. I missed an obvious issue myself: so, with this fairing bug, forget abort stages, I wonder if the SDHI docking parachute might not function on return (even if you discarded the fairing hours/days earlier). Has anyone gone that far?

EDIT: Yeah, so, idiot that I am, it never occurred to me to check the RealChute end of this--apparently, RealChutes having problems deploying with/near/within visual range of a fairing of some sort is actually not uncommon, according to the RC thread (not sure if that's being worked on). In my case, I may just replace it with a default go-to parachute within the CFG as a temporary fix.

Edited May 24, 2015 by Synthesis

[sumghai]

And I don't know if this is intentional or not, but I noticed I was able to toggle the umbilical graphic while in flight, on the Mk1-2 pod. Should it not be toggleable only in the VAB? Not exactly a huge problem either way, of course.

As per the release notes for V2.3, it's a known issue, but there's not a whole lot I can do about it at this stage.

Originally, the umbilical retrofit mesh for the Mk1-2 Pod was animated using Firespitter, which allows animation toggling to be selectively disabled in the VAB / Flight Scene / IVA. I switched over to the stock animation module to lessen the number of dependencies, but as you know, the stock animation module does support the same context-sensitive feature as Firespitter.

I've submitted a suggestion / feature request to SQUAD, but I'm not sure if they'll see it.

Back to experimenting with the parachute. I missed an obvious issue myself: so, with this fairing bug, forget abort stages, I wonder if the SDHI docking parachute might not function on return (even if you discarded the fairing hours/days earlier). Has anyone gone that far?

EDIT: Yeah, so, idiot that I am, it never occurred to me to check the RealChute end of this--apparently, RealChutes having problems deploying with/near/within visual range of a fairing of some sort is actually not uncommon, according to the RC thread (not sure if that's being worked on). In my case, I may just replace it with a default go-to parachute within the CFG as a temporary fix.

Report acknowledged.

[Exposure]

Just wanted to add, yes, the new model fixes the collision issue in the VAB. Hurrah!

Back to experimenting with the parachute. I missed an obvious issue myself: so, with this fairing bug, forget abort stages, I wonder if the SDHI docking parachute might not function on return (even if you discarded the fairing hours/days earlier). Has anyone gone that far?

EDIT: Yeah, so, idiot that I am, it never occurred to me to check the RealChute end of this--apparently, RealChutes having problems deploying with/near/within visual range of a fairing of some sort is actually not uncommon, according to the RC thread (not sure if that's being worked on). In my case, I may just replace it with a default go-to parachute within the CFG as a temporary fix.

That's weird. I covered the pod and chute with the stock fairings both from a fairing starting point below it, and a fairing starting point attached to the chutes to test this out myself, and it works just fine with RealChutes once I eject the fairings. Are you using a different set of fairings?

[sumghai]

That's weird. I covered the pod and chute with the stock fairings both from a fairing starting point below it, and a fairing starting point attached to the chutes to test this out myself, and it works just fine with RealChutes once I eject the fairings. Are you using a different set of fairings?

I believe Synthesis was using the original pod boost protect covers that comes with the SDHI pack, which as I mentioned numerous times previously, does not properly occlude drag in stock aero.

Starwaster will help me write a plugin to fix that, but not yet.

[Synthesis]

That's weird. I covered the pod and chute with the stock fairings both from a fairing starting point below it, and a fairing starting point attached to the chutes to test this out myself, and it works just fine with RealChutes once I eject the fairings. Are you using a different set of fairings?

I believe Synthesis was using the original pod boost protect covers that comes with the SDHI pack, which as I mentioned numerous times previously, does not properly occlude drag in stock aero.

Starwaster will help me write a plugin to fix that, but not yet.

Ah, okay, the connection with the physics model went over my head--sorry about that.

Exposure, you're using the in-game generated fairing models, right?

[Exposure]

Ah, okay, the connection with the physics model went over my head--sorry about that.

Exposure, you're using the in-game generated fairing models, right?

I was, yeah.

After switching to testing out the boost cover, I did get the behaviour of parachutes to just not functioning even when they ejected, unless I right clicked on the port and clicked on decouple node. In fact the rest of the pod seemed to remained occuluded from physics when I staged the cover, since MechJeb kept reporting a drag coefficient of zero while it kept accelerating absurdly fast all the way past mach 1 (or was it 2?) into the ground.

Edited May 24, 2015 by Exposure

[Synthesis]

I was, yeah.

After switching to testing out the boost cover, I did get the behaviour of parachutes to just not functioning even when they ejected, unless I right clicked on the port and clicked on decouple node. In fact the rest of the pod seemed to remained occuluded from physics when I staged the cover, since MechJeb kept reporting a drag coefficient of zero while it kept accelerating absurdly fast all the way past mach 1 (or was it 2?) into the ground.

That's actually very interesting--if I'm not mistaken, you manage to evade the problem by decoupling, rather than ejecting, the SDHI fairing cover?

I won't lie, I still consider the KSP procedural fairings a little rough around the edges (please excuse the pun), so if I can keep the default fairing, I'd much rather.

EDIT: I went ahead and gave it a try, creating an action group to decouple the docking ring from the fairing--no luck. The fairing doesn't really want to move (it needs the force of the actual fairing decoupler, I guess), and unrelated, it still gives an error message.

Edited May 24, 2015 by Synthesis

[Exposure]

That's actually very interesting--if I'm not mistaken, you manage to evade the problem by decoupling, rather than ejecting, the SDHI fairing cover?

I won't lie, I still consider the KSP procedural fairings a little rough around the edges (please excuse the pun), so if I can keep the default fairing, I'd much rather.

EDIT: I went ahead and gave it a try, creating an action group to decouple the docking ring from the fairing--no luck. The fairing doesn't really want to move (it needs the force of the actual fairing decoupler, I guess), and unrelated, it still gives an error message.

Yeah on my tries afterwards it seems I just happened to got spectacularly lucky by the time I started staging the chutes (since the occluded effect goes away if the boost cover goes boom upon encountering terrain), with all the other ones giving out the same behaviour as regular staging.

[Synthesis]

Yeah on my tries afterwards it seems I just happened to got spectacularly lucky by the time I started staging the chutes (since the occluded effect goes away if the boost cover goes boom upon encountering terrain), with all the other ones giving out the same behaviour as regular staging.

Ah, bummer. I was going to ask if you'd be kind enough to share your craft files if you had a working solution. Thanks for sharing what you know anyway,

[Starwaster]

As per the release notes for V2.3, it's a known issue, but there's not a whole lot I can do about it at this stage.

Originally, the umbilical retrofit mesh for the Mk1-2 Pod was animated using Firespitter, which allows animation toggling to be selectively disabled in the VAB / Flight Scene / IVA. I switched over to the stock animation module to lessen the number of dependencies, but as you know, the stock animation module does support the same context-sensitive feature as Firespitter.

the stock animation module has a really interesting looking option called allowManualControl. Upon discovering it I immediately edited the config that adds the umbilical port and jumped in the game to try it out.

It completely disabled the animation in the VAB and in-flight or EVA. I guess action groups probably would have worked. I bet that's what it was for

[sumghai]

@Bomoo: Service Module Adapter UVs have been adjusted - it lined up okay with the fairing panels when I was previewing it in Unity 4.2.2, but could you please double-check in-game? Thanks.

the stock animation module has a really interesting looking option called allowManualControl. Upon discovering it I immediately edited the config that adds the umbilical port and jumped in the game to try it out.

It completely disabled the animation in the VAB and in-flight or EVA. I guess action groups probably would have worked. I bet that's what it was for

Darn, so close. Guess my suggestion to SQUAD still stands

[Bomoo]

@Bomoo: Service Module Adapter UVs have been adjusted - it lined up okay with the fairing panels when I was previewing it in Unity 4.2.2, but could you please double-check in-game? Thanks.

First shot is the side you just fixed, and second is the other side which didn't need fixing as far as I could tell.

[Jiraiyah]

can i ask a question, if i get the files from git's master repo, will it work properly with aero dyns of 1.0.2 now?