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

[Kerbas_ad_astra]

I thought there might be a #3 but I can't recall what it might have been just now...

Something about colliders, maybe?

Also, regarding "it has a top part...", bear in mind that anything can be used to close up the fairings (if players want to make an interstage cargo bay or something), not just the nose cones.

[NecroBones]

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

OK cool, thanks for taking a look! I can certainly add all of the modules, but would it be better to wait for the new module you're working on? I'm not in any rush, so if that's going to work better, I'm willing to wait.

Actually I already fixed the DRE config on my side, and just haven't pushed the update yet. I think I'll go ahead and do that now since nothing else has come up in over a week.

Pushed:

1.0.1 (2015-06-09) - Fixes
 - Added transparency in VAB/SPH. Known issues: 
    - Flag decals look mangled in VAB/SPH, but look fine in flight.
    - Must mouse-over the base, not the fairing.
 - Updated Deadly Reentry config with more current data.
 - Updated the DRE config to not lower the heat resistence of the nose cones when DRE is not being used.
 - Added "ModuleCargoBay" modules to fairing bases, with hope of working toward stock aero support.

[Starwaster]

Re: colliders. Colliders seem to be used to tell the cargo bay at what point to stop shielding things. See the picture below. The OKTO2 should definitely not be shielded (you can tell that it is because its drag vector is completely zeroed out). For that matter, the tanks sticking out the side should not be either. ModuleProceduralFairings seems to be generating colliders as you build the mesh.

@NecroBones: In the long run it might be better to wait. What I have planned will function similarly to stock's procedural fairings and hopefully be immune to the above. (if I can generate a collider to match...)

[NecroBones]

OK great, I'll hold off for a bit then.

I can definitely add colliders, but if the module can handle that automatically, that would be fantastic. Adding them on my side is tedious but doable. For instance, if I aim to have a 12-sided hollow cylinder, plus cover the front end (with a part trigger collider or something), then each base needs 13 colliders per length added (52 total).

[Kerbas_ad_astra]

Alright! Thanks to Starwaster's advice on the AnimatedDecoupler repo, I've got the shielding working (bubble issue aside):

@PART[0Pfairing*]:HAS[@MODULE[ModuleDecouple]]:NEEDS[AnimatedDecouplers]
{
    @MODULE[ModuleDecouple],*
    {
        @name = ModuleAnimatedDecoupler
    }

    @MODULE[ModuleCargoBay]
    {
        @DeployModuleIndex = 2
        lookupCenter = 0,5,0
        @lookupRadius = 5
        -nodeOuterAftID = unnecessary
        -nodeInnerAftID = unnecessary
    }
}

It seems that ModuleCargoBay doesn't need to be pointed at the ModuleAnimatedDecoupler that corresponds to the exact upper node which is being used on a particular vessel. In the future, if/when Starwaster implements the node check, we may need to get specific and define a ModuleCargoBay for each possible length, but that can wait until then.

You can render the ModuleCargoBay patch unnecessary by fixing the CargoBay definitions in the parts themselves for your next release. The nodeInnerX and nodeOuterX definitions are used only for hollow cargo bays like the Mk2 and 3, and the DeployModuleIndex has to be pointed to the zero-indexed position of the deployment control module (i.e. the uppermost ModuleDecoupler/ModuleAnimatedDecoupler -- since it's the third MODULE in the config, the DeployModuleIndex has to be 2). Alternatively, you can take the ModuleCargoBay out of the "stock" config and move it into the patch (since it only works with AnimatedDecouplers anyway), like this:

(EDIT: I had an "@" in here -- make sure you don't!)

MODULE
{
    name = ModuleCargoBay
    DeployModuleIndex = 2
    closedPosition = 0
    lookupCenter = 0,5,0
    lookupRadius = 5
}

Incidentally, your test model with built-in colliders and animation also projected a "shield bubble" around itself.

Re: colliders. Colliders seem to be used to tell the cargo bay at what point to stop shielding things.

That might also explain why I've had trouble with non-hollow cargo bays. Thanks for the heads-up!

Edited June 10, 2015 by Kerbas_ad_astra

[NecroBones]

Awesome! I'm moving the cargobay module out to the MM config just for AD, for now. We're making progress!

[Kerbas_ad_astra]

Awesome! I'm moving the cargobay module out to the MM config just for AD, for now. We're making progress!

Just to be extra-sure you notice, I had an erroneous "@" in my adding-cargo-bay patch for the lookupRadius. If you didn't copy blindly, you're fine. (Also, you may have to change the index from 2 to 1 if you're taking out ModuleCargoBay from the main config, since it comes before the first decoupler MODULE.)

[NecroBones]

Just to be extra-sure you notice, I had an erroneous "@" in my adding-cargo-bay patch for the lookupRadius. If you didn't copy blindly, you're fine. (Also, you may have to change the index from 2 to 1 if you're taking out ModuleCargoBay from the main config, since it comes before the first decoupler MODULE.)

Ah, I missed the "@", but got the module index. Thanks

[Starwaster]

Updated Animated Decouplers to not report things as shielded if they aren't coupled. (if you want to try the previously mentioned method of using multiple cargo bay definitions. It's still taking me awhile to get my other system implemented)

[Kerbas_ad_astra]

Updated Animated Decouplers to not report things as shielded if they aren't coupled. (if you want to try the previously mentioned method of using multiple cargo bay definitions. It's still taking me awhile to get my other system implemented)

It works as advertised, though the 1.1.3 release on GitHub still points to the same commit as 1.1.2.

Here's the new patch (again, if you're taking ModuleCargoBay out of the main config entirely, modify the first MCB patch and decrement all of the DeployModuleIndex values):

@PART[0Pfairing*]:HAS[@MODULE[ModuleDecouple]]:NEEDS[AnimatedDecouplers]
{
    @MODULE[ModuleDecouple],*
    {
        @name = ModuleAnimatedDecoupler
    }

    @MODULE[ModuleCargoBay]
    {
        @DeployModuleIndex = 2
        lookupCenter = 0,2,0
        @lookupRadius = 3.5
        -nodeOuterAftID = unnecessary
        -nodeInnerAftID = unnecessary
    }

    MODULE
    {
        name = ModuleCargoBay
        DeployModuleIndex = 5
        closedPosition = 0
        lookupCenter = 0,3,0
        lookupRadius = 4
    }

    MODULE
    {
        name = ModuleCargoBay
        DeployModuleIndex = 8
        closedPosition = 0
        lookupCenter = 0,4,0
        lookupRadius = 5
    }

    MODULE
    {
        name = ModuleCargoBay
        DeployModuleIndex = 11
        closedPosition = 0
        lookupCenter = 0,5,0
        lookupRadius = 6
    }
}

(The Modular Rocket Systems LAS shroud should be unaffected, since it only has one decouple node anyway.)

[NecroBones]

Updated Animated Decouplers to not report things as shielded if they aren't coupled. (if you want to try the previously mentioned method of using multiple cargo bay definitions. It's still taking me awhile to get my other system implemented)

No worries, take your time. I know how the modding thing goes, and often have several half-finished projects sitting around.

It works as advertised, though the 1.1.3 release on GitHub still points to the same commit as 1.1.2.

Here's the new patch (again, if you're taking ModuleCargoBay out of the main config entirely, modify the first MCB patch and decrement all of the DeployModuleIndex values):

-snip-

(The Modular Rocket Systems LAS shroud should be unaffected, since it only has one decouple node anyway.)

Awesome. Yes, I already took the MCB block out of the part configs, so here's how I have the patch looking now (decremented the module reference:

@PART[0Pfairing*]:HAS[@MODULE[ModuleDecouple]]:NEEDS[AnimatedDecouplers]
{
    @MODULE[ModuleDecouple],*
    {
        @name = ModuleAnimatedDecoupler
    }

    MODULE
    {
        name = ModuleCargoBay
        DeployModuleIndex = 1
        closedPosition = 0
        lookupCenter = 0,2,0
        lookupRadius = 3.5

    }

    MODULE
    {
        name = ModuleCargoBay
        DeployModuleIndex = 4
        closedPosition = 0
        lookupCenter = 0,3,0
        lookupRadius = 4
    }

    MODULE
    {
        name = ModuleCargoBay
        DeployModuleIndex = 7
        closedPosition = 0
        lookupCenter = 0,4,0
        lookupRadius = 5
    }

    MODULE
    {
        name = ModuleCargoBay
        DeployModuleIndex = 10
        closedPosition = 0
        lookupCenter = 0,5,0
        lookupRadius = 6
    }
}

[Starwaster]

It works as advertised, though the 1.1.3 release on GitHub still points to the same commit as 1.1.2.

Ok, so I tried pushing the the latest update from my computer using Github for Windows then deleted the 1.1.3 release and recreated it.

Aaaaand.... it still is pointing to the same commit AND promptly marked 1.1.2 as being the latest version instead of 1.1.3....

See, **** like this is why I hate Github. HATE it.

EDIT: AND to further add insult to injury it claims that I made that release 3 days ago instead of 3 MINUTES ago. WHAT?????

EDIT #2: SoI just made it 1.1.4 and called it a night. (stupid Github. Stupid Starwaster )

Edited June 12, 2015 by Starwaster

[StahnAileron]

Hmm... Any luck with this working with Stock Aero yet...???? I came across another mod that made me think of this one immediately.

[Kerbas_ad_astra]

It does work with stock aero. You will need Animated Decouplers and my patch.

Edited April 29, 2016 by Kerbas_ad_astra
Fixed link with the forum update.

[StahnAileron]

Oh, really? Cool. I guess all the testing you three did worked out? Or is this technically still unofficial since NecroBones hasn't integrated it yet (nor updated the OP to state there is at least a method for stock functionality). Any known issues I might/should be aware of?

[NecroBones]

If it's working well enough, I'll have to see about adding some MM configs to detect AnimatedDecouplers, etc, and then maybe change the CKAN dependency to require that instead of FAR.

[grimlock14]

I'm having a problem in 1.0.5 where when I attempt to jettison the fairing.  Attempting to blow the panels off causes an explosion that destroys my payload.

[NecroBones]

2 hours ago, grimlock14 said:

I'm having a problem in 1.0.5 where when I attempt to jettison the fairing.  Attempting to blow the panels off causes an explosion that destroys my payload.

I haven't tested in 1.0.5, but they should still work pretty much the same. One thing you can try is to spin up the spacecraft a little to fling the panels out. Otherwise I'm not sure what to suggest since they don't really work properly with the stock aerodynamics, unless you add other mods that provide that sort of support.

[grimlock14]

I've tried spinning and non-spinning deployments, and I am running FAR.

[Kerbas_ad_astra]

On 9/9/2015 at 2:14 PM, StahnAileron said:

Oh, really? Cool. I guess all the testing you three did worked out? Or is this technically still unofficial since NecroBones hasn't integrated it yet (nor updated the OP to state there is at least a method for stock functionality). Any known issues I might/should be aware of?

Sorry to leave this unanswered for so long -- the last I checked (mostly during 1.0.4, I've removed ZPIF from my 1.0.5 install as part of a culling of parts I didn't use much, to save memory), the main issue that I recall with using ZPIF with AnimatedDecouplers is that the "shielded" region doesn't respect the boundaries of the fairing; instead, it's a sphere that encompasses the fairing and a substantial volume out the sides, so a payload can be wider than the fairing and still be protected.

[linuxgurugamer]

@NecroBones

Will ZPIF work without FAR?

[NecroBones]

4 minutes ago, linuxgurugamer said:

@NecroBones

Will ZPIF work without FAR?

 

I think so, if you use this:

 

On 9/9/2015 at 10:41 AM, Kerbas_ad_astra said:

It does work with stock aero. You will need Animated Decouplers and my patch.

 

[linuxgurugamer]

@NecroBones

Will ZPIF work without FAR?

 

I think so, if you use this:

 

On 9/9/2015 at 10:41 AM, Kerbas_ad_astra said:

It does work with stock aero. You will need Animated Decouplers and my patch.

 

Would you consider an additional CKAN entry which would be for stock?  

[NecroBones]

6 minutes ago, linuxgurugamer said:

Would you consider an additional CKAN entry which would be for stock?  

 

Possibly. For the most part I've been thinking of this mod as being retired, but if it's still seeing some use, we can probably rig something up.

 

[linuxgurugamer]

31 minutes ago, NecroBones said:

 

Possibly. For the most part I've been thinking of this mod as being retired, but if it's still seeing some use, we can probably rig something up.

 

Well, what I was thinking of would be to take Kerbas_ad_astra's patch as a mod, with requirements of ZPIF & animated Decouplers.

once I find the patch (that link isn't working), I could do that later today