[WIP] Infernal Robotics - Next

[kcs123]

Just focus on 1.4.1. By the time you will be able to made everything as you want and as intended, there will be more and more people moving to 1.4.1.

For KSP 1.3.1. people can use older version of IR - latest stable package from Zodiusinfuser. There is no point to stretch out your limited free time to support older version of KSP.

[Rudolf Meier]

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

[Rudolf Meier]

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

Edited March 23, 2018 by Rudolf Meier

[Rudolf Meier]

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

[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

[Rudolf Meier]

 I did re-insert about 95% of the old IR code into my test module, but just the module itself, no helper classes and... weak... I never had such a stupid mystery  ... but you know what? I start liking it... I don't know why  

[Rudolf Meier]

I do now have 2 implementation... one strong, the other weak and the difference between is, that I deleted 2 classes... now that's interesting, because I never thought those classes could make a difference...

... oh cool... just a side effect, not what I was looking for. Anyway... there aren't that many classes to delete anymore. I'll find it... it is still stable and I'm still blogging in the forum  ... but I learned, that rubber duck debugging is the best you can do to solve problems

Edited March 24, 2018 by Rudolf Meier

[Rudolf Meier]

now I have a very tiny little module, just containing the minimum to make the joint very strong... and... when I'm removing one line, everything gets weak... but it doesn't make sense... those values are (or should be) completely unrelatet to each other...

 

[viperwolf]

Dont burn yourself out, take a little breather. Seems like you burning the midnight oil with this, its very appreciated . Just dont overwhelm yourself with it, love the passion for resolve you have though.

[Rudolf Meier]

well well... thanks for the support... but I don't like having bugs and stuff like that... I cannot relax then

now for the "problem"... we started at "impossible" and are now at the "what do we want" level. so... I'd say that's good news

what do we have so far...

1) just to remind you: in KSP before 1.4 we had another unity engine. I don't know if this has any relation to our problem, but... it's good not to forget this I think

2) there was always this joint problem in unity, that when connecting a part with higher mass to a part with a lower mass... the "joint" (ConfigurableJoint) is attached to one part and connects to another... fine... in case you attach it to the part with the lower mass, documents and many forum entries tell you, that this is a problem when the ratio of those masses is larger than 1:10 ... that's wrong... you also have a problem when the ratio is 1:1.1 (at least that's what I see in my tests)... not that big, but still you have them

3) the new unity tries to fix the problem of the mass ratios by adding a new "massScale" and "connectedMassScale" variable to them...

that's what we know, that's why things sometimes are weak, sometimes not...

but sometimes the joints are really weak and sometimes not... and the solutions (like turning the joints around or using the massScale) don't seem to work and nobody seems to know why (or I was too stupid to understand the explanations)... but, IR joints (the old IR joints) were strong... and I know why... but I've no idea if the code causing this was in because of pure luck or if that's because they found out in the past that this works

... what you can do if your joints are weaker than what you expect. And ... I really would appreciate if someone could explain me why that is... setting the parent of the transform of one mesh of your model to the transform of the parent of your part in onStart ... you can remove this later... but you need to set this in this function

after setting this, the joints in 1.3.1 are strong... very very strong... and in 1.4.1 the massScale works normally (bending a little bit, when you scale the mass so that you have a 1:1 ratio in the end... otherwise you need to set it to 10 times higher values to have this effect) ...

...

next: ... I guess the (small) bending is ok... that's nothing I don't want (huge forces should bend parts like those long extendatrons a little bit)... the ibeams also bend a little bit... what I will add though is a correction of the position of the fixed mesh so that they look better when bending (but that's more a detail, since you don't want them to bend anyway) ... and I will try to make them compatible with storing/loading in a bended state... so that our parts don't initialize in the wrong place after loading

... I hope we are closer to a solution now.

[Rudolf Meier]

I had to redesign the calculation of the position... this wasn't good for trasnlational joints (I did not put as much effort in those as in rotational ones... so, no surprise) ... now it is still off by 0.01 sometimes... I will try to build a correction for that later

right now I'm trying to find out, why (without KJR of course, otherwise you cannot see the effects) ibeams bended jump back into position when I start time warping while my joints don't do that... it's not that I want them to jump around... I only want to understand the difference, because I think this is causing those anchor-point shifts we see (also with old IR parts) ... and I don't want them

[Problemless Mods Wanter]

On 3/3/2018 at 9:12 AM, AccidentalDisassembly said:

One thing noticed so far: when TweakScaling more than one or two increments from wherever the part starts (e.g. going up or down more than a couple arrow clicks in either direction - I think), torque values for the parts become very small. They can be set back to 30 again, but there's definitely something funky with scaling + torque values.

The same issue persists where parts (looks like all parts, now) scaled up past a certain point do not turn or extend, as well. You have to add larger sizes to the TweakScale configs to see this, as below (but without the asterisks, of course):

SCALETYPE
{
    name = Rework_Standard
    freeScale = false
    scaleFactors = 	0.198425, 	0.25, 	0.314980, 	0.396850, 	0.5, 	0.629961, 	0.793701, 	1.0, 	1.259921, ******7******
	scaleNames = 	Small -, 	Small, 	Small +, 	Medium -, 	Medium,	Medium +, 	Large -, 	Large, 	Large +, *****GigantorTest****
    defaultScale = 1.0 
}

Example: Both servos should be moving (unlimited EC) in this image, but only the non-scaled one moves. If scaled to 1.259921 (as in the above SCALETYPE), it will still move fine. But when scaled to 7x, it does not move at all:

I really need to upscale these parts, I need at least "4" or something, how can I approach this?

 

I am also wondering how and why these spesific numbers were chosen.

 

By the way I edited the CFG file, added new numbers and scalenames but I don't see any change in options in game.

Edited March 26, 2018 by Smart Parts Wanter

[AccidentalDisassembly]

14 hours ago, Smart Parts Wanter said:

I really need to upscale these parts, I need at least "4" or something, how can I approach this?

 

I am also wondering how and why these spesific numbers were chosen.

 

By the way I edited the CFG file, added new numbers and scalenames but I don't see any change in options in game.

In short, you rewrite the TweakScale configs (replace them). However, it seems there are still scaling problems in the most recent 1.4.1 version (so far as I can tell), so you still won't be able to scale beyond about 1.5x. I'm getting no movement for larger-scaled parts, and weird movement for very small-scale parts now...

The limited values that can be applied right now were chosen because previous IR developers did not try to work around certain scaling limits created by the weird way KSP does joints.

Some values were chosen because of the relative sizes of specific elements of the stackable extendatron models. Other values were chosen simply to line up with those values.

I'll be creating a customized TS config for my own use, which I'll share if others want to use it too, but it won't do much good yet.

[Rudolf Meier]

23 hours ago, Rudolf Meier said:

right now I'm trying to find out, why (without KJR of course, otherwise you cannot see the effects) ibeams bended jump back into position when I start time warping while my joints don't do that... it's not that I want them to jump around... I only want to understand the difference, because I think this is causing those anchor-point shifts we see (also with old IR parts) ... and I don't want them

I have found out, which function is causing this problem and I'm now testing solutions for it

1 minute ago, AccidentalDisassembly said:

IHowever, it seems there are still scaling problems in the most recent 1.4.1 version (so far as I can tell), so you still won't be able to scale beyond about 1.5x.

I think that should work... didn't try it recently and also not with 1.4.1, but... I thought it works... at least I once fixed it

[AccidentalDisassembly]

12 minutes ago, Rudolf Meier said:

I have found out, which function is causing this problem and I'm now testing solutions for it

I think that should work... didn't try it recently and also not with 1.4.1, but... I thought it works... at least I once fixed it

If you did, it was by doing something not reflected in the TweakScale configs, or something... For me, same story about the 1.5x scaling - that or bigger and it won't move (probably due to node sizes as before). In the TS configs I'm using, TWEAKSCALEEXPONENTS tries to control the node size, but I'm not sure how to write the config correctly to make it do it right. EDIT: Im' taking the attachNodes { size = 0 } from the config included in your DL:

SCALETYPE
{
    name = IR_Standard
    freeScale = true
    scaleFactors = 0.25, 	0.5, 	0.75, 	1.0, 	1.25, 	1.5, 	2.0, 3.0, 4.0
	incrementSlide = 0.025, 0.025, 	0.025, 	0.025, 	0.025, 	0.05, 	0.1, 0.1, 0.1
    defaultScale = 1.0
	suffix = x
    TWEAKSCALEEXPONENTS
	{
		mass = 2.2
		attachNodes { size = 0 }
	}
}

 

Edited March 26, 2018 by AccidentalDisassembly

[Rudolf Meier]

2 minutes ago, AccidentalDisassembly said:

If you did, it was by doing something not reflected in the TweakScale configs, or something...

nope... in this case it's easier... I think I forgot to upload the latest version

[AccidentalDisassembly]

24 minutes ago, Rudolf Meier said:

nope... in this case it's easier... I think I forgot to upload the latest version

Time for GitHub!

EDIT: Or... just naming the ZIP files differently, that could be helpful work too...

Edited March 26, 2018 by AccidentalDisassembly

[Problemless Mods Wanter]

42 minutes ago, AccidentalDisassembly said:

In short, you rewrite the TweakScale configs (replace them). However, it seems there are still scaling problems in the most recent 1.4.1 version (so far as I can tell), so you still won't be able to scale beyond about 1.5x. I'm getting no movement for larger-scaled parts, and weird movement for very small-scale parts now...

The limited values that can be applied right now were chosen because previous IR developers did not try to work around certain scaling limits created by the weird way KSP does joints.

Some values were chosen because of the relative sizes of specific elements of the stackable extendatron models. Other values were chosen simply to line up with those values.

I'll be creating a customized TS config for my own use, which I'll share if others want to use it too, but it won't do much good yet.

Thank you so much for your reply, please please please TAG me, if you upload any custom tweakscale configs, so I can try it a.s.a.p

[Rudolf Meier]

the joints seem to be stable now... the only shifting I see at the moment is along the axis ... I guess that's a bug in the force calculation... and I guess that this won't work for rotational joints at the moment...

... but I'm making progress

[Rudolf Meier]

sorry... i still don't have the solution... those quaternions are a nightmare... and the documentation is non existing... everyone is trying ... and those who say they understand them do calculate things that are completely wrong...

I need to find out how this works and why the hell I'm rotating everything into the wrong direction...

[kcs123]

1 hour ago, Rudolf Meier said:

sorry... i still don't have the solution... those quaternions are a nightmare... and the documentation is non existing... everyone is trying ... and those who say they understand them do calculate things that are completely wrong...

I need to find out how this works and why the hell I'm rotating everything into the wrong direction...

Don't know if it will help you, but this document helps me a bit to understand quenterions better, might be something you already know, though:

https://www.essentialmath.com/GDC2013/GDC13_quaternions_final.pdf

 

[Rudolf Meier]

in a way it should be an easy one... but I seem to be to stupid to find out what I don't do correctly...

if I want to convert the targetRotation of a joint into the space of the owner of this joint (the part) ... how do I do this? ... all my calculations are wrong... I don't know why... I want to rotate a part in the same way this targetRotation would do it... so, quaternion of this space to other space conversion... I don't know when it was the last time I had such problems... but maybe I don't understand the "joint space" ... or... whatever... I don't continue this work now... maybe another day...

[Rudolf Meier]

I've now built a test and I see the wrong calculation now... the only problem is, that I need to find out, why it is wrong but at least the problem is now down to 1 line.... and in 1 forum entry I found something like "joint space is inverted to world space" ... I don't understand why or don't remember that I have seen this before... could be that I had problems because of that earlier... but this really is one of the key points...

...

now it fits better... I will check out if this wil bring us the solution... such a stupid little detail and you lose hours...

a tip for everyone out there working with unity joints... first thing to do -> put a class into your program that can show lines of different colors and use them all the time! draw every single vector you're calculating... that's much easier than trying to solve a problem without the lines!

Edited March 29, 2018 by Rudolf Meier

[Rudolf Meier]

after killing Jeb multiple times and after destroying the launch pad even more times, I can report, that the rotational problems are solved now... I will now try to find out why the translational force is applied wrongly after loading... and then I will see if I can build a new release...

Edited March 29, 2018 by Rudolf Meier

[Rudolf Meier]

I removed KJR and the forces to check if everything is fine... but it is not... I'm off by about 0.04 with my angle calculations (almost always) ... I don't like that and will try to find out why and improve this... (the goal is < 0.005 at least)

later I will re-implement the force-stuff (this does not work anymore, because of the shifting-correction I added... that's why I have to rebuild that feature completely... but what we have was just a first try... and shouldn't be a big deal to do that) ... but those angle-things... joints shouldn't show 0.04 without force (and in fact... it remains very stable ... it's just, that the initialization of the 0-position seems to be... wrong... somehow... maybe the joint is moved after it's creation or... I don't know...) could be a rounding problem... but I'm not sure

Edited March 29, 2018 by Rudolf Meier