[0.90] Magic Smoke Industries Infernal Robotics - 0.19.3

[Galane]

Powered rotary IR parts would be even more useful with a "no brakes" tweak so they would coast slowly to a stop or be free spinning when the action key is let up. Another useful addition would be a way to map keys to change the speed of the currently powered servo(s), without altering the setting for any not currently being moved.

Rotatrons and powered docking washers would become practical for more things, especially rotary wing craft.

[Camacan]

In my experiments I was using the IR control panel arrow to spin the rotors and it was quite unwieldy. But then I remembered that IR actions mapped to action groups are applied differently: it toggles on or off. Much better.

(There's an audio bug related to that functionality: the sound will sometimes continue after the servo is toggled off if an action group is used.)

Being able to change servo speeds using keys would be useful in other nonrotor servo-y contexts. Perhaps two keys that could be mapped to double/halve the speed of any active servos, even if .cfg setting was the only way to do it.

I'm an IR noob, but a rotor seems more like an engine part to me than a servo. A rotor needs fast continuous movement and is ideally under the control of the throttle.

[fatcargo]

I've been visiting IR thread for a long time now, hoping that i would see this at least as planned feature, but i did't even see anyone suggest this.

I would really like to see IR finally fulfill the obvious need for automation. Articulated designs are fine, but having to manually control them makes them unwieldy at best with increasing complexity.

Not to mention that if automation is ever to be implemented, feedback from IR parts would be almost mandatory for any reasonable kind of dynamic control.

For those thinking of KOS plugin - yes it is my intent to make IR possible to control. Some attempts to utilize IR from KOS have been made, but they are all limited to action groups - both in number of "control lines" and lack of feedback inputs.

This issue may be partially solved by using Action Groups Extended that enables use of named groups and raises limit to 250, which translates to much more "control lines" for better, more organized control. However, even though KOS does have support for external plugins, making a KOS-AGX bridge is still a "crutch".

So, will ever IR have the following :

1. External part enumeration and control

2. Part feedback position, speed and loading

3. Support for other plugins to access the above

1. External part enumeration and control

The idea is that while building a craft, a existing IR window is used to name parts (considering symmetry) to human readable format.

Enumeration would be a way for 3rd part plugin to access IR internal data on all attached parts and so it can build it's own list (regardless of the naming) for whatever purpose.

Control, obviously, should allow other plugins to send commands to IR parts.

2. Part feedback position, speed and loading

Parts should have supply data on their state with position, speed and loading (forces applied to their attachment nodes) to allow external control "software" to determine actions.

Some examples would be articulated aircrafts, dampening supports (custom-controlled landing struts or gears) and even walker designs (read Biomimetics for more info). Possibilities are quite wide if not limitless.

3. Support for other plugins to access the above

Well, it is superfluous to mention this by now, but for sake of completness i have to reiterate the above. IR should allow other plugins to read it's internal data and let them act on its parts.

Ok, that is all for now. Reading through over 500 pages (as of time of writing this post) is an overkill, so if any of the above is already underway, please tell me.

[Dunbaratu]

Ok, that is all for now. Reading through over 500 pages (as of time of writing this post) is an overkill, so if any of the above is already underway, please tell me.

I didn't see anything in your list that wasn't possible already with kOS, although since we didn't want to make it specifically JUST for IR, but for all mods, we did it in a generic API way.

1. Part Naming:

kOS provides this for any part in the VAB (not just IR parts) http://ksp-kos.github.io/KOS_DOC/general/nametag.html

2. position, speed, and loading.

Anything any mod (including IR) decides to show you on at part's rightclick menu can also be read by a kOS script. It won't let you look at something not on the display panel, but that's because we can't read the minds of other mod makers and guess what internal data they are okay with exposing. Making it appear on the display menu is proof that they're okay with exposing it. I think the things you want to see can easily be shown on the part menu if IR wants them to be.

3. Well, the fact that kOS can do these things is sort of proof that a plugin can do them, isn't it?

[fatcargo]

I started a reply and realized that i'm hijacking a thread with KOS-related discussion. I will post now in KOS thread instead. Thanks for the guidance, i haven't looked at KOS development for a long time and was amazed with results. I also found a section on values from editor menus and the fair-play of not directly editing inside code of other plugins.

[Dr_Goddard]

A little preview of a function I'm going to push to Sirkut.

It's terrific!

[riocrokite]

Sirkut, I noticed that collider for fixed mesh (the one that is not moving) is not showing up while in flight (in VAB/SPH it's displayed correctly). Both rotational and translational parts have this problem. Can this be fixed?

[sirkut]

Gotta be more descriptive. I don't understand what you mean.

[fatcargo]

I have question that i originally posted in ZodiusInfuser's IR rework thread, i'll repeat it here since i was told it really belongs here (with which i agree).

I was asking if it is possible to have singular IR parts that can act on multiple translational axes or rotational planes and answer was no.

What i'm thinking now is it possible to make a compound IR part that is made of multiple standard IR parts ? Kind of like trying to use Ubiozur's part welder, but with IR parts ? Even if that was possible, i don't really understand how would IR control see all available "control-lines" of such part. Main goal is to make multi-control parts that are not only compact but also have common mechanical stress. To clarify : a difference in part strength with two perpendicular rotatrons as separate pieces and as one "welded" or compound part.

[ZodiusInfuser]

Gotta be more descriptive. I don't understand what you mean.

I do. Basically, the parts are made up of two meshes, yet only the moving one can be used for right-click selection and highlighting. This to my knowledge has always been how the parts have behaved.

A little preview of a function I'm going to push to Sirkut.

It's terrific!

http://i.imgur.com/vAM3xhJ.png

Are they going to be exposed to the user in the final version, as to me that seems like something that should be plugin controlled, where volume is set based on part size, and pitch based on part speed.

Edit: Oh and Goddard, http://forum.kerbalspaceprogram.com/threads/65365-WIP-MSI-s-Infernal-Robotics-Model-Rework-%28Updated-27-08-2014%29?p=1734190&viewfull=1#post1734190

Edited February 16, 2015 by ZodiusInfuser

[Wercho]

Would it be possible to make jointSpring and jointDamping tweakable, possibly through a flag the same way as limitTweakable? I know I'd like to be able to create suspension systems easily, and using MM to duplicate the parts with springy values leads to extreme part clutter.

This mod is so sweet.

[riocrokite]

Sirkut, I noticed that collider for fixed mesh (the one that is not moving) is not showing up while in flight (in VAB/SPH it's displayed correctly). Both rotational and translational parts have this problem. Can this be fixed?

I do. Basically, the parts are made up of two meshes, yet only the moving one can be used for right-click selection and highlighting. This to my knowledge has always been how the parts have behaved.

Yah, so basically every part is made of two meshes, fixed and moving one. Yet only moving one has a collision collider.

Schematic explanation of current behaviour:

---------------------------------------------------------------------------------------------------------------------

So would it be possible to add persistent collision mesh for fixed part?

Edited February 17, 2015 by riocrokite

[ZodiusInfuser]

So would it be possible to add persistent collision mesh for fixed part?

Issue 1 is incorrect, as there is collision on the fixed mesh (or at least there is on all the Rework parts). As for issue 2, AFAIK, there's no way for an attached part to know if its joined to the fixed or moving mesh, just the overall part. This makes it virtually impossible to identify those attached parts that shouldn't be moved and exclude them from the transform operation. The one way to hack around it would be to divide the object into two parts, as I devised for the station bearing.

Edit: Just loaded the game up, and there certainly is collision there, because when you hover over the part the parent gets highlighted instead. That wouldn't happen without collision. That being said, maybe the collision isn't being counted in the physics engine, as in my test case that section just went straight through the floor.

Edited February 17, 2015 by ZodiusInfuser

[Space Scumbag]

Hey sirkut, don't know if you got my pm some weeks ago.

I was thinking how to make it easier to use IR for some builds and came up with this new idea. You could add a new action group, which makes an IR part move to its max value and back to the min value. So it moves back and forth when the button is pressed, kinda like the move +/- action group. I don't know if this was already suggested. And is this possible? I would really appreciate it, if you can add this in the next release.

Also, can you make a ball joint part, which can move in every direction, not only up/down or back/forth? You would need to control it with 4 keys, but it would be more flexible. I hope you know what I mean.

[ZodiusInfuser]

Also, can you make a ball joint part, which can move in every direction, not only up/down or back/forth? You would need to control it with 4 keys, but it would be more flexible. I hope you know what I mean.

That would be multiple axes per part, which currently isn't supported by IR.

[AcidEric]

I've made universal joints by attaching 2 hinges together at right angles to one another.

[fatcargo]

How well they hold under stress ? Do they flex under larger loads ? Does scaling them up help raise connection strength ?

[AcidEric]

you have to be careful to get them connected the correct way or the part that rotates is on the wrong end. I was pulling a 150 tonne land train, because I was using the unpowered hinges it shimmied quite a lot and tended to jacknife easily. they never broke even when the rest of the vehicle fell apart around them. there was a fair amount of flex but welding them together into a single part 'might' fix that.

dunno about the scaling thing I don't use tweekscale.

[fatcargo]

Ah yes, i you don't mind "bending the rules", you could use quantum struts placed on IR parts and periodically turn them on/off in sync with motion, though it requires KOS to work smoothly. Manual control via action groups would work, but it would be no fun to cross 100 meters that way.

[Leon026]

@Leon26:

When installed correctly, you will have a MagicSmokeIndustries folder in your GameData folder. If that's what you have, check with a new sandbox game since the parts are available fairly late in Career mode.

This might be a bit wierd, but the parts appear when I start a new game in Creative/Sandbox mode, but when I go back to my career game (I have my research lab fully upgraded and all the techs researched), a majority of the Infernal Robotics parts don't show up

[ZodiusInfuser]

This might be a bit wierd, but the parts appear when I start a new game in Creative/Sandbox mode, but when I go back to my career game (I have my research lab fully upgraded and all the techs researched), a majority of the Infernal Robotics parts don't show up

If the mod is a recent addition to your install, you'll have to go to the nodes the parts are in and unlock each part individually. Look around the advMetalworks area.

[Perry Apsis]

I have a rover with a gantry rail variant, with a hinge riding on it, with a 1x1 Structural Panel stuck on the end of the hinge, and a Clampotron Senior attached to the panel. It all works fine to start. I can raise and lower via the rail, and adjust the angle with the hinge. However, if I use it to dock with a base, when I undock, everything seems scrambled. I can only move the IR parts a bit, and when I do, oftentimes both parts move. If they were physical parts, I'd say the torque from the docking magnets jammed the mechanism. I did not attach the port directly to the hinge, but could I be suffering from the problem I Have Been Warned about involving attaching docking ports to IR pieces?

Thanks for any insight.

[Master Tao]

@Perry Apsis:

From the OP:

Do not attach IR parts directly to docking ports. It will make your life miserable. You have been warned!

It should perhaps read "Do not move docking ports with IR ports," but that's the issue. If you're interestd, there are a fair number of posts explaining what's going on scattered throughout the thread.

[taniwha]

Perry Apsis: What Master Tao is very true, but there is a workaround: the docking port must be on the same side of the IR parts as the root node (preferably, it is the root node). The problem comes from KSP reorganizing the vessel's part tree when it docks such that the docking port is the root node (assuming the vessel becomes a child of the other vessel). Presently, IR does not like this rearrangement. I've had IR parts actually snap apart when I accidentally did a nono-docking (using KAS winches), undocked, and tried to move things.

[Perry Apsis]

Perry Apsis: What Master Tao is very true, but there is a workaround: the docking port must be on the same side of the IR parts as the root node (preferably, it is the root node). The problem comes from KSP reorganizing the vessel's part tree when it docks such that the docking port is the root node (assuming the vessel becomes a child of the other vessel). Presently, IR does not like this rearrangement. I've had IR parts actually snap apart when I accidentally did a nono-docking (using KAS winches), undocked, and tried to move things.

Then I suppose this will have to wait, since it has hinges on both sides of the docking port pairs:

Javascript is disabled. View full album

- - - Updated - - -

BTW, there were some truly entertaining moments involved in this. The Clampotron Seniors generate a lot of torque, and things tend to go boom. Still, this was an improvement over the usual land-based docking experience for me.

Is the docking port issue something there's a fix in the works for, or should I expect it to be this way more or less permanently?

Obligatory: Trying not to go all gushy and fanboy here, but seriously, look how much creativity and fun this mod has unleashed. I read 75 pages of posts in this thread looking for more info on the docking port issue, and it was great reading. Hats off to the devs, and to the community as a whole.