Snark

Hello, and welcome to the forums! 
You've come to the right place.    Thanks for including the screenshot, that really helps diagnose the problem!
See those two buttons at the right end of the orange bar?  See how the one labeled # looks like it's "pressed in"?  That's the "numeric entry" toggle.  Click that button to make it pop back out, and you should be back to normal again.

Hello @hellwraiz, and welcome to the forums!
The placement of CoL "above" (i.e. dorsally) or "below" (i.e. ventrally) the CoM is much less critical.
Basically, what that will tend to do is affect the roll stability of the craft.  Above the CoM = more stable for roll; below the CoM = less stable for roll.
The reason it's not all that important is that aircraft tend to be naturally pretty stable on the roll axis, unless you do something really unusual to the design.  This is because,
there typically aren't any major aerodynamic forces that tend to induce roll aircraft tend to have a lot of control authority for roll, since wings tend to stick pretty far out to the sides, and an aileron at the tip therefore has a lot of lever arm to work with SAS does a pretty good job of maintaining roll attitude If you'd like to add a smidgeon of roll stability, you can give your wings a slight dihedral angle (just a tiny bit is plenty), and/or mount them higher up on the fuselage than the midline.
Speaking for myself, though, honestly I don't bother most of the time-- I just mount wings on the default midline and everything works fine.  I'll usually give them a very slight amount of pitch up (i.e. positive angle of attack) to reduce fuselage drag, but that's about it.

OK then, sounds like you've got the ship-design angle all figured out.   
Okay, on to "how do I rescue the poor guy".  So, the way you'll rendezvous will have steps like this:
Launch rescue craft to LKO, then burn to put it on course to the Mun.  (I'll assume you know how to do all that, since you've already done it before.)  Make it so that as you approach the Mun, your Pe is just barely inside Jeb's orbit.  Basically you want your projected path to be just "kissing" the target craft's orbit, with your Pe barely inside it. You're now on a hyperbolic flyby path of the Mun (since you haven't captured yet). Right at your Pe, set a maneuver node and give it some dV:  enough to capture to the Mun, but not enough to match orbits yet.  Lower your Ap to something that's still substantially higher than Jeb's orbit. Ideally you'll be coplanar at this point, assuming that you've kept everything equatorial (both the orbit of your rescue craft, and Jeb's orbit).  Following description assumes this. If this is not the case-- i.e. if Jeb isn't in an equatorial orbit, but is in an inclined one-- tell us, please?  Then you'd have extra steps. So, you should now see markers for "next two encounters" that will give you a sense of how close your craft will pass to Jeb as it orbits around.  You've got the right geometry set up, now you need to work on the timing so that they'll be in the same place at the same time. Carefully give some more dV to your maneuver node.  This will shrink your orbit, and as you slowly/carefully add , you'll see the closest-approach markers move around.  Your goal is to adjust it until the amount-of-separation is at a minimum, i.e. so that the markers for the two ships coincide. Once you've gotten that, you just do the burn. Then coast around until you approach the encounter. When your ship gets within a certain distance of the target (like 50 or 60 km), then your navball will shift to "target-relative" mode. From this point, follow the first few steps from this illustrated guide to docking (only as far as step 3, since you're not actually docking), until you end up parked next to Jeb, fairly close by, at near-zero relative velocity. At that point, you then switch ships (use the [ or ] key), send Jeb EVA, have him collect any science out of the pod, then he lets go and spacewalks over to the rescue craft to get in.
Then you just fly home.  Ta dah! 

Hello, and welcome to the forums! 
I've taken the liberty of splitting off your post from its original thread to here, since it sounds like you have a specific technical problem and need help with that, and this is the right place for that sort of thing.
Nobody else can help you directly, since it would be illegal for anyone to send you any assets from the stock game, due to copyright / EULA reasons.
However, depending on how you acquired KSP, it may be easily fixable.
For example, if you bought it on Steam, just go to your game library in the Steam app, right-click on KSP, choose "Properties".  When it pops up the properties dialog, click on the LOCAL FILES tab, then click the "VERIFY INTEGRITY OF GAME FILES..." button.  It will automatically scan your installation, find any missing or corrupt files, and fix / replace them by downloading fresh copies from the Steam server.  And it's safe to use even if you're modded-- won't disturb anything except the "standard" files that are part of the game.
If you got it by some way other than Steam, there may be a way to do it for your platform, too, but in that case I don't happen to know the exact steps myself. 

As @bewing correctly points out above, the Communotrons won't help you at all for your relay power, since they're direct antennas.  All that matters is the actual relay antennas.
RA-100, like most antennas, doesn't stack linearly.  It's an exponential fall-off.  The actual antenna power is:  take the number of antennas, raise that to the 0.75 power, and multiply that by the power of one antenna.  You have 9 of them, so 9 ^ 0,75 = ~5.2.  Therefore, as bewing points out,
At its outermost orbit, Plock is beyond that (689G), so this comsat won't reach that far as a relay.
The issue that you're running into is that the stock antennas were designed to work with the stock solar system.  If you're working with solar systems that are much bigger than the stock one, this has the potential to cause problems.  There are various ways to deal with this.  One way is to use some combination of multiple-hop relays with spamming lots of RA-100.  Another way is to use a mod.
If you're open to the idea of using mods, here's a mod with a giant 1000G antenna, specifically designed for playing in larger-scale modded solar systems.  It includes a compatibility patch for Outer Planets:
 

The problem is that your center of mass doesn't line up with your center of thrust.  So there's two ways you could fix it:
Move the center of mass Move the center of thrust The easiest way to move the center of mass is to pump fuel around... but the degree to which you can do that will be limited by things such as "where do you have available empty tanks that you could pump fuel to" and so forth.
As to moving the center of thrust... you might actually be well set up for that, because of this:
What you can do is to tinker with the thrust limiters.  If the craft tends to curve left when you thrust, try lowering the thrust limiter of the engine on the right, and so forth. 
How effective that will be (and whether it will be enough) will depend on how far off-center your CoM is, and also how far apart your engines are.
 
The way that @Vanamonde describes is basically the only way to do it in flight, unless you use a mod.  Rotate the camera view, the CoM is the center of the camera rotation.

So, a few thoughts.
First, reaction wheels.  Looks like you've got some to spare.  For example, your "Duna base 2" looks like it's got a reaction wheel sitting on top that it doesn't need anymore (since it's already landed)-- scrounge that.  Your "Duna base" crashed spaceplane has at least three more of those reaction wheels.
Grab as many spare reaction wheels as you can, and bolt them to the plane any-old-place (doesn't matter where).  They might have enough torque to flip it.
I see that you've got a ton or thereabouts of liquid fuel on the flipped plane, so if you could pump that out of there to somewhere, it could help make it easier to flip.  (Or, at least, pump it to somewhere on the plane that's as close as possible to the "flip point".)
The hardest part of flipping the plane will be getting it cranked off the ground in the first place.  So, if you can't quite manage it with all the reaction wheels, but you can come close to it, you could take one of these landing legs off your "Duna base 2" (looks like it's on sloping ground, so take off the uphill leg, it'll probably be fine):

...you can mount it somewhere strategic on the plane, then choose "extend landing leg" to make it lever the plane up off the ground and at least get it so it's standing up at a 45 degree angle or so.  If you can do that, then reaction wheels could take it the rest of the way.
 
Another idea that occurs to me would be to use two of these legs in sequence:  have one lever the plane up a bit.  Then insert the second one (retracted) farther in, and open it to lift the plane further.  Then take off the first leg and move it further in to lever the plane even more, and so forth.
 
But honestly, I suspect the simplest thing to do is:
attach as many reaction wheels as you can (you've got at least four that I can see) try to flip with that if it doesn't work, use a landing leg to prop the plane up off the ground and try again also try removing the liquid fuel from the plane to save some weight  
[EDIT] Now that I look a little more closely, looks like you've got at least 6 more reaction wheels in the underbelly of that crew ship.  So that's a total of at least 10 reaction wheels that you have available to play with.  Attach those to the plane and you oughta be able to flip it right over. 

Moving to Gameplay Questions.
Because heat shields are extremely tough and useful even without ablator-- very high temperature tolerance, and fairly low thermal conductivity.
And also because your ship has a very low ballistic coefficient, i.e. it's lightweight relative to the amount of drag it produces.  Lightweight, draggy designs don't take as much of a pounding from reentry heat.
If your ship had significantly more mass loaded up behind that 2.5m heat shield, then you might find yourself needing the ablator.
 
(Out of curiosity, how fast were you going when you hit atmosphere?  You're only 3500 m/s in that screenshot, but you're already deep in the atmosphere and decelerating hard.)

Hi @TomVorat,
So, first thing to check is to make sure you're not running out of RAM, especially if you only have 8GB on your machine.  Keep Task Manager open and look at KSP's RAM usage as it loads.  How high does it get?
If the problem were some particular mod, then the symptom you'd expect to see would be KSP having problems, but your computer otherwise being fairly unaffected.  If it slows your computer way down, and causes issues like computer audio, then that's the sort of thing you'd expect to see when you're pushing past your computer's RAM limit and it and it has to start excessively spamming virtual memory.
The fact that you're running a very heavily modded KSP on a machine with only 8GB of RAM just makes that sound even more likely.
So, I'd suggest checking your RAM usage, and if that turns out to be the problem, either run with fewer mods or get more RAM.

Hello, and welcome to the forums! 
Two things to understand:
First, there will be zero effect of drag on your ship unless you are actually flying the ship while it's in atmosphere.  That's because KSP runs every ship "on rails" other than the currently controlled vessel (and any other vessels within a few kilometers of it, a.k.a. the "physics bubble").  So for example, if you were to switch away from the ship and just watch it orbiting 'round and round from the tracking station or something, it will literally never degrade and orbit forever.
"Background drag" simply doesn't happen in KSP.  As long as your ship stays above an altitude of 1% Kerbin sea-level pressure (i.e. an altitude of about 23 km on Kerbin), then it will simply orbit forever with no drag happening, if you're not flying it.  (And if it goes below that altitude while you're not flying it, then it will simply be deleted as "lost", so beware).
Second, you mention that your Pe is 69,590 m.  That's just barely kissing the top of Kerbin's atmosphere, which is at 70,000 m exactly.  You're only dipping 410 meters into the atmosphere, and you're not going to be spending much time below 70 km.
That means even if you are flying the ship... drag forces are going to be only briefly applied for a moment right at Pe, and will be vanishingly tiny.  You're going to take for-gosh-darn-ever to noticeably degrade-- you could be continuously flying the ship and it would still probably take many hundreds of orbits to degrade and re-enter.  You really need to get your Pe a lot lower than 69,590 to start seeing significant drag.
My suggestion?  Get out and push.
...No, really, I'm not joking, I literally mean that.  Kerbal EVA thrusters are notoriously overpowered-- they're enough to give a lone kerbal something like 600 m/s of dV, and also you get a free refill of your EVA propellant every time you get back into the command capsule.
So in a situation like this, here's what you can do:
Wait until your ship has coasted up to Ap. Go EVA, maneuver Jeb around until he's in front of the craft facing towards it in the orbital direction... and then thrust Jeb forwards so that he's pushing against the ship.  (It can be a little tricky not to spin the ship or slip off to the side while doing it-- will likely take some futzing around.) This will give the ship a very gentle nudge in the direction.  Since you're doing it at Ap, this means it will lower your Pe.  The ship is a lot more massive than a kerbal, so you'll probably only be able to lower the Pe just a bit, but do what you can. When Jeb starts to get low on EVA propellant, maneuver him back around and get back inside the command pod. The above sequence of actions will lower your Pe by a bit.  Probably not enough in just one pass to reenter and come down... but as soon as Jeb clambers back inside in step 4, he gets a refill on his EVA propellant for free!  So if (as is likely) he hasn't lowered the Pe enough to be very helpful, you can just coast back up to Ap again and repeat the process.

Hello, and welcome to the forums! 
Moving to Technical Support (since the "mod development help" forum is for folks writing mods).
Ah, okay.  That's probably it, then, there's your answer.
So to solve your problem, just establish which mod it is that's causing the issue.  Once you know that, you can go to the mod's thread to ask about the problem.

Right, because you don't have enough dV on that rocket.
Your first stage has 1362 m/s, your second stage has 1663 m/s.  That's only 3025 m/s altogether, which simply isn't enough to get orbit-- you want 3400 m/s minimum, and that's assuming an optimal ascent path and no other problems.  If you're fairly new to KSP and still learning the ropes, I'd recommend a few hundred m/s of dV above 3400.
In addition to which, there are some other issues with that rocket:
Poor streamlining-- the big flat front ends on the top of those boosters is going to kill your aerodynamics, so you'll waste a lot of dV to drag.  Put nosecones on them. Your TWR is probably too high.  I'm guessing you haven't used the thrust limiters on those SRBs?  If you haven't, and they're firing at 100% strength... two of those on a small rocket like that is way overkill.  (Try expanding the initial stage in the editor view-- it'll tell you what your launchpad TWR is).  In general you don't want your TWR on the pad to be any higher than 2 at most.  When your TWR goes way higher than 2, you end up going too fast when you're still too low in the atmosphere, and you end up wasting a lot of dV to aerodynamic drag.  (Which is made even worse by the lack of nosecones on your boosters). As to why your changed design has so much less dV than the original... that comes back to the rocket equation, which I can go into if you like but the short answer is that "it's considerably easier to get to orbit with three stages than two", and also "you want your orbital stage to have a small, lightweight engine on it with high Isp".

Here's what you need:
Have a good transfer trajectory from Kerbin in the first place. Understand the basic "how it works", i.e. what it is you're trying to do. Know where Tylo is supposed to be upon your arrival, and what path your craft should be taking. Adjust your path, midway on your trip from Kerbin, so that Tylo (and your craft) will be in the right place upon arrival. Details on each of these, below.
 
Step 1:  Have a good transfer from Kerbin
You need to have an efficient Hohmann transfer from Kerbin.  This is because you want to arrive at Jool with the lowest possible Jool-relative speed.
I mean, obviously you want that anyway to try to lighten your dV requirements.  But also, it's especially critical for using a gravity assist.  Because the faster you go whizzing past a planet or moon, the less dV you can squeeze out of it in a gravity assist, because there's less time available for its gravity to bend your path.
I've done Tylo gravity assists, and they work great if set up properly with a decent Hohmann transfer:  i.e. can shave a few hundred m/s off the craft's speed, and actually capture to Jool without spending a single gram of propellant.  So it's totally doable. 
Just, make sure you have a pretty good transfer window, or a Tylo assist won't help you all that much, is all.
 
Step 2:  Understand the basic "how it works" (e.g. "why am I finding this so hard")
Long-winded details in spoiler, but  the key concept to bear in mind here is that timing matters.  Tylo has to be in the correct place.
 
Step 3: Know where Tylo is supposed to be upon your arrival, and what path your craft should be taking.
(In the following discussion, I'll use "left" and "right" in the sense of "north is up" that KSP uses in space.)
When your craft is approaching Jool, you'll see the face of Jool moving from left to right as it rotates.  The moons are orbiting in the same direction:  from left to right as they pass in front of Jool, and from right to left as they pass behind it.
You're going to want your craft to pass to Jool's right (i.e. you want to be orbiting in the direction relative to Jool's rotation). You want Tylo to be in front of Jool (not behind), i.e. between you and Jool:  you want to meet Tylo before your Jool Pe, not after. You want Tylo to be slightly to the right of Jool as you approach from interplanetary space. You want your craft to whizz past Tylo as close as possible to Tylo's surface, in order to maximize the dV transfer from the assist. You want your craft to pass to the right of Tylo (i.e. you want to go past its leading edge in its orbit), so that it will slow you down. Put another way:  If Jool is the center of a clock dial, and Tylo is at the rim of the clock and orbiting counterclockwise, and your craft is approaching from the 6 o'clock direction, you want to pass just to Tylo's right when Tylo is in about the 5 o'clock position.
 
Step 4:  Adjust your arrival timing to make that happen.
Wait until you're around halfway from Kerbin to Jool, when you're still many hundred days away from Jool arrival.  Presumably you already have an intercept with Jool's SoI (since you set that up when you left Kerbin).  So now you just need to adjust things for your gravity maneuver.
You'll be doing this by plopping down a maneuver node, there at the midway point, and adjusting the handles.  Here's what you do:
Focus the map view on Jool, so you can see your path through the system. You need to know where Tylo's going to be, given your current timing.  To do this, just use the controls on your maneuver node to scan your arrival trajectory back and forth from left to right through the Jool system, from the left edge of Tylo's orbit to the right edge of Tylo's orbit.  Somewhere in there, you'll see your trajectory show a Tylo intercept. Okay, now you know where Tylo's going to be at the time of your arrival, if you didn't do any tinkering with the timing.  This tells you what you have to do about the timing.  Maybe you got super lucky and Tylo's already in the right place, in which case yay, you're done.    But it probably isn't.  So, unless you got really lucky, it will be one of the following two cases: Tylo is behind where it needs to be (in which case you need to delay your Jool arrival to give Tylo time to move farther along in its orbit). Tylo is ahead of where it needs to be (in which case you need to make your Jool arrival earlier, so that you'll catch Tylo before it moves along too far). Okay.  So now you know whether you need to delay or advance your arrival, you need to make that happen. Take a look at your Jool Pe marker to see when it is.  Note the time. Start playing with the controls.  The goal is to adjust the time of your Jool Pe, while keeping its location where you want it.  Note that for each of these pairs of controls ( on the one hand, on the other), one of them will make your arrival path sweep to the left, and the other will make it sweep to the right.  The way you adjust your time without adjusting your path is to use those controls in turn.  For example, if you use to sweep your path a bit to the left, and then use to sweep it back to the right again to the original location... the time of your Pe won't be the same as it was.  It will be ahead or behind where it was, by a bit.  So just keep repeating that operation to shift your time until Tylo gets to where you want it to be.

Moving to Gameplay Questions.
It's only present when "Allow Full Rotation" is set to "disabled" on the rotational servo.  Since it's enabled by default, that's why you're not seeing it.

Hello, and welcome to the forums! 
I think that may have been a temporary technical glitch that happened when the site got overwhelmed by an avalanche of people all trying to buy Breaking Ground at once.
Could you try again and see if it works better this time?  (I've heard from folks who ran into the same problem as you, but then tried a while later and were fine.)

A question, @Baker.  Do you have Making History, or not?  If you do, it has some "engine plate" parts that could would be helpful here.
First of all, your return craft:

...that's got way, way, way too much engine on it.  So you can make this part of the ship considerably lighter by slimming down a few things:
Make sure you've zeroed out the command pod's monopropellant, if you haven't already done that.  Saves 120 kg. Reduce the ablator on the heat shield, if you haven't already done so.   You really don't need much for a Mun return.  Reduce it down to, say, 10%.  Saves 720 kg. Replace the Poodle with a pair of Twitch engines.  Saves 1.59 tons Alternatively, if you have Making History, you can replace the Poodle with a 2.5m engine plate, and then mount a single Spark under it. The engine plate then lets you attach a 2.5m component directly to it, which is nice. So, overall, you can reduce the mass of this component by over 2.4 tons, which should help your dV bottom line by quite a bit.  (I also note that it's got more fuel than it really needs, too-- it's got more than double the dV it needs to get home from Mun orbit, even before saving 2.4 tons as suggested above.  So you could save another couple of tons by cutting the fuel amount in half.  2 tons of fuel is plenty to get home on.
Next, let's look at your lunar lander:

That's got way, way overkill in several aspects.
First of all, it's got far too much engine. Remember that munar surface gravity is only 1.63 m/s2.  You don't really need more than a local TWR of 3, meaning that a lander this size needs under 60 kN of thrust.  Whereas you've got four times that. Second, you don't need the big legs, unless you just like them for looks.  The medium legs should work just fine. Make sure you've zeroed out the lander's monopropellant supply, if you haven't already. So, for example.  Get rid of the can's monoprop, that saves 160 kg.  Replace the large legs with medium legs, that saves 200 kg.  Replace the 8-ton LFO tank with a 4-ton LFO tank, saves 4.5 tons.  Replace the pair of Thuds with a pair of Twitch engines.  Result:  you get a craft that has about the same dV but only half the mass.
(And it's worth noting that even that is way more dV than you need.  Getting from low Mun orbit to the surface and back takes 1200 m/s plus a bit of safety margin.  You're packing over double that.  So unless you're planning on doing a bunch of biome hopping before returning to orbit, you could cut your fule considerably to save even more mass.)
Now, the 1.25m Science Jr does present a problem, since you've got a 2.5m stack.  One convenient way to solve that is with an engine plate (a Making History part), which would let you mount a Science Jr. there but still mount the 2.5m stack below directly to the lander without breaking up the radius.  If you don't have Making History, you could instead put a 2.5m service bay on the craft, and stick the Science Jr. inside of that.
 
Finally:  your lifting and transfer stages:  Note that doing the simple things described above can cut the mass of both your return ship and your Mun lander approximately in half, without losing any functionality.  So since that stuff weighs half as much now, that means you only need half as much booster to get it launched.  So you can do a lot of slimming down there, too. 

Great, in that case you're doing exactly the right thing and you already have a good transfer window there.
What about my second point, the one you didn't quote?
^ That's really important.  Laythe orbits Jool at over 3200 m/s, so depending on what direction you're approaching Laythe from, this can make up to 6400 m/s of difference in your relative velocity when you hit atmosphere.  This is huge, and very important to be aware of.
Sure.  Basically, it's a reverse slingshot maneuver.
Let's imagine the reverse situation.  Suppose you're in low circular orbit around Jool, and you want to eject from the Jool system with as much velocity as you can, without using too much of your own fuel for dV.
Well, one way would be to just do a great big burn to eject.  But there's a way you can gain several hundred m/s of dV for free, using a gravity assist maneuver, or "slingshot:  you do a burn that's enough to raise your Ap a bit past Tylo, such that you're crossing right behind Tylo (deep into its SOI, passing as close to Tylo as possible) when you're crossing its orbit.  Tylo's gravity and orbital velocity will give you a "helping hand" and fling you out of Jool's orbit much harder than your own small dV burn provided.
So, basically, do that in reverse.
Set up your Jool arrival so that your target Jool Pe is really low down (i.e. lower than Laythe's orbit). Have it timed such that as you're falling closer and closer to Jool, at the point where you cross Tylo's orbit, you're doing it just in front of Tylo in its orbit (i.e. you cross Tylo's SoI on your inbound trajectory towards Jool, passing very close to Tylo as you do so). When you fly past Tylo in this fashion, its gravity and orbital velocity will bend your trajectory in a way that removes a lot of your velocity:  done well, it can bleed off so much speed that it actually captures you to Jool orbit without needing to burn your engine at all! This puts you in a very eccentric Jool orbit, with a Pe down below Laythe and an Ap way up high, maybe out past Pol. As you exit Tylo's SOI, continue falling in towards Jool. When you arrive at Jool Pe, do a moderate burn (your first since entering Jool's SoI) to lower your Ap further, to something manageable, e.g. around Pol's orbit or below. Coast up to Ap, then do a small burn to raise your Pe up to match Laythe's orbit. Coast back down to Pe (now at Laythe's orbital height), and do a burn to adjust the timing of your orbit such that you'll meet Laythe the next time you reach Pe. Swing 'round by an orbit, then do your aerobraking at Laythe as you like.  
Incidentally, if getting it timed for a Tylo gravity assist in this fashion seems too complicated and difficult for you... the above strategy still works pretty well, just skip steps 2 and 3.  Set up your Jool approach to aim for a very low Pe, i.e. as low as you can go without hitting atmosphere, then do a burn at Pe to capture and lower your Ap to Pol's orbit or below.  Then just do the remaining steps 7-9 to arrive at Laythe.  Even without the reverse gravity assist from Tylo, this is an efficient way to arrive because it takes advantage of Jool's gargantuan Oberth effect.

Ah, quite so.  Missed that.
Lengthy advice below, but the TL;DR boils down to:  1. Make the tail bigger, with a lot more control surfaces; 2. Move the wing ailerons farther out towards the wingtips, 3. Consider maybe adding canards on the front, and 4. Make sure you have roll authority turned off for your vertical stabilizers.
And now for the Wall of Text™: 
Well, for one thing, it's got very little pitch authority.
Bear in mind that the effectiveness of a control surface (in terms of generating torque to rotate the craft about some axis) is directly proportional to its lever arm, i.e. how far it is from the center of mass along the relevant axis.
You don't have the CoM marked, but given the relative amount of lifting surface on wings and tail, I assume it's a reasonably safe assumption that your craft CoM is centered pretty close to the wing, yes?
In that case, any ailerons you have on the wings are going to be pretty much useless for pitch-control purposes, because they're right next to the CoM and therefore have very little lever arm to work with.  Which means you're entirely going to be dependent on tail elevators for pitch control... and it's hard for me to see just how much oomph you've got there, but it looks like a pretty small tail compared with the size of aircraft that you're trying to steer.
So, my suggestion would be to put more control surfaces on the tail, and/or move the tail farther back from the CoM if there's a reasonable way to do so.  You may want to consider giving more control authority (i.e. above the default 100%) to those elevators back there.
I'd also suggest adding some canards way up in the front of the craft, as far forward as possible, since that also has a pretty good lever arm.  More pitch authority there.
As for roll authority... is the craft rolling reasonably responsively, or is it sluggish?  If it's sluggish to roll, then you need to move those ailerons on the wings farther out towards the wingtips, to give them more lever arm to work with.  You've got them snuggled in close to the fuselage, which makes them less effective for roll authority.
Looks like the plane has vanishingly tiny yaw authority-- just a couple of itty bitty vertical stabilizers on the tail.  That may very well be plenty enough (you can fly a plane using just pitch and roll, without a lot of yaw).  Maybe you're fine there, maybe not-- I'd suggest addressing the pitch and roll issues first, and then see how you like how it flies.  Then consider whether you need additional yaw authority.
(One thing to make sure, though, is that you've got roll authority turned off for your tail's vertical stabilizers.  You want those to be doing nothing but yaw.  If you've got roll authority turned on, then they're going to generate a lot of unwanted yaw torque when they try to "help" with rolling, especially since you've chosen to put them sticking way up high above the craft body like that, which gives them a lot of lever arm for rolling.  Failing to turn off the roll authority can make the craft harder to steer and can cause the wing ailerons to end up fighting with the vertical stabilizers, making it harder to steer the craft.)

Yeah, the wiki seems... curiously mum on the subject of autostruts.  Really oughta have an article there.
Here's the idea behind autostruts:
You're familiar with the EAS-4 Strut Connector, yes?  It's that part that you can place where you attach the two ends wherever you want, and it holds them rigid.  Useful for making a ship stronger / stiffer... but it comes at the cost of weight and drag (struts are heavy and draggy), and also the fact that it's a physical part and has to be a straight line places some constraints on where you can put them.
Well, an "autostrut" is functionally similar to a physical strut-- in that it connects two different parts, and holds them fairly rigidly in the same position with respect to each other.  However, it's not a physical part, and has no mass or drag.  It's just part of the hidden internal physics model that the game uses when putting stresses on a craft.
Autostruts are always available in sandbox games.  In career mode, they're only available after you've unlocked the necessary tech node, which (I think) is General Construction.
To be able to work with them, though, you need to have Advanced Tweakables turned on in the game settings, as bewing mentions above.
If they're available to you (because you're in a sandbox game, or a career game after getting General Construction), and if you have Advanced Tweakables turned on, then you can see them on a part's right-click menu, either in the vehicle editor or in flight.  For example:

Clicking the button allows toggling among the various autostrut modes.  The choices are:
Disabled.  (This is the default.)  No autostruts are applied to the part. Heaviest part.  Generates an auto-strut to the heaviest part in the ship (or set of parts, if it's a symmetry group).  Note that this is dynamic:  if "which part is heaviest" changes (e.g. with docking/undocking, or a fuel tank emptying), then it'll switch to the new heaviest part. Root part.  Generates an auto-strut to the root part of the ship. Grandparent part.  Generates an auto-strut to the parent part of this part's parent.  This is chiefly useful for things like radial boosters:  i.e. you attach a decoupler to the central core, then you attach a fuel tank or whatever to the decoupler.  You can set that fuel tank to "autostrut grandparent part" and it'll be locked to the central component, which is typically what you want. Advantages of autostruts:
No mass No drag They're free (no part cost) They're not physical pieces, so there's no constraint about their maximum length, or whether there are any other pieces in between the two parts that are autostrutted together. You can edit them while in flight, not just in the editor. Disadvantages of autostruts:
Judicious use in just the right strategic spots is fine, but don't go nuts and spam them everywhere.  They complicate the physics model and (if abused) can slow down your frame rate and/or can attract the kraken. Some might call them "cheaty", if you're the kind of person who cares about that (I'm not, myself) Since you can't see them, it's easy to forget that they're there, which means it can sometimes be non-obvious why a ship is behaving as it does. Personally, I use them, but sparingly.  I will commonly use the "autostrut grandparent part" for radial boosters-- but usually it's only there.

Hello, and welcome to the forums! 
Moving to Gameplay Questions (since Science & Spaceflight is for discussions about real-life science & spaceflight).
Yeah, those darn Russians and their names full of consonants.  Tsiolkovsky.
Sounds like you're off to a good start.  Just FYI:  You probably want to use atmospheric Isp for the first stage off the launch pad, but you should probably be using vacuum Isp for everything after that.  Reason:  The atmosphere falls off very quickly with altitude.  By the time you get to 10 km, you're already 90% of the way to vacuum, and engines' effective Isp will be much closer to vacuum values than ASL.  And your first stage probably takes you high enough that everything after that will mostly be in vacuum.
This doesn't matter all that much for engines like the Swivel, Reliant, etc. because their vacuum and ASL numbers aren't all that far apart.  But for engines like the Terrier or Poodle, there's a huge gap between the two (they're truly awful in atmosphere), so your numbers will be a lot more accurate if you use the vacuum Isp values for those.
You may be going off the rails there.  The mass of the stages doesn't matter.  What matters is the mass of the whole rocket.
For example, suppose you have a 3-stage rocket, and the total mass of the rocket sitting on the launch pad is 16 tons, and the first stage has 4 tons of fuel in it.  So, when you plug that into Tsiolkovsky's equation, the two numbers you should use to find out the dV of the first stage is the total rocket mass divided by mass of rocket minus first stage's fuel, i.e. in this case it would be 16 / 12, or 1.333333.
Then, to calculate for the 2nd stage, you'd do the same thing-- but for "total rocket mass" you'd use the total mass after ditching the first stage, and for dry mass you'd use the total-mass-after-ditching-first stage divided by the mass after burning the 2nd stage's fuel.
What you don't want to do is to use the mass of the stage itself.  It's the whole mass of the rocket at that point that matters, including the dead weight of the stages above that which you haven't activated yet.
Aside from the fact that your math has gone off the rails because you're not using the whole rocket mass... it's also worth noting that you have a really wrong number for Isp on this one.  SRBs' Isp is nowhere near 520.  ASL Isp for a Thumper is 175, and for a Hammer is just 170.  So the value of the three of them together would be between those two numbers (closer to the former than the latter, since that's where most of the thrust is).
Nope, you're exactly right in this realization, as discussed above. 

Hello, and welcome to the forums! 
I've taken the liberty of splitting your post into a thread of its own, since the last one was pretty old.
No, that's not enough.  But there are options.
First, you do have enough to get into orbit around the Mun, so that's a good start.
Once you get to that point, you have a few possibilities.
One would be to send a rescue mission.  Send another ship that has an empty crew slot, which can rendezvous with your stranded ship in Mun orbit.  Then transfer the kerbal across and head home.
Another option would be to get out and push, i.e. use your kerbal's EVA thrusters to shove the ship in the right direction, and go back into the crew pod every time your EVA fuel gets low, so you have a refill.  Keep doing that and you can pick up a few hundred m/s of dV (slow and tedious, though).
Yet a third option would be to send the kerbal EVA, use their 600 m/s (!!!) of EVA propellant to take the kerbal to low Kerbin orbit, and rescue them there.
 

Hello, and welcome to the forums! 
What's happening here is that the aero forces on the ship are so huge that it's turning your ship into a floppy noodle and wrenching it out of shape.
A major part of the reason for that is that you've mounted your heat shield on a flimsy little narrow girder, which means the connection's a lot weaker than if you used a 2.5m stack.  Skinny parts aren't as stiff as thicker parts.
If you attach it with a part that's the same size as the heat shield itself (i.e. 2.5m), it will be a lot stiffer.
Another option is that you could just turn on the "autostrut" feature for that part-- tell it to "autostrut to heaviest part", for example, and it'll go almost completely rigid, even if you've left it on the skinny girder.

Completely depends on the science instrument.  Each science instrument has a different set of "rules"-- not just "where can it take a measurement?", but also "in what situations does it yield per-biome results?"
By "situation", I mean one of:
Landed Splashed Flying Upper atmosphere In space, near In space, high Basically every instrument works while landed, and all of them are per-biome in that situation.  But for other situations, it varies.
For example:
Flying: Thermometer, atmosphere analysis, EVA report, and crew report are per-biome.  Other experiments aren't. Upper atmosphere:  Atmosphere analysis is the only one that's per-biome. In space, near:  Gravioli detector and EVA report are per-biome.  Other experiments aren't. In space, high:  Gravioli detector is the only one that's per-biome. You always get different science from ground and orbit.  It's just that whether it's per-biome or not that may vary.  For example, let's suppose you're visiting the Mun, and you visit two biomes-- say, Lowlands and Highlands.  And you land on each of those biomes, and also spend some time "in space near the Mun" over those biomes.  And you have two science instruments: a thermometer and a gravioli detector.
Here are the science results you could get from those:
Thermometer:  Three results.  Landed, Lowlands.  Landed, Highlands.  In space near the Mun. Gravioli detector:  Four results.  Landed, Lowlands.  Landed, Highlands.  In space near the Mun over Lowlands.  In space near the Mun over Highlands. ^ In the above example, both instruments can take science on the surface, and also in orbit.  But the gravioli can take as many measurements in low orbit as there are biomes that it flies over-- whereas the thermometer can only take one measurement in low orbit, regardless of how many biomes it flies over.
Careful-- that's only true in the specific case of "in space, near".  Answer is different for other "above ground" situations such as "flying", "upper atmosphere", and "in space high above".  For example, a thermometer is per-biome when flying (i.e. low flight in atmosphere).  EVA report isn't per-biome if you're "in space high above".

Hi @Hotel26,
Details below, but the executive summary is that the VAB is just as deterministic and easy-to-build as the SPH.  The problem is that you have the wrong mental model for orientation.  (Not your fault-- it's KSP's fault for being confusing about this.)  As soon as you mentally re-orient yourself so that your mental model matches what the VAB is actually doing, things make a lot more sense.
In short:  Your confusion isn't caused by the VAB not having an orientation (because it does have one).  Rather, the problem is that the VAB has the wrong orientation, and that's what's confusing you.
 
Yes, and so does the VAB.
SPH prograde = eastward SPH up = skyward VAB prograde = skyward VAB up = southward It's perfectly consistent.  Let's say you go into the vehicle editor and plop down, say, a Mk1 command pod.  What happens in each editor?
In the SPH: The pointy end is pointing prograde (eastward), and the hatch is pointing up (skyward). In the VAB: The pointy end is pointing prograde (skyward), and the hatch is pointing up (southward). Your problem is that in the VAB, you're thinking of up as up.  It isn't.  Kerbin-up is ship-prograde.  Kerbin-south is ship-up.
 
No.  That's not what's happening.  Compass orientation is perfectly consistent in the VAB, exactly the same as with the SPH.
What you're missing is that the VAB definitely has an "up", and it's pointing south.
The reason this causes you confusion is that you're missing that systematic and pervasive bias in the VAB, so things seem random.  "Sometimes I put a thing there and it lines up with parts already placed, but sometimes it doesn't."  That doesn't mean the VAB is inconsistent-- it means you are.
Newly placed objects in the VAB always have their "up" direction facing south, regardless of the orientation of already-placed parts.
And actually, it's even more pervasive than that:  If the ship's facing some other direction than the default, and you detach one of the bottom parts... it suddenly snaps to turn 'round so that its "up" is facing south, and if you want to re-attach it the way it was, you have to actually rotate it!
 
All of this probably wouldn't be so much of an issue if the VAB actually had its default orientation set up in the obvious sane way:  VAB "up" should be west, not south.  "Doing a gravity turn" should consist of pitching down, not yawing right.  But it's not set up that way, and when you try to make your ship built in that orientation, you're fighting the VAB every step of the way.
In short:  Your experience in trying to build stuff in the VAB is exactly the same as if you try to build a spaceplane in the SPH that's lying on its right side rather than right-side-up.  Go on.  Try it.  Confusing, isn't it?
So, given that you do in fact want to build things facing eastward rather than northward, what can you do?
Well, there are a couple of ways.
First, if you want to do it entirely in stock:  Just go ahead and build everything in the VAB with your ship facing north, the way that the VAB inexplicably wants you to.  Then, when you're done, choose the "rotate" tool, and click on the root part of the assembled ship, and then rotate the whole shebang to face the correct direction.
This approach has the advantage of being stock.  It has the disadvantage that you're basically "fighting" the VAB every step of the way, which means that you have to do this silly dance every single time you build a ship.  Actually, it's even worse than that, since any time you want to go back and edit the ship, you need to rotate it back to facing nonsensically northwards, then do your edits, then rotate it back again.  It's stark raving silly.
Or, alternatively, you can just install this mod, as @swjr-swis suggests:
This mod is very simple:  all it does is change the default orientation of the VAB to face east instead of north, which is exactly what you want here.  Do that, and the VAB will "just work" in pretty much the way you expect.  In other words:  The "stock" approach described above requires you to change your mental model (and play style) to match the stock game's.  VABReorienter, on the other hand, changes the game's model to match yours.
Personally, I like the second way better. 
 
Disclaimer:  When I talk rather cavalierly in this post about how the VAB's default orientation is "wrong" or "silly" ... I'm not claiming to speak for everyone, or even for most folks.  I merely speak for me, and for people who think like me.  There are plenty of players who, for good reasons of their own, prefer it the way Squad set it up.  However, I need not go into that because such players are not the target audience for this thread.    For people who have my mental model of the game, the stock setup doesn't work and is irretrievably silly.  And from your writing, it appears to me that you're running into this problem because you have essentially the same mental model that I do.  So, my remarks in this post are addressed to people like that.

This is actually not quite the case.  What needs to stay behind your center of mass isn't the center of lift, it's the center of dynamic pressure.  (You can think of this as "center of drag", sorta.)  That's a different thing from "center of lift".  (The CoL display in the VAB only includes components that explicitly have "lift" assigned to them, e.g. wings; but the center of dynamic pressure applies to all parts.  If you focus only on CoL, you're likely to get a highly misleading picture.)
Unfortunately there's no convenient VAB marker for showing where that is (for good technical reasons), so you kinda have to eyeball it.  Main thing is to make sure that your CoM is as far forward as possible, and that any fins you have behind it need to be as far behind the CoM as possible (because the effectiveness of a fin is directly proportional to its distance behind CoM).