[1.3] Kerbal Joint Reinforcement v3.3.3 7/24/17

[a.g.]

As I expected, due to unconstrained stiffening extension, every decoupler pretty much creates joints between every (grand-)parent part, and every (grand-)child part, and then removes them all if even one of them is decoupled. Thus, as soon as you decouple the launch clamps, you lose all stiffening of the interstage bases. Then, when you decouple the booster decouplers (which don't have the clamps either as their parents or their children, and survive until now), you kill the extra connections coming from these parts and everything falls apart.

[jrandom]

So, a bug then? Argh. Like ferram4 doesn't have enough on his plate already, getting the next version of FAR done.

As a workaround, could I just slap on some radial decouplers that don't hook to anything and set their staging way up at the top so they never get triggered? Would that maybe add extra stiffening connections throughout the part tree?

[a.g.]

What you need to do is remove this from the config file and deal with the result, because all this everything connects to everything is the real bug and is not intended.

<string name="decouplerStiffeningExtensionType7">StretchyTanks</string>

[jrandom]

What you need to do is remove this from the config file and deal with the result, because all this everything connects to everything is the real bug and is not intended.

<string name="decouplerStiffeningExtensionType7">StretchyTanks</string>

But... but... I like everything connecting to everything! Framerate be damned!

...

I'll remove that line from config.xml and give it a shot.

[jrandom]

It worked! Much wobblier on takeoff, but it survives staging! Now all I have to do is add some outer struts between stretchytank sections to shore it up and all should be well.

Question: does this bug only affect StretchyTanks? Or is it more global than that?

Edited December 8, 2013 by jrandom

[a.g.]

There are two issues here:

• All decoupler strengthening links created by a decoupler are removed at once, if any of the link targets is decoupled.
  
• The config file included a heavy structural part like stretchy tanks into the list of parts that should be considered in need of additional strengthening.
  

The intent of decoupler strengthening is to work around the issue of a very light decoupler part being used to connect heavy tanks, since this mass difference causes issues for the physics. It does it by creating 'invisible struts' directly between parts on both sides of the decoupler. The list in the config file is intended to extend this strengthening to combinations like tank-decoupler-engine-tank, or tank-fairing base-decoupler-engine-tank. In both cases the first issue does not arise, since either there is only one decoupler, or they are close and are likely decoupled in combination anyway. However, including the tanks allows this strutting to extend recursively to the whole rocket, and consequently disappear as soon as any part is decoupled.

[jrandom]

Makes sense.

Thanks to your help (and some additional exterior struts between tanks), my 3-geosat-mission is finally underway!

Heading out towards 35,786km apoapsis for circularizing to a 23:56:04.1-period orbit -- carries three small geosats with Mun-relay capability, remote guidance unit for RemoteTech control for fine-tuning sat orbit on deployment, six kerbals to run said guidance unit in the BigG crew module, and two pilots in the Gemini command module.

[Dante80]

ferram, a question. I'm using the Procedural Wings pack that contains a very nice procedural adapter for stacking different diameter parts together, I cannot make it work for the life of me though...As soon as a craft is loaded in the launchpad, the adapter flies away forcefully, with rather dramatic results.

I have isolated the problem to KJR. Any ideas?

[ferram4]

Lemme guess; the adapter has no specified part strength, right? If that's the case, then it's using the far too low default 22; try adding "breakingForce = 100" or some higher number to the config and see what happens.

Basically, it's falling apart on physics load with the higher forces caused by the stiffer joints. I've got some stuff lined up for the next release that should fix that, which should come out after KSP 0.23 is out and I've confirmed compatibility.

[Dante80]

Here is the part from the .cfg

PART
{
name = pAdapter
module = Part
author = DYJ

mesh = model.mu
rescaleFactor = 1
scale = 1

//node_stack_top = 0.0, 0.59743, 0.0, 0.0, 1.0, 0.0, 1
//node_stack_bottom = -0.0, 0.01882, 0.0, 0.0, 1.0, 0.0, 2
node_stack_top = 0.0, 0.592, 0.0, 0.0, 1.0, 0.0, 1
node_stack_bottom = -0.0, 0.01982, 0.0, 0.0, 1.0, 0.0, 2


cost = 50
category = Structural
subcategory = 0
title = PD-Mk1 AAAAAAdapter
manufacturer = Procedural Dynamics
description = The Procedural Dynamics Adaptive Adapter Apparatus adapts its shape and size to arrange a Aerodynamic Assembly of an Array of any Assorted Appliances. 

attachRules = 1,1,1,1,1

mass = 0.1
dragModelType = default
maximum_drag = 0.2
minimum_drag = 0.3
angularDrag = 2
crashTolerance = 6
breakingForce = 200
breakingTorque = 200
maxTemp = 2900
fuelCrossFeed = True


MODULE
{
    name = SingleGroupMan
    keyBoneScale = t
}

MODULE
{
    name = SingleGroupMan
    keyBoneScale = r
    BoneName = Root
}
}

I think the breakingForce = 200 is what you were talking about, right? Should I set it higher?

[ferram4]

That's... odd. I would think that it would be fine.

Go into the KJR folders until you get down to the config.xml; open it in notepad and set debug = 1. Then cause the issue again and post a copy of the output_log.txt so I can see what's happening.

[Dante80]

Does this help, or is there another way to post the log?

[Starwaster]

Lemme guess; the adapter has no specified part strength, right? If that's the case, then it's using the far too low default 22; try adding "breakingForce = 100" or some higher number to the config and see what happens.

Basically, it's falling apart on physics load with the higher forces caused by the stiffer joints. I've got some stuff lined up for the next release that should fix that, which should come out after KSP 0.23 is out and I've confirmed compatibility.

OR

@PART[*]:HAS[~breakingForce[]]
{
	breakingForce = 200
}
@PART[*]:HAS[~breakingTorque[]]
{
	breakingTorque = 200
}

And never have to worry about missing breakingForce / breakingTorque ever again. (otherwise your rockets will be breakingBad)

Requires ModuleManager 1.5.x

[ferram4]

Ah. I know what's happening here.

Go into the config.xml and make a second entry for whatever exception there is for the procedural wings, but specify this part's module. That should help fix it (I think) as a stopgap in the same way it works for procedural wings.

[Dante80]

Here is my current .xml.

<?xml version="1.0" encoding="utf-8"?>
<config>
    <bool name="reinforceAttachNodes">1</bool>
    <bool name="reinforceDecouplersFurther">1</bool>
    <bool name="reinforceLaunchClampsFurther">1</bool>
    <bool name="debug">0</bool>

    <float name="linSpring">500</float>
    <float name="linLim">0.05</float>
    <float name="linDamp">5</float>
    <float name="linBounce">0</float>

    <float name="angSpring">0</float>
    <float name="angLim">0</float>
    <float name="angDamp">0</float>
    <float name="angBounce">0</float>

    <float name="linearDriveSpring">50000</float>
    <float name="linearDriveDamper">20</float>
    <float name="linearMaxForceFactor">1</float>

    <float name="angularDriveSpring">100000</float>
    <float name="angularDriveDamper">600</float>
    <float name="angularMaxForceFactor">1</float>

    <float name="breakForceMultiplier">1</float>
    <float name="breakTorqueMultiplier">1</float>

    <float name="massForAdjustment">0.01</float>

    <string name="exemptPartType0">MuMechToggle</string>
    <string name="exemptPartType1">MuMechServo</string>

    <string name="exemptModuleType0">WingManipulator</string>

    <string name="decouplerStiffeningExtensionType0">ModuleEngines</string>
    <string name="decouplerStiffeningExtensionType1">ModuleHybridEngine</string>
    <string name="decouplerStiffeningExtensionType2">ModuleHybridEngines</string>
    <string name="decouplerStiffeningExtensionType3">ModuleEngineConfigs</string>
    <string name="decouplerStiffeningExtensionType4">ModuleDecouple</string>
    <string name="decouplerStiffeningExtensionType5">ModuleAnchoredDecoupler</string>
    <string name="decouplerStiffeningExtensionType6">ProceduralFairingBase</string>
    <string name="decouplerStiffeningExtensionType7">StretchyTanks</string>
</config>

would a line called

<string name="exemptModuleType1">SingleGroupMan</string>

work? I'm sorry for dragging on with this, I really have no clue how coding goes..XD

[TimMartland]

This mod is really good!

[Starwaster]

Here is my current .xml.

would a line called

<string name="exemptModuleType1">SingleGroupMan</string>

work? I'm sorry for dragging on with this, I really have no clue how coding goes..XD

Yeah that should work.

[Zander]

Hey ferram any idea when we can get a fix for this mod not working with procedural fairings and nathan kells stretchy srb/tanks. The adjustable size fairing base is not scaling connection strength when you make it bigger so it wobbles like crazy for the bigger diameter fuel tanks its attached to.

Edited December 15, 2013 by Zander

[NathanKell]

Check the end of the Stretchy thread. I posted a beta v7 that fixes that. It was never ferram's fault anyway, it's in ST.

[jrandom]

Hey ferram any idea when we can get a fix for this mod not working with procedural fairings and nathan kells stretchy srb/tanks. The adjustable size fairing base is not scaling connection strength when you make it bigger so it wobbles like crazy for the bigger diameter fuel tanks its attached to.

The pre-release of StretchyTanks v4 fixes the joint wobble issue -- that wasn't ferram4's fault. And I've had no trouble with procedural fairings and KJR. The only wobble I got was always at the ends of long ST tanks, and again that's been fixed in v4.

[NathanKell]

I think you're confusing MFS and Stretchy, jrandom.

The beta for stretchy is v7.

Although I just posted it officially and edited the OP, since no one has mentioned any showstoppers yet.

[jrandom]

7... 4... that's only a difference of less than PI! Close enough for engineering!

[egreSS]

Just thought of something after reading the dev build fix for off-rails transition chaos. Could turn that into its own thing as a type of Kraken early warning / defense system. Only variables would be knowing what to look for and if the chain reaction that inevitably leads to spontaneous vessel disassembly can be stopped once detected.

[ferram4]

Not possible with the way it works. The current planned fix doesn't stop the movement, it simply makes sure that the joints don't break. So basically it'll just go even further into wacky-waving-arm-flailing-inflatable-tube-rocket before it flies apart. It's more intended to fix the very high forces caused by physics initialization, and adding some type of Kraken-detecting code would also hurt performance a lot.

Besides, the way KJR works is essentially by taunting the Kraken as much as possible and still trying to get away with it. Sometimes, it gets angry and throws a launchpad at you. No big deal.

[drtedastro]

Yup, been there, caught the launch pad... Not pretty when it happens, but very entertaining.