Plusck

The optimum trajectory is: as flat as possible. There are only two reasons for it not to be perfectly horizontal on lift-off:
you cannot accelerate hard enough to go fast enough to reach orbit before you start falling down to the ground again you cannot get streamlined enough to avoid huge drag losses in the lower atmosphere. The answer to issue 1 is essentially the same as on any airless body: you start going upwards to clear the terrain, then burn as horizontally as possible while maintaining a minimal positive vertical component to your velocity. In other words, head for the horizon on the navball while making sure that the prograde marker stays very slightly above it.
The added complication of having an atmosphere is that your ship has drag, and that drag is probably (assuming normal ship design) going to be lowest when you're pointing nose directly forward and engines directly rearward. Therefore your only efficient solution is to be pointing prograde at all times. Drag also affects control over the ship, and you probably also have best control (assuming normal ship design...) when pointing exactly in the direction of travel.
And this brings us to neatly to issue 2: you want to get out of the lower atmosphere quickly, while always pointing in the direction of travel (especially while in the lower atmosphere...). Therefore you have to start vertically and make a gradual turn to horizontal as soon as possible but slowly enough to get out of the thick atmosphere.
That compromise: "as soon as possible but slowly enough to get out of the thick atmosphere", is your gravity turn.
So, the gravity turn has to be:
perfectly smooth (therefore minimising drag and control problems), i.e. facing prograde exactly at all times, at full power at all times (otherwise you could use less engines, saving weight), ideally, at lower altitudes, executed at a speed not exceeding the terminal velocity of your ship at that point (since on reaching terminal velocity, drag = 1g, rising exponentially: you'd lose less by climbing for a bit longer rather than trying to climb a bit faster). This is really only an issue for the first few mostly-vertical kilometres. Exactly what the gravity turn looks like will depend on your thrust-to-weight ratio.
A high TWR means you reach orbital velocity faster. Therefore the gravity turn has to be finished quicker - which means starting it more agressively off-prograde or launching at less than 90°. Therefore you end up going a lot faster in the lower atmosphere and losing more energy to drag (converted into a lot more heat on your ship's skin).
A low TWR means that the gravity turn has to be much more gentle. At the lowest feasible TWR, your gravity turn only comes to an end when you reach orbital altitude: you burn constantly from lift-off to orbit circularisation. You lose less to atmospheric drag and much more to gravity losses. What you lose on fuel, however, you more than make up for on cheaper and lighter engines.
And finally, to find that best trajectory, one of the easiest tools to use is available in vanilla via the map: time-to-Ap.
On lift-off, time-to-Ap is necessarily zero and rising. It therefore doesnt help much as you try to start your gravity turn right.
However, it becomes a very good indicator of efficiency when you're at around 8-12km altitude, 45° inclined to the horizon. At that stage, time-to-Ap should be around 30s or 40s or so, climbing slowly before stabilising, then remaining that way until you're nearly in orbit. The lower your TWR, the higher this number has to be. For a low TWR ship, you need to stabilise at around 50s. For a higher TWR ship, at 40s or less. Maintaining prograde lock and this time-to-Ap should get you very efficiently to orbit.
And conversely, if you have a low TWR and time-to-Ap starts falling below about 40s or 35s, you know that you've messed up and are losing vertical speed too fast. It's only recoverable (if at all) by aiming a lot more radially out, meaning a big loss of efficiency.

The problem - as I see it - is that your question is essentially unanswerable.
There is no possible "efficient" solution if the starting position includes both (1) a 9:11 LFO mix, and (2) Nukes (any number).
Each engine has a "peak efficiency" curve. Or rather, several such curves depending on the variables that you are measuring efficiency by. The variables you can use are firstly payload, TWR, dV. Then secondly cost, fuel mass, playing time, required additional equipment (i.e. part count), elegance. From the first three (payload, TWR, dV) pick one as a fixed variable, and then you can relatively easily plot the other two as a curve.
And good example of this is here: https://meithan.net/KSP/engines/
It's a bit old now, and some engines might be wrong, but the principle is sound. This is the graph for a 40 tonne payload:

Each "step" in the graph represents an additional engine. So you can see that for this 40t payload, if you want more than 0.5g thrust, nukes are only the best option if you have 7 or 8 of them. And you intend to run them for a dv of about 1800 - 2500 m/s.
So the trouble with nukes is that they are so heavy that they need to keep burning for quite a while before their efficiency makes up for their own mass. Or the payload has to be so big that the mass of the engine becomes less relevant.
And in all cases, if you start looking at the other "efficiency" variables, such as cost, manouverability, low part count and so on, there will always be a better option, and that option is often the Poodle... And if you have to start calculating how much extra liquid fuel you need to carry to balance the LFO mix burnt by one of the chemical rocket engines, you lose that last possible efficiency benefit: your playing time.
The pic above doesn't show you the next best option, but you can see that if you follow the link and use Meithan's tool. In most of the usual scenarios, that second-best option is either the Aerospike or the Poodle. One of those two has a distinct advantange for cost and manoeuverability (and therefore part-count); no guesses which...
So, no, there is no real answer to your question. If you want to move a big orange tank somewhere, you definitely don't want to use a nuke to do it. If you have nukes onboard already, you'd be best ramming them into something and destroying them so you can lighten the load.
However, creating a nuke tug is definitely a good idea. Create a re-usable, drag-and-drop nuke-based interplanetary booster, with radiators, drop tanks, torque wheels and suchlike, and you will definitely end up with a very efficient system, certainly better than any LFO alternative (at least until the Rhino becomes a reasonable option, for huge ships). But don't try to mix it with any LFO engine, you'll waste either the benefits, or your time, or both.

Thanks for picking up on that. My phrasing sometimes could do with being clearer, since I did say the only mod I have is KER and I used the stock cheat to set the orbit, but it got a bit lost in the other things I was saying
So to be clear: I don't have HyperEdit installed and haven't for the last couple of versions of KSP. Last install was fresh 1.3.1 + latest KER + custom flag (I like flying the Saltire).

Personally, I'd start with Moho since it's easy to flyby if you leave Kerbin around day 80 or day 300 in any given year and catch it on your second time around the sun.
So I'd start by going past Minmus on the way down to Moho's orbit. Correct at Pe to get a Moho flyby the second time round. From there adjust to flyby Eve and Gilly, to send you back up to Duna. Probably the trickiest part of the whole journey.
Land on Duna then Ike, then eject to Jool. Use a Tylo flyby to cature and get sent down to Vall and use that to capture slower at Laythe, flying (and getting contract 2) then landing there.
Then back up to Tylo to land. Then eject the Jool system via Bop (getting contract 3), on the way to Eve again. Land on Gilly then end on Eve (getting contract 1).
So that makes:
- Minmus (flyby)
- Moho (flyby)
- Eve (flyby)
- Gilly (flyby)
- Duna (land)
- Ike (land)
- Jool (flyby)
- Tylo (flyby)
- Vall (flyby)
- Laythe (fly, land) (contract 2)
- Tylo (land)
- Bop (flyby) (contract 3)
(- Kerbin flyby to reduce Eve arrival burn?)
- Eve (flyby)
- Gilly (land)
- Eve (land) (contract 1).
Total from LKO I estimate at about 7km/s plus a 5km/s lander (with half of that as drop tanks, only used for Laythe and Tylo), plus whatever you need to capture at Eve that last time (which could be huge if you can't aerobrake or step down to it gently via a Kerbin gravity assist).
So actually, that makes me wonder whether it wouldn't be best to start with the Eve flyby and Gilly landing, then do Moho-Eve-Duna, so that you don't need any fuel at all after leaving the Jool system and coming back at Eve for that final, non-recoverable landing.
And that is one huge ship.
 

Good idea - the wiki entries don't give all the relevant facts.
The numbers given in the wiki for production on a CB are exact (I checked this for a thread recently - "ISRU is less more" - with a ton of small drills on a good patch on Minmus). So it's definitely 1/5th the production of the larger drills.
And a large drill (with no engineer) will produce 0.25 ore/sec on an asteroid. It will not lose mass if the drills are at 100% efficiency, but will lose mass if they aren't. I'd guess that the small drills produce a fifth of that, chucking the rest of the mass away.
So yes, there are three things to write into the wiki:
ore output from an asteroid, for both the large and small drills (definitely 0.25/sec for the large, probably 0.05/sec for the small); mass loss (meaning ore loss) using the small drill at 100% efficiency (which i suspect will be 0.20/sec x 5kg = 1kg/sec); mass loss (meaning ore loss) using either drill at less than 100% efficiency.  

As others have said, Puffs are useful if you have to carry Monoprop but won't be using all of it, and you could do with a bit more thrust than the RCS thrusters but don't want to add a whole new fuel tank.
The downsides are that monoprop doesn't give great Isp, and monoprop tanks are slightly heavier than their LFO counterparts.
The upsides are that you don't need to worry about exact ratios of fuels between RCS and main engines (they'll both work until you are dead in space) and the smaller stacking monoprop tanks take up less space than their equivalent-sized LFO counterparts.
One situation I've used them is to send crew home after expanding a space station somewhere: I need monoprop for docking, but once docked the tanks are just useless parts. If they're attached to the command pod, I can simply decouple that and use Puffs to get back to Kerbin.

You can use F3, but that will include the movement you get from the rotation of the surface. So to get the real figure, you need to multiply the time spent by your average difference between orbital and surface speed (orbital speed minus surface speed), and subtract that (which would result in adding, if negative) from the total...

1) You've already seen in the first orbiting tutorials that the best place to raise/lower Ap is at Pe, and the best place to raise/lower Pe is at Ap.
When you leave the Mun's SOI, your surplus speed (called V∞ or Vinf) has the effect of a retrograde burn from a circular, Mun-altitude orbit. Therefore you want that velocity change to be perfectly retrograde. That means leaving the SOI on a line parallel to its direction of movement.
So, if you imagine you were following the Mun's orbit (without the Mun being there), and had the absolute minimum amount of fuel on board to get home, you would have no option but to burn directly retrograde. If you burned at any other angle, your Pe would necessarily be higher.
Therefore, watching your Kerbin Pe as you drag the node around indicates whether you have that retrograde ejection angle perfect, or not.
2) Actually, it isn't quite the most efficient if you make it perfectly parallel at the time of the burn. It takes time to leave the Mun's SOI, by which time the Mun will have travelled along its orbit. You should find that the most perfectly efficient return trajectory is therefore going to be rotated slightly (anti-clockwise, from the point of view shown in your pic).
The faster the ejection speed, the closer to perfectly parallel it should be (if you leave at the Mun's orbital velocity, you are essentially coming to a dead stop in space and won't move from spot you're in right now as the Mun moves away from you - and in this case you would want the angle to be perfectly parallel - but on leaving the Mun's SOI you will just fall straight down into Kerbin).
3) When you leave the Mun to go home, you're optimising the angle of your Vinf velocity to reduce Pe around the major body, Kerbin.
When you go interplanetary, you want to optimise the angle of your Vinf velocity to raise Ap or reduce Pe around the major body, the sun, to get to a different level orbit around the sun. It's exactly the same principle: for maximum efficiency, you change orbit by changing velocity purely prograde or retrograde, which means leaving along a line parallel to your starting orbit.

Ah ok.
In that case, I'd forget about trying to make a relay unless you feel like making a serious commitment to it.
With a serious commitment, 6 to 8 strong antennae (88s basically) on a ship could be very useful later on. Just send out prograde and look at when you reach sun orbit Pe - you should burn until it reads 1 year 180 days or so. Then wait for Pe and make circularise to follow Kerbin's orbital period exactly.
But without that serious commitment, your sun orbit relay will be pretty useless. It might help once in a blue moon but everything would have to be perfectly aligned for that.

OK, well your pitch control is constantly on, pitching down.
I was going to suggest cancelling trim (alt-X) but when you engage SAS it should automatically negate any trim (it takes over, and trim only returns when you press an input).
Do you have any controllers or joysticks or something connected? Something it creating that pitch input, and whenever there is input, SAS disengages to let you fly manually.
Beyond that I can't help - this is more a "technical support" question than gameplay...

I just checked this out with an 80-drill rig hyperedited to an 8.4% ore patch on Minmus, with level 3 engineer.
Unfortunately I scrimped on cooling, so it was only possible to see it for a second as the drills hit 100% efficiency...
Still, the numbers all tally. "Ore rate" is given as 0.021577. That is 0.015 (small drill rate) x 17 (3-star engineer) x 8.46% ore concentration. Total ore production with all 80 drills active is 1.73 ore/s.
The small ISRU, meanwhile, consumes 2.5 ore/s for an LFO mix of 0.5 total (0.22+0.28).
That means you'd need 116 small drills (+ 3-star engineer) to keep up with one small ISRU.
Meanwhile, next door, my single large drill produces 0.11 ore/sec and the ISRU uses 0.5/sec to produce 0.45+0.55 LFO, so a fifth of the consumption for twice the output.
Therefore I'd need 4-5 large drills to maximise production for this ore concentration with my 3-star engineer. Or 23 drills if I used the small ISRU...
 
There is, however, a difference between "surface harvesting" and "asteroid harvesting". A large drill will mine 0.25 ore/sec from an asteroid (without an engineer on board). Therefore you only need 2 drills for 1 large ISRU on an asteroid.
 

I took a look too. My conclusions are slightly different: your only real problem is in your final (lander) stage: there is no way you'll get home with it, even though your transfer stage will be virtually full of fuel when you ditch it.
The two sets of reaction wheels at the top of the lifter stage are unnecessary and you can remove them altogether. You have plenty of fins for aero control and gimbal for upper atmosphere/vacuum control. The single reaction wheel at the top can easily get you lined up for the transfer burn on its own. That also lets you get rid of the struts holding the craft together around those weak reaction wheel joints.
You should make LKO with about 1000 m/s left on the Twin Boar - so your transfer to Duna can be done with the lifter stage. That leaves over 2km/s just to get into Duna orbit. The problem is that without docking ports, you can't use the transfer stage to refuel for the return home. Your lander has about 1700m/s, which is just too tight (you'll certainly need some of that to land on Duna, so you'll be nearly dry on returning to orbit). If you use a pair of docking ports to attach to the transfer stage, and a basic probe core to stop if from being automatically treated as debris, you can meet up in orbit, transfer fuel across and be laughing for the return home.
 
edit: just re-read the original post. You're right that the transfer stage can be used to land, but you'll have no landing legs and you need to at least start the return to orbit using the transfer stage if you're going to have enough fuel to get back to Kerbin. If you plan on doing that, you can put parachutes/drogues on the 2.5m section, airbrakes too if you want, and leave the final stage light and clean (plus a couple of photovoltaic panels) so it can get home on its own.

I think it's simply that you're putting too much weight on that surface attachment.
If you look carefully at the video (notably at about 8:17), when the guy mouses over different cargo bay sections and you see which bits of craft are highlighted as "children" of those parts, the side stack of fuel tanks appears to be separated into at least two parts, connected to the second and fourth  (?? I think) cargo bays. The wings are connected in two parts too - the front section to the second fuel tank, and the rear section (most of the wing) to the rear or second-to-rear tank.
So I'd guess that the fuel tanks are simply too heavy for a single surface attachment at the rear. Struts might help. KJR should help too. Attaching them the tanks with cubic struts then clipping them in might also help. Clipping the tanks further into the body might too.
See here for an example with ore tanks:
 
Ore tanks have terribly weak joints. Clipping the first set solidly into the core stack lets them all hold on.
However, if I use just the default clipping with a symmetrical attachment without moving them, the weakness of the first joint makes the others move too, so they all fall off. The first tanks only just hold on:
And if I move them further out still, they ALL fall off:
 
So I'd say that you simply need to move the tanks further in to the cargo bays and they should hold on. I wouldn't attach the lowest tank first - perhaps the second lowest, to keep it relatively close to the engine and the central point for transmitting forces from the wing.

For the Duna system, I use Ike to park all my craft.
My reasoning?
- Mining on Ike involves far less loss on returning fuel or ore to orbit, and cheaper and easier landing wherever the ore is.
- A low-ish orbit around Ike allows faster warping; you need a higher orbit around Duna for the same warp speed.
- Going interplanetary from low Ike orbit is cheap enough, with no benefit to going back to low Duna orbit.
- Getting to Ike from an interplanetary transfer is easy and cheap enough if planned well, with only a couple of maneuvres. Duna orbit may be simpler, but either (a) you insert into a too-high orbit to benefit from aerobraking or the Oberth effect, or (b) you brake low then have to raise your Pe, which is wasteful.
 

It's probably just that the front end is light, so drag on the body acts as a big lever around the CoM that your control surfaces/torque wheels are powerless to overcome.
If you have canards, that can help until you exceed the control angle of the canards - then they do the opposite and create a whole lot more drag at the front so you flip.
The only real solution is to put as much heavy stuff as possible at the front. Fuel will work, but you might need a locked tank because re-entry will cause the same issues. An upwards-facing Vernor or two on the nose could help.

The "ore extraction rate" is what the drill is capable of in that particular patch of ground. It isn't the actual throughput, except when at 100% efficiency. IIRC the ore extraction rate changes when an engineer is on the craft (depending on level). In other words, it's more-or-less an indication of the amount of ore in the ground.
The "80%" figure is "80% of maximum ore concentration", not 80% ore. The maximum ever ore concentration you will find is about 10% (again, IIRC - I play on medium difficulty and have never seen more than 8%...).

The easy solution is - shift-click.
The problem with merged craft is only the root part can be attached to anything, and only if it has a spare node.
If you shift-click to chop off part of a phantom object, the part you grab becomes the root part for the group you just hived off, and it has a spare node.

Each of the "flats" on Minmus is a separate biome, so that makes several biomes you can easily visit still.
If you're looking to max out science, you really need to use the science facility's "archive" feature - and you'll be able to see quite quickly how many biomes have been covered and which experiments you've missed out on. I'd also recommend checking it relatively often, because it doesn't take any time if you're already at KSC but it tends to get to be TMI to process easily if you wait until you need to find missing bits of science here and there...

Yes, I understand.
Although some people may prefer doing the opposite, I am convinced that inverting up and down is "best" : most of us have played some sort of flight sim, then some games where W moves you up and S moves you down, plus there are some computers/phones which scroll upwards when you swipe down and vice versa. However in every single case, left is left and right is right. So we're constantly dealing with inverted Y-axes but never with inverted X-axes. You should get used to it very quickly.
Still, that doesn't solve your problem because you're vertical, and there is no simple way of knowing which way is which.
In your situation, assuming that RCS isn't activated for nothing, I'd bring the camera up directly over the rocket to start with, then just tap RCS translate right and left to see what fires. I'd then bring the camera down so that is looking down at about a 45° angle, with "left" and "right" the right way round, and force myself to invert the Y-axis in my head. So pressing W will bring the nose towards you and S away from you.
Quicksave and try it, I'm sure you'll pick it up quickly and be able to scoot along just a couple of metres off the surface in no time.
However, if the craft is heavy and doesn't rotate quickly, the simplest solution might be simply to select target, climb vertically 50m, maintain a constant altitude and perfectly skywards heading, and use RCS translate and target mode on the navball to do it as if you were docking.

Well, it's a bit more than that now
You really don't need to add more altitude, unless you're trying to slow a very fragile big craft and want several parachutes to open progressively at different heights. You can generally reduce that 1000m to 800m or less and still have virtually no chance of encountering a problem.
The full deploy "altitude" is your distance from the ground, not sea level. Air pressure, however, is completely dependent on height above sea level as Pecan says.

If you mean using the rotate gizmo on ghost parts, that is a feature that apparently no longer works but which even massively experienced players generally never even knew existed...
You can still rotate before placing with WASD/QE and shift-WASD/QE.

This happens on slopes on some moons. There is some sort of bug with the planet surface, so when you return to the ship the game thinks you're in the air. There is clearly some error-checking code in there, because you do get plonked back down on the surface, but by that time the drill already thinks it's lost ground contact.
There isn't much you can do. If you restart the drill it should work fine. If you babysit the craft it'll continue to work fine, even at high warp. If you go away, it'll probably lose ground contact again when you come back.
Apparently the mining that gets done while you are away is calculated when you return to the ship, so if this happens you'll never mine anything during the time you are away.
So basically - move to another flatter spot (with no guarantee that it'll work... Pol in particular is a bit messed up), or babysit while you are mining.

To post pics, don't use the URL that the host site tells you to use, but the URL of the image itself, which is https://img2.picload.org/image/rgawdrli/screenshot22.png
As for your question, I'd say your orbit is going exactly the wrong way compared to the contract's request. Hard to be sure without seeing the animation but it sure looks like it with the fade. :/

Size and weight. Since the LV-N is so heavy, it only makes sense to use it if you give it plenty of fuel, which means your lander has to be huge. You can't control that without some serious torque wheels or RCS, which adds more weight. If you use RCS, that makes you dependent on your monoprop. You can't use Vernors because you aren't carrying Ox.
If you use a Terrier, you have gimbal so virtually all maneuvering can be done with that, and command pod torque is enough for the rest. That means that you only need RCS for docking, so you can carry minimal amounts. The lander sits lower, which is convenient when gravity is quite high. And if you want to go a lot further, with the aerospike you can add a ton of fuel yet still have a decent TWR, and use Vernors for RCS control so you only depend on your total fuel load.
This is the design that I used for the Mun but which I got bored flying ; )

It is too heavy for use on Duna (unless you burn off enough fuel before coming in to land), so I messed with it a little just now. I then messed again to give a non-nuke variant.
Admittedly, there are things I would do differently if starting from scratch. Also, looking again at that chemical variant, it would be better with an additional FL-T200 on top of each of the fuel stacks. That would give about 1.2km/s (vacuum) before the drop-tanks were dropped, and about 4.2km/s (ASL Duna) afterwards with a TWR of 1.5.
Admittedly also for the LV-N version, TWR is atrocious to start with. I'd want chutes to land it the first time...

There was a longish thread about this last year:
And it seems that @Claw and others made tools for this purpose - but they don't work in 1.0.5 ...
I'm sure there was a more recent thread on this subject, but I can't find it.
From what I remember of dicussions here, the answer is "yes it's possible" but it's a pain because of the changes the game makes to the ship to convert it from an editable structure to a working entity. With a monster of a ship like yours, reversing those changes manually would be a herculean task.
Another thread with a tool that might help you in this endeavour:
 
Finally, I don't think there is a difference between the "autosaved" ship and the craft file - so if you can extract the rover's info and make it craft-like, you might as well just save it as one.