Rudolf Meier

ha! I finally was able to make both classes behave the same way!! ... I replaced both with an empty class ... but now I know, it's not the model, not the cfg file, the name, TweakScale, KJR or the dog I don't have... it has to do with the class

it really IS something I'm missing... I did remove the functionality of IR and IR_v3 joints (no initialize, no FixedUpdate anymore) ... so, they do nothing... and when I do this, the "ships" with old IR joints are way more stable than those with the new ones... WITHOUT touching the configuration of the joints... and (interesting fact!) the parts like IBeams attached to the same parts where I attached the IR parts are way more rigid, when attached together with an old IR part than with a new IR part.... but I cannot find out why... I'm removing every setting, piece by piece... but still... I haven't found it... that's drives me crazy!!

try this... truss in the middle, attached to a launch clamp, then put 2 ibeams on each side of the truss and at the end a big tank (I used the 20 t Rockomax tank) ... the ibeams bend and the tank is on the ground... now put an old IR joint on this truss (additionally) ... see what happens... those ibeams become enormously strong and dont move anymore... or is this just something I can see on my machine? ... *hmm* ... that is related to KJR... ok... interesting...

I have some working configurations and some non working ones... but I cannot explain it... I will stop here and continue to investigate this... I want to understand why this is how it is... and I will only continue with this project after I fully understood it... I hope it doesn't take too long, but the good news for the moment is: I saw configurations that were stable... so I think those are the solution... at least I didn't see problems with those solutions

it pretty difficult to turn around everything... I don't know if I will continue with this idea and because of all those positive statements about the idea of dropping support for old KSPs and focus on a good solution for 1.4.1 I think I will stop trying to fix this... soon

I made some experiments now... when I make the connection between the tank and the extendatron 15 times stronger (as if the mass would be 1:10), then it is as strong as those between the Extendatron and Extendatron Stackable (without modification of this joint) ... I don't see the reason for it... or a pattern behind this logic... maybe someone has an idea for a good experiment to find out what's going on here? ... for the moment it's fine for me, I can continue my work... it's just... I've no idea how to explain what I see and maybe this info would also help others in the future

oh... now I see why all masses are 1 ... they seem to initialize only after a while... I don't know until which event I need to wait, but after that they're much more like expected... *hmm* very interesting...

sure, if you can upload them somewhere... I'm currently working on the joint-strength problem, but I will try to look into your problem after that

hi I don't understand those joints. First, I do have this situation: root -> ... something -> truss -> FL-R10 RCS Fuel Tank (0.1 t) -> Extendatron Basic (0.2 t) -> Extendatron Stackable (0.15 t) -> something -> massive heavy tank The Extendatrons are horizontaly attached. Now, the first joint is massively bended and unstable, while the second one is strong like hell (but both use the same force/spring/whatever values). Fine... this can be explained with the "lower mass == weaker". But: is it just the relation of those masses or is it the absolute mass as well that's influencing the strength?? ... and what I don't understand: why is the rigidBody.mass 1 for both parts? and... which mass is now the relevant one? how can I find it? (I need it, if I want to set the new "massScale" correctly) And... massScale... does it help, to set massScale and connectedMassScale to let's say 10 ? or is just the relation between those masses interesting? ... do further child/parent objects of the 2 connected object also have an influence on the joint? Would be nice if we could answer some questions about joints, now that we got a new Unity version.

I think I did change some values like torque and things like that a week ago... but... I didn't expect that this breaks the part. Because... the name should still be the same... at least I think my saves still load... I will do some tests later... but I wasn't aware of such a problem with KSP... but maybe I simply modified more than I thought... I will have to investigate this ... can you keep some old and new save files, just in case, so that I could compare them, when I'm running out of ideas?

*hmm* ... how did it break them?

ok, I can confirm, that I can make the joints very very very strong now without adding mass somewhere... but, just in 1.4.1 and currently I don't understand why it works... I simply multiplied a value by 10... but I expected, that it should work without this multiplication... anyway, that's not so important, I can figure this out... at least we know, that it works somehow... if this will bring us a usable overall situation... no idea... but maybe... at least it's looking better than yesterday now I will try to implement the 1.3.1 solution... if this can be done easily, then... I might support this too, otherwise... I will re-think the idea

... I don't like dropping old versions too soon. I'm thinking about writing 2 versions. An optimized one for 1.4.1 and one for 1.3.1, 1.2.2 that does it with the performance penalties (which is the only solution for those versions) ... but... ... don't know if that's a good idea maybe I will write both and then compare them... if it's not too much, I could try to support the special one for 1.3.1 for a while... but first I'm now verifying, if my theory is correct with 1.4.1

one question... if I could make the joints stronger either with performance penalties or only in 1.4.1 ... what do you prefer? drop support for 1.3.x and before or add the system with performance penalties? (I don't have the solution at the moment, but, as hypothetical question)

IR 2.x ?

I need to restart my investigation of translational joints... I have no idea why joints, locked on y, z axis and with rotation on all axis locked do rotate and move along those axis, even when they are infinite strong.. that doesn't make sense to me. ... so, no solution up to now... the old IR joints are extremely strong... but I haven't found out why... they don't move a bit into the wrong direction... that's incredible... every joint (every instance) has it's axis pointing to somewhere else... I don't see a system here... it's almost random. But, they keep their translational positions away from the movement axis 100% ... they don't move a bit... I worked with IR for a long time now... but I still don't see how this is done... must be a stupid detail I'm missing Edit: I found one detail... I'm trying this tomorrow... and I'm trying if... KJR (and therefor also IR) could be improved in 1.4.1, when I'm using a new setting... it's still a mistery why some joints are stronger than others... it is clear, that it has to do with weight... but maybe not with the absolute mass, but just with relative weights? ... I'm not sure, but I do have the impression, that this theory could at least contain some truth... we will see...

I don't know if it's interesting to copy real life rockets. Building and finding own solutions is more interesting. The parts should allow this, but not be something like a "Saturn IC - Tank". ... and what I miss is, that deep space missions are not interesting enough. Fly to Jool with a Kerbal... well... yeah... but not very realistic. The game could use some tweaks here. Maybe there should also be some kind of setting for the career mode how realistic it should be. And while we all love explosions... maybe we should still try not to kill Kerbals... and this should be rewarded a little bit more ... maybe. So... realism without being a copy of the real life. That should be what KSP should try. And this DLC is... well... more a copy than realism. But I do like 1.4.1 and those decoupler, adapter plates and shroud updates and stuff like that. But that's just a general view. I didn't go into details now.

it is not easy, but, the old IR is doing some kind of "active correction" of the wrong positions... that's something I did ignore completely... what it does is, allow movements along all axis and then point into one direction and set the target position in the space and not along the axis joint... that's probably the main difference and why it seems to be that stiff one of the questions here could be... if we like that and what the difference between this and an ibeam is... because the ibeam seems not to bend that way and does not have an active compensation of the wrong position... so... lots of data and cases to compare

so far I like what I found... ... I will build something new now... ... *hmm* not every idea works. I need more time to find out if there is a solution that provides everything we need... which is not too strong servos but still not shifting in non-movable directions the point is, one solution seems to be ok for me... but the non-moving mesh is slightly out of position... I could try to adjust this but that's not all... there is also the problem that parts attached to IR parts seem to have a problem with the bending of the IR parts... so, maybe it would be better not to allow them to bend... the problem here is: how do we do this? it's not working without making the joints infinitly strong... and then there is never something like a "stuck" servo ... it would always have infinite torque ... but, maybe I'm wrong and there is a setting that allows both things. I'm still searching...

That's true! Sometimes when we don't have useful ideas for problems in software development, we explicitly start implementing "stupid" or "can never work" ideas... in almost every case we found a good solution for the problem after just one or two hours of development... but, try to do this in "normal" companies... impossible

ok, here is the basic problem behind all this do the following experiments take a launch clamp, attach an I-beam or other truss (stock) to it so that it's pointing outwards (maybe you can add 2 of them) and then you add a heavy tank (or more) ... what you see is, that the launch clamp is bending and the tank will point a little bit down after a while then do this with Extendatrons attached to a solid tower (not a launch clamp)... you will also see that it will bend and the tank points to the ground after a while and after that do this with old Extendatrons too ... if you do now go to time-warp or do a save/load, we have different behaviour. The stock part will jump back and fall down again, the new Extendatrons will bend further and further and the old Extandatrons shift their attachment points towards the ground more and more with every step And now we need solutions... jump back is the default behaviour (that's why they added the "physics easing" I think, because ships would break after loading otherwise) ... but I'm not sure if that's the way to go... like this every robotic arm/joint/part will jump into the "non-bended" position as soon as you do time-warp or something like that... and this would give us very strange results I think... loading a scene with a part attached to an IR part would almost immediately destroy everything. If the joint is bended along the axis it is moving... then that's no problem. This should work in IR Next already. But if it's bended to the side... well... then I do have a little problem... because to fix this I would need to put some force on the joint... and doing this means that I need to let it rotate on those axis... but then... I'm not sure if I can still have a locked setting on that axis... *hmm* you know what??... I should try something ... thanks... it always helps to discuss such problems...

in a way it's unbelievable... why did never ever someone of the development team think about the fact, that somewant wants to save/load/timewarp a ship that has a force applied to a joint and that this force is bending this joint? ... that should be something that's inside the game already... that's basic stuff ... but as I said ... I'm used to things like that. Today (in my job) we had to store a "string" in a "boolean" ... otherwise the compiler would have selected a wrong option... took us some hours to find that out

the question here is: is this an IR problem? ... I guess not... those part-attachment-point-drifts I see all the time with all sorts of parts (not so much for stock parts) ... but in case something "bends" (happens very rarely for stock parts as I found out), then... they jump back into their position without force applied when you start time warp or save/load ... I don't like it, but... it's the game... maybe our parts should act in the same way... that should be possible to do... I don't know how they do it, but I will find out (launch clamps for example do this) ... the rest I think is up to KSP developers to fix that one day...

now I like the solution... at least in first tests... unfortunately the linear limits are completely wrong calculated now and I've to fix that first... but that's just setting the anchor and connectedAnchor correctly... I did mess up somethign with those values and another thing that's not good... when you have too much load on a joint, it bends (that's pretty good how it does it) but when you load such a scene... the parts start move around the body... that's fixed for rotational joints, but not for translational joints, since it was never ment that they could "rotate"... but, in case they bend heavily... that's something I need to solve too...

if someone builds the model, I will provide the coding...