Starman4308

While the inclination is a problem, it's not the biggest problem. The biggest problem is that Moho is in a much lower specific-energy orbit: if you transfer straight from Kerbin to Moho, you're traveling several kilometers/sec relative to Moho at the encounter.
What can save you several km/s is using gravity assists off of Eve and Moho to shed some of your orbital energy. It's a little tricky to set up courtesy of the differing inclinations of Kerbin, Eve and Moho, but a careful series of gravity assists can really help you shed energy and enter Moho's SOI with a much lower excess velocity.
The three tips I can give: take careful note of where you encounter a planet when setting up a gravity assist (as you will always wind up returning to roughly the same spot), it can help to set up resonant orbits (e.g. having a 2:1 vessel:Moho orbital period ratio so you re-encounter Moho in two of its orbits), and remember that gravity assists can change inclination as well as orbital energy.
EDIT: And if you're wondering what I mean by "shedding energy", that's basically just going to a lower orbit. While going into a lower orbit means you pick up kinetic energy, you lose more gravitational potential energy than you gain in kinetic.

Modern operating systems generally are pretty lax about memory management: unless it's actually running out of memory, it's cheaper to keep old, no-longer-needed objects hanging around in memory than spending CPU cycles figuring out what can and can't be cleared out of memory. The same is true of KSP itself: you'll occasionally see the game stutter for no apparent reason: what it's doing is "garbage collection" where it finds pieces of memory which are no longer needed, and frees up the space for re-use.
The closer KSP is to its memory limit, the more frequently it has to do GC runs, and more time is wasted scanning over objects which are still in use. So, if your system has the physical memory to spare, it'll happily just eat up the memory until the OS says "no more"*.
*The actual amount of memory KSP can use I'm not 100% clear on, but the general theory of "it's often cheaper just to let stuff accumulate and have rare GC runs clear up a lot of memory each time" holds.

Modern operating systems generally are pretty lax about memory management: unless it's actually running out of memory, it's cheaper to keep old, no-longer-needed objects hanging around in memory than spending CPU cycles figuring out what can and can't be cleared out of memory. The same is true of KSP itself: you'll occasionally see the game stutter for no apparent reason: what it's doing is "garbage collection" where it finds pieces of memory which are no longer needed, and frees up the space for re-use.
The closer KSP is to its memory limit, the more frequently it has to do GC runs, and more time is wasted scanning over objects which are still in use. So, if your system has the physical memory to spare, it'll happily just eat up the memory until the OS says "no more"*.
*The actual amount of memory KSP can use I'm not 100% clear on, but the general theory of "it's often cheaper just to let stuff accumulate and have rare GC runs clear up a lot of memory each time" holds.

Modern operating systems generally are pretty lax about memory management: unless it's actually running out of memory, it's cheaper to keep old, no-longer-needed objects hanging around in memory than spending CPU cycles figuring out what can and can't be cleared out of memory. The same is true of KSP itself: you'll occasionally see the game stutter for no apparent reason: what it's doing is "garbage collection" where it finds pieces of memory which are no longer needed, and frees up the space for re-use.
The closer KSP is to its memory limit, the more frequently it has to do GC runs, and more time is wasted scanning over objects which are still in use. So, if your system has the physical memory to spare, it'll happily just eat up the memory until the OS says "no more"*.
*The actual amount of memory KSP can use I'm not 100% clear on, but the general theory of "it's often cheaper just to let stuff accumulate and have rare GC runs clear up a lot of memory each time" holds.

Modern operating systems generally are pretty lax about memory management: unless it's actually running out of memory, it's cheaper to keep old, no-longer-needed objects hanging around in memory than spending CPU cycles figuring out what can and can't be cleared out of memory. The same is true of KSP itself: you'll occasionally see the game stutter for no apparent reason: what it's doing is "garbage collection" where it finds pieces of memory which are no longer needed, and frees up the space for re-use.
The closer KSP is to its memory limit, the more frequently it has to do GC runs, and more time is wasted scanning over objects which are still in use. So, if your system has the physical memory to spare, it'll happily just eat up the memory until the OS says "no more"*.
*The actual amount of memory KSP can use I'm not 100% clear on, but the general theory of "it's often cheaper just to let stuff accumulate and have rare GC runs clear up a lot of memory each time" holds.

Modern operating systems generally are pretty lax about memory management: unless it's actually running out of memory, it's cheaper to keep old, no-longer-needed objects hanging around in memory than spending CPU cycles figuring out what can and can't be cleared out of memory. The same is true of KSP itself: you'll occasionally see the game stutter for no apparent reason: what it's doing is "garbage collection" where it finds pieces of memory which are no longer needed, and frees up the space for re-use.
The closer KSP is to its memory limit, the more frequently it has to do GC runs, and more time is wasted scanning over objects which are still in use. So, if your system has the physical memory to spare, it'll happily just eat up the memory until the OS says "no more"*.
*The actual amount of memory KSP can use I'm not 100% clear on, but the general theory of "it's often cheaper just to let stuff accumulate and have rare GC runs clear up a lot of memory each time" holds.

Modern operating systems generally are pretty lax about memory management: unless it's actually running out of memory, it's cheaper to keep old, no-longer-needed objects hanging around in memory than spending CPU cycles figuring out what can and can't be cleared out of memory. The same is true of KSP itself: you'll occasionally see the game stutter for no apparent reason: what it's doing is "garbage collection" where it finds pieces of memory which are no longer needed, and frees up the space for re-use.
The closer KSP is to its memory limit, the more frequently it has to do GC runs, and more time is wasted scanning over objects which are still in use. So, if your system has the physical memory to spare, it'll happily just eat up the memory until the OS says "no more"*.
*The actual amount of memory KSP can use I'm not 100% clear on, but the general theory of "it's often cheaper just to let stuff accumulate and have rare GC runs clear up a lot of memory each time" holds.

Almost forgot to get back to this.
1) On how to make an equatorial LEO orbit in RSS: Mostly, you don't. There's no real reason to, and the plane change maneuver necessary when launching from most launch sites is brutal.
2) MechJeb can create a maneuver to change your inclination at an equatorial AN/DN.
3) If you're trying to match planes with a specific target, my general suggestion is to use the stock AN/DN icons in the map, which will update based on your maneuvers.
 
4) To reach the Moon in RSS, there are three typical cases:
A: You are launching from a site with latitude less than the Moon's inclination. In this case, just wait for the Moon's orbital track to pass over the launch site, and launch into the Moon's plane. There's some discussion on the exact math involved here:
B: You are launching from a site with roughly the same latitude as the Moon's inclination. This is a special case of A, where you wind up launching due east. In the absence of Principia, Kennedy Space Center is basically always this way.
C: You are launching from a higher latitude. This is more complicated. What I generally do is wait for these conditions to be true.
First, the Moon has to be about 60 degrees before one of its equatorial nodes. This happens twice a month.
Second, your launch site has to be pointed 90 degrees away from one of its AN/DNs, preferably in the orientation where an eastbound launch will minimize relative inclination.
By having both of these be true, you can meet the Moon at one of its ascending/descending nodes, and hopefully minimize plane-change dV.

The big factors here are Kerbin's rotation and that, when in a stable orbit, you always return to the place of your last maneuver.
 
At the equator, Kerbin rotates by about 175 m/sec. As such, when launching due east from said equator, you gain 175 m/sec of bonus velocity.
Launching due north, you don't actually get a 90 degree orbit; you get something like 85-ish degrees inclination. This is because, while you're adding northwards velocity... you're not cancelling out the eastwards spin of Kerbin. To actually get a perfectly polar orbit, you have to launch slightly west of north.
Launching due west, not only do you lose the 175 m/sec spin advantage, you have to pay it all over again just to hit zero horizontal velocity. As such, it's a 350 m/sec penalty to launch west.
 
At a higher-latitude site, you start with less velocity from Kerbin's spin, all the way down to zero were you to launch from the poles. This can help when launching to polar or retrograde orbits, as you have less eastwards velocity to cancel out... but it is a hindrance if you do want to go for an eastwards or mostly-eastwards orbit.
 
One other significant advantage of equatorial launch sites is the ability to access low-inclination orbits without plane-change maneuvers. You always return to the last place you made a maneuver. So, if you make your ascent-to-orbit at 40 degrees latitude, even traveling due east, your resulting orbit will have at least one point at +/- 40 degrees latitude, meaning an inclination of at least 40 degrees. While there are multiple tricks to make this less of an issue, it'll still always be a fundamental limitation: no equatorial orbits without some sort of dog-leg or plane-change maneuver.
This is part of why the real-world Korou is a fairly attractive launch site; being dead-on at the equator, Korou not only gets a substantial benefit from Earth's spin, but it also minimizes the plane-change to get to geostationary Earth orbit.

First off: welcome to Rocket Science: The Video Game.
 
Second, the very quick version:
Find the vessels' ORBIT nodes.
SMA should be identical. This is the most important thing, since orbital period (how long it takes to complete one orbit) is a function only of SMA.
ECC should be very low but preferably not exactly zero.
INC should be either identical or close to identical, close to 0 for equatorial, close to 90 for polar.
LPE should be identical.
LAN should be identical.
MNA should be: 0 for one relay, 2.0944 for the second, and 4.1888 for the third
EPH should be identical.
REF should be identical, and presumably refers to Duna.
 
Third, the rocket scientist's version.
A typical orbit, such as the Moon around the Earth, is just one kind of orbit, called an elliptical orbit. There are also circular orbits (a special case of elliptical), hyperbolic (an escape trajectory), and parabolic (a special case of an escape trajectory).
An elliptical orbit is an ellipse (an oval), in a plane, with one focus of the ellipse at the body that you are orbiting around.
 
The oval is defined by the semi-major axis (which specifies 1/2 of its length along its long axis), and its eccentricity (how oval vs. circular it is).
Semi-major axis is equal to (1/2 * (Pe + Ap)), where periapsis and apoapsis are measured from the center of the orbited body, not its surface. This, by the way, is the only orbital element necessary to calculate orbital period (how long each orbit takes).
Eccentricity is equal to ((Ap - Pe) / (Ap + Pe)) for an elliptical orbit. A perfectly circular orbit has an eccentricity of 0, though that might give KSP a fit because of the other orbital elements that depend on periapsis.
 
The plane of the orbit is defined by inclination (how tilted it is with respect to the orbited body's equator) and longitude of the ascending node (at what point it crosses the equator going up). Inclination varies from 0 to 180 degrees, with 0 being an equatorial prograde orbit, 90 being exactly polar, and 180 being retrograde equatorial. Longitude of the ascending node is defined with respect to the First Point of Aries, which for KSP, is an arbitrarily chosen point in the skybox.
 
How the oval is oriented with respect to the plane of the orbit is defined by the longitude of periapsis (in the save file) or argument of periapsis (if using Hyperedit). Longitude of periapsis is where your periapsis is with respect to the First Point of Aries, while argument of periapsis is the angle from the ascending node to periapsis.
If you're wondering what that means: you could imagine an orbit where periapsis is close to the equator, close to the poles, etc: this is what LPE/AOP represent.
 
These five define the track of the orbit... but not where a vessel is in that orbit. That is usually defined with two parameters: epoch (an arbitrary point in time), and mean anomaly at epoch. Mean anomaly is related to the angle between periapsis and your current point in the orbit, and mean anomaly at epoch is "what was the value of mean anomaly at that arbitrary point in time".
Incidentally, the exact angle between periapsis and your current point in the orbit is true anomaly, and is exactly equal to mean anomaly for a circular orbit, but is more complicated to deal with for elliptical orbits.

Use the staging button to fire off one of the stack separators? If neither staging a separator nor running a test completes the contract, and you have the correct part in the correct situation, then you have a bug, and I'd just use the alt-F12 debug menu to complete it.

It completely depends on which direction you enter and exit the SOI. That is the whole point of gravity assists: you have the same Eve-relative velocity going in and out, just in different directions.
When you enter Eve SOI, your Sun-relative velocity vector is Eve's velocity vector, plus your Eve-relative velocity vector. When you exit, your Sun-relative velocity vector is Eve's velocity vector, plus a new Eve-relative velocity vector of the same magnitude but different direction.
So, if you're using Eve to brake into Moho, what you want to do:
Enter Eve's SOI from behind Eve, go around the front side, and go back out from behind Eve.
Let's say you have an Eve-relative velocity of 2 km/sec, and the gravity assist does a perfect U-turn. Eve orbits at roughly 11 km/sec.
So, before the intercept, you have 13 km/sec of velocity relative to the Sun. After Eve turns you around, you now have 9 km/sec of velocity relative to the Sun.
In practice, you're not going to get perfect U-turns, but the theory remains the same: speedy thing goes in, speedy thing comes out, but in a different direction.

What other mods do you have going? Usually, RSS players have some of these mods.
Ferram Aerospace Research: Makes aerodynamics more realistic, and in particular gives reentry vehicles more drag.
MechJeb or Kerbal Engineer Redux to help design vehicles
Procedural Parts and Procedural Fairings: helps make very large, very small, and oddly shaped parts.
One of these three:
SMURFF: Brings stock propellant tanks and engines more in line with reality, but without all the complexity of Real Fuels
Realism Overhaul: Includes Real Fuels and a wide variety of real-world engines, along with a truckload of other tweaks
Real Fuels-Stockalike: Brings stock parts into line with reality, using Real Fuels, and all the complexity that comes with (ullage, cryogenic boiloff, etc).
The reason for the last three is simple. Because Kerbin is so much smaller than reality, Squad balanced things by making fuel tanks extremely heavy (9:1 full:empty, versus real-world tanks that can exceed 30:1), and by making engines very heavy relative to their thrust output. They also pegged engine specific impulse at approximately the level of the common hypergolic propellants (hydrazine/MMH/UDMH as fuel, NTO as oxidizer), whereas you can get slightly better performance with cryogenics like kerosene-oxygen, and much better performance with hydrogen-oxygen.
All three of these correct these much closer to real-world values, which helps partially with getting to orbit. In particular, you'll generally find real-fuels stages will often have more delta-V and burn longer, because with lighter-weight tanks and engines, there's less incentive to stage off fuel tanks and engines. Also because the delta-V requirements are so much greater, but that's what you're trying to address.

Aim for a very low periapsis, as low as you can get it without smacking into terrain.
This conclusion comes from two things: the Oberth effect, and conservation of orbital energy. The Oberth effect says "the faster you're going, the more energy you gain or lose by accelerating", and conservation of orbital energy says "unless you make a maneuver, the sum of your kinetic energy and gravitational potential energy is constant".
The energy of a nice circular orbit around Minmus is much less than the energy of the capture, where by definition you have at least enough energy to escape Minmus orbit. So, you want to shed that energy.
Where's the best place to do that? At periapsis, where Minmus's gravity has accelerated you to the greatest extent possible, so your velocity at the capture burn is maximal, so you can shed more kinetic energy per m/sec of delta-V.
Where's the best place to have your periapsis? Scarily low, where Minmus's gravity will have accelerated you as much as it can without experiencing a lithobreaking event.
 
The length of the burn should simultaneously be very short (Oberth effect) and very long (engine mass is dead mass for the Tsiolkovsky rocket equation). It's a complicated optimization problem; I took a stab at the landing part of it a while ago and I think my conclusion was that the optimum was to have enough engine for about 2-2.5 m/sec^2 of acceleration (4-5 TWR for Minmus, ~0.2-0.25 TWR on Kerbin).
 
Landing should begin at as low of an altitude as you dare, managing vertical velocity to avoid a RUD event while shedding as much horizontal velocity as quickly as possible. Again, the Oberth effect comes into play here, and is a balance against adding too much dead-weight in the form of rocket engines. The ideal rocket, after all, is a giant, infinitesimally lightweight balloon full of propellant being fed through an infinitesimally lightweight (but still high specific-impulse, can't forget that) rocket engine*.
*And if you want to go real-world about it, that engine has an infinitely long de Laval nozzle... that again is infinitesimally lightweight.

Well, take a look at the moment of capture into the Mun's SOI.
You know the Mun's velocity vector, and can make a good estimate of your vessel's velocity vector: approximately parallel to the Mun's trajectory, at your apoapsis velocity.
Thus, your Mun capture velocity is approximately the Mun's velocity, minus your transfer orbit's apoapsis velocity. In practice, it's probably going to be a bit more, because you're probably not going to be at exact apoapsis and you're probably not going to be exactly parallel to the Mun's orbit at the moment of capture.
Thus, you now have a Mun-relative V, and you already know G*m for the Mun, and your altitude is the Mun's SOI (be sure you're using SOI radius from the exact center of the Mun, not from the Mun's surface).
 
An example, assuming you started from 100 km periapsis of Kerbin, and will capture 20 km above the Mun:
Note that the vis-viva equation simplifies to V^2 = mu/a when you are in a circular orbit (r == a)
 
Vpark = sqrt(mu(Kerbin) / rpark) = 2246.139 m/sec at parking orbit
Next, your transfer orbit apoapsis will be about at the Mun's SMA of 12,000,000m, so your transfer SMA will be 0.5*(700,000 + 12,000,000), or 6,350,000m.
Vtrans = sqrt(mu(Kerbin) * ((2/rpark) - (1/atrans))) = 3,087.738 m/sec
So, your Mun injection burn requires (3087-2246) = 841.6 m/sec
 
Next up is calculating your Mun-relative velocity at capture.
Vapokerbin = sqrt(mu(Kerbin) * ((2/apo) - (1/atrans))) = 180.1 m/sec
We know the Mun's orbital velocity, 542.5 m/sec. So, at capture, your Mun-relative velocity will be approximately 362.4 m/sec.
 
We can now plug this in to determine our Mun-capture SMA using the Mun's SOI radius as our altitude.
V(mun)^2 = mu(Mun) * ((2/SOI) - (1/a))
Rearrange, and you get a = 1 / ( (2/SOI) - (V^2/mu(Mun)))
We now have a semi-major axis of -838387 meters. Yes, I know a negative SMA seems nonsensical, but it's how SMA works for hyperbolic orbits.
 
We can then plug that in to determine our velocity at peri-Mun of 220000 meters
Vperi = sqrt(mu(Mun) * (2/220000 - 1/a)) = 818.45 m/sec
 
We can then calculate the velocity of our destination, circular 20 km (220 km from the center) orbit
Vdest = sqrt(mu(Mun)/220000) = 544.14 m/sec
 
From that, we know the delta-V of our insertion burn: 818.45 - 544.14 m/sec = 274.315 m/sec

One possibility: some gaming laptops have a button to force the computer to use the integrated graphics rather than the dedicated graphics chip; make sure that's toggled correctly. Do you have similar problems with other games, or is it just KSP?
Potentially, you might try reinstalling KSP; the other possibility is that you're trying to control a 1000-part monster vessel, which will lag any computer.
The other possibility that springs to mind is that your computer isn't being cooled very well; at the least prop the back up to get airflow, and there are dedicated cooling pads.