ZodiusInfuser

Why not have structural parts? I mean seriously, the current stock selection of girders are not up to the job of creating cool robotic contraptions. If you're not interested in them then don't download them, although you will have a deminished experience since the structural parts are designed to fit perfectly with the new robotic parts. Also, "miffed"? Why would the work I'm doing in my spare time that you have no obligation to use make you miffed? Yes . Two versions allowing you to create a gimbal for exactly that sort of application! Yea, different time-zones between myself and sirkut meant that I couldn't release my update at the same time like I wanted to. -------------------------------------------------- Robotic Parts Updated!! Main changes are making them IR 0.15 compatable, removing the redundant part, and renaming them to match their code-names better. I have plans to replace the missing part with something especially cool, but that will take a few more days to complete. Please be sure to delete your _Rework_Robotic_ folder to remove the now missing part. If you don't the part won't appear in the VAB anyway, unless you choose to manually update the CFG (I'd discourage this since I won't be maintaining that part from now on)

I have similar usage plans for such a part. Here is the old design I started on. When I get inspiration I'll revisit this concept, but don't expect this anytime soon.

#1. Thanks for reminding me. I'll get on that shortly As for #2, I did have a station sized telescoping section modelled ages ago but never got it in game. It's certainly on my list of stuff to add in the future

Indeed you did . I have set it so each of the three part sizes are defined using the tweak scale, rather than having duplicates. I can't say it will reduce part spam too much though, as there are a lot of new parts added to this pack (filling roles I felt were missing in the current line-up). So whereas before there were 5 or so rotational parts, there are now 15 (some of these exist due to KSP/Mod limitations though). As such you can think of my work as an expansion as much as it is a remodel

I think Sirkut means that the next CFG versions will need to follow the Part/MuMechToggle combo. For now though, have you tried playing around with the rotation axes of the parts. IIRC that was changed about a bit as part of the 0.14 update.

Docking port used . It was super effective! Are those RCS tanks I see either side of the port?

Pretty much all of the colliders are simplified geometry (for performance), so for example the RoboTube ones ignore the outside protrusions, and the joints ignore the "motor" feature. Are there any particular ones you think should be addressed? There is already a free spinning Rotatron in the collection. I will be adding docking washer sized versions in the future though. As for gimbal, an uncontrolled one is possible by combining the two free spinning Pivotron types. I may considere a powered version in the future, but I'm not sure of how useful they would be.

That is the best thing ever!!

Hence having an invert button to switch from MasterScale * TweakScale, to MasterScale / TweakScale, with TweakScale being from 1 to 5 . Its not that elegant though, so perhaps toadicus' code may be worthwhile exploring (not for too long though )

All that logic is sound and what I assumed you were doing anyway. I was saying that 25% slower isn't the same as 25% of a value, but that's just a technicality that doesn't relate to the main point I was trying to make. That is certainly possible, and like I say, maybe I'm over thinking things. That being said, here's a visual representation of the suggestion I was trying to propose: The difference here is you get the same resolution regardless of if you want the servo to go faster or slower, kind of like a Logarithmic scale.

On the Tweaked part. The Servo Control is fine since it's a text box so any floating point value can be entered. Oh and 25% slower is 0.8 What I mean is if you have a 0.1 increment there are 5 steps between 0.5 and 1. Between 1 and 2 you have 10 steps, so double the resolution despite these being x2 and ÷2. Also for some values such as 1.4 (40%) there is no direct remap to a speed decrease, the exact slider value you'd need to set is 0.7142857... which obviously cannot be done. If you want the reverse of 0.7, you'd need to put 1.4285714... I could just be overthinking it though, since really only 0.5 and 2 will be the main values people use.

Woot! This is going to be an extremely useful ability when combined with the new range sliders . My only criticism is that the current method gives a lot of resolution at the high end but not enough at the low end, since the slider follows a linear scale. I tried to come up with some code to allow for a -1 to +1 scale to work, but its not trivial and isn't intuitive from a user point of view. To counteract this I suggest you have a linear slider from x1 to x5, with increments of 0.03333333333 (because 1/30 resolution allows for thirds and halves), and have a button to flip whether the speed value is a multiplier or divisor. That way you could make something be 25% slower or 25% faster.

I'll reiterate the answer I PM'ed sirkut with earlier. We should have a speed multipler in the IR window AND on the tweakable. In my mind the one in the window allows you to control the global speed of your action, so is pretty much the go-to one for all situations. A speed multiplier on each part would merely be used to compensate for the range of your part. For instance one of my new pivotrons rotates 90 degrees, and the hinges rotate 180. This multiplier would be used to half the speed of the first hinge so that they both get to their start and end positions at the same time. In the part I've done this with two separate groups, which not only makes things conceptually more difficult to manage but means you can't perform both at the same time. Having both multipliers gives you this flexibility. Yea, what sirkut said I too have difficulty grasping this idea, could you perhaps draw a picture? Also, what you describe sounds like a single part with multiple robotics elements within it. This is not possible with IR, and goes against its construction style, since it's my job to give people the tools to make such devices rather than offer the complete things. For example, my phoenix implementation is many different parts that 'can' be assembled to have engines come out, but could have many other uses. Try and break your idea down to see what unique parts are required.

I would agree that 0.25, 0.5 and 1.0 would be more intuitive for my application, over the current numbering. So your planned change would make the Tweakable values match the scale values, rather than the current numbering? For me 2.0 goes against the design direction of the parts i'm doing. I'd much rather make specific variants of parts based on the 1.25 scale. I'm not sure about the mode idea, I mean its only modders who will really use this so they should be able to figure out the specific scalings they want.

Personally I am against changing the numbering scheme. For my application at least IR parts don't conform to the normal KSP sizes. By default I set the parts to size 2, with size 1 being half, and size 0 being a quarter of that size. If you do add this, there should be an option to turn it off.

Can I suggest you make the INV setting be independent of the symmetry of the part. For example if you look at the stock lights the Light On tweak doesn't apply across 3x symmetry for example, yet the Colour does. This would overcome the issue people have with 2x symmetry not behaving as intended. Or have two flags, one that shared across symmetry and one that is not.

I just have to say, thanks Gaius and Biotronic for your work on this plugin. This has allowed me to avoid duplicating the parts in my Infernal Robotics Model rework by 3

This isn't expected behaviour as such, but a limitation of the mod and occurs with all existing IR parts too. To alleviate this, all these new parts have yellow markers near the "correct" attachment node. Use these as a guide to avoid incorrect placement. Edit: ninja'd

That's a nice solution actually. I'll look at modelling something in. I know it could just be done with the texture, but geometry would let me make it exact. Only two are because of an attachment limitation. The rest have been designed to offer players choice in what they can build. Here's the list of parts and their key differences: Standard Pivotron : -90 to +90 rotation range Offset Pivotron : 0 to +180 rotation range, offset by 90 Wide-Angle Pivotron : -120 to +120 rotation range, Half-Offset Pivotron : 0 to +90, offset by 90, half rotation speed Half-Offset Pivotron (Rev): 0 to +90, offset by 90, half rotation speed (This is redundant and will be removed next update) Standard Hinge (closed): 0 to +180 rotation range Standard Hinge (open): 0 to +180 rotation range, reverse direction Flat Hinge (closed): 0 to +180 rotation range, low profile Flat Hinge (open): 0 to +180 rotation range, reverse direction, low profile Standard Rotatron : Continuous 360 rotation Right-Angle Rotatron : Continuous 360 rotation, axis rotated by 90 Right-Angle Rotatron (Rev) : Continuous 360 rotation, axis unchanged but second attachment rotated by 90 (due to KSP limitation) Uncontrolled Rotatron : Continuous 360 rotation, is free spinning Uncontrolled Pivotron: Is a free spinning joint with its axis of rotation at the second attachment node Uncontrolled Pivotron (rev): Is a free spinning joint with its axis of rotation at the first attachment node (due to KSP limitation) I would do, but the folder names are used to define the order the parts appear within the part list, hence hinges having x in their directory name to put them after joints. This is quite annoying for me that KSP does this. I'd much rather it be based just on the name in the cfg. Also, the part titles are not final. I may find some more descriptive names or go the Structural Part route. I tried to using the same method as before (for the structural parts) and the one you suggest; however, both completely disable the Infernal Robotics functionality. The part rotates, but both the fixed and moveable mesh move, rather than just the moveable one . "Mesh" is the only method that I found to work for these, meaning I'll probably end up making separate textures for each part. If you can think of a solution to this please let me know, as it would be nice if they shared the same texture, for the reasons you say.

For anyone not keeping an eye on the IR Model Rework thread, there's a few new parts I could use people's feedback on: http://forum.kerbalspaceprogram.com/threads/65365-WIP-MSI-s-Infernal-Robotics-Model-Rework-(Structural-Pre-Release)?p=1138752&viewfull=1#post1138752 Thanks

I tried doing this a while ago but couldn't come up with an indicator design I liked. I will have a look at it again though. Would you say it's necessary on all the parts, or just those that start in the middle of their range? Since the 0.14 update these buttons haven't worked as intended, even with the existing parts. I think they were meant to correct issues with part rotation when dealing with mirror symmetry, but that's not an issue with these new parts, so as Sirkut says, the function will probably be removed. After sleeping on it, I know of one that's definitely redundant (top row, one in from the right), so I'll look at removing that and remodelling its neighbour a bit. Some parts like the right-angled rotatrons and uncontrolled pivotrons are flipped due to limitations in KSP meaning you can't place the other on backwards (hence the yellow markers being different). Well you can but the wrong mesh of the model will rotate Which others do you consider to be redundant? Thanks. That took me quite a bit of time to get right. I wanted a profile that allowed the parts to mesh well, but also allowed surface attachment without the parts appearing to float.

I'm now at a point where I feel conformatable with letting people play around with the robotics joints I previewed. I am doing this to gain feedback on the usability and functionality of the current set of parts before finalising them for release. This is why the textures are unfinished, as it makes modifications fairly straightforward. Edit: Check the download link and changelog in the first post I would appreciate people playing around with these, combined with the structural parts, to see what and what cannot be done with the current selection. Maybe there's a use that I need to make a new part for, or perhaps some are redundant and therefore not needed. Also any bugs you find with them, please let me know Thanks and enjoy!

Thanks, I have tried to give a wide variety of joints based on the many use-cases I've planned for. There will likely come out after then next IR update (which I hope will be soon). I'm afraid there isn't a schedule to all this. I'm pretty much doing this on the basis of "when I have time". That means I can't really commit to any sort of timeline on this work.

Thanks I think that resolved the issue. I need to do more testing but initial experiments haven't turned up any of the issues I've reported before, and that exception has certainly gone.

Thanks. That should be enough for me to get started hopefully