[0.90] Magic Smoke Industries Infernal Robotics - 0.19.3

[sirkut]

Woot! This seems like the best option IMO. I presume that "Rotate Limits" will only be present for parts that do not have rotation limits set by default? If not for those parts that do have limits designed in the cfg, would the tweakable just define whether they are overwritten or not? I don't want people turning off the limits on all of my carefully designed Pivotrons

Eh. I've been wondering what to do about that important problem. I'm probably just going to add a new flag to the CFG to prevent it from being toggleable.

[ZodiusInfuser]

Eh. I've been wondering what to do about that important problem. I'm probably just going to add a new flag to the CFG to prevent it from being toggleable.

I'd say if rotateLimits = True is set in the CFG then you prevent the limits from being toggleable, since this is the one parameter that distinguishes Pivotrons from Rotatrons. In fact, can't you make it so the tweakable is hidden in that scenario, or is that beyond the power of KSP?

[sirkut]

I'd say if rotateLimits = True is set in the CFG then you prevent the limits from being toggleable, since this is the one parameter that distinguishes Pivotrons from Rotatrons. In fact, can't you make it so the tweakable is hidden in that scenario, or is that beyond the power of KSP?

The problem stems from a rotatron. In the CFG, rotateLimits is set to false. Which means it rotates endlessly. Some people are wanting the ability to limit the rotatron so when it gets toggled to True, it renders the idea useless if you want to hide it.

[Malsheck]

I'm impressed! How did you manage to keep the gait in sync when turning on the spot?

At the time of the video I just eye-balled it and made sure that I stopped when all of the hinges were horizontal. Now I have it set to an action group that centers all of the servos to take the guess work out of it. I just hit that before and after turning.

[ZodiusInfuser]

The problem stems from a rotatron. In the CFG, rotateLimits is set to false. Which means it rotates endlessly. Some people are wanting the ability to limit the rotatron so when it gets toggled to True, it renders the idea useless if you want to hide it.

I understand that, but why does this new tweakable have to tie into the cfg rotateLimits flag? Couldn't you just have a separate internal variables that stores the tweakable's state?

bool rotateLimits = //read from cfg
bool limitTweakable = //read current tweakable state

if((rotateLimits == True) || (limitTweakable == True))
{
    //Movement range is limited
}
else
{
    //Movement range is not limited
}

[sirkut]

The problem being I need a variable that allows a user to toggle a limit and a variable that changes that bool to true and false. I can't use just one because if I use limitTweakable as my sole variable I'm screwed when it gets false and it is no longer visible in the UI. I have no problem with limitTweak being set to True meaning user CAN set the limits of a rotational device, I need another persistant variable that records whether or not the limit is enabled or not during the doration call.

[sirkut]

I understand that, but why does this new tweakable have to tie into the cfg rotateLimits flag? Couldn't you just have a separate internal variables that stores the tweakable's state?

bool rotateLimits = //read from cfg
bool limitTweakable = //read current tweakable state

if((rotateLimits == True) || (limitTweakable == True))
{
    //Movement range is limited
}
else
{
    //Movement range is not limited
}

it doesnt, I'm using a different variable. there was confusion when I was explaining it.

Edited June 4, 2014 by sirkut

[Malsheck]

For anyone interested, the basic principle I made when I created my spider walker is this:

The inner part of the legs spins like a wheel and at one end of it is a henge (near the body) that determines how far off of center the outer part swings. You'll notice in the video that one of the first things the spider does is raise every other leg. It's also lowering the other ones the same amount to set the gait. (Kind of like setting the tire size) If I didn't do that the inner part of the leg would spin while everything else would remain motionless. This was done by making 2 IR groups with half of the inner hinges in one and the other in the other... but in such a way that they are staggered... like even numbered left legs and odd numbered right legs in one and the rest in the other. Then set the controls for the two groups so that they are the same buttons but opposite. like (9,0) and (0,9). This way you lower half while raising the other half. At the body and at the knee(?) are servos that spin the whole assembly at the same rate and direction. This gives the outer leg the appearance of walking rather than spinning like a wheel.

The second part is to break the servos down by left side and right side in the IR controls. For example, I set the left side ones to go < when Q is pressed and > when E is pressed and then on the right side the opposite. > for Q and < for E. This way all the servos turn the same amount all of the time. You'll later want to set an action group to center all of your servos before you start walking forwards after turning or vise versa... otherwise your spider is going to do the dieing cockroach because the left and right will be off sync.

To add a layer of control, I added a second hinge between the outer servo and the outer half of the leg. This allows me to tilt the outer leg up and down. (in the video you'll see me use this when the spider dips down and then back up prior to setting the gait.) This helps out A LOT.

To move forward, I simply made an action group to spin all the servos forward at once.

I hope this helps folks out and that you have as much fun with it as I did.

[mughi]

Ahh, looks like I downloaded it off the Spaceport and not this thread, which would explain why it was an old version. Luckily I don't actually use any IR parts other than that first little experiment so the update didn't break anything, and fixed the problem! Thank you, I'm glad I was just being an idiot and it wasn't something that required a patch or something.

Just a note for those dealing with this. I had the latest version of IR and it still wouldn't work. I fixed it by deleting both IR _AND_ 000_Toolbar, and using the ones provided in the latest IR download. As I'm fairly sure I had deleted IR when I originally tried to update, I think the issue was probably an older version of Toolbar. (Which makes sense, and I'm not sure why it took me so long to think of it, but thought I'd save anyone else some headscratching)

[sirkut]

Development is going well, aside from ZodiusInfuser being a pain with the constant suggestions I have hit a crossroad and would like everyone's input.

Due to the resolution of the tweakable UI, it's hard to get accurate numbers due to it's limitation of being 100 steps. So, we can keep the current system I have designed which is in this video:

Or utilizing KSPAE (http://forum.kerbalspaceprogram.com/threads/81496-KSPAPIExtensions-Utilities-for-shared-mod-use) I can do it this way. Note, you can't slide the entire range, you have to step through the range using the buttons but you have a more precise manner of changing the values thanks to KSPAE. You'll have to click more to get what you want. I may need to change the ranges a bit for the buttons. Here's a video of this method:

[AndreyATGB]

I vote for KSPAE method, I've been using Procedural Parts for a while and never had an issue with the way resizing works. Not sure if it's been asked before but is it possible to have the rotatron be free to rotate by external forces? Like using it as a base for a rotor or something like that.

[Alewx]

I definitely go with you own tweakables, having a tweakable tweakable is awesome, and defining the stepIncrease in the tweakable itself is by far better than the KSPAE Version. Go for it

[sirkut]

I vote for KSPAE method, I've been using Procedural Parts for a while and never had an issue with the way resizing works. Not sure if it's been asked before but is it possible to have the rotatron be free to rotate by external forces? Like using it as a base for a rotor or something like that.

You would simply copy the same CFG that is in the dockerwasher free to make it rotate freely. I'm not certain I can do this as a toggle so I could toggle from motorized or uncontrolled but I will look into it.

[AndreyATGB]

You would simply copy the same CFG that is in the dockerwasher free to make it rotate freely. I'm not certain I can do this as a toggle so I could toggle from motorized or uncontrolled but I will look into it.

Oh no, I feel really stupid now. I used IR for KSPI receivers so I only copied over the hinge parts so I kind of didn't know/read what the other parts do, I assumed the thing that rotates is also capable of being free moving but there's no point to change that since there's a part that does that already which you just pointed out to me.

[sirkut]

Oh no, I feel really stupid now. I used IR for KSPI receivers so I only copied over the hinge parts so I kind of didn't know/read what the other parts do, I assumed the thing that rotates is also capable of being free moving but there's no point to change that since there's a part that does that already which you just pointed out to me.

No worries. It's also low profile so it doesn't take up space.

[ZodiusInfuser]

Development is going well, aside from ZodiusInfuser being a pain with the constant suggestions

You would simply copy the same CFG that is in the dockerwasher free to make it rotate freely. I'm not certain I can do this as a toggle so I could toggle from motorized or uncontrolled but I will look into it.

I prefer having separate modeled parts for free and un-free parts, especially considering that making them free removes any angle/distance constraints. Also, I imagine that most of these parts make use of some sort of worm gear mechanism (since no power is consumed), meaning it wouldn't be physically possible to back-drive them anyway.

[sirkut]

I prefer having separate modeled parts for free and un-free parts, especially considering that making them free removes any angle/distance constraints. Also, I imagine that most of these parts make use of some sort of worm gear mechanism (since no power is consumed), meaning it wouldn't be physically possible to back-drive them anyway.

Leaving them separate then.

[Gristle]

I like method #1. The KSPAE solution looks and feels broken.

[sirkut]

Anyone willing to test 0.16pre4 with a backup game utilizing KSPAE?

[Alewx]

Anyone willing to test 0.16pre4 with a backup game utilizing KSPAE?

If you give me an Pre016Version with your own tweakables I would test it, even at this late time.

[Korb Biakustra]

Just a small update. I'm not going to be adding the text boxes to do min/max for rotations. It's just easier to make the config for the rotatron for example be -360 for min, and 360 for max. Then using that AND a new tweakable "Rotate Limits" you can now move about as you wish.

Do you mean we need to edit the limits in the .cfg file? That way, all rotatrons will have the same limits in the game, right? If so, I am not sure this is a good solution. Even inside one ship one may need different rotatrons, but even more among ships of a save. But I see in the two videos you posted after that the limits are set in tweakables, so there's a light hope! Have you changed your mind and made limits tweakables?

[sirkut]

Do you mean we need to edit the limits in the .cfg file? That way, all rotatrons will have the same limits in the game, right? If so, I am not sure this is a good solution. Even inside one ship one may need different rotatrons, but even more among ships of a save. But I see in the two videos you posted after that the limits are set in tweakables, so there's a light hope! Have you changed your mind and made limits tweakables?

the limits are tweakable and you won't need to edit the CFG. You specify the range of motion, then you enable the tweakable toggle so it will stop when it reaches one of the 2 ranges. Once changed it is stored for just that rotatron/.dockingwasher, etc. UNLESS You are in symmetry mode during the editor scene. When in flight, it's each part individually.

[Korb Biakustra]

Great! Thanks a lot.

[federally]

I love this mod and I just want to share one of my favorite creations that uses it

Javascript is disabled. View full album

[JewelShisen]

I love this mod and I just want to share one of my favorite creations that uses it

http://imgur.com/a/KQE8L

That is really cool.

Edited June 6, 2014 by JewelShisen