Rudolf Meier

I think KJR Next is always a good thing to install. I personally think, that playing KSP without KJR is almost impossible. And, sure it adds some load to the game. But that's what autostruts would do too and you need at least one of those things to play the game (it's so unstable otherwise). And the advantage of KJR Next is, that it's an automatic way of stabilizing things and also a very optimized way of doing it. So... I highly recommend it (but only KJR Next... the other versions don't have a great support for moving parts and are overall... not that optimized).

This won't work at all... I don't recommend those beta version. Some of them contain experimental code and only the release is really a good versoin. And KJR 3.3.3 is none of my KJRs. It doesn't work with IR at all. I recommend to do an upgrade to at least 1.4 and use the latest KJR Next and IR Next. For those who don't know why there is this "not before 1.4" requirement. It's because 1.4 did get a new version of Unity. That's a big difference and why support can only be provided for 1.4 and later.

And beside the possible incompatibility with the KSP version it is also possible to see such behaviour if you didn't first remove the folders of KJR before installing the new one. We had situations in the past when users ended up with 2 KJR dlls installed. This then showed similar problems.

... that has been in IR already for a long time

That's also my experience...

Right, now that you mention it I remember that my last rover did fell over all the time and I could stop him from doing it by modifying those values.

I often see it after comming back (loading scene) or after timewarp... but I didn't remark it directly after landing (I say "remark" because it may be there, but I didn't see it... but now I will pay more attention ). But wheels (and landing legs which are wheels) are a constant problem in ksp. That's why I rated this as normal.

And all this KAL-stuff is not "robotics", it is just "animation" in my eyes.

1. That is already in... 2. This could be interesting for Infernal Roboitcs only, but DLC robotics will have problems with that too. That's why I'm currently waiting to see how this develops. But for KJR Next I think there's nothing to do. Because this joint is already reinforced in a way that is strong enough. DLC or no DLC, that's not the question... 1.7.1 and 1.7.2, that's important. They modified parts of it, but I don't see problems with that at the moment. And... KJR Next in the latest versions works with both of them (but can do its job better and form stronger joints in 1.7.2... because of the new event 1.7.2 sends).

well... if it is, then KJR Next cannot do anything against it here's why: For every "Part" in a vessel ksp does have a "orgPos" and "orgRot" value... those values are only updated in situations like creation of a ship, loading a ship, docking/undocking (which is in a way a creation) and things like that... so, not very often. Those values contain the position and rotation information a part should have (you can say, it's the blueprint of the vessel). And because they are almost never updated, you can say that you have almost no floating point rounding errors. Now, if KJR Next (and only Next, not the original or continued version -> that is one of the things that makes this version a "Next") needs to reinforce a joint, those joints are reinforced using those values and not the old or current values. So, no matter how often this is done, it is always done the same way round. And... just as a side note. Infernal Robotics Next and the DLC robotics need to update those orgPos and orgRot values way more often, because they do something that wasn't in the original idea of ksp. Here I can say that Infernal Robotics Next does also have a mechanism to prevent floating point rounding errors, while DLC robotics (as far as I can see from the behaviour and gap buildup over time) does not have such a meachanism (or it doesn't work... at least I can see those gaps building up over time).

Yes, sizing docking ports (Clamp-O-Tron) doesn't work. That's why we cannot do that. But we are working on something else anyway for "the docking question" ...

ok... but you forgot to answer one question ... when does it bounce? landing? reloading? time-warp? when you first touch the ground? after a while after touching down? ...

When landing? This mod isn't touching the landing legs or gears at all. I don't see how this would be possible...

Well... it's not that I don't believe it... and I have it still on my list as "unresolved" (I'm never closing cases just because I didn't find out what it was). But I wasn't able to reproduce it currently... also not with the ships I got from users reporting this. That's why I cannot say anything about it currently... sorry... but, thanks for reporting it. I could imagine, that it has to do with timing... maybe one version is quicker and does see an other situation... can you try to lock/unlock the servos and tell me if it still exists then? Or going to time warp for a short period and see if it happens also after that? ... those 2 actions would trigger a rebuild of the joints... maybe we can find out something when you play with those?

I have uploaded version 3.0.2 it is still a pre-release, but almost what the new version should look like it does now no longer need TweakScale and has its own variants it offers some new features and the rotor and control mode have been improved LEE/GF classes are almost done what's missing or not fully implemented? sun tracking, things to build rail systems, multi attachpoints and a lot of cleanups... and there is a little bug which sometimes prevents the servo to stop exactely where it should... in this case you have to move it away a little bit and try again to reach the position... or stay where you are (most of the time the difference is 0.01 to 0.03 at most)

Nice... the second one you should try to build with the new "rotor" mode of IR. It offers much more controll over the rotation via a lot more axis that you can also bind directly (not only via the action groups). But, you should wait for 3.0.2 (should be out soon, at least as a preview)... it improves the behaviour of this mode in some situations.

if it is what I say (and you should first verify if it is that by activating the visibility of the autostruts), then the only possible way to solve that is by not having the heaviest part and the wheels/landing legs on opposite sides of a robotic joint (or, but just IF it is this problem, you can ask Squad to fix it and to wait for an updated version of ksp)

the only technical (= non user error) reason possible is the wheel/landingleg autostrut going to the heaviest part... note: if this is the reason, we cannot do much at the moment (I still say that's a problem Squad needs to solve... but, I guess they will one day... after too many complaining about it, because DLC robotics does have the same problem)

Maybe not that much... could be that I have the solution now, but I need to test that before I can release it...

that's possible... I never tried that, this code was something I only recompiled ... but I will fix that too thanks

That's interesting. I didn't know that this mode doesn't (or does not anymore?) call the normal editor functions... thank you for the info

it's something on my list... and I'm sure it won't take too long

thanks... and this is just a preview of 3.0.2 ... unfortunatelly I cannot say anything about the wheels at the moment... except, that if it will come back, it will be it's own mod but it needs more investigation, because robotic joints and wheels, that's something completely different (I don't know how it was earlier, but in todays KSP it is)

no, nothing I know off... do you have Kerbal Joint Reinforcement Continued installed? this mod cannot be used together with IR Next. Maybe it's blocking because of that? You need Kerbal Joint Reinforcement Next if you want to use it with IR Next... that's the only idea I have about it Edit: I tryed it myself and it seems to be the problem... uninstall KJR or KJR Continued, then you can install IR Next and KJR Next

It is the goal to have more realistic stability at the lowest impact in performance. But the project isn't completely finished yet (I'm still working on improvements, mainly performance improvements). That's why I haven't measuered it yet... so, unfortunatelly I cannot give you a clear answer at the moment.