[WIP] Infernal Robotics - Next

[AlienFX]

I noticed that the ships having the hinge-type parts begin to spin a little in orbit. I made a check.

Image
Hinges do not close until the end. The one that the screenshot does not close less than 3 degrees. When trying to close, torque occurs proportional to the "Torque" parameter.
KSP v1.4.2 + MHE  &  Infernal Robotics v3.0.0 ("Next", beta 3, patch 1)

[Rudolf Meier]

5 minutes ago, SpannerMonkey(smce) said:

 Hi, that all seems fairly straight forward,  all seems  logical.   All seems fine in SPH though still need to retune the limits .  Problems aside i see no trouble adapting everything to the "Next" method

An explanation of the following would be handy , as in what they do

Speed is still degrees/sec

factorSpeed = 20
factorTorque = 35
zeroNormal = 0
zeroInvert = 0
pointer = 0, 1, 0

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)

[Rudolf Meier]

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...

Edited April 9, 2018 by Rudolf Meier

[mexorsu]

On 08/04/2018 at 3:09 PM, Rudolf Meier said:

I don't know if I fully understood the idea behind this class... I thought that this is just an example of how to do it in other projects and that those classes need to be built inside your project? An example of this class (which may or may not work, because I never tested more than the compiling) is in the latest IR-Sequencer. ... or, did I missunderstand something?

Yeah thats right- it's just that it's no longer "correct" after changes in your fork, for once it uses reflection and tried to grab the wrong classes, it also expects a list somewhere where its now a dictionary. After the changes I made to it its again compatibile with your version, so you could put it back I guess- unless you expect some more big changes to the interfaces which will break it again. That way if someone (like for example KOS developers) wants to (re)itegrate back with your version of IR he can just use the new wrapper and it should work again (new wrapper works exactly as old from API user perspective, just correctly maps to new IR_v3 types). By the way- I forked your repo and put the changes there too so that you can easily merge it if/when you want. Its all @ https://github.com/mexorsu/InfernalRobotics

And here you can find example of re-integration (with KOS in this case) using the new wrapper: https://github.com/mexorsu/KOS/commit/ee11a63cab1083064500ba3946ee095ce2c4d4c6

I made a new folder there and just copied old IR integration code (to keep it separate to allow using both versions at the same time just in case) and then just swapped the old IRWrapper with new one. Voila, it works.

Best regards

Edited April 10, 2018 by mexorsu
add more info

[Rudolf Meier]

13 hours ago, Gurki said:

Regarding "issue" it's a mix between tuning and bug :

• Rotatron - Basic : (maybe other too) Above the max roration limit (+/- 177°) , keeping the button pressed seem to continue the rotation value but not the actual part rotation. Pressing the button in of the opposite rotation consume the "extra" rotation before actually rotation the part (let say I press the "forward" button for 2 seconds above max limit, I have to press the backward button for 2 seconds before the part start rotating).
• Join Pivotron - Uncontrolled : Allow contraption above its current model (rotation above +/- 120~130° from visual estimation). I think this one is harder to fix as it should depend on attached part hitboxes ...
• From rotatrons I've tested,  they should hardset their rotation value above limits to corresponding opposite angle. Let say I have a rotation of 190° on a part that allow +/- 180°, it should be hardset to -170° and be able to keep rotating to 0° then 180° then above, following the same hardset.

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...

[Getsome2030]

Hi Rudolf, FYI. I was doing some more testing with Gantry design and IR Gantry Rails but this time I used the original "IR-2.0.14-Final-Core" and "IR-LegacyParts" for KSP 1.3.1 in KSP 1.4.2 interestingly enough they all work without any major fits or explosions. I still had to tweak some settings like mass reduced from 0.8 to 0.02 for rails and telescopic pistons, i also inverted the center attach node node_stack_center = 0.0, -0.05, 0.0, 0.0, -1.0, 0.0, 2 without it all exploding in game.

At the moment I am able to pick up over 6 tonne on Kerbin and am constructing a base buy picking up and maneuvering the the parts into place. 

Cheers 

[Rudolf Meier]

4 hours ago, mexorsu said:

... I guess- unless you expect some more big changes to the interfaces which will break it again.

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

[Rudolf Meier]

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

Edited April 10, 2018 by Rudolf Meier

[Rudolf Meier]

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

[kcs123]

30 minutes ago, Rudolf Meier said:

in the meantime my keyboard stopped working... had to change that too... well... let's see how it goes today

I hate when such things happen. Therefore, I always keep at least one keyboard and mouse in reserve. Cheaper ones than I use on day basis, but those suffice when Murphy laws kicks in in worst possible moment. Anyhow, nice to see progress made despite no longer have enough free time for KSP lately.

[Rudolf Meier]

1 hour ago, kcs123 said:

I hate when such things happen. Therefore, I always keep at least one keyboard and mouse in reserve. Cheaper ones than I use on day basis, but those suffice when Murphy laws kicks in in worst possible moment. Anyhow, nice to see progress made despite no longer have enough free time for KSP lately.

 that's what I do too...

 

2 hours ago, Rudolf Meier said:

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 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...

[Rudolf Meier]

On ‎10‎.‎04‎.‎2018 at 11:51 AM, mexorsu said:

...
I made a new folder there and just copied old IR integration code (to keep it separate to allow using both versions at the same time just in case) and then just swapped the old IRWrapper with new one. Voila, it works.

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.

[Rudolf Meier]

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

[Rudolf Meier]

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.  

Edited April 12, 2018 by Rudolf Meier

[Rudolf Meier]

On ‎11‎.‎04‎.‎2018 at 9:51 PM, Rudolf Meier said:

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 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...

[Rudolf Meier]

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...

 

On ‎09‎.‎04‎.‎2018 at 2:03 PM, Getsome2030 said:

So what your thinking is to have the rail attached at the ends and the center is able move the full length without pivoting in the center, that would be the way to go if it is possible?

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

[The Minmus Derp]

I want to but i have too many mods

[The-Doctor]

thank you for this work

[Rudolf Meier]

7 hours ago, The Minmus Derp said:

I want to but i have too many mods

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

[SpannerMonkey(smce)]

Hi, well I'm having no luck getting my formerly IR legacy powered  parts to play nice,  and by varying degrees they all behave in similar way to that shown in my previously posted video.  All my tests have carried out in 1.4.2 in a clean dev game so perhaps i should try the 131 version.

Bit stumped as to what to try next, as they worked in 131 with legacy IR, and are built to the same spec as the rework parts

For ref, the parts i'm attempting to convert, as mentioned a lot of my parts pivot or rotate, and these being a simple one joint affair seemed like the obvious first choice, as if this one would work I'd be able to set the others up just as easily

Spoiler

SO the parts First part the stabilising blade.  For ref all pivot points are on world 0 0 0 ,  and have zero local rotation,  and both parts and the GO are scale 1 .

this image highlights the fixed mesh

This the moving mesh

And this is the original module and the new IR next module replacement, i fully expect the obvious mistake to be pointed out, and be rightly called a dummy and really hope someone does see what i've messed up.

// toggle parameters
//MODULE
//{
//	name = MuMechToggle
//	rotateJoint = True
//	rotateAxis = 1, 0, 0
//	keyRotateSpeed = 20.0
//	rotateLimits = True
//	allowRotateLimitsToggle = True
//	rotateMin = -90.0
//	rotateMax = 90.0
//	stepIncrement = 0.1
//	rotateLimitsRevertKey = False
//	jointSpring = 0
//	jointDamping = 0
//	onActivate = False
//	rotateKey = 
//	revRotateKey = 
//	fixedMesh = BladeBase
//	servoName = HRVblade
//	invertSymmetry = False
//	partMassOriginal = 0.1
//	motorSndPath = MagicSmokeIndustries/Sounds/infernalRoboticMotor		// Motor loop sound path
//	electricChargeRequired = 2.0
//}
MODULE
	{
		name = ModuleIRServo_v3
		servoName = HRVblade

		axis = 1, 0, 0
		pointer = 1, 0, 0

		fixedMesh = BladeBase
		movingMesh = Blade

		isRotational = True

		hasMinMaxPosition = True
		minPosition = -42
		maxPosition = 110

		isFreeMoving = False

		electricChargeRequired = 2.5

		isInverted = False
		isLocked = False

		canHaveLimits = True

		hasPositionLimit = False
		minPositionLimit = -42
		maxPositionLimit = 110

		factorAcceleration = 20
		maxAcceleration = 20
		accelerationLimit = 4

		factorSpeed = 20
		maxSpeed = 20
		speedLimit = 1

		factorTorque = 35
		maxTorque = 30
		torqueLimit = 30

		zeroNormal = 0
		zeroInvert = 0
		presetsS = -90.0|0.0|90.0

//		invertSymmetry = False 
//		motorSndPath = MagicSmokeIndustries_Next/Sounds/infernalRoboticMotor		// Motor loop sound path
	}

The crane is identical apart from the obvious shape and the start position of the boom,  although the transforms are still zeroed at start position , uses a pretty similar cfg to above , excepting the range of movement , which for the crane is 180 .  As mentioned both parts function perfectly in the SPH its only in flight scene that things go badly awry.  tested with all the last 3 betas ,as you publish, and have tried with various builds of KJR, just in case , in all test runs the strange torquing of the craft occurs .

If need be i'm quite prepared to change anything in the hierarchy in order to make this work, as some of the robotic parts see extensive use , and some of the craft become fairly ornamental without the robotic arms and lifts functioning correctly .   

 

[Rudolf Meier]

13 minutes ago, SpannerMonkey(smce) said:

... i fully expect the obvious mistake to be pointed out ...

I do have at least one  ... you have set the axis to 1, 0, 0 and the pointer too... but you need 90° between axis and pointer, therefor you should use 0, 1, 0 or 0, 0, 1 as pointer. I would suggest to use a value that points directly from your axis towards the blade (activate the BuildAid in the editor and you understand why I recommend that).

... maybe I should add code to catch this error? Seems that you're not the only one doing this.

[kcs123]

43 minutes ago, Rudolf Meier said:

... maybe I should add code to catch this error? Seems that you're not the only one doing this.

Yep. That would be nice. Even it is produce spamm in log, it would good to have it because part developers or people like me who only mess around with config files will be able to find issue quickly in log files. Or even if they don't find it it will be easier for you to tell what happened from provided log file.

[SpannerMonkey(smce)]

3 hours ago, Rudolf Meier said:

... maybe I should add code to catch this error? Seems that you're not the only one doing this.

For my part while i love a good and to the point log message, something like that  doesn't need to be pinging the log every scene change , or every time the craft gets edited, which these things sometimes do.  Once or twice should be enough for anyone who's bothered enough to look. 
So perhaps instead of always logging , perhaps a setting ,  a cfg option that defaults to debug false, and needs a line added for debug = true?    As with many things, great to have when developing any parts for plugin power , but slightly annoying to have to wade through acres of non relevant info, when  developing other parts.    That said the 90degree offset is easily remembered.

As for it making any difference, to my particular problem,  the other parts cfg was indeed 90 offset as it should be , but i've had doubts about the sanity of this install today so I'll have to retest again in a clean install, just to be sure of no interference.

I know once i learn the special move, and secret gesture it'll all fall into place like it did for the original IR, until then the fight continues

Cheers

[Rudolf Meier]

19 minutes ago, SpannerMonkey(smce) said:

For my part while i love a good and to the point log message, something like that  doesn't need to be pinging the log every scene change , or every time the craft gets edited, which these things sometimes do.  Once or twice should be enough for anyone who's bothered enough to look.

correct... normally I also build special debug versions that log and release versions that don't... and they also don't have debug-checks. Because I want releases to be efficient. And with efficient I mean "written like the software for the Apollo computers". Those guys flew to the moon with just about 70 kb of memory!  ... ok, other topic... where were we?

oh yes... I made a 3 joint test and ... I think I will keep this in the code. Seems to be good.

[Rudolf Meier]

Beta3 Patch4 is online... little fix for the 3joint stability that I added with the last patch. This one looks pretty good for me now...

at least good enough for me to start a new game and try it in a real game play