HebaruSan

This is the inefficient way of going interplanetary. The reason why is complicated but conventionally goes by the name "Oberth effect" if you want to read up on it.

Yup, the setting's label is (still) inverted.

It used to be very possible in the pre-1.0 souposphere / airhogging days. The thinning atmosphere could be compensated for by adding more air intakes, so people did things like this (the black things are old air intake models) and managed to get ridiculous high-atmospheric performance from jet engines:

Nowadays I think the engines themselves have thrust limits based on altitude (I think that's what they changed, don't take my word without checking though), so that doesn't work anymore.

Yup, that's it:

SigmaBinary and SigmaDimensions are throwing exceptions on load. They seem to be trying to talk to the wrong version of Kopernicus.
[ERR 08:37:20.237] AssemblyLoader: Exception loading 'SigmaBinary': System.Reflection.ReflectionTypeLoadException: Exception of type 'System.Reflection.ReflectionTypeLoadException' was thrown. at (wrapper managed-to-native) System.Reflection.Assembly.GetTypes(System.Reflection.Assembly,bool) at System.Reflection.Assembly.GetTypes () [0x00000] in <9577ac7a62ef43179789031239ba8798>:0 at AssemblyLoader.LoadAssemblies () [0x000e6] in <39c0323fb6b449a4aaf3465c00ed3c8d>:0 Additional information about this exception: System.TypeLoadException: Could not resolve type with token 01000028 (from typeref, class/assembly Kopernicus.Configuration.BaseLoader, Kopernicus, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null) System.TypeLoadException: Could not resolve type with token 01000028 (from typeref, class/assembly Kopernicus.Configuration.BaseLoader, Kopernicus, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null) System.TypeLoadException: Could not resolve type with token 01000028 (from typeref, class/assembly Kopernicus.Configuration.BaseLoader, Kopernicus, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null) [ERR 08:37:20.241] AssemblyLoader: Exception loading 'SigmaDimensions': System.Reflection.ReflectionTypeLoadException: Exception of type 'System.Reflection.ReflectionTypeLoadException' was thrown. at (wrapper managed-to-native) System.Reflection.Assembly.GetTypes(System.Reflection.Assembly,bool) at System.Reflection.Assembly.GetTypes () [0x00000] in <9577ac7a62ef43179789031239ba8798>:0 at AssemblyLoader.LoadAssemblies () [0x000e6] in <39c0323fb6b449a4aaf3465c00ed3c8d>:0 Additional information about this exception: System.TypeLoadException: Could not resolve type with token 01000014 (from typeref, class/assembly Kopernicus.IParserEventSubscriber, Kopernicus.Parser, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null) System.TypeLoadException: Could not resolve type with token 0100003c (from typeref, class/assembly Kopernicus.Configuration.BaseLoader, Kopernicus, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null) Try removing those.
You also apparently have an ancient version of KSP-AVC, only compatible with KSP 1.2–1.3, which is throwing lots (thousands?) of exceptions:
[EXC 08:37:36.809] TypeLoadException: Could not resolve type with token 01000024 (from typeref, class/assembly KSP_AVC.Addon, KSP-AVC, Version=1.1.6.2, Culture=neutral, PublicKeyToken=null) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object) Try removing that, too.

Have you tried approaching from normal or anti-normal? Any other orientation can be subject to "drift" as the slightly different orbits get out of alignment, but along the normal axis that effect actually helps you by gradually moving the vessels closer together.

Looks like another instance of this.

Looks like another instance of this.

Looks like another instance of this.

Are you aware that the delta V meter in the VAB has atmospheric and vacuum modes? The delta V maps generally use vacuum delta V, and it's likely you were looking at the atmospheric delta V, which can be significantly less for some engines. If you hover the delta V icon in the toolbar the options should be apparent.

If you're launching your main Steam instance rather than a copy, you might get better results setting the game command line in CKAN to:
steam://rungameid/220200 That should launch KSP via Steam.

That's this:  https://github.com/KSP-CKAN/CKAN/issues/3221
Long story short, you installed ModuleManager manually, CKAN is trying to replace it, but your version is a little old so the filenames don't match up. As a workaround you can try selecting ModuleManager in the mod list, going to the Versions tab, and clicking the checkbox next to 4.1.3 to install the same version you have now, after which CKAN will be able to update it as needed.
The next release of CKAN will handle this better:  https://github.com/KSP-CKAN/CKAN/pull/3287

Kind of ironic that you're posting about a problem that CKAN would have prevented and drastically simplifies the investigation of:

(You're using a ModuleManager that isn't compatible with KSP 1.3.1.)

Kind of:
 
 

Click Refresh and try again.  (https://github.com/KSP-CKAN/NetKAN/issues/7016)

Your "current" stage has 0 m/s dV. KER wants you to stage immediately:

Whatever this decoupler icon is, it's not shown in your VAB screenshot, so that would be the first thing to make consistent:

Alt-F5 (or right shift-F5 on Linux).
https://wiki.kerbalspaceprogram.com/wiki/Key_bindings

KSP by itself doesn't support custom textures; you need to install a mod to use them, usually EnvironmentalVisualEnhancements.
That's not a glitch, the RSS team did that on purpose to simulate some of the challenges of axial tilt.
Possibly. Try naming them and someone might be able to help you.
Yes.

https://spacedock.info/mod/248

You might try CraftManager:
 

Here's a recent discussion of that:
 

The main tech you need is the claw; you use it to grab the asteroid for pushing:

https://wiki.kerbalspaceprogram.com/wiki/Advanced_Grabbing_Unit
As long as you've got that, yes, you can definitely divert an asteroid from hitting Kerbin, though as you've realized, you'll need to rendezvous before its periapsis.
Build a spacecraft with a claw, a Poodle, and maybe 3000 m/s delta V, give or take Attach a launch vehicle that can put it into orbit (i.e., so the 3000 m/s starts once you're in orbit) Launch it to the same inclination as the asteroid Target the asteroid Place a maneuver opposite the asteroid's incoming path Increase the maneuver's prograde component and watch what happens with the close approach markers Fiddle with the maneuver; eventually you should be able to put your craft into the asteroid's path just as the asteroid is reaching the same spot; that's your intercept! Burn Rendezvous with the asteroid (see various docking tutorials for help, this is its own process) Open the claw and grab the asteroid Rotate so you're pointing perpendicular to the asteroid's path Burn and watch the asteroid's periapsis ascend out of the ground As soon as it's >70 km, you're done! Also, spoilers:
EDIT: Further note, 15 days might be a little too long to do this conveniently. It only takes about 7 days to get all the way out to Minmus, which is nearly at the edge of Kerbin's sphere of influence, so if this Kerbin-killer is 15 days out, you might be looking at an intercept outside of Kerbin's SOI, which can be harder to plan. If you wait till it enters Kerbin's SOI, getting the intercept should be a sure thing.

You also need to take the natural logarithm of that mass ratio:
Delta V = 9.81 * Specific Impulse * ln(Initial Mass / Dry Mass)

I wonder if it's getting confused by that fairing. It looks like you put it as the final stage and then deployed it manually. MechJeb might think that the initial "Stage 1" should last 0 seconds because there's no reason to delay the release of the fairing. Then when it looks at the initial "Stage 0", the fairing is already deployed; maybe that confuses it?

I think it's showing your AN/DN relative to the target orbits.