AHHans

I was just about to mention that in response to @Snark's post. But that is more a feature of Eve and not something that you need to worry about on Kerbin. (Eve finds lots of different ways for making your craft go boom.)

That's why Minmus has lakes! So that there is one place where you can land without your lander constantly sliding around. P.S. Just wait until one of your Kerbals stumbles and then takes a 5 km and 10 min slide downhill on one of Minmus' icy slopes...

As others already said: you first need to pitch over manually (and then let the prograde come down, as explained in my other post) before "locking to prograde". Also the optimal time and amount to pitch depends on the rocket. With this rather high TWR rocket(*) you need to pitch over more aggressively (than my usual rockets), so pitching 10 deg when you reach 50 m/s is O.K. for this rocket. I also want to encourage you to try out different ascent strategies (pitching sooner or later, pitching more or less, throttleing down or not, etc.) and see how well they work. And feel free to post another video. (*) The one from you video without the SRBs.

Hi. Welcome to the forums. Just yesterday we had a similar question, maybe the answers in there could help you:

You got into orbit, so you didn't do anything wrong!(*) The main issue that I noticed is that the rocket has a very high TWR. Just the SRBs alone give it an acceleration of 3g directly off the launchpad, and peaking near 6g. (Just be glad that Kerbals are not as squishy as humans. SCNR!) For that case the rule-of-thumb numbers I mentioned (for when you need to pitch and how far) are not the best anymore. Such a high acceleration at the start is always wasteful because you become too fast too low in the atmosphere where drag is much stronger, and you need to carry a too heavy engine around with you. My suggestion is to just remove the SRBs, you don't need them to get to orbit. (I just tried a re-creation of that rocket.) And that way it is more of a challenge. If you want to make it a bit easier, then remove the extra reaction wheels, the gimbal on the swivel and the terrier give you enough control authority. [Edit:] O.K. if you do the "circularization" burn right the rocket without the SRBs even has enough dV to get into orbit when going straight up to an AP of 85km and then starting the circularization once it it out of the atmosphere. That's fine! I don't think you could gain significant amounts of efficiency by doing that better. P.S. (*)You did several things right though! Starting by playing KSP in the first place.

That used to be needed, but recently @SQUAD introduced the maneuver view that can display your apoapsis height and time to apoapsis in the ship view, so there is less need to switch to map view. If you switch on "Show Extended Burn Indicator" then you can have the the game do that bit of math for you. And more importantly: have the "warp to next maneuver" stop 1 min before it is time to start, and not 1 min before the maneuver. And while you are in the settings: switch on "Advanced Tweakables" if you haven't done that already. If you are interested enough in KSP to get here to the Forums, then you'll want that sooner or later.

You can set the window in the lower left of the screen to "Maneuver Mode" and then to display you current Apoapsis, Periapsis, and the times to reach them. You want the time to apoapsis to increase or stay constant until your apoapsis is where you want your orbit to be. Then you can switch off the engines and coast to your circularization burn. I suggest to first try to do this and get a feel for that. Then you can refine it even more and try to keep the time to apoapsis from getting too high - having it at just more than 1 min is a good value to aim for. The most efficient way for this with a well built rocket is to pitch over the right amount so that you don't get much over that without throttling down. An easier way to do this is to throttle down when your time to apoapsis gets too high, i.e. to use the throttle to manage your time to apoapsis.

Sorry, I have a hard time picturing your problem. But no, there are no known problems with any elevons. They all perform as well as can be expected.

Sorry, I guess in trying to be more precise I made it unclear. What I meant is: when you go straight up and then pitch over, then at first your prograde vector will still point straight up and only over time it will come down as you gather horizontal velocity. So don't pitch a few degrees and then go back to straight up just because your prograde vector points there - e.g. by pitching and then immediately hitting the SAS follow-prograde button.

An image would help! But the short answer is: if your plane doesn't want to point its nose into the wind (i.e. prograde) then it is aerodynamically unstable. The CoL display in the editor shows only the lift, not all the the aerodynamic forces. And it only shows the lift for small angles-of-attack. So with significant drag (and the MK2 parts are (in)famous for high drag at nonzero AoA) and or high AoA the position of the center-of-pressure (where the sum of the aerodynamic forces actually attack) can be at quite a different position. And when you get to building spaceplanes: at supersonic (or even hypersonic) speeds high in the atmosphere the lift (relative to the drag) gets smaller and the drag starts dominating the CoP. So a craft that flies perfectly fine at slow speeds may suddenly flip out when you try to get to orbit. [Edit:] P.S. A RL example of a plane that gets less stable at high AoA is the 737 MAX.

No. In a stock game any craft (debris or not) that is outside physics range and below a certain altitude (IIRC 20 km for Kerbin) in the atmosphere (i.e. not landed) will just get deleted. The game doesn't compute the physics of craft outside the physics range, so it doesn't know if the part will crash or if it has enough parachutes to land softly or whatever. So to keep things simple anything below the magic altitude is just assumed to be destroyed. In a similar fashion: craft in an orbit that dips into the atmosphere (but not low enough to be deleted) will not have their orbits decay if they are outside physics range. What I do regularly is to recover the last stage of my rockets that was on a suborbital trajectory and still high enough when the payload finished circularizing into orbit. I.e. I first put the payload into orbit, and then switched to the booster and followed it down to a more or less safe landing.

Great! Just as a general advice: it helps a lot to learn how to read the navball. I fly most maneuver nearly exclusively with the Information I get from the navball. Another comment that I have is that the ascent profile that you described (straight up to 30 km, then pitch over 45 deg) if fairly inefficient. (But it works, so don't sweat it!) It is more efficient to pitch over much sooner but not so far, and then follow the prograde direction until you are in orbit. Pitching about 5-10 deg as soon as your rocket is at 50 - 100 m/s speed and then following the prograde vector once it is down to your pitch angle is usually a good strategy. But the exact parameters depend on the rocket (how much TWR and how much drag it has during its flight). Feel free to experiment. Earlier this year we had a challenge to find the best launch profile for one of the stock craft:

Hmmmm... Is it also a liftoff when you get the wheels of the runway by raising the gear? (Assuming that you don't fall back to the runway.)

High-ish false positive rates don't make the tests useless, even in low-incidence populations. What they are useless for is to tell which individuals are immune or not - but that is a stupid idea anyhow for several reasons - but they are useful to figure out how prevalent the infection was in the tested population. You do have to be careful when interpreting the result though. E.g. 10% positive results with a test that has a 5% false-positive rate doesn't mean that 10% of the tested population is positive.

For all bodies without atmosphere (that I tried up to now, i.e. Mun, Minmus, Ike, and Gilly) I got the seismic science by dropping spent stages or other obsolete craft on it. Preferably having them impact from the transfer, but dropping old landers from orbit or drop-tanks during landing also works. Duna required a dedicated impactor that was designed to be reasonably streamlined, and that I "rode down" i.e. had as active vessel during the atmospheric entry and all the way down until the crash. And Eve?!? Well, Eve is Eve. I finally build massive robotic planes, that mined up a few hundred tons of ore in Eve, then flew to the experiment site and still only got the 50% done when crashing at 4x physics warp...

Thanks. So when you choose to control from the command-pod (with the control direction as default) then you shouldn't have any SAS issues. When you control from the claw, then the gimbal of the rocket engines will be in the wrong direction. (I.e. their torque will fight with the torque from the reaction wheels and RCS (if active).) It would also help to see the target marker from targeting the CoM of the asteroid. Does that move when you are accelerating? Probably not. If you want to give them more leverage to generate more torque, then you would need to move them farther away from the asteroid, i.e. make the rocket longer. What may be a problem is if the asteroid is too close to one (or more) of the engines and screens the exhaust (thrust occlusion). In that case that engine would not generate thrust and the thrust from the engine on the other side would not be balanced.

Well, this is a case where a picture would say a lot more than some hundreds of words. I don't really have a good idea how your craft looks like. The issue that @OHara mentions occurs when the control direction is not pointed in the direction into which the engines apply their thrust. But it could also be that your thrust vector isn't really pointed 100% through the center of mass. (I never got that perfect when pushing class-Es, so I always had to apply some torque to keep the craft straight. So I limited my engine thrust to what the RWs could compensate.) I understand that you are pulling the asteroid. That only gives you any benefits if the asteroid is free rotate behind your craft (see pendulum rocket fallacy). Do you have the pivot of the claw locked or free?

Yupp, it does! Although, we usually call it CommNet. KerbNet is the "mapping tool" (if you really can call it that) in stock KSP. Many a probe has found their death unheard and alone on the far side of the Mun or Minmus(*) because they got into the radio-shadow of the moon. (*) Or Duna, or Ike, or actually any CB in the game. I think the main reason I haven't crashed into Eeloo (yet) is that I only went there once with a probe.

Hmmm: multiplayer KSP and then a race with these things.

Indeed! And I just remembered: when you come in at too much of an angle, then there is also the Matt Lowne method of aligning a craft for docking.

And how does increased speed help there? When I'm docking large craft then I'm going extra slow (during the approach) so that I have more time to get well aligned.

Well, I use a rover with a claw up front. Well actually a plane/rover/rocket contraption, with a retractable nose-gear that will scrape the claw over the ground when the nose-gear is retracted, a main engine to push it foreward, and lifter engines to get it off the ground (and the nose upwards) when it's time to lift. Up to now I always managed to grab the target with a combination for pushing it around and raising/lowering the nose(-gear). Once the target part is grabbed it has enough thrust (and gimbal range) to get to space - with or without the help of a handy hill.

Is it this bug (quoted from Flying Rock Challenge): Wait, you said "Scenario"? ... *click* *click* *boost* *curse* *click* *clack* *boost* *grab* ... Yupp! It is that problem! You are trying to drag along an asteroid that masses 150 t instead of the 30 t that it is supposed to have.

Indeed! This behavior is especially ... errrrrm ... interesting when you switch to a cabin in a rotating gravity ring. (One more reason to switch off SAS on space stations.)

Indeed! My guess is that some part of the "game" - probably a mod - got updated and that this caused the craft to get screwed up.