ZodiusInfuser
-
Posts
1,352 -
Joined
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by ZodiusInfuser
-
-
48 minutes ago, Duke-49th said:
@Names in the screenshot of mine. No they were basically correct. I was just playing around. I kept changing the names, adding more colliders etc. I also thought at one point that MAYBE the names could be hardcoded haha.
That's why the screenshot differs from the cfg file. Sorry, I should have made it matching. Didn't notice it. My intention was more on showing the hierachy. But when I am testing it, I always make sure they match.
I have tested all combinations that could come to my mind.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
)
49 minutes ago, Duke-49th said:What I am wondering is that I took the original VTOL parts config as an example and that part works. The bottom node is not working on the old VTOL (attached tanks remain at the position when rotation starts). But the base and Joint parts are moving correct or better say, the base standing still and the joint is rotating as it should be. But with my model, it is moving like in the short video clip that I have posted.
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.
53 minutes ago, Duke-49th said:Just @orientation is something that I wasn't aware of, aside of this Quaternion thing. That's a good hint, if it has influence. I will try that later/tomorrow (I think 15 hours is enough for today loool)
Pretty sure it has influence, as I believe IR applies a rotation relative to the base and joint objects, rather than the part itself.
55 minutes ago, Duke-49th said:Also I noticed that it rotates counterclockwise, while the other parts form the mod rotate clockwise. (when pressing arrow right in the motor control window) - I assume that is an indication that the orientation is messed up?
Counter clockwise may be fixed with the orientation changes. If not then putting -1 for your axis value is entirely valid.
56 minutes ago, Duke-49th said:But I don't really undestand what you are trying to say with Blender. It keeps around transforms? Sorry, maybe I am tired, but I don't get it. I get the idea from the second sentence tho. I think haha.
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.
-
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
-
2 minutes ago, Semaj97 said:
Wow, I've been using KSP 1.3.1 just to use IR for ages now, glad to see somebody revived it. On another note though, the aesthetic is apparently the same, any plans on improvement there or nah?
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 hours ago, mindseyemodels said:
deleting WHICH folder? because otherwise I wont know... also I do not have inner lock(never heard of that mod til now honestly)
Delete MagicSmokeIndustries then let CKAN install IR next again.
-
1 hour ago, mindseyemodels said:
cannot see the tab and I had to delete magic smoke industries in order to install this mod on ckan... how do I get both installed at the same time? edit: after trying everything it seems that magic smoke industries and this mod are absolutely incompatible... I try deleting file after file to fix overwrites but nothing changes
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.
-
58 minutes ago, mindseyemodels said:
installed the mod but none of the parts were in my parts list... what can I do? does it require a core mod or something?
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).
-
1 minute ago, VR_Dev said:
Oh sure that makes sense. I usually have it set to 20 where I assume it's clamped?
By the way MoveTo(float float) works, it just kills the frame rate
Think the limit is a setting in the part configs, rather than a hard code limit. No idea about the frame rate problem though.
-
38 minutes ago, pellinor said:
A servo could run in two modes...
Hey Pellinor! Nice to see you here, wasn't sure if you were around
6 minutes ago, Rudolf Meier said:... the only problem: If I use the axis property -> KAL feeds it -> fine... user clicks on slider to jump from 0 to 88 -> then the servo moves to 98 and comes back to 88 because it doesn't know where the input came from.
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...
-
6 minutes ago, Rudolf Meier said:
Sure, but the main question remains... what's the interface you want? MoveTo(targetPosition, maxTargetSpeed) ?? or MoveTo(targetPosition, maxOvershooting) ?? ... is this useful?
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).
-
2 minutes ago, Rudolf Meier said:
The system would have to be split into 2 parts. It's not generally hard to do. It only needs some new classes and interfaces... I took the old idea and left it like it was. But maybe I should change this in a future version.
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/
-
1 hour ago, Rudolf Meier said:
The problem here is, that this would be an external controller for the movement and this is somewhat against the idea that we have implemented. It's a bit the same situation with the KAL-1000. If I would accept the commands just like they are set, then it could be that we run into a situation in which for example the joint won't be able to stop before reaching its limits. That's one problem... the second one is, when you often do an update, the system tries not to get faster than a specific speed so that it can stop at the position you commanded
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?
1 hour ago, Rudolf Meier said:E.g. if you want to move from 0 to 12 and you command 0.2, 0.4, 0.6, 0.8... then the system will look at the acceleration possible and never go to a full speed, because it always thinks it has to stop after the next 0.2 step. If you want a smooth movement, you should command position 12 and speed e.g. 0.4 if you want this speed to be reached while moving. Then it accelerates to 0.4 as fast as possible, moves until e.g. 11.55 so that it has enough time to decelerate and then it stops at 12.
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.
-
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).
-
6 minutes ago, Dragon01 said:
They are supposed to have increased friction over structural panels. So like a piece of rubber as opposed to a metal plate. Could be useful for walkers, or for grabbing things with a robotic claw.
Ah thank you! Will be interesting to see how that behaves in-game.
-
9 minutes ago, Dale Christopher said:
Walkers! XD
I'm not sure I follow. Aren't they styled structural panels?
-
Anyone know what the Grid Pads are for?
-
On 7/9/2019 at 1:25 PM, PriusMann said:
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.
-
17 hours ago, nmc said:
Nice work!
I am against surface attachment for these parts, even without knowing about the bug you mentioned. Also, that's quite enough parts for me, thanks!
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:
-
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?
-
21 hours ago, Masoneus said:
Where can I find the latest DL please?
https://github.com/meirumeiru/InfernalRobotics/releases/tag/v3.0.2
-
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
-
1 minute ago, Horus said:
The stock robotics is kind of... lite edition of IR. IR is still the best and more robust.
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.
-
1 hour ago, Horus said:
Btw. is the IR Sequencer abandoned?
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.
-
8 minutes ago, Horus said:
I don't really get the idea behind the part - Utilitron - Docker. Can you please explain its' purpose? Also, this part does not have size variants - can they be added later?
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.
-
1 hour ago, nmc said:
@ZodiusInfuser I like the hex hub! And for multiple attachments like that I use ReCoupler
Oh cool! I didn't know that mod existed.
5 hours ago, kcs123 said:Maybe to use more general option, "track target" instead of just Sun ? Each movable part could have one of two options enabled. Track target Yaw and Track target Pitch. In such case, target can be anything, other ship or planet. Can be useful for landing legs to track exact center of celestial body you want to land, for example. BD Armory fans might find it useful as well. My 2 cents on topic, since you already mention it here. Not super urgent request for such feature.
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).
)
[WIP] Infernal Robotics - Next
in KSP1 Mod Development
Posted
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.