Streetwind

No way to see commnet connections, no. The system is borderline unimplemented. I'm honestly surprised it's working at all - it serves no purpose at the moment and wasn't mentioned on any roadmap.

Right... so, there are two things going on here.
One, your center of lift is too far behind the center of mass. You want to have them roughly on top of each other, just a little bit behind. If it's too far behind, all the lift goes towards lifting your tail only, while nothing carries the nose. This makes the front of the plane flop forwards/downwards.
Additionally, you have a single engine mounted on top, not in line with the center of mass. This means the engine thrusts past the CoM, thereby inducing torque that tries to turn the entire plane around the CoM like a jet-powered spinning top. In your case, that torque goes into the same direction as the plane's natural inclination of flopping nose down due to the misaligned CoL, so both effects add to each other and ensure you cannot ever pull your nose up.
Take a look at this guide. It's for KSP1, so disregard any comments about the aero/physics model, but the basic design principles still hold true in KSP2.
 

Oh yes, there are numerous bugs with the dV display in the editor. For example, the mass of Kerbals inside cockpits is counted incorrectly (added only to wet mass but not to dry mass). Then, using multiple different engines on the same stage appears to cause the editor to report significantly less dV than there actually is (I had this effect with a Dart on the bottom of a couple tanks, to which I then added a pair of Thuds. Which halved the reported dV in the editor, but the vessel still made orbit just fine).
You've just found another. And there are more besides.
If you're ever unsure about whether the editor is showing you the truth, you can always sanity-check it by solving the rocket equation yourself. For a single stage, it's not even complicated.
Detach everything below the stage you want to check, but leave everything above in place Note down the entire vessel's mass, let's call it m0 Empty all the fuel tanks that this stage is supposed to empty during its operation Note down the entire vessel's mass once again, let's call it m1 Bring up the Windows calculator (or equivalent tool on your OS of choice). You may need to set it to scientific, if it isn't already. Divide m0 by m1 Press the "ln" key once (that's the natural logarithm, if you're wondering) Multiply by 9.80665 Multiply by the vacuum Isp of the engine(s) on this stage The result is this stage's true vacuum dV The only part where this can get complicated is if you're mixing engines with different Isp values on the same stage. In which case you first need to calculate the average Isp, which unfortunately needs to be weighted by thrust contribution. So, for each individual engine, you would multiply its Isp by its thrust, and write that number down. After doing that for all engines, you sum up all these numbers, and then divide the result by the total thrust of all engines combined.
If your own math is one or two m/s off, don't sweat it. That's an acceptable error. If your result is a two-digit number or more off, then something's fishy. Either with the editor, or with the math you used.
 

You're touching on what's colloquially known as The Golden Rule Of Rocketry. Which is: heavy stuff at the front, draggy stuff at the back. Think of an arrow shot from a bow. It has the heavy metal arrowhead at the front, and the fletching feathers at the back.
In technical terms, you're asking after the relationship between the center of pressure (the sum of all aerodynamic forces acting on the rocket) and the center of mass (the point on which the entire rocket's mass is balanced).
Because a given body pivots around its balance point, you can quite literally think of the center of mass as a hole through which you drive a nail to pin a model rocket to a wall. The model rocket will hang there, until an external force makes it pivot around the nail. An external force like, say, you blowing a strong wind at the dangling rocket from the side.
Imagine your model rocket has a set of big fins at the back, and nowhere else. The strong wind will push against all parts of the rocket. Because the fins are big surfaces that catch the wind, there are a lot more aerodynamic forces acting on the bottom end of the rocket than on the top. As a result, the fin equipped bottom end will be pushed away from the source of the wind. The model rocket pivots around its balance point, turning its nose into the wind. This is a configuration where the center of pressure is below the center of mass, and as you can see, this rocket really wants to fly straight into the airstream. The harder the oncoming wind blows, the harder the rocket sticks to flying straight as an arrow. We call this rocket passively stable, and we need to use active steering devices like thrust vectoring to make it change directions.
Now, imagine instead that your model rocket has a set of big fins on the nose, and none on the bottom. Like SpaceX's Starship. Now, the wind coming from the side pushes the top end of the rocket more than the bottom end, and the model pivots around its balance point, going engine-first into the airstream. This is a configuration where the center of pressure is above the center of mass, and it creates a rocket that really wants to reverse itself at the first possible opportunity. The harder the oncoming wind, the more aggressively it tries to reverse itself. We call this rocket passively unstable, and to fly it, we need to constantly fight its urge to flip until we are out of the atmosphere. Starship's first flight test ended in the whole skyscraper-sized rocket doing cartwheels in midair in the most Kerbal fashion because it destroyed too many of its engines by shattering the launchpad, and thus had too little TWR, flew too shallow, started pointing away from prograde to try and correct, and subsequently reversed itself because it is passively unstable.
When building rockets, you want them to have their center of pressure below their center of mass at all times, even as its fuel tanks drain. Then your rockets will be passively stable, and the atmosphere suddenly becomes your friend instead of your enemy. You want a heavy front, and you want a draggy rear. Which may seem like a tall order, given that the front typically features draggy fairings, and the heaviest part of the rocket - the first stage tanks and engine section - are all the way at the rear. But that is the challenge you, as a rocket engineer, must solve in order to succeed.

You can use struts (a part found at the top of the Structural tab) to stabilize the boosters. Attach the strut from the tip of the booster to the core of your rocket.
If you attach a SRB to a decoupler near the top of the SRB, that's a very unstable configuration. Have the decoupler halfway up the booster. Or, have it down at the bottom while using a strut to stabilize the top.
Additionally, try to avoid control authority on the side boosters. Meaning: if it has a gimbal, turn it off. If you have fins attached, remove them. Attach fins to the core stage if you feel you need some.

Yes. a - c is the periapsis altitude, and 2a - (a - c) is the apoapsis altitude.
No, because an orbit needs additional parameters. For a given AP/PE pair, there is an infinite number of possible orbits. You need to narrow it down further by supplying an inclination, and a longitude of the ascending node. That still leaves you with a technically infinite number of solutions, albeit in a narrow band. Specifiying the argument of periapsis finally results in a single, precisely defined orbit.
https://en.wikipedia.org/wiki/Orbital_elements
 

Rendezvous are a multi-step process, and it's hard to figure out how to help you if your description of what went wrong isn't a bit more detailed.
Generally, it involves five steps: (1) get into a similar orbit, (2) match inclination, (3) match the orbit, (4) phase the orbit, (5) match the target. However, the order you perform these steps in isn't set in stone. Even "get into a similar orbit" doesn't necessarily have to come first, despite what it might sound (but to be fair, in most cases it does come first). You make the call what you want to do next. It is not uncommon to do some steps more than once, edging a little closer each time.
As an example, let's take a rescue contract which is in an 80km by 90km low Kerbin orbit with zero inclination. If I were to do this rendezvous, I would...
(1) ...start by launching into a similar, but intentionally not too similar orbit. Something like 75km by 75km. The more the semimajor axis (think average altitude) of my orbit is different from that of the target, the quicker it is to phase the orbit, but the lower the precision will be. I will typically time this launch so that the target spacecraft is directly overhead the launch site, so that I insert into orbit slightly behind it, but it's not a necessity - it just makes the process faster.
(2) I'll select the marooned spacecraft as my target, so I get an AN/DN marker. I'll make a maneuver node there with a plane change to cancel out any minute deviations from 0° inclination that I may have picked up during launch. Even a tiny inclination mismatch can screw with some of the later steps.
(3) Then I will look at where the target spacecraft is along its orbital path, relative to where I am. Because I am in a lower orbit, I want to be behind the target (hence my launch timing in step 1). Lower orbits are faster, so I will be catching up to my target from behind. Now a judgement call must be made: am I close enough behind? Not close enough? Too close? The answer depends not just on the current position, but also on the difference in orbits. The greater the difference in SMA, the faster I will catch up with the target on each orbit around Kerbin, so if I am really close to the target but the orbits are too dissimilar, I will overshoot. It is best to err on the side of not being close enough, both in your launch timing, and in selecting how close you make your approach orbit to that of the target.
(3a) To help this judgement call, I will make a maneuver node somewhere ahead of me, and give it enough dV to cross the target orbit. This will display a close approach marker, and also fill in numbers in the rendezvous tab of the flight data display in the lower left. I will then select the maneuver node and toggle it one orbit ahead into the future. The close approach marker and data will change. If the marker jumped ahead of the intersect, I am too close, and must either force a rendezvous immediately, or pass the target and wait a week or two to come up behind it again, or pass the target and then assume an orbit higher than the target so that it will begin catching up to me instead and I can do the rendezvous from the other side. If the marker is still behind the intersect, I will push the node another orbit into the future.
(3b) The goal is to get myself into a position where the maneuver node shows a close approach marker more or less on top of the point where the orbits intersect at some point in the future. There will typically be two such points, and having a close approach at either one is fine. This whole process of one spacecraft catching up with the other is called "orbit phasing", and its purpose is to get both spacecraft to arrive at the same point in space at the same time. It doesn't matter how well I match the target orbit if I am not phased correctly and thus will never be in the same place as the target at the same time.
(4) Most often, I will not get a close approach marker on top of an intersect, no matter what I do. I just blindly picked my initial orbit, after all, so there's no guarantee that it is suitable for rendezvous. If this happens, I must match orbits better. I will typically phase the orbit until I am quite close behind and in danger of overshooting soon. Then, I will make a maneuver node next to the target orbit's periapsis, and make a burn to roughly match apoapsis. My orbit will turn from a 75 by 75 km orbit into something like a 75 by 89 km orbit (the target being in an 80 by 90 km one as you recall). Because I am doing this burn next to my target's periapsis, this means I am not just matching SMA more closely, but my eccentricity will also align with the target's eccentricity (the so-called argument of periapsis will match).
(4a) After this burn completes, I will once again make a maneuver node, have it cross the target orbit, and see if I get a close encounter near the intersect. As my orbit still differs slightly, I will still phase forward ever so slowly with each revolution around the planet, but the steps will be really small now. I will find the point in the future where the close approach jumps from behind the intersect to in front, and then I will click and drag the maneuver node around the orbit and observe how the close approach changes. Typically I can find a close approach of under 300 meters like this. I may also occasionally find that my intersect disappears completely while I do this, because dragging the node to a different part of the orbit means it no longer has enough dV to cross orbits with the target from that position. In which case I add more dV and then repeat the process. This is also the part where inclination mismatch really interferes, so hopefully I did my step 2 properly.
(4b) Once I have my close approach of under a few hundred meters, it's just a matter of time to wait for the node to come up and execute the burn. I will typically turn my engine power down really low for this (by rightclicking on the part), and carefully use the throttle so that the burn takes three to five seconds despite expending only 1-2 m/s worth of dV. This greatly helps with precision. I will look at the rendezvous data display in the lower left to see my close approach change in real time as I burn. Often I can get even closer than the maneuver node suggested. I've managed to get an impact trajectory more than once!
(5) And then I just wait for half an orbit until I come up right next to the target, and light my engines one last time to match it and remain stationary.
 

Scientists do not influence the yield of ship-mounted experiments. The main reason to bring a scientist along is that they can reset goo and materials experiments, so you don't need to carry more than one of them even if you plan on visiting half a dozen biomes.
Scientists do modify the yield of Breaking Ground DLC surface experiments they deploy.

Whenever this question comes up, I like to link this guide.
It's very old by now, and its snarky comments regarding KSP's poor drag calculations are outdated and no longer true. However, all the construction principles remain just as relevant today as they were back then - and I have never seen them explained better in any other place.
(And yes, it does address the very common problem of veering off the runway on takeoff.)
 

There are apparently a few bugs with Kerbal inventories in the latest versions (1.12.2+). There's also a mod that fixes them, among other things.

Sorry for the dumb question but... is this the correct solar panel?
You're floating in front of a fully extended panel. Perhaps the one you need to repair is not this one, but rather a different solar panel, which is not currently extended (because it is broken)? Isn't there a mount visible on the opposite side of the truss in this picture? I'm not sure if it is another panel, but it well could be.

That sounds like a large build, so another guess is "not enough reaction wheel for its mass".
But we can only guess blindly if all we have to go on is a vague text description. Maybe you could post a few screenshots, or even the craft file?

I'm going to assume that when you say "SSTO", you actually mean "spaceplane" instead. Because it's trivially easy to make a standard rocket go single stage to orbit with plenty of dV left over.
Your plane has 4000m/s of vacuum dV, which should be plenty, given that it should only take about 3400m/s to reach low Kerbin orbit with a standard gravity turn trajectory. Hence, your choice of trajectory is to blame for losing about 600 m/s worth of dV along the way. Getting more TWR and climbing a little longer can certainly help improve this. But keep in mind that one major contributor is your launching off of the runway. That's just never going to be as fuel efficient as a start from the vertical pad.
Also, if getting more TWR means that you lose maximum dV in return, you may find that you gain little to nothing along the way. Your maximum possible upside from trajectory optimization is less than 600 m/s; if you stick to the runway start, it's probably in the realm of 400 at most. Switching from a Dart to a Swivel will drop your dV by about 300 m/s, depending on how much the extra weight is going to impact your plane. So you might gain about 100 m/s tops when reaching orbit. Workable, but not ideal.
(Of course, all of this is guesstimated, so your results may vary )
Another thing you can do is take a page out of the Space Shuttle's book, and make do with flying like a brick. As in: bring less wing, or bring more tank. This makes your landing approach harder, but it'll give you more dV to work with in orbit. You're at less than a 12x multiplier of your Isp in terms of dV, so you aren't that deep in the diminishing returns of your mass fraction just yet. If you can get back to like 4000m/s while mounting a Swivel, without increasing your wing surface, that should allow for more fuel leftover in orbit.
 

Welcome to the forums
The issue is that your relay satellites... are not actually relay satellites.
The DTS-M1 is a direct antenna, which cannot receive and forward other signals. The part rightclick info in the editor shows this, albeit just as a single innocuous line.
Refer to this table for a quick overview of what antennas can relay. As a rule of thumb, relay-capable antennas are always heavier and higher-priced for the same perfomance.
 

A long time ago, in a galaxy far, far away, I wrote this "little" explanation piece about the phenomenon you observed, and some of the lessons you can derive from it. I recommend giving it a read, and looking at your rocket stage design in a whole new way afterwards

Uninstall KSP in Steam Rightclick KSP in Steam Select Properties Click the "Betas" tab Ensure that the dropdown menu is set to "none" Close the Properties window Install KSP again If this does not give you the latest version, please contact Steam support about their client not working properly.

This is something for which there is no straightforward way to do it in the base game. As Jimmy said above, the engine plates included in the Making History DLC are specifically meant for this.
If you don't have them, you need to use surface attachment to circumvent the lack of dedicated parts.
Start by attaching the fuel tank of the lander to a fairing truss node, with a full size decoupler in between. No bi-couplers or anything here, don't ever use them in between stages, it never works. Just lander tank -> decoupler -> truss node.  This leaves you with a clean, full-size node stack top to bottom without any of the engines getting in the way.
Now, rightclick the fairing and turn off the interstage truss. Not the nodes, just the truss, so that your attached lander is magically free-floating but still attached. Yes, it looks stupid, don't worry, it'll be fine later. Then, you surface-attach engines to the bottom of the lander's tank inside the hollow decoupler, in such a way that they won't catch on the decoupler ring during stage separation.
But what if you want engines that cannot surface attach? Well, that's what the BZ-52 Radial Attachment Point is for. You surface attach a pair of those to the bottom of the tank, which gives you extra nodes outside the main node stack to attach the engines to.
Next, switch to the Move tool, select the decoupler, and move it down towards the fairing base until the engine bells are nice and close to it. Don't clip into it, that may not end well.
Finally, build the interstage fairing. Once it is closed, you'll no longer be looking at a magically floating lander - it is now (at least visually) supported by the interstage. Set the fairing to Not Staged, and it'll remain a fixed structure that never gets ejected until you leave it behind when the lander decouples.
 

Vessel antenna power = strongest antenna * ( sum of antennas / strongest antenna ) ^ Combinability
Combinability is always 0.75, except for the starter antennas.
So: 5,000,000 * ( 10,000,000 / 5,000,000 ) ^ 0.75 = 5,000,000 * ( 2 ) ^ 0.75 = 5,000,000 * 1.6818 = 8,409,000
Maximum Range = SQRT(Vessel_1 power * Vessel_2 power)
When the two vessels are identical, you're just taking the square root of a square, so the result is always the vessel's own power: 8,409,000
The Mun's orbit is perfectly circular with a semimajor axis of 12,000,000 meters. Therefore, you are correct: these satellites will not be able to establish a connection. Even three HG-5 per satellite would fall just ever so slightly short. Four would work, but with terrible signal quality.
Honestly, Mun/Minmus exploration without a DSN connection somewhere in the mix requires jumping through hoops until you unlock the 160-point node that contains the DTS-M1 and RA-2 antennas. It might be worth to just accept that your Mun rely satellites will only link back to Kerbin while the KSC is above the horizon from their view. This should not be a great problem for the science ground station, as it is perfectly capable of waiting for a valid comms link before transmitting its latest batch of science. And you'll still have a link for an entire half of each day anyway.
 
Correct, no third party ever influences the connection between any two given antennas, except perhaps for a celestial body eclipsing one of them.
 

It sounds like rocket construction is an area in which you can improve further. You'd be surprised just how much proper construction matters. A launch vehicle of five hundred tons in mass should get you really, really far if you built it well. I bet I could get a direct Hohmann transfer to a low solar periapsis in less mass than that, no need for a bi-elliptic one.
If you're encountering a case where adding more fuel to your rocket is no longer improving its dV, you are most likely adding that fuel to an already overloaded stage, thereby causing other stages to get choked by the added mass. The way rockets work is that everything you add on top affects everything that exists below. This may sound daunting - that's like, an unlimited number of variables to take into account!
Good news though - it's much easier than it sounds. Because the way the math works out, there's only one single number that matters for each individual stage, and you can in fact eyeball it most of the time and it'll be fine, so long as you avoid going really far off track. Doing the math just helps you learn how to eyeball it. I've written about it here before. Apologies, it's kind of a wall of text. I have a regrettable tendency towards those. Trust me though, it'll be worth your time
 
Note that this is very inefficient, due to something called the Oberth effect. It's a particularly arcane bit of orbital mechanics, and you had no way of knowing this beyond figuring it out through trial and error, so don't be hard on yourself over it This is what the forum is for.
The way it works, in simplified terms, is that spending fuel is more efficient the deeper down you are in a gravity well. It's not exactly that, but that's what it boils down to in practice in KSP.
What you have been doing is spending a small amount of fuel to get out of Kerbin's gravity well, then spending a lot of fuel to aim at your actual destination while you are not anywhere near a gravity well. Thus you spent more fuel than you needed to. What you should have been doing instead is spending all your fuel deep in Kerbin's gravity well - in other words, making the full transfer burn in low Kerbin orbit. Counterintuitively, the same amount of fuel - indeed, the same amount of dV - would give you a noticeably deeper Sun periapsis then.
Or, well, you can follow Zheetan's suggestion and do a bi-elliptic transfer. But even then, you'd ideally do the full transfer burn to your high solar apoapsis directly from low Kerbin orbit. Escaping Kerbin before even plotting your transfer is always the least efficient method.
But how do you get from this tiny circle around Kerbin to your destination in solar orbit? Well, imagine Kerbin wasn't there. Imagine if it was just your spacecraft in a solar orbit that happens to be identical to Kerbin's solar orbit. What would you do to lower your periapsis towards the sun? Burn retrograde to your solar orbit, of course. And if you wanted to get out to Eeloo? Burn prograde, of course.
So that's what you do, except that you must do it while circling Kerbin. You are in a low orbit around the planet, but your goal is still to make a burn in the correct direction relative to Kerbin's solar orbit. For example, if you want to go closer to the sun, you want to make a burn on Kerbin's sunlit side, so you are ejected from Kerbin's SOI "backwards". In other words, you make a prograde burn (relative to your low Kerbin orbit) that ejects you retrograde (relative to Kerbin's solar orbit). And going out to Eeloo is the same, just on Kerbin's night side. You make a prograde burn (relative to your low Kerbin orbit) that ejects you prograde (relative to Kerbin's solar orbit). In this way, the burn to escape Kerbin's sphere of influence is at the same time a burn in the right direction relative to solar orbit, so you can just keep burning in the same direction to lower your solar periapsis (or raise your solar apoapsis) despite still being just a few kilometers above Kerbin's atmosphere.
Of course, depending on the amount of dV you must spend and the acceleration your engines provide, making a very large burn in low Kerbin orbit can be very tricky. Because the orbit is so strongly curved, and you traverse a significant portion of the circle in just a few minutes, burns you make there grow less and less efficient the longer they get. If you burn at the maneuver node, you'll burn off-prograde for most of the time, whereas if you follow the prograde marker, you'll not burn in the right direction for most of the time. Rule of the thumb is that if your burn is longer than six minutes (three before the node and three after), you're starting to get inefficient.
You can get around this by splitting the burn. For example, make one burn that raises your Kerbin apoapsis to around where the orbit of the Mun is. (Take care not to actually encounter the Mun, you don't want that here.) Loop around once, and as you come back towards your Kerbin periapsis, make a new maneuver node there and start a new burn in the same direction as the first one - basically continuing what you started.
Once you have an escape trajectory out of Kerbin's SOI, you can keep burning until you have achieved your desired solar orbit destination.

The Advanced Grabbing Unit (also called "the klaw") is a part that can latch onto another ship and establish a docking connection without the need for a docking port on the target ship. Though, note, I'm not sure if certain difficulty settings might not interfere with fuel transfer across the klaw. Even in that case, though, you can still use the engines on the ship with the klaw to pull your Eve return craft's orbit down to intersect with the atmosphere. After that, it's just a question of aerobraking until you reenter.

The transfer app requires building upgrades. After all, you already need to upgrade a building to even make a maneuver node by hand. It would be silly to give you a tool that would make nodes for you even before that, right?
The fireworks launchers are parts, and like all parts in career mode, are somewhere in the tech tree.
If they are not in the tech tree, that would be a bug.

A Kerbal has only two inventory slots, yes. But some parts are stackable inside the same slot. That's why repair kits have this vertical bar once they are inside an inventory. It shows how many are stacked.
So you probably only need one of the two inventory slots the Kerbal has to transport four repair kits. I don't know the stack limit off the top of my head, but it's likely larger than 3.

Rather than tell you the answer, I'm going to tell you how to discover it yourself without even needing to go to Duna.
In the editor, build the craft you hope to launch from Duna, or a sufficiently similar stand-in. Now, click on the stage that has the engine in it to expand its view. You should be able to see its TWR there. Finally, go to the dV app in the toolbar on the bottom right. Make sure it is set to sea level. In the dropdown menu at the top, select Duna.
Your stage info will now show you Duna-relative TWR at Duna's sea level. If this number is greater than 1, you can launch with your current engine. If you then set the dV app to vacuum and refer to the Community dV Map for a typical cost to launch into low Duna orbit, you can check if you have enough dV as well.

TL;DR: It may feel like you're winging it, but as it turns out - it's largely the way things work. If you really want to skip making mid-course corrections, you can employ an external tool to precalculate a ballistic transfer for you.
- - - - - - - - - - - -
Eve's orbit is inclined compared to Kerbin's orbit. Eve's orbital period is different from Kerbin's. Even the eccentricity differs, although not by much. But, to put it in highly unscientific terms, these differences are not "the same", not "in sync". As in, If you fly transfers at various recurrences of the correct phase angle, then you will not always have the same transfer with the same plane change to do. Each time the planets line up in the correct angle, the alignment of orbital planes and parameters will be different. This means there is no magical solution to the way you should do your Kerbin departure burn that works in every case. You literally have to find a new unique solution each time.
As far as matching inclination directly through your Kerbin departure burn Kerbin goes - the general rule of the thumb is "you cannot". There are special alignments where it is possible, but outside of them, it flat-out doesn't work. If you think about it for a moment, the reason becomes clear. Where do you normally do your mid-course corrections again? The ascending/descending node, I hear you say? Yes, that is the correct spot. At these points (or rather, along the axis that goes through both of these points and the parent body), the orbital planes intersect. So you can go from one to the other. If you are not where they intersect, you cannot go from one to the other. Any attempt to do so will invariably lead you to go into a different orbital plane instead (even if only slightly different). Try and imagine it in your head - two paper discs stuck on top of each other at an angle, intersecting along a line. And you can only travel along the rim of any given disc.
This means that, in order to match inclination with Eve's orbit directly with your Kerbin departure burn, Kerbin itself needs to be at AN or DN with respect to Eve's orbit. Then, and only then, this maneuver works. You'll simply be folding your normal AN/DN course correction into your departure burn. Of course, since the difference in orbital periods, inclinations, and eccentricities are not "in sync", Kerbin won't do you the favor of being anywhere near the AN/DN on most phase angle matches. People still use the so-called "apoapsis transfer" to go to Moho, because a Hohmann transfer to Moho is the single most dV-expensive and precision-dependant transfer you can make in stock KSP, and most people would rather have a cheaper and less finnicky option even if it takes a few years longer to arrive. For Eve though, which is already one of the cheaper transfers to other planets, this seems unpractical.
You can, however, still typically get a direct Eve encounter from Kerbin orbit anyways. The lack of sync just means that this will be fairly easy to do for some opportunities, and fairly hard for other opportunities.
The next thing you need to understand is that, by being in Kerbin orbit, you are also in solar orbit, because Kerbin itself is in solar orbit. KSP does a bit poorly at representing this fact, due to the way you can only be in one sphere of influence at a time. But orbital mechanics won't let you cheat either way. Try launching a spacecraft into a perfect 90° polar Kerbin orbit. Now make a retrograde escape burn like you normally would when going to an inner planet like Eve. What's your inclination around the sun going to be like? 90° too? Hah, not even close. It's likely going to be less than 9°, even. The maximum solar inclination you can achieve by leaving Kerbin is the inclination of the upper (or lower) edge of Kerbin's spherical SoI with respect to Kerbin itself. 84,159,286 meters above Kerbin's own solar orbit. You cannot go any higher without a plane change in solar orbit. And most of the time, you will be far lower than that, even when leaving Kerbin from an inclined orbit.
This means that, in order to attain even a few degrees of solar inclination through your Kerbin departure burn, you'll need a highly inclined departure orbit. And these things are... uncomfortable. For starters, doing plane changes in low Kerbin orbit is so expensive that you'd be spending far more dV trying to enter that inclined orbit after launching into an equatorial one than you would save by not making a course correction in solar orbit. No, in order to make this worth the effort, most of the time you'd have to launch directly into the inclined orbit. This also costs more dV than an equatorial launch, because you're not getting the full eastward rotation bonus; it's difficult to fly, since you need to actively steer rather than just letting the rocket fall over towards the east; and it's even more difficult to time it right. In contrast to an equatorial orbit, which has most of its orbital parameters nulled out and irrelevant, an inclined orbit needs to be inclined correctly. Not just the correct amount, but also the correct direction: the so-called longitude of ascending node (LAN). To get this one right, you have an instantaneous launch window - you need to launch at exactly the right time of day, when the launch site is directly under where you want your inclined orbit to be. You may or may not have some practice with this kind of launch window through exploring Minmus, where you can launch directly into a 6° Kerbin orbit in the moment where the launch site passes under Minmus' AN or DN with respect to the equator, and save yourself a plane change that way. But, in contrast to Minmus, here you have Kerbin's motion around the sun to consider. That means that for any given LAN value you select, the interplanetary transfer window is strictly speaking also an instantaneous window. If you wait too long past your opportunity, your laboriously achieved inclined departure orbit will slowly drift out of alignment with Eve's orbit.
That, anyway, is the "perfect" solution. An instantaneous launch window leading directly into an inclined departure orbit for an instantaneous transfer window that's been precalculated to represent the total trip dV minimum for this particular, unique planetary alignment. And if you're now sitting back and going "that's way too complicated", then at least 95% of the playerbase will eagerly agree with you.
Heck, even most third-party navigation tools agree, too Even Alexmoon's mighty Transfer Window Planner, which I absolutely recommend to each and every player, makes the default assumption that your departure orbit is perfectly equatorial and perfectly circular, because deviating from that assumption makes the calculation so much more complicated and the execution ingame so much more prone to imprecision. And it can still compute you ballistic (no course correction) transfer windows to Eve for every phase angle opportunity. You may ultimately be paying a few percent of extra dV to fly these... but considering how effortless it is to go around the stock system, that's honestly negligible.

In such a case, I like to press V repeatedly until the camera is in "locked" mode. You can then orient your view as you like it, and the camera will keep it fixed for you, so your orientation never changes. Perfect for translation maneuvers with RCS.
I believe that, when you use docking mode, W/S is forward/backward, A/D is left/right, and Shift/Ctrl is up/down. Same controls as for Kerbals on EVA, basically. With the locked camera mode, you'll always know which way is up, so you always know which key you must press to go where you want.