ZodiusInfuser

Members
  • Content Count

    1,349
  • Joined

  • Last visited

Everything posted by ZodiusInfuser

  1. 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!
  2. Delete MagicSmokeIndustries then let CKAN install IR next again.
  3. 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.
  4. 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).
  5. Think the limit is a setting in the part configs, rather than a hard code limit. No idea about the frame rate problem though.
  6. 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...
  7. 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).
  8. 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/
  9. 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.
  10. 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).
  11. Ah thank you! Will be interesting to see how that behaves in-game.
  12. I'm not sure I follow. Aren't they styled structural panels?
  13. Anyone know what the Grid Pads are for?
  14. 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.
  15. 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:
  16. 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?
  17. https://github.com/meirumeiru/InfernalRobotics/releases/tag/v3.0.2
  18. 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
  19. 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.
  20. 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.
  21. 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.
  22. 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).
  23. PMed you some comments Sun tracking is not a new feature request. IIRC it's been suggested for all the time that IR has existing, going back to Sirkut's days. I believe the decision at those times was that it should not be a part of IR and instead should either be a separate module or kOS script that controls servos using the API calls. So if you do want to do it then I would suggest separate module, maybe even on a dedicated "sun tracker" part. We can discuss the specifics privately though.
  24. Well if they're anything like the existing trusses then they shouldn't need modifying for at least 5 years Cool! I'll keep an eye out for it! Thanks! Actually finding the creating of these hubs quite therapeutic, and a good distraction from the ActiveStruts parts I've been remodelling Old one in the bottom right for comparison. Did a lot of research to find an IRL mechanism to base these off: https://www.youtube.com/watch?v=O56oBIwEtp0 On the point of hub modelling, Yay or Nay to hex-hubs? Note: Due to how KSP works the outer ring of trusses in the image below would only be attached on one side, so would need strutting on the other. I thought about doing Oct hubs too but not sure of the benefit there. Hex is nice because it lets you form equilateral triangles as above.
  25. Can you test with just a single rotatron on top of a command pod? Also, do you have KJR Continued installed?