Rudolf Meier

ok... closer now... two problems: 1) when you use the "projection mode" (cheating mode of the solver to prevent such stupid movements that it shouldn't allow anyway) and you don't set limits (set the joint to "free" moving), then you still need to set the limit values (0 and 177 works, 0 and 0 doesn't) ... no idea why that makes a difference... those values shouldn't be used when you choose not to use them... but... hey... anyway... 2) the new way of limiting the joints (built directly into the joint we have, mainly to improve the performance) ... that's not working for this problem here... I will have to revert back to a 2 joint solution (but we do need 2 joints for rotational joints anyway, because there we don't have other possibilities -> otherwise limits from -177 to +177 degrees is the only thing we cal build... and even if this would be enough, you could never store/load a joints not in its default position...) ... so, it's clear now. But it takes some time to modify this. And then we can try again. Maybe the next solution is "better" (and "better" is defined as "fit's better on the solver unity uses" ) yeah, I'm complaining about units solver all the time, I know that... but... shouldn't those frameworks solve problems and not produce problems? (and there are better ones, so it's not impossible!) ... if I need to write one workaround after the other simply to make it look as if physics works... that's no fun...

that was my first idea too... but even going to float.PositiveInfinity doesn't help... so, that cannot be the point... (just to mention that... if you set damping forces to infinity... then you destroy the sun, right after the launch...)

I still cannot reproduce this... I don't see the difference between the old IR's joints and the new one... I'm right now modifying the new IR in a way that it's building the joints exactely how the old one did it... but, no idea why the new ones are hanging down while the old ones don't...

to me it seems to be causes by flaws in the unity solver

I made some experiments...maybe you can confirm what I think I see. When I'm building your 4 Extendatron with stackable Extendatrons inside ship... and I'm first adding the Extendatrons (mirrored) and then the stackable ones (also mirrored), then it's shaking... when I build just one Extendatron with the stackables inside, then I take those 3 parts and mirror them all in one step... then I don't have the shaking... is that correct or is it just a coincidence?

another standard KSP problem... that's what KJR tries to solve, but doesn't work for all situations... maybe there is a solution for that, but currently... I don't know... maybe I could install huge dampers or something... but it is for sure a default KSP-shaking-joint problem but... I see, the old IR had no problem with this configuration... maybe I can learn something from that and try to improve this it is even better... put one old IR part on that truss and... no shaking... I've to find out why

I get the idea of the hydraulic fluid. But I don't think we should model electric driven parts differently... simply because that's not how KSP does it with its electric parts (wheels for example). ... and ... sure, for things like fast running motors, you don't need a controlling gui. But... I don't know if that's realy "robotics" then ... try this with a tank in the middle instead of those trusses... then it works... that's the old problem with non-physical parts in KSP... no idea if we can fix that or if we should fix it... maybe I'll try that one day, but it's definitely "normal" for KSP at the moment...

the gui will need more work than I thought... maybe I'll fix the rest first and plan the gui updates for later... (because it's not a real problem, just... not so nice... sometimes) ...

sure... it's always good to have ideas

No need to apologize... I cannot count how often I investigated something I thought was a bug and in the end it was nothing. But often I did find bugs I didn't search because of such actions. So, for me that's "normal development" I was thinking about this option too... but I don't know if that's possible... maybe... at least I will re-read the code and try to find a possibility for that. I need to re-think and maybe re-design how the limits work... or maybe just correct some minor issues... could be that something is not how I think it should be so in any case, it was good we talked about it

I cannot see this... what did you do to get this wrong behaviour? if you start outside the limits or activate the limits when you are not inside its range, then you see a little bit strange things... but... the question here maybe should be: why do you acitvate a limit from e.g. 20 to 50 when you're at position 2? ... maybe I should not allow to set limits when you're outside of them?

I do provide support for recompiles I made

those bugs I will fix them... about the drag&drop... that's an interesting point... I didn't think about this... I'll try to solve that

It may contain bugs (it's a software... isn't that always possible? )... but currently we are working on no issues... and it's planed to have the Sequencer ready soon too... it can be installed side-by-side with the old IR... I wouldn't say it's 100% safe... but still pretty good... so, if someone is interested in trying it... it would help us in the development to get feedback for those interested in the source code... it will be available soon, I'm currently converting the directory structure for an upload on GitHub

well ... I just mentioned the problem I had with the mass scaling... and pellinor fixed it very quickly ... and added the new feature that a 0 scaling doesn't do anything (instead of overwriting the value with itself) this confirms what I thought: that TweakScale is a realy good mod with realy good support

new version is out... includes compile for 1.4.1, fix for the limit bug, readded the actions, fixed group-speed-factor allowing infinite speed and joints are made stronger (x 1.75)

And with IR parts you are splitting the group of parts in 2 for KJR... and it can only connect/reinforce parts within a group of parts. The official KJR doesn't build groups, but only uses 1 group... the one with the root part in... all other parts are completely ignored and not reinforced... with this one you can never build stable wings ... but with the new one I hope there is a way. ... maybe you need to add more parts to your wings... e.g. hidden tanks or something that can act as anchor? try to add a heavy part directly after the IR joint and attach the wings to that

The default sized Extendatrons can now hold about 60 t... I think this value is a good one, but... maybe we should use it for a smaller scale. Could be that the forces are right, but the scales too high? Maybe we should change the factorTorque for all joints to 60 ? (making the "Medium" parts holding 60 t?) ... but still I'm not sure about the linear scaling of that

I should upload the code... I know... I'm working on that...

now that sounds good... as starting point... sure... ok, so for the mass... mass scaling is done using the tweakscale.cfg file (because it always overwrites everything comming from a module... I think that's a bug... but anyway, not a problem for us... that's why we still have the "mass = 1" in those files) The other strengths involved... that's (for motorized joints) only the torque. Torque is used to specify the "maximumForce" of a JointDrive and it's "torqueLimit * factorTorque" ... the scaling does lower the "maxTorque" value of a joint the idea of the "factorTorque" is, that you don't have huge values in the gui... nothing more... the "maxTorque" is simply an upper limit for the "torqueLimit" value which is ... the strength of the joint/motor... but the "breakForce" and stuff like that is infinite already... I guess you don't talk about those anyway so... making it stronger means, you need more torque... currently this is scaling linearly... maybe we should go to another scale? ... (it is done internally, but I learned, you can overwrite this with the TweakScale.cfg files) ... maybe you find a better solution for those scaling factors all number by the way i comming from the cfg files, nothing is hard coded, except things that are done in a way that it's compatible with KSP... like e.g. setting the breakforce of the joints

I did it for a single rotatron... the idea is this part = IR.bla_123456789 -> part = IR.bla.v3_123456789 in the MODULE part containing name = MuMechToggle name = ModuleIRServo_v3 isEnable = <isEnabled> swap = False position = <rotation or translation> correction_0 = 0 correction_1 = 0 force = 0 presetsS = <presetPositionsSerialized> servoName = <servoName> groupName = <groupName> isLocked = <isMotionLock> isInverted = <invertAxis> zeroNormal = <see cfg file and scale correctly when translational -> linear, don't scale for rotational> zeroInvert = <see cfg file and scale correctly when translational -> linear, don't scale for rotational> defaultPosition = <defaultPosition or scale correctly when translational and too high> hasPositionLimit = <limitTweakableFlag> minPositionLimit = <rotateMin or translateMin> maxPositionLimit = <rotateMax or translateMax> torqueLimit = <torqueMax> accelerationLimit = <accelTweak> speedLimit = <speedTweak> jointSpring = Infinity jointDamping = 0 hasSpring = False factorTorque = <see cfg file> factorSpeed = <see cfg file> factorAcceleration = <see cfg file> scaleMass = 1 <or see cfg file> scaleElectricChargeRequired = 2 <or see cfg file> forwardKey = <forwardKey> reverseKey = <reverseKey> stagingEnabled = <stagingEnabled> remove all ACTIONS or wait for the next IR... then those ACTIONS work again I don't know if that's working always or if I missed something... and, I don't know what it takes to convert a "reversed" attached part with a new IR part... and of course, this is only tested once and only with a "craft" (1 part ) inside the VAB

What did work was to keep the attachNode size at 1... but I cannot make TweakScale ignore the "mass"... that's not a big problem, because all IR does is scaling it the same way TweakScale does now... but I think for future releases of TweakScale that could be something to fix... anyway... I'm now uploading the new IR which you can scale even to huge sizes

I'm not sure if that makes sense... we could try to add this, but... would only be needed for scaled parts. So... maybe doing the scaling differently might be easier. And nope... KSP build 1 joint if size is < 2 and 3 if it's >= 2 ... (I never speculate, I'm always getting this information from its code ) If you want to convert a craft in the VAB, it might be possible... I will look into that this evening...

I did only a quick test... I tryed to build something for "ModuleIRservo_v3" like there is for "ModuleIRservo" in one file... but that was just a 2 minutes action... I think this needs a little bit more time. What I know ... it is the "size" value of the attachNode that is interesting... no... unfortunatelly it won't... in case you turn them into the default position, then... maybe you can figure out the values you need to set... but... all those values like "correction_0", "correction_1" and stuff like that... that would need some thinking on how to set them correctly...

Yes, that's the idea. Those parts are pretty different and also the values they store/load. Without a converter it's not possible to convert one into another... and I don't know if that can be done easily. ... I will try it, but I didn't start that project yet.