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

[erendrake]

I am loving the changes in IR, but it's pointless to have a tweakscale config that allows sizes above 199% or so if the bug with scaling IR parts up that large hasn't been resolved...

Again, it is extremely easy to replicate.

Just scale a part up past 1.5x or so, then go try to use it. For example, scale a powered hinge to 400% in the vab, launch, attempt to move it.

To be honest, I have very little interest in having parts scale that high. If they just work that's fine by me but i'm not going to spend time on it. If you care as much as you seem to, we accept pull requests on Github and you are very welcome to contribute.

I am only speaking for myself. Not the others who may be working hard to resolve it.

[AccidentalDisassembly]

To be honest, I have very little interest in having parts scale that high. If they just work that's fine by me but i'm not going to spend time on it. If you care as much as you seem to, we accept pull requests on Github and you are very welcome to contribute.

I am only speaking for myself. Not the others who may be working hard to resolve it.

That's fine if you don't want to, your work, so your call, obviously. Though I would argue it would be a shame to only half support TweakScale.

Sadly, I wouldn't know what to request you pull, but I can at least do teensy bits of feedback re: exceptions and the like.

New version on a (relatively) clean copy of KSP throws an exception when placing the first IR part after loading the VAB scene.

Steps:

1. Load VAB scene, place a part or two, then place first IR part onto those. Exception thrown.

2. Doesn't throw more exceptions when you place additional parts, remove and re-place.

3. Re-loading VAB scene (exit and re-enter to same craft or doing a new craft) resets whatever is going on, and placing first IR part will again throw exception.

Log: https://dl.dropboxusercontent.com/u/59567837/output_logNewIR2.txt

[Ziw]

That's fine if you don't want to, your work, so your call, obviously. Though I would argue it would be a shame to only half support TweakScale.

Sadly, I wouldn't know what to request you pull, but I can at least do teensy bits of feedback re: exceptions and the like.

New version on a (relatively) clean copy of KSP throws an exception when placing the first IR part after loading the VAB scene.

Steps:

1. Load VAB scene, place a part or two, then place first IR part onto those. Exception thrown.

2. Doesn't throw more exceptions when you place additional parts, remove and re-place.

3. Re-loading VAB scene (exit and re-enter to same craft or doing a new craft) resets whatever is going on, and placing first IR part will again throw exception.

Log: https://dl.dropboxusercontent.com/u/59567837/output_logNewIR2.txt

Exception is thrown by blizzy's toolbar. I'll check our interaction with it in a bit.

EDIT: I cannot reproduce this. On your blizzy's toolbar did you add IR as a button?

Edited April 3, 2015 by Ziw

[ZodiusInfuser]

I am loving the changes in IR, but it's pointless to have a tweakscale config that allows sizes above 199% or so if the bug with scaling IR parts up that large hasn't been resolved...

Again, it is extremely easy to replicate.

Just scale a part up past 1.5x or so, then go try to use it. For example, scale a powered hinge to 400% in the vab, launch, attempt to move it.

You'll have to wait until the Tweakscale dev (who is also a dev on IR) gets back from his break before some serious time can be spent looking in to this

For now I suggest you add an issue to the projects Github so it remains on our to-do list. Save you asking about it after each new release.

[Albert VDS]

Is there a plan to try and make the connections for each IR part stronger, so that stuff like this doesn't happen:

[riocrokite]

Is there a plan to try and make the connections for each IR part stronger, so that stuff like this doesn't happen:

http://i1363.photobucket.com/albums/r716/albertvdsluis/irbug_zpsfe6c5291.png

stiffness of joints are connected to part's mass (game mechanic). You can edit those parts mass and increase it considerably for more stiffness.

[ZodiusInfuser]

stiffness of joints are connected to part's mass (game mechanic). You can edit those parts mass and increase it considerably for more stiffness.

Ok, maybe it's time for the rework to do a propper balancing pass on all its part masses. Could use pointers on what masses produce good results.

[erendrake]

New Version is available! v20c

HERE

Changes:

* Minor UI Events renames

* Bugixes: invertAxis&Keys persistense, min/max range tweakbles hidden for translating parts

* Fixed min/max range ot showing in Flight for translating parts

* Peristence Related BugFixes + InvertAxis Button

[Kurbis]

19.3 or WIP. is this one stable to use

[Ziw]

Pretty stable, I use it on my main save. But it's all down to parts and Zodius did make some changes so don't forget to install deprecated pack if you used his parts before.

[Kurbis]

I haven't used it before. Should I download that model rework to, or is it included.

[Ziw]

I haven't used it before. Should I download that model rework to, or is it included.

It is a separate download. If you haven't used it before - you won't have any problems.

[allmhuran]

Erm. Is it possible to set the speed of parts to increments other than those available in the GUI?

I was working on a keyframe animator but it requires that I be able to set the servo speed to any continuous value. I figured this was already possible but I got to the end of writing all the code and found out that no, I can only set coarse speed to minimum increments of 0.1, even programmatically (through KOS). I spent a lot of time trying to figure out what the bug in my code was.

So, although I was happy to determine that my code was good, discovering this limitation was something of a table flipping moment.

- - - Updated - - -

Also, is there no other way to improve the servo strength/stiffness/resistance than increasing their mass? How did KJR work?

[Ziw]

Erm. Is it possible to set the speed of parts to increments other than those available in the GUI?

I was working on a keyframe animator but it requires that I be able to set the servo speed to any continuous value. I figured this was already possible but I got to the end of writing all the code and found out that no, I can only set coarse speed to minimum increments of 0.1, even programmatically (through KOS). I spent a lot of time trying to figure out what the bug in my code was.

So, although I was happy to determine that my code was good, discovering this limitation was something of a table flipping moment.

- - - Updated - - -

Also, is there no other way to improve the servo strength/stiffness/resistance than increasing their mass? How did KJR work?

Speed field is now named "Speed", not "Coarse speed". If your code works with "Coarse Speed" then you're using 0.19.3 version.

I've finished writing the API for IR, so as soon as it gets through QA we can implement it in KOS to make your life easier. But it will take some time still.

I'll check in the code, but in reworked plugin there are no specific limitations on Speed field, except that it could not be 0.

You must also keep in mind that Speed is a multiplier to part's default speed written in cfg

[allmhuran]

Yep, I wrote this thing in the old version and was wondering whether things had changed in the new. Looks like they have which is good! I haven't tried the code with the new version yet.

I already made a test vehicle and KOS script to spit out the actual speed for each part for a given set speed, so no issues with having different part speeds or multipliers.

Of course, the acceleration now makes things harder, since I don't have a known speed throughout a movement.... Dammit. Can acceleration be set to "instant"?

[Ziw]

Yep, I wrote this thing in the old version and was wondering whether things had changed in the new. Looks like they have which is good! I haven't tried the code with the new version yet.

I already made a test vehicle and KOS script to spit out the actual speed for each part for a given set speed, so no issues with having different part speeds or multipliers.

Of course, the acceleration now makes things harder, since I don't have a known speed throughout a movement.... Dammit. Can acceleration be set to "instant"?

New preset system may help you with your keyframes, no?

[allmhuran]

Might do. But I believe the positions must be sequential? The keyframer will move between any preset positions at a speed tied to the throttle. But all servos need to be synched up. This means getting their relative speeds (done), and also knowing how long the frame will take to execute, or checking that the parts have reached their goal... but you'd need to check all parts, because some might not move in a particular frame. And if none move then the frame will instantly advance, which is not what I want, successive keyframes in the same position should be a delay.

In other words, the only reliable way to know when to advance a keyframe is to know when the frame time is up, but knowing how long a frame should last depends on knowing the speed of the servos, and having that speed be tied directly to the throttle through the movement. Acceleration makes things pretty much impossible. Sure, if I know exactly how the acceleration was affecting the speed (by looking up, say, "actual speed" during acceleration - if that's even an available field) I could continuously recalculate. But this would be hellishly expensive.

Edited April 6, 2015 by allmhuran

[allmhuran]

I've just downloaded the very latest plugin rework. It seems that if I set "move to next/previous preset" to an action group, the action group has to be pressed twice before it moves. Haven't seen this mentioned yet.

Edit: Ah... I see from KOS it's an action, therefore must be turned on and off.

Also, currently moving to "next" preset takes you to the end of the list, but it doesn't cycle back to the start. You have to "move previous" through all the presets to get back to a starting position. This does prevent someone from accidentally going "too far" I suppose, but it also means you can't cycle through presets in a loop.

Edited April 6, 2015 by allmhuran

[Ziw]

Here's a WIP preview of what would be possible to do with API. Please ignore ugly UI, it needs a lot of polish

[allmhuran]

Ah, now that looks very useful indeed. I will put my project on hold.

In the meantime I tried the new version again, with the new part pack as well. The new parts really do look great.

I thought maybe my last mech was too heavy because it was wobbling around a lot, so I tried building something... rather lighter. Cut down from 50 tons to about one and a half. And yet... the wobbles. Oh my god the wobbles.

If there's no way to rectify this I unfortunately don't see much use for IR. Surely someone has a solution to this. Here's a clip: https://gfycat.com/SecondHandyAffenpinscher

Edit: I understand there's limitations because of unity/KSP itself, but maybe there's an outside the square solution. Like giving IR parts enormous SAS torque. Or maybe automatically "welding" the joint when it's not engaged... there's a welding mod that works for independent parts, maybe someting like that could work within the IR part? Welding wouldn't be perfect (would still be a bit wobbly while moving) but would be a big improvement.

Edited April 6, 2015 by allmhuran

[Darren9]

Probably to soon to ask but a "Wait" waits until the joint gets to it's set position? If it is will it wait until all the above joints have reached there position? Is this what kOS will be able to access? Looks like fun.

[The Space Man]

Here's a WIP preview of what would be possible to do with API. Please ignore ugly UI, it needs a lot of polish

http://i.imgur.com/2jGv1wh.png

Would that make it easier build walking mechs without using KOS?

[allmhuran]

Probably to soon to ask but a "Wait" waits until the joint gets to it's set position? If it is will it wait until all the above joints have reached there position? Is this what kOS will be able to access? Looks like fun.

I hope it's not an actual wait, since that suspends all KOS processing. You'd want to be able to do other stuff while the joints move.

[erendrake]

Would that make it easier build walking mechs without using KOS?

This API will be made available to kos so you can do all of the same stuff that @ziw's sequencer does.

I hope it's not an actual wait, since that suspends all KOS processing. You'd want to be able to do other stuff while the joints move.

It would be non blocking

[allmhuran]

Good stuff!