Zhetaan

TAC Fuel Balancer
The mod thread does say that it is available on CKAN and updated for KSP v1.12, so you should not have any trouble there.  I did look through the history to see whether, in the chain of people who have maintained it, anyone changed the name from 'TAC Fuel Transfer' to 'TAC Fuel Balancer', but didn't find it.  The mod does transfer fuel, so I think it's just a case where someone got the name wrong and the wrong name caught on.
I'm not certain that it does precisely what you want it to do, but at least now you can try it and find out.

@HebaruSan is correct, so I'll give a bit more context and explanation.
You can't stop it.  This is an emergent property that arises because you're in a rotating frame of reference.  Because your orbit is a curve, the direction of forward motion (what you and I know as prograde) changes with respect to any absolute frame of reference.  Anything that moves to intercept is necessarily on a different curve, and so the different directions of prograde will result in relative drift.  This is true even if you match orbits perfectly first, because moving to intercept necessarily changes the shape of your orbit.  This is also the reason that all of the counter-intuitive manoeuvring (i.e., decrease altitude to increase speed, and so forth) works in orbital mechanics:  you have to account for the rotating frame of reference.  That's true on the surface, as well, but we can usually approximate things with straight lines and flat surfaces (though there are notable exceptions in navigation:  following a great-circle course, with a few edge case exceptions, means constantly changing your heading).
This rotation affects everything in any combination of prograde and radial directions.  You may note, for example, that radial in at the periapsis points in the opposite direction of radial in at the apoapsis.  Over the course of the orbit, the compass rose of prograde, retrograde, radial in, and radial out rotates around one time.  This rotation is parallel to the axis of the orbit and perpendicular to the plane of rotation, i.e., about the normal direction.  What this means is that normal does not change over the course of the orbit, and you can use this to your advantage when docking.
Provided that you do not change inclination much, you can approach from normal or anti-normal and get a dock without the target vessel rotating away from you.  This only works for small relative inclination differences because matching orbits in every way but inclination means setting yourself up for a collision later--either controlled docking, or the more explosive version.  Other alternatives include docking in a high orbit (with its slow rotation) or simply docking quickly (this could mean rendezvousing, matching at a close distance, and waiting for a potion of the orbit for the target to point the docking face that you want towards you).

Well, don't apologise for asking questions.  That is the literal point of this forum, and besides, if you ask certain questions frequently enough then we can put it in a special place for questions that people ask frequently.  We can call it 'Things People Ask About a Lot', or the TPAAL--something catchy like that.
Anyway:
For the Clamp-O-Tron Jr., you get two such to mate by having the shiny rings touch.  This means that, assuming that you're going for an Apollo-style configuration, you will want the assembled Command-Service Module to have the shiny ring pointed up (assuming that the main engine is pointed down and for the Lunar (Munar?) Excursion Module's shiny ring to point down onto that of the CSM.
However, I do feel compelled to point out that if you want authenticity, then you should have the LEM (MEM?) in a fairing under the CSM, which is at the tip of the rocket.  Then, once you've achieved trans-Munar injection, you blow the fairing, release the CSM, and then turn around to dock with and extract the lander.
For the other docking ports, the one that routinely gives people trouble is the Clamp-O-Tron Sr.  The general rule is that you want to see a short slot on the docking face, and no plus sign.  That's the mating face.  Have a look at the part in the VAB (start a sandbox save or look at the wiki) and you'll see what I mean.

I disagree with it being cheaty; if you're expanding the tech tree, then you need to expand the science pool, and that means re-balancing everything that goes into it.  You may not be modelling the change in technological capability in your game, but it's not unreasonable to think that data storage and transmission can improve immensely in twenty years:  twenty years ago, some digital cameras recorded images on floppy disks inserted into the camera, and streaming video was ... well, no, it wasn't.
That's a big part of it.  The RA-2 is literally the worst-transmitting antenna in the stock game.  Switch to a Communotron 88-88 or HG-55 (the HG-55, not the HG-5).
I don't think you can warp through transmission, but you can definitely make transmissions work better.  Since you're comfortable with modding and writing patches, let me give you the essential idea behind data transmission, so that you'll then be able to decide whether to use a better stock antenna or else go in another direction.
Science is transmitted in units called mits.  It's like a bit, but mumbled.  Individual experiments have fixed mit values.  This is not automatically related to the science value of the experiment--that depends on whether you're recovered the experiment before, where you did the experiment, and so forth.  For example, a temperature reading always has a value of 8 mits, but the science value changes if you take the reading in low orbit of Jool instead of Kerbin.
Mobile Processing labs factor the science multipliers into the conversion to data, which is a trade-off:  you transmit science from the lab at a transmission rate of one mit per science point, so you need more and longer transmissions for the same mit value of experiments as you collect them from higher-yield situations.  Of course, the lab multiplies the data value, too, so it's a net positive, but you knew that already, I think.
Antennas gather mits into bundles called packets, and different antennas have different packet sizes.  The HG-55 has a packet size of 3 mits, the RA-2 has a packet size of 1 mit, and all other stock antennas have a packet size of 2 mits.
Antennas also have a packet interval, which is the time taken per packet transmission.  The reciprocal of this value is the number of packets per second, and taken with the packet size gives the transmission rate in terms of mits per second, or, if transmitting from a lab, science points per second.  The HG-55 has an interval of .15 seconds with a packet size of 3, and the Communotron 88-88 has an interval of .10 seconds with a packet size of 2.  This means that they both transmit science from a lab at a rate of 20 science per second.
Lastly, antennas have packet resource cost, which is simply the EC used per packet.  I get the impression that you don't have an electrical scarcity problem and are more interested in speed, but for your information, the HG-55 has a relatively low EC cost per mit but its high transmission rate means a high EC cost per second.  The 88-88 is the worst in terms of electric use per second (but the RA-2 is the worst in terms of EC per mit).
Anyway, if you're transmitting something of roughly 5,000 science points per transmission (though probably less given diminishing returns), then doing it through an RA-2 will take about half an hour.  Using an HG-55 will do the same thing in four minutes and ten seconds, though at roughly double the electricity per second (but at one quarter the total electrical consumption).
If you should decide to mod an antenna, then you will want to increase the packet size, decrease the packet interval, or do both in order to reduce the transmission time.

Atmospheric attenuation.  Here's a link to a relevant post.  It's six years old but still accurate.
The Gigantor solar panels are rated for 24.4 ec/s  at Kerbin's orbit, as in at Kerbin's distance from the sun, absent any intervening obstacles.  Intervening obstacles can include the Mun during eclipses, Kerbin itself (Kerbin tends to shade the panels a bit at night), and atmosphere.  Because of this, the surfaces of the inner planets are actually some of the worst places in the solar system to use solar panels:  solar panels at Eve sea level (with 5 atm of pressure) tend to be about two-thirds as efficient as panels at Kerbin orbit, and Moho's 61-day night (owing to its crazily-long rotation period with respect to its orbit about the sun) is something of an issue, as well.  High temperatures affect panel efficiency, too.
In the linked post, testing showed that near Kerbin sea level, Gigantors produce something in the neighbourhood of 21.5 ec/s at noon and get worse from there.  Near sunrise and sunset, they make less than 1.5 ec/s.  I don't know the decay curve, but there's no way that the average output is more than 90 ec/s over the course of the day.
Another possibility is how many converters you are running on your converters.  By that I mean to say that the Convert-O-Tron 250 has four converters on it:  Monopropellant, LF, Ox, and LF+Ox.  Each of those converters is a separate process, and so each will pull 30 ec/s to run.  (They will also overheat the part if you try to run more than two, I think).
Many players use fuel cell arrays rather than solar for their conversion processes, since the cells consume less than the converters produce, still generate respectable power, work at night, and don't break off in atmosphere.  It chafes at my understanding of thermodynamics, but it's a valid gameplay strategy.

Yes, yes it is.
Near space over the sun is far enough away, in relative terms, that a typical Hohmann transfer orbit is no longer the most efficient way to do it, and you're better off using a bi-elliptic transfer, instead.  That's similar to what you've been doing, but your problem right now is that you're burning at an apoapsis that is far too close to the sun to be efficient.   You'll want to boost all the way out to Eeloo at the least.  Farther is better and, counterintuitively, more efficient, but don't go so far as an escape orbit.  You'll need to keep in mind the contract deadline, too.  Once you're at your supra-Eeloo apoapsis, burn retrograde to bring your periapsis down from Kerbin to the sun as you have been.  This has the additional advantage of making your periapsis transit faster, so perhaps you won't burn to death (or at least get by only slightly crispy about the edges).  Remember that you're not near the sun for the purposes of science experiments until you're under one million metres in altitude, so I hope you brought thermal protection.
Thankfully, you can take the measurements while flying by--you don't need to circularise.
The other things that you can do are all the standard advice about designing your vessel properly for the mission, so picking the right engine (for a 500-tonne vessel, it won't be ion engines or Nervs), taking only what you need and nothing else, setting up clever staging, and so forth.
 
On an unrelated note, welcome to the forum!  As newer players go, you're certainly ambitious, but that's not a bad thing.  Good luck, and if you have any other questions, then please feel free to ask.

There are two little tricks that you need to know before you start calculating.  The first is that orbital period is dependent on the semi-major axis, not the eccentricity.
This should make sense if you think about it:  let's say that you're orbiting the Mun at 100 km at any arbitrary eccentricity.  Where is the 100 km point on that orbit?  Is it the apoapsis?  Is it the periapsis?  Is it somewhere in between?  Any orbit that has a periapsis at or below 100 km and an apoapsis at or above 100 km will pass through the 100 km altitude at least once, but without knowing more about how that orbit is arranged, the altitude and eccentricity do not help.
That being said, it is true that the eccentricity is derivable from the same information that gives you the semi-major axis in KSP:  the apoapsis and the periapsis.
This leads to the second little trick:  the altitude given in KSP is measured from the surface of the celestial body, and in order to get accurate information, you need to account for the body's radius.  This information is found in the Tracking Center.  It's in the Knowledge Base button that tells the planetary characteristics, (it's the one that looks like a planet with a ring around it; it should be between the one with an i and the one that looks like a planet with a wedge carved out of it) and it's the Eq. Radius parameter that should be at the top of the list that opens when you click on it.
... Or, I suppose, you can find the information on the wiki.
 
Anyway, on to translating the Wikipedia article:
Wikipedia shows you two ways to calculate what you want.  The first is the calculation of orbital period from the semi-major axis, and the second is calculation of the semi-major axis from the orbital period.
I will reproduce the formula here to assist with the explanation:
T = 2π √(a3 / μ)
Where:
T = the orbital period (in seconds),
π = the mathematical constant, approximately equal to 3.14159265 (I generally prefer to carry precision out farther than it will ever be necessary and round off later),
a = the semi-major axis (in metres), and
μ = the Standard Gravitational Parameter, a value which depends on the celestial body.  It is equivalent to the universal gravitational constant, G,  multiplied by the body's mass, M, and so some depictions of the formula will show GM instead of μ.  The symbol is the Greek letter μ pronounced roughly as 'myoo'.  The value of this number is also available in the Tracking Center, in the same place as the equatorial radius.  It's listed as GM and is a couple of lines down from the radius.  For the Mun, it is equal to 6.514 x 1010 m3/s2 according to the Knowledge Base button, but the more accurate value is 6.5138398 x 1010 m3/s2.
Let's start with a circular Mun orbit of 100 km.  That would be, therefore, 100,000 metres.  (Metric prefix notation is nice, but this is astronomy.  Confine yourself to base units and use scientific notation when you need it; it's less confusing that way and you'll be less prone to make mistakes.)
Any orbit of the Mun will need to add 200 km to its altitude to get its true gravitational distance; this means that your circular orbit will actually have a radial distance of 300,000 metres.  Since the orbit is circular, the radius is equivalent to the semi-major axis (had it not been circular, then you'd need to average the apoapsis and periapsis distances), so that's the value we want.
Therefore:
T = 2π √([300,000]3 / [6.5138398 x 1010])
T = 2π √(2.7 x 1016 / 6.5138398 x 1010)
T = 2π √(4.145020576 x 105)
T = 2π * 643.8183
T = 4045.23 seconds
(optional conversion)
T = 4045.23 seconds * (1 minute / 60 seconds)
T = 67.42 minutes
The second formula in the Wikipedia article is the same as the first, but algebraically manipulated to find the semi-major axis variable when all other information is given.  It's popular for finding the synchronous altitude (using Kerbin's data to verify the stationary orbit is an exercise I leave to you), but you want a three-hour orbit of the Mun, so let's work on that.
Here's the formula:
a = 3√(μT2 / 4π2)
The symbols mean the same as in the previous formula.  I direct your attention to two things to note:  first, the 3√ means cube root, and sometimes you'll see the cube root of some x-value, 3√x, represented instead as x(1/3).  The two notations are equivalent.  Second, note that I condensed the GM given in the wiki to the μ of the first formula.  This was only for consistency.
The only preparatory work needed here is to convert three hours to seconds.  That's easy enough:
T = 3 hours * (60 minutes / 1 hour) * (60 seconds / 1 minute) = 10,800 seconds
Now we need to put everything into the formula.  The rest of the parameters we know from above, so I will save some time and copy mercilessly:
a = 3√([6.5138398 x 1010] * [10,800]2 / 4π2)
a = 3√([6.5138398 x 1010] * [1.164 x 108] / 4π2)
a = 3√([7.5978106 x 1018] / 4π2)
a = 3√(1.9245479 x 1017)
a = 577,534.97 m
This is the answer, but we are not finished.  We need to subtract off the 200,000 m of the Mun's radius.  By the same assumptions as before, the semi-major axis of a circular orbit is equivalent to the orbital radius:
Altitude = 577,534.97 - 200,000 = 377,534.97 m
Put a vessel at that altitude and you'll have your three-hour orbit.  You can round up to 377,535 m, if you like.

That orbit does not have a Mun encounter, so you won't get a Munar orbit without a burn while still in Kerbin orbit.
You did have a close approach (the close approach markers are directly below your vessel and directly to the right of the Mun), but from that screenshot, you have just passed that point of closest approach.
On a side note, your apoapsis is very high.  This means that, even were you to get an encounter, it would not be ideal.  This is for several reasons.  First, you're expending propellant to send your vessel to a too-high apoapsis and getting no benefit from that, so it's wasted propellant.  Second, you'll need to burn to undo that velocity addition when you do get a Mun encounter, so it's actually double wasted propellant.  Third, that kind of right-angle cross of the Mun's orbit will put you at a manoeuvring disadvantage when you get into the Mun's sphere.  You'll end up with a lot of radial velocity and that's not often a good thing.  The ideal low-cost transfer approach is along a tangent to the target body's orbit.  This means that you want your vessel's apoapsis to barely touch the Mun's orbit.
Burn retrograde at Kerbin's periapsis to bring down the apoapsis.  However, don't burn all the way to make a circular orbit.  You've got an orbit that reaches Mun orbit, so we can work with that and not waste too much propellant.  Instead, burn to bring down the apoapsis to near the Mun's orbit, and as you get it closer to the Mun's orbit, an encounter should appear.  Then you just need to wait.

The impact tolerance won't be an issue unless you try to land on it or decide to play bumper ships in orbit.  Generally, you want to land with less than 6.0 m/s anyway.
The ejection force isn't a problem; it's not a terribly useful form of propulsion, so the force that you need is only that which pushes the separated stages apart in a reasonable amount of time.
One thing to note about the new versus the old decouplers is that the new ones have names with systematic relationships to their size.  The TD-12 is the 1.25 metre decoupler.  The TD-06 is the 0.625 metre decoupler.  Similarly, the TD-25 and TD-37 are the 2.50 metre and 3.75 metre decouplers.  The old decouplers usually had random numbers or no numbers at all (the 2.5 metre decoupler used to be called the Rockomax Brand Decoupler, which told you nothing about its size unless you knew ahead of time that Rockomax parts tended to be 2.5 metres).  This is still the case with the radial decouplers:  the 38 in TT-38K means nothing that I can determine, and Hydraulic Detachment Manifold is practically technobabble.

It should, but keep in mind that the rate of science production is a fairly complicated mathematical process; it operates on a logarithmic decay model and so reducing this multiplier by a factor of five may only reduce the initial rate by that much.  It may be a linear multiplier applied to the output of the logarithmic decay, or it may work out that later research when the initial store of data points is depleted may be slowed by significantly more--possibly by enough to create an effective standstill even with a large amount of data still in the lab.  To get the effect you want, I'd suggest changing the scienceMultiplier value to 1, instead, to reduce the total science conversion.
Change it to 0.   If the game throws an error for that, then change it to .001 as you see in the atmospheric thrust curves for engines' cutoff pressure.
I have not tried it, but I assume so.  Without knowing the equation that governs the time calculation, I can't tell you what changing it would do aside from what it says on the tin.
I'd personally suggest reducing the science conversion and eliminating the scientist bonus before changing the processing rate.  Changing too many factors at once may nerf the lab to the point of uselessness, in which case I'd say to just comment out ModuleScienceConverter and play without that function.

On the one hand, there are a few missions that require more experience.  On the other hand, doing them is how you acquire experience.  On the gripping hand, frustrating yourself unnecessarily makes things less fun.
Along with @18Watt, I agree that Moho is probably a bad choice if you are, as your post title suggests, a 'low-skill player'.  Putting aside the issues of simply getting to Moho in the first place, landed equipment on Moho generally needs alternative power arrangements and such because of the length of night.
Vall and Laythe are both good choices and have different requirements.  Laythe's main attraction is the fact that it has an oxygen atmosphere, but if you're not interested (or simply not yet ready) to try flying interplanetary aeroplanes, then remember that Laythe is still interesting for those who insist on visiting it with normal rockets.  Vall is more challenging than the Mun and also has some interesting features.
Don't forget that you can challenge yourself in a different way by taking a multiple-lander to try both of them--you don't need to go from nothing to a full Jool-5.  In fact, Jool-2 and Jool-3 missions (either Vall/Laythe/Pol for the ease of getting there, or Vall/Bop/Pol for the similarity of environment) are great ways to train for more complicated missions such as grand tours.
There are other things to do, too, that may interest you.  Asteroid capture and mining is a completely different game, and Dres is worth a look, as well.  Dres suffers from the fact that it is far away from everything and lacks a collection of moons like Jool's, but it's still worth the trip.
Have fun!

That seems to me to be an asymmetric thrust problem.  You'll need to turn on the centre of thrust indicator in the VAB and ensure that the line coming out of it points through the centre of mass.  It's a bit tricky to do since the line doesn't come out of the front of the marker, but you can do it by rotating the view of the vessel while in the VAB.
Before you get that far, be certain to remove any boosters that will be expended before you light the OMS engines; you don't want to include engines that will be staged away by the time that the OMS fires because they and their tanks will throw off your centres of thrust and mass in the VAB, which would lead you to optimise for the wrong configuration.
Once you do that, you'll need to rotate the OMS engines to align the thrust with the centre of mass.  When I do it, I try to get my view behind the centre of thrust and rotate my view so that the centre of mass disappears behind it, and then rotate engines to align the thrust vector, too.  This is much easier to do if you first rotate the whole rocket to be on its side or even switch to the SPH for this portion; thrust and mass don't care about the direction of gravity.
Next, you'll need to drain the propellant tanks and see whether the centre of mass shifts appreciably.  If you're using something like an SSME (that's a Space Shuttle Main Engine, which is the engine that used the propellant from the big orange tank on the real Shuttle) instead of, or in addition to, an OMS system, then you'll probably need to move the orange tank (or equivalently-coloured tank) up on the shuttle's belly so that its centre of mass is on the same line as the thrust.  That way, the centre of mass as the tank drains only moves closer to the engines along that thrust line, and you either eliminate or significantly reduce the asymmetric thrust.
Note that if you have wings or other engines, then the thrust of the shuttle may not point precisely where the OMS engines do.  Also, as you go into vacuum or change engine configurations, the powered flight performance of the shuttle will change as well.  There's no good overall solution for that, but you can still optimise the engines' alignment for where you intend to most use them:  for example, don't take lift into account at all if you intend to use the OMS engines only in orbit or the upper atmosphere.
I hope that helps, and if it doesn't, then please do let me know (and provide more details so we can help you more).

Gilly's surface gravity is .049 m/s2.  The Nerv has a thrust of 60,000 N.  This would mean that a Nerv can, at least theoretically, land a craft of anything up to 1,224.5 tonnes, though for a safety margin it's probably best to limit the weight to 90-95% of the thrust.  It'll still take a long time (a Nerv pushing that mass will have the same acceleration as Gilly's gravity, so 5 cm/s2), but you're underrating the Nerv by a factor of about four.

Gilly's surface gravity is .049 m/s2.  The Nerv has a thrust of 60,000 N.  This would mean that a Nerv can, at least theoretically, land a craft of anything up to 1,224.5 tonnes, though for a safety margin it's probably best to limit the weight to 90-95% of the thrust.  It'll still take a long time (a Nerv pushing that mass will have the same acceleration as Gilly's gravity, so 5 cm/s2), but you're underrating the Nerv by a factor of about four.

Let's go through it step by step.  There are certain assumptions and simplifications that we can (and should!) apply to this problem, but the overall result will still be close enough to correct.  First, however, since your issue is more about your assumed expectations, let's look at the problem more abstractly and see what insights we get from it to correct your intuition.
For one thing, your orbit radius is a bit over twice Minmus's radius (remember that an altitude of 70,000 metres is actually 130,000 metres from Minmus's centre).  In terms of the abstraction, let's call it exactly twice and work from that.
If Minmus is at half of the orbital radius, what then?  If we assume that the orbit is a unit circle, that the sun shines from the left side of the graph, and that Minmus's shadow is a cylinder (projected to be a rectangle--the point is that it does not taper), then Minmus's bulk will cover the right side of the orbit to half of the orbit's maximum height above the x-axis.  Thus, we want the angle that leads to a point y = .5 on the unit circle.   We can solve that with trigonometry:  arcsin (.5 / 1) = 30°.  Of course, Minmus covers a portion of the shadow below the x-axis, too, so we need to double the angle.  The total included angle is therefore 60°.
We can get that value another way, courtesy of our abstraction:  if the orbit is twice Minmus's radius, then the size of the shadow, which itself is twice Minmus's radius, will equal the orbit radius.  Since the distance from the origin to the edge of the shaded part of the orbit is going to be one orbit radius for both the upper and lower edges of the shadow, it altogether makes an equilateral triangle, so the included angle is definitely 60°.  Since your actual orbit is slightly larger than double Minmus's radius, we can safely expect that the true included angle will be near to but less than this value.
In terms of the fractional coverage of the larger orbit, 60° is one sixth of the total orbit, and of course the total is the full circle at 360°.  If you expect a darkness time of 30 - 45 minutes, then you expect an orbital period of 180 - 270 minutes, or 3 to 4.5 hours (actually slightly more).  If you find your orbital period in KSP, you'll see right away that that does not make sense.  The reasons why are less intuitive, but it's simple enough to check.
Orbital period is better to use, but your orbital speed is the first parameter that KSP displays, so let's work with that, instead.  I'll show the calculation later, but for now let's assume that it is at or very near to 116.5 m/s.  The circumference of a 130,000-metre circular orbit is 816,814 metres, so going around that orbit at that rate gives a period of 116.85 minutes.  Thirty minutes of darkness is a little more than one quarter of that orbit.  Forty-five minutes is closer to forty percent--and that should immediately feel absurd, because fifty percent coverage is what you get at the surface.  Forty percent coverage requires you to be so close to surface altitude that to achieve it should have you crashing into the mountaintops.  One sixth of the orbit gives about 19.5 minutes, but again, we've already shown that the actual value will be somewhat less than that.
 
Now to the more precise calculations:
Minmus has a standard gravitational parameter, μ, of 1.7658 x 109 m3/s2 and a radius, r, of 60,000 metres.  A circular orbit at 70,000 m altitude has a semimajor axis, a, of 130,000 metres, which is equal to the orbital radius at all points on the orbit.  This orbit thus has an orbital speed, v, of:
v = √(μ / a)
v = √(1.7658 x 109 / 130000)
v = √(13583.1)
v = 116.5 m/s
Minmus's shadow cone technically ought to vary in length over the course of its orbit about Kerbin.  Since neither Minmus's orbit nor Kerbin's have any eccentricity, the constraints on the variation, and thus also the variation in taper angle, should be relatively easy to determine.  However, for one thing, this orbit is close enough to Minmus that approximating Minmus's shadow as a cylinder with no taper will work more than adequately (it will slightly overestimate the darkness time, but not by a lot), and for another thing, I don't know how faithful KSP is to the realities of physics in this case.  I would like to assume that it is accurate but I have neither tested it nor seen anyone else do so.
Under these assumptions, the included angle of the shadowed arc of the orbit, θ, is given by twice the arcsine of the body radius, r, divided by the orbital radius, R:
θ = 2 * arcsin (r / R)
θ = 2 * arcsin (60000 / 130000)
θ = 2 * .479729 rad
θ = .95946 rad or 54.97°
The arc length of the shadowed portion of the orbit, l, is given by the included angle multiplied by the orbital radius:
l = R * θ
l = 130000 * .95946
l = 124,729.4 m
At the previously-calculated (constant) rate of speed, your vessel will cover this length in time t:
t = l / v
t = 124729.4 / 116.5
t = 1070.6 seconds
t = 17.84 minutes
Your calculations are correct.

You can accomplish rotation in a couple of ways when in free fall in space.  The first is to use RCS and monopropellant.  The second is to use reaction wheels.  Reaction wheels require electric charge, but your command pod normally has a small battery (it usually has reaction wheels, too; the dedicated parts are for larger rockets).
The reason that you're seeing what you did was possibly because the battery is massive enough to require more power than you were producing to turn the rocket, but before you added it, the demand was less than the supply.  Try adding another power generator, such as a solar panel.

I'll admit to a bit of confusion about what you're asking, but I'll try my best:
If you mean previous versions of KSP, you have to have downloaded it.  Usually, SQUAD makes the most recent previous version available at the KSP store; if you're on Steam, you need to find the previous version and move it out of the Steam directory before Steam updates it.  However, current saves are usually not backwards-compatible.

If you mean previous versions of a mod, then the mod-makers usually have older, archived versions at the same place that they offer the current version for download.  It's much easier to get older versions of mods than it is to get older versions of KSP.  However, again, older versions of mods may not work with the current version of KSP and they may be save-breaking in the event that you are currently using the updated version.

If you mean going to previous saves, then you need to have an older save.  The game backs up your last few autosaves (you can find the backup directory in your save directory, wherever you have KSP installed).  Loading the older save has the effect of going back in time, and saving it will overwrite your newer progress.
  You need both a planet pack and a mod that can process planet packs.  The current standard for processor mods is Kopernicus; as for planet packs, you have your choice.  Note that Kopernicus tends to lag a version behind the current release of KSP, so if you want to use it, then you'll need to get the most recent previous version of KSP to go with it.  If none of the available planet packs pique your interest, then you may try your hand at making your own.

So far, the most popular planet packs include Outer Planets Mod, which is exactly what it says; Real Solar System, which again is exactly what it says it is; Galileo's Planet Pack, which completely reconfigures the solar system (and not just in the sense of moving the planets to new orbits; it replaces the stock solar system with a totally different one), and a few others, such as rescale mods (they change the size of the solar system to be closer to what it would be in reality, but without going so far as to replace it with the actual Real Solar System--although there is a Toy Scale mod that actually makes things smaller).

Removal consists of removing the planet pack, but I'll caution you against doing so--if you add a planet pack, then you should probably keep it for the duration of the save.  If you put anything on or in orbit of a mod planet or moon, then removal of that body will cause problems.  Any remaining hardware or Kerbals left there will suddenly consider themselves to be in orbit of something that no longer exists, and I honestly don't know what will happen to experience logs, the science archive, or the contract system for anyone or anything back at Kerbin if they begin looking for references to planets that simply disappeared.  Adding planet packs to an existing save can cause similar havoc (celestial bodies are given numeric identifiers, and when a rocket in low orbit of the Mun suddenly finds itself orbiting inside a rescaled Mun, or in the atmosphere of a completely new planet that reuses the number, hilarity does not usually ensue), with the exception that planet packs that solely add new planets and do not change existing ones are sometimes safe (Outer Planets Mod is mostly designed this way; I don't know what happens should you install it while you have anything at Eeloo, though).
  Yes.  Some mods are not compatible with other mods; this is because they try to change the same aspects of the game in ways that conflict.  A lot of mods are dependent on specific versions of the game; the mod makers do try to keep up with the new releases, but it takes time.  Planet packs and Kopernicus are especially dependent; it turns out that the solar system is a core part of the game and thus things that modify it are often specific to that individual release.  Some mods have bugs that may very well interfere with what you want to do (this is usually the result of a previously-unconsidered edge case or a previously-undiscovered incompatibility; sometimes, it can be addressed, and sometimes not).  Mods are not necessarily optimised completely, and so they may induce lag and slow down the game.  Mods that add a lot of processing or new physics can do this to the point of making the game unplayable, especially if you have a lot of memory-dependent mods installed at the same time.  Mods that change the play style can derail a game in progress (for a simple example, imagine that you were to add a life support mod to a game that has a crewed vessel out near Jool; doing so will probably sentence that crew to die). I'm certain that there are other things to consider, and I'm equally certain that others will arrive shortly to add those parts.  For now, this is a good beginning.

That depends on your order of visitation, vessel design, preferred return profile, and use of assists, among other things, but you can definitely do it with 17 km/s.  I tend to completely overdo my delta-V budget because I'm usually looking to do other things, such as establish stations and bases, so I don't have a good number for you.  Still, here's a link to a slightly outdated Jool-system delta-V map for your perusal and to aid with planning.  The only inaccuracy I know of is that the Laythe entry data is wrong because this was made with the old aerodynamics model.  However, that also means that it overestimates the needed delta-V by quite a lot (about 500 m/s if I recall correctly), so it shouldn't be a problem.
Also, here's the current Jool-5 challenge thread.  That may help, too.

No.
RTGs reach their thermal equilibrium at, apparently, 350 kelvin of core temperature.  That's the temperature of an unbearably hot room but it isn't enough to boil water, let alone damage your vessel.

Respectfully, I disagree with the others; a Nerv-powered lander can work just fine, but you have to take into account its particular issues.  Mass is part of it.  Heat is another.  The length of the engine is yet another.  But you also need to load it with the correct fuel.
 
My apologies to those who commented before if I repeat anything, but in the interest of gathering these ideas into one place:
 
First, Isp is a measure of efficiency, as others (@bewing) have said.  It is not the only way, and it is not the most intuitive way.  The most intuitive way is exhaust velocity:  an engine that propels its exhaust at a higher velocity imparts more momentum to that exhaust (and, because of conservation of momentum, to the rocket, too) than an engine that propels its exhaust at a lower velocity.  The convenient thing about Isp and vexh is that they directly relate:  in other words, if you have two engines and one has double the Isp, then it also has double the vexh.
Please note that efficiency does not necessarily relate to thrust.  Because of the way engines are made, there's often a trade-off between thrust and efficiency, but this is not always necessarily so.  For example, the ion engine accelerates its exhaust to ludicrous speed which makes it extremely efficient, but it does so almost a molecule at a time, so its thrust is terrible.  A solid rocket booster, on the other hand, comparatively vomits its propellant onto the pad nearly all at once and thus achieves high thrust, but at such low velocity that the only real advantage is that SRBs are cheap.  On the gripping hand, Project Orion is both efficient and high-thrust; please never mind the fallout.
 
Second, you are correct that at the same thrust, the higher Isp of the Nerv gives a longer burn time for the same amount of fuel.  We can work that through the calculation and figure out how much fuel is involved:
We can consider that thrust from an engine is essentially constant regardless of the mass of the rocket (unlike delta-V).  The engine exhaust velocity is also constant, and that is directly related to Isp (thanks to @HebaruSan):  For the Terrier, it is 3383.29 m/s, and for the Nerv, it is 7845.32.
Thrust is a force, which traditionally is defined as mass times acceleration (that's effectively Newton's Second Law), but acceleration is velocity divided by time, which means that we can define thrust in terms of velocity and still get a valid answer.  Specifically, thrust, the force, is equal to velocity times the quantity of mass divided by time--which we can call mass flow rate.  In other words, thrust results from the engine exhaust velocity times the rate of fuel flow.  Tabulated, these give us the following values:
Thrust / vexh = Mflow
Terrier:  60000 N / 3383.29 m/s = 17.734 kg/s
Nerv:  60000 N / 7845.32 = 7.648 kg/s
Fuel flow rate times total burn time gives the total mass of fuel consumed:
Terrier:  17.734 kg/s * 113 s = 2 tonnes
Nerv:  7.648 kg/s * 118 s = .9 tonnes
The FL-T400 tank holds two tonnes of LFO, divided up as .9 tonnes fuel and 1.1 tonnes oxidiser.  In this case, using the same tank for your Nerv engine starved it of more than half of its potential fuel load.  I could use the rocket equation to see, given your delta-V values, whether you unloaded the oxidiser from the tank, but you really ought to have used Mk1 Liquid Fuel Fuselage tanks for a Nerv-powered lander.  It's the exact same tank but in a liquid-fuel-only variant; if you had used that, you would have had more than double the burn time and much more delta-V.
Specifically:
2 tonnes LF * 7.648 kg/s = 262 seconds, approximately
5.19 TWR / 60 kN = 11560 N weight
11560 N / 1.63 m/s2 Mun surface gravity = 7092 kg mass
(You didn't drain the Oxidiser!)
Assuming 2000 kg liquid fuel:
ln (7092 kg / 5092 kg) * 7845.32 m/s = 2599 m/s delta-V
We can call this approximately 2600 m/s of delta-V.  It's only 700 more than you'd get with the Terrier, so there's an argument to be made about adding another fuel tank rather than switching to a Nerv, but there's an equally valid argument for using the Nerv and keeping the lander relatively small.
 
Replace the FL-T400 with a Mk-1 fuel fuselage.  Used in this way, your lander will be perfectly serviceable.

@Actually_New_KSP_Player:
There's a random element to it.  If you've ever encountered a green monolith, that's the random part.  There are permanent anomalies, so I can tell you that there are at least a certain number on each body, but without knowing the constraints of the random distribution, I can't give you an upper limit.  I believe that every body except Jool has at least one green monolith, but I've never done an exhaustive survey.
Moho has at least one.
I don't think Eve has any except the random ones.  The same is true of Gilly.
Kerbin has ten, I think, not counting KSC itself.  The Mun has eight.  Minmus has one.
Duna has three.  Ike has none.
Dres has sixteen.
Actually, no; it doesn't have any unless you count the moonlets, but the game doesn't count those.
Jool doesn't have any, including random ones.  It does have some Easter egg text in the science experiments for landing there, though it's mostly along the lines of, 'You just broke the universe!  Congratulations!'  Laythe doesn't have any.  Vall has one.  Tylo also has one.  Bop has two, I think.  Pol has none.
Eeloo has none.

30 km is still mostly out of the atmosphere.  The pressure there is about 400 Pascals, or less than half of a percent of sea level.  There is still drag (it's certainly enough air for aerobraking, for example) but it's not going to materially interfere with your ascent.
Yes, you can.  Real-life rockets and the Space Shuttle didn't have the throttle range that KSP rockets have, so they would actually pitch down (meaning add a little radial in) to circularise.  That wastes fuel but the difference in cost between adding more fuel capacity versus designing a deep-throttle-capable SSME is such that anyone who approved that line of development would have earned all of Senator Proxmire's Golden Fleece awards.  I understand that the SSME of itself is capable of throttling down to something under twenty percent, but the pumps have trouble ... suffice it to say that while the capability would be nice, sometimes, the real-life answer really is, 'More boosters!'
In any event, you have the basic idea:  horizontal velocity is yours to keep, but vertical velocity is not.  The entire point of a gravity turn is to trade vertical velocity for horizontal as your speed and altitude increase, within the limits of your thrust-to-weight ratio.  A perfect gravity turn is one that exchanges vertical for horizontal velocity as soon as you no longer need it, and does so continuously throughout the ascent.
This can result in some interesting-looking gravity turns.  For example, Minmus gravity is such that many landers have a surface TWR of around eight or ten, or even more.  With such extreme thrust and no atmosphere, the perfect gravity turn on Minmus is to thrust up just long enough to clear the ground and then turn hard over to horizontal:  you'll ascend to orbit easily because you have too much engine power to do otherwise.
On the other hand, for your Kerbin ascent, you are seeing the opposite end of the spectrum.  You need a TWR greater than one to get off the ground; that's non-negotiable.  However, staying off the ground is a new problem, and once you begin to ascend, the situation begins to change.  As your trajectory begins to look more and more like an orbit, your TWR needs begin to reflect that.  Since orbital thrust is only required to be nonzero (although greater thrust means shorter burns), it means that the required TWR begins to drop.
Practically, that means that you need enough thrust to counter whatever drag you still experience, and you need enough thrust over that to keep the surface of Kerbin receding faster than you fall, which simultaneously counters gravity losses and gains altitude.  Especially when you're in the upper atmosphere where drag is low, and doubly especially when you have a lot of horizontal speed such that the gravity losses are low, that required TWR will be less than one.
If you ever decide to try spaceplanes, you'll start to see this much more clearly.  Wings to provide lift alleviate the need to thrust vertically, which means that the engines can focus on providing horizontal thrust alone.  The main challenges are to reduce drag, and to balance the interests of building up enough horizontal speed while low enough in the atmosphere for the wings and jets to work but also high enough that you won't burn up from the increased drag of the lower atmosphere, but meeting these challenges does not require a TWR of greater than one.

It shows the average of a series of optimum Hohmann transfers.  That means that the numbers will tend to be low.  There are more efficient trajectories, but most of these are not direct transfers; they require increased flight time, gravity assists, or both.  There are infinitely many less efficient trajectories.  As @bewing said, you can be 100% inefficient.

I can help you with some of the prediction.  If you want to know when you'll be at 90 degrees true anomaly, then you need Kepler's laws; that's non-negotiable.
I'll assume that you're starting from a true anomaly of zero; it's one element that is easy enough to see both in KSP's interface and in Kerbal Engineer.
True anomaly, θ, is given by the equation:
(1 - ε) tan2 (θ / 2) = (1 + ε) tan2 (E / 2)
Where E is the eccentric anomaly and ε = .28, the eccentricity.  In this case, we know that we want a ninety-degree (or π/2) true anomaly, so this equation is a matter of solving for E.
(1 - .28) tan2 (π / 4) = (1 + .28) tan2 (E / 2)  --- This is easy enough; tan of π/4 is 1
.72 = 1.28 tan2 (E / 2)
.5625 = tan2 (E / 2)
.75 = tan (E / 2)
.643501 = (E / 2)
1.287 rad = E
This is about 73.7 degrees.
Once you have E, you need to solve Kepler's Equation for mean anomaly, M:
M = E - ε sin E  --- This is the easy way to do it; if you were solving for position instead of time, you'd have to solve the transcendental
M = 1.287 - .28 sin 1.287
M = 1.287 - .28 (.96)
M = 1.287 - .2688
M = 1.0182 rad
This is about 58.3 degrees.
Mean anomaly is the mean motion times time, and 2π radians divided by the period is the mean motion, n; you mentioned earlier that the period is twelve hours, so I'll use that.  Twelve hours is 43,200 seconds, so:
2π / 43,200 = 1.45444 x 10-4 radians per second.
1.0182 rad = 1.45444 x 10-4 s-1 * t
7000.63 seconds = t
Your time after periapsis passage at true anomaly of 90 degrees is 7000.63 seconds, or 1 hour, 56 minutes, and 40.63 seconds.
The next question is whether you are certain that you want the true anomaly to be ninety degrees.  θ of ninety degrees actually gives the location of the latus rectum, which is certainly useful for some purposes, but if you really want the location of the semi-minor axis, then you want E to be ninety degrees, not θ.  Of course, that's even easier to solve; you can dispense with the true anomaly completely and can begin with Kepler's Equation.
 
Edit:  Oh, why not--let's do it:
M = E - ε sin E --- sin of π/2 is 1
M = (π / 2) - .28
M = 1.2908 radians, approximately, or 74.0 degrees
1.2908 = 1.45444 x 10-4 s-1 * t
8874.87 seconds = t
This gives a time after periapsis passage of 8874.87 seconds, or 2 hours, 27 minutes, and 54.86 seconds.

Outer Planets Mod does what you want; making Eeloo a moon of Sarnus is its only stock planet shuffle.
Extrasolar adds another star system and has the benefit of being compatible with Outer Planets Mod, so you can run both at once if you wish.