Jump to content

Rudolf Meier

Members
  • Posts

    947
  • Joined

  • Last visited

Everything posted by Rudolf Meier

  1. 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
  2. I should upload the code... I know... I'm working on that...
  3. 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
  4. 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
  5. 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
  6. 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...
  7. 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...
  8. 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.
  9. yeah... but my config file seems not to work... no idea what I didn't do correctly... maybe because I mixed 2 modes or... whatever... um... KJR does normally take care of it, but in this case not, because it does ignore IR part... it needs to ignore them... otherwise we cannot move the joints... but, our joints are already pretty strong... but just 1 and not multiple... so I guess, you're right... it may work when the node size is not scaled
  10. ok, I know what it is... it seems that TweakScale is also scaling the size of the AttachNode... and if this size is >= 2, KSP doesn't use 1 but 3 joints between parts... you're right with > 1.5... this rounds up to 2 and then we have too many joints either we need to talk to @pelinor (I think he's developing this, right?) or... we should never scale a moving part > 1.5 and by the way... I wasn't able to make TweakScale ignoring the "mass" when scaling... no idea if my cfg was wrong or if that's another problem with TweakScale? ... (but I guess it's my config...) ... ok, there's also another option... I could rewrite IR so that it can handle those 3-joint joints... for huge parts... but... well...
  11. *hmm* ... I'm scaling to 5 now and... it works... with extendatrons at least ... oh, no... now I see it... *hmm* ... I can make everything very strong... and then it bends in strange ways and breaks... when I move the joints...
  12. Yes... the KJR included in my download contains many fixes not related to IR
  13. It has to do with mass... maybe... but when I remove all mass scaling, then it scales cubic and then everything works...
  14. wow... the first "non-bug"-report ... I think that's a good sign that we are on the correct path
  15. thanks, no, that's no problem, I'm currently updating all those links and build paths anyway... this will soon move to there
  16. ok, everything fixed and uploaded... for 3 versions of KSP (1.2.2, 1.3.1 and 1.4)
  17. ok, all bugs fixed in IR (minor things) and now I'm working on KJR ... I do now have a situation in which I see the problem... and I'm asking myself, if it ever worked in the old KJR?
  18. the function "InitializeValues" is about 1000 times slower than I expected... I will investigate this ok... that sounds easy... I will try to reproduce that...
  19. ups... that wasn't a bug, I did copy the GameData folder to build the release of IR next and forgot to delete it after... KSP now found 2 plugins and loaded them both... that's what caused the problems... so, no bugs I could see on my side... I will now investigate those reported from others
  20. I know... but I couldn't reproduce that. Can you tell me what parts you used in what order and how did you connect/disconnect? ... should be an easy one once I can see it on my machine, but I didn't use the winch in the past ... I can already imagine what this is... must be the same bug that sometimes doubles the category and stuff like that... That's a new one... something else... I was thinking about a special "broken mode" ... in case the joint is torn apart, the mod could start showing it that way... no idea if that's interesting... I was also thinking about other "broken" states... not working anymore or consuming way too much electricity because of overload in the past or things like that... but maybe that's a feature for the future
  21. new version is out... and this one should be a good one! all that might need a little tweaking is the values in the cfg files... for stronger joints, modify those values... I don't know if we did choose them correctly, but there is a good chance, that the code is ok now... Edit: I did test it, the joint strength seems to be ok for me (according to first tests with just one extendatron) ... but I see, there's sometimes a problem with the gui (too many buttons show up and the category doubled in the VAB... once...)
  22. I need more information on that. How did you do that? I need the exact list of parts or (if they're only stock) the vessel in a file. All my experiments didn't show such an autostrutting action. (but I know, that they only happen when the vessel contains parts in a very specific configuration... so, I guess I simply didn't find a config that shows the problem)
  23. ... but, is the axis looking into the same direction related to the mirroring? it's not really a mirroring like in a mirror... jet engines on the left side are also the same as on the right side... they rotate in the same direction... I think that's the same here and I didn't find a situation in which it's not correct... but... could be there is one I've had so many strange things... everything is possible
  24. I don't know if that's a bug... you need to invert the axis, sure... but... I'm not sure if that's really something that should be done automatically...
  25. thank for the input with the groups and those joints... sorry for that, I forgot a part in the code that makes them extra weak (I needed this to test the limits and forgot it, but it's only in translationals) ... I will clean that and bring a new version... and I will fix those 2 bugs
×
×
  • Create New...