AHHans

So the docking port is right in front of the the other docking port but at quite some angle. Now in order to dock your ship has to rotate to get the ship docking port pointed at the station docking port while keeping the ship docking port mostly where it is. So it needs to swing the whole ship around, while not gathering enough speed to fling the ship completely away. In large and heavy ships that takes ages if you rely on the magnetic forces of the docking ports. It may work to just switch off SAS and MechJeb to just let the magnetic forces get your craft oriented. But that will only work if you don't already have too much speed to get away from the magnetic forces again. AFAIK that's the distance from your CoM to the target docking port. So it will never get smaller than the length of your ship from the docking port to the CoM. No. The fact that your ship is long and heavy is part of the problem because it means that it has a high moment of inertia and you need a large torque to get it turned. In addition turning it around the docking port (= re-orienting the ship while keeping the docking port in place) means moving the CoM quite a bit. If you have solely been relying on MechJeb for docking then I also recommend to learn to dock manually. Just enough to learn what is needed for docking and to see when MechJeb is failing and needs help with docking. A good guide is @Snark's Illustrated guide to docking Why do you say that? Docking means coming to a stop when the two docking ports are touching, so there is no minimum speed for docking. It's quite the opposite: if you are too fast when touching the docking port then you just bounce off, even if everything else is aligned perfectly. My recommended speed for docking is 0.1 m/s, maybe a bit less. (I typically slow down so that the display just switches from 0.1 m/s to 0.0 m/s just before I get close enough to feel the magnetic forces.)

Sorry, I can't reproduce that. I only have two types of craft in long-time use that have several robotic parts in a row in a row. One is a Very Kerbal Array that I have in Kerbin orbit and the other a science shuttle with an extending boom for a scanning arm. Both were fine when I visited them with all the parts locked or unlocked as they should be and all in the correct position. One point is that they are all in space in microgravity, so there are no forces acting on the parts that the locks have to withstand. On the other hand the folding-wing airplane that I have parked on Eve is also fine. Well, the parts - in particular the propellers - are moving around as I mentioned in "bent 3P Telescoping Hydraulic Cylinder", but the hinges that fold the wings are still in their position and still locked.

O.K. While my explanations in the other post are correct they don't really address the actual issue: which is that when a section of a craft is staged away that doesn't contain a crewed command point, then the "control point" of the discarded part is not set to the probe core controlling the part but to the new root part of the detached section of the craft. (what?(*)) So for your vehicle you need to explicitly select control from the probe core after switching to the missile by activating "control from here" on the probe core. My suggestion is to put "control from here" of the probe core on an action group and hit the corresponding button after switching to the missile. (That's faster than messing around with the mouse.) I would also suggest to add a vertical stabilizer to the missile. It makes it a lot more stable in flight. [Edit:] (*) What the <well, you probably know what>? Even a IMHO fairly harmless three-letter-acronym gets censored by the forum software?

I believe that not the cylinder as such is bent, but that the point at which it is attached has moved somewhat and that it is now attached at some angle, same for the claw at the other end. In general that happens to all parts when you put a strong force on them, but the robotic parts move a lot more than the non-robotic parts. (I mean a lot!) AFAIK you cannot undo it once it has happened, and you cannot completely eliminate it. You can mitigate it somewhat by reducing the force on the parts. So designing your ship that there is less force transferred trough the robotic part. (Yes, great. I know that is usually not possible. ) The parts also seem to be able to deal better with straight compression forces than with shear forces or tension forces. (But, again: how to get straight compression forces without any shear forces?). The most practical mitigation strategy that I found is the strategic use of autostruts: when a robotic part is locked then autostruts can traverse it. So if you have a part on one side of the robotic part that is autostrutted to a part on the other side, then a part of the force is transferred via the autostrut and not via the robotic part. (Even better if you have multiple autostruts that can transfer the force around the robotic part.) The usual disclaimer about the use of autostruts apply.

In KSP the rocket engines start generating thrust immediately after starting (in contrast to jet engines which need to spool up), and there is a mandatory delay between two staging events (in order to reduce the number of accidental multi-staging incidents). So in a setup like yours it is most convenient to just stage all rocket engines and the decoupler(s) in the same stage. Well, how the pitch, yaw, and roll directions map onto your craft depends on the orientation of the probe core(*). If you mount the probe core backwards into your missile then pitch, yaw, and roll can still map onto the same axes that the design of the missile suggests but the probe core will believe that the missile is flying backwards and the directions are all inverted. If you then also rotate the probe core 90 degrees, then the probe core not only thinks the missile is flying backwards but also that it is flying on its side. So when the probe core pitches up or down then the missile will move in the horizontal direction. You can check the orientation that the probe core is in by looking at the navball. If the center of the navball points to the ground while your missile is going up and the retrograde marker is in the center of the navball, then the probe core is built in back to front. Similar for having a rotated probe core. (*) Well, to be more precise: the control point which can be a command pod, cockpit, probe core, or docking port. But if you only have a probe core on your missile then that probe core it is.

Do you still have the *.craft file of this broken ship? Could you put it somewhere where I can download it?

Well, do you know any violet cows that are not associated with the production of chocolate? Or do you know any non violet cow related snack that comes in packaging and shape that is depicted on the promo picture?

Well, yes, cows are not made of chocolate. But they give chocolate, in particular the violet ones!(*) Also they don't mind if you take it from them. And I had said "beyond reasonable doubt", so if you doubt this then I need to consider you as being beyond reason! P.S. (*) Sorry, the better quality commercials that I found were all in German only.

Kind of. After a staging event that splits the craft (e.g. firing any kind of decoupler) the calculation computes the dV on the part that contains the root part. How else should the game know for which of the two parts you want the dV calculated? (Or do you want to have the dV of the spent stage that you just dropped shown?)

They are fairly high up in the tech tree. But if you don't know them, then you need to give them a try. Especially on an otherwise fairly small rover. Then you may understand why my first reaction to them is: "Why?!?"

Errr. You know that this freeze-dried so-called ice cram isn't actually eaten by astronauts? Have a look at this article: Space is the best place to eat ice cream P.S. I also consider the "this may not be chocolate" idea to be heresy. It has been proven beyond reasonable doubt that cows do exist on Kerbin, so obviously Kerbals snack on chocolate!

Indeed! The first dock that connects will work like a "normal" dock, i.e. somewhat like a regular connection made in the editor. The other docs that connect will act more like struts. One interesting feature of "multi-docking" is that if you undock the primary dock without having undocked the other docks, then one of the other (previously strut-like) docks will become the new primary dock.

@KerikBalm: Sorry, I wasn't clear. I hope the edit makes it better.

"He stared in shock, screamed 'WHY', and subsequently dropped dead on the spot." [Edit:] I know the XL3 are great, but whenever I think about them that quote comes to my mind.

And which one is the Cadbury cow?

Let me quote from the Convert-O-Tron 250 wiki page: So, yes, you can power the Convert-O-Tron with fuel cells and have fuel left over. (Don't ask, it's Kerbal physics.) Or you can power it with many solar panels or many RTGs. Or a combination of those. I personally have changed my solar-powered Minmus miner to work in the Joolian system by adding two RTGs (to always have some power) and a fuel cell array. So it doesn't have enough generating capacity with any method on its own, but together it should work O.K.

Hmmm... that would happen if the thrust was occluded, i.e. if there is a part of the vehicle in the way of the exhaust. But you wrote that there is nothing in the way of the exhaust. And the only other way that thrust occlusion makes itself known is by heating the occluding part. So, sorry, I don't have a good idea what your problem is.

Well, gimp your own cow then.

Like that?

Did you check the mass of the vessel? If you have an asteroid in tow, then you may be affected by bug #24855. [Edit:] Oh, you said you are using 1.8.1, so the asteroid bug shouldn't affect you, but still a good idea to check the vessel mass.[/Edit]

That's what this forum is here for. So ask away!

Better! What I can say is that you are not really aligned well and not moving towards the docking port. (If I interpret the MechJeb output correctly then you are moving mostly perpendicular to the docking axis.) Is that after you "bounced off" from the docking port? Do you feel any force from the magnetic attraction of the docking ports? The "distance to dock axis" in the MechJeb output is that for the docking port of your ship, or for the CoM of the ship?

I'm wondering Is there any benefit to using the exact same craft(*) for the second mission? And/or to visiting several destinations in a mission? (*) New launch but same craft file

You mean like that:

So: chocolate!