[1.0.1/1.1.3][Semi-Retired, Semi-Revived] Zero-Point Inline Fairings v1.0.2 (2016-04-28)

[NecroBones]

Cool, cool. Yeah, that might be the thing to do, just get a FAR-required release going.

In considering this, something that I'm really hoping gets fixed in the UI updates for KSP is the VAB/SPH menu bug that kept me from having more than two "ModuleJettison" nodes per fairing base. If that were to get fixed, I could see consolidating the fairing bases again so that all 4 lengths at each base+fairing diameter combination would be in just one base, instead of two like we have currently. If I could get things to work that way, I'd love to drop the "Lite" version of the mod and keep a more lean primary copy of the mod running.

Maybe I'll do that anyway. With three or more jettison nodes, the fairings still worked, it was just a really stupid exploding/zooming bug in the menu icons. We can probably live with that, if it means reducing the menu item count, and making the mod easier to manage on my end.

I'd also be tempted to redo the fairing panels to separate in halves rather than quarters, since ModuleJettison appears to mostly ignore the jettison directional information you give it, and instead seems hardcoded to separate two panel halves, since the only stock engine that uses this is the LV-N with its two shells.

Considering options.

[NecroBones]

OK, so I did a bunch of work on this over the last couple of days. I think I have almost everything put together to make it work.... and then I hit a big roadblock.

I think something changed in KSP 1.0+ with how it handles the "ModuleJettison" fairing panels (where "isFairing = False", counter-intuitively). The thing is, the only stock part that uses this is the LV-N, and it only has the typical top and bottom attachment nodes.

What's happening now, is that when you stage anything, the panels fling off, even if whatever is attached above the fairing is still in place. If I can't find a work-around for this, we're dead in the water, which stinks after all the work I did to get it caught up.

Right now the only thing I can think of to try, is to put the decoupler nodes back into the fairings rather than the nose-cones, so that it's configured like it was in previous versions. But I suspect this is a new bug in KSP with no quick fix, and that experiment is probably doomed to fail.

Change log so far:

 - Redesigned quite heavily. 
    - Requires FAR/NEAR or similar aerodynamics mod. WILL NOT SHIELD CONTENTS WITH STOCK AERO.
    - Fairing bases consolidated. 4 lengths per base.
    - Panels now separate in halves rather than quarters.
    - Decoupler nodes moved to nose cones. Must use decoupler/separator/dockingport (or decoupling nose cone) above the fairing.
    - Updated tech tree assignments to correspond to new stock fairing diameters.
    - Added matching "flush" nose cones.
    - Added new bulkhead profile and thermal settings for KSP 1.0+.
    - Renamed nose cones to match more recent fairing naming scheme.
    - Various size and scaling adjustments.
    - Minor texture updates.
    - Updated textures to use DDS format.
 - Lite version of mod is discontinued.

Before launch:

Hitting spacebar (staging only the clamps and the mainsail):

- - - Updated - - -

OK, so I did a bunch of work on this over the last couple of days. I think I have almost everything put together to make it work.... and then I hit a big roadblock.

I think something changed in KSP 1.0+ with how it handles the "ModuleJettison" fairing panels (where "isFairing = False", counter-intuitively). The thing is, the only stock part that uses this is the LV-N, and it only has the typical top and bottom attachment nodes.

What's happening now, is that when you stage anything, the panels fling off, even if whatever is attached above the fairing is still in place. If I can't find a work-around for this, we're dead in the water, which stinks after all the work I did to get it caught up.

Right now the only thing I can think of to try, is to put the decoupler nodes back into the fairings rather than the nose-cones, so that it's configured like it was in previous versions. But I suspect this is a new bug in KSP with no quick fix, and that experiment is probably doomed to fail.

--snip change log--

Before launch:

http://ksp.necrobones.com/screenshots/2015-05/KSP%202015-05-28%2021-08-54-55.jpg

Hitting spacebar (staging only the clamps and the mainsail):

http://ksp.necrobones.com/screenshots/2015-05/KSP%202015-05-28%2021-09-01-66.jpg

OK, so I'm confused and pleasantly surprised.

It turns out that putting the decoupler capability back into the fairings themselves, does indeed seem to fix the problem. Also, it look like the old VAB/SPH menu icon bug isn't being a problem either (which is what kept me from having more than two lengths per base, since it would wig out with 3+ decoupler nodes in one part).

We may be back in business.

But I do have one more thing to try. I think I goofed up something with the nose cone decoupler staging settings.

Edited May 29, 2015 by NecroBones

[NecroBones]

OK, this is up for people to play with.... I'm thinking of this as an extended beta test, but slapped the "1.0" number on it mainly to indicate incompatibility with previous 0.X versions.

I fully expect to need to fix things.

EDIT: I tried adding mouse-over transparency in the VAB/SPH, which kind-of worked, but it screwed up the flag decals. There's always a catch.

1.0 (2015-05-28) - Re-release after KSP 1.0.
 - Redesigned quite heavily. 
    - Requires FAR/NEAR or similar aerodynamics mod. WILL NOT SHIELD CONTENTS WITH STOCK AERO.
    - Fairing bases consolidated. 4 lengths per base.
    - Panels now separate in halves rather than quarters.
    - Updated tech tree assignments to correspond to new stock fairing diameters.
    - Added matching "flush" nose cones for sizes 1 & 2 (1.25m & 2.5m).
    - Added new bulkhead profile and thermal settings for KSP 1.0+.
    - Renamed nose cones to match more recent fairing naming scheme.
    - Various size and scaling adjustments.
    - Minor texture updates.
    - Updated textures to use DDS format.
 - Lite version of mod is discontinued.

Edited May 29, 2015 by NecroBones

[Kerbas_ad_astra]

Have you tried making these work with stock aero? I've got some ideas I'm going to test on my own (and if any of them work, I'll let you know), but before I start diving too deeply into ModuleCargoBay and DragCubes, I'd like to know if you've tried anything that hasn't worked. Thanks!

[NecroBones]

Have you tried making these work with stock aero? I've got some ideas I'm going to test on my own (and if any of them work, I'll let you know), but before I start diving too deeply into ModuleCargoBay and DragCubes, I'd like to know if you've tried anything that hasn't worked. Thanks!

I haven't tried yet (but plan to soon), so feel free.

They'll definitely need ModuleCargoBay and probably a set of drag cubes, at the very least.

But back while KSP 1.0 was still being worked on, Harv mentioned using raycasts to determine if an object is inside a bay/fairing or not, based on colliders. The thing is, usually with auto-shrouds like these, they don't have their own colliders at first, and then the colliders are auto-added when the panel is ejected. However, he also said that the colliders can be configured as part triggers (rather than physics colliders). So I suspect what might need to happen, is to add "part trigger" colliders as child objects to all of the panels, and end-cap ones as well that are owned by just one of the panels.

But if there's a way to get it working without going through all of that, I would be very happy. I'll probably add all of that to one of the bases to experiment with and see what happens.

[Kerbas_ad_astra]

I'll add Drag cubes and ModuleCargoBay, but the wrinkle that I foresee is that drag cubes basically encode area and shape, but each of these parts comes in four sizes. What I think may be necessary is to basically use Module Manager patches to split each config into four parts (e.g. short, medium, long, extra long) -- duplicating the base part and removing all but one of the four upper nodes (and adding ModuleCargoBay and a drag cube). Then each of those configs can host an appropriately-sized drag cube. This kind of loses the point of the pack, but at least you'll get to keep the single model for each width.

Once I've got a couple of those set up, we'll see if the part trigger colliders turn out to be necessary. (I basically plan to stuff a couple aluminum fins inside a fairing, blast off with the SLS engine, and see if the fins explode.)

[NecroBones]

OK, that sounds like a good experiment.

Something also worth considering is that the drag for the fairings shouldn't change too hugely. It's probably OK to fudge it and set up one set of drag cubes and just let the drag be the same for all lengths on the same base. Just set the drag low, and call it good.

I'm also re-adding the VAB transparency again. It mangles the flag decals while in the editor, but they look normal when you launch. Here's a screenie:

[NecroBones]

This doesn't bode well. I added a "part trigger" collider at the front end of the fairing, and "no attach" physical colliders to the panels, just to the shortest length of the "flush" fairing system. In other words, as long as I used the shortest attachment node, the payload should be entirely enclosed in the fairing's colliders.

Plus I added ModuleCargoBay (not worrying about drag cubes yet, just wanting to see if it'll shield anything):

	MODULE
	{
		name = ModuleCargoBay
		DeployModuleIndex = 0
		closedPosition = 0
		lookupRadius = 2.5

		nodeOuterAftID = bottom
		nodeInnerAftID = inside
	}

And I got full drag on the contents, as far as I could see.

Grrr.

Edited May 29, 2015 by NecroBones

[Kerbas_ad_astra]

I see that sumghai has been wondering the same thing as we have: http://forum.kerbalspaceprogram.com/threads/119675-Plugin-to-allow-multi-part-fairings-boost-protect-covers-to-work-in-stock-1-0x-aero

Notice what he reports (a little way down the thread): that DeployModuleIndex is looking for the index of the animation module that controls openness or closedness. We may be out of luck unless someone comes up with a module like the one he describes, to somehow convert a staging action into something that ModuleCargoBay can use. On the plus side, sumghai and Starwaster are on the case, so there's hope for this mod yet.

Also, the lookupRadius should be the distance from the CG to the maximum linear extent of the bay. Assuming the CG is at 0,0,0, this would be something like 9.6 for the 2.5m inline flush fairing -- you may want to move the CG up so that the radius (and thus search and calculation time?) can come down.

[NecroBones]

I see that sumghai has been wondering the same thing as we have: http://forum.kerbalspaceprogram.com/threads/119675-Plugin-to-allow-multi-part-fairings-boost-protect-covers-to-work-in-stock-1-0x-aero

Notice what he reports (a little way down the thread): that DeployModuleIndex is looking for the index of the animation module that controls openness or closedness. We may be out of luck unless someone comes up with a module like the one he describes, to somehow convert a staging action into something that ModuleCargoBay can use. On the plus side, sumghai and Starwaster are on the case, so there's hope for this mod yet.

Also, the lookupRadius should be the distance from the CG to the maximum linear extent of the bay. Assuming the CG is at 0,0,0, this would be something like 9.6 for the 2.5m inline flush fairing -- you may want to move the CG up so that the radius (and thus search and calculation time?) can come down.

Yeah, I figured out the radius/CG thing after taking another look at it. I've bumped it up and added the ModuleCargoBay to all of the fairings, but of course it still fails right now.

The thing is, the stock "procedural" fairings also work on a staging event and no animation (as far as I can tell), and it still uses the ModuleCargoBay. They might have hard-coded a special case for it of course. I wouldn't put it past them to hardcode things despite the settings in the CFG (they do that often enough anyway).

At least people can still use this with NEAR/FAR in the meantime, but it would be great to get a stock solution working too.

EDIT: Looking at the links, I see they're talking about how procedural fairings work with it. Also forgot to note, the CG/CoM position is inside the base for ease of placement from the VAB menu, and also so that it makes sense after staging off the panels. It would still need to be a sensible place for all panel lengths, so I think I could only get away with moving it forward 3m, to accommodate the shortest fairing length. A radius of 7m versus 10m is a large volume difference, but I'm not sure if it's worth messing with how the part balances in the rocket. It only gets triggered to recalculate at those specific events anyway.

Edited May 29, 2015 by NecroBones

[Kerbas_ad_astra]

Yeah, I figured out the radius/CG thing after taking another look at it. I've bumped it up and added the ModuleCargoBay to all of the fairings, but of course it still fails right now.

The thing is, the stock "procedural" fairings also work on a staging event and no animation (as far as I can tell), and it still uses the ModuleCargoBay. They might have hard-coded a special case for it of course. I wouldn't put it past them to hardcode things despite the settings in the CFG (they do that often enough anyway).

At least people can still use this with NEAR/FAR in the meantime, but it would be great to get a stock solution working too.

In that thread I linked, sumghai speculates that ModuleProceduralFairing somehow creates a "dummy" one-shot animation that executes during staging. I guess that's the approach that he and Starwaster will take for their "ModuleDecouplerListenerForCargoBay".

[NecroBones]

In that thread I linked, sumghai speculates that ModuleProceduralFairing somehow creates a "dummy" one-shot animation that executes during staging. I guess that's the approach that he and Starwaster will take for their "ModuleDecouplerListenerForCargoBay".

I think I edited my post to include that as you were posting.

But yeah, what's funny is that I put correct values in for my cargo bays in other mods, then promptly forgot about it.

[damerell]

I feel there's definitely a place for Zero-Point fairings in 1.0. They offer a combination of simplicity of use and constrained dimensions that no other fairing mod I've found has. Procedural Fairings offer comparable simplicity but will go round anything, KW offers nice fixed sized fairings but they're fiddly to use, and stock makes you do a lot of manual work and has few limitations.

That was essentially what I felt. I don't like procedural parts of any kind - working within the constraints of a defined set of parts is more enjoyable, I think.

I'm glad you've got to it, since I hadn't. :-/

[NecroBones]

That was essentially what I felt. I don't like procedural parts of any kind - working within the constraints of a defined set of parts is more enjoyable, I think.

I'm glad you've got to it, since I hadn't. :-/

My pleasure. Actually it gave me a chance to rework it in a way that I wanted to for quite some time. The fact that people can still find it useful is nice.

I'm working on getting it relisted in CKAN. I have a ticket open with them to do this, and add FAR as a suggested component. When I had them delist it, it took a few weeks before the changes took effect, so we'll see how long it is this time.

[damerell]

I see there's a commit on a NetKAN branch that re-includes it, so not long now.

[Kerbas_ad_astra]

So, it seems that AnimatedDecouplers is working for the SDHI fairings, but they've got a built-in animation, and I haven't had any luck getting it to do the same with ZP fairings (check out my issue report there to see the config I used). Still, it's at least the beginnings of a solution, and you might have more luck tinkering with it than I've had.

Incidentally, I figured out an easier way to test if a fairing is actually shielding its contents than fiddling with aerodynamic overlays in flight: solar panels won't deploy if they're shielded.

[NecroBones]

So, it seems that AnimatedDecouplers is working for the SDHI fairings, but they've got a built-in animation, and I haven't had any luck getting it to do the same with ZP fairings (check out my issue report there to see the config I used). Still, it's at least the beginnings of a solution, and you might have more luck tinkering with it than I've had.

Incidentally, I figured out an easier way to test if a fairing is actually shielding its contents than fiddling with aerodynamic overlays in flight: solar panels won't deploy if they're shielded.

Cool, I may have to toy with it. It's possible that it's not working due to the issue with ModuleCargoBay needing the compartment to be enclosed in colliders, which the fairings don't have in the last release. I added colliders to just one length+diameter in an experimental copy of here, so I may grab your config and give it a shot.

Good to know about the solar panels too!

[NecroBones]

Cool, I may have to toy with it. It's possible that it's not working due to the issue with ModuleCargoBay needing the compartment to be enclosed in colliders, which the fairings don't have in the last release. I added colliders to just one length+diameter in an experimental copy of here, so I may grab your config and give it a shot.

No dice. The ship comes out to the pad with the contents unshielded. However, I suspect it's still expecting an animation. I can try adding a dummy animation and see if that works.

[eataTREE]

So are these coming back then? Hooray! I have been using your interstage adapters from your other parts packs for their fairing-generating abilities in the meantime.

The stock fairings have their purpose, but are an aerodynamic nightmare.

[NecroBones]

No dice. The ship comes out to the pad with the contents unshielded. However, I suspect it's still expecting an animation. I can try adding a dummy animation and see if that works.

No good with that either. The presence of an animation didn't help.

EDIT: If you'd like to toy with it, here's the experimental copy. Only the shortest length of the "flush" 3.75m is set up for it right now:

http://ksp.necrobones.com/files/testing/experimental-fairing.zip

So are these coming back then? Hooray! I have been using your interstage adapters from your other parts packs for their fairing-generating abilities in the meantime.

The stock fairings have their purpose, but are an aerodynamic nightmare.

It's back in CKAN now, with FAR listed as a dependency. We're still working on the stock aero support.

Edited June 4, 2015 by NecroBones

[damerell]

More details on request, but this is the initial "everyone, or just me?" bug report.

I've been trying to launch a craft with 0-point fairings. All working well... except that when I come to jettison the fairing, something explodes. From the log, it seems that one part of the payload has collided with one fairing piece - even if the fairing base is absurdly large compared to the payload - and then the payload has undergone several structural failures sending parts flying off spinning, as if the collided-with piece were given a really enormous impetus.

[NecroBones]

More details on request, but this is the initial "everyone, or just me?" bug report.

I've been trying to launch a craft with 0-point fairings. All working well... except that when I come to jettison the fairing, something explodes. From the log, it seems that one part of the payload has collided with one fairing piece - even if the fairing base is absurdly large compared to the payload - and then the payload has undergone several structural failures sending parts flying off spinning, as if the collided-with piece were given a really enormous impetus.

It's hard to say. I saw something similar a few times while reworking the ejection angles a little, but then I started getting clean tests after that. I'm wondering if something has changed with how the "ModuleJettison" fairing panels work, either in terms of the ejection, or how it creates the colliders for them. I'd love to hear from people as to whether this is widespread, but other than messing with the ejection angles (which KSP seems to apply as an addition to a hard-coded ejection vector), I'm not sure what can be fixed.

The downside of this sort of mod, that's trying to capitalize on a stock capability to use it in an unintended fashion, is that we may run into some issues that might not be fixable, depending on what new KSP bugs may crop up.

[includao]

is it problematic to implement these fairings to work with stock aerodynamics? Or impossible? Thanks

[NecroBones]

is it problematic to implement these fairings to work with stock aerodynamics? Or impossible? Thanks

Right now it's not possible. We're discussing (here in this thread actually) some possibilities for plugins that we might be able to use to get it to work, but nothing is working yet.

[Starwaster]

I downloaded your mod and had a look at the problem involved in trying to shield payloads in stock with ModuleCargoBay / Animated Decouplers (which has had shielding capability added to it).

I have had some success in getting this to work but with some caveats.

The following MM config demonstrates what I did:

@PART[0Pfairing2mW1]
{
	@MODULE[ModuleDecouple]:HAS[#explosiveNodeID[top04]]
	{
		@name = ModuleAnimatedDecoupler
	}
	MODULE
	{
		name = ModuleCargoBay
		DeployModuleIndex = 9
		closedPosition = 0
		lookupRadius = 4.5
		lookupCenter = 0, 4.5, 0
	}
}

The caveats:

1. Animated Decouplers don't actually check to see that anything is connected to them initially. (specifically not through their explosiveNodeID, though they do check that in the event that vessel modification occurs such as through decoupling or damage). What that means is that it doesn't matter if anything was connected to top04 or not. It still will try to shield. It probably wouldn't be a big deal for me to add such a check; I just didn't think it would be necessary since I didn't anticipate a particular decoupler module deliberately not having anything attached to it.
   
2. However, even if I did that, you need a ModuleCargoBay section for every single ModuleAnimatedDecoupler that exists on the part. Its lookupCenter would be set to its explosiveNodeID's coordinate Its lookupRadius would be set to half the distance to its explosiveNodeID's Y axis value. (see example above). DeployModuleIndex has to be set to each particular ModuleAnimatedDecoupler's ordinal position. For example, the decoupler module with explosiveNodeID top04 is the tenth MODULE on the part so the index is 9. (0 = first)
   
3. I thought there might be a #3 but I can't recall what it might have been just now...
   

So, assuming I do put the necessary check in, you'd need 4 cargo bay modules on that part and on every other part for as many decouplers as they support. Definitely possible in the manner that I described, but what would be better is a single pair of modules on the fairing base. One ModuleCargoBay and one other module which I've been working on for use with KWR and its legacy fairings. I'm still finalizing the exact procedure but your fairing system is similar enough in that it has a top part that has to be attached that would be used to determine the size of the cargo bay.

One other thing... the DRE support file that you have no longer functions with the current version of DRE. ModuleHeatShield should only be used with ablator style shields. Passive protection such as fairings should instead have a high emissiveConstant