bewing

Use the KML Persistence File Editor.

The easiest way is to hit F1. Then, underneath your KSP main folder you find the folder called Screenshots. They are numbered sequentially, so it will be the one with the highest number. Then go to the image hosting website www.imgur.com, click the New Post button, drag and drop the image from your Screenshots directory. Wait for a minute and imgur will give you a URL to the image it stored. Post that URL here.

Could you post a picture of what you are doing, just as you are about to click the button to shoot? That would help to make sure nobody is forgetting a step.

You have to have the debug window open, the "armed" box checked, aim with the cursor, middle mouse button to shoot.

Are you familiar with ROCs? They are explained in KSPedia. They are unusual features on the surfaces of all the CBs. Crystals, trees, special craters, mineral veins, etc. You need to drive up really close to one of these things and then activate the scanning arm. It counts as a new kind of science experiment. They are intended to be used with rovers. It's highly unlikely that you could park a simple lander close enough to a ROC to get a reading from it.

2. In the debug menu, click the "ignore max temperature" button. That's the only way you can even get close.

Those are actually very small control surfaces. Only a very small portion of them actually adjusts. In your next design that needs control surfaces, use tailfins instead.

It always rotates back to the default direction for the part that you detached.

Did you download from Steam? On many occasions, steam downloads have one or two small errors that need to be fixed with a "file validation." Do you know how to do a file validation? That's exactly what your problem sounds like to me.

I was talking about inside the VAB. No camera modes there.

Well, even on console (at least with the proper preset) you have fairly quick access to 10 custom action groups. So that really should be enough for most things. And you shouldn't need to assign the landing legs to the "gear" group -- that should happen automatically, I think. That bug has never existed on the PC version that I know of ... so if it ever happened on consoles, then it's exclusive to consoles and the rest of us would never know about it.

Look out the door of the VAB from inside. You see the launchpad there in the distance? The game does not rotate your craft between the VAB and the pad. However -- the rest of your comment talks about the control direction of the craft. The default control direction of the craft is based on the final orientation of the pod or probe core that controls the craft. Specifically: if you put a probe core at the top of your rocket and leave it in the default orientation, then D is East on the pad. You can see this by looking at your navball. If, when you placed that probe core, you hit W twice before you actually put it down -- now the probe core is placed backwards and A is East, even if the rest of the rocket has not changed. If, when you place the probe core, you hit S twice -- now your probe core is upside down. All your controls will now be reversed, because everything is in the opposite direction. Even more: if you build a default rocket, then grab the entire thing and hit W twice -- then every single control point on the rocket will be turned around backwards and A will be East on the pad because now your rocket itself is backwards. If you build a default rocket, separate the top half (with the pods and probe cores attached) and hit W twice and reattach it, then every single control point will be turned around backwards, even if half of your rocket is still pointed in the original direction. So, you can always tell the orientation of the rocket as a whole before you launch. However, to tell the orientation of all the control points (pod and cores), you need to look at them very closely and you need to know which side of them is supposed to point north and south.

The preset action groups perform default actions in addition to any that you assign. So yes, adding something to "stage" will blow off a stage when you hit space -- as well as performing your additional actions. However: lights, gear, brakes, RCS, abort, & etc are usually pretty harmless when it comes to their default actions. Especially if you make them an action group for a sub-vessel that has no brakes, gear, RCS, etc. Of course, most action groups only serve to avoid doing a few repetitive keystrokes. So if you really do end up short of action groups, you can look them over and figure out which action group is the least useful, and then do that one by hand instead.

In staging view, you can keep fuel and orbital info on the screen in stock KSP, as long as you are at a current version. You can pin the "resource app" open by clicking on it. You can see orbital info by opening the new "Maneuver Mode" info pane in your staging display.

The problem is that if you come to a close rendezvous, and come to a 0.0 relative velocity dead stop -- then the answer is "instantaneously" to some degree of accuracy. So 1) you need to specify the minimum relative speed that classifies as "different orbital directions", 2) it depends on your orbital velocity, because it's a lot different at 2200 m/s than it is as 150 m/s, 3) it depends on the geometric configuration of the two rendezvoused ships and their exact distance -- a ship at 100m normal separation is going to have a nearly identical orbital period, and one with a 100m altitude difference is going to have a totally different period. And it's the difference in periods that is the main cause for orbital drift. But just to put a number on it, in LKO after a rendevous and dead stop, I usually figure I have 30 seconds before things start to drift too badly.

It depends on your difficulty settings when you begin each new game. I believe 12% is the max for a 100% resource concentration game?

Yes, KSP does model "blowing into your own sail". We call it "exhaust obstruction". The game checks for a medium distance to see if any part of your craft is directly behind the exhaust plume. An asteroid counts as being part of your craft. If it finds something there, then 100% of your thrust gets cancelled. If you want to use a pulling-tug, then you will need to do some tests on the ground before you launch your craft to find the obstruction distance. It's long enough to be a nuisance, but not so long as to be insurmountable.

Fuel transfer does not really depend on the craft. To transfer fuel, you need to have a minimum Level 2 R&D facility, and you may need to uncheck the "fuel transfer obeys crossfeed settings" button in your game's Advanced Settings.

Friction and traction control are two different things. Make sure you are looking at friction. And this particular thing isn't a bug -- this is all engineering stuff that needs to be dealt with IRL too. If you want bugs, you should try playing some bethesda games.

The landing lights are supposed to point forward to light the terrain that you are approaching. However, I have never had a single problem with turning them around when I felt like it.

Ah. You are mistakenly addicted to maneuver nodes. The point of the exercise is to realize just how wonderful and efficient your MK1 eyeballs are. Wait until your craft is almost at the An/Dn line, then burn (locked Normal/Antinormal if you have it on SAS) by hand. Yes, you lose the tiny pythagorean bonus from burning on a predefined maneuver axis.

Well, if what you listed out is accurate, that doesn't sound like any stock contract. So you are using some sort of mod? This old thread is probably not the best place for your question, so I think you should start a new thread about your issue, including posting a screenshot of your contract -- since it sounds unusual, or the way you are trying to complete it is very non-standard.

On a contract with a target orbit, the UI always puts an An and Dn on the target orbit. You probably see the markers but ignore those numbers, assuming they don't apply to your current craft. However, they DO apply to your current craft. All the An and Dn numbers on every target orbit are always calculated relative to the currently selected craft. Change which craft you have selected, and notice that all the target An and Dn values change. You don't need to select any specific orbit as the target, because all the target orbits are continuously updated.

I can't load your craft, because it has a modded part and I'm running stock. I think it's a mechjeb part? Anyway, this is a very common problem. Common enough that it actually has an entry in the FAQ on this forum. Unfortunately, there are many possible specific causes for runway veering and each has a somewhat different fix. As far as I'm concerned, the most likely source is that there is too much drag against the ground on the front gear, and not enough on the rear to make the SSTO directionally stable on the ground. The easiest way to fix/test for this is to open the front gear in the SPH, switch friction from automatic to Manual, and reduce the friction to somewhere between .4 and .6 -- if that doesn't fix it, try reducing it incrementally all the way down to zero.

However, if you need to do a prograde/retrograde/radial adjustment, it is most efficient to do that at a different point in the orbit than the plane change. So in order to consolidate all those adjustments into one, then you need to compromise on "efficiency".