Streetwind

It is physically impossible, I'm afraid - in real life and in KSP both.
What you're experiencing is called "microgravity". When you are side by side with another spacecraft, you are still not in the exact same position - your centers of mass are a few dozen meters or so apart. And that means that these two spacecraft are effectively in different orbits. The difference is extremely small, sure - but over time, orbital mechanics will pull the two spacecraft apart, or towards each other, or the like. A perfectly nulled out velocity difference will immediately start growing, however slowly, the moment you turn off your engines.

Posting a video is always a great way to get help
In this particular case, you are too close to the maneuver node by the time you start to throttle up. In other words, the maneuver node is too large for you to complete it at that moment in time. In yet other words, your engine does not have enough thrust. All of these are true.
But as CBase already pointed out, these are not the underlying cause. The actual cause is that your ascent is much too steep. You spend too much effort into going up, and not enough effort into going sideways. As a result, by the time your apoapsis reaches your desired altitude, you need to catch up to all this going sideways business. But there is so much to catch up to, you'd have to bring a really big engine and accellerate really hard to make it in time.
If you go sideways more during ascent, then the maneuver node you have to make to insert into orbit will be smaller. Additionally, it will also take you longer to push the apoapsis up to your desired altitude, which means you spend more time going sideways more, which yet again reduces the size of the final maneuver required. With practice, you will be able to get your final insertion maneuver down to less than 100 m/s.
So, how do you know how much sideways is enough sideways? Experience, mostly. But, here's a handy rule of the thumb: by the time your rocket has turned halfway over (45 degrees towards the horizon), you want to be somewhere between 10km and 12km in altitude. Don't sweat it if you don't hit it exactly; it is a rule of the thumb, not a law of physics. The exact "perfect" trajectory varies from rocket to rocket anyway, based on its thrust-weight ratio (TWR). The rule of the thumb assumes a launchpad TWR of roughly 1.4 to 1.5, which is considerd a good practices value for many kinds of rocket. If your launch stage has more oomph than that, turn over harder, and pass that 45 degree angle at 10km or even below; if your rocket barely manages to struggle off the ground, turn less aggressively, and go to 15 km or maybe even more for your 45 degree milestone.
 

Try to figure out what the longest burn you must do in one go at max throttle is.
For example, let's say you have a TWR of 0.1, and you wish to leave Kerbin on ion power. Your acceleration is roughly 1 m/s² (one tenth of Kerbin's gravity), and you need to expend 1000 m/s in order to escape. Once you have an escape trajectory, you can keep burning as long as you want, but until you have one you're still stuck in orbit, so escape is your effective limit. At this TWR it would take you 1000 seconds, or 16 minutes and 40 seconds, in order to escape. This is clearly impractical, because any burn larger than roughly 1/6th of your orbit is going to start making problems for you with imprecision. We'll assume that you are in a 36 minute orbit of Kerbin, so 1/6th of that orbit is 6 minutes. This will clearly be a periapsis kick sequence made of three burns. The first two burns will input 720 m/s, so there's no risk to encounter the Mun as you loop around for the final burn, so this is a good setup. You can fly with your spacecraft as it is.
Going futher with this example, now answer the question: on this mission, do you ever expect to have to make a burn that is longer than six minutes? One that asks you to expend more than, mass loss included, let's say 400 m/s worth of dV in one go? You're going to Jool, so an aerobrake-assisted capture burn is an option, which might well let you get away with this amount. After all, as long as you get any capture at all, even a super eccentric one, you've safely arrived. Afterwards, you can either lower this orbit through successive aerobraking/further burns, or tweak your orbit at apoapsis to target Laythe and aerocapture there.
The point of this thought exercise is this: once you have figured out your maximum expected burn length, you can design your spacecraft to the most mass-efficient specifications possible to supply full engine power for just that long and no more than that.
For example: to generate 216 Ec/s with RTGs, you need 288 of them, and that weighs 23 tons. However, if you brought only enough RTGs for 66 Ec/s, you'd only need 88, and they'd only weigh 7 tons. Then, you need to provide 6 minutes of 150 Ec/s worth of battery storage, or in other words, 54,000 Ec. Since all batteries weight the same - 1 ton for 20,000 Ec - you can calculate that that will weigh 2.7 tons. Now your final mass for your power solution is 7 + 2.7 = 9.7 tons, instead of 23 tons for straight RTGs.

Your issue is likely in the fins on the side-mounted boosters. Your craft goes in the same general direction as this one - a short-ish, draggy center core that is stabilized by fins mounted on side boosters which start flexing around the radial decoupler joint as soon as aerodynamic forces come into play. Now, you do also have fins on the center core, which certainly helps, but the fins on the SRBs may still resist active steering and begin flexing that way.
Check out my post in the linked thread for more detail, and a bullet-point list of recommendations that might help with rocket construction. They're not the only right way to do things, but they are a right way. Hopefully you can take something useful away from them
 
(By the way: confirming that the CoM is ahead of the CoL does not help on rockets. You are not concerned about the center of lift, but rather about the center of aerodynamic pressure. That is different, and unfortunately, the game does not have a means of displaying it for you. So basically, you must work with the CoM marker alone, and try to move it upward as best as you can while estimating where your rocket creates drag.)

Pre-plotted orbits for contracts can only be seen for the parent body you have currently focused. For example, if you are focused on Kerbin (the default tracking station view), you can only see pre-plotted orbits in Kerbin's SOI. If you change your focus to the Sun, you will be able to see pre-plotted solar orbits.
(When flying a vessel and being focused on that, it shows pre-plotted orbits inside the same SOI the vessel is currently in.)

If you are plotting your maneuver node with a retrograde burn at periapsis, as you describe, that is the most efficient orbit insertion possible. I'm afraid you are simply coming in with that much of a difference in velocity that you must cancel out. This typically indicates that you have not flown a Hohmann transfer, but rather something else. Either you launched well out of the transfer window, or you plotted a high energy transfer (burning really hard when leaving Kerbin to make the trip as short as possible).
You might however be able to at least salvage your mission to the point of being able to insert into orbit and later return to Kerbin. Because luckily, Duna has an atmosphere. That means you can aerobrake.
Make a maneuver node just a few minutes ahead of where your ship is right now, and play with the radial and normal sliders to try and move your PE closer to Duna. The atmosphere ends at 50km, so you want it to be closer than that. Of course, depending on how sturdy your ship is, and how insanely fast you come screaming past Duna, your ship may be torn apart by shock heating. So, after you have executed your maneuver to push the periapsis into the atmosphere, press F5 to quicksave. Now timewarp to your arrival and observe what happens. If you get torn apart, go a little higher next try. If you feel like you have ample breathing room, try going deeper.
You should probably align retrograde and fire your engines even while aerobraking. If you have to bleed off two km/s just to capture, a single aerobraking pass without engine support will not do it, especially if your craft is fragile.
Your goal should be to capture into any form of orbit. Even if it is crazy elliptic with the apoapsis way out near the edge of the SOI. Additional aerobraking passes will let you bring that down without spending any fuel.
Note that even a slight grazing of the atmosphere at these kinds of speeds is liable to rip off any extended antennas and non-fixed solar panels. If this would result in a loss of mission... well. You're kinda screwed. Your best bet in that scenario would be to not insert into orbit, but rather to burn at periapsis so that you end up in a solar orbit from which you can later get a Kerbin encounter, so at least you can return home.

There is a very subtle mistake in there, which is not easy to spot for someone new to the world of physics.
The notation is not just a "g" for "gravity". It is very specifically "g0", or written out, "standard gravity". That means this is not actually a variable where you put whatever gravity is for the place you are examining. No, it is a constant. Simply a number with a fixed value. It has the same value anywhere - the average value of the force of gravity at the surface of the planet Earth.
You see, the so-called Tsiolkovski rocket equation originally read: dV = Ve * ln(m0/m1). Where "Ve" is "effective exhaust velocity" - describing the speed at which the jet exits the engine.
Now, enter a bunch of rocket scientists. Some live in Europe, where they work in metric units. Some live in the US, where they use imperial units. They meet and want to compare notes. And suddenly, they notice that some of them measure this exhaust velocity in feet per second, and others measure it in meters per second. Confusion ensues. If only there was some way of measuring this that works out to be the same in both of these systems!
So they decided to split off the offending component that has the non-uniform unit into a known, well-defined constant, leaving all the variables to have units that are identical in both metric and imperial systems. By dividing a speed (something per second) by an acceleration (something per second per second), only seconds are left as a unit. This is specific impulse. It is a measurement artificially created by math in order to unify two disparate unit systems that (thankfully) could both agree on the definition of a second.
And the acceleration they chose to divide by? Standard gravity. Both sides knew this number. It is different in each measuring system. But if you have an effective exhaust velocity in imperial units, and you divide it by standard gravity in imperial units, you get specific impulse. If you have an effective exhaust velocity in metric units, and divide it by standard gravity in metric units, you again get specific impulse. Problem solved!
Thus, Ve * ln(m0/m1) = Isp * g0 * ln(m0/m1).
As KSP usually works in metric units, your go-to value for g0 is 9.80665 m/s².

You're violating the golden rule of rocketry: "heavy stuff at the front, draggy stuff at the back".
Specifically, you have a high amount of parts and assorted greebling sticking out your upper stage. The blunt, uncapped docking port is an absolute no-go - put a nosecone on that, you can eject it once you leave the atmosphere. Additionally, there's that gap in the rocket where the stages connect. I cannot quite understand what is going on there, but depending on how it's set up, it's a major candidate for crippling drag.
I see you have the center of lift marker activated. Unfortunately, this marker does not actually show the center of aerodynamic pressure that is relevant for rocket stability. The game does not feature a way to display this to you. You'll have to work with educated guesses based on the CoM location, and test flights to verify your guesses. In your case, those test flights tell you "nope, you guessed wrong".
You can use a fuel flow trick to force the CoM a little further up in flight, by configuring the fuel tanks on your first stage so that they have decreasing priority from the bottom up. That is, if your fuel tank priority is, I dunno, 30 by default, then leave the bottom-most fuel tank at 30, set the one directly above that to 29, the next one to 28, and so on. This will make the bottom-most tanks drain first, leaving the others completely full. As a result, the average Center of Mass ends up higher than if all tanks were draining equally at the same time.
This is however only a band-aid. It can make the difference between slightly unstable and barely stable. It will not fix an unflyable rocket on its own.

Yes, it works like that. You can make such satellites, and they will bounce the signal back to Kerbin for you.
There is two reasons you're only seeing direct connections to Kerbin right now. One, Kerbin's ground based antennas (the Deep Space Network, DSN, after the real life system of the same name) are several orders of magnitude more powerful than what you can carry on your spacecraft. Antennas automatically search for the most high-quality path home they can find. Because the DSN is so powerful, this highest quality path is almost always "just talk to Kerbin directly". Two, not all antennas can bounce a signal. There are two different kinds: so-called "direct" antennas, and so-called "relay" antennas. Direct antennas weigh and cost less, but cannot route other spacecraft's signals through them. Only relay antennas can.
The first relay antenna you get is the HG-5. It is pretty weak, though. You'll want to put two or more of them on your relay satellites, and the landed vessels on the Mun will need a dedicated antenna of their own (not just the integrated transmitter in every pod or probe core). Alternatively, you could use the RA-2, which is plenty powerful for all your Mun relaying needs. But it takes more research to unlock it.
More information: https://wiki.kerbalspaceprogram.com/wiki/CommNet
 
Also correct. The orientation of your control point matters.
That said, you might be able to right-click the probe core and set it to reverse control in the part action window. I'm not sure if that option is always available, or only if you have Advanced Tweakables toggled on.

Hmmm. I see. Alright then, here's some very basic rocketry tips:
1.) Train your pilots. If you are playing with the Kerbal level-up experience system enabled (meaning, Kerbals are not five-star by default), then you want to send a few pilots into Kerbin orbit and back before you head anywhere else. Orbit around Kerbin is enough to get them to level 1, at which point they learn "SAS Hold Prograde". That means you can tell your Kerbal pilot to help you fly by trying to always keep the nose pointed in the direction of travel. You will find this invaluable while launching. There are also probe cores that have this ability, but unless you are playing sandbox mode, you have to put in some research effort to unlock them.
2.) "The golden rule of rocketry": heavy stuff at the front, draggy stuff at the back. Think of an arrow. The compact, pointy metal head is right at the tip. The light feathers that catch a lot of air are at the back. In technical terms, the center of mass is ahead of the center of pressure. This causes passive stability. A well-built, passively stable rocket can fly to orbit without turning on SAS and without touching the steering keys - only via managing the throttle. Though admittedly, in practical application not many player-built ships will be quite that stable, because payloads tend to be light and fuel tends to be heavy, which makes it hard to achieve this perfect distribution. Rather than taking this rule too far, take its opposite, and keep it in your mind as what not to do. Do not put wings or fins on the nose of your rocket, for example. And when you find yourself with a rocket that will not fly straight no matter what, then think of this rule when trying to find the reason.
3.) Single-size designs. A major source of instability is flexing joints, and few joints flex more than stepping down to a smaller part size in the middle of a stack and then stepping up again. This also causes drag, by the way, which (as we just learned) is bad if it happens towards the front of the rocket. As you progress in the game, you will gain parts (service bays, fairings, and engine plates) that allow you to shield smaller parts in the envelope of a larger one.
4.) Single-stack designs. Another thing that wants to flex like Dwayne Johnson hopped up on caffeine is a small radial decoupler carrying a large side booster producing massive thrust. You can use struts to try and fortify such boosters, or you can turn on advanced tweakables and simply magick away joint flexing via rigid attachment and autostrutting (if you do not feel cheaty by doing so), but you can also simply not have the problem in the first place by building your rocket without large radially attached boosters. The main limitation you have here is the thrust output of the launch stage engine. However, it is still easily possible to reach orbit on a single-stack, 1.25m size rocket. It is also possible to perform a Mun flyby and return to Kerbin on a single-stack, 1.25m rocket. Though to pull that off, you may need to get some practice in the next item on this list.
5.) Downsizing. Contrary to what you may think, bigger isn't always better. You will learn about this as you get deeper into the game (the keyword is "Delta-V"), but for now, what you need to understand is: how far a rocket can go does not directly scale with its size. The only thing that counts is the mass of the fuel you carry compared to the mass of "not-fuel" you carry. And no matter if your rocket is 10 meters in diameter or just 1 meter - if this ratio is the same, then both rockets will fly the same distance. So the takeaway should be: you must minimize everything that is "not-fuel". Take the fewest number of parts that are not fuel tanks as is possible. And if you have multiple parts that can fulfill a certain job you need done, pick the one that weighs the least - unless this causes other problems, such as having the wrong size. Besides helping with going further, this also helps with rocket building in general - if your rocket is light enough, you do not need extra boosters to make it move! And without extra boosters, you don't get flexing decoupler joints, which means your rocket won't go out of control on ascent...
To illustrate my point, let me show you the rocket I used for my initial Mun flyby the last time I played Career (well, Science mode, actually):
From the top down, that is: a MK-16 parachute, a MK1 command pod, a 1.25m service bay, a TD-12 decoupler, two SC-9001 "Sciene Jr." bays, a FL-T200 tank, a FL-T400 tank, a LV-909 "Terrier" engine, another decoupler, another four FL-T400 tanks, and finally a LV-T30 "Reliant" engine. Inside the service bay, there are two mystery goo containers, two thermometers, two barometers, and two Z-100 batteries.
Super simple. No radial boosters. No size mismatches. No struts. No advanced tweakables shenanigans. The whole thing weighs just 15.4 tons and contains just 23 parts, 8 of which are science instruments. It can be built and launched in career mode without needing any building upgrades whatsoever, and no tech tree node more expensive than 45 science. It actually has a healthy surplus of fuel for the Mun flyby mission - you could technically slim it down a little more still, but then again, you can never go wrong with some safety margin.
It is not 100% passively stable, but perhaps 99%. Adding four basic fins to the bottom will make it perfectly passively stable - a bit too stable for my tastes even, so stable that it becomes hard to make it turn in the lower atmosphere. Which is why I prefer it without fins.

At face value, the ratio is exactly what you're looking for.
Take any old liquid fuel engine: it has a PROPELLANT node for LiquidFuel at a ratio of 0.9, and one for Oxidizer at a ratio of 1.1. You just add them together. For any 0.9 + 1.1= 2.0 units of mass that the engine consumes, 0.9 units will be LiquidFuel, and 1.1 units will be Oxidizer.
It's important here to read carefully: I said "any two units of mass". Because the ratio is not about the unspecific "units" of a resource in a tank*. It's about a mass flow rate. Specifically, the mass flow rate that you calculate out of the relationship between thrust produced and specific impulse. That will tell you that the engine must have a throughput of XYZ kg/s of mass per second. The ratio then simply determines what percentage of each resource makes up that mass flow. It would work just the same way with a tripropellant engine.
And then you look at an electric engine, and things get weird.
Remember what I said about the ratio being about a mass flow rate? Well... it just so happens that ElectricCharge doesn't have mass. This is why you cannot make a pure electric engine like an EMdrive in KSP simply by copying the Dawn engine and removing its XenonGas propellant, leaving EC as the only remaining input. Such an engine would produce no thrust, because it would have no mass flow. Instead, electric engines like the Dawn define a ratio between a massless propellant and one that has mass. But how can that possibly work out in math?
Look at ArgonGas in the config snippet you quoted. It has a ratio of 1.0. Can you guess what that means?
The answer: no, you can't.  Because in this configuration, the ratio assigned to ArgonGas does not matter. It has no meaning. It can be literally any number you want it to be. The result is always the same: since EC has no mass, the engine will field its entire mass flow rate with ArgonGas alone. Whatever the calculation of thrust and Isp says the engine must consume, that's how much ArgonGas it eats. The ratio number doesn't matter. Changing it doesn't change the ArgonGas consumption in any way, shape or form. Nertea simply decided to set it as 1.0 because that is as good a number as any other... or, perhaps, a better number than any other if you intend to do multiplication and division with it.
Because now we get to EC. It also has a ratio specified. But since the entire mass flow of the engine is already fielded by ArgonGas, it should be meaningless...? Except it isn't. Because the amount of EC the engine demands supplied is calculated off of the ArgonGas flow rate - pay attention now - measured in resource units, not mass units. Everywhere else, KSP works with mass flows; but in the case of massless resources alone, it works with resource units.
 
As an example, let's take the stock Dawn engine, because I just so happen to have all the relevant numbers I need for it on the KSP wiki:
4,200 seconds of specific impulse in vacuum. We convert this weight-based unit into a mass-based unit by multiplying in standard gravity:
4,200 s * 9.80665 m/s² = 41,187.951 m/s ("effective exhaust velocity"). This is dimensionally equivalent to thrust divided by the mass flow rate, and the engine develops 2,000 N of thrust in vacuum, so:
2,000 N / x = 41,187.951 m/s   --->  2,000 N = 41,187.951 m/s * x   --->  2,000 N / 41,187.951 m/s = x   --->  x = ~0.04856 kg/s mass flow rate.
One resource unit of XenonGas is 0.1 kg, ergo: 0.04856 kg/s / 0.1 kg = 0.4856/s XenonGas consumption measured in resource units.
The Dawn engine has an ElectricCharge ratio of 1.8, so: 0.4856/s * 1.8 EC = 0.87408 EC/s .
But wait! Squad decided to define the XenonGas ratio of the Dawn engine as 0.1. So we have to additionally divide by this ratio to get our final number. See now why Nertea chose 1.0 instead, even if the number is meaningless for the propellant flow rate?  
0.87408 EC/s / 0.1 = 8.7408 EC/s.
And if you look it up in an unmodded game, that's exactly what the Dawn engine says it needs.
 
 
*) However, coincidentally LiquidFuel and Oxidizer have the same mass per resource unit, so it just happens to work out to the same in resource units anyway. In this case.
 

I know of one bug (or perhaps unavoidable occurrence) that causes parts to not be shielded:
When the part that's supposed to do the shielding is the root part of the craft. For example, if you make a fairing base the root part of a rocket, the fairing will not shield the parts contained in it. The same is very likely true for a cargo bay.

Whenever your trajectory looks buggy, and you have HyperEdit installed, remove HyperEdit and check again before doing anything else.

Commnet range is simply SQRT( antenna power of the first partner * antenna power of the second partner ). If you have two craft with identical antennas trying to communicate, this simplifies into SQRT(antenna power)², which in turn simplifies into antenna power itself.
The antenna power of an RA-15 is 15,000,000,000, so the maximum range two RA-15's can communicate with one another is 15 gigameters, AKA 15 million kilometers.
The semimajor axis of Eve is roughly 9.8 Gm. The semimajor axis of Kerbin is roughly 13.6 Gm.
Closest approach: SMA_Kerbin - SMA_Eve = 13.6 - 9.8 = 3.8 Gm
Largest separation: SMA_Kerbin + SMA_Eve = 13.6 + 9.8 = 23.4 Gm
Therefore, your relay system using RA-15's can link back home from Eve some of the time, but not all of the time. Eve is simply too far away from Kerbin in your save right now, but it will eventually return to being close enough again.
If you want to have a connection with Eve at all times, you have various options. The first and most obvious is to rely more on the DSN. It seems like you have extra ground stations disabled. If you did not, you would already have a stable link to Eve at all times. This is because the DSN, being a ground-based installation without limits in power and dish size, is absurdly powerful. The level 3 DSN has 250G antenna power. A RA-15 can talk to it from more than 61 gigameters away. This setup mirrors real life, where satellite based communication networks are pretty much nonexistant because the sheer power of ground-based antennas render them completely pointless.
Of course, you may have the extra ground stations disabled for a reason, and actually want to play with commsat networks. In that case, you have no choice but to increase the antenna power of your satellites. Thankfully, due to the way the math works, it's enough for you to upgrade one side of the equation only. Upgrading both sides helps even more, but for the closer planets like Eve, it's probably not necessary.
Upgrading your Kerbin constellation to RA-100's will boost your Eve-Kerbin link to SQRT( 15G * 100G ) = ~38.73 gigameters. With Eve's maximum distance to Kerbin at just 23.4 Gm, you can see that you don't need to replace the RA-15's at Eve. You still get a permanent link. Upgrading the Eve constellation as well would improve the signal quality, but nothing more.
If you don't have the RA-100 yet, you can also improve your satellites' antenna power by stacking multiple antennas. The equation for vessel antenna power is:
Vessel Antenna Power = Strongest Antenna Power * ( Sum of Antenna's Powers / Strongest Antenna Power ) ^ ( Average Weighted Combinability Exponent for Vessel )
...which looks super complicated, but in practical application ends up being far simpler than you think. As long as you only stack the same kind of antenna, it simplifies into (number_of_antennas^0.7) * antenna power.
Assuming you replace your Kerbin constellation with commsats that have three RA-15's each, that would give them an antenna power of 15G * (3^0.7) = ~32.4. Plugging this into the commlink range equation, you get SQRT 15G * 32.4G ) = ~22.0 gigameters. Meaning you can talk to Eve for 95% of the time, only dropping your link at the point of furthest separation. If your Kerbin commsats carried four RA-15's each, you'd have 100% link uptime.
Stacking RA-100's like this will eventually be your only way to maintain permanent links to really far out places like Jool and Eeloo without relying on the DSN.

I think I once wrote a step-by-step guide on how to use Alexmoon's planner for someone. Let me see if I can find it again...
 
EDIT: Okay, I only wrote about how to make a node with the resulting information, not how to use the planner itself. Here's that first part:
Make sure your spacecraft is in a circular, equatorial Kerbin orbit, and set the Initial Orbit altitude on the website accordingly. The planner makes the assumption that you start in such an orbit, because it makes the math faster and easier; if you try to execute the calculated transfer from a highly inclined or eccentric Kerbin orbit, you will miss your target. You can make the planner calculate from an eccentric and/or inclined orbit, too, but you have to manually input all the parameters of that orbit through the Add Body menu. And that's both tedious and requires you to have a mod installed that shows you these numbers ingame in the first place, because KSP won't show them you by default. If you are already in interplanetary space, you unfortunately also need to manually input your orbital parameters this way. Choose your destination. If you are planning a flyby or aerocapture, check the "no insertion burn" box; if you want to enter orbit around your destination, leave it unchecked. If you want to enter orbit, enter a useful value for Final Orbit. On bodies with an atmosphere, you want this to be 5-10 kilometers above where the atmosphere ends (you can look up that number ingame, or on the KSP wiki). On bodies without an atmosphere, simply enter 10. Set Earliest Departure to your current ingame date. Select "Ballistic" from the transfer type dropdown menu (though I believe that's also the default). Sometimes it's cheaper to do a midflight course correction, but I personally tend to not want to bother. Click on Show Advanced Settings to bring up two additional settings. They are pre-filled, and do not need to be adjusted in 90% of all cases; but once you undertand how to use the planner, you can use Latest Departure and Time Of Flight to narrow down your results more. Press Plot It! In the colorful plot at the bottom, travel time is on the vertical axis, and departure date is on the horizontal one. <--- This is really important for reading the plot. Make sure you understand it fully. Mouse over the plot; you'll see a dV cost next to your mouse cursor that represents the particular date/traveltime combination you're hovering over. The planner will have pre-selected the cheapest solution it can find between your specified earliest and latest departure dates. This is the next "transfer window" - the moment in time where the celestials are aligned just right. This solution will always be a Hohmann transfer, or as close to one as orbital alignment allows.
You don't have to fly in that transfer window. You can fly at any time you want, and spend more or less travel time, as dictated by your whims and needs; but you will notice that those other departure date/travel time combinations cost more dV. That is because you are either flying "out of window" and/or are performing a "high energy transfer", and have to spend extra dV to force an encounter. In some cases, though, the planner will show you multiple solutions marked in deep blue. That simply means that there are multiple Hohmann transfer windows of similar good quality for you to choose from in the near future.
Either accept the preselected solution, or find a solution that's suitable for your needs by clicking on that spot on the graph. If you want, you can adjust your Latest Departure and Time Of Flight in the advanced settings mentioned before and recalculate, to make the plot more focused on specific areas. When you have found your solution, click on it, then press "Refine Transfer" at the bottom.
As one last step, click on the little blue "i" marker next to the Ejection dV reading in the results list.
Now you can finally proceed to setting up your node in the game.
 

If you almost immediately stage the Sparks after takeoff... have you questioned why you even have Junos in the first place? Jet engines only make sense if they can run for a while on their own.
Just for the sake of iteration, maybe try a plain rocket SSTO? You can toss all air intakes, save the mass of the engines themselves, can replace the LF tank with an LFO one your rockets can make use of...

No, it does not. You can only ever be in one SOI at a time. "Sphere of influence" means that the current celestial body's influence is dominant over all others in this region; it makes no logical sense to say "The Mun is the dominant body, but so is Kerbin".
You can easily confirm this ingame, by simply going from one SOI to the other while observing the projected result of converting experiments. Take science from high Kerbin orbit while you are on an intercept course for the Mun. Check how much data you get before and after you switch SOIs. You will see that you lose the bonus as soon as you enter the Mun's SOI. And you will see the same result when you take science from the Mun and then leave its SOI.
 

There is a potential problem where this can happen under a specific set of circumstances. Namely, your vessel must have very little battery buffer, and you must be running at very high timewarp, and you must have constant Ec drain.
What happens is that energy production and drain are multiplied by the time warp factor. If you are draining 1 Ec/s, that means you're draining 0.05 Ec per physics step. If you go to 10x timewarp, you're draining 0.5 Ec per physics step. If you go to 1,000x timewarp, you're draining 50 Ec per physics step. If you do the maximum of 100,000x, you're draining 5,000 Ec per physics step.
So what happens when you want to draw 5,000 Ec in a single step, but your ship only stores 800 Ec? The storage is set to zero, and the consumer notes that its request could not be fulfilled, and so it reports itself as "out of power". Then your solar panels come along, and perhaps generate 120,000 Ec in a single step. They puts 800 of that into the storage, and discard the rest because it won't fit. Then your consumer comes and requests another 5,000 for the next physics step. Again there is only 800 available, so the consumer notes itself "out of power" again.
And so on and so forth.
This is a limitation within KSP itself and has nothing to do with mods. it doesn't manifest much in the stock game because there are very few things that have a passive energy drain. You have two solutions available to you that I know of:
1.) Build each spacecraft so that it has a minimum battery storage of (passive drain / 20) x (highest timewarp factor)
2.) Install the mod Near Future Electrical. It includes a small experimental plugin, called DynamicBatteryStorage, which tricks the game into thinking that your spacecraft's battery capacity scales with the timewarp factor in order to circumvent this problem. (I don't know if you can use DynamicBatteryStorage without the rest of NF Electrical present. You'd have to ask Nertea.)

Peruse the image in the following thread:
If you have questions on how to read it, don't hesitate to ask But it's really quite simple. You just add up the numbers for every step along the way that you need to traverse.
As for an Eve assist to Duna? I wouldn't bother. Getting a Duna intercept costs barely 100 m/s more than getting a Minmus intercept. Heck, if you need to force a plane change at the wrong time, Minmus might cost just as much as Duna. Also, Eve costs roughly the same as Duna, too. So you wouldn't even save anything - in fact, because your transfer orbit would be more elliptical, you'd need to pay more dV to capture at Duna.
 

Yes, they are.

You can't get a link because you're not in range for a link See here:  http://wiki.kerbalspaceprogram.com/wiki/CommNet
Antenna range is always a function of the power level of both endpoints. Range = SQRT ( Antenna Strength 1 * Antenna Strength 2 )
In case of a HG-5 talking to a Communotron-16, that comes out to:
Range = SQRT ( 5,000,000 * 500,000 ) = 1,581,138.83 meters.
Geostationary orbit around Kerbin is roughly 3,463,330 meters. in other words, more than twice as far away as you have range.
 
Your HG-5's can talk to the ground stations at that distance because those ground stations are extremely powerful. The Communotron-16, however, is not very powerful. In fact, it is the weakest antenna in the game. The HG-5 is slightly better, but not by much on the scales of space. The two of them just don't have the power to hear each other across that kind of distance.
If your low orbit spacecraft also had a HG-5 instead of a Communotron-16, then you would have 5,000,000 meters of effective range between two HG-5 endpoints, and you could talk to your orbiting constellation.
 

You can keep asteroid signatures from disappearing by tracking them. To do so, enter the tracking station and select the signature. You should now have a blue "track" button in place of where the green "fly" button normally is. Press that, and the signature is added to your list of tracked vessels. While being tracked, it will not disappear anymore. You can stop tracking it at any point you like, as long as you have not already visited it (which turns the signature into a permanent object).

You can stop tracking asteroids as long as they are just signatures.
However, as soon as an asteroid comes close enough to the player that it's worth showing on the UI (probably within 100 km), the asteroid itself is created as a vessel, consisting of a single part (a potatoRoid part). It has to be a vessel in order or the Klaw to work (it's essentially a docking maneuver). Once it has been created as a vessel, it stays a vessel forever, regardless of whether or not you decide to attach somethign to it.
You cannot stop tracking vessels other than through terminating them.
Therefore, you are limited to terminating asteroids that have already been created as vessels.
 

@Tex_NL that equation calculates dV expenditure at a given thrust over a given period of time. It doesn't calculate dV available for use.
 
@themonk RCS thrusters are just tiny engines, like any other rocket engine. So you can use the Rocket Equation: dV = isp * 9.80665 * ln(wet mass / dry mass)
Insert the Isp of the thrusters (260s in vacuum IIRC). Plug in the current mass of your vessel (visible in map mode via the info button) as wet mass. Figure out the total mass of monoprop you're currently carrying (4 kg per unit), subtract this from your wet mass, and put the result in as dry mass.
Example: a 5-ton vessel carries a single FL-R25 monoprop tank with 250 units. So your Isp is 260, your wet mass is 5 tons, and your dry mass is 5 - 0.004 * 250 = 4 tons.
dV = 260 * 9.80665 * ln(5 / 4) = ca. 569 m/s
 

I'm afraid to tell you, good sir, that while what you are trying to do is certainly possible (dV budget permitting), it's no easy feat. You will need to do maths and guesstimate some values and use a mod and use an external tool to pull it off, and you will have to do it on the fly - you cannot plan the return transfer before you have executed the transfer burn to Duna. Which is why I said "dV budget permitting". There's a chance that you'll find yourself without enough dV left for an expedited return after you make your Duna transfer burn, because the cost of return depends 90% on the initial transfer. Therefore, you need to make a best guess at how much to throw at the initial transfer to accelerate it, and how much to keep in hopes of being able to also accelerate the return. There exists no tool for KSP which can precalculate this for you - I recommend a named quicksave for trial and error purposes.
On to the how-to, then:
1.) Go to https://alexmoon.github.io/ksp/
This tool is available as an ingame mod, but you'll be using the website, because you're going to need its advanced features later, which the ingame tool doesn't have. For starters, use it to plan a high energy transfer to Duna suitable for your desired departure date and dV budget. Make sure your probe is in a circular, equatorial Kerbin orbit, and set the Initial Orbit altitude accordingly. Check the "no insertion burn" box since you're planning a flyby, set Earliest Departure to your current ingame date, select "Optimal" from the transfer type dropdown menu, click on Show Advanced Settings, and enter a Latest Departure to your taste. Setting this latest departure date close by allows you to constrain the result space and keeps the planner from suggesting the next ideal window instead of a suitable near-term solution.
2.) Let it calculate a solution. In the colorful plot at the bottom, travel time is on the vertical axis, and departure date is on the horizontal one. Mouse over the plot; you'll see a dV cost next to your mouse cursor that represents the particular date/traveltime combination you're hovering over. Find a solution that's suitable for your needs. If you want, you can adjust your latest departure time and the travel time window in the planner settings and recalculate, to make the plot more focused on specific areas. When you have found your solution, click on it, then press "Refine Transfer" at the bottom.
3.) Now, make a maneuver node using the information given and execute it.
4.) Your probe is now on a flyby trajectory past Duna, putting it into a solar orbit afterwards. It is this solar orbit from which you must return to Kerbin. Therefore, you need to configure Transfer Window Planner to recognise this orbit. This is where it gets complicated.
Press "Add Body". Switch body type to Vessel, give it a name. Note down what the solar apopasis and periapsis altitudes will be after your Duna flyby. Select the Sun in map mode, pull up its info window, and look for the radius. Add the Sun's radius to both apoapsis and periapsis, and use only the modified numbers for all further colaculations. Calculate your semimajor axis by adding together your apses and dividing by 2. Also calculate your eccentricity = 2 / ((apoapsis height / periapsis height) +1). Put these numbers into the planner. Mouse over the periapsis, note how much time it takes to arrive there, and add that time to the current ingame date. Try to be precise despite the numbers constantly changing. Enter the date you calculated under "Time of Periapsis Passage" in the format "year/day hh:mm:ss" - for example "1/235 04:53:18".
Inclination is a problem. You can easily determine your current inclination after your departure burn by targeting the Mun, which is perfectly equatorial; but, your Duna flyby will change your inclination. Especially if it's a close flyby, and especially especially if Ike is getting in the way (which you know it will). I think you'll have no other choice than to check your current inclination against the Mun, then eyeball how your post-flyby solar orbit differs from your transfer orbit. I know it's easier said than done, but try to be precise.
That leaves two fields: the longitude of ascending node, and the argument of periapsis. Duna has an inclination relative to Kerbin, so your orbit does too, so they must be specified. Unfortunately, there is no way for you to find them for your final solar orbit. The best you can do is to use a mod of your choice (KER, MechJeb, etc) to display them for your current transfer orbit. They will be wrong for the final orbit, especially for close Duna/Ike encounters, but there's no way around that which I know of. And ideally the error is small enough to not influence your final return trajectory cost by more than a few hundred m/s. It's because of these two errors that I told you to be as precise as possible with the other values... you want to avoid cumulative errors growing out of control.
5.) Save your custom vessel orbit, and select it as origin. Set destination to Kerbin, and check No Insertion Burn (you don't have dV to spare). Look at your probe's trajectory, find the time to encounter Duna's SoI, add that to your current ingame date, and set that as Earliest Departure. Set Latest Departure a hundred days later. Transfer Type optimal, and calculate.
Now is the big moment: the planner will have preselected the cheapest possible route in this time window. Is the dV cost within your probe's remaining dV budget? If yes, you can attempt to find the shortest possible transfer your budget allows for, tightening the Latest Departure and Travel Time settings for more precision. If not... well, you can attempt to relax the settings to see if you can return at all. But most likely, you'll have to reload and do the whole thing all over again with less dV spent on the initial transfer.
6.) If you have a result: try to make a node at the appropriate time. Do you get a Kerbin encounter? I'm willing to bet you don't, because your origin orbit wasn't set up correctly. The question is, what (and how much) do you have to change to get your encounter? This is left as an exercise to you; I cannot give advice here. You must rely on your skills in maneuver node editing. Once you have your encounter, check again: can you still afford it? Remember, just an encounter alone isn't good enough, it must also intersect Kerbin's atmosphere (or leave enough fuel for a later course correction to that effect). If not, try moving the node to earlier or later in the orbit, and see if that makes it cheaper. When all else fails, reload and repeat.