[WIP] MSI's Infernal Robotics - Plugin Rework (Updated: 05/04/2015)

[smjjames]

Please do not DDSfy our icons. We load them ourselves in our code. Icons are 32x32 pixels, you won't save much by DDSing them.

Okay. I can still DDSfy the parts though, right? I can just direct the DDS converter to just do the parts anyway.

[Ziw]

Okay. I can still DDSfy the parts though, right? I can just direct the DDS converter to just do the parts anyway.

Part for sure, just not the icons.

[JeffreyCor]

After seeing that demo video, wow! Already removed TweakScale from reworked parts, lot of work but well worth it. Can't wait to try this when playing later

[AccidentalDisassembly]

Thank you, we've added more checks into the preset movement code. New version of pre-release would be up soon for you to test. What TweakScale issue are you having? Have you tried making a clean install of IR?

It's the very long-standing issue IR has with tweakscale - you can easily reproduce it, too. IR parts can be scaled down without any problems (that I've seen, anyway!), but they can't be scaled up past a certain point (something like 1.999x size, but it doesn't seem absolutely consistent). To reproduce, just go to a clean copy of KSP with only TS and the new IR release, then try to scale up a hinge to 4x size. Go into flight mode, attempt to move it, you'll see what I mean. It doesn't produce exceptions, I don't think, it simply doesn't function like it should. Sometimes, you can see slight movement in the parts (or really bizarre, off-axis, wrong-direction movement, specifically with extending parts - I think).

Somewhere else, someone mentioned (speculated? I don't know) that it might have to do with changing node sizes on an IR part via tweakscale. If that's true, it would be a TS-specific issue, since it is very possible to re-scale IR parts manually via config editing and give them gigantic stack nodes with no problem. Maybe it's the attach node? Just guessing wildly. When rescaled via config editing, IR parts do ​work at much larger than normal sizes.

Also - if I could make one request, it would be to remove TweakScale from the part configs themselves and apply ALL TweakScale stuff via MM config. It is much, much easier for an end user like me to work with that way.

Edited March 26, 2015 by AccidentalDisassembly

[sumghai]

I'm particularly impressed with the ability to set arbitrary intermediate positions for individual / groups of actuators.

I'd like to know if it would be possible for an add-on author making their own IR parts to hardcode said intermediary positions into their part CFGs (i.e. to make stepper motors). I have a Warehouse part that I want to make into a rotary storage rack with four rotational positions.

[ZodiusInfuser]

I'm particularly impressed with the ability to set arbitrary intermediate positions for individual / groups of actuators.

I'd like to know if it would be possible for an add-on author making their own IR parts to hardcode said intermediary positions into their part CFGs (i.e. to make stepper motors). I have a Warehouse part that I want to make into a rotary storage rack with four rotational positions.

Yes . I'm working on adding the following line to the Rework parts.

presetPositionsSerialized = 0.0|90.0|180.0|270.0

Note that there's no way to prevent people from changing these in-game, so if you did want to make a stepper that could be an issue.

[sumghai]

Yes . I'm working on adding the following line to the Rework parts.

presetPositionsSerialized = 0.0|90.0|180.0|270.0

Note that there's no way to prevent people from changing these in-game, so if you did want to make a stepper that could be an issue.

Nice

I'm not hugely fussed about people changing my mod part's presets in-game, because they'll be doing so at their own risk. If feature creep isn't an issue, one could also add a preventPresetOverride = true field.

[Ziw]

Nice

I'm not hugely fussed about people changing my mod part's presets in-game, because they'll be doing so at their own risk. If feature creep isn't an issue, one could also add a preventPresetOverride = true field.

We don't really want to limit people in creative options, but this flag seems reasonable, in case you design very specific parts. Can you create an issue on github for easier tracking?

[ZodiusInfuser]

Just bumping this. We could really do with more people testing this to spot any issues as a lot has changed under the hood. I've picked up several things with the presets system for example.

[AccidentalDisassembly]

I'm obviously pretty fixated on the tweakscale stuff, haven't really seen much else. Fixing TS interaction (if it's even IR's fault!) would be pretty awesome, though!

[sarbian]

Please do not DDSfy our icons. We load them ourselves in our code. Icons are 32x32 pixels, you won't save much by DDSing them.

If you load them manually you should move them in your Plugins\PluginData\ directory or use GameDatabase.Instance.GetTexture to get a reference because right now you load texture that the game has already loaded and it is a bit wasteful.

[Ziw]

If you load them manually you should move them in your Plugins\PluginData\ directory or use GameDatabase.Instance.GetTexture to get a reference because right now you load texture that the game has already loaded and it is a bit wasteful.

Thanks for the tip!

[DaniDE]

Just bumping this. We could really do with more people testing this to spot any issues as a lot has changed under the hood. I've picked up several things with the presets system for example.

Probably most are like me, using this happily without issues, but not also not really hardcore engineering with robotics parts. So far, everything I made with this version works as expected, and I like the changes so far.

On a sidenote, maybe you should link to this dev thread from the Infernal Robotics Thread´s first post. I stumbled across this only because someone linked it on like the second last page on that thread.

The only thing I´d wish is for you guys to include the reworked parts in the download so you don´t have to manually copy them over.

[ZodiusInfuser]

...

On a sidenote, maybe you should link to this dev thread from the Infernal Robotics Thread´s first post. I stumbled across this only because someone linked it on like the second last page on that thread.

The only thing I´d wish is for you guys to include the reworked parts in the download so you don´t have to manually copy them over.

This is a dev thread for people to test the plugin out before a proper release. When that happens the OP of the main IR thread will get updated.

As for the reworked parts, the plan is to keep them as separate downloads but condense them down from the many that exist at the moment. We want to give people the choice of which robotics parts they use with Infernal Robotics (since there's a few other modders doing stuff), so as part of this we'll finally be separating the Legacy pack into its own download . Hopefully players will like this decision but if not now's the time to voice your concerns.

[Darren9]

I had an issue throwing the plugin into an existing install, it has AGX among other things if that's important, existing craft in that install had the "move+" and "move-" action groups reversed (I only noticed because I was activating them from a script and things went backwards) and also where I had set the "Engage lock" action group it was removed with the new plugin.

Is the next/prev preset action group a straight toggle? I seem to get into a situation where I need to activate it sometimes once and sometimes twice to have it go to the preset position. I had a similar effect with the move+/- action groups, it could be that if you send a new move action group command when it's still in the deceleration phase of the last movement it can be ignored?

It all seems to be working well though, a great addition

[allmhuran]

Feature / design change request:

Would it be possible to adjust all of the property names to be consistent across part types? So, for example, we current have some parts with "rotation" and others with "translation". Similarly we have some parts with "min translate" and others with "min rotate".

It would be really helpful if they could all have the same property names that don't depend upon the part type IE, good names would be "position", "min" and "max".

Why? Mostly for programming. Right now when iterating over arrays of positions I need do a check, which is both expensive and ugly... eg, currently it looks like this:

foreach part in partlist {
   if part:hasfield("translation:") {      
      set delta to nextposition - part:getfield("translation:").
      if delta > 0 {
         part:setfield("max translate", nextposition).
         part:doaction("move+", 1).
      } else {
         part:setfield("min translate", nextposition).
         part:doaction("move-", 1).
      }
   } else {
      set delta to nextposition - part:getfield("rotation:").
      if delta > 0 {
         part:setfield("maxrotate", nextposition").
         part:doaction("move-", 1).
      } else {
         part:setfield("maxrotate", nextposition").
         part:doaction("move+", 1).
      }
   }
}

Ideally it would look like this:

foreach part in partlist {
   set delta to nextposition - part:getfield("position").
   if delta > 0 {
      part:setfield("max", nextposition).
      part:doaction("move+", 1).
   } else {
      part:setfield("min", nextposition).
      part:doaction("move-", 1).
   }
}

Edited March 30, 2015 by allmhuran

[Ziw]

Feature / design change request:

Would it be possible to adjust all of the property names to be consistent across part types? So, for example, we current have some parts with "rotation" and others with "translation". Similarly we have some parts with "min translate" and others with "min rotate".

It would be really helpful if they could all have the same property names that don't depend upon the part type IE, good names would be "position", "min" and "max".

Why? Mostly for programming. Right now when iterating over arrays of positions I need do a check, which is both expensive and ugly... eg, currently it looks like this:

foreach part in partlist {
   if part:hasfield("translation:") {      
      set delta to nextposition - part:getfield("translation:").
      if delta > 0 {
         part:setfield("max translate", nextposition).
         part:doaction("move+", 1).
      } else {
         part:setfield("min translate", nextposition).
         part:doaction("move-", 1).
      }
   } else {
      set delta to nextposition - part:getfield("rotation:").
      if delta > 0 {
         part:setfield("maxrotate", nextposition").
         part:doaction("move-", 1).
      } else {
         part:setfield("maxrotate", nextposition").
         part:doaction("move+", 1).
      }
   }
}

Ideally it would look like this:

foreach part in partlist {
   set delta to nextposition - part:getfield("position").
   if delta > 0 {
      part:setfield("max", nextposition).
      part:doaction("move+", 1).
   } else {
      part:setfield("min", nextposition).
      part:doaction("move-", 1).
   }
}

It is on our list right now, but the solution would be slightly different: we'll introduce an API and integrate it into KOS later so you will not have to do this stuff with part:doaction

On a downside it may take some time, as kOS has different release cycle.

[riocrokite]

This rework is great, I actually have nothing to add. Presets with action groups add great functionality, reset to center is very useful as well as emergency stop button. Very nice

edit: actually there are things I wanted to report:

- reset to center works differently for rotators than for moving servos. For movers it seems that it returns to placement center. for rotators it returns to the position it was launched. it would be cool to have consistency in this regard for movers and rotators.

-shop position editor was a great tool for me to fine-tune rotators in editor, now it's missing and consequently there's no step-finetuning possibility by 1 degree in editor. It would be great if this feature would be preserved and possibly extended by ability to define step number especially for moving servos (since rotating servos have had 1 degree which worked briliantly).

- it would be great if 'reset to center' functionality was available in editor too. For example when I move servo by a random number in editor it is sometimes very hard to reset it to center manually (or by step in previous version). I had/have to resort in this case to detach and attach that part again which is not ideal especially with imprecise surface attachment.

edit2:

a nice-to-have feature but probably limited to my mod:

- I would be cool to integrate IR with Firespitter's FSmeshSwitch functionality. What that module does is that it lets you switch between different part versions (that reuse same texture) in editor via right-click. In effect it declutters editor window nicely.

edit3 (lol):

- a nice feature in IR editor window would be some kind of 'send to bottom' (and maybe 'send to top' but this is not as important) button so moving elements to newly created groups is much faster and less error prone. Now, when you have several groups with assigned parts already and wanted to move another part from top group to newly created bottom one it is not easy. You have to move the part through all created groups and consequently rename it first to avoid confusion. With 'send to bottom' button assigning parts to new groups would be much faster imho.

Edited March 30, 2015 by riocrokite

[Ziw]

This rework is great, I actually have nothing to add. Presets with action groups add great functionality, reset to center is very useful as well as emergency stop button. Very nice

edit: actually there are things I wanted to report:

- reset to center works differently for rotators than for moving servos. For movers it seems that it returns to placement center. for rotators it returns to the position it was launched. it would be cool to have consistency in this regard for movers and rotators.

-shop position editor was a great tool for me to fine-tune rotators in editor, now it's missing and consequently there's no step-finetuning possibility by 1 degree in editor. It would be great if this feature would be preserved and possibly extended by ability to define step number especially for moving servos (since rotating servos have had 1 degree which worked briliantly).

- it would be great if 'reset to center' functionality was available in editor too. For example when I move servo by a random number in editor it is sometimes very hard to reset it to center manually (or by step in previous version). I had/have to resort in this case to detach and attach that part again which is not ideal especially with imprecise surface attachment.

edit2:

a nice-to-have feature but probably limited to my mod:

- I would be cool to integrate IR with Firespitter's FSmeshSwitch functionality. What that module does is that it lets you switch between different part versions (that reuse same texture) in editor via right-click. In effect it declutters editor window nicely.

Thank you for the feedback! Some comments on your issues/suggestions:

1. We'll look into it. Do you want both of them return to As-Launched position or both to return to default position?

2. We're currently working on a tool for precise positioning in editor, but it will take some time (moving parts in editor is handled by completely different code than in flight). Right now you can position as close as you can and then use preset to fine-tune to desired position as soon as you leave the VAB/SPH.

3. It has the same roots as 2. and will be solved too when 2. is solved

4. It is not on our radar right now, and with new custom category filter (coming soon) there will actually be much less clutter in editor.

[allmhuran]

It is on our list right now, but the solution would be slightly different: we'll introduce an API and integrate it into KOS later so you will not have to do this stuff with part:doaction

On a downside it may take some time, as kOS has different release cycle.

Wootage, sounds good!

[riocrokite]

Thank you for the feedback! Some comments on your issues/suggestions:

1. We'll look into it. Do you want both of them return to As-Launched position or both to return to default position?

2. We're currently working on a tool for precise positioning in editor, but it will take some time (moving parts in editor is handled by completely different code than in flight). Right now you can position as close as you can and then use preset to fine-tune to desired position as soon as you leave the VAB/SPH.

3. It has the same roots as 2. and will be solved too when 2. is solved

4. It is not on our radar right now, and with new custom category filter (coming soon) there will actually be much less clutter in editor.

cool

ad.1. I think as-launched position might offer more flexibility to designs but I feel that return to default might be less error prone (I might be wrong ofc). For me choice no.1 (as-launched) is better but I'll be happy with either solution.

ad.2,3 cool, it's no biggie since as you mentioned it could be fine tuned using presets when launched

ad.4 nice, I can't track whether I asked this question before; are all parts using IR module going to end up in the new tab or just original IR parts?

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

one more thing (since I edited my post too many times:)

"edit3 (lol):

- a nice feature in IR editor window would be some kind of 'send to bottom' (and maybe 'send to top' but this is not as important) button so moving elements to newly created groups is much faster and less error prone. Now, when you have several groups with assigned parts already and wanted to move another part from top group to newly created bottom one it is not easy. You have to move the part through all created groups and consequently rename it first to avoid confusion. With 'send to bottom' button assigning parts to new groups would be much faster imho. "

edit: acutally other solution would be to create a new group on top of other bottom ones instead of at the bottom. Then using current move down/up buttons would work perfectly.

Edited March 30, 2015 by riocrokite

[Ziw]

ad.4 nice, I can't track whether I asked this question before; are all parts using IR module going to end up in the new tab or just original IR parts?

It will be all parts with IR Module.

- a nice feature in IR editor window would be some kind of 'send to bottom' (and maybe 'send to top' but this is not as important) button so moving elements to newly created groups is much faster and less error prone. Now, when you have several groups with assigned parts already and wanted to move another part from top group to newly created bottom one it is not easy. You have to move the part through all created groups and consequently rename it first to avoid confusion. With 'send to bottom' button assigning parts to new groups would be much faster imho. "

edit: acutally other solution would be to create a new group on top of other bottom ones instead of at the bottom. Then using current move down/up buttons would work perfectly.

You know that you can drag and drop servos between groups, right? But creating group on top of everything can be something to look into. We'll try it out on our test build.

[riocrokite]

It will be all parts with IR Module.

You know that you can drag and drop servos between groups, right? But creating group on top of everything can be something to look into. We'll try it out on our test build.

ah I didn't know that Yah group on top would be nice

- - - Updated - - -

sorry with spam; one more thing;

1. would it be possible for IR parts to use bigger attachment nodes? As far as I tested previous version, it could use only size 1 attachment nodes. With bigger nodes IR mechanics would break. Afaik the bigger the nodes the more rigidity in the joint, so it would help with building i.e. heavy-lift cranes

2. same with a relation between moving and fixed object within a part, is it possible to make them more rigid i.e. not detach those two objects of the same element too much under heavy stress?

[ZodiusInfuser]

edit2:

a nice-to-have feature but probably limited to my mod:

- I would be cool to integrate IR with Firespitter's FSmeshSwitch functionality. What that module does is that it lets you switch between different part versions (that reuse same texture) in editor via right-click. In effect it declutters editor window nicely.

Unless you're doing parts that just change in appearance rather than structure then FSmeshSwitch makes a lot of sense. If not, as is the case for the Rework parts, you'll end up with the mesh changing but the attachment nodes remaining the same. Also, FSmeshSwitch would need to be modified to allow for multiple named meshes to be switched to make it work with IR parts. I considered using it for Rework pistons but decided against it for those two reasons.

1. would it be possible for IR parts to use bigger attachment nodes? As far as I tested previous version, it could use only size 1 attachment nodes. With bigger nodes IR mechanics would break. Afaik the bigger the nodes the more rigidity in the joint, so it would help with building i.e. heavy-lift cranes

2. same with a relation between moving and fixed object within a part, is it possible to make them more rigid i.e. not detach those two objects of the same element too much under heavy stress?

AFAIK, there is very limited control available to the IR plugin over how the joints behave, meaning the current behaviour is probably the best that the game allows. Also it doesn't help that most players create very weak contraptions to lift very heavy objects, which would just not work at all if done in the real world.

[StahnAileron]

FYI, just did a quick test of the stock IR provide here (i.e. not using the model rework package): the Rotatrons don't seem to be adhering to the limits set. I see the defaults are -360 to +360. They spin infinitely it seems. I tried inputting my own limit like 0 to 90, but they still go past those limits. Is this by design or a bug?