[1.3.1, 1.4.x, 1.5.x, 1.6.x, 1.7.x] Kerbal Joint Reinforcement Continued v3.4.0 [25-04-2019]

[pap1723]

@ferram4 has decided to take an extended break and us at the Realism Overhaul team have been working on updating Kerbal Joint Reinforcement. This does not require Realism Overhaul, it works in all other installs as well. Here are the details from the original post by @ferram4. Thanks to @siimav for all of the work to get this done!

Kerbal Joint Reinforcement

Tired of rockets collapsing when physics initializes, but it would be fine if physics didn't start with a jerk?

Irritated launch clamps can twist your rocket apart when physics starts for no apparent reason?

Need more joint stiffness because you're playing Real Solar System and the stock joints just don't cut it?

Then you need KERBAL JOINT REINFORCEMENT!

Lessen the effects of physics glitches and get back to designing rockets to handle flight, not to handle the forces applied when the game loads.

EXCITING FEATURES!

• Physics Easing
  • Slowly dials up external forces (gravity, centrifugal, coriolis) when on the surface of a planet, reducing the initial stress during loading
  • All parts and joints are strengthened heavily during physics loading (coming off of rails) to prevent Kraken attacks on ships
• Launch Clamp Easing
  • Prevents launch clamps from shifting on load, which could destroy the vehicle on the pad
• Increase stiffness and strengths of connections
  • Larger parts will have stiffer connections to balance their larger masses / sizes
  • Sequential parts in a stack will be connected with a stiff, but weak connection to add even more stiffness and counteract wobble
• Stiffen interstage connections
  • Parts connected to a decoupler will be connected to each other, reducing flex at the connection to reasonable levels
• Stiffen launch clamp connections
  • Less vehicle movement on vessel initialization
  • Warning: may cause spontaneous rocket disintegration if rocket is too large and over-constrained (far too many launch clamps; their connections will fight each other and give rise to phantom forces)
• Option to make connections fail at lower forces to maintain difficulty in launching

More documentation and changelog available in the README file.

Download v.3.4.0 from GitHub!

Also available from CKAN

Licensed under GNU GPL v3

 

Changelog

Spoiler

v3.4.0
      Features
      @siimav implemented all these great features
      --Recompile for use in all KSP versions from 1.3.x through 1.7.x
      --Launch Clamps can now be set to completely rigid
      --Removed compatibility checker
v3.3.5
      Features
      --If physics jolts cause a vessel with launch clamps to shift out of PRELAUNCH then put it back in PRELAUNCH. (and reset launch / MET timers)

v3.3.4
      Features
      --Recompile against KSP 1.3, ensure CompatChecker compatibility with 1.3 

v3.3.3  
	Features  
	--Recompile against KSP 1.3, ensure CompatChecker compatibility with 1.3  

v3.3.2  
	Bugfixes
	--Fix multijoints breaking IR joints and any other exempted parts from moving  

v3.3.1  
	Bugfixes  
	--Fix a critical bug involving unphysical forces applied to vessels on load / unload of other vessels and SOI switches  

v3.3.0  
	Features  
	--Recompile to fix for KSP 1.2  
	--Update method of handling multi-part-joints to ensure compatibility with Konstruction mod  
	--Removal of old symmetry-based multi-part stabilization due to ineffectiveness in all situations to reduce overhead  
	--Implementation of new vessel-part-tree leaf-based stabilization for greater stability on space stations and other convoluted shapes  

v3.2.0
	Features  
	--Recompile to ensure KSP 1.1.3 compatibility  
	--Change multi-part-joint system to stabilize space stations and similar vehicles with very large masses connected by very flexy parts  

v3.1.7  
	Features  
	--Recompile to ensure KSP 1.1.2 compatibility, especially within CompatibilityChecker utility  

v3.1.6  
	Features  
	--Update to ensure KSP 1.1.1 compatibility  
	--Minor optimization in joint setups  
	--Remove B9 pWings from stiffening exemption, as it is unnecessary  

v3.1.5  
	Features  
	--Updated to be compatible with KSP 1.1  
	--Very minor efficiency improvements in physics easing and stiffening of joints  
	--Fully exempt EVAs from all KJR effects  
	--Update config parameters to function with stock fixing of never-breakable joints bug  

v3.1.4  
Misc  
--Fixed issue with .version file and compatible KSP versions

v3.1.3
Features
--Update for KSP 1.0

v3.1.2
Features  
--Added code to slightly stiffen connections between symmetrically-connected parts attached to a central part; should reduce some physics weirdness

BugFixes  
--Fixed issue where undocking was impossible.

v3.1.1
BugFixes  
--Fixed a serious lock-to-worldspace issue involving multipart joints and physicsless parts

v3.1  
Features  
--Set multipart joints to account for large mass ratios in choosing which parts to join  
--Set Decoupler Stiffenning to require the connection of immediate decoupler children to stiffen things even further

BugFixes  
--Fixed a decoupling issues with multipart joints  
--Fixed multipart joint lock-to-worldspace issues  
--Fixed some issues on loading very large, heavy parts

v3.0.1
 BugFixes
--Fix some issues involving multipart joints
--More null checking for situations that shouldn't happen, but might

v3.0
Features  
--MultiPart joints: weak, but stiff connections along a stack that will add even more stiffness without making the connection cheatingly strong  
--Proper, guaranteed application of stiffened properties, regardless of stock joint parameters  
--Updated default config values for greater sanity  
--Refactoring of code for sanity

BugFixes
--Longstanding issue with radially-attached parts that were larger than their parent are now fixed  
--Many NREs from bad events or bad states now avoided

v2.4.5
Features
--KSP 0.90 compatibility
--Include some extra checks to prevent errors from occurring

v2.4.4
Features
--KSP 0.25 compatibility  
--Update CompatibilityChecker  
--Shutdown functionality if CompatibilityChecker returns warnings

v2.4.3
--0.24.2 compatibility

v2.4.2
--0.24.1 compatibility

v2.4.1
Bugfixes:
--Included JsonFx.dll, which is required by ModStats
--Relabeled ModStatistics.dll to allow simple overwriting for ModStats updates
--Fixed buttons being added to toolbar after each flight

v2.4
Features
--Ensured compatibility with KSP v0.24

v2.3
Features
--Updated attach node reinforcement to use properties closer to stock joint performance, but stiffer.
--Decoupler and clamp stiffening increased in strength for use in Real Solar System
--Removed unused config values

v2.2
Features
--Updated to function with KSP ARM Patch (KSP 0.23.5)
--Removed inertia tensor fix, as it is now stock
--Main stiffening / strengthening is now disabled by default due to stock joint improvements
--Decoupler stiffening is now disabled by default due to stock joint improvements

Bugfixes:
--Vessels can no longer become permanently indestructible

v2.1
Features
--Reduced extent of decoupler stiffening joint creation; this should reduce physics overhead
--Code refactoring for additional performance gains
--Removed physics easing effect on inertia tensors; was unnecessary and added more overhead
--Workaround for the stock "Launch Clamps shift on the pad and overstress your ship" bug that is particularly noticeable with RSS
--Clamp connections are stiffer; now allowed by above workaround

Bugfixes
--KAS struts no longer break on load


v2.0
Features
--Full release of proper inertia tensors!  Massive parts will feel more massive.
--Full release of greater physics easing!  Landed and pre-launch crafts will have gravitational, centrifugal and coriolis forces slowly added to them, reducing the initial physics jerk tremendously
--Launch clamps are now much stiffer when connected to more-massive-than-stock mod parts
--Tightened up default joint settings more
--Decoupler Stiffening Extension will now extend one part further if it's final part is much less massive than its parent / child part
--Added Majiir's CompatibilityChecker; this will simply warn the user if they are not using a compatible version of KSP

Bugfixes
--Fixed an issue where joints were not strengthened during the physics easing


v2.0x2
Features
--Added more elaborate physics easing; joints are given wide range to flex that are then tightened up and gravitational + rotating ref frame forces are cancelled out to allow internal joint stresses to be resolved prior to loading the rocket
--Tightened up the default joint settings a lot

Bugfixes
--Fixed an issue where non-zero angular limits would force parts to be oriented in the wrong direction.


v2.0x1
Features
--Fixed part inertia tensors; heavy, large objects should now "feel" more massive and their connections should behave better.  Thanks to a.g. for finding this one.
--Launch Clamps are slightly stiffer
--Removed improper stiffening for stretchy tanks that was added in v1.7; given the ability to stretch stretchy tanks, this shouldn't be necessary

Bugfixes
--Fixed an issue where non-zero angular limits would force parts to be oriented in the wrong direction.

v1.7
Features
--Added ability to calculate connection area based on volume instead of connection area; intended to handle very, very large vehicles that the standard settings cannot
--Some more tweaks to the default joint parameters to stiffen things
--Extra stiffening for stretchy tanks; a better solution is in the works, but this should help for RSS

Bugfixes
--Fixed an issue where decoupling could lead to extra stiffening joints being deleted from non-staged decouplers during decoupling / partial crashing

v1.6
Features
--BreakStrengthPerUnitArea will not override large breakForces; this is intended for building things using I-beams and structural elements

Bugfixes
--Fixed decoupler-dockingport combination parts from causing strange disassembly when undocking

v1.5
Features
--Updated to KSP 0.23
--Joint breaking strength can now be set to be dependent on connection area, so large part connections can have realistically large strength; on by default
--Vessels are further strengthened for the first 30 physics frames after coming off rails or loading; this helps prevent jitters during intialization from breaking things apart

Bugfixes:
--Fixed launch clamps not being clamped to the ground after staging
--Fixed an issue where the Kraken would throw launchpads at craft in orbit

v1.4.2
Bugfixes
--Fixed an issue that would allow more wobble to exist than it should have
--General tweaks to reduce wobbling further

v1.4.1
Bugfixes
--Fixed an issue where maximum joint forces were calculated incorrectly
--Fixed an issue where docking could cause exceptions to be thrown and cause lag

v1.4
Features
--Changed calculation of surface-attached connection area to be more accurate

Bugfixes
--Fixed an issue where lots of wobble would occur between stack-attached parts of very different sizes

v1.3
Features
--Better solution for failure to apply decoupler ejection forces
--Will not apply stiffening to parts below a given mass; mass can be changed in config
--Properly updates on docking

Bugfixes
--Fixed a serious issue where launch clamps would lock the ship to the surface

v1.2
Features
--Workaround for stock KSP bug where struts would prevent decoupler ejection forces from being applied

Tweaks
--Reduced default maxForceFactors to be more reasonable levels

BugFixes
--Fixed serious issue where struts would not properly disconnect
--Fixed serious issue where decouplers would not function properly


v1.1
Features
--Stiffness of joint no longer erroneously dependent on breakForce / breakTorque
--Decoupler stiffening function made more comprehensive

BugFixes
--Fixed an issue where radial decouplers would not be affected by by further decoupler stiffening
--Fixed an issue where decoupler further stiffening would cause Nulls to be thrown when attached to physics-disabled parts
--Fixed an issue where procedural fairings would be locked to the rocket
--Fixed an issue where Infernal Robotics parts would not function
--Temporary stopgap measure: stiffening not applied to pWings to prevent ultra-flexy wings

Known Issues
--Decouplers create no detach force with extra decoupler stiffening enabled
    Same issues as strut attachment bug

v1.0
Release

 

Edited April 25, 2019 by pap1723
CKAN

[Red Stapler]

Thank you @pap1723 for clarifying and creating this new thread! 

Can you also speed up time so I can get home from work and try this latest version out?  

 

[iGGnitE]

Nice! Works absolutely perfectly so far in ksp 1.6.1!

[MikeO89]

This thread should be linked to CKAN instead of the original thread which has become a train wreck.

[RaiderMan]

-snort- I actually GO by the name trayna'wrek in another game..so that comment by @MikeO89 is kinda funny to me.

that said..I'll be testing this version of KJR on my game soon.

Edited April 26, 2019 by RaiderMan

[Red Stapler]

Tested last night and confirmed all good on 1.6.1.   No bendies.   Tnx again!

 

[zer0Kerbal]

seems to be working just fine in 1.7. ymmv

[MikeO89]

This works perfect. Glad to see original thread closed (it had turned into a mess). Now individual fork makers can do their own thing separately and following along now has just become much easier (for me anyway). This one is continuing from the original. That's good enough for me knowing this mod is going to hang around.

Edited April 28, 2019 by MikeO89

[kcs123]

meirumeiru aka @Rudolf Meier is listed as contributor to this fork. But, does all of his pull requests are included in this fork of KJR ? It is hard to tell from commits what was included and what not.

One of important improvement was to make KJR aware interface, to make it possible for other mods to "tell" KJR to avoid struts on certain parts (IR moving parts for example). It was made in that way to avoid editing XML config file in future, because not all of users are familiar with editing XML and if each other mod that use KJR distribute it's own version of XML it can also create mess on long run with larga amount of mods. There is other improvements as well, to improve performance etc. Some other forks of KJR have those included, like Lisias's fork or one from linuxgamer.

[siimav]

4 hours ago, kcs123 said:

meirumeiru aka @Rudolf Meier is listed as contributor to this fork. But, does all of his pull requests are included in this fork of KJR ? It is hard to tell from commits what was included and what not.

One of important improvement was to make KJR aware interface, to make it possible for other mods to "tell" KJR to avoid struts on certain parts (IR moving parts for example). It was made in that way to avoid editing XML config file in future, because not all of users are familiar with editing XML and if each other mod that use KJR distribute it's own version of XML it can also create mess on long run with larga amount of mods. There is other improvements as well, to improve performance etc. Some other forks of KJR have those included, like Lisias's fork or one from linuxgamer.

No, KSP-RO fork has neither the KJR-aware additions or the alleged performance improvements because it is based directly on Ferram's work. Meirumeiru did do a PR to Ferram's original KJR repo but unfortunately that PR was a bit of a mess and touched things that it shouldn't have. Ferram did merge it at first but then probably found out that the PR is not clean enough and then reverted the changes. This explains why meirumeiru is listed under the contributors on GitHub.

Edited April 28, 2019 by siimav

[Rudolf Meier]

55 minutes ago, kcs123 said:

meirumeiru aka @Rudolf Meier is listed as contributor to this fork. ...

I don't know if something of my code is inside there... but for all those who are interested... in about a week I should have a new version online in which I try to solve problems we had in the past (e.g. performance issues when using it).

 

[kcs123]

5 hours ago, siimav said:

No, KSP-RO fork has neither the KJR-aware additions or the alleged performance improvements because it is based directly on Ferram's work. Meirumeiru did do a PR to Ferram's original KJR repo but unfortunately that PR was a bit of a mess and touched things that it shouldn't have. Ferram did merge it at first but then probably found out that the PR is not clean enough and then reverted the changes. This explains why meirumeiru is listed under the contributors on GitHub.

 

5 hours ago, Rudolf Meier said:

I don't know if something of my code is inside there... but for all those who are interested... in about a week I should have a new version online in which I try to solve problems we had in the past (e.g. performance issues when using it).

 

Thanks for reply, that clarify messy old KJR thread a bit. So, as summary of available KJR forks, community can use:

• KJR fork from this thread, direct continuation of Ferram's work, recompiled for latest KSP
  New features from changelog, after KSP 1.3.x:
  --Launch Clamps can now be set to completely rigid
  --If physics jolts cause a vessel with launch clamps to shift out of PRELAUNCH then put it back in PRELAUNCH. (and reset launch / MET timers)
  -- drawback is that may not work properly without additional changes in config file with WIP IR Next mod
• KJR fork from linuxgamer that contain changes made by Rudolf Meier with improvements and support for IR next mod, with drawback that is slightly obsolete by now
• KJR fork from Lisias that contain changes made by Rudolf Meier, along with some other improvement but with drawback that it also have new additional dependency for KSPe that some people have trouble to install properly
• KJR fork from Rudolf Meier that is not available yet to public for latest KSP, but should be within a week or so, with additional improvements for IR next and other quality of life changes to make life easier for other moders

Hope that this info will help others as well as reminder for me, for current status of KJR mod and available forks.

 

[pap1723]

This has gotten a little crazy and out of hand with all the forks. Does someone want to officially take over the project? It will just be causing confusion in the future. 

[MikeO89]

3 hours ago, pap1723 said:

This has gotten a little crazy and out of hand with all the forks. Does someone want to officially take over the project? It will just be causing confusion in the future. 

For me the only confusion was with the forks. The code in this version is golden, no need need to fix what was never broken to begin with. Please don't give this away or we are going to be back in the same boat as the original thread had become. This thread will settle down as people begin to figure stuff out (all caused by the confusion that had developed in the original thread). Keep this one and let others develop their own stuff and people can choose what they want to use. The name "Kerbal Joint Reinforcement Continued" says it all. That's all I need to know.

Edited April 29, 2019 by MikeO89

[Rudolf Meier]

7 hours ago, pap1723 said:

This has gotten a little crazy and out of hand with all the forks. Does someone want to officially take over the project? It will just be causing confusion in the future. 

I will definitely build a new version of KJR. I'm not maintaining the old code or just make it compatible to new KSP versions but really build a new version of KJR and replace a lot of the code, hence the "Next" in the name of my project.

 

3 hours ago, MikeO89 said:

The code in this version is golden, no need need to fix what was never broken ...

That's something that I see completely differently.

[Stone Blue]

11 hours ago, MikeO89 said:

For me the only confusion was with the forks. The code in this version is golden, no need need to fix what was never broken to begin with. Please don't give this away or we are going to be back in the same boat as the original thread had become. This thread will settle down as people begin to figure stuff out (all caused by the confusion that had developed in the original thread). Keep this one and let others develop their own stuff and people can choose what they want to use. The name "Kerbal Joint Reinforcement Continued" says it all. That's all I need to know.

100% all this :point_up:

[kcs123]

11 hours ago, MikeO89 said:

For me the only confusion was with the forks. The code in this version is golden, no need need to fix what was never broken to begin with.

That is reason why I have listed (almost) all of KJR forks, to clear up confusion what is what. And I have to disagree with your opinion that this version of KJR is "golden" and that is not necessary to fix anything. You may not come across with any issue, but that does not mean that some issue does not exist.

15 hours ago, pap1723 said:

This has gotten a little crazy and out of hand with all the forks. Does someone want to officially take over the project? It will just be causing confusion in the future. 

I agree on that. A lot of regular users would not figure out what exact fork they use and might ended up seeking for help in wrong KJR thread. I'm not the one who should tell which one of moders should take over project "officialy", that should be discussed between each of moders who have created their own fork. It will be much less confusion in future for whole community if only one version is maintained with accepting of PR from other moders.

Personaly, I would vote for Rudolf's fork, since it contain a lot of improvements and should be easier to maintain in future. Though, it still can't be done just yet, since it is not yet available for public usage.

[MikeO89]

Quote

Quote

Personally, I would vote for Rudolf's fork, since it contain a lot of improvements and should be easier to maintain in future. Though, it still can't be done just yet, since it is not yet available for public usage.

 

I'm not as brave as you. KJR has been tested throughout eons, is tried and true, works perfect, yet you would still toss it in favor of a mod that is not even out yet nor been tested. I'm going to stick with this one until I have a reason not to. Everything is rock solid with it for me and I don't have to think about it.

Edited April 29, 2019 by MikeO89

[Lisias]

21 hours ago, pap1723 said:

This has gotten a little crazy and out of hand with all the forks. Does someone want to officially take over the project? It will just be causing confusion in the future. 

As was EXPLICITLY said on the original fork:

THERE`S NOT AN OFFICIAL VERSION FOR AN ADD'ON. Choose a provider that you trust, and stick with he/she. The license is the rule that applies to everyone, and Forum Policies are the one the rules us here.

 

On 4/26/2019 at 4:34 AM, MikeO89 said:

This thread should be linked to CKAN instead of the original thread which has become a train wreck.

CKAN's entry for "Kerbal Joint Reinforcement" is under Ferram4's copyright. It would be a misrepresentation pinpointing "Kerbal Joint Reinforcement" to any other thread than Ferram4's one, unless he explicitly authorizes it. And he didn't. And this would make the license NULL and VOID to the fork's maintainer, what would not only be a serious legal problem, but by Forum Rules would make this thread deleted/blocked/whatever.

"Kerbal Joint Reinforcement Continued" is pointing this one, right? It's enough.

 

— — 

That said, how about avoiding polluting this thread with unrelated issues? This is about "Kerbal Joint Reinforcement Continued" - an "official" fork so official as mine, by the way. I just choose not to publish it on the Forum as there's a better man available for the job.  

I would recommend to transfer all discussion unrelated to "Kerbal Joint Reinforcement Continued" to another thread - perhaps that one about Copyrights? But it's up to the thread's owner to decide.

Edited April 29, 2019 by Lisias
Hit 'save" too soon.

[MikeO89]

Quote

Kerbal Joint Reinforcement Continued" is pointing this one, right? It's enough.

 

No it's not. Kerbal Joint Reinforcement Continued on CKAN is still pointing to original thread. It's should be pointing here.

Edited April 29, 2019 by MikeO89

[kcs123]

4 minutes ago, MikeO89 said:

No it's not. Kerbal Joint Reinforcement Continued on CKCAN is still pointing to original thread. It's should be pointing here.

You are right on this one. But, it is probably bug with CKAN metadata, probably leftover of copy-paste and editing metadata from old KJR fork. Something that is not big deal, but should be fixed regardless when whoever maintain metadata files grab some free time for it.

[strudo76]

So is there a way to specify "continued" as a replacement for ferram4's KJR on CKAN?

At the moment I've just set up a 1.3.1/RSS/RO/RP1 game that I was ready to play. Now this is released I thought I might as well use this one, however I can't uninstall ferram4's KJR in CKAN as it is a dependency of RP1, which in turn has a dependency on RO, which in turn has dependencies on RealFuels and RealPlume, and none of those recognise "continued" as satisfying that dependency chain.

Is it a case of contacting the author of RP1 to add "continued" as a dependency, or is it something you guys can take care of? I assume the RO team gets along with the RP1 team quite well?

Currently I have the "continued" version 3.4 manually installed over the top of ferram4's 3.3.3 version, but I don't know if that's a working configuration as I haven't started playing yet, and I don't know if it will pose any problems to do a change over going forward.

What are my options?

Thanks

[MikeO89]

You might have to get ckan to help on this one. Post in their thread and someone will direct you to post to open a support ticket. Someone there will quickly respond to you, hopefully for a solution for ckan to remove the original without effecting the other 'dependency' mods and then for ckan to install the latest. The boys over at ckan are pretty good with stuff like this. No problem overwriting but then you will have to continue to update it manually outside of ckan.

Edited April 30, 2019 by MikeO89

[siimav]

7 hours ago, strudo76 said:

So is there a way to specify "continued" as a replacement for ferram4's KJR on CKAN?

At the moment I've just set up a 1.3.1/RSS/RO/RP1 game that I was ready to play. Now this is released I thought I might as well use this one, however I can't uninstall ferram4's KJR in CKAN as it is a dependency of RP1, which in turn has a dependency on RO, which in turn has dependencies on RealFuels and RealPlume, and none of those recognise "continued" as satisfying that dependency chain.

Is it a case of contacting the author of RP1 to add "continued" as a dependency, or is it something you guys can take care of? I assume the RO team gets along with the RP1 team quite well?

Currently I have the "continued" version 3.4 manually installed over the top of ferram4's 3.3.3 version, but I don't know if that's a working configuration as I haven't started playing yet, and I don't know if it will pose any problems to do a change over going forward.

What are my options?

Thanks

If you overwrote both the xml config file and the DLL then it should work just fine.

[GoAHead]

hi there

motors in the new expansion do not work with KJR installed

Tested:

Vanilla => worked
Installed KJR => motor doesn't rotate

hopefully this gets an update soon :-)

thx

greets

Edited May 31, 2019 by GoAHead