Claw

Thanks, and added.

No sweat. I really was just trying to not completely hijack the thread with examples while explaining what someone asked. I've moved this information to a new thread: http://forum.kerbalspaceprogram.com/threads/79594-Docking-and-Vessel-Type-Rules-%280-23-5%29 The root part in the pictures above are the probe cores closest to the modular girders that connect the wheels to the fuel tank. The root of the whole ship in that last picture is the probe core that I right-clicked on.

This question of docking priorities and ship hierarchy has been floating around for a little while and came up again recently. While it may not be detrimental to the design of your ship, I've explored the docking and undocking rules and will try to document them here. They're actually pretty simple from what I've found so far. They are far less complex than the Fuel Flow rules. Docking Parent/Child Establishment Rules (Root Vessel) When two ships dock, the rules are evaluated in ascending order (1, 2, 3...). If a rule is invoked, then the parent/child relationship is established and the VESSEL's heirachy is established. The choice of what becomes parent/child is a matter of three layers of priority. I'm not certain of all these rules or where the thresholds are, but this is what some of my testing has shown. Rule 1: Parent status does not depend on which vessel is "in control" and which is the "target" at the time of docking. The vessels become parent or child based on the rules below. Rule 2: If the Vessel Types differ, parent status is assigned to the vessel with a higher priority Type. Type priority order from lowest to highest is: Debris, Probe, Rover, Lander, Ship, Station, Base. Easy way to remember priority order: the priority corresponds to the map filter order (buttons at top, from left to right). The Vessel Type used is whatever is currently set via the "Rename Vessel" menu. Rule 3: If two Vessels are of the same type, the "larger" Vessel becomes the parent. The "Larger" vessel is the vessel with the highest part count. Rule 4: If two Vessels are of the same type and size, the first one listed in the save file becomes the parent. Generally, the first vessel in the save file will be the first one launched. However, if previous docking/undocking/decoupling was performed, order in the save file is established per the undocking/decoupling rules. Rule 5: The child's root part ID and vessel type is stored by the parent. The child is then shuffled and re-rooted to connect via its docking port. The child's docking port then takes on the parent vessel's docking port as it's parent. Undocking/Decoupling Vessel Type Rules Rule 1: If the vessels were previously two separate vessels, the child vessel reverts to its previous Name and Type, regardless of re-naming or re-Typing of the parent. Rule 2: If the vessels have been connected since launch: The vessel containing the original root part is the parent vessel and retains the Parent Name and Type. (There are a few instances where the parent is renamed with [Type] appended.) The child vessel is automatically assigned a Type via the "Vessel Type at Time of Launch" rules. (Type preference is given to the highest priority vessel controller.) The child vessel is automatically assigned a Name in the form "Parent's Name" + [Type]. (If the parent is named "Ares", then a separated probe core is named "Ares Probe") Rule 3: The child vessel's MET timer resets after decoupling/undocking. Rule 4: "If Focus" shifts to the craft per the criteria below. This criteria is shaky, and sensitive to a lot of "what ifs?" "Control From Here" overrides all other priorities. Focus will stay with the vessel that has the "Control" part, regardless of root part or if it has a valid control ability. Any manned vessels have priority over unmanned and uncontrolled vessels. (Here, unmanned means vessels that could contain kerbals, but don't. Such as an empty Mk1 Pod.) Probe cores have priority over unmanned vessels and uncontrolled parts. Except if the Unmanned pod recently had a Kerbal in it, then it will take focus. For two craft with the same priority (such as splitting two Mk1 pods, or splitting two OKTO2 probe cores), focus stays with vessel containing the original the root part. Vessel Type at time of Launch It's probably easier to understand the Vessel Type during initial decoupling/undocking operations by exploring the rules for how KSP determines the default Type for a vessel. Rule 1: As before, Type priority order from lowest to highest is: Debris, Probe, Rover, Lander, Ship, Station, Base. If more than one of the rules below is present, the Type is set by the highest priority controller. Rule 2: If a vessel has no source of control, it is assigned Type = Debris. Rule 3: If a vessel uses a probe core (or rover body) for control, it is assigned Type = Probe. Rule 4: If a vessel uses a lander can or cupola for control, it is assigned Type = Lander. It doesn't matter if the crew stations are unoccupied. Rule 5: If a vessel uses a command pod or cockpit for control, it is assigned Type = Ship. It doesn't matter if the crew stations are unoccupied. - You can find and edit the default Type in each component's part.cfg file. Look for the line similar to "vesselType = Lander" and change it to the desired default type. The type name is case sensitive. - Incidentally, the game loads a Kerbal into the first "Lander" or "Ship" that it comes to in the Vessel's hierarchy, regardless of priority.

I found a new way to deal with this problem for v0.23.5, and I think it's slightly easier. The fix also works for the problem described in post #25. If it happens again, give the "Super quick and dirty" instructions a try: http://forum.kerbalspaceprogram.com/threads/78863-FIX-Dock-Undocking-Bug-in-0-23-5?p=1136991&viewfull=1#post1136991

It might be that MJ is calculating wrong if it has old TWR and weights stuck in there somewhere. I'd say KSP might also be to blame, but KSP simply puts the nodes where you tell it to.

Here is a tutorial I wrote. It doesn't seem to be very popular, but perhaps it will answer your question. http://forum.kerbalspaceprogram.com/threads/75759-Asteroid-Rendezvous-Outside-of-Kerbin%E2%80%99s-SOI

Funnyenough, I was specifically trying to avoid hijacking the tread. But since it's already answered... (Perhaps we should move this elsewhere?) Here's a simple example. I made three craft, all identical. Two are marked as landers, named "Lander 1" and "Lander 2". The third craft is tagged as a Ship, and is named "Ship". Examination of the save file craft order shows: Lander 2, Ship, Lander 1 First test, docking Lander 2 (in control) with Lander 1 (the target). By "simple" rules, Lander 2 should become the child and Lander 1, the parent. Except what happened here? Lander 2 became the parent even though it was "in control" at the time of docking. That's because the craft are the same size and same type, so the one that's first in the save file wins. Examine the save file, Lander 2 is listed as one large VESSEL with a DOCKED_VESSEL of "Lander 1", and Ship is listed after. Second Test: Docking the Ship to the Lander 2 (now composed of "Lander 1" + "Lander 2"). By the simple rules, the Ship is "in control" and should become the child. Again, that didn't happen. Ship became the parent even though Lander 2 is larger and listed first in the save file. That's because it's Type has priority. Even if all my rules are completely wrong, I can say that it is definitely NOT the case that which ever craft is in control becomes the child. Also, if people are going to keep digging, I should crush one other thing that may be mistaken from these two examples. They both show that the "in control" vessel becomes the parent. Realize that's because I was specifically trying to show that the "in control" craft does not always become the child. It doesn't matter which vessel you are "in control" of for either of these two examples. In fact, you can be in control of "Ship" when Lander 1 & Lander 2 complete the docking and Lander 2 always becomes the parent.

It is definitely NOT that whatever craft you are controlling becomes re-rooted and turned into the child. That I can say for certain. Quite frankly, the code is the same for whichever craft you are reshuffling so it wouldn't be "easier" or "harder" for to reshuffle one craft or the other. As for my examples. Well, you got me by the virtue that I didn't think about how I was typing it, because I thought it was straight forward enough. I didn't say which craft was "in control" and which was the "target" but I can see it being read that way. I can just as easily say... Examples... - So if you dock a station to a ship, the station is the parent. When the Ship undocks, its timer is reset. (Here, I mean the "Ship" type, not just a generic craft.) - If you dock a lander to a probe, the lander is the parent. - If you dock a base to a station, the base is the parent. I would say I typically think about it the other way, because that's the priority and that's what makes sense in my head. Snippet of HarvestR's post... I am certainly not trying to go against anything HarvestR is saying. I don't really know what you want me to say about it. I'm just trying to tell you that I can come across more than one situation where the vessel I'm controlling does NOT become the child. If you don't believe me, go dock two craft together. Quicksave before you do and be in control of one of them. Dock and check. Then quickload, switch to the other, dock and check again. The parent will be the same. You can also dock a vessel marked as a ship (in control) to a vessel marked as a lander (the target) and see which becomes the parent ship. By what you said, it's the lander. By the priority I listed, it's the ship. Also, bear in mind that I did this testing with ships of similar composition. So if you find something different, like I said there may be other rules.

Glad you found it. It might be worth posting to the MechJeb guys and maybe they'll fix it up.

Oh sorry, that's not quite right. My post was mostly in reference to the structure of the craft in the save files and how everything gets shuffled around. The choice of what becomes parent/child is a matter of (at least) two layers of priority, maybe three. I'm not certain of all these rules or where the thresholds are, but this is what some of my testing has shown. Parent ship is chosen by: 1) Priority order from lowest to highest by craft type: Debris, Probe, Rover, Lander, Ship, Station, Base. The craft with the highest priority becomes the parent. Easy way to remember: this priority corresponds to the map filter order (buttons at the top). 2) If the two craft have the same priority, the "larger" one becomes the parent. (I don't know yet how larger is chosen, but I think it might be by part count.) 3) If the two craft have the same priority and size, the first one launched becomes the parent. Like I said, I'm not certain these are all the priority rules, but it's what I've learned so far. Examples... - So if you dock a ship to a station, the station is the parent. When the Ship undocks, its timer is reset. (Here, I mean the "Ship" type, not just a generic craft.) - If you dock a probe to a lander, the lander is the parent. - If you dock a station to a base, the base is the parent.

You want some sort of "cage" that they can float and move around in? Or you want a module (like a capsule or lab) that they can "move around in"? Also, spinning only works out on a short term basis. When you leave the craft or enter non-physical time warp the spinning will stop...

Without trying to hijack the thread... Torque does, in fact, "magic" it's way to the CoM. There are many (many) threads discussing this fact. Additionally, it isn't "magic" or some form of making programming easier. It's real world physics. What you are mistaking is the difference between torque and the resulting movement. The torque is indeed applied at the spot where the torque module is located. However, the resulting rotation of the craft occurs around the Center of Mass, regardless of the torque's location. So this means that if you have a bendy craft with weak connections and torque modules way out on the ends, the weak connections are likely to be broken off when SAS attempts to turn the craft. This may or may not have anything to do with the original space station pulling itself apart. Sometimes torque modules become harmonized with the stations shaking due to the reactions of SAS. When it becomes harmonized, the craft shakes itself apart. This is also real world physics.

This is some really sound advice. I'm actually taking the game incredibly slowly, and am almost embarrassed to admit how much I haven't done. Although I do love looking at some of the fantastic builds out there. Get really good at the parts of the game that you like and the parts that make sense, then expand from there.

Make sure you reset trim on everything. Resetting trim only on the craft you are controlling will not fix it. And welcome to the forums.

Welcome to the forums! There are always a ton of questions in KSP, so don't hesitate to ask even if you think it's a stupid question. A lot of people will be pretty quick to answer any questions about specific topics. It's generally a little harder to give general advice to a new player since there is quite a lot to learn. Starstrider's link is a good place to start for some basics. Specialist's link is really good for when you start having specific questions. There are a lot of really good tutorials in his list. Also, this thread link will take you to the tutorials section of the forum. You can also find a ton of information in there once you start digging deeper into KSP. http://forum.kerbalspaceprogram.com/forums/54-Tutorials

Yes, it appears the parent docking port remembers the UID of the child's root, the child's craft type, and the name of the child craft. The child craft gets shuffled a bit with the child's docking port becoming the child's connection point, and the child's docking port takes on the mothership's docking port as its parent. When the ship splits, the child is reshuffled back and the root part becomes the root again. At least this is what I can discern fom studying save files. I suspect some of the undocking woes are within this splitting/reshuffling process. I've been able to find a way to split ships by using a different connection method within the save file. It's not convenient, but it seems to be effective in splitting stuck docking ports.

Hmm, something else that I just thought of. I don't know what the root part of your vessel is, but I'm wondering if the control reference is being transferred to MechJeb's position. I had a symmetric 4x probe rocket that kept using one of the probe cores as the control reference and MJ had a heck of a time controlling it. MJ was always slightly off with it's pointing which got worse when near the end of a burn. I never landed with it, but when I took off the thing was a mess and I had to provide lots of input. Eventually I had to go back and put another probe core along the center of the ship in order for MJ to not be confused. I would guess the lander can is the root of your ship, but maybe something weird happens with the control reference when docking/undocking. I'm not sure if "control from here" will fix that problem, but maybe give that a try. I have my doubts given how symmetric your craft looks, but might be worth a shot to maybe put the "control from here" on the docking port on top.

Fantastic! Sorry for all the confusion, but I'm glad you got it all worked out. To change your thread, edit the original post and click "Go Advanced". From there, you can change to "answered" via a dropdown, then save.

Docking Ports Won't Connect This fix is for craft that are NOT connected together, and when the docking ports touch they refuse to connect. This is typically because the state on one or both of the docking ports doesn't get reset correctly. 1) Make a copy of your persistence.sfs file and keep it safe. 2) Make sure your docking ports are several meters apart from each other and quicksave. 3) Open quicksave.sfs in a plain text editor like notepad.exe. Do not use WORD or some other processing software. 4a) Changing the Docking Port State Find the "broken" or unresponsive docking ports so you can change the state. You may need to edit both the vessel's docking port and the target's docking port. That section will look something like this. MODULE { name = ModuleDockingNode isEnabled = True [COLOR="#FF0000"] state = Disengage dockUId = 0[/COLOR] dockNodeIdx = 0 EVENTS { Undock { active = False - The broken port may say a number of things, including Disengage or Acquire... Change the state line to read "state = Ready". - If there is a number in "dockUId" make it zero. So it should look like this: "dockUId = 0". The docking port's state could be a variety of things including "Disengage" or "docked (Dockee/er)". Make absolutely sure you are at the broken port. One way to verify that you are at an empty port is by checking the attachment nodes. Scroll up a little and look for this: srfN = None, -1 attN = None, -1 attN = bottom, 0 Make sure that on the "attN" lines, there is no "top" label. So you should NOT see "attN = top, XX". They can be "None" or "bottom". 4b) Delete the "DOCKEDVESSEL" info. Scroll down to the end of the docking port PART structure. Just prior to the ACTIONGROUPS label, check for a "DOCKEDVESSEL" block. ACTIONS { UndockAction { actionGroup = None } DecoupleAction { actionGroup = None } } [COLOR="#FF0000"] DOCKEDVESSEL { vesselName = Docking Rover vesselType = 3 rootUId = 3111877274 }[/COLOR] } } ACTIONGROUPS { Stage = False, 0 Gear = True, 0 ... If there is a DOCKEDVESSEL block, delete everything from DOCKEDVESSEL to the closing bracket (all the highlighted parts above). Do not leave any extra blank lines. 5) Save the file and quickload. Try docking again. Remember, you may need to edit both the vessel's docking port and the target's docking port.

Yeah, he said that in his post.

For torque modules, the distance from the CoM is irrelevant in terms of how well the torque will work. The biggest consideration is as Kasuha pointed out. You want to place them in such a way as to minimize the stress in the particular craft. If you put too many on a part that has a weak joint, the bending will simply snap the piece off.

My guess is you were having problems because the (relatively weak) Jr docking ports were trying to move around a pretty massive payload in order to connect. Also, like Sirrobert said, when you fire that thing up the port is probably going to bend. I wouldn't try to turn at all while the engine is firing. Congrats on getting docked at least.

I have been experiencing this more so in 0.23.5 than I did in 0.23.0. I'm not sure if they are tweaking the MJ code and it's a bit off, or if I just didn't run into it that much in 0.23.0. Although I've noticed the maneuver node steering also seems to run off a bit earlier than it 0.23.5. In either case, I do like others have hinted at and cancel the autopilot when it's getting toward the end. That way I can keep the heading where it's at and complete the burn myself. It's not ideal if you want MJ to do it all, but it works okay for those times when the steering races away. I'm sorry, I can't comment on the landing because I never use it. I know MJ has problems on atmospheric bodies, but that doesn't really help...

Yes, copy the KSP/saves directory over (as others have said). Make sure you COPY and don't MOVE them because if there is an error, KSP will sometimes lock out craft or saves (or just plain delete them). If you copy them, then you'll have a backup in case something happens. Also, when you "install" the updated KSP, I recommend putting it into it's own (new) directory. Don't copy/merge it into your old KSP directory.

Welcome to the forums! You may want to avoid posting into a thread that's 6 months old, because most people will skip over your question and go back to answering the original post, which doesn't do anyone any good. You can't just swap parts around in the craft file. There are all kinds of links and pieces that reference each other based on where they are in the file itself. In any case, what is it that you are actually trying to accomplish? As in, why do you want/need to have the other command pod as "primary"? The SelectRoot mod will change the root part, but that might not help do what you want based on how your craft is built and what you're trying to do. (You may want to post your whole question and a picture of your craft in a new thread. You can post images to a site like http://imgur.com