Jump to content

ZodiusInfuser

Members
  • Posts

    1,352
  • Joined

Everything posted by ZodiusInfuser

  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?
  16. Anyone know what the Grid Pads are for?
  17. Usually that is because the files were installed incorrectly. You should have a MagicSmokeIndustries folder within KSP/GameData, the same folder where Squad and SquadExpansion are. If you have a Gamedata folder inside KSP/GameData then you need to move its content out and put it in the higher one.
  18. Thanks! I think surface attachment is something I will have to try out in-game, as at least for the cubic hubs I can see it being useful (but they wouldn't suffer from this bug anyway so it's a non-issue there). In the meantime I looped back to ActiveStruts. For those not familiar, ActiveStruts was a mod (kottabos video here: https://www.youtube.com/watch?v=ryIGnlaan_k) that IR acquired many years ago, that let you create struts in flight. As you can imagine this proved quite useful for robotics. Anyway, for various reasons the mod was removed from IR but now me and Rudolf are looking to bring it back, this time with whole new models! The biggest task with these new models was to make them more realistic, so I endeavoured to based them on as many real-world mechanisms and technologies as possible (the rigid strut itself is based on this https://www.youtube.com/watch?v=O56oBIwEtp0). Let me go through the parts you see: On the right we have two magnet-based ActiveStruts, which have a fixed angle and can extend up to 3m. These would be the most basic in terms of tech tree access (and cheapest). In the middle we have two anchor-based (aka microspines) ActiveStruts, which will be aim-able in a given range and can extend up to 5m. The anchor would theoretically allow them to attach to the ground and asteroids. These would be the most advanced in terms of tech tree access. The left three parts are latch-based ActiveStruts, which will be able to automatically track their assigned receptacle part (far left) and can extend up to 5m. This would offer the strongest connection to reward players for pre-planning their builds with the receptacles included, for example if you know the retracted and deployed states of a craft. Here you can see an example connection: So, that's our plans for returning ActiveStruts to IR. No ETA on this as there is much coding and part configuring still to do, but the models themselves are close to final so I thought I'd share Edit: For reference, this is what the old part offering was:
  19. On an unrelated point, had inspiration for a large magnet attachment today. It's been on my to-do list for a while now but couldn't get a design I was happy with until now. This has a 1.25m diameter so intended for more industrial uses than the existing Utilitron - Grabber. Now to a serious matter, what name should I give it? Ideally it should end with er/ar/or like the rest of the Utilitron parts. Attractor maybe?
  20. https://github.com/meirumeiru/InfernalRobotics/releases/tag/v3.0.2
  21. Following up on the structural hub stuff from the other week, I think I have created a complete collection of Hex Hubs. I have a question though. Do you want to be able to surface attach these parts to others or have them purely be node attach? The reason I ask is because I plan to use the stock variant system for them and it has a bug (or missing feature) where when changing variants it won't change the surface attachment point. This means I have have to separate some of the parts out based on the surface attach height (all those in the bottom right), in addition to separating by the number of nodes. I imagine using the B9MeshSwitch would avoid this issue but after discussion with Rudolf it was agreed that IR should have no hard dependencies on other mods. Also, usual question of too many / not enough? I started imagining bridges and other A-frame structures being made with them so the variant count snowballed a bit
  22. Oh the parts themselves are for sure. It's just the KAL is good for creating animations, which seems to be enough for most players. This is why the latest IR Next pre-release supports it, so you get the best of both worlds until such time as the IR Sequencer is revisited. I personally envisaged the IR Sequencer being more like a visual version of kOS akin to the drag-and-drop programming language Scratch, but achieving that is an awful lot of work.
  23. Not explicitly but the current maintainer @Valren_Starlord has not been heard from in a while and Rudolf is not in a position to take it over. Also, with the DLC release and the KAL sequencer being somewhat competent for most player's uses the IR Sequencer will need a bit of a re-think going forward.
  24. Literally because putting a Clamp-O-Tron Jr on IR parts looked ugly and I didn't like that :P. No other reason. It's functionally identical to the Jr and in fact uses the same model for the docking port part. As for size variants, its missing them because I believe that would prevent it from docking with other Clamp-O-Tron Jr's but if that's not the case i'll happily add the large variants.
  25. Oh cool! I didn't know that mod existed. Other ship tracking would be particularly useful for having comms dishes aim at the other satellites in a network (even though the game doesn't require it).
×
×
  • Create New...