[0.90] Magic Smoke Industries Infernal Robotics - 0.19.3

[jake9039]

Is there a way to keep the top and bottom nodes from rotating (the fuel tank and cupola remain fixed), and have the rotating section in the middle? Kind of like this:

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

put some free spinning docking washers on there. it will then rotate on it's own with power. also, strut the top and bottom so they stay in the same place proportionate to each other(it might colide with the center might not.)

[ctbram]

Hinge Creep! I am having an issue where every time I cycle a hinge the ZERO point and the max extended points are creeping. I have attached an image and you can see that at what should be the 90 degree zero point the hinges are actually around -5 deg. If I keep cycling the hinges the creep gets worse each cycle!!!

What is causing this? The hinges are completely useless to me if this is how they are going to behave and there is no way to reset them to the proper 90 degree angle at the zero position.

[Master Tao]

@Angel-125:

You can cheat by using two parts, like the IR Station Hub.

@p331083, ctbram:

No, no fix for the creep issue. sirkut was looking into it, but is currently busy.

And p331083, thanks for going above and beyond in reading back to see if the bug had already been brought up.

[Angelo Kerman]

put some free spinning docking washers on there. it will then rotate on it's own with power. also, strut the top and bottom so they stay in the same place proportionate to each other(it might colide with the center might not.)

Well all be, that does work! Thank you much! Now I can make a custom docking washer and motor.

@Angel-125:

You can cheat by using two parts, like the IR Station Hub.

@p331083, ctbram:

No, no fix for the creep issue. sirkut was looking into it, but is currently busy.

And p331083, thanks for going above and beyond in reading back to see if the bug had already been brought up.

Oh that's exactly what I needed! Thanks!

Edited March 5, 2015 by Angel-125

[Space Scumbag]

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.

Any thoughts on this, anyone? Such a feature could replace KOS for simple movements. Please make it happen

[erendrake]

Any thoughts on this, anyone? Such a feature could replace KOS for simple movements. Please make it happen

that should be simple enough to do with kOS. why not just do that?

[Space Scumbag]

that should be simple enough to do with kOS. why not just do that?

Because it would be even simpler and faster if it is build into this mod. I never really tried KOS. For my crafts, I would have to program dozen of hinges etc.. Don't know how much time that costs.

[erendrake]

Because it would be even simpler and faster if it is build into this mod. I never really tried KOS. For my crafts, I would have to program dozen of hinges etc.. Don't know how much time that costs.

the reason i spoke up is that as soon as this 'wave' action gets implemented someone is going to say "well, i want that but i want it to only go 30% up then back down" and that process can go on and on forever with more actions. Or we could let Sirkut work on other stuff you cannot do with kOS.

as far as how long that would take, you can always ask us over in the kOS thread. we are pretty friendly.

[pellinor]

Hi everyone,

I'd like to show a pet project from the last couple of days. After getting stuck with some TweakScale problem, I took a break to play with another thing I always wanted to do: smooth interpolation for IR.

The result is a small interpolator class that takes commands in the form "go to position X at speed Y", and takes care of

* acceleration limit

* speed limit

* position limits (for finite movement range)

* modulo behavior (for freely rotating axes)

So far, I somehow hacked the interpolator into IR for testing. The first tests with a fast rotatron look pretty good:

The test rotor takes its time to build up speed, and is still reasonable stable around 1500 deg/s, which is 30deg/frame.

With just two float parameters, the commands include all that IR currently offers. They would also be a great interface to other plugins.

[cmdPos / cmdVel]
x /  0      : stop
x /  v      : move to pos=x at speed 10
x / inf     : move to pos=x as fast as you can
+-inf / v   : move forward/back at speed v
+-inf / inf : move forward/back as fast as you can 

I can't publish a test version yet as the interface is still too bad (all parameters are hardcoded).

[Galane]

Nifty. Can you also give it a speed ramp down? The powered docking washers could use the same treatment.

What would really be slick is a single piece hub with two stacked, counter-rotating sections for building concentric rotor helicopters. I made a test one using powered washers and small fuel tanks and an edited cfg for one of the stock rectangular wing panels for the rotor blades.

Functional but the rotors are either full on or off, instant top RPM and instant stop. Makes it very hard to fly. A speed slider would be exceptionally useful, move it and it stays there without having to hold down a key or dedicate an action group to hold it on.

co-axial rotor test by g_alan_e, on Flickr

[pellinor]

Nifty. Can you also give it a speed ramp down?

Of course, the acceleration limit applies to braking as well. This thing is designed to stay within its limits no matter what commands you throw at it. It will slow down on its own when approaching end positions. When given a commandPos closer than the current braking distance, it will overshoot and come back.

The powered docking washers could use the same treatment.

A speed slider would be exceptionally useful, ...

This is not meant as a patch for a specific part, but as a core piece of IR (provided the current maintainers are interested in it). I would envision a code structure consisting of

* A UI layer that creates commands. Ideally, it would let the user create custom buttons or sliders and bind them to commands. This layer does not need to enforce any limits.

* The interpolator takes commands and updates positions. This layer takes care of part-specific or user-defined limits, modulo behavior etc. It does not know any of the other objects.

* A physics layer that takes the positions and updates part transforms, nodes etc. It knows the part-specific stuff (like the difference between rotation and translation) and provides limits for the other layers.

[Ziw]

One thing IR really needs IMO is some kind of interval movements commands, like - "Rotate 1 degree" or "Translate 1mm". I know that I can do this through KOS (which I already did), but it is such an unnecessary chore, IMO better to be implemented inside IR.

[Angelo Kerman]

@Master Tao: Thank you for pointing me in the direction of the IR Station Hub. That was exactly the right piece of the puzzle for me to get the hub I have in DSEV working. After struggling with the ConfigurableJoint for the better part of a week, I tossed out my code in favor of using Infernal Robotics. now people will need to download IR if they want to use the DSEV hub.

I also noticed that when using the hub, if it is spinning during timewarp, then it will likely break the ship when it comes out of warp. I also noticed that starting/stopping the hub happens abruptly, and can break the ship if too much mass is on the hub and the rotation is high. Fortunately, I now have a solution that works great for DSEV, but I wanted to share it here in gratitude for the help. Please check out SpinHub, up on GitHub. It has action buttons to start and stop the hub as well as change direction, and context-menu buttons to do the same. SpinHub accounts for timewarp too, so if your hub is spinning during timewarp, it stops the spin so that the ship won't break when coming out of timewarp.

To use SpinHub, just include the following in your config file:

MODULE

{

name = HubHelper

}

I hope that helps people who may have run into the same problems that I did. Thanks again.

Edited March 6, 2015 by Angel-125

[sirkut]

Of course, the acceleration limit applies to braking as well. This thing is designed to stay within its limits no matter what commands you throw at it. It will slow down on its own when approaching end positions. When given a commandPos closer than the current braking distance, it will overshoot and come back.

This is not meant as a patch for a specific part, but as a core piece of IR (provided the current maintainers are interested in it). I would envision a code structure consisting of

* A UI layer that creates commands. Ideally, it would let the user create custom buttons or sliders and bind them to commands. This layer does not need to enforce any limits.

* The interpolator takes commands and updates positions. This layer takes care of part-specific or user-defined limits, modulo behavior etc. It does not know any of the other objects.

* A physics layer that takes the positions and updates part transforms, nodes etc. It knows the part-specific stuff (like the difference between rotation and translation) and provides limits for the other layers.

I'll implement any feature that the masses want. Just let me know when you are ready and I'll make some time to bring it into the code. I've just been swamped with work & family life that I haven't had time to work on outside projects BUT with that being said if there are developments such as this I'll gladly pull them in.

[pellinor]

I'll implement any feature that the masses want. Just let me know when you are ready and I'll make some time to bring it into the code. I've just been swamped with work & family life that I haven't had time to work on outside projects BUT with that being said if there are developments such as this I'll gladly pull them in.

Thanks for your interest! I'll sort through the IR code myself first, make a version that people can test, and do some GUI experiments (since this is the only way to test the interpolation). When things get stable we will see how much of my changes you want to adopt.

[The DigitalAlchemist]

Is it possible to crank up the rigidity of the parts? I've had this idea for a few weeks now and I want to make a medium/large (HX parts large) ship that uses rotating engine nacelles for landing on planets. The issue I'm running into right now is that any sufficiently heavy part (which is most) or a powerful engine will cause the rotating joint to flop around like a wet noodle. You cant just slap struts on it because that prevents the part from moving at all (and will actually snap the ship if you try, found this out when one of mine broke in half like a cracker)

If I can some how get it to work, I could move all the engines outboard, leaving the center open for space to park a small flier or rover in.

[AccidentalDisassembly]

Is it possible to crank up the rigidity of the parts? I've had this idea for a few weeks now and I want to make a medium/large (HX parts large) ship that uses rotating engine nacelles for landing on planets. The issue I'm running into right now is that any sufficiently heavy part (which is most) or a powerful engine will cause the rotating joint to flop around like a wet noodle. You cant just slap struts on it because that prevents the part from moving at all (and will actually snap the ship if you try, found this out when one of mine broke in half like a cracker)

If I can some how get it to work, I could move all the engines outboard, leaving the center open for space to park a small flier or rover in.

I tried something similar once, and I may be wrong on this, but I think the rigidity/strength of the joint has a lot to do with the mass of the IR part - so you could make a larger-scaled IR part (copying the config or something) and make it weigh quite a lot, and that might possibly work.

[Darren9]

Is it possible to crank up the rigidity of the parts? I've had this idea for a few weeks now and I want to make a medium/large (HX parts large) ship that uses rotating engine nacelles for landing on planets. The issue I'm running into right now is that any sufficiently heavy part (which is most) or a powerful engine will cause the rotating joint to flop around like a wet noodle. You cant just slap struts on it because that prevents the part from moving at all (and will actually snap the ship if you try, found this out when one of mine broke in half like a cracker)

If I can some how get it to work, I could move all the engines outboard, leaving the center open for space to park a small flier or rover in.

Have you looked at Active Struts? And the matching IR Rework model pack that goes with it. There's a certain level you can get to by increasing size/mass of the IR parts. With active Struts you have a base and endpoint, stick the base on the ship and the endpoint on the engine, an action group toggles the strut on/off, once a base is connected to an endpoint it always reconnects to it, even if it's been moved by IR, you can have double or quad strutted, turn them off (toggle the AG), move the engine, turn them back on. The combination of larger parts and Active Struts is probably the most usable.

[sirkut]

Thanks for your interest! I'll sort through the IR code myself first, make a version that people can test, and do some GUI experiments (since this is the only way to test the interpolation). When things get stable we will see how much of my changes you want to adopt.

Sounds good to me! I'll try to escape my busy schedule to help test but lately I've been losing that battle.

[sashan]

Are there any parts or plugins for IR that allow simple deploy functionality? Like for antenna masts, RTG towers ets. I want to be unable to retract them, just like in real life.

[erendrake]

Are there any parts or plugins for IR that allow simple deploy functionality? Like for antenna masts, RTG towers ets. I want to be unable to retract them, just like in real life.

Would the trade-off be a lighter, cheaper, stronger part? or is it just for flavor?

[The DigitalAlchemist]

Have you looked at Active Struts? And the matching IR Rework model pack that goes with it. There's a certain level you can get to by increasing size/mass of the IR parts. With active Struts you have a base and endpoint, stick the base on the ship and the endpoint on the engine, an action group toggles the strut on/off, once a base is connected to an endpoint it always reconnects to it, even if it's been moved by IR, you can have double or quad strutted, turn them off (toggle the AG), move the engine, turn them back on. The combination of larger parts and Active Struts is probably the most usable.

Actually, I solved my problem by cheating, and scaling the mass/fuel/thrust of all the HX part's down by 100x. It actually worked extremely well and hasnt changed the performance at all. Only difference is that the part's dont warp as bad and I can now use non HX parts. Like landing gears...

Also, I'm using Quantum Struts for my engine stabilization needs. I have it rigged to actions so that when the part is rotating, it toggles the strut, then when i hit the button again to make it stop it toggles back on.

As far as using things like active struts (which is broken for me btw, (my LMB stops working when i try to connect them in the editor so I cant connect it) it's still not feasible for stock HX. The parts are simply too heavy and as soon as the struts let go the part will just rip it's self off or flop around like a wet noodle.

Active struts sounds like it would work better than the quantum struts since they'll attach to the same point again where as the quantum strut has to be aimed. If it misses the part, it can actually strut the ship to the ground which is hilarious. The ship moving 300m/s suddenly stops, and it's like colliding with a brick wall mid air. I nearly jumped out of my chair the first time it happened because it was so unexpected.

Edited March 10, 2015 by The DigitalAlchemist

[Goddess Bhavani]

I recently made a controllable pitch setup for a large free-spinning rotor system using IR parts. It also allows the center section of a ship to rotate freely independent of the front and back halves of the ship.

Regarding the flopping about like a wet noodle, I definitely encountered that when constructing a helicopter with two rotor assemblies. I solved the dynamic instability by many, many hours of testing counterweights and struts until it held together long enough for 'safe' test flights...

[pellinor]

A first testing version for smooth interpolation is available: Github repo (you only need the updated InfernalRobotics.dll). (very WIP, likely to break stuff!)

So far it is only wired to rotation, and tested only with the "IR rotatron" part. Max Speed and Acceleration are still hardcoded, but it takes its modulo flag and min/max position (if modulo is off) from the interface in the right-click menu (will not update during flight). If anyone is curious about smooth acceleration, feel free to test!

I wired the three buttons (left, zero, right) with movement commands that last only while the button is pressed. On release the axis will smoothly brake.

The debug output shows a bit of the inner workings (like the generated commands and current pos/speed).

Edited March 12, 2015 by pellinor

[C4pt.Miles]

Sorry if this was already asked (tl:dr) but would it be possible to assign axis more often to different keys?

So that i can assign one Servo to different groups.

This would make Robotic Arms much more easy to handle...

I made a video below, because I'm not sure if you know what i mean...