AHHans

I have no idea. But with two sentinels in well spaced out orbits I can fulfill all the contracts without having to move the sentinels again. (The orbit requirements for the sentinel contracts are fairly loose, so you don't have to be all that close to them to get the "be in this orbit" box ticked.) I have even less idea about that.

O.K. Then maybe having deployed sentinels does indeed cause more asteroids to be detected. I have two looking at Kerbin, one in a lower and one in a higher orbit. (Those two cover - up to now - all "find x many asteroids around Kerbin" contracts without me having to move them anymore.) And I usually have 5 - 10 new asteroids / unidentified objects in the tracking station.

The games doesn't keep you from deploying more experiment stations on a CB. But you will not get anything more from deploying more than one.

As far as I know: wait longer. Hmmmm.... Only 3 asteroids seen in total seems on the low side. Do you have any sentinels deployed on asteroid hunting missions?

There is nothing special about 5000 m. There is somewhat sudden change when you get to (and then through) the speed of sound, at that speed the drag increases quite a bit. There is quite a range of possibilities why a rocket flips out of control. My guess is the following: I understand that you have 6 Vector engines on that craft, together they are four times as strong as a single mainsail. They also have a large gimbal range, so there is a lot of torque when they are steering. That can easily lead to SAS (or your hand-steering) overcorrecting any deviation, in particular if your rocket is tall and "wobbly" and your control point is at the top - far away from the engines. If this goes out of hand your rocket will likely flip. You can try reducing the gimbal range of the vector engines to see if that helps.

Hi @Fenceingmadman You need: Moar Struts! (SCNR!) Well, at least autostruts. You may also want to look at e.g. the following thread: P.S. The Vector is a *bleep*ing strong engine. To me it seems a bit overkill for a 1.25 m side-booster. Doesn't it suck the tanks dry in next to no time?

My Jeb is the only real Jeb! Yours are all cheap impersonators!

Well, action groups are essentially shortcuts for stuff that you can do in the PAW (right-click window) of the parts in the current vessel. I.e. instead of right-clicking on a dozen different solar panels and unfolding them one by one, you can assign that to an action group and unfold all of them at once with the push of a single button. Can you delete a piece of debris by right-clicking on it and selecting an action in the window that pops up? So: No! You cannot create an action group to "delete debris". I deal with your problem in two ways: One is that I don't use stack separators, only decouplers or docking ports. (You can also stage the initial decoupling action of a docking port with the staging system.) That way I don't have single stack separators floating around. Sometimes this leads to KSP-style hot-staging, when a rocket engine stays attached to a decoupler and blows its exhaust onto it until said decoupler gets hot enough to blow up. The other is that I only move a vessel after separation (staiging ot undocking) when it is clear of the other vessel. Often enough this means giving it a push with RCS and then waiting for them to drift apart.

It should not. On PC (Linux) you can deploy the science experiments also in sandbox mode. You just don't get any science from them. (Might be that they immediately shut themselves down.)

Well, give it a try, my guess is that it will work. If it doesn't you could also do the transfer in 1.7.3, and then load that file in 1.8.1. (The savefiles have the version with which it was written inside. So I could imagine that 1.8.1 has some code to fill in entries missing in a 1.7.3 file. Code which might not be called when opening a file that claims to be 1.8.1. But there is probably no significant difference between 1.7.3 and 1.8.1 savefiles.)

I'm not 100% sure that this will work for a jump from 1.3.1 to 1.8.1. E.g. I don't know if the game freaks out if a Kerbal has no lightR/lightG/lightB information. But it should be fairly straightforward to fill in the new fields with default values.

Kind of what I thought, but I couldn't resist a snarky comment. I haven't used the ducted fans myself (yet?), but 250 m/s is more than my propeller planes manage. I haven't built a speed-optimized craft, but I wouldn't be too surprised if 270 m/s or so is a hard upper limit.

Which turbofan engines are you talking about? In a light plane with the panther afterburning turbofan I can supercruise (> mach one in dry mode) and easily manage more than mach 2.5 in wet mode.

Just wanted to say: your arrangement of the five pistons and claws is essentially the same as in my heavy asteroid tug. For me that turned out to be quite useful when pushing around 2000t asteroids with 200t (when fueled) craft. About the gap in your station: I don't see any robotic parts in there, are some of the modded parts robotic?

How much science you get out of an experiment doesn't depend on the quality of the radio connection at all. Even the weakest connection will give you the full transmittable science if it is good enough to connect at all - and your electricity doesn't run out, but that's another topic. Some experiments (e.g. crew- and eva- reports) will give 100% science when transmitted, others (e.g. surface samples, but also mystery goo observations and science jr. materials studies) give only a small fraction of the total science when transmitted and not recovered. In your first screenshot you see that if you recover the mystery goo observation you get 40 science, and if you transmit it you'll get 16.8 science. That is a property of the mystery goo observation experiment, and will not improve with a better radio connection.

That probably means that you don't have enough control authority to pitch up on the runway. Check where you have your elevators - the control surfaces that control pitch - in relation to the COM and the landing gear. In a traditional setup - with the elevators at the tail - you need to be able to push the tail of the plane down in order to pitch up. If the landing gear is too close to the tail, then the leverage arm can be too short to push the tail down and nose up.

Yes, five claws on one craft: one in the center and the other four in a square around that. I first connect with the piston of the center one at full extension. Then retract the piston to pull the craft closer, typically this makes one of the others connect. Then I connect (extend the piston) the claw opposite to that so I can balance out the craft (point to the center of mass) in that axis. The I follow up with the remaining two claws. Finally I lock all the five pistons. If one of the claws doesn't connect but just moves through the asteroid, then that's fine (up to now). The one time only three claws connected was when I was grappling a small-ish asteroid (class-C I believe, quite a bit lighter than the rest of the craft), so the three points of contact were fine. No flipping around or other weirdness observed.

My big asteroid tug uses five Klaws at the end of large pistons to attach to asteroids. That allows me to adjust the length of the pistons to orient my craft to point exactly at the center of mass of the asteroid, and then lock the pistons for a solid connection. Sometimes one of the Klaws touches the asteroid at too steep an angle to get hold, but the even with only four Klaws connected the connection is usually good enough to get a solid grip and push around even the heaviest asteroids. [Grrr... Google doesn't like me removing their cookie from my browser each session, so they decided to liquid me off. So right now it's too much hassle to log into my (an) imgur account to show you a picture.] Edit: I finally bothered to try imgur again, so here is a picture of my craft (but also check out @PTNLemay's solution):

Well, I also think about how stuff would work in real life. So e.g. when designing folding wings I set it up so that when the wings are unfolded the hinges are at their maximum and get pushed into the "end stop" by the forces during flight. Also: don't use physics warp with spinning rotors (e.g. propellers). But in general: "move when no load is there, be locked when load is there" worked fairly well for me.

Not a full solution. You can mitigate this by locking the robotic parts and having autostruts that bind parts on both sides together, but it doesn't go completely away. Sometimes it is also possible to "reset" the parts by unlocking and locking while there is no load on the parts. (E.g. when flying or in orbit.)

Well, that's not too different from the PC version then.

I've managed - at least once - to get the "build a new satellite" tick mark back on a vessel by switching to another vessel (outside physics range) and back. I believe that if the satellite as such is newly launched after the contract was accepted, then it should fulfill that criteria. I.e. if there are no parts docked to the current vessel that were already launched before the contract was accepted, then the "build a new satellite" tick mark should be there. Independent of what has happened with the current vessel in the meantime. And sometimes you can kick the game back into behaving after being buggy, but I won't guarantee that this works every time.

On PC (well, on my Linux version) the "Main Throttle" axis action group doesn't allow to choose between absolute and incremental mode. It only ever allows absolute mode. Is this different on consoles? (In that case I would consider it a bug.) Some unsolicited, but maybe helpful advice: That is a known problem, and I think this issue is worse in game than in real life. The usual solution is to have two counter-rotating propellers. I usually use a small fairing to put two (electrical) engines on the same axis, but a classic twin-engine design also works well. For my prop-planes I don't use the main throttle at all. I keep the max RPM to max, bind the torque limit to one axis group, and bind the propeller pitch to another axis group. Then when flying I set the torque limit to the limit of my power consumption (usually just max), and do the actual thrust control with the propeller pitch. That allows me to adjust the pitch for high thrust at low speeds or increase the maximum speed at which the props generate thrust, and at it allows me to nearly direct control over the airspeed at low speeds by lowering the prop pitch (down to 0 for braking on the runway, or a quick increase for a go-around). The latter makes braking way more easy for a fat-fingered slob like me.

AFAIK it doesn't really matter. I believe that "to root" and "to grandparent" just don't do anything on the root part, and I don't use "to heaviest" anyhow. For myself I usually just activate "to grandparent" on (nearly) all parts, including the root part. In general: yes! During docking the two crafts will become one craft with the new root part being the root part of one of the two original crafts. I don't know how the game chooses which of the two becomes the new root. I personally avoid using autostrut to root for that reason. Does this happen immediately upon docking, or does it wobble itself apart? Does the "F3" menu give any information on what happened? What could have happened is that the "weldable" connections cause the game to treat the parts as different vessels for a moment before the mod kicks in and re-arranges the craft. If they move far enough apart during that moment then the mod cannot (or does not) "stick" them back together. Struts (regular an d auto-) will not connect parts of different vessels, so they don't help during that moment. Hmmm... actually they could cause the problem: if they held the other parts under tension (like a compressed spring) before the docking, then the release of that tension during them moment of non-connectedness could move the parts apart. Some things you could try: Disable SAS during docking. Disable autostruts to root (or heaviest) during docking. Try the stock docking ports and not the modded ones. Don't attach the portable struts until all parts are assembled. But in general: I don't use these mods and I haven't really encountered your problems, so I can only speculate!

In my experience the ability of the robotic parts to take up mechanical load is rather limited while they are allowed to move. But they get much stronger when the parts are locked, even more so when combined with autostruts. In the locked state autostruts are able to traverse the robotic parts, so you can autostrut a part on one side of the robotic part to another part on the other side of said robotic part. Constructs like folding wings that are folded inside a fairing during launch, folded in behind the heatshield during aerobraking on Eve, and then unlock-unfold-relock while hanging off parachutes, or rover wheels that are folded in during launch and unlock-unfold-relock in orbit work quite well for me. (Don't activate autostruts on the robotic part itself, that's bugged in a way that may prevent the part from moving. See: Bug #23492 [Edit: Hmmm... might be that this bug is now fixed.] The usual disclaimers when using autostruts also apply.) The one time I used a docking port on an robotic extension also worked reasonably well. See my comments here: