Jump to content

ZodiusInfuser

Members
  • Posts

    1,352
  • Joined

Reputation

531 Excellent

4 Followers

Contact Methods

Profile Information

  • About me
    IRL Doctor of Robotics

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Glad you were able to get somewhere with it! I've no idea why it's behaving like that in the VAB though, as the same config is used for both. It's very different code paths though, so it's entirely possible the mod is now broken in whatever the newest version of KSP is now.
  2. The names are definitely not hard coded, just all the models use the same names to make things easier when I was developing the CFG's (and a bit of laziness ) If that's the very old VTOL parts you're referring to, then I would advise against referencing that. It was never updated to work with IR Next because nobody had the original model files for it. Also the style did not match the Rework style that was the main "selling point" of the IR Next release. Pretty sure it has influence, as I believe IR applies a rotation relative to the base and joint objects, rather than the part itself. Counter clockwise may be fixed with the orientation changes. If not then putting -1 for your axis value is entirely valid. Ah, maybe "keeps around" was the wrong phrasing. What I meant is that when modelling in Blender it is easy to move the local origin of the model to not be positioned at the world origin. This would cause issues when importing a .blend file directly into Unity, which is how I did it. Interestingly, checking the .blend file for the rotatrons, I see I have the local origin is at 0,0,0, but has a 90 degree rotation around X. I can only guess this is to have Y facing up so the model appears correctly in Unity and does not need any transform applied in there.
  3. Nice to see there is still interest in this mod! (despite it effectively being redundant with the DLC existing) Looks like what you're making is functionally similar to the Rotatron Right (Rev). Sadly its been a long while since I've tested the mod, so I cannot remember if that part is still in it (Rudolf was able to remove most of the Rev parts). Here is what it looks like in Unity though: That looks very similar to what you show in your unity picture, other than the Base and Joint objects not having child object. Having colliders on child gameObjects is fine, and something I did on more complex parts like the rails. Your part config seems good too, although you do have your fixedMesh = Cube, when in the later Unity picture it is named Base. I suspect this is why the base is rotating. As for the weird rotation you are seeing on the joint, make sure the orientation of its gameObject in Unity matches that in the picture above. Often Blender keeps around transforms, so you may have to clear the transforms on that end (I've no idea how you'd do that nowadays). Or you can have the joint transform oriented correctly, then a child transform with the model and collision mesh at the needed orientation. Hope that helps
  4. Thanks! Sadly, the aesthetics are unlikely to change. This is in part due to my limited spare time, but also me not being a texture artist. So if they were ever going to get stock-alike textures (the models themselves are fine) it would be because someone joined our team for that specific purpose as there are a lot of parts to do. I would really like to see this happen one day though!
  5. Delete MagicSmokeIndustries then let CKAN install IR next again.
  6. MagicSmokeIndustries IS Infernal Robotics - Next. No idea what previous version you had installed, nor why CKAN complained. Do you have InnerLock installed perhaps, as that too creates a MagicSmokeIndustries folder. All I can suggest is deleting the folder again then have CKAN put IR Next in again.
  7. Can you see a Robotic part tab (not the DLC one though)? If so then that's a sign that the MagicSmokeIndustries folder is in the wrong location. It should be in the GameData folder (same as Squad and SquadExpansion).
  8. Think the limit is a setting in the part configs, rather than a hard code limit. No idea about the frame rate problem though.
  9. Hey Pellinor! Nice to see you here, wasn't sure if you were around Why would it jump up to 98 then back to 88? My thought on this is that we have a second interpolator that is simpler than the current one, with a target and a linear speed. When the speed is low the joint will move smoothly towards the target but also adapt to sudden changes in input. If the speed is high though then the function effectively becomes the suggested DirectMove. Now how you have two interpolators interact is another matter...
  10. I imagine @VR_Dev would know better but I would say the former. Internally I would say it should operate pretty similar to this: https://docs.odriverobotics.com/control , which is the control loop for the ODrive, a pretty expensive servo system that I have seen used in many robots. Depends on what part of the underlying joint is changed, (i.e. is it rotation or rotation rate).
  11. Well the current system works well for what most players need it to do, so I wouldn't suggest changing it. It seems with this and KAL we have these few edge cases that want more low-level access to the servo movement. Been as though Control Mode is becoming part of the regular servo mode, that means we have the Cyan colour free for an "Advanced" or "External" mode. Think of this like how IRL smart servos have RC PWM mode (Servo Mode), continuous rotation (Rotor Mode), and serial control: https://www.robotshop.com/info/wiki/lynxmotion/view/lynxmotion-smart-servo/
  12. Maybe @pellinor can weigh in here (if they are still around), as they were the original coder for IR's control system. Maybe there is some way the system can be modified? The point I would like to add here is that the reason you would want to set a position every update is because you A) do not know that 12 is your end position ahead of time due to the dynamic nature of the movement system you are trying to implement (i.e. you only know at this point in time it should be at 7 for example), and B) maybe 12 is where you want to go but because of whatever IK algorithm is being used, and the connectivity of the joints, a linear motion in space may not translate to a linear rotation rate (i.e. maybe you want to go 1, 2,6,9,11,12). These are situations I have personally encountered with both with IRL robotics and this thing below that we have talked privately about before. Also your own IK thing will encounter problem B.
  13. Maybe this would warrant a different control system then? For things like inverse kinematics, VR_Dev's walking, and even the sub/object tracker, having the ability to set a new commanded position every fixedUpdate and them perform any relevant feedback loop would be particularly useful. After all real life servos usually only have a proportional loop (maybe a full PID if they're smart servos).
  14. Ah thank you! Will be interesting to see how that behaves in-game.
  15. I'm not sure I follow. Aren't they styled structural panels?
×
×
  • Create New...