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

[StahnAileron]

Question: Any chance we can get the feature of re-ordering whole groups? The drag and drop function is cool and all, but with large systems (more than the window can display without scrolling) and/or many groups, I think it would be just easier to move groups next to each other to swap servos between them via the arrow buttons. Also, it would allow more logical, arbitrary ordering of commands. I was messing around with groups and the last group of servos I wanted to be last in the list (and be activated) somehow wound up as the first group in the list (this was from a sub-assembly, though the original ordering before I made it a sub-assembly was correct... But making that into a sub-assembly require using another sub-assembly first... Yeah, one of those...)

Also, you say there is a memory leak associated with the drag and drop function. Maybe this will mitigate it for now. I do know that ever since I started using the new rework plugin, I can't play for more than maybe an hour or two before crashing from out of memory issues. Even faster if I'm in flight it feels like. Perhaps related, the game is stuttering far more than I recall prior to using IR again. To the point of slideshow. I'm pretty sure there's something else in my install feeding into this (what with >40 plugins & mods), but IR seems to be exacerbating the problem. I think the memory leak is causing Unity's GC to kick in a lot more often. I was just punted from a game session while sitting on the runway testing an IR-based probe to check Pivotron settings. I got a slideshow a couple of times - about 3.3GB RAM being used by KSP at that point; crashed at around 3.5 when I tried to revert back to the SPH. It seems anything I fly with IR parts in it does this during some point in my flights. Usually during burns in space and somewhere in the 30k to 50k alt range over Kerbin. The latter I think might have NEAR compounding the issue. I'll have to test a non-IR using vessel at some point later to be sure.

I'm just screwing around with the game at this point... The crashes have been preventing me from putting up a comm network (RemoteTech) in a timely fashion. I've been spending time trying to hunt down performance issues instead. (I finally pinned down the add-on that was spamming my log: last official release of TacFuelBalancer was calling a deprecated function for highlighting parts - the newer, un-official 0.90 compatibility release fixed that.)

Lastly: symmetry cloned parts don't seem to be carrying over user set limits. I was using some right-angle Extendotrons from the model rework. I was offsetting the minimum limit to 0.1 to prevent some clipping. Every time I used symmetry, the limit on the new cloned part would be 0.0, though it would be sitting at 0.1 physically.

Also, Rotatrons from the model rework seem to have some issues with the reset function (in the Editor at least). I engaged limits, modified them (90 degree range), moved them to check, then hit reset (while they were NOT at either limit) to adjust some things and re-test, but the Pivotrons had reset to REALLY weird orientations (this was done using the off-angle one.) Not sure if this is a model or plugin issue. Been staying away from Rotatrons for now.

[Ziw]

Question: Any chance we can get the feature of re-ordering whole groups? The drag and drop function is cool and all, but with large systems (more than the window can display without scrolling) and/or many groups, I think it would be just easier to move groups next to each other to swap servos between them via the arrow buttons. Also, it would allow more logical, arbitrary ordering of commands. I was messing around with groups and the last group of servos I wanted to be last in the list (and be activated) somehow wound up as the first group in the list (this was from a sub-assembly, though the original ordering before I made it a sub-assembly was correct... But making that into a sub-assembly require using another sub-assembly first... Yeah, one of those...)

It is a problem currently with groups, we can try to enable Group Drag And Drop, but with recent discovery of memory leaks there it does not seem very prudent thing to do. Another issue with groups is that they are parsed from parts when the ship is loaded. Sometimes the parsing order does not equal the way you set the groups up in editor. I have some ideas on how to fix that, but it might be a breaking change, meaning some of the older crafts might stop working as intended.

Also, you say there is a memory leak associated with the drag and drop function. Maybe this will mitigate it for now. I do know that ever since I started using the new rework plugin, I can't play for more than maybe an hour or two before crashing from out of memory issues. Even faster if I'm in flight it feels like. Perhaps related, the game is stuttering far more than I recall prior to using IR again. To the point of slideshow. I'm pretty sure there's something else in my install feeding into this (what with >40 plugins & mods), but IR seems to be exacerbating the problem. I think the memory leak is causing Unity's GC to kick in a lot more often. I was just punted from a game session while sitting on the runway testing an IR-based probe to check Pivotron settings. I got a slideshow a couple of times - about 3.3GB RAM being used by KSP at that point; crashed at around 3.5 when I tried to revert back to the SPH. It seems anything I fly with IR parts in it does this during some point in my flights. Usually during burns in space and somewhere in the 30k to 50k alt range over Kerbin. The latter I think might have NEAR compounding the issue. I'll have to test a non-IR using vessel at some point later to be sure.

Memory leaks related to IR are substantial only in VAB/SPH, trust me I did quite an extensive testing of this matter. As for performance - our code is not very CPU intensive, especially when you're not moving the parts, so it is most likely something else. In my experience Ship Manifest was an unexpected reason to a very low performance on my quite beefy system and I had to delete it. Since then the author made some changes to the code, but I haven't tested them since.

Lastly: symmetry cloned parts don't seem to be carrying over user set limits. I was using some right-angle Extendotrons from the model rework. I was offsetting the minimum limit to 0.1 to prevent some clipping. Every time I used symmetry, the limit on the new cloned part would be 0.0, though it would be sitting at 0.1 physically.

Also, Rotatrons from the model rework seem to have some issues with the reset function (in the Editor at least). I engaged limits, modified them (90 degree range), moved them to check, then hit reset (while they were NOT at either limit) to adjust some things and re-test, but the Pivotrons had reset to REALLY weird orientations (this was done using the off-angle one.) Not sure if this is a model or plugin issue. Been staying away from Rotatrons for now.

Problem with symmetry is known, and we're working on it. If you change the Limits via right-click menu all symmetry counterparts are updated accodingly, but in servo editor window you have to change them again manually after tweaks.

Can you post a screen shot of weird actions for off-axis pivotrons?

[StahnAileron]

It is a problem currently with groups, we can try to enable Group Drag And Drop, but with recent discovery of memory leaks there it does not seem very prudent thing to do. Another issue with groups is that they are parsed from parts when the ship is loaded. Sometimes the parsing order does not equal the way you set the groups up in editor. I have some ideas on how to fix that, but it might be a breaking change, meaning some of the older crafts might stop working as intended.

Memory leaks related to IR are substantial only in VAB/SPH, trust me I did quite an extensive testing of this matter. As for performance - our code is not very CPU intensive, especially when you're not moving the parts, so it is most likely something else. In my experience Ship Manifest was an unexpected reason to a very low performance on my quite beefy system and I had to delete it. Since then the author made some changes to the code, but I haven't tested them since.

This is actually very good to know. I have SM, but barely use it. I'll see if removing it helps me. I have an i7-4771 (stock @3.5GHz) with an HD7970@2GB and 16GB of system RAM, so I expect a bit better performance than what I've been experiencing lately.

For group ordering, can you just give whole groups their own ordering arrows, like the servos themselves? It's messy for sure, but I think being able to re-order groups would be quite handy.

For saving the groups, perhaps using something similar to how Action Groups Extended does it might work to keep the ordering? AGX uses a central external file to store configs for each vessel and loads the configs based on an internal vessel ID it generates (or so it looks to me. I had a conflict with AGX and KIS, so I was working that issue for about a week...) The file is stored in the respective save game folder.

Oh, not sure if you can reuse the code, but Alternate Resource Panel has a drag and drop system for reordering resources it displays. Perhaps looking at that might help? (I think there was another mod I saw that had drag and drop functionality for its displays... I think it might've been MechJeb...)

Problem with symmetry is known, and we're working on it. If you change the Limits via right-click menu all symmetry counterparts are updated accodingly, but in servo editor window you have to change them again manually after tweaks.

Can you post a screen shot of weird actions for off-axis pivotrons?

So it's really an interface issue? Hmm... Guess I'll just have to adjust my workflow to account for that.

I need to head out for class soon. I'll look into reproducing the pivotron thing I came across once I get back. (I want to test removing SM as well.

Edited April 9, 2015 by StahnAileron

[allmhuran]

Huh.

So in the previous version it seems like speeds were limited to preset increments, but you could set min and max arbitrarily.

Now, at least in the GUI, min and max seem to be restricted to preset increments. I added an extendatron, opened the group config, and tried to set maximum extension to 0.27. But what was entered was 0.25.

The first time I thought I'd made a typo, so I entered it again. Press "7".

Mod: "5".

Me: "No. You have a place where I can enter a number. I am entering 7, and I bloody well expect you to put a 7".

Mod: "5".

Me: "7!".

Mod: "5".

Here's the really weird and annoying part: Sometimes increments of 0.1 work, and other times not.

Typed value    Value entered into GUI
0.20             0.20
0.21             0.21
0.22             0.22
0.23             0.25
0.24             0.25
0.25             0.25
0.26             0.25
0.27             0.25
0.28             0.3
0.29             0.3

Edited April 11, 2015 by allmhuran

[Ziw]

Huh.

So in the previous version it seems like speeds were limited to preset increments, but you could set min and max arbitrarily.

Now, at least in the GUI, min and max seem to be restricted to preset increments. I added an extendatron, opened the group config, and tried to set maximum extension to 0.27. But what was entered was 0.25.

The first time I thought I'd made a typo, so I entered it again. Press "7".

Mod: "5".

Me: "No. You have a place where I can enter a number. I am entering 7, and I bloody well expect you to put a 7".

Mod: "5".

Me: "7!".

Mod: "5".

Here's the really weird and annoying part: Sometimes increments of 0.1 work, and other times not.

Typed value    Value entered into GUI
0.20             0.20
0.21             0.21
0.22             0.22
0.23             0.25
0.24             0.25
0.25             0.25
0.26             0.25
0.27             0.25
0.28             0.3
0.29             0.3

If you don't right-click the part after entering the correct value in the Servo Configurator window, it will stay as entered. The right-click menu seems to snap to nearest 0.05 as soon as you open it. I'll look into it, but for now you have a workaround.

Edit: this will be fixed in the release.

Edited April 11, 2015 by Ziw

[smjjames]

While trying to test this craft, after I had set the basic rotatron (the one on the SAS wheel) to a speed of 2k, IR started spitting out this error when I tried to have it rotate. The numbers on the control panel would change, but it doesn't rotate. It actually worked with an earlier test at a slower speed.

NullReferenceException: Object reference not set to an instance of an object

at InfernalRobotics.Module.MuMechToggle.DoRotation () [0x00000] in <filename unknown>:0

at InfernalRobotics.Module.MuMechToggle.UpdatePosition () [0x00000] in <filename unknown>:0

at InfernalRobotics.Module.MuMechToggle.FixedUpdate () [0x00000] in <filename unknown>:0

Edit: It seemed to be because it wasn't actually connected to the SAS wheel thing.

Edited April 11, 2015 by smjjames

[allmhuran]

If you don't right-click the part after entering the correct value in the Servo Configurator window, it will stay as entered. The right-click menu seems to snap to nearest 0.05 as soon as you open it. I'll look into it, but for now you have a workaround.

Edit: this will be fixed in the release.

Yep, that works. I had the right click menu open at the time because I was copying the "current value" to use as the max, your workaround does the job.

[allmhuran]

I think I might be done.

Been working on this timberwolf for about three weeks now. Probably 100 hours if you added it all up. Been through several different versions, updating it for looks, for KOS, for new IR. Building it takes a really long time, not just trying to find exactly the right parts for the shape. There's also the game crashing every 5 or 6 reverts, symmetry bugs, node-disappearing bugs, and so on. Then when I can find no way to make the IR parts strong enough to resisit wobbling I decide to rebuild the whole thing.

Finally got to here earlier today. This is the most accurate twolf I could get and it only weighs about 20 tons, 15 without the BDarmory additions. Been working on figuring out how to do the feet most of the night.

So I finally finished some feet that I liked, and it was time to start working on the actual animation for walking. Updated my KOS script for the new version of IR, replacing references to "rotation:" with "rotation" instead (but still "translation" for the translating parts... why not just "position"? Still annoying). Recalculating base speeds, and so on.

Then I get to the basic tests, making sure all the parts actually move in the right direction. I have a KOS script for that too.

Finally it's time to start setting up positions, using action groups to test each little bit. I start with the knees. But of course, they don't turn properly. I tell them to move and the leg just tears itself apart.

Great.

I start stripping pieces off, changing angles, changing attachment points, removing doubled-up servos, and so on, until I get down to the root of this particular problem. No doubt there would be dozens or hundreds of others just like it. Here it is:

http://gfycat.com/DemandingIdealisticAntarcticgiantpetrel

And that's it, that's me done. I can't do this anymore. Too much time invested for too many "WHY DON'T YOU WORK?? AAAGH" style frustrations.

[allmhuran]

I'm a sucker for punishment.

Amongst other possibilities, the KAS grappling hook seems to mess up the joint every time. I have also posted this to the KAS thread. Grappling hook on far left "toe":

http://gfycat.com/SevereElaborateIndianglassfish

[allmhuran]

Would also be good if there was a way to be precise with the position editor in the VAB. I click a button as quickly as possible trying to get two to match rotation, trying to move one of them 0.07, but the thing jumps about .85.

[Ziw]

Would also be good if there was a way to be precise with the position editor in the VAB. I click a button as quickly as possible trying to get two to match rotation, trying to move one of them 0.07, but the thing jumps about .85.

You can create a temporary preset, type in correct value and move parts to this value by clicking the Move-To button in Preset Editor window.

[allmhuran]

That'll do for now, cheers.

It's coming along, geometry is all done and at least it can balance on one foot while firing the GAU-8's. Still no walking yet, lots of things to work around before I even get the legs moving without disintegrating lol.

Edited April 12, 2015 by allmhuran

[allmhuran]

When reordering servos within a group the order isn't currently saved. Not sure if dragging to reorder was even meant to work or if it was just for moving stuff between groups, but it would be nice if it did save the order for organization purposes.

The order of positions in the position editor also seems out at moment. If I "reorder" them (by swapping the values), save and close, then reopen, the positions are back to where they were. This might be related to only being able to move to adjacent positions right now, but it's happening with just two positions created, which are of course always adjacent, so should be able to be reordered.

Edited April 12, 2015 by allmhuran

[ZodiusInfuser]

When reordering servos within a group the order isn't currently saved. Not sure if dragging to reorder was even meant to work or if it was just for moving stuff between groups, but it would be nice if it did save the order for organization purposes.

It is currently not intended for the order of servos within groups to be saved (not the order of groups themselves), but its on the list to be resolved in the future.

The order of positions in the position editor also seems out at moment. If I "reorder" them (by swapping the values), save and close, then reopen, the positions are back to where they were. This might be related to only being able to move to adjacent positions right now, but it's happening with just two positions created, which are of course always adjacent, so should be able to be reordered.

Presets will always be in ascenting order, not just sorted to be adjacent. This is intended behaviour. Unless you are talking about another bit of the plugin?

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

On an unrelated note, here's a new preview of the Servo Sequencer addon Ziw and I have been working (this is separate to the main IR plugin):

[Ziw]

Here's the sneak peek of IR API capabilities coming in the next release

https://github.com/MagicSmokeIndustries/InfernalRobotics/wiki/Using-the-IR-API

Please do not try to use it in your mods yet.

EDIT: We've solved the memory leak, hooray!

Edited April 12, 2015 by Ziw

[allmhuran]

Presets will always be in ascenting order, not just sorted to be adjacent. This is intended behaviour. Unless you are talking about another bit of the plugin?

Yep, talking about the little preset window. I do see the rationale behind that sort order, it's a bit weird because it reorders the position when you click into the text box, makes it easy to accidentally edit the wrong entry. But I have gotten used to it. With legs the position values move back and forth through the animation so the ordering doesn't match up, but I'm only using the preset editor to get precise values anyway. I won't be using presets actually move the legs so no problem there.

Sequencer looks pretty good. I will probably stick to my KOS script because it works the opposite way (I set position keyframes and the script calculates the speed and direction required to get all of the servos there at the same time, rather than me figuring out the speed and direction), but my way is pretty specific to trying to get something complex like legs to work, where it's easier to move things around beforehand in the SPH to make sure the result keeps feet flat on the ground etc. Your way should be much simpler and easier for most purposes.

Edited April 12, 2015 by allmhuran

[Ziw]

That'll do for now, cheers.

It's coming along, geometry is all done and at least it can balance on one foot while firing the GAU-8's. Still no walking yet, lots of things to work around before I even get the legs moving without disintegrating lol.

http://i.imgur.com/76OPqC3.png

That is an awesome recreation already! I'm fastforwarding the kOS-IR integration project just for you!

[allmhuran]

LOL cheers. I imagine it will get a lot of use, using KOS to run IR just makes too much sense for people not to do it.

If I ever do in fact manage to get it to walk, I will send you the craft and script, and of course I'll be making a video. Might be a good promo for both mods. Again... IF

[Azimech]

Originally Posted by allmhuran

I'm talking about in the editor, not after launch.

I want to align something in the editor, but I want it to move freely when launched.

Specifically, I want to rotate the free joints in order to strut and dock-on-physics-load the joints as shown by the red lines here

Hmm, I see now, it is a valid request. Unfortunately this will have to wait until next week, as I need to consult with Zodius whether or not allowing Editor movement of uncontrolled parts can break anything and he is away. Uncontrolled parts are slightly different in handling from what I've heard.

Wouldn't it be easier to A: control the parts in the editor as usual. B: after parts are set, use a tweakable to switch them to uncontrolled. I'm no coder but it's something I would do.

[Stikkychaos]

Looks nice, but... HOW DO I GET IT TO WORK. I get only basic parts and basic models :/

[JeffreyCor]

The rework is the plugin, it doesn't LOOK like anything (apart from the GUI) the parts are a different parts rework listed on the first page.

[allmhuran]

By the way, the KOS integration isn't actually my main hurdle. Yeah, the current animator code is a bit inelegant/verbose/hard to read with all the testing for part type before any operations, but it does work.

The biggest issues for me at the moment are these:

- The inability to manipulate uncontrolled joints. I don't think many people will have this requirement, but I need it because my mech's legs are connected at multiple points, and I need to align the pistons angles with the docking ports in each keyframe, although all of this is mostly because of the next one...

- Joint stiffness. I only need to do the multiple point connections because the IR joints and connections are loose. I know there has been a lot of discussion about this one in the past, but it actually looks like there might be some kind of solution possible after all. The reason why I think this is that the new rework model rotatrons are, for some reason, *far* more rigid than the docking washers. Check out this docking washer sliding around on the hip, compared with the rigidity of the new ones, which are used in the hips and knees on this version, which doesn't flex at all even when dropped. Why the new ones are more resistant to flexing, I have no idea. You can see that the new model hinge pivotrons used in the feet of the second gfy have really weird connections, see how far they compress into the girders attached to them, causing the mech to bounce when it lands. So the rigidity is not universal across the new models.

- Odd joint behaviour. Sometimes joints don't move the way you want them to (like this leg disintegration gfy from earlier). I can't figure out how to reproduce this reliably. I know for sure that the KAS grappling hook causes issues (which is the problem in that example), but that's probably just a mod compatability thing, not a problem with the IR behaviour as such. But occasionally I'll attach a stock part (like a wing section), test the motion, and the something will resist the servo causing it to turn off-axis or fall apart. It's as though an incorrect movement transform is being applied to some of the parts in the tree parented by the robotic part. Could be to do with using offset gizmos, could be a clipping issue... I haven't been able to pin it down. But when it happens it usually means pulling the entire section apart and rebuilding it (and hoping it doesn't happen again). Very time consuming.

- The in-VAB GUI is also a bit hard to navigate. It's not hard to understand, it just takes a bit of hunting and looking-closely to find servo/configuration/value you're after, and then a lot of care to make sure you're doing what you actually want to do. I can do a little video of me using this to show you the difficulties if that would help. But I expect the GUI components available are a bit limited, and it looks like you sensibly don't want the window to get too big because this would interfere with the actual geometry interface, particularly since mouse event bubbling is an issue here (clicking buttons will remove parts from your craft), but that's a bug in the base KSP GUI as far as I know, not a bug in the mod.

Edited April 13, 2015 by allmhuran

[Ziw]

Our editor windows should be click-through proof, i.e. clicking mouse inside our windows should not affect parts. Let me know if its not the case for you.

There are a lot of UI limitations, but post the video, maybe there is something we can try to fix.

As for joint rigidity - we are looking into it, but no solutions found thus far.

[ZodiusInfuser]

As for joint rigidity - we are looking into it, but no solutions found thus far.

One thing you can try allmhuran is increase the mass of all the robotics parts you use in their cfg files. Its been mentioned that this affects joint strength but I've not had time to do a reliable test case.

[allmhuran]

I did (previously) indeed try increasing the mass on the old washer. I didn't notice much difference. Or, perhaps said better, the difference between the old docking washer and the new rotatron certainly seems to be vastly more significant.

I will do some dedicated testing tonight to really probe this further, but right now it does seem like some of the joints are significantly stronger than others. I could be mistaken... it could be something to do with how they are attached to their parent, or perhaps how their children attach to them. Proper scientific testing is required. But in the meantime if you can think of anything that makes the new rotatron different from the old docking washer (other than the raw geometry, obviously), that might be the key.

I'll put together some click through gfys, pretty sure I've accidentally taken parts off but again, could be my faulty memory. Will perform some proper testing for you tonight.

Overall I should mention that BY FAR my biggest issues with building right now are to do with the game crashing after half a dozen reverts, and the problem with symmetry getting stuck on radial. These are bugs in the base game that, afaik, have nothing to do with any mods and which take up much more of my time than working around any issues with IR, KAS or KOS. Testing IR craft (or, really, any complex craft) requires a lot of launches and a lot of tweaking, and when the game has a memory leak that happens on revert... yeeesh. I spend half my time looking at the KSP loading screen, lol.

Edited April 13, 2015 by allmhuran