Kerbal Joint Reinforcement - Next

[dudey229]

So i am using this with canada arm.  I am on version 1.9 and the arm works fully in the VAB but not out of it.

[ThRodrigues]

 

Hello, I have a problem that has nothing to do with this mod, but as I already used it to try to solve it (and it didn't work), so I came here just to know if there is any light at the end of this tunnel because the subject involves similar physics.

When trying to build a helicopter rotor with a swashplate using the robotic parts, I realized that they do not behave as they should when the power of their engines is low or 0kN, as they do not move uniformly / constantly when they suffer an equal external force in each of them (pushing or pulling) even if they are built with symmetry, because as they have no power they move as the external force determines.
  I made a video to explain better: 

 

What I want is to know if it is possible to overcome this problem and be able to build a rotor with a decent swashplate that allows perfect control of an aircraft, that is, it is me who is doing everything / something wrong.

 

Translated via google.

 

Edited August 16, 2020 by ThRodrigues

[steve_v]

On 5/4/2019 at 10:20 AM, Rudolf Meier said:

This improves the the performance of your game and should provide better and more stable results.

Uhh, erm, well, ahh, that's not quite what I'm seeing in game...

KSP 1.10.1, 553 part random "battleship" from KerbalX (lots of surface attached wing & structural parts) sitting (half) on the launchpad.
Stock: 49FPS
+ KJRc 3.5.1: 41FPS
+ KJRn 4.1.15: 32FPS

I thought you were making fewer joints, and that should improve performance, no? Any idea what's going on?

[Lisias]

On 8/23/2020 at 9:06 AM, steve_v said:

Uhh, erm, well, ahh, that's not quite what I'm seeing in game...

KSP 1.10.1, 553 part random "battleship" from KerbalX (lots of surface attached wing & structural parts) sitting (half) on the launchpad.
Stock: 49FPS
+ KJRc 3.5.1: 41FPS
+ KJRn 4.1.15: 32FPS

I thought you were making fewer joints, and that should improve performance, no? Any idea what's going on?

One size does not fits all.  You are benchmarking your machine too, and its way beefy than the average gamer is using.

Differences on CPU architecture (number of cores and how they share the cache - no to mention the need to mitigate or not Spectre et all), memory controller and GPU will heavily influence the results. You need to benchmark things in multiple machines in order to have figures to be shown to the general public, instead of people that uses what you use.

KSP also switched physics engines, and what could be sound on the previous one could bork heavily on the current.

Not to mention the requirement of work together Infernal Robotics.

On Feb 2019 I made some tests on my old Potato (never reproduced it on the new Potato), and at that time the current KJR/N on a i5 2520M  with shared graphics, and the improvement on the performance was noticeable to the point it's possible to to detect it easily on Youtube.

http://ksp.lisias.net/showcase/add-ons/IRNext-KJRL/2019-0219_Performance-Test/screenshot40#main-img

 

[steve_v]

1 hour ago, Lisias said:

its way beefy than the average gamer is using

Eh? It's a 7 year old CPU... Is the "average gamer" running KSP on a z80 or something?

1 hour ago, Lisias said:

Differences on CPU architecture (number of cores and how they share the cache - no to mention the need to mitigate or not Spectre et all), memory controller and GPU will heavily influence the results.

Well... I guess I do have mitigations disabled on this box, and it has slightly nuts memory bandwidth for it's age... But still, 7 year old CPU.
Is KJRn using some fandangled new CPU instructions KJRc isn't? AVX2 math all over the place? Custom asm86 core? Magic code that runs slower with retpoline off?.. I thought not.
So why the discrepancy between the forks, on the same not particularly unusual commodity hardware?

 

1 hour ago, Lisias said:

You need to benchmark things in multiple machines in order to have figures to be shown to the general public

I'm not really interested in numbers to show to the general public TBH, otherwise I would have done more extensive benchmarking.
What I am interested in is why, in the specific scenario I tested with, KJRn performs significantly worse than KJRc.
FWIW I actually see similar results in lower part-count general gameplay as well (and have for several KSP versions at that), but I didn't mention it, because uncontrolled benchmarks with a bunch of other mods installed are kinda useless.

Telling me that all benchmarks are invalid unless they cover every possible configuration is pretty darn unhelpful TBH. If that was the case, any and all claims to improved performance (as in the OP) would be equally invalid, and we'd have to just throw our hands up and abandon testing as an impossibly time-consuming task.
 

1 hour ago, Lisias said:

KSP also switched physics engines, and what could be sound on the previous one could bork heavily on the current.

Indeed. If that's the case, it might be time to revisit the supposed performance improvements in KJRn... Which is kinda why I posted those numbers to begin with.

1 hour ago, Lisias said:

Not to mention the requirement of work together Infernal Robotics.

If the cost of dynamically detecting robotics parts is ~9FPS, I'll take the ugly old manual blacklist method any day.
 

1 hour ago, Lisias said:

the improvement on the performance was noticeable to the point it's possible to to detect it easily on Youtube.

That's all well and good, and I'm sure it was faster for you at that time. My question was: Why is it not faster for me, at this time? Is it broken on KSP1.10.1? Does it need some work for game engine changes? What?

The OP claims general performance improvements, not "May be faster on particular hardware when the wind is blowing north-east, for a limited time only", or "Designed to perform better with KSP 1.7.x on Macbooks"...
Yet as of right now, on my rig, it imposes double the performance penalty of the old version. Something is clearly up.

If I'm just going to be brushed of with "stuff changes" or the old favourite "It must be your PC", then I'm bound to assume KJRn is now broken as far as it's stated goals, and go back to Ferram's demonstrably better performing implementation.
I don't want to, but the numbers don't lie, and an extra 9FPS at 550 parts is not something I'm going to turn down.

 

Ed. On a completely unrelated topic, I finally got around to properly exploring your website... It's quite interesting.

 

Edited August 26, 2020 by steve_v

[Lisias]

7 hours ago, steve_v said:

Eh? It's a 7 year old CPU... Is the "average gamer" running KSP on a z80 or something?

Ouch... wrong steve! Sorry!

 

7 hours ago, steve_v said:

Well... I guess I do have mitigations disabled on this box, and it has slightly nuts memory bandwidth for it's age... But still, 7 year old CPU.

Check the genkernel options (i think I remember you use gentoo) you used to compile the kernel - I think they are on by default. But I don't remember either.

On my old Potato, when Apple updated the firmware before declaring it EoL, the performance on it plummeted on KSP 1.7. KSP 1.3.1 doesnt, and it's still the faster KSP to go on an i5-2520M apparently.

Curiously, KSP 1.8 and newer made things slightly better on that thing.

Now on my less old i7-3615QM, things inverted again. KSP 1.7 is way faster then 1.10 to the point I'm going back to 1.7 for my day-to-day gaming.

Why? Don't have a clue, dude.

 

7 hours ago, steve_v said:

Is KJRn using some fandangled new CPU instructions KJRc isn't? AVX2 math all over the place? Custom asm86 core? Magic code that runs slower with retpoline off?.. I thought not.

It's about how Unity does multithreading, and how the physics engine is pipelined.

Nothing beats Unity5 on my older rig. Why? Because it have the hyperthreading cripped by Apple to mitigate the Intel's idiocy. So anything that is optimized for multicores will flop [and Unity5 is optimised for single cores].

Similarly, data intensive code will hinder multicores with small and shared L0 caches - because the cache will be flushed all the time, hurting all the cores.

Multichannel memory access will perform better then singlenchannel on some algorithms, while will make no difference on others.

And so goes on.

 

7 hours ago, steve_v said:

So why the discrepancy between the forks, on the same not particularly unusual commodity hardware?

On what KSP version? Better, on what Unity version?

The answer will be different for each one we use in KSP: 5, 2017 and 2019.

See above for the reason.

For a quick&dirty example. Let's talk about loop unrolling from the GCC optimizations bag of tricks. Do you know that loop unrolling can make the code slower on the same CPU depending the size of the L2 cache? On pretty small caches, the taxing of RAM access will outgrow the savings from avoiding break the pipelines with branches.

Same thing: code optimised for newer CPUs will perform worse on older ones.

 

7 hours ago, steve_v said:

I'm not really interested in numbers to show to the general public TBH, otherwise I would have done more extensive benchmarking.

Fair enough.

 

7 hours ago, steve_v said:

What I am interested in is why, in the specific scenario I tested with, KJRn performs significantly worse than KJRc.

So please describe your scenario, otherwise your numbers are meaningles to anyone else.

I don't even know the KSP version you are using, besides guessing 1.10.

Now I need the CPU model, how many memory, the chipset (are you using dual or single channel?) and the GPU (shared memory or discrete graphics?).

The current physics engine optimizations appears to be the main factor here. But how to know without comparing hw specs?

 

7 hours ago, steve_v said:

FWIW I actually see similar results in lower part-count general gameplay as well (and have for several KSP versions at that), but I didn't mention it, because uncontrolled benchmarks with a bunch of other mods installed are kinda useless.

Telling me that all benchmarks are invalid unless they cover every possible configuration is pretty darn unhelpful TBH.

You answered yourself. Without a baseline, they are just numbers thrown on the wind.

The fact is that the last time I compared KJR/N with KJR, the later made my rig perform so badly that I could not even complete some tests on more complicated crafts. Less then 2 frames per second, while Next was delivering me 10 or 12 on the same craft. 

Tests made in KSP 1.6.1 on i5-2520M with dual channel memory active and shared graphics.

 

7 hours ago, steve_v said:

Indeed. If that's the case, it might be time to revisit the supposed performance improvements in KJRn... Which is kinda why I posted those numbers to begin with.

If the cost of dynamically detecting robotics parts is ~9FPS, I'll take the ugly old manual blacklist method any day.

The cost of not detecting robotics is not being able to use them. See my second video using the KJR, the parts just don't move.

You need to disable the joint, move the part a bit, then enable the joint again on every fixed update.

So the choice is not to blacklist something or not, but to be able to use the thing or not.

 

7 hours ago, steve_v said:

That's all well and good, and I'm sure it was faster for you at that time. My question was: Why is it not faster for me, at this time? Is it broken on KSP1.10.1? Does it need some work for game engine changes? What?

Without further information, and more benchmarks on different machines with different KSP versions, we will not know.

 

7 hours ago, steve_v said:

The OP claims general performance improvements, not "May be faster on particular hardware when the wind is blowing north-east, for a limited time only", or "Designed to perform better with KSP 1.7.x on Macbooks"...

Check the date of the claim. It was true at that time. And more than one confirmed the claim at the time. Me included.

It's obvious that something changed, but I think it's unreasonnable call bogus claims made under different times on a different environment.

Granted, the OP doesn't states that neither.

 

7 hours ago, steve_v said:

Yet as of right now, on my rig, it imposes double the performance penalty of the old version. Something is clearly up.

If I'm just going to be brushed of with "stuff changes" or the old favourite "It must be your PC", 

But IT IS YOUR PC. Because on mine, things performed differently.

The magic happens when we realise exactly what changes from your machine to mine so we can try to nail the problem and try a fix.

The thing is not working for you. Perhaps will not work for others people too. But the thing worked as intended to me and to a lot of people before, and perhaps it's still working for some guys.

 

7 hours ago, steve_v said:

 then I'm bound to assume KJRn is now broken as far as it's stated goals, and go back to Ferram's demonstrably better performing implementation.

As long you dont use robotics. ferram's locks everything, including robotics. And if you blacklist robotics, they will wobble and so why use KJR?

on that second benchmark of mine, KJR (original) not only rendered the robotics useless, but also halved the (already limited) frame rate. On KSP 1.6.1 running at i5-2650M with shared graphics.

-- -- -- POST EDIT -- -- -- 

Did you removed all the auto-struts from the test subject?

Edited August 26, 2020 by Lisias
post edit

[steve_v]

15 hours ago, Lisias said:

Check the genkernel options (i think I remember you use gentoo) you used to compile the kernel - I think they are on by default.

They are, but there's a handy mitigations=off kernel command line switch.
 

15 hours ago, Lisias said:

the performance on it plummeted on KSP 1.7. KSP 1.3.1 doesnt, and it's still the faster KSP to go on an i5-2520M apparently.

Curiously, KSP 1.8 and newer made things slightly better on that thing.

Now on my less old i7-3615QM, things inverted again. KSP 1.7 is way faster then 1.10

Fascinating I'm sure, but you're talking abut the performance of KSP across versions and hardware generations. I'm talking about the performance of KJR forks on the same KSP version and hardware.
 

15 hours ago, Lisias said:

On what KSP version? Better, on what Unity version?

1.10.1, which means Unity 2019.2.2f1 IIRC.
 

15 hours ago, Lisias said:

Do you know that loop unrolling can make the code slower on the same CPU depending the size of the L2 cache?

No excrement. I've been running Gentoo since 2003, and LFS before that, so I'm quite familiar with compiler optimisations (and the pitfalls of such). What do GCC optimisations have to do with KJR?
 

15 hours ago, Lisias said:

So please describe your scenario, otherwise your numbers are meaningles to anyone else.

I don't even know the KSP version you are using, besides guessing 1.10.

Both of these are in my initial post on the subject:

On 8/24/2020 at 12:06 AM, steve_v said:

KSP 1.10.1, 553 part random "battleship" from KerbalX (lots of surface attached wing & structural parts) sitting (half) on the launchpad.

I can flick you the craft file if you want, as well as any logs or whatever else. You didn't ask.
 

15 hours ago, Lisias said:

Now I need the CPU model, how many memory, the chipset (are you using dual or single channel?) and the GPU (shared memory or discrete graphics?).

I7 4960X @ 4.3GHz all cores, no turbo limits, HT on.
32GB DDR3-1600CL9.
X79.
Quad channel.
GTX 1070 8GB discrete.
 

15 hours ago, Lisias said:

The cost of not detecting robotics is not being able to use them. See my second video using the KJR, the parts just don't move.

Starwaster's KJRc build from the KSP-RO repo (the only 3.5.1 I am aware of)  works fine with stock robotics. I haven't used IR in years.
 

16 hours ago, Lisias said:

It's obvious that something changed

Which is... Why I posted my results in the first place.
 

16 hours ago, Lisias said:

I think it's unreasonnable call bogus claims made under different times on a different environment.

It is entirely reasonable to call them no longer valid if benchmarks in the current game version indicate so.
 

16 hours ago, Lisias said:

As long you dont use robotics. ferram's locks everything, including robotics. And if you blacklist robotics, they will wobble and so why use KJR?

Like I said, it works for me with stock robotics. I haven't specifically tested for robotic joints being wobbly, but if they are it's a fair trade for the performance differential.
I doubt robotics has anything to do with it anyway, as none of the craft I benched performance on have any robotic parts at all.
 

16 hours ago, Lisias said:

Did you removed all the auto-struts from the test subject?

No. Tests with KJRc and KJRn are with identical unmolested craft from KerbalX. They may have autostruts, but given the wet-noodle behaviour without KJR (either fork) I doubt it.
I guess autostruts could be causing problems, but then they'd be causing problems for both KJR forks.

 

[Lisias]

15 minutes ago, steve_v said:

I7 4960X @ 4.3GHz all cores, no turbo limits, HT on.
32GB DDR3-1600CL9.
X79.
Quad channel.
GTX 1070 8GB discrete.

Definitively, not a potato. There's something really smelly around here.

Well, I put myself on a corner: now I need to redo my benchmarks. I wish I hadn't lost the instalment I used on the previous one, I would like to reuse that craft on this one.

[steve_v]

5 hours ago, Lisias said:

I would like to reuse that craft on this one.

So would I. I hit up KerbalX and sorted by part count for this, since I didn't set out to bench KJR specifically and just went for "things that will thrash the physics sim". Finding KJRn as the biggest perf hog was a  surprise.
It's entirely possible that my results are skewed by this indiscriminate test-craft selection, as they are all pretty heavy on surface attachment. If you have a craft file more representative of normal (i.e. not building ships) gameplay I'm happy to try it.

Edited August 27, 2020 by steve_v

[Daniel Prates]

Sorry if this has been asked before, but KJR CONTINUED and KJR NEXT? Are they the same thing? Is one more suited to an specific need and vice versa? Is one of them "better"? Why are there two? Do they "compete" somehow?

Will be asking the same thing too in the other mod's thread. 

[kcs123]

20 hours ago, Daniel Prates said:

Sorry if this has been asked before, but KJR CONTINUED and KJR NEXT? Are they the same thing? Is one more suited to an specific need and vice versa? Is one of them "better"? Why are there two? Do they "compete" somehow?

Will be asking the same thing too in the other mod's thread. 

Answer on this question is in OP and in several posts on first few pages of this thread. @Lisiashave already answered in other thread in detailed manner. @Rudolf Meieris not so active here, so it may take a while until you got "official" answer from author. I don't know if there is anything more to add on this topic that is not already answered:

There is even more details in other posts, but you should search them for yourself, it is not that there is too much pages in this thread.

[Atlas Gaming]

On 6/21/2020 at 1:50 PM, dudey229 said:

So i am using this with canada arm.  I am on version 1.9 and the arm works fully in the VAB but not out of it.

Ya I'm also having an issue with canada arm wigging out.. for instance hen connected to a mall vessel in space, and attacking to a larger one... the arm starts to vibrate and 'swing' the much larger ship around like it has no mass until a bunch of things break and explode.

[theleg]

Does this work with ksp 1.11 

[eberkain]

1 hour ago, theleg said:

Does this work with ksp 1.11 

seems to be fine for me

[Gariba]

On 12/23/2020 at 10:23 AM, theleg said:

Does this work with ksp 1.11 

The only issue I found so far is when using the EVA construction feature. When removing a currently attached part, KJR doesn't let go and... well the vessel kinda explodes with the force exerted by your mouse.

[Daniel Prates]

On 12/28/2020 at 1:23 PM, Gariba said:

 the vessel kinda explodes with the force exerted by your mouse.

Freaky.

So KJR next is fine then? KJR continued seems to have stopped working, it does not "reinforce" anything anymore and I seem to have returned to pre-kjr wobblyness.

@Lisiaswe had a conversation about this some time ago. Both versions of kjr were indicated for different situations/users. Seems it is no longer the case.

 

Edited January 7, 2021 by Daniel Prates

[Lisias]

12 minutes ago, Daniel Prates said:

@Lisiaswe had a conversation about this some time ago. Both versions of kjr were indicated for different situations/users. Seems it is no longer the case.

I hope someone fix the Continued (or the original one) so - because both Continued and Next fulfil different roles on the matter....

[eberkain]

I feel like I need a joint reinforcement for the stock robotics parts.  They just have so much slop and wiggle going on its silly. 

[chd]

Is the explodiness problem in 1.11 EVA construction only for -Continued, or does it apply to -Next also? I'm running Next, and did a repair contract just to test. Nothing blew up... but then, maybe it's only an issue with vessels you build, not ones created by a contract, because of how KJR-N works? Totally guessing, but I could see that.

Short version -- running KJR-N with 1.11, what is unsafe to do?

[PocketBrotector]

On 1/26/2021 at 9:10 PM, chd said:

Is the explodiness problem in 1.11 EVA construction only for -Continued, or does it apply to -Next also? I'm running Next, and did a repair contract just to test. Nothing blew up... but then, maybe it's only an issue with vessels you build, not ones created by a contract, because of how KJR-N works? Totally guessing, but I could see that.

I’m also interested in the answer to this. 

I had KJR Continued and it caused mass devastation when trying out 1.11’s Construction mode. I uninstalled it and have been making do with stock autostruts, which are barely adequate at best. But EVA Construction seems to cause harm even with autostruts. 

If KJR Next is better, that would be great. But my attempts to search for discussion of these issues have been failing me...

[chd]

I did complete one repair contract (repair a solar panel on a satellite) running -Next, and nothing bad happened that time, but I haven't done much experimenting beyond that...

[The Aziz]

Well for me the Next version causes some weird effects, including turning off gravity for affected vessel

https://gfycat.com/pl/helpfulsentimentalbluetonguelizard

 

[WhitestWizard]

On 1/27/2021 at 2:10 AM, chd said:

Is the explodiness problem in 1.11 EVA construction only for -Continued, or does it apply to -Next also? I'm running Next, and did a repair contract just to test. Nothing blew up... but then, maybe it's only an issue with vessels you build, not ones created by a contract, because of how KJR-N works? Totally guessing, but I could see that.

Short version -- running KJR-N with 1.11, what is unsafe to do?

Applies to both. Tried both separately and both caused issues with EVA construction.  

[si2504]

how can I improve the strength of joints in KJR? is there anything I can adjust in the config.XML file? unstableness is a very big issue with big rockets and ships in RSS, so much wobble in joints, even with added struts.

[Iggyboo]

So just had my first 1.11 craft Krak'a'sploded using this mod. This happened oddly when I removed a part and put it into cargo storage, but not when a attached the part initially. It also doesn't happen if I just remove the part and leave it floating.

If there is no way to fix it, would there be a way to add a "Enable/Disable" button to it? I removed the mod and I did see a significant jiggle when I stored the part. Also, if this is the "fix" might you just tie the enable and disable to when EVA construction mode is active? I can see a benefit of having a way to manually disable on the fly though.