sirkut

I can wait. I haven't seen anything yet.

Nothing lately to report, just been busy with life & job and little time to bash the code around. Right now I'm slowly looking at KAS and Lazor on how they do their docking which is a learning curve for me.

I'll hopefully have time tomorrow to look at it but I'm fairly busy at the moment. Thanks for the interest in DevHelper. I'll get to it as soon as I have time.

When I updated to the new 0.19 version which allows moving parts in the VAB/SPH I removed the warning that attaching pistons to docking ports will break things.

I think so but have you looked into Pistons via the infernal robotics mod? People have been doing that already.

It's the inherent nature of joints in unity and there isn't much that can be done.

How would I know until it's released? There's no telling how any of it will be. My gut tells me it won't be what you are expecting but we will have I wait until it's released for me to mess with it. As for free moving rotatrons with limits. No, that's not available. I haven't figured out how in the code to prevent it from moving when it hits the limits.

One person's success does not dictate that it's stable for everyone. Be careful in spreading this type of information.

Thanks for the logs. I do see that there are a LOT of errors involving Snacks Snacks - FixedUpdate: Object reference not set to an instance of an object at Planetarium.GetUniversalTime () [0x00000] in <filename unknown>:0 Also each time it crashes from both logs I see this line: Tac.EditorController[FFF8793C][840.84]: Start While I'm not one to blame other mods just yet, try removing that mod and see if you get a crash. I'm just not sure how IR would be causing it.

Guys, I need output_log.txt files in order to offer help. Telling me that something crashes doesn't help me because: 1. I can't produce it from just your description 2. Other people (14,000+ downloads) and I'm just now seeing "x part" causes a crash so I'm fairly skeptical that it's IR. Lastly, yes there is base creep. it's a bug that I haven't figured out how to fix yet. If this is bothersome, go back to the old method of going to the launch pad to test your craft. Sounds crazy right? Imagine just a few months ago moving parts in the VAB wasn't even possible.

Symmetry has been an issue when trying to set individual ranges. I suggest using the mod part wizard and stripping the symmetry after you have placed it. Then you can assign each range individually.

I'd like to see a log file. these memory issues is something unheard of until now so I'd like to see what is going on. Also list the mods you use.

Yup, pure awesome. Can't wait!

Yikes, someone help this man, his work is great and would be a shame to not have IVA's

I didn't seem to have that problem. Have you considered using editor extensions? You can disable surface attachments so you won't have that problem. Keep in mind I never used it to get this to work in the craft file.

Here's photos explaining what I found: It would appear that the docking washer is being attached via surface attachment rather than using one of it's nodes. why it isn't working I'm not sure yet but it appears we have found a new bug. Remove the docking washer and reattach it utilizing one of the attachment nodes. It will then work. To demonstrate, here's the newly saved craft file with the node attachments being used: http://pastebin.com/EeJxd1YM

I'll look at the craft file tomorrow. Is the washer upside down? I want to say I made the red marker be the part that is supposed to move, I could be wrong. As for attaching he washer it's a known issue due to how large the nodes are and how close they are to one another. There is nothing that can be done other than using greys node helper to toggle attach nodes on/off but that isn't worth the effort.

Craft file? Log file? That scenario works fine for me. Landercan+dockingwasher+tall hinge and it works. Also, just to double check that you didn't use a free moving docking washer.

I'm still working on it and no, the link does not fix the rotation issue while building. The link is a fix for the parts where their origin is messed up. also, try this link instead: http://www./download/lsu0cfa0g0xijjw/Robotic_ProbeUnique_FixedParts.zip

They should work but I highly suggest moving all parts back to it's origin, save the game, overwrite all old files and restart the game. it may work but i can't guarantee it.

I don't understand what you mean.

I use the visual studio post build event and enter this line: copy $(TargetFileName) C:\kerbal\KSP_winDEV\GameData\MagicSmokeIndustries\Plugins\$(TargetFileName)

I haven't crossed that bridge yet for the end piece.

Yeah that part is broken and I need to fix it sometime. :/

Direction should not matter because in the CFG, you the modder has the freedom to specify which direction the transforms should rotate. The only caveat is they all must follow the same structure where one is a child of the previous. Also at least in blender, each mesh's origin must be at the spot of rotation. And from what I know, you must not apply it's location to all zeroes otherwise the rotational axis rotates about the origin rather than the mesh. I'll talk to RoverDude to ask for permission to offer the blender file as a reference to everyone to look at if they want to get a head start. The only thing I have left to do before the WIP release is to work on some sort of magnetize/claw attachment system and I'll let those who I pick have a whack at making an arm for it. Here's a pic of what I mean about the origins (note the orange dots):