sirkut

1.1.2 Magic Smoke Industries Infernal Robotics 2.0.2

2160 posts in this topic

Here is a ModuleManager patch that does the following things for Rework parts specifically - not for Legacy:

Things:

  1. All robotic parts can now be scaled at relatively fine increments from 0.25x their original (normal) size to 5x. HUGE! Wooooo!
  2. Trusses and wheels can also be scaled at these fine increments, though I didn't allow for wheels to become huge since I just don't know if they behave correctly when enormous. You can easily change this if you want.
  3. The mass of robotic parts except at the smallest scale is increased somewhat (most Rework parts originally: 0.1t, my changes: 0.3t); this gives them slightly stronger joints. Smallest-scale parts now weigh ~ 0.02 instead of 0.025ish.
  4. Much simplified TweakScale stuff - fewer SCALETYPES to edit if you want to fiddle with scaleFactors or what have you.
  5. Hides the three pointless (I think? I just couldn't figure these out) half-size Athlete trusses.

Downsides:

  1. Biggest downside: when placing parts, they start out huge and you'll have to scale them down for normal-sized ships. This is currently unavoidable if you want parts more than 1.5X (or so) the size of the originals.
  2. Telescopic pistons didn't get upscaled - they don't cooperate and I don't know why. Maybe someone else can figure this out. You can still make trusses match their size (or pretty close) since they're made to freescale.
  3. Heavier robotic parts could be a downside too.
  4. The original SCALETYPES for reworked parts had a cool system of matching names of scales to absolute sizes of parts - this is somewhat broken with my system, but only for half-size bits like RoboTruss Lite and RoboTube parts, wheels too, I think, and maybe some others. I.e. a RoboTruss Lite part at "2x" scale will no longer exactly match every other part scaled to "2x". I think the bonuses outweigh this.
  5. No Legacy part support. They break like the telescopic pistons. Also don't know why.
  6. Didn't mess with electric charge required, so that will be way off - maybe in another version.

Some thoughts on this:

* Telescopic pistons are not special in any way, the only difference I am aware of is that zodius made them for use with powers of (third root of 2), which is why they have their own scaletype. What does "they don't cooperate" mean? You could try adding ":FINAL" to the patches so they run last, and see if that changes anything. Just in case they tried to change something that was not there yet, or were overwritten by later patches.

* I'd consider part patches like "@rescaleFactor *= 4" as problematic because adding or removing your config will likely break every affected part, scaled or not, both in the save file and in craft files.

Share this post


Link to post
Share on other sites
Some thoughts on this:

* Telescopic pistons are not special in any way, the only difference I am aware of is that zodius made them for use with powers of (third root of 2), which is why they have their own scaletype. What does "they don't cooperate" mean? You could try adding ":FINAL" to the patches so they run last, and see if that changes anything. Just in case they tried to change something that was not there yet, or were overwritten by later patches.

* I'd consider part patches like "@rescaleFactor *= 4" as problematic because adding or removing your config will likely break every affected part, scaled or not, both in the save file and in craft files.

Hard to describe the not cooperating bit, and unfortunately I don't have a picture. Essentially the patch breaks the telescopic parts - they will extend, but when they extend, they shift upward/sideways as well as outward, ones at the base don't extend fully, etc. I don't understand it either, since I also couldn't figure out how those parts could conceivably be different than the others... all I was doing was changing the exact same variables as for the other parts, didn't change the SCALETYPE or anything else. I also couldn't figure out why some legacy parts (like gantries) broke in a vaguely similar way when doing this...

It's possible it was just some error/typo when I was making the MM config too, I just left it out because it was still broken.

Yeah, the @rescaleFactor *= 4 definitely wrecks stuff, but until TS and IR play together nicely for upscaling, it's at least one way of having larger IR parts without duplicating everything (a method I've also tried) and therefore cluttering your part list. Is there a way to do this without breaking things? Duplication was the only thing I could think of.

EDIT: Added the telescopic parts back to the patch. New behavior I haven't seen - now they explode when you extend them. This is the starting point:

ExplodingTelescopics1.png

When you press the control to extend them, they do begin moving outward. If you just press it for a moment and extend them a tiny bit, the craft will begin rotating (constantly) counterclockwise.

If you extend them farther, they explode. Beats me... Totally guessing, but could there be an issue with these parts specifically and the new nodes sizes I apply? Works OK for the other parts, but they aren't usually in robotic-on-robotic-part chains.

EDIT AGAIN: Aha! That's got something to do with it - when I place other IR parts (rescaled) end to end - one robotic part on another, oriented correctly - they also cause weird forces in the ship and explode if moved too far. Huh. So much for the patch as is. =( I seem to remember this phenomenon with the stacked telescopic parts being less pronounced when in an original iteration I tried using stack nodes of size 2... not sure about that though.

Edited by AccidentalDisassembly

Share this post


Link to post
Share on other sites
Great work guys, I love the fact that when assigning parts to an action group you no longer need to toggle a direction on and then off again. That caused a lot of issues with some of my torture devi.... I mean machines. Also I'm having some issues getting the rotor to lock. It will turn past its adjusted preset minimum and maximum every time. Also the 180 degree Pivitron I believe it was, would not accept a new "center" position it would default to its original preset regardless of what I enter and save. I wound up using the old deprecated Pivitron with a default center position of 90 degrees and that worked like a charm. But those two minor issues aside you all did an amazing job on the rework.

Rotatrons do not have limits engaged by default, you have to turn them on via right click menu, and I believe that is what causing the issue you are having. I'll check the 180 pivotron tomorrow, it should not be different from any other part.

Share this post


Link to post
Share on other sites

Welp, it was indeed the node sizes, or so it seems. How much do they matter, really? I didn't find a definitive answer to the question of whether stack node size affects joint strength, but I thought it did...

Parts alone can work with larger stack nodes (at least when surface attached to something), but robotic part on robotic part = disaster. =(

Edited by AccidentalDisassembly

Share this post


Link to post
Share on other sites
Welp, it was indeed the node sizes, or so it seems. How much do they matter, really? I didn't find a definitive answer to the question of whether stack node size affects joint strength, but I thought it did...

Parts alone can work with larger stack nodes (at least when surface attached to something), but robotic part on robotic part = disaster. =(

All I know is that the larger node sizes were updated when the NASA pack came in to create more than one joint between neighbouring parts, or perhaps even between neighbours of neighbours. If the latter then that would definitely explain why thing explode when IR parts are moved. I wouldn't know how to verify this for certain though. Surface attachment ignores node size rules so will always be a single joint.

Share this post


Link to post
Share on other sites
All I know is that the larger node sizes were updated when the NASA pack came in to create more than one joint between neighbouring parts, or perhaps even between neighbours of neighbours. If the latter then that would definitely explain why thing explode when IR parts are moved. I wouldn't know how to verify this for certain though. Surface attachment ignores node size rules so will always be a single joint.

If there isn't a necessary correlation between stack node size and joint strength, then maybe there's a way to override TweakScale's treatment of stack nodes just for IR parts - then maybe they could be scaled up indefinitely without breaking? Assuming the joint strength would still be reasonable.

I am suspicious that IR parts start malfunctioning when scaled up specifically when the size of the stack nodes goes up an increment from 1 - so if it starts at stack node size 1, then they'd start breaking when scaled beyond about 1.41x (1.41^2 = ~2, increments to stack node size 2 because of TweakScale using exponent 2 for managing stack node sizes... maybe).

I am not sure how to write a TWEAKSCALEEXPONENTS{} that would make stack node size increase with an exponent of 0.4 (rather than 2).

I tried this, but it didn't work:

SCALETYPE

{

name = Rework_Standard_4x

freeScale = true

suffix = X

scaleFactors = 0.25, 0.5, 0.75, 1.0, 1.5, 2.0, 2.5, 3.0, 3.5, 4.0, 5.0

incrementSlide = 0.025, 0.025, 0.025, 0.025, 0.1, 0.1, 0.1, 0.1, 0.1, 0.1, 0.1

defaultScale = 1.0

TWEAKSCALEEXPONENTS

{

name = Part

mass = 2

attachNodes

{

breakingForce = 0.4

breakingTorque = 0.4

}

}

}

Downside would be visual burial of the attach node within the larger parts, but not a terribly big deal.

EDIT: Changing the ScaleExponents.cfg to have values of 0.4 for all the breakingForce/breakingTorque stuff also did nothing. Is there some other way to control TS' interaction with stack nodes maybe?

Edited by AccidentalDisassembly

Share this post


Link to post
Share on other sites

Wasn't there a Centrifuge part for this mod ?

Share this post


Link to post
Share on other sites
Rotatrons do not have limits engaged by default, you have to turn them on via right click menu, and I believe that is what causing the issue you are having. I'll check the 180 pivotron tomorrow, it should not be different from any other part.

I apologize I forgot to mention. I did engage the limits with the right click menu. And then went into the IR screen with the button at the bottom of the screen. Moved to rotatron to 1 degree set limits of 0 and I believe 75 degrees then it would work in the SPH but when launching it would ignore the limits that where set.

Share this post


Link to post
Share on other sites
I apologize I forgot to mention. I did engage the limits with the right click menu. And then went into the IR screen with the button at the bottom of the screen. Moved to rotatron to 1 degree set limits of 0 and I believe 75 degrees then it would work in the SPH but when launching it would ignore the limits that where set.

Aha, I thought this was fixed. For some reason Engage limits does not persist from editor. This will be fixed now for sure.

Share this post


Link to post
Share on other sites

Will legacy parts get updates textures?

Share this post


Link to post
Share on other sites
Will legacy parts get updates textures?

Not to my knowledge. Instead parts are in the process of being replaced by reworked versions, with the only major things missing at the moment being gantries and docking washers.

Share this post


Link to post
Share on other sites
Aha, I thought this was fixed. For some reason Engage limits does not persist from editor. This will be fixed now for sure.

That makes sense, thank for taking a look. Also something I was messing around with last night was a rotating bomb rack under my B-2 it has 6 BDarmory cruise missiles attached to a central tube which is supported by a controlled Rotatron at one end and an uncontrolled Rotatron at the other. Previously I just held down a button to manually rotate the rack back and forth. But with the new presets I can now press a single button to simply advance to the next bomb. I have 6 presets at 60 degree intervals. It worked fine for the first 4 bombs so from zero degrees up to 240 degrees. But as soon as I would press the action group to advance to the next preset past 240 degrees, it would over rotate back to 0. My work around was to use negative numbers for the last two (first two) presets. So I would have 0 as my center position and a range of 0 - 240. And at the top of my preset list I have -60 and -120 after this change it would stop every 60 degrees. Hopefully I didn't make that sound too overly complicated. Long story short I'm not sure if this is an IR issue or a me issue and I just need to relearn the new interface. But I found a work around and the new IR works very, very well. I have yet to have an alignment bug like the previous IR. I was honestly afraid to move anything in the VAB SPH before but now it all works exactly the way it should to test things before launching. And is far more accurate than before.

Share this post


Link to post
Share on other sites
That makes sense, thank for taking a look. Also something I was messing around with last night was a rotating bomb rack under my B-2 it has 6 BDarmory cruise missiles attached to a central tube which is supported by a controlled Rotatron at one end and an uncontrolled Rotatron at the other. Previously I just held down a button to manually rotate the rack back and forth. But with the new presets I can now press a single button to simply advance to the next bomb. I have 6 presets at 60 degree intervals. It worked fine for the first 4 bombs so from zero degrees up to 240 degrees. But as soon as I would press the action group to advance to the next preset past 240 degrees, it would over rotate back to 0. My work around was to use negative numbers for the last two (first two) presets. So I would have 0 as my center position and a range of 0 - 240. And at the top of my preset list I have -60 and -120 after this change it would stop every 60 degrees. Hopefully I didn't make that sound too overly complicated. Long story short I'm not sure if this is an IR issue or a me issue and I just need to relearn the new interface. But I found a work around and the new IR works very, very well. I have yet to have an alignment bug like the previous IR. I was honestly afraid to move anything in the VAB SPH before but now it all works exactly the way it should to test things before launching. And is far more accurate than before.

It is a known issue too, but as you said it is more of a UI problem. For unrestricted rotatrons the internal range is from -180 to 180, BUT presets do loop around, e.g. if there are no rotation limits and you have presets set like [-120, -60, 0, 60, 120, 180] then pressing NextPreset when you are at 180 should bring you to -120.

As for moving things in editor - don't be afraid, during whole month of testing we haven't encountered any creeping issues apart from off-axis parts, and that was fixed too.

Share this post


Link to post
Share on other sites
If there isn't a necessary correlation between stack node size and joint strength, then maybe there's a way to override TweakScale's treatment of stack nodes just for IR parts - then maybe they could be scaled up indefinitely without breaking? Assuming the joint strength would still be reasonable.

I am suspicious that IR parts start malfunctioning when scaled up specifically when the size of the stack nodes goes up an increment from 1 - so if it starts at stack node size 1, then they'd start breaking when scaled beyond about 1.41x (1.41^2 = ~2, increments to stack node size 2 because of TweakScale using exponent 2 for managing stack node sizes... maybe).

I am not sure how to write a TWEAKSCALEEXPONENTS{} that would make stack node size increase with an exponent of 0.4 (rather than 2).

I tried this, but it didn't work:

Downside would be visual burial of the attach node within the larger parts, but not a terribly big deal.

EDIT: Changing the ScaleExponents.cfg to have values of 0.4 for all the breakingForce/breakingTorque stuff also did nothing. Is there some other way to control TS' interaction with stack nodes maybe?

Now I know IR from the inside, limiting the node sizes should be easy. I don't think they can be scaled with a config, so they need their own code. IR is already notified on rescale, we can limit the node sizes there. This extra manipulation will not break TweakScale because it reads the original sizes from the prefab part.

So is there a consensus that nodes on IR parts should globally be limited to size 2? (i.e. the standard node size on 2.5m parts)

Share this post


Link to post
Share on other sites

can you please add a wheel alignment option im getting excessive drift more then usual and its very hard to eyeball these things

Javascript is disabled. View full album

ive tried tweaking the angle of the wheels several times but it doesnt seem to help

Edited by endl

Share this post


Link to post
Share on other sites
can you please add a wheel alignment option im getting excessive drift more then usual and its very hard to eyeball these things

http://imgur.com/a/R02Ys

ive tried tweaking the angle of the wheels several times but it doesnt seem to help

Why not just use the 45 degree preset if you have 4 wheels at radial symmetry?

Share this post


Link to post
Share on other sites
Why not just use the 45 degree preset if you have 4 wheels at radial symmetry?

I agree with Ziw on this one. I have yet to even use the alignment indicator for B9 landing gear. with IR you have the ability to align to the fraction of a degree. Math is you friend, well maybe not mine but that's my own fault.

Edited by V8jester

Share this post


Link to post
Share on other sites
Why not just use the 45 degree preset if you have 4 wheels at radial symmetry?
I agree with ZIW on this one. I have yet to even use the alignment indicator for B9 gear. with IR you have the ability to align to the fraction of a degree. Math is you friend, well maybe not mine but that's my own fault

already tried this, it doesnt work, i assumed it was the runway and tried the other areas but the problem persists. ive also tried other angles and configurations. it might be something with the modeling but even still there are scenarios where your not using symmetry where alignment guides are very helpful this should be a default feature especially for anything like a wheel or docking arm (claw)

Share this post


Link to post
Share on other sites
already tried this, it doesnt work, i assumed it was the runway and tried the other areas but the problem persists. ive also tried other angles and configurations. it might be something with the modeling but even still there are scenarios where your not using symmetry where alignment guides are very helpful this should be a default feature especially for anything like a wheel or docking arm (claw)

My thought is the legs on your rover appear to be pretty straight up and down. Try and lower the angle of the legs more horizontal. Much like the rover in the tutorial video. The wheels extend more outward than downward. Makes for a wider and more stable platform.

edit:

Another idea is use 4 quantum struts or active struts to connect the wheels together under the fuel donut under your rover after the wheels are deployed?

Edited by V8jester

Share this post


Link to post
Share on other sites
My thought is the legs on your rover appear to be pretty straight up and down. Try and lower the angle of the legs more horizontal. Much like the rover in the tutorial video. The wheels extend more outward than downward. Makes for a wider and more stable platform.

edit:

Another idea is use 4 quantum struts or active struts to connect the wheels together under the fuel donut under your rover after the wheels are deployed?

doesnt work,

Javascript is disabled. View full album

Share this post


Link to post
Share on other sites

I have one last idea. Look at your nav ball. you are controlling from a command pod pointing straight down. and by pressing (w) you are driving the wheels as well as any reaction wheels you may have added or what is already equipped in your command pod. This could be adding torque to the legs bending them and altering your intended path.

Edit: I just looked at a larger version of your picture, I should have led with that. Each arm is attached to a separate structural panel. this could be a lot of your issue. Try attaching all the arms to one common part using symmetry and then see what happens.

Edited by V8jester

Share this post


Link to post
Share on other sites

Are you sure you wheels are all parallel to the ground when deployed, as it really doesn't look like it from that shot. If they are angled then your far more likely to experience this behaviour. Also even if they are parallel as you move variations in forces on the legs will make this effect marginally occur. At least that has been my assessment from testing the parts during development.

Edit: Just tested with my Athlete rover and I get no drift at all, even with angling the wheels to the ground, so scratch what I've said above.

Edited by ZodiusInfuser

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now