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

[Bomoo]

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?

Not yet, dude. The fairings aren't compatible with the new aerodynamics system.

[Jiraiyah]

ah kk, will wait np

[sumghai]

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.

http://images.akamai.steamusercontent.com/ugc/534020142371856458/B94C67C36A3C95AD941CEEB819FB91DB00BB5EA9/

http://images.akamai.steamusercontent.com/ugc/534020142371856657/3C3A8879C6BEFD357DF13E59A0976FCD56F585F9/

So nearly there, but not quite?

I took another look tonight, and decided to completely revise the panel lines altogether. Please bear with me while I explain my reasoning for the change:

- Originally (in V1.0), I didn't want panel lines on the adapter at all, since such lines indicate where the fairing halves would separate (obviously, the adapter itself doesn't split)

- I then realized that having panel lines on the adapter was acceptable, since it implies sheet metal being formed into segments that cover the adapter's mechanical structure. The resulting two panel lines are what you saw in V1.0 through to V2.4, including the UV mapping errors you initially reported.

- Since my first fix involved some shifting of UV maps, this caused one side the line up with the fairing seams, while the other got out of line alignment - this was because they lay on the edges of the UV island ribbon making up the adapter base ring, and was a massive pain to deal with.

- Ultimately, I ended up splitting the adapter base ring into six segments, and offset the panel lines to avoid being on the edge of that blasted ribbon of a UV island. As a bonus, they also appear to (more or less) line up with the Service Module above it, which makes for nice visual consistency.

So while the result isn't exactly what you wanted, it's ultimately better IMHO.

[Bomoo]

So nearly there, but not quite?

I took another look tonight, and decided to completely revise the panel lines altogether. Please bear with me while I explain my reasoning for the change:

- Originally (in V1.0), I didn't want panel lines on the adapter at all, since such lines indicate where the fairing halves would separate (obviously, the adapter itself doesn't split)

- I then realized that having panel lines on the adapter was acceptable, since it implies sheet metal being formed into segments that cover the adapter's mechanical structure. The resulting two panel lines are what you saw in V1.0 through to V2.4, including the UV mapping errors you initially reported.

- Since my first fix involved some shifting of UV maps, this caused one side the line up with the fairing seams, while the other got out of line alignment - this was because they lay on the edges of the UV island ribbon making up the adapter base ring, and was a massive pain to deal with.

- Ultimately, I ended up splitting the adapter base ring into six segments, and offset the panel lines to avoid being on the edge of that blasted ribbon of a UV island. As a bonus, they also appear to (more or less) line up with the Service Module above it, which makes for nice visual consistency.

So while the result isn't exactly what you wanted, it's ultimately better IMHO.

Bahaha. Honestly, they're fine as far as I'm concerned, but I didn't want to be that picky. Yes, strictly speaking, I don't think they're quite "perfect," but they're far from being UNnnnnnacceptabbbleee!

The new way you've arranged the textures, yeah, that looks good to me! Except, and I fully accept my fate if you want to kill me for this, but...

This f***in' Bomoo guy, I swear.

[sumghai]

Bahaha. Honestly, they're fine as far as I'm concerned, but I didn't want to be that picky. Yes, strictly speaking, I don't think they're quite "perfect," but they're far from being UNnnnnnacceptabbbleee!

The new way you've arranged the textures, yeah, that looks good to me! Except, and I fully accept my fate if you want to kill me for this, but...

http://images.akamai.steamusercontent.com/ugc/534020142375958245/1F0B65DEB512A99E42A139CDF668D5AA8228E70F/

This f***in' Bomoo guy, I swear.

Marooned for all eternity in the center of a dead planet, all Starfleet Captain sumghai could do was scream into his communicator...

"BOMOOOOOOOOOOO!"

---

Jest aside, that bright patch should not be there. I'll get rid of it tonight

[Bomoo]

Marooned for all eternity in the center of a dead planet, all Starfleet Captain sumghai could do was scream into his communicator...

"BOMOOOOOOOOOOO!"

---

Jest aside, that bright patch should not be there. I'll get rid of it tonight

Cheers, man.

[Bomoo]

Huh, so that bright spot isn't normally visible. It's only visible if you point a light directly at it, as on the launch pad, or in the VAB if you move a switched-on spotlight around until it shows up. Sneaky. Attaching a light in 6x symmetry around the ring reveals several such bright patches.

[sumghai]

Huh, so that bright spot isn't normally visible. It's only visible if you point a light directly at it, as on the launch pad, or in the VAB if you move a switched-on spotlight around until it shows up. Sneaky. Attaching a light in 6x symmetry around the ring reveals several such bright patches.

If that's the case, it sounds like a problem with the normal maps - the base ring of the adapter is textured/bumped mapped like the stock fuel tanks, and I suspect that the DDS conversion caused some artifacts in certain spots. I've tweaked the bump map to mitigate some of the potential problem areas, but I'm calling it a day on this one.

I'll see if I can poke Starwaster again regarding the fairing fix

[Bomoo]

If that's the case, it sounds like a problem with the normal maps - the base ring of the adapter is textured/bumped mapped like the stock fuel tanks, and I suspect that the DDS conversion caused some artifacts in certain spots. I've tweaked the bump map to mitigate some of the potential problem areas, but I'm calling it a day on this one.

I'll see if I can poke Starwaster again regarding the fairing fix

Yeah, man, don't worry about it. I thought it was a texture thing, but it's only visible in edge cases. Not worth losing any sleep over, really, unless you got nothing else to do.

[Moon Goddess]

"nothing else to do" seems a long ways off, seeing as the bug report I'd love to file is "Lack of sumghai clones" One can work on the SDHI, another could work on SEV, another could work on the other stuff.

[sumghai]

"nothing else to do" seems a long ways off, seeing as the bug report I'd love to file is "Lack of sumghai clones" One can work on the SDHI, another could work on SEV, another could work on the other stuff.

Let's see...

- One sumghai clone to work on SDHI SMS

- One sumghai clone to work on SDHI AeroFairings

- One sumghai clone to work on SDHI Strobe-o-Matic

- One sumghai clone to work on FusTek Station Parts

- One sumghai clone to work on FusTek MSEV

- One sumghai clone to work on FLEXracks

- One sumghai clone to moderate the forums

Michael Keaton, I'd like to have a word with you.

[Synthesis]

No harm dreaming, right?

[sumghai]

No harm dreaming, right?

Heh.

To be fair, the optimal solution doesn't just stop at cloning - each sumghai clone must have the ability to synchronize with each other in real time, to allow propagation of gained knowledge/experience (e.g. the sumghai working on SDHI SMS learns something useful, which the sumghai working on FusTek immediately puts to good use). Each clone should also only require 1/nth as much subsistence as the original sumghai (where n represents the total number of sumghai clones working on various projects).

[Synthesis]

Well, I'm no clone of the brilliance of you, Sumghai, but I have, after trial and error, found a solution to the Aerofairing problem!

Namely, if you destroy the fairing (say, by firing it into the ground), the parachute will deploy!

So all I need now is a range/timed explosive, since firing the fairing directly at the ground after an escape takes too long (the pod will only have a second or two after the fairing strikes the ground to deploy its chute). Anyone have any recommendations? The last ranged explosive mod I remember was back in 0.23.

[sumghai]

Well, I'm no clone of the brilliance of you, Sumghai, but I have, after trial and error, found a solution to the Aerofairing problem!

Namely, if you destroy the fairing (say, by firing it into the ground), the parachute will deploy!

So all I need now is a range/timed explosive, since firing the fairing directly at the ground after an escape takes too long (the pod will only have a second or two after the fairing strikes the ground to deploy its chute). Anyone have any recommendations? The last ranged explosive mod I remember was back in 0.23.

Blowing up the pod cover and fairings seems like a rather extreme (and somewhat unreliable) workaround. The real solution is to get ModuleCargoBay (which handles drag occlusion for hollow parts) to recognize decoupler events as triggers for recalculating drag occlusion for the (now unshielded) parts - this is what Starwaster and I are exploring.

[Ford6]

Well, I'm no clone of the brilliance of you, Sumghai, but I have, after trial and error, found a solution to the Aerofairing problem!

Namely, if you destroy the fairing (say, by firing it into the ground), the parachute will deploy!

So all I need now is a range/timed explosive, since firing the fairing directly at the ground after an escape takes too long (the pod will only have a second or two after the fairing strikes the ground to deploy its chute). Anyone have any recommendations? The last ranged explosive mod I remember was back in 0.23.

TAC Self destruct. Or have the pod default to debris and make it move out of physics range @ Ludicrous speed . . . or maybe Plaid. . .

[Synthesis]

Blowing up the pod cover and fairings seems like a rather extreme (and somewhat unreliable) workaround. The real solution is to get ModuleCargoBay (which handles drag occlusion for hollow parts) to recognize decoupler events as triggers for recalculating drag occlusion for the (now unshielded) parts - this is what Starwaster and I are exploring.

I should be clear--this is just a temporary solution for those of us who really like using the fairing.

TAC Self destruct. Or have the pod default to debris and make it move out of physics range @ Ludicrous speed . . . or maybe Plaid. . .

*Hides his doll collection*

Thanks, I'll try that.

Edited May 28, 2015 by Synthesis

[sumghai]

I should be clear--this is just a temporary solution for those of us who really like using the fairing.

I don't like pushing temporary or contingency solutions to releases - if I'm going to fix something, I want to do it properly in one go.

[Synthesis]

I don't like pushing temporary or contingency solutions to releases - if I'm going to fix something, I want to do it properly in one go.

I understand completely, I just don't want to give the impression I'm pushing for a fix. I know you've got your own priorities with good reason.

[Bomoo]

Heh.

To be fair, the optimal solution doesn't just stop at cloning - each sumghai clone must have the ability to synchronize with each other in real time, to allow propagation of gained knowledge/experience (e.g. the sumghai working on SDHI SMS learns something useful, which the sumghai working on FusTek immediately puts to good use). Each clone should also only require 1/nth as much subsistence as the original sumghai (where n represents the total number of sumghai clones working on various projects).

A "sumghive" if you will.

[sumghai]

A "sumghive" if you will.

Ha!

---

Starwaster has started looking into writing a plugin that allows the stock ModuleCargoBay to work with my decoupler-based fixed-size fairing pieces.

ModuleCargoBay determines the bounds of drag occlusion using the lookupRadius parameter, which is specified from the origin of the part. So essentially, I'll need to move the origin of the existing SDHI Service Module fairing pieces around.

http://i.imgur.com/dQX1D9W.png

Obviously, this will be save breaking, but it's a small price to pay for something that will work with the stock aero in a robust manner.

EDIT: As Starwaster noted, no changes to the fairing and pod cover models are necessary.

Edited May 30, 2015 by sumghai

[Starwaster]

Update regarding fairings:

I have this working right now as is, to my satisfaction without Sumghai having to do anything that will break saves. (turns out that ModuleCargoBay lets you specify an offset from the part's origin. So, kudos to Squad for doing that right)

The way that this will work is that it I'm adding this functionality to my animated decoupler plugin. The only thing I have left to do is to ensure that there is no hard dependency on an animation being specified. (so basically it will always work just like a stock decoupler if no animationName is given). I should have Animated Decouplers fully updated by the end of the day and a pull request sent to Sumghai with the necessary updates to fairing and aeroshroud.

The reason for me doing it this way is that AnimatedDecoupler is already an SDHI dependency so everyone will already have it and no new dependency created.

When THAT is out of the way, I move to phase 2: Making a system that will work with KW Rocketry's fairings so that those will work with stock aero. I will have those working. Know that for sure.

[sumghai]

Update regarding fairings:

I have this working right now as is, to my satisfaction without Sumghai having to do anything that will break saves. (turns out that ModuleCargoBay lets you specify an offset from the part's origin. So, kudos to Squad for doing that right)

The way that this will work is that it I'm adding this functionality to my animated decoupler plugin. The only thing I have left to do is to ensure that there is no hard dependency on an animation being specified. (so basically it will always work just like a stock decoupler if no animationName is given). I should have Animated Decouplers fully updated by the end of the day and a pull request sent to Sumghai with the necessary updates to fairing and aeroshroud.

The reason for me doing it this way is that AnimatedDecoupler is already an SDHI dependency so everyone will already have it and no new dependency created.

OH YISS.

(Points to massive pyre of boosters, struts and Kerbalnaut effigies) Accept this humble sacrifice as a token of my gratitude, O great Starwaster!

[sharpspoonful]

Sumghai, I'll run it through a test run as soon as you merge the pull request.

Edited May 30, 2015 by sharpspoonful

[Starwaster]

OH YISS.

(Points to massive pyre of boosters, struts and Kerbalnaut effigies) Accept this humble sacrifice as a token of my gratitude, O great Starwaster!

Let the fuh-USE be lit!