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

[MOARdV]

Isn't it a know bug of KOSMOS that currently the URM tanks don't work well with the launch clamps? I don't think it's because of this mod here, but could be I'm mistaken.

I reported on that bug in the KOSMOS thread. The bug is not the URM tanks (or not only the URM tanks). The bug is that the entire ship is shifted by 0.141m when you go to the launch pad (look in the debug log for the "Ground Contact!" message). In 0.21, the error was 0.006m. There is a large adjustment being applied to a ship when you go to the launch pad, while physics is "on". I was hoping that this plug-in would affect the launch clamps enough that I could undo the hack to the launch clamp breaking force, but it isn't enough to fix that problem. I still have to use a very high breakingForce (1500-1750 instead of 150) on the clamps to hold a URM ship in place at launch when the earth moves beneath it.

[p3asant]

Thanks to this, this finally works:

Nice to have an awesome mod released by nathan and ferram both every couple days

[BigFatStupidHead]

I remember reading some reasoning why Squad would not un-wobble rockets completely - but where?

There was an old, old mod that stiffened the joints up on rockets. Because planet surfaces are completely rigid, it became not unlike two solid pieces of metal bouncing around together when trying to land. Without the give between joints, or our modern shock-absorbing legs, it was an altogether unpleasant experience.

I'm glad to see this return; the time is right.

Edited October 28, 2013 by BigFatStupidHead

[The Destroyer]

This is good! I remember a mod like this a long time ago.

There is SOME weakness though, right? Like, you can't strap 100 boosters onto eachother and expect them to not bend?

[ferram4]

So for people who want some insight into what this mod does, here it is:

Every time a vessel is created / loaded the plugin iterates through the parts, doing three things (if every option is selected):

1. Replaces the stock "FixedJoint" between attached parts with a "ConfigurableJoint" with parameters selected to make the joint properly stiff
   
2. Adds a PartModule to decouplers that adds a "ConfigurableJoint" from each of its children parts to its parent part, using parameters similar to what struts use
   
3. Adds a PartModule to launch clamps that adds a "ConfigurableJoint" from itself to the part it is attached to, using parameters similar to what struts use

Now, if you don't know much about physics simulations, you might wonder, "hey, why is 'FixedJoint' so flexible? Isn't it 'fixed?'" Well, it's "fixed" for a given timestep (how much the physics simulation calculates forward every update) and for a given mass ratio (which is always kind of a problem). Smaller timesteps make the simulation more accurate, but more expensive to run; halving the timestep will double the processor power to simulate a set amount of time. This means that you'll get physics slowdowns for much smaller rockets with a smaller timestep, so it's quite obvious why the KSP devs have opted to go for a larger timestep for the simulation, at least for now.

As for the theory behind the stiffening, at least between attached parts:

The stiffness of the joint is based solely on the part size; this is used to calculate the estimated connection area and area moment of inertia, which are used to calculate linear and torsional spring constants to model the distributed strain (percent change in material size at any point) of the part. In general, stack attaches are assumed to be connected through a cylinder of diameter equal to the part diameter; surface attaches are assumed to be connected along the length of the part, with the "area" being calculated assuming that the part is a cylinder and that the surface attach is along a 15 degree arc section of that cylinder.

The actual stiffness values are much lower than they would be in real life; this is because with the real life stiffness of aluminum in the calculations all part connections were incredibly twitchy. As a result, all rockets still flex far more than in real life, but certainly within manageable limits now.

So as for the computational overhead for most of this:

• There's a very slight (completely unnoticeable) overhead from running the global joint update function.
  
• There's some overhead when a new vessel initially loads on the pad / from the list of vessels in flight as the joint properties are calculated.
  
• The decoupler and launch clamp functions themselves add very slight overhead due to the extra PartModules on them, but this is somewhat difficult to notice.
  
• The joints added by the decoupler and launch clamp functions do incur some overhead, since physics calculations need to be run on them, but since there are fewer parts to simulate, it seems to be faster than adding struts. If you can't tell the extra overhead from using autostrut = yes on procedural fairings, then you can't notice this.
  
• The stiffening of joints does nothing to make physics calculations worse, since it replaces the old joints completely with different parameters. Same calculations have to be done anyway.

Also, you can't just strap boosters on like mad and expect it to work. If you do find that the stiffening makes the part connections too strong for you you can universally weaken all part connections through a value in the config.xml to counteract it.

And now, for several pages back:

I was looking forward to using this, but apparently, it also affects joints it shouldn't, namely, joints within Damned/Infernal Robotics parts. With the plugin installed, they lose most of their range of movement, which makes them useless, once I remove the plugin, the normal range of movement is restored.

Could they be considered a special case somehow?

This was completely unknown to me, but I can take a look at it. Would you (or someone else well-versed in Infernal Robotics) be so kind as to post a craft that truly exemplifies the problem and has no other mods attached? I'd like a confirmed problem case to work with before I start messing around with it too much.

[Necroscope]

Downloading now.

I can live without robotic arm, but I can't with engine sliding sidewards right after ignition.

Thank you VERY much!

[a.g.]

Did you test how this interacts with docking and undocking, especially on complicated stations with multiple modules and docking ports? I think the known bug with octagonal struts and docking ports is because the game reshuffles part hierarchy and joints when docking happens, and messes up with nonphysical parts. It may also kill the improved joints.

[ferram4]

I have not; I'll have to look into it to be honest. However, the improved joints simply replace the original joints, particularly with respect to the part.attachJoint, which is what gets refactored for such things. The decoupler joints aren't dependent on hierarchy once they are added, so docking should affect them.

[Mihara]

This was completely unknown to me, but I can take a look at it. Would you (or someone else well-versed in Infernal Robotics) be so kind as to post a craft that truly exemplifies the problem and has no other mods attached? I'd like a confirmed problem case to work with before I start messing around with it too much.

It's quicker to describe it really, because it shows up even in the most primitive examples. While I first discovered it in quite a complicated craft, I have confirmed the joint reinforcement was at fault using just two parts.

1. Install Infernal Robotics.
   
2. Take a large probe core, and attach a large adjustable rail on top, it doesn't at all matter where or how. (You might want to also throw in a battery, but you have a few minutes of control anyway, enough to see what's happening)
   
3. Launch, attempt to move the adjustable rail.
   

Without joint reinforcement, the rail can reach it's limit of motion, which is the moving segment sliding about 80% of it's length off the static segment. With joint reinforcement, it reaches about 25% and can not be moved any further, this remains true for every rail that is part of the craft. I have not tested other robotics parts, but I expect that washers and rotatrons will also exhibit this problem -- hinges might actually work because they don't have much surface area contact.

But in case that description is insufficient, I'll post a minimal craft in a few minutes.

EDIT: Here, the craft in these screenshots, uses no parts other than stock and those that come with current Infernal Robotics.

This is what's supposed to happen -- rails extended to their natural limit:

With joint reinforcement, this is as far as it goes:

Edited October 28, 2013 by Mihara
craft and screenshots added.

[a.g.]

Unless I'm much mistaken, a vessel can only have one root part, so when two crafts dock, it has to reshuffle hierarchy to make one of the vessels a child of the other. During this process it would obviously have to change parent links, and possibly re-create the joints, overwriting the ones you create; so you may need to re-run your code after a docking or undocking happens.

[The Destroyer]

Ferram, because it's stiffening the joints, won't that mean that it will have to do less calculations on flexing, and therefor improve performance?

Now, time to install FAR, Big kerbin, KIDS, and attempt to get into orbit!

[nismobg]

The MSI parts definitely have less play and move half the speed they usually do when activated.

[ferram4]

@Mihara: Thanks for the info. I'll look into a fix for that, hopefully one that can maintain proper stiffness between the joints. I think (read: pure speculation) that if the moving rail has a different rigid body than the main rail then the joint might end up connecting the wrong rigid bodies together, causing the issue.

@a.g.: Well, then the logical conclusion is to dock a mainsail to a space station, light it and see what happens. However, if the vessel code works as I think it does (which is that the game creates a new vessel for the docked combination) then that means that it should automatically do that.

@TheDestroyer: Nope, the flexing calculations get done anyway. It's actually those calculations with larger, part-appropriate numbers that keep the flex to a minimum.

[Kickasskyle]

Thanks for this, you've fixed one of the nagging problems KSP had and at the same time made it customizable.

[Mihara]

@Mihara: Thanks for the info. I'll look into a fix for that, hopefully one that can maintain proper stiffness between the joints. I think (read: pure speculation) that if the moving rail has a different rigid body than the main rail then the joint might end up connecting the wrong rigid bodies together, causing the issue.

As far as I know (I am not really an expert on IR internals, I'm afraid) that's exactly how IR works in the first place -- parts have to consist of multiple independent rigid bodies or they won't work, and many of the problems in using them result from the fact that you attached parts that you want to move to the wrong one.

[sojourner]

Finally, an addon that will make me fully invest in ksp .22. and abandon my .21 save. I have a lot of designs to rebuild with reduced part counts. Woot!

[sirkut]

Infernal Robotics uses ConfigurableJoints and I just saw that your plugin too uses ConfigurableJoints. I think during the iteration process it is overriding the values that the Infernal Robotic parts have.

[Surefoot]

Okay played a bit with it, my HyperJet X model (that i posted on FAR thread, there's the .craft file to try it out) has got a problem with this mod: wings become incredibly wobbly. Also i still have to use the heavy struts across the fuselage otherwise it will flex like crazy.

- Do this plugin affects B9 fuselage sections ?

- How does it affect horizontal "stacks" (SPH designs, basically)

- PWings get borked pretty hard, try my hyperjet to understand.. Screen caps coming in a few

(edit) there:

See the weird geometry, wings attachments go crazy

WHOA NELLIE

Edited October 28, 2013 by Surefoot

[ferram4]

@sirkut: Yeah, looking at it I think I'll just have to exempt MuMechToggles from the changes. Hopefully it works.

@Surefoot: There are no NullReferenceExpections that can be traced back to KJR, correct? I haven't tested it with B9, but I will investigate and see if there is anything strange about those.

[foamyesque]

Yus. Finally.

[Surefoot]

@ferram: just tested another, simpler (atmospheric) design, the pwing roots are moving "freely" around, like they are just attached with an elastic (they dont break out though). I'll take a look at the logs if i see anything suspect..

(edit) i only see a warning: "JointWobbleRemover: extents could not be properly built for part Mark2 - PWing" when i load my plane, no NullReferenceExpection (and no error).

Edited October 28, 2013 by Surefoot

[ferram4]

Ah, I see what's happening. Since the plugin can't load the mesh for whatever reason, it doesn't have a stiffness for the joint "spring." Basically it means it's being set to zero. I'll add pWings to the new "exemption" list that will be in the config.xml for now. Hopefully that list will allow people to not have to wait to deal with plugin-caused incompatibilities.

I also need to update the name in the warning to be Kerbal Joint Reinforcement (it went through a few name changes).

[ANWRocketMan]

Well... Something went wrong...

I've also found some errors on certain parts not stiffening as they should... Most specifically with the Procedural fairings, but also between KW Rocketry engines and KW Rocketry decouplers. I couldn't see anything specific in the log or see anything in the debug menu in-game.

EDIT:

The specific parts are:

• Procedural Fairing bases(all of them so far it seems)
  
• KW Rocketry Engines(I've noticed this with all of them except the 1m engines)
  

*NOTE: The Procedural Fairing bases might be procedural fairings problems as they tend to do that stock as well, but I strutted this one down quite well I think.

Edited October 28, 2013 by ANWRocketMan

[Surefoot]

I get an error in the logs too (with my planes, using the B9 landing gears): "WheelCollider requires an attached Rigidbody to function." Not sure if it's related to B9 itself or that new plugin.. I suppose your plugin log entries are all prefixed with "JointWobbleRemover:" right ?

[SSR Kermit]

I'm having a non-critical issue with this plugin and FAR on a spaceplane that was already strutted; I had a pair connecting every segment. With this plugin, the FAR flight assistance freaks out in the pitch axis, causing serious oscillations.

EDIT: No I'm not, rather the plugin revealed a pair of unconnected struts by having them be the breaking point.

The design I use is stable at high mach numbers but calls for some trimming or flight assist at lower speeds, but with the plugin it remains stable _unless_ I use the flight assistance even at lower speeds (SAS works like it usually does with FAR, btw, ie not-so-good at high lift).

A bit odd that the FAR flight assistant did a worse job than either the stock SAS or even no assist-- never seen that before. Since its also a VTOL, I kinda need the flight assists to land, but fortunately the fix was simple: remove struts between attached segments. Or use the stock SAS, but that would retain the weirdly stable aerodynamics below mach 1.

Here's what it looks like for reference:

Edited October 28, 2013 by SSR Kermit
removed cluttering image, redacted dumb post