Rudolf Meier

This might be true... but, they are not Infernal Robotics... you can delete whichever you want. But you need Infernal Robotics!

Beta3 Patch3 is online... it has the bug that should have been fixed in Patch2 fixed again and it contains a test for translational joints... you should try it... I added test code based on this idea... (no idea if this breaks everything, but the rails work) ... should be no problem for all other joints

I still don't like quaternions... and I don't know if I ever will... after pretty much time I found it... I switched 2 parameters to a function... I will create a new release soon...

I just found a bug... the uncontrolled Pivotron and the off axis Rotatron seem to fail when going into time warp or save/load when they are attached reversed... I don't know why at the moment... but most of the parts seem to be ok (I first thought it could be a general problem, but I'm not sure...) ... it's the same function again.

I have uploaded a very early version of a new Active Struts mod... maybe you want to play around with it...

I will look at it and try to build something out of it... sometimes I do have the idea to change something ... but I hope it's not needed. Old IR sometimes used "internal" and "external" values and things like that. In case this is still the case in the wrapper, then I would remove that... but other things than that I wouldn't change.

that's what I do too... I have built beta3 patch2 and it's online I only found one problem (the one with the quaternions being flooded with NaN's) ... my gantry rails immediately explode whenever I modify the node, so that's something I cannot see how to fix or why it should work on someones computer additionally I think the problems reported are all related to this bug and I don't see a difference in strength between the old IR rail and the IR Next rail...

KJR 3.4.1-p1 is online... should now no longer destroy the settings of IR when IR parts are locked/unlocked but still reinforce those IR parts when they are locked I think that was one problem we saw yesterday... and now I try to fix the other one... I do have an implementation already, but found a better one and will try this now

I'm right now trying to fix the problem with the new KJR feature (dynamically activate/deactivate reinforcement, like active strut does it) ... it's... well... I don't know if I like how it's done internally, but... I think it is not worse than what KJR does anyway... so, I'll give it a try in the meantime my keyboard stopped working... had to change that too... well... let's see how it goes today

I did rename some namespaces yesterday . Those updates need to be integrated too, but now it should be stable...

seems that Beta 3 is complete crap... nothing works... those things were all ok in the early version, but the cleanup and optimization seems to have destroyed everything... I will start testing everything again and see what's wrong... the internal locks and lock-joints seem to be completely messed up...

it is not ready yet, but currently it did not explode for the duration of my test... let's hope this was the solution but, for bug number 1, the KJR one... that's not easy to solve... the problem is, that KJR is modifying the main joint... and that's a bad thing... autostrut is adding additional joints, that is better for this situation. Of course, needs more power (cpu/gpu) but... *hmm* ... no idea... we will see...

sounds good so far... Factor's are there mainly for gui. If you have a part that is showing a speed of 1 in the gui or your api, but you want it to move 20 (in this case deg/s or in translation whatever unit it might be), then you can use the factors. Like this you can also build 2 parts moving with speed "1" but one is e.g. twice as fast. pointer is the "secondaryAxis" this is what points to the child part (mainly used for IRaid tool) ... if you don't need this value, set it to something perpendicular to the axis (if you don't, the parts cannot calculate their current positions) zeroNormal and zeroInvert ... those are used for translational parts... they define what value the "zero" position has (the position your part has directly after loading) ... one is for the normal, the other one for the inverted part... e.g. rotatrons do have 0 and 2.4 (when inverted the 0 position is the 2.4 position) while the gantry rail has 0 and 0 (sits in the middle of the rail)

the NaN problem comes from the fact, that my quaternions do something that they shound't do ... and when I try to correct it, it's getting worse... again something I don't understand with quaternions... ok... thought I finally understand them, but nope...

hi... well, I wouldn't, but at the moment I think the rate of bugs is a little high and sometimes there are still discussions about other things like strength of the joints and things like that... because of those I think it's not the worst idea to keep it in one place, at least for some time... but it would be a good idea to switch to it when we are in a slightly more stable situation. But thank you in advance for every input... and, yes, the idea was to replace IR in the future... and I also had discussions with the original developers about that when I started the project --- updates on the bug... the NaN bug... it is a rotational problem and we only have it when multiple joints are linked together... it is some floating point overflow, but I haven't found exactely why it happens

hi, ... I'm glad to see that more and more are interested in the mod .... and to answer your question: yes, there are differences. I tried to name the new values in a logical way and pretty descriptive like "canHaveLimits" and things like that. I would recommend to look at one of the cfgs included in the mod, and then I can answer your remaining questions. those rounding problems are new... I hope I can work around them soon... but, if you don't use the Rotatrion Basic, it should work (I normally tested with the Pivotrons) ... and, dont lock Extendatrons at the moment ...

we are on 'hold' ... Beta 3 (together with KJR) has some big problems that need to be fixed first Bugs found so far: 1) KJR, when locking an extendatron, it shoots out to its middle position 2) the NaN flooding -> could be, that this comes from an optimization... I'm calculating something like rot = a * b * c * oldRot for every part in the vessel that is connected via IR part... and, I thought it would be an idea to precalculate a * b * c ... but when I do this, sometimes the values are too small and then the floating point calculation freaks out and returns infinite and in the next Step NaN ... maybe I cannot optimize this... wouldn't be a big problem then and a first test shows, that I could be right... and next tests show me, that it's better, but not solved... it still happens... I learned, that floating point numbers are like KSP... they often explode

somehow... it may be difficult to do and maybe we would need new models or whatever... but... could be an idea. There is also something like a... no idea how it's called... re-dock re-attach something? that is connecting parts in a way KSP doesn't allow it normally... this would be an option maybe. It could be a problem if you form a circle (for the Unity engine), but... still something to think about. And maybe it could be solved without circles. I think this is for a later version, maybe 3.1 or something, but still something to keep in mind...

that's not sure... maybe we only need more than 1 joint... maybe a translational joint like the rail joint needs to be 3 joints or something... I was thinking about this for some time... but... don't know yet if it's a good idea

That's the old Unity-PhysX-Strength-Is-Related-To-Mass crap... can be improved in 1.4.x a little bit, but in the end... it's difficult. If I add enourmous strengths to everything, every joint is so strong, that everything becomes highly unrealistic... if I don't do it, those things you do here don't work...

it is this special type of rotatron that is the problem... but I haven't found the exact problem... for some reason the internal rotation starts spinning even though it's not moving... this is causing the rotational calculation to freak out and flood everything with NaN's ... that's not so good ... and that's because of rounding problems because of a not so optimal angle between several things I'm using to calculate the rotation... I need to find a better way to do this... and maybe it's wrong anyway (because of bending that I'm not taking into account for rotational joints) ... anyway... we will find the solution... I think exactly like "George Phelps" ... you don't know him? ... really not? ... https://www.youtube.com/watch?v=Vop2OOCpwiQ

ok, I see it now... and I think I know where it happens... (it's the same function as always... the newest...) ... strange, but in a way interesting

and you are using Beta3 Patch1 ? because that was the problem of Beta3... that's why I built Patch1 ... and I think this should be fixed... or not? anyway... I'm trying it going into time warp destroys the universe... ok, that's nice ... must see if that's a new one or an old one I didn't get up to now... but it's not the error you describe... but, who knows, maybe this is different because I didn't set it on wheels... anyway, I have something to fix now

Do you know Infernal Robotics Next ? The main reason why I started the project was, because I wanted to have a Canadarm and Canardarm-2 in the game. Including the redocking of the arm and attach it to other PDGFs. That wasn't possible in old IR, but is no problem in IR Next. Additionally I started to investigate docking ports, because I think PDGFs should (at least sometimes) act like dockingports (because the game removes things not docked to a vessel... so, switching vessels could ruin your day, when you're new space station part simply dissapears). And... I wanted to include inverse kinematics to it (almost done). Oh and... add collisions to the scene so that you cannot move arms and parts attached to arms through your stations and things like that. ... I hope there is a way to try if IR Next could be used with your arm(s).

Somehow there are ways to do this in the Unity engine... but the idea of our parts is not that they are as strong as possible in this game engine, but reasonable strong. And I was comparing them to ibeams and other stock parts attached in such long constructs ... and my goal was to have the same behaviour with IR parts. In case they are too weak, I could try to fix something. But if they're just not hyper-strong... then it is "by design" ... but to be honest, I've not yet tested your configuration and if it is not strong enough. I will do this later...