Rudolf Meier

We all use and love infernal robotics. It offers great possibilities and adds a very important part of space exploration to the game: robotics. But we all know that there are also limitations and problems with the project. The idea of this project is to solve all those problems and take it to a new level. Main points of the project: major parts of the code will be re-written, made more robust, more efficient and easier to understand correct handling of reversals of servos in the editor as well as in flight during undocking and redocking enabling collisions of parts connected with servos fixing the problem that parts move away from their original attachement points over time minor bugfixes in gui adding ik for robotic arms (maybe in an other project) ... If you do have comments on this, ideas, things you think someone should look into, then please write it in this thread. The latest release and beta versions can be found here https://github.com/meirumeiru/InfernalRobotics/releases https://github.com/meirumeiru/InfernalRobotics (source code) It is recommended to use KJR Next with this mod. It is an improved version of original KJR and works correctly with the moving parts of Infernal Robotics and other mods. [WIP] Kerbal Joint Reinforcement - Next https://github.com/meirumeiru/Kerbal-Joint-Reinforcement/releases https://github.com/meirumeiru/Kerbal-Joint-Reinforcement (source code) the Infernal Robotics Active Struts (a new project using the old models) can be found here https://github.com/meirumeiru/Active-Struts/releases https://github.com/meirumeiru/Active-Struts (source code) This project wouldn't have been possible without the support and help of @ZodiusInfuser Meiru

Yes, I can... without testing it. Turn one hinge (180°) and it should work... or wait until I release my new IR... this one can handle those problems. We are at the moment in an alpha-test and I will come back when we can start the beta-test. Rudolf

thanks... I'll contact you as soon as I've solved the oscillation problem...

sometimes it freaks out... the movement itself is ok (more or less... sometimes it stopps between 0.01 and 0.02 degrees to early) but IK still gives some strange commands (sometimes) ... and then everything starts oscillating ... not very difficult, but takes some time to fix ... but I'll report when I'm ready. The main problem I have is, that I don't understand those debuggers. The breakpoints don't work how think the should. I'm not used to work with C#... normally I'm coding in C/C++ ... but it's just a matter of some days. But, in case someone is interested in beta testing, then I'd be happy to get a message. Edit: ok... I was wrong... the main problem (again) is Unity... the oscillation comes from Unity and currently I don't know why. I can reduce it by making the joint motor super powerfull, but that doesn't make sense to me. Anyway... I'll start a test series to figuere out how the problem works... I guess the problem is, that Unity freaks out when I give the command to turn just a little bit (less than 1 degrees) ... and, strangely it doesn't recover from the problem once it oscillated away from the center (it get's worse and worse... and my program does nothing else than telling him to go back to position xy) ... very strange :-) ...

ok... it's moving... now I try to find a way to integrate IK... maybe I've to add an additional vector to the definition, but that shouldn't be a big problem... I hope that I can start first beta tests after this weekend...

Oh yes... that's very well known and unsolvable (because of how IR is made and how Unity works... that doesn't fit together... never). I made some tests in the past weeks (too many tests... hours of tests... even days) and I did create a new mod now that can handle this. I'm currently trying to integrate it into the IR project (so that we could use the same UI and at least some of the interfaces) ... should be ready soon.

Well... I only thought... because all other things like the water purifyer are available. Maybe I'll build a fuel cell that runs with liquid fuel and oxygen instead of "oxydizer" ... but I'd have to calculate the ratios first so that it makes sense... we'll see... or maybe something like the space shuttle's RCRS ? but here too I'd have to calculate the ratios :-) and I'm currently working on an other mod

Well... there is the Ion-Engine. That's electrical. Not only electrical, but half. I created an electrical engine from your mod now... ok, it still has the flameouts when leaving the water... but maybe I can turn this into a quicker overheating instead. But, for the moment it only consumes electric power and I can send it to Eve... I'm still experimenting with how to stear the thing... maybe I can use a rotatron of Infernal Robitics and place the engine on that one...

Its a great mod... and I didn't find problems with it until now. But, I've a question you could probably answer. Is there a reason, why you don't have some kind of carbon dioxide filter or extractor module? ... or, can you tell me what I do with "liquid fuel" without "oxidizer"? after extracting the carbon with a sabatier reactor? ... what's the point I'm not seeing?

you know what's missing? :-) ... a pure electric Clipper Focused Propeller Engine ... (I want to use this on a water-rover on Eve) ... could this be done with some changes in the cfg or is it more complicated?

What do you mean with "new" ? is there already one? :-) I don't know anything about it... But... yes, everything will be new. And I think most configurations of joints wont work anymore, since the axis are all different (I didn't understand how they were set...). But that shouldn't be a big problem... it's just text in a file. Currently the inverse kinematics is just an idea. I've some ideas how to control it, but... we will see. Currently I'm still working on the docking, redocking and re-redocking problems. But I hope that the end-product will be Canadarm-2 or SSRMS ...

I'm currently rewriting the project (to solve all the reverse-reattach-stuff), because I didn't find the problems in the original code and because I found it pretty difficult to add inverse kinematics into it (because the 0-points are jumping around due to how Unity works) ... if someone is interested, I could contribute this code. But I cannot say now if I can support this project/code in the future...

I've an interesting problem... whenever I start the timewarp (non physic) and get back from it, I see a little movement between some parts (I guess it's between the physical and non physical ones) ... and sometimes (but, to be honest, I didn't find out if when it does what) the movement in one direction is larget than in the other one. The result is, that after going into timewarp and out again for about 20 to 40 times (sometimes also reloading the scene does this) my parts are... well... still connected... but far away from each other... with a huge gap between... why is that? I guess the main point where this happens is, when I connect my part to a cubic strut.

In real life NASA says that both ports can act as active or passive part (as far as I know). In KSP, if the port is not gendered (gendered = false) then it should work and the cfg's do contain the gendered = false... so, it should work (also with 2 passives by the way). One other thing: I was unable to dock once, because one port has a snapoffset of 60 and the others 120. I had to change the 60 to 120 (in cfg file) to make it work. No idea how it's handled internally by KSP... I think I should try to find it out one day... Edit: I did check that: the snapOffset need to be the same for both ports... otherwise KSP would not even try to calculate if the two docking ports are cose to each other and thus would also never allow a docking of them...

That's nice... but not like this ... and that's what I want to create :-)

those joints... now the lowAngularXLimit doesn't work... no idea what it means... or how it's supposed to work... I cannot move higher than the highAngularXLimit (that's working), but I've no reaction from the lowAngularXLimit...

Hi I like the mod... verry good... but I think we can improve it and we could turn the APAS into the best docking port of KSP. I'm currently investigating how the joints work and I'm pretty sure that I can make one that works like the real APAS ports. This means that you could dock with a an angle up to some degrees away from perfect alignment on all axis (and then with capture, retraction, docking states of course). ... but, while my programming skills are good, my modeling skills are just slightly over those of a beginner. Would it be possible to get a model of the APAS (the active one with the ring) in wich you don't have an animation, but with pistons between the ring and the docking port built in a way that they are freely movable (e.g. 20cm to 50cm or something like that)? (so that the ring can be pulled out and the pistons follow... with no force between those parts?) ... like this I could then attach this to my joints (which will then bring the force into the model) which should then work as in real life... Would be great if we can do that... Rudolf

I found out (in a tutorial video, after watching it 3 times :-) )... that you should set the axis to your rotation axis and the secondary to one that is perpendicular to it (in my case I guess I don't care about this axis... but I'm not sure yet). And then you should rotate around the x axis (the axis of the joint defines the x-axis of the joint's rotation and movements) ... and you should set the axis to the rotation axis, because like this it is the x-axis and the x-axis has the most possibilities in terms of settings and options of the movement... (that's the only reason to do that... you could rotate around all axis, but with less options... so, e.g. you cannot defined such fine restrictions or things like that) I hope that is correct what I wrote... But right now it seems that it's working... my only remaining problem is, that the thing doesn't seem to rotate around the anchor point... but when the rotation stopps, it snaps to it... so... I must have made some config errors here...

Yeah, but what direction does a joint rotate to if I allow him to rotate on it's x axis? That's the question the documentation doesn't answer.

I can find this about the "secondaryAxis" of a configurable joint: "Together, Axis and Secondary Axis define the local coordinate system of the joint. The third axis is set to be orthogonal to the other two." That's great... but does say nothing. Is the axis the x-axis and the secondaryAxis the y-axis or (what could also be) is the secondaryAxis the z-axis or maybe between the x-axis and the y-axis with a 30° angle between them? I mean... such documentations are crap. That's like writing all the ingredients for a cake on a paper and not telling what to do with them. Does somebody know that? ... I don't want to guess... I hate when I have to guess! ... sorry for that, but... really... Rudolf

Can someone explain this? I modified IR a little bit so that I can see the axis (joint.axis and joint.secondaryAxis). What I see is that the hinges all seem to work the way I expected it. Axis in direction of the visual model and the secondaryAxis shows into the "up" direction when the hinge is in it's 0 position. But the rotatrons... I don't understand them. Those axis seem to point anywhere (ok, that's not correct... not "anywhere" but 90° or 180° away from what I expect to see). What am I doing wrong?

Well... just to mention some problems of IR: the "docking" problem (reversing movements), the "no collision" problem (you can move arms through your ship), the "secondary docking" problem (that's not unique for IR, but makes it impossible to create SSRMS like systems) and there's no really good way of operating the arms (I know there is the IR sequencer, but that's not what I'm looking for... I want more)... oh and the "sometimes everything jumps around after reloading the scene" or the "sometimes joints and connections break whitout obvious reason" problem ... or the "when you apply a force to a hinge there forms a huge gap between the two hinge parts" problem... things like that... I found solutions for many of those problems but they are not very pretty at the moment and I'm still investigating how to improve them... and also improve the performance... currently I activated probably too many things in Unity... I'd like to make it simpler...

I know I don't need custom colliders. It's only that I wanted to learn how to make them. Just that I know how it works :-) ... on my way of finding out how the whole modding stuff works, I run into such questions and then I want to understand it. That's why I try to do things I don't really need for the current problem. But at the moment I'm working on an other "interesting problem" ... the question is: can I create a collider for an object that is not part of the object and not a child of it. So, is there a way to couple objects somehow that I can detect collisions and stop movements for robotic arms (because of the way ksp handles this it has to be done without child objects)... anyway... it remains interesting. ... one of the things I try to do is to fix all problems in infernal robotics and this is quite a challenge... but it's possible.

Yes... but here's the point I want to do differently (sorry if I didn't describe this precisely enough)... I want to use a second object that I modeled in blender as a collider. And by the way: it's working... the only problem is, that it seems, that my collider-object is visible too... and I've no idea how to make this collider a collider only.

What do you mean with "original" and "cloned"? ... I've realized that I have no idea how Blender works...