Rudolf Meier

I did split up the mods. Infernal Robotics - Next is now robotics only. The connection and docking functionality is now in the IR ConnectionSystem (which is depends on the DockingFunctions mod). Maybe you don't have those mods installed? (the reason for the split up was that I built the DockingPort - Next and the PayloadRetentionSystem - Next) Tell me if it still doesn't work after installing or updating those mods. (By the way, it should now offer more functionality like e.g. time warping while having grappled an object. This is very useful, if you are in space and you want to wait for the sun to rise again. ... I don't recommend to overuse this feature, but sometimes it is handy.)

no problem well... try it with the latest version and if it's still possible to reproduce it, then yes

version 3.1.15 is online it fixes a problem with the control group handling

version 3.1.15 is online it fixes a problem with the control group handling

v4.2.27 is online (fixes a small problem in the version with gui)

v4.2.27 is online (fixes a small problem in the version with gui)

Which version of IR is that and what do you do to run into this? Do you add/remove parts? copy them? merge vessels? use sub assemblies? store load... restart ksp? what do you do, what not before you see those problems? Can you create a sequence of operations to reproduce it?

thanks I know... but it's not easy to achieve this. I have built my own Connected Living Space for this (I had to modify it quite a bit). The main problem is, that my port is not based on a ModuleDockingNode because that is impossible. And KSP doesn't know any other ways of identifying docking ports, which lead to the situation that no mod does have an other way of detecting docking ports either. I've created a mod which is meant to be a base for docking ports (DockingFunctions) and which offers an interface IDockable. If everyone would start supporting this, that would be a solution, but it may be hard to get to that point.

KJR Next is not just an other "KJR continuation", but a completely different development which does not just "add a bunch of extra joints", but tries just to fix the problems of the game engine used by KSP with a minimal number of modifications and extra joints on the vessel. This seems to be unknown to many players. (It is worth to read the first page of this thread again, because it contains new information.) And now with the release of KSP2 "For Science!" this topic is being discussed a lot again and so I wanted to link a video of a demonstration that I did recently.

@jebycheek and @ngx thanks, I will try to fix those

There was a problem after changing the system of servo groups. This caused some problems with old ships and savings. The only solution is to delete all groups and rebuild them. But after that you have many more options and it should run more stable.

... no, just kidding. But to be honest, I'd love to see people trying the new options of KJR Next with fully disabled autostruts. And then we could try to tweak the system and learn something about the possibilities. And not just repeat stuff that's no longer true today...

I always read "1 attachment point" and people complain about it (not you, it's just that it crossed my mind when I read what you wrote). But, it is not 1 attachment point. It is 1 joint. That's a difference! A joint is what the software uses to calculate and predict the relation between two parts. That's all. If you stack and bolt 2 tanks on top of each other, you may use 100 bolts in reality and you still have just 1 joint in the game. That's fine, because this 1 joint simulates the behavior of all those 100 bolts which form "the connection". So, my first point is, that it is irrelevant how many "attachment points" we have. But just how good those simulate reality. That's also why it is perfectly fine to use chains of Rigidbodys connected via ConfigurableJoints to simulate a rocket. The only problem is the flaw or design choice (maybe it is not even a flaw, we could debate this... but for now it is what we have to work with) which makes joints enormously weak, if the weights of the connected parts are not equal enough. The game is built on top of that system. That's why the game needs to handle this (in the background in my opinion). You don't want that you have to design your ships in a special manner, just because of the engine which does not simulate the stuff correctly. Therefor we need a fix in the game, which does this, preferably without the player remarking anything. And by the way... I often hear stuff like "we don't want workarounds" and stuff like that. But did you know that in KSP 1 parts were sometimes non physical parts and then turned into physical parts when it was needed? ... you could say, that this is also a "workaround". It could be that this idea could also be used to solve the wobbly rocket problems in KSP 2. But... I'm not sure if that's an easier solution to implement...

This stock vessel doesn't have a second stage like the real Saturn V, it only has what is the third stage in reality. That's why it is not bending there. And further up, they used a lot of struts around the engines to make it stable.

You want videos? I have videos... I have disabled AutoStruts completely in KSP 1 to show that it is as bad as KSP 2 (still today). Then in the second part of the video I have activated only one mode of KJR Next: the "reinforce inversions" mode! This mode adds only 9 joints to this stock Saturn V.

welding -> ok, I like the idea... alltough, I'm not sure if it's needed... e.g. the Saturn-IC (first stage of Saturn-V) had 2 tanks inside and a specialy formed hull where the gap was between those tanks. This part is not as stable as the rest (that's why they reinforced it). Now... if you weld things together, you don't have this potential point of failure anymore. And... well, there may be other situations in which it is definitely the right thing to have and to do (for the game)... one solution would be to make the resulting part weak, if one of the welded parts is weak (KJR Next does make the extra joints weak, if the light part which it tries to bypass is weak... the idea is, not to make a strong connection between two huge tanks, if they're connected via pudding). But I agree, this could be a good thing to have... and it would improve the performance. This is mostly due to how joints work. It is not like in reality and it is not intuitive to understand what's going on (joints do for example also have anchor points which let them behave as if they're way outside the connecting bodies and stuff like that). But adding more joints between those parts does not help. It increases the load on the computer, but doesn't produce better results. You only get an improvement, if you connect parts behind and after the interstage directly to each other (with one single joint, that's enough, when the mass distribution is right).

... but, the outcome is just a rigid vessel and therefore a changed game experience. Which is something not everyone wants (including me).

No, that's not how they work! How would they do that? It's a problem of the game engine. That's like a problem in physics and you say "ok... nice... I know there's the 'heisenberg uncertainty principle' and I had to work around this (when building the transporter from star trek), but now I don't want to do this anymore and I try to find a solution that ignores this fundamental rule of physics" ... how should that work? ... by modifying physics? or the universe? ... would be an interesting task. This is a problem of Unity and you have to accept that and live with that. I'm not talking about old KJR... I'm only talking about KJR Next v4.2.x ... that's the version with the new idea and fully new implementation. Early versions were sort of continuations and upgrades of the original KJR. The new one only shares the idea of "we need to do something against the wobble".

Are we talking about the real problem now? Because if yes, then I can say something about it. Assume we want to keep the Rigidbody+Joint idea of KSP (which I think is not bad) and lets say we want to keep the idea of wobble and failing rockets due to non working connections and stuff like that (which I also like). Then what is the problem with that? Well, it's that when you connect a heavy part to a light part and then again to a heavy part, that won't work. This is what I call "mass inversion" in KJR Next. You have this e.g. when you add decouplers (with their own Rigidbody). And that's all. This is the only problem. You need to fix those "mass inversions". (h - h = good / h - l - h = bad) One idea is to hope for a redesign of Unity... or PhysX. And I know, one day they will do something... like e.g. adding other properties which define strenght and not only mass. The other idea is, to build an additional joint from the heavy part to the heavy part and not going via the light part. Again -> look what KJR Next does. And then, we sometimes still have other instabilities... but those are small and we could talk about them in a very different way. Most (if not all) of the problems come from those mass inversions (at least in KSP 1). Some problems like oscillating vessels come from poor SAS. And this solution works for everything. From huge to tiny ships. Interstellar ... whatever. Because it addresses the problem in the game engine. (other solutions with not adding some additional joints could work too... but, in the end you need to get rid of the h - l -h connections).

True, but if they're not stopping to use RigidBodys and Joints or start using a completely differen version of Unity, then I don't see much they can do differently. And if they want to change this, then... well, then this means that this version of KSP2 is not even early access. Then they would have to change everything and all testing and development we do now would be more or less useless... this is something that needs to be addressed as the first point in this development (but, that's just my opinion... could be I'm completly wrong).

Well... then I didn't see the suggestions or technical ideas behind what has been said. Sorry... might be, that it wasn't detailed enough for me to understand it. On the other side, I'm among not many who did present a real implementation (in KSP 1) and nobody seems to care...

That's why we need to talk about the problem. We need to understand it and then we (or, the developers) can try to implement a solution. So... what is the problem? ... the answer is easy: it is Unity. As long as you use Unity + RigidBody + Joints, you will have all the problems that you have, when using Unity + RigidBody + Joints. And those problems are well known, fully understood and we also know what can be done to against it. What works, what not. So... it's not like flying into a completely unknown part of the universe. We know why it is what it is and what can be done! Why are we talking about it, as if nobody has an idea what is going on? And by the way, for the "autostrut" discussion: we also know autostruts. We know how they work and why they are not a good idea. Why are we then talking about "autostruts yes or no?" instead of "why are they not good?" "what is the problem with them?" "can we find a better implementation?" "are there ideas?" ... it's so annoying to read about this without seeing a real discussion about solutions!

the latest KJR Next does exactly this... and it works much better than I first thought (in KSP1, but this would also work for KSP2)

v4.2.26 is online (fixes problems with orbital construction mode)

v4.2.26 is online (fixes problems with orbital construction mode)