[WIP] Infernal Robotics - Next

[Rudolf Meier]

ok, I can reproduce it...

[kcs123]

49 minutes ago, Rudolf Meier said:

How did you create this? Which link is the one that's not normally possible? I guess it's the one at the Extendatron... between Extendatron and uncontrolled Pivotron? right? ... did you use a mod?

almost every part seems to be connected with the ground... that shouldn't happen with KJR... but... I never looked into this code (the one responsible for making ground connections) ...

can you move the wings, after releasing it from the clamp?

Creation order:

1. Place Robo Truss lite 2.5m piece on fuel tank
2. Place 0.625m Robo Truss lite in mirror on #1 piece
3. Place Robo Truss lite to tube pro adapter on #2 piece in mirror mode
4. Place Rotatron bearing uncontroled on #3 piece
5. Rotate #3 piece by 90 degree along with bearing rotatron with rotate tool in SPH
6. Reposition piece #3 to align all parts with #2 piece
7. Attach 1.25m Robo Truss lite part to Bearing rotatron and move it ~ 1/3 of length in front of bearing, the rest of length to rear - It suppose to hold future wing piece
8. Attach Uncontroled Pivatron (I named it "UPivatronWing") to part #7
9.  All pieces #1 to # 8 creates one chain of parts
10. To create second chain, place Uncontroled pivatron ("UpivatronExt") on part #1 on rear end
11. Attach basic extendratron to piece #10
12. Adjust angles on pivatrons #10 to get it close with pivatron "UPivatronWing"
13. Finally, connect extendratron and "UPivatronWing" with strut

No, haven't tried it without launch clamps, I never have issues with those when I experimented with some of future craft designs.

[Rudolf Meier]

ok, that's nice... I saw this with the strut, but thought that's done by a mod

I'm not an KJR expert (yet), but the problem is, that it connects almost every part with the ground... I've no idea why at the moment... but I guess I will find out.. but, it's not related to IR

[kcs123]

Recreated same thing with official KJR and old IR plugin. Have no issue with moving wings attached to truss. So it must be that something is not triggering properly. IIRC KJR with exclusion works that it removes "magical autostruts" between parts as soon as IR starts to move and reattach them again when moving stops.

Have no idea why I didn't experienced similar thing with rover craft, perhaps because I didn't attached any wing parts to it.

[Rudolf Meier]

26 minutes ago, kcs123 said:

Recreated same thing with official KJR and old IR plugin. Have no issue with moving wings attached to truss. So it must be that something is not triggering properly. IIRC KJR with exclusion works that it removes "magical autostruts" between parts as soon as IR starts to move and reattach them again when moving stops.

No... that's not how KJR works. The reason why it works with the original one is another. It is because KJR is ignoring all parts attached as child to an IR part. But that's not correct... it shouldn't do that. That's why I built the new version. But because of what ever reason (didn't find it up to now) it's now attaching everything to the groud, as soon as you have a clamp in your construction together with an IR joint... I try to find out what's wrong here... but it's hard to read through code of others

by the way... it would be cool if KJR works like that... maybe this would be an idea for the future  

Edited March 4, 2018 by Rudolf Meier

[Rudolf Meier]

ok, sorry for blaming KJR... it's not KJR

it happens inside the VAB... I did build a ship without clamps... that's fine... then I added the clamps and bang... a lot of ground attachements... (only inside the VAB -> save ship -> read file ...) ... and KJR is not loading inside the VAB... this must be a KSP problem... but... why it worked with your other test? no idea... different order of attaching clamps?

or maybe... maybe KJR is enforcing those joints... those joints KSP adds for some reason and that are not ment to be permanent... *hmm* ... and because of the fix, it's now finding those... ok, that makes sense... I'd have to check this...

Edited March 4, 2018 by Rudolf Meier

[Rudolf Meier]

I think, if you add a very light wing... it should move... but, anyway, I'm testing a fix for it now

oh and... I think, it would also fail with the old KJR, if you add an additional part between the wing and your truss

Edited March 5, 2018 by Rudolf Meier

[Rudolf Meier]

well nope... its also not that...

but, I cannot move your system not even without wing... I can move it tough if I apply a huge force but, the system doesn't want to rotate around the uncontrolled bearing... must be something else... maybe the strut? I'm still guessing... but I don't think it is KJR or at least not alone

oh... sure... the bearing axis... I forgot to fix that one... ok... next try  

yeah... ok...  sorry guys it's too late... but I've found it

it's true, it was a problem between KJR and KSP... now with the fix installed it works (after correcting the axis of the joint) ...

Edited March 5, 2018 by Rudolf Meier

[Rudolf Meier]

here's a compilation for 1.3.1 http://meiru.square7.ch/reg554ui9wert/KerbalJointReinforcement_special.zip ... again ... the fixed one... this should move the wing (but I saw, your extendatrons are way too weak for this task... they were shaking like hell)

just to mention this also... I don't know if that's correct/good either what it does now... I need to check what KSP does when a ship takes off or lands... if the joints are modified in a way KJR doesn't expect it (means turns it from ground attached to non ground attached and vice versa) then... we probably would have to modify KJR again... and I'm not sure if we need this even for situation without IR...

Edited March 5, 2018 by Rudolf Meier

[kcs123]

16 hours ago, Rudolf Meier said:

by the way... it would be cool if KJR works like that... maybe this would be an idea for the future  

I probably missplaced behaviour of KJR and FAR in my mind. FAR does voxalization only after moving animation finish, to prevent FPS drops.

14 hours ago, Rudolf Meier said:

here's a compilation for 1.3.1 http://meiru.square7.ch/reg554ui9wert/KerbalJointReinforcement_special.zip ... again ... the fixed one... this should move the wing (but I saw, your extendatrons are way too weak for this task... they were shaking like hell)

That's just one of first prototype of mechanizm, I would probably end up with more than one pair of extendratron, but was unable to test it and improve it.
Probably it will be a good idea to combine this with InnerLock mod, to lock parts after moving in desired position.

For now I just want to create few proof of concept craft, for testing purposes and comparison with old IR crafts. Something to have to test, to see if joints are strong enough or not etc.

[Rudolf Meier]

25 minutes ago, kcs123 said:

For now I just want to create few proof of concept craft, for testing purposes and comparison with old IR crafts. Something to have to test, to see if joints are strong enough or not etc.

That's good and I like what you do... the joints are all too weak. You should multiply the torque by 20 I think (cfg file) ... at least that's my plan at the moment... between 10 and 20

[Rudolf Meier]

16 hours ago, Rudolf Meier said:

yeah... ok...  sorry guys it's too late... but I've found it

it's true, it was a problem between KJR and KSP... now with the fix installed it works (after correcting the axis of the joint) ...

no... forget that one... seems that it only works by luck  ... the joints I'm ignoring now are the correct ones but for the wrong reasons... I need more time to solve that

[kcs123]

34 minutes ago, Rudolf Meier said:

That's good and I like what you do... the joints are all too weak. You should multiply the torque by 20 I think (cfg file) ... at least that's my plan at the moment... between 10 and 20

Yep, after testing new version in game, I see what you mean. Joints are way too weak, compared to same parts with old IR plugin. I have increased Torque in SPH up to 30 on right click menu, it behave much better, but it need to be increased more. For comparison, with similar mechanizm created in the past, this plane was able to pull more than 9g in flight with everything on place:

On that plane, I used only pivotrons instead of bearings, but concept is similar.

I just started to search in part config file, but I don't see if there is variable available to increase that value. Found it:

Quote

maxTorque = 30
torqueLimit = 30

I will try to change those to see how it will look like in game.

Meanwhile, I found some other small issue wit editor in SPH:

When I set default preset for some part and it's value and later on choose for whole group or certain part to "move to default", it always move all parts to zero, instead of chosen default preset. Old IR behave properly with this, in comparison.

5 minutes ago, Rudolf Meier said:

no... forget that one... seems that it only works by luck  ... the joints I'm ignoring now are the correct ones but for the wrong reasons... I need more time to solve that

No worries, no need to rush. Meanwhile it works good enough to be able to find out what else might be broken. Or to broke even more stuff for myself

 

[kcs123]

I changed those settings in config files to 600, but still can't select in SPH higher value than 30. Probably plugin need changes too, to allow higher values from config files

Quote

maxTorque = 30
torqueLimit = 30

For comparison, I tried to hang verticaly 2 x Orange fuel tank, 1 x Orange fuel tank and 1 X Rotomax 32(half of orange fuel tank) on extendratron.

Two orange fuel tanks extend joints slightly, there is visible gap between base and movable pieces of extendratron. But joints does not break
One orange tank still extends joints to have air gap between parts.
1/2 of  orange fuel tank gives barely visible gap between parts.

Not most accurate test, but at least something to compare when you need to find out "proper" values for variables.

[Rudolf Meier]

1 hour ago, Rudolf Meier said:

no... forget that one... seems that it only works by luck  ... the joints I'm ignoring now are the correct ones but for the wrong reasons... I need more time to solve that

ha!! I found it... it IS a bug in KJR... I can give you the line number or you can see it on github when I'm done with that... (later this evening)... I don't know why it worked in earlier versions... but I guess it never did... maybe also just by luck (depend's on the weight of the involved parts) ...

I will also fix the other bug they have (something with a stock part that's not correctly ignored I guess) ...

Edited March 5, 2018 by Rudolf Meier

[Rudolf Meier]

latest version is online (currently only for 1.3.1) ... it should have fixed everything except the spring/damper stuff... could be that joints do have a too high spring force and maybe you cannot modify that at the moment (I'm trying to find a good configuration and because of that this code does have some experiments in it)

but things like gui, default pos and such things are fixed... as well as the included KJR version (I'm not sure if undocking is still possible with this version... I need to check that) ... this version can be seen as a highly experimental version (2 things) with fixed gui

it should now be possible to build a good one until tomorrow...

[kcs123]

20 hours ago, Rudolf Meier said:

this version can be seen as a highly experimental version (2 things) with fixed gui

And it is only used for some experiments in Kerbal style:

Old IR plugin, for comparison can hold 18X Orange tanks. Joints does not breaks, just separates a bit:

Put some more weight and joints between fuselage and truss would break sooner than joint on IR parts. It streches maybe too much but does not break.

With IR next, things are bit different. Almost like comparing aples to oranges. With default settings, extendratron can hold half of orange tanks without issues, but with full one it stretch a lot, but joint does not break. I tried to increase new value:

factorTorque = 20

up to 2000, but I was unable to find settings that can hold more weight than one orange tank. With one orange tanks it jumps a bit up and down until it settle near default zero position, performs like a shock absorber when you don't want it, but does not when you want it

 

In editor, default values works properly now. But groups don't so much. Possible reason could be that I loaded craft created with previous version of IR next.
Anyhow, when I attach IR part on craft and create new group and move that part into that group, with old IR plugin, when I deattach that part from craft and attach it again it is still member of new group that I put part in.

With latest version, when I reattach such part, new group that was created is deleted and re-attached part is put into default first group. Only way when it remains in selected group is when I have more than one part in group. It seems that new group is always deleted in editor if it no longer contain parts. It should not behave like that.

I wasn't able to test much more than that.

[Rudolf Meier]

12 minutes ago, kcs123 said:

In editor, default values works properly now. But groups don't so much. Possible reason could be that I loaded craft created with previous version of IR next.
Anyhow, when I attach IR part on craft and create new group and move that part into that group, with old IR plugin, when I deattach that part from craft and attach it again it is still member of new group that I put part in.

With latest version, when I reattach such part, new group that was created is deleted and re-attached part is put into default first group. Only way when it remains in selected group is when I have more than one part in group. It seems that new group is always deleted in editor if it no longer contain parts. It should not behave like that.

That's true... the grouping and the system behind is not so good. I need to invent something new here. I don't have plans for that at the moment... but wont take long  The problem is, that I will need a new idea for that. There is no such thing like a "vessel" (those are created on a "what parts are currently attached to each other" basis) and therefore I don't have a space to store those groups. In a way I would need a new idea here... I do have some, but I need to check out if they are good or not.

For the joint strength... well, those ones do have some experimental springs in it and those are not very strong. So it's fully explainable what happens here.

But it's good to hear that we only have problems I know and no new ones

[Rudolf Meier]

34 minutes ago, kcs123 said:

And it is only used for some experiments in Kerbal style:

Old IR plugin, for comparison can hold 18X Orange tanks. Joints does not breaks, just separates a bit:

Put some more weight and joints between fuselage and truss would break sooner than joint on IR parts. It streches maybe too much but does not break.

With IR next, things are bit different. Almost like comparing aples to oranges. With default settings, extendratron can hold half of orange tanks without issues, but with full one it stretch a lot, but joint does not break. I tried to increase new value

One question here is: how strong should the joints be? Doest it have to be possible to hang a Saturn V onto a single joint? Or ... do we try to give those values a little bit more sense?

[AccidentalDisassembly]

40 minutes ago, Rudolf Meier said:

That's true... the grouping and the system behind is not so good. I need to invent something new here. I don't have plans for that at the moment... but wont take long  The problem is, that I will need a new idea for that. There is no such thing like a "vessel" (those are created on a "what parts are currently attached to each other" basis) and therefore I don't have a space to store those groups. In a way I would need a new idea here... I do have some, but I need to check out if they are good or not.

For the joint strength... well, those ones do have some experimental springs in it and those are not very strong. So it's fully explainable what happens here.

But it's good to hear that we only have problems I know and no new ones

Tried the new version with large scaling - doesn't work. Same issue, plus a new issue: in the editor, if the TweakScale SCALETYPE has a large value, clicking more than twice in either direction on the selector arrow causes the context menu control to seem to lock up. Dunno what's up with that.

For your testing purposes, if you haven't already, please get rid of the two IR tweakscale configs you have and use these instead: https://www.dropbox.com/s/z2htmyrsfpr9x6z/New IR TweakScale Configs.zip?dl=0

Also, for the sake of scaling, the variable names used to control the movement limits for rotational parts vs. extendable parts need to be different. TweakScale needs a value it can scale for extending parts as a function of the part's size - e.g. maxPosition or maxPositionLimit, which should increase as the size of the part increases so that the numbers work out for how far the part is extending.

HOWEVER, rotational parts use the same variable name (in the same module) to represent degrees of motion. This will cause all sorts of bizarre numbers with TweakScale.

This is from the Rotatron part, for instance:

minPositionLimit = -360
maxPositionLimit = 360

When TweakScale changes the part's size, it will also change those values in a linear fashion - but it should not do so, since they're a measurement of degrees of rotation.

Those variables need to be changed to something else so that TweakScale will not modify them.

 

[Rudolf Meier]

8 minutes ago, AccidentalDisassembly said:

Tried the new version with large scaling - doesn't work....

Don't use a TWEAKSCALEEXPONENTS for ModuleIRServo_v3. It is handeled internally by the module itself. The behaviour you describe is what I would expect with your configuration (every part of it, including the lock up of the context menu).

[AccidentalDisassembly]

31 minutes ago, Rudolf Meier said:

Don't use a TWEAKSCALEEXPONENTS for ModuleIRServo_v3. It is handeled internally by the module itself. The behaviour you describe is what I would expect with your configuration (every part of it, including the lock up of the context menu).

!!!! Ok, that's news to me! I'll go give that a try.

EDIT: will we still be able to mess with those values somehow, in a config somewhere? Probably won't be necessary, just curious. Mostly thinking of mass values, part cost, EC consumption.

EDIT2: OK. After removing TWEAKSCALEEXPONENTS everywhere, the part context menu will still lock up IF there is a large scale in the SCALETYPE. This scaletype will not cause it to lock up:

EDIT AGAIN: Actually, the blue arrow selectors for part scale cease working after clicking them once or twice (with EITHER scaletype) in the editor, but you can still click on the green bar in the middle to change the scale... what in the world?! Perhaps I have borked something indeed.

However, the scaling does seem to work in my preliminary tests! Huzzah! I would note that the Rotatron's EC consumption goes up quite a lot more than the extendatron when scaled large. At 5x size and with values maxed (speed, accel), the rotatron takes something like 1250 EC/s while the extendatron takes far less.

Second note: The large scaling works with parts individually. However, if I place both an extendatron and a rotatron scaled to 5x on the same craft, the one I place second will not move/rotate in flight... strange. This does not seem to occur on non-scaled parts, at least.

Edited March 6, 2018 by AccidentalDisassembly

[kcs123]

17 minutes ago, AccidentalDisassembly said:

clicking more than twice in either direction on the selector arrow causes the context menu control to seem to lock up. Dunno what's up with that.

I noticed this too, but forgot to mention earlier. I didn't edited any of config files regarding tweakscale values.

51 minutes ago, Rudolf Meier said:

One question here is: how strong should the joints be? Doest it have to be possible to hang a Saturn V onto a single joint? Or ... do we try to give those values a little bit more sense?

I'm in divided opinion here. Reason why old IR have such high values is because crafts were always being slightly unstable (bending too much and similar). It would be nice to have a more sense with new values while still being possible to create certain craft type. That is one of reason why I started to create variable geometry wing craft, this kind was always being difficult to create in stable manner. That one would show how much strength is needed.

So far new system looks promising, it might everything being properly adjusted with right values. For example, it is acceptable for extendratron to strech out in longitudinal motion, but should not be able to bend on lateral axis.

Exposing torque or whatever other values are responsible for this can be exposed to SPH/VAB with wide variety of ranges to choose from low weight to saturn a-like values.
To balance out this in game, higher torque values might also increase mass of part.

It will be easier to find out "right" values when more people who were using IR before try to create their craft and tell their opinion how it feels in game.

[Rudolf Meier]

2 hours ago, kcs123 said:

I noticed this too, but forgot to mention earlier. I didn't edited any of config files regarding tweakscale values.

that should be fixed now

2 hours ago, kcs123 said:

So far new system looks promising, it might everything being properly adjusted with right values. For example, it is acceptable for extendratron to strech out in longitudinal motion, but should not be able to bend on lateral axis.

Thanks and I fully agree on that one... that's also why the joints are today built differently, so that this cannot happen anymore. Now we only have movements in or around 1 axis and not more (except if you overload everything with enourmous values... but this should break the joint anyway). 

2 hours ago, kcs123 said:

It will be easier to find out "right" values when more people who were using IR before try to create their craft and tell their opinion how it feels in game.

That's true... I think, if in the end everything is just an adjustment in the cfg files, we do have a good chance of finding good default values

2 hours ago, kcs123 said:

I'm in divided opinion here. Reason why old IR have such high values is because crafts were always being slightly unstable (bending too much and similar).

This one by could be solved by the new design of the joints but maybe also with improvements in KJR if needed... I think if you have moving wings, we need KJR, but I'm not sure at the moment... currently I'm trying to improve it further. It's still not clear enough which joints are reinforced and why and which ones are added... and it has bugs that someone tried to fix with other bugs...  or it is so complicated, that I don't get the idea behind it... one interesting thing of course is, that KSP undocks parts but doesn't reset the parent of the part to useful data before informing the attached modules about it... I guess this was also a source of problems for KJR developers

Edited March 7, 2018 by Rudolf Meier

[kcs123]

I did some research as I haven't dealed with hydraulic cylinders and actuators in real life. How much force they can push or pull depends on diameter and pressure of oil used. Usual max of pressure used in practice is up to 210 bar. It is possible to have higher, but it depends how much of pressure pipes, pumps and other supporting equipment. So, it is not unusual for piston to support 500t. Even electric actuators can pull around 60 t.

http://mail.tolomatic.com/archives/pdfs/9900-9239_00-How-to-size-hydraulic-cylinders-to-Electric-actuators.pdf

https://www.rockwellautomation.com/global/news/the-journal/detail.page?pagetitle=Use-an-Electric-Rod-Actuator-or-Hydraulic-Cylinder%3F&content_type=magazine&docid=0acf211a46d4cf2f4199ad69debdd3c2

https://ez-tools.eu/hydraulic-cylinders

Last link offer cylinders ready to buy on market that can support up to 300t.

One big orange tank weight about 36t. So, it would be resonable for extendratrons/pistons to support weight of 2 x Orange tanks for 72t. Few tons more and piston could show signs of streching, but should be able to handle 72t without much issue.

So, I would start with that values ant try it in game to see if it is too much or it is still too low.